Sophos AI Defense: detectar y controlar el uso de la IA

Sophos AI Defense hace visible el uso de aplicaciones de IA y controla qué servicios se permiten, generan una advertencia o se bloquean. Este complemento de pago para entornos Sophos EDR, XDR y MDR que cumplan los requisitos está disponible de forma general desde el 13 de octubre de 2026. Se gestiona en Sophos Fusion y utiliza sensores de Sophos existentes. Sin embargo, una licencia, un mosaico visible o un asistente completado no demuestran por sí solos una recopilación completa ni una aplicación efectiva de los controles.

Para implantarlo, se recomienda seguir este orden: aclarar la licencia y el estado de Fusion, inventariar las fuentes de datos y las políticas existentes, implementar de forma controlada los requisitos de los sensores y, solo entonces, probar una política de alcance muy limitado. La inspección del contenido de los prompts no es una función de protección actual garantizada: la comunicación del fabricante es contradictoria al respecto. El alcance que puede planificarse con seguridad en este artículo comprende la visibilidad, las políticas de acceso a aplicaciones y los informes, con fecha de revisión del 20 de octubre de 2026.

Qué significa Shadow AI y qué problema resuelve AI Defense

Shadow AI es el uso de IA al margen de los procesos previstos de autorización y control. Por ejemplo, una empleada utiliza otro chat web, un desarrollador instala un asistente de programación o una aplicación existente incorpora una nueva función de IA. El servicio puede resultar útil y, aun así, carecer de reglas claras sobre los documentos o el código fuente que se cargan, el uso de datos para entrenamiento o su ubicación.

AI Defense reúne tres preguntas: ¿qué aplicaciones de IA se utilizan, qué riesgo se les atribuye y qué política de acceso debe aplicarse? La descripción del producto menciona modelos de lenguaje accesibles desde el navegador, como ChatGPT, Claude.ai y Copilot, y aplicaciones más recientes de programación, escritorio y agentes, como Claude Code, Cursor y OpenClaw. Estos ejemplos no garantizan la detección y el control de todas las variantes, conexiones API o actividades en todos los dispositivos. Lo determinante sigue siendo el sensor concreto y la cobertura realmente observada.

En los análisis, Unsanctioned significa que ninguna política permite expresamente una aplicación utilizada. Se trata, en primer lugar, de un estado de autorización, no de una prueba de malware o de una fuga de datos. A la inversa, permitir un servicio no autoriza automáticamente cualquier uso. Sigue siendo necesaria una norma organizativa sobre qué datos pueden introducirse en cada servicio.

Además, AI Defense no es el Sophos AI Assistant ni AI Search para investigaciones de XDR. En esas funciones, la IA ayuda a los analistas. AI Defense controla el uso de IA en la organización. Ni el nombre Fusion ni las funciones de Assistant existentes activan automáticamente el complemento.

Aclarar previamente la licencia, Fusion y los sensores

Antes de comprar y antes de configurar deben comprobarse requisitos diferentes:

Derecho de compra: AI Defense es un complemento de pago para clientes Sophos EDR, XDR y MDR que cumplan los requisitos. Sophos exige también utilizar Sophos EDR Endpoint Protection. Por tanto, una licencia de Sophos Endpoint sin más o una Sophos Firewall independiente no acreditan que se cumplan los requisitos. El alcance contractual concreto se comprueba siguiendo Activar y comprobar licencias.
Acceso técnico: la configuración documentada exige una cuenta de Sophos Fusion actualizada a la nueva plataforma con Security Operations. La comprobación de la transición a Fusion distingue el nombre del portal de la actualización real del producto.
Excepción de compra para Taegis: los clientes de Taegis que cumplan los requisitos pueden comprar el complemento desde su disponibilidad general sin esperar a migrar a Fusion. Esto no constituye una excepción documentada a los requisitos técnicos de configuración. Antes de implantarlo, deben aclararse los derechos, la vía de despliegue y el estado de actualización con el interlocutor responsable de Sophos.
Sensores adecuados: el asistente de configuración ofrece actualmente Sophos Endpoint, Sophos Firewall y Sophos Linux Server. La descripción general del producto menciona también DNS Protection, Protected Browser y Sophos Data Lake como fuentes de datos. Esta enumeración más amplia de la arquitectura no debe interpretarse como una lista idéntica de opciones ni como una capacidad de aplicación de controles equivalente en todos los componentes.

Antes de realizar cambios, se documentan los usuarios, dispositivos y redes afectados, los valores previos de las políticas, los administradores responsables y el procedimiento de reversión. La carga de datos y el descifrado HTTPS afectan a la privacidad y a las aplicaciones existentes. Su autorización debe obtenerse antes de activarlos, no durante el análisis posterior. Para la prueba piloto se utiliza un usuario de prueba autorizado en un dispositivo de prueba gestionado; los cambios necesarios en políticas compartidas no deben afectar accidentalmente a toda la organización.

Preparar los sensores y completar la incorporación

Abra Sophos Fusion y, a continuación, My Products > AI Defense > Get started. El asistente pregunta por la función del administrador, su experiencia con herramientas de IA, el número de usuarios y el sector. En Choose your sensors, seleccione los sensores que realmente se utilizan. Después deben confirmarse sus requisitos. Marcar una casilla confirma que se han comprobado; no sustituye la verificación de su efecto.

Sophos Endpoint

Sophos documenta los ajustes siguientes para el sensor de Endpoint:

En Endpoint > Policies > Data Collection and Investigation, active Upload to the Data Lake en la política correspondiente y seleccione Process Data, HTTP Data, DNS Data y Network Data.
En Endpoint > Policies > Threat Protection, active SSL/TLS decryption of HTTPS websites y Block QUIC browser connections. La recopilación documentada requiere esta configuración; sin comprobarla no debe suponerse una visibilidad equivalente. El descifrado HTTPS y el bloqueo de QUIC pueden afectar a las aplicaciones. Pruebe los cambios de forma controlada y no elimine indiscriminadamente las excepciones existentes.
Cree un perfil web en Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles. Asígnelo, en Endpoint > Policies > Web Control, a las políticas nuevas o existentes de los usuarios y dispositivos previstos. No es necesario utilizar el mismo perfil en todos los casos.
En Endpoint > Policies > Application Control, active Detect controlled applications when users access them y seleccione Block the detected application. Antes de cambiar nada, compruebe las asignaciones de aplicaciones existentes y su efecto; Endpoint Application Control explica esta configuración.

Take me to settings abre la configuración correspondiente. Tras aplicar los ajustes, vuelva a comprobar su asignación efectiva al dispositivo de prueba y solo entonces confirme los requisitos en el asistente.

Sophos Firewall y Linux Server

Para Sophos Firewall, los firewalls previstos deben estar incorporados a la gestión de grupos en Firewall Management > Firewalls. Los firewalls que no estén bajo gestión de grupos no reciben reglas de aplicación de controles de AI Defense. Además, cada política web pertinente debe tener activado el registro: abra la administración web del firewall mediante su menú de tres puntos, seleccione la política correspondiente en Web y active el registro. Sin él falta la actividad necesaria para la detección. Compruebe la pertenencia a grupos y las reglas de grupo existentes antes de realizar cambios, para que la incorporación no modifique inadvertidamente otros ajustes del firewall.

Para Sophos Linux Server, la configuración exige activar Upload to the Data Lake con Network Data en Server > Policies > Data Collection and Investigation. Esto no implica que Linux Server aplique los mismos controles de acceso a aplicaciones que Endpoint o Firewall. La vista previa de la política mostrará después a qué producto se aplica cada regla.

Si el asistente no puede verificar el estado del sensor, ofrece Refresh. Si la comprobación sigue sin completarse, permite continuar. Esto no constituye una prueba satisfactoria del sensor: la discrepancia queda pendiente y debe investigarse antes de aceptar la protección.

No tratar la Base Policy como un borrador sin efecto

En Define your base protection se crea la Base Policy si todavía no existe. Se aplica a toda la organización. Generative AI category default establece Block, Warn o Allow para las aplicaciones sin una regla propia. Las reglas específicas de aplicaciones prevalecen sobre este valor predeterminado. El asistente muestra aplicaciones de los últimos 30 días; esto no indica el plazo general de conservación de los datos.

Create base policy and finish crea la Base Policy. También puede omitirse este paso. Si ya existe una Base Policy, la incorporación no la modifica; Finish and take me to the policy abre su estado actual. Una política preparada por el partner debe revisarse primero, no sustituirse por precaución. Settings > Restart onboarding permite reiniciar el asistente; no es un restablecimiento ni una reversión documentados de las políticas existentes.

Para una prueba limitada, no cree una regla de bloqueo para toda la organización basándose en suposiciones. Primero debe aclararse qué valor global predeterminado está autorizado por los responsables. Después se crea la política piloto con un alcance expresamente limitado.

Crear políticas de AI Defense de forma segura

En My Products > AI Defense > Policies > Create policy, asigne a la nueva política un nombre de libre elección, por ejemplo, AI-Pilot-Freigegebene-Dienste. La descripción recoge la finalidad, la persona responsable y la fecha de revisión prevista. La política consta de Rules y Scope.

Reglas y prioridades

Tanto la lista de políticas como las reglas de cada política se evalúan de arriba abajo: decide la primera entrada que coincida. Por ello, una regla correcta situada debajo de otra que coincida antes puede no tener efecto.

Una política adicional nueva contiene de forma predeterminada una regla que bloquea todas las aplicaciones de IA. Sophos recomienda dejarla al final y crear autorizaciones específicas encima. Durante la prueba piloto, esta regla de cierre solo debe afectar al alcance de prueba autorizado. Activarla sin cuidado para todos los usuarios podría bloquear también flujos de trabajo previamente permitidos.

Con Add Rule, seleccione la Action y, mediante Add Filter, una Dimension y su Value. Las dimensiones admitidas incluyen, por ejemplo, la aplicación, el nivel de riesgo y las propiedades de cumplimiento ofrecidas en la interfaz. En Application, se seleccionan aplicaciones concretas de la lista. Utilice únicamente valores realmente disponibles; una clasificación de riesgo no sustituye la revisión propia del servicio y del contrato adquirido.

Allow: permite el uso de la aplicación que coincida.
Warn: muestra un aviso a los usuarios, pero les permite seguir utilizando el servicio. No sustituye un bloqueo.
Block: debe bloquear el uso de la aplicación que coincida mediante el producto compatible. La prueba piloto debe demostrar si funciona para la vía de acceso prevista.

Un ejemplo adecuado consiste en situar una aplicación expresamente permitida encima de la regla de bloqueo de cierre y utilizar una segunda aplicación autorizada para la prueba, pero sin una regla de autorización propia. Así puede comprobarse la lógica de excepciones prevista sin emplear contenido confidencial real. La organización determina los nombres de las aplicaciones y su autorización; los ejemplos de productos anteriores no son recomendaciones de uso.

Alcance y activación

En Scope, limite la política a los usuarios, grupos o redes previstos; por ejemplo, mediante Specific Users and Groups, a un grupo de prueba existente. La página muestra si la política se aplica a Sophos Endpoint o a Sophos Firewall. En What will happen, las reglas, el alcance y el efecto sobre el producto deben ser coherentes antes de marcar I’ve reviewed the rules and scope above.

Save guarda la política adicional sin activarla. Esto permite comprobar primero su posición en la lista. En cambio, Save & Enable la activa inmediatamente con la máxima prioridad. Por ello, para una prueba piloto preparada se recomienda utilizar primero Save; antes de activarla después, vuelva a comprobar su posición y alcance. Esta diferencia de seguridad documentada entre los botones se aplica a las políticas adicionales y no debe trasladarse indiscriminadamente al paso final de la Base Policy.

Las plantillas de Browse templates > Use y Clone, en el menú de tres puntos, pueden ahorrar trabajo. Sin embargo, incluyen reglas ya rellenadas o el alcance copiado. Ambos deben adaptarse al entorno propio antes de guardar. Las políticas existentes pueden editarse mediante su entrada en la lista, el icono Edit de una regla con Save Rule y Scope > Edit.

Interpretar correctamente el uso, los riesgos y los informes

En My Products > AI Defense, varias vistas responden a preguntas diferentes. Seleccione siempre primero el periodo adecuado mediante el icono de calendario:

Dashboard: muestra la actividad total, las actividades bloqueadas, las aplicaciones y usuarios únicos, y la distribución entre Allow, Block y Warn. Incluye también las aplicaciones y usuarios más frecuentes, Shadow AI, la distribución del riesgo, el flujo de uso y su evolución temporal. La puntuación de postura de seguridad, de hasta 100, tiene en cuenta la cobertura de los sensores, la madurez de las políticas y el riesgo de uso. Un valor alto no garantiza una protección completa.
AI Defense Activity: muestra la aplicación, Actor como dispositivo, riesgo, sensor, hora, acción y política que la desencadenó. Unknown significa que no se registró un veredicto, no que la actividad estuviera permitida con seguridad. Los niveles de riesgo van de Low, Medium y High a Critical. Los widgets permiten filtrar, por ejemplo, las actividades permitidas; Export genera un CSV.
Inventory > Apps o Users: permite comprobar las aplicaciones y los usuarios realmente observados. Unsanctioned Use indica que falta una autorización expresa; Trains on Data, la información registrada sobre el uso de datos para entrenamiento por parte del proveedor. La clasificación de riesgo de la aplicación tiene en cuenta, entre otros aspectos, evidencias de cumplimiento y prácticas de entrenamiento. En el uso de aplicaciones, una actividad agrupa el uso de una aplicación por un dispositivo en ventanas de 10 minutos. Por tanto, el número de actividades no equivale al de prompts individuales. Ambas listas de inventario pueden exportarse como CSV.
Detections: muestra, por ejemplo, una aplicación detectada por primera vez, un uso de alto riesgo o el uso de una aplicación no autorizada. Threat score va de 0 a 10 y Severity, de Info a Critical. Los filtros permiten acotar por Severity, Threat Score o título. La vista de detalles ofrece una descripción, el usuario o host afectado, la acción recomendada y los datos subyacentes en JSON. Puede exportarse como CSV con formato, CSV o JSON.

Los detalles de la aplicación permiten examinar su función, el resumen de riesgos, las reglas de entrenamiento, el cumplimiento y el uso de datos; los detalles de actividad también indican Data Residency. Esta información ayuda a decidir, pero no confirma que el plan o la cuenta concretos de la organización, o un acuerdo individual de tratamiento de datos, tengan condiciones idénticas.

Tras investigar una detección, documente en la ventana de detalles un estado justificado: True positive benign, True positive malicious, False positive o Not actionable. Un uso detectado correctamente puede ser inocuo; no debe clasificarse como un ataque exitoso solo porque exista una detección.

Para obtener un informe, abra AI Defense > Reports > AI Risk Assessment Report > Generate, seleccione Report period y, si procede, Download PDF. El informe reúne los riesgos de las aplicaciones, la exposición a Shadow AI y la comparación de la reducción del riesgo entre periodos. Las listas de los cinco primeros son selecciones, no un inventario completo. Es un informe propio de AI Defense y no implica la entrega automática de informes de MDR. Las exportaciones pueden contener datos de usuarios y dispositivos y deben guardarse en una ubicación de acceso restringido con un plazo de conservación acordado.

Validar una prueba piloto y acotar los errores

La comprobación siguiente es un procedimiento de aceptación propuesto, no una prueba de tenant o laboratorio realizada por Avanet. Acuerde previamente la ventana de prueba, el dispositivo, el usuario, los servicios permitidos y las acciones esperadas. Utilice únicamente datos de prueba sintéticos autorizados, por ejemplo, Solo una prueba funcional sin datos de la empresa. No envíe a un servicio de IA datos de clientes, credenciales, documentos internos ni código fuente real. Una prueba de acceso no requiere introducir contenido confidencial.

Empiece con una aplicación expresamente permitida y después compruebe la regla de bloqueo o advertencia prevista para la prueba piloto. Anote en cada intento el servicio, dispositivo, hora y respuesta real que experimenta el usuario. Con Warn debe ser posible continuar; con Block, la vía de acceso probada no debe poder utilizarse.
En AI Defense Activity, coteje para el mismo periodo la aplicación, Actor, sensor, Action y Policy. El bloqueo visible y su entrada correspondiente deben coincidir con la prueba prevista. Una página de bloqueo por sí sola también podría proceder de una regla previa de Web Control o Application Control.
En Inventory, compruebe que aparecen la aplicación y el estado de autorización esperado. Debido a la agrupación de 10 minutos, no compare las cifras de uso con entradas individuales. Utilice el mismo periodo en el informe. No hay una latencia fija de visualización documentada; no intente ocultar la falta de entradas repitiendo pruebas indefinidamente.
Haga una comprobación con un usuario que no pertenezca al grupo piloto o con un dispositivo ajeno a la prueba. Sus flujos de trabajo autorizados deben permanecer sin cambios. Amplíe el alcance gradualmente solo después de documentar la aceptación.

La aplicación no aparece: compruebe primero el periodo, la vía de acceso realmente cubierta y el sensor. Después revise la carga de datos y, en Endpoint, los ajustes documentados de Threat Protection, Web Control y Application Control. Si se recopilan datos de Firewall, revise también el registro de las políticas web. Un dashboard vacío no demuestra que no se utilice IA.

La aplicación aparece, pero no se aplica la acción deseada: compare el estado de activación, el orden de las políticas y reglas, el alcance y el producto mostrado en What will happen. Para la aplicación de controles en Firewall, compruebe también la gestión de grupos. No intente corregirlo con un bloqueo amplio para toda la organización ni desactivando protecciones existentes.

Una aplicación de trabajo deja de funcionar después de un cambio: compare el último cambio con los valores documentados previamente y revierta la prueba piloto. No cree excepciones TLS indiscriminadas ni reglas Allow globales para ocultar el problema.

Si una discrepancia sigue sin aclararse, recopile eventos depurados, el periodo con zona horaria, sensor, dispositivo, acción esperada, respuesta real, orden de las políticas y alcance. Con estos datos puede abrirse un caso de Sophos Support sin compartir prompts confidenciales.

Reversión y límites de la protección

Antes de la prueba piloto, registre las reglas previas, su orden, el alcance y las políticas de sensores modificadas. Para revertir, devuelva una regla piloto problemática a su estado anterior mediante la edición documentada de políticas o restablezca el alcance piloto al autorizado previamente. Después vuelva a comprobar el flujo de trabajo antes permitido y la vista de actividad. Si se ha modificado la Base Policy, restaure de forma específica su valor predeterminado y sus excepciones de aplicaciones a partir del registro previo. Restart onboarding no la restablece.

Los cambios en los sensores solo pueden revertirse a los valores concretos anteriores si se realizaron exclusivamente para la prueba y no dependen de ellos otras tareas de protección o investigación. En particular, no desactive indiscriminadamente las cargas al Data Lake, el descifrado TLS o Application Control. La reversión de políticas no elimina automáticamente la telemetría ya recopilada ni los informes exportados. Su tratamiento se rige por el proceso de privacidad y conservación acordado.

Hay tres límites importantes para la planificación:

Visibilidad no equivale a control sin lagunas. Un endpoint privado no cubierto, otra vía de acceso o un requisito del sensor que falta no pueden protegerse únicamente mediante una política central. Detectar una aplicación tampoco demuestra que se controlen todas las acciones autónomas de un agente.
El control de acceso a aplicaciones no es una DLP de prompts garantizada. La comunicación de prensa sobre la disponibilidad general presenta la inspección en tiempo real de prompts y cargas como una función actual. La información posterior para partners sitúa expresamente la inspección y protección de prompts en versiones futuras. Mientras no se confirme de forma fiable el alcance concreto, no debe contarse con ese efecto protector y, en particular, no debe probarse con datos confidenciales reales.
La hoja de ruta no es un compromiso de compra. La distinción entre cuentas de IA personales y empresariales y las protecciones adicionales para agentes también figuran en la hoja de ruta, sin fecha vinculante. Quien necesite precisamente esas funciones debe confirmar su disponibilidad para su propio tenant antes de decidir y aceptarlas por separado.

Por tanto, un comienzo sólido no consiste en afirmar «la IA ya está protegida», sino en disponer de un inventario verificable, servicios autorizados de forma consciente, políticas limitadas y una comprobación repetible de su efecto real.