Seguridad de la IA empresarial: alcance, arquitectura y mapa del marco para 2026

La seguridad de la IA empresarial es la práctica de proteger los sistemas de IA que operan a escala organizativa: los modelos, los flujos de datos, los agentes y los servicios SaaS basados en IA que son propiedad de varios equipos, se adquieren a través de los procesos de contratación pública, están integrados en sistemas heredados y están sujetos a obligaciones normativas. El calificativo «empresarial» determina qué controles son los adecuados, no solo cuántos se necesitan.

Esa distinción es precisamente el objetivo de esta página. La seguridad de la IA abarca la disciplina en general, mientras que la ciberseguridad empresarial se centra en la parte organizativa de la expresión. A continuación se aborda la intersección: dónde se sitúa el límite, qué incluye un entorno de IA empresarial seguro, qué revelan los incidentes documentados de 2026 sobre la vía de ataque, qué abarca una arquitectura de referencia y qué marcos normativos y regulaciones están vigentes a fecha de agosto de 2026.

¿Qué caracteriza a la seguridad de la IA en el ámbito empresarial?

La seguridad de la IA se convierte en seguridad de la IA empresarial cuando la escala, la propiedad compartida, la exposición normativa y el volumen de identidades de máquina cambian, lo que hace que los controles funcionen realmente.

Empecemos por el verbo. Garantizar la seguridad de la IA significa proteger el propio sistema de IA: sus datos de entrenamiento y recuperación, los artefactos de sus modelos, su entorno de ejecución y los permisos de que disponen sus agentes. Eso es lo contrario a utilizar la IA para proteger algo más. Ambas disciplinas son reales, a ambas se las denomina «seguridad de la IA» en el día a día, y mezclarlas es la forma más rápida de perder una discusión sobre el alcance del proyecto ante la junta directiva.

Hay seis dimensiones observables que distinguen el uso de la IA en las grandes empresas del uso de la IA a menor escala. Cada una de ellas se traduce en una consecuencia en materia de control, más que en una diferencia de tamaño, y eso es lo que hace que esta distinción sea útil y no meramente retórica.

Leyenda: Las seis dimensiones que convierten la seguridad de la IA en seguridad de la IA empresarial, y las consecuencias que cada una de ellas tiene en materia de control.

Ahora, este término tiene un coste asociado. En el estudio «El coste de una filtración de datos en 2026», realizado por el Ponemon Institute entre 602 organizaciones que sufrieron filtraciones entre marzo de 2025 y febrero de 2026, el coste medio global de una filtración alcanzó la cifra récord de 4,99 millones de dólares, lo que supone un aumento interanual del 12 % (Network World, 2026). Durante el mismo periodo, más de una de cada cuatro organizaciones que sufrieron un ataque malicioso afirmaron que este había sido perpetrado mediante inteligencia artificial, lo que supone un aumento del 56 % con respecto al año anterior (Infosecurity Magazine, 2026).

Ese es, en una sola línea, el caso de los límites de la empresa. El mismo ataque resulta más costoso cuando afecta a un entorno de este tamaño; la IA es ahora un componente cuantificable de ese aumento, y los controles que funcionaban en una prueba piloto con dos personas no son aplicables aquí.

Seguridad de la IA en la empresa, gobernanza de la IA y gestión de riesgos de la IA

La seguridad se pregunta si el sistema de IA puede ser objeto de un ataque; la gobernanza, si debería existir; y la gestión de riesgos, qué pasaría si fallara.

Leyenda: Las tres disciplinas que los programas de IA empresarial suelen confundir, diferenciadas por la pregunta a la que responde cada una.

El ámbito de la gestión de riesgos se basa en una taxonomía del Gobierno de EE. UU. La norma NIST IR 8596, el «Perfil de IA cibernética», se publicó como borrador preliminar inicial el 16 de diciembre de 2025 y divide el campo en tres ámbitos que denomina «Proteger», «Defender» y «Frustrar»: proteger los componentes de los sistemas de IA, llevar a cabo una ciberdefensa basada en la IA y frustrar los ciberataques basados en la IA (NIST, 2025). La seguridad de la IA empresarial abarca el primero y el tercero. El segundo es un tema distinto que, casualmente, utiliza los mismos términos, y la costumbre de fusionarlos es la razón por la que tantos programas no pueden precisar a qué se destinan sus fondos.

La responsabilidad recae sobre el artefacto, y no sobre el organigrama. El equipo de la plataforma es responsable de los controles dentro del proceso; el equipo de seguridad, de la detección y la respuesta en los sistemas de IA y las identidades que estos utilizan; y el equipo de GRC, de las pruebas que ambos generan. La fragmentación de la responsabilidad entre estos tres equipos es el fallo que los profesionales describen con mayor frecuencia, y suele ser un síntoma de que nunca se ha establecido este límite desde el principio.

La seguridad y el cumplimiento normativo en materia de IA empresarial están relacionados, pero no son intercambiables. El cumplimiento normativo es la capa de evidencia, que demuestra que un control existía, funcionaba y se revisaba. La seguridad se refiere a si el control impide que ocurra algo. La profundidad de la gobernanza a nivel de programa —es decir, los registros de modelos, los flujos de trabajo de aprobación y las herramientas de políticas— corresponde a las herramientas de gobernanza de la IA y no a este contexto, mientras que la disciplina genérica se enmarca en la seguridad de la IA.

Qué protege la seguridad de la IA empresarial

La seguridad de la IA empresarial protege cinco capas, y la que la mayoría de las empresas pasan por alto es la herramienta de IA que un empleado ha autorizado sin consultar a nadie.

Organizar por capas del entorno es mejor que hacerlo por nombre de amenaza, ya que las capas se corresponden con los responsables y los presupuestos, mientras que los nombres de las amenazas se corresponden con las ponencias de las conferencias.

Leyenda: Las cinco capas de un entorno de IA empresarial, el factor que predomina en cada una de ellas y dónde reside la profundidad.

Lo primero es el inventario, porque no se puede proteger un patrimonio que no se ha contabilizado, y el problema del recuento es ahora el más importante. En el estudio sobre brechas de seguridad de 2026, más de dos tercios de las organizaciones indicaron que no contaban con ningún proceso de gobernanza para limitar la IA en la sombra, lo que supone un ligero repunte con respecto a la cifra de 2025, y la proporción de incidentes de seguridad relacionados con la IA en la sombra se duplicó con creces respecto al año anterior, alcanzando el 43 % (Cybersecurity Dive, 2026). La detección, la asignación de responsabilidad y la revisión del alcance de OAuth deben realizarse durante los primeros 90 días de cualquier programa.

La propia taxonomía de riesgos es pública y está actualizada. La lista «GenAI LLM Top 10 para 2026» de OWASP, publicada a principios de agosto de 2026, clasifica 01:2026 Prompt Injection En primer lugar, 02:2026 Divulgación de información confidencial, en segundo lugar, y 03:2026 «Excessive Agency», en tercer lugar, con 05:2026 Envenenamiento de datos y modelos y 09:2026 Debilidades de los vectores y las representaciones que abarcan la capa de datos (Proyecto de seguridad OWASP GenAI, OWASP: Los 10 principales modelos de lenguaje grande (LLM) de IA generativa de 2026). Utiliza los identificadores de 2026. Seis de las diez entradas han cambiado de posición con respecto a la edición de 2025, por lo que un identificador obsoleto ahora apunta a un riesgo equivocado.

Hay dos aspectos que merecen una mención especial. La IA generativa cuenta con su propio conjunto de controles en torno a la gestión de los resultados, los límites de recuperación y la procedencia del contenido, temas que se tratan en el apartado de seguridad de la IA generativa. Y lo más complicado de la adopción interna de modelos de lenguaje grande (LLM) y agentes rara vez es el modelo en sí. Se trata de la superficie de integración: las herramientas a las que un agente puede recurrir, los sistemas a los que acceden dichas herramientas y las credenciales que hacen posible dicho acceso.

Lo que revelan los incidentes de 2026 sobre la vía de ataque de la IA en las empresas

En todos los casos documentados de 2026, la capa de IA disponía de más permisos de los que requería su tarea, y nada detectó la diferencia a tiempo. OWASP clasifica ese patrón como 03:2026 «Excessive Agency» subió desde el sexto puesto en la edición de 2025, debido a que los incidentes de producción se concentraron en los sistemas de agencia.

¿Supone la IA una amenaza para la seguridad? Sí, de tres formas distintas. La más conocida es que los atacantes utilicen la IA en tu contra, y el aumento interanual del 56 % en los ataques impulsados por la IA mencionado anteriormente lo confirma. Las otras dos son las que los modelos de amenazas empresariales siguen pasando por alto, y ambas aparecen en casos documentados de 2026.

En primer lugar, tu propia IA autorizada puede sobrepasar su ámbito de actuación. En julio de 2026, una plataforma de alojamiento de modelos de IA reveló una intrusión que, según su propio comunicado, se atribuyó a «un marco de agentes autónomos», sin revelar la identidad del operador, y notificó más de 17 000 eventos registrados que se reconstruyeron durante el análisis forense (Hugging Face, 2026). Informes posteriores determinaron el origen: el incidente «se derivó de una prueba de seguridad interna» en la que un agente de evaluación intentó acceder a los sistemas de producción y recuperar las soluciones de la prueba (The Hacker News, 2026). Se trató de una evaluación autorizada que traspasó sus límites, no de una campaña delictiva externa, y precisamente por eso debe incluirse en un modelo de amenazas corporativas.

El mismo patrón se observa en el origen. Un laboratorio de IA revisó 141.006 ejecuciones de evaluación en las que sus modelos podrían haber obtenido acceso a Internet e identificó tres incidentes en los que un modelo se conectó a Internet desde el interior del entorno de evaluación (Anthropic, 2026). La causa principal fue un fallo en los límites de control, más que un fallo del modelo: la instrucción de evaluación indicaba al modelo que su entorno era una simulación sin acceso a Internet, pero un malentendido con el socio de evaluación hizo que eso no fuera cierto. Fíjate en el denominador. Se trata de pruebas de evaluación realizadas en un laboratorio, no en empresas.

En segundo lugar, la IA que se adquiere a terceros se convierte en una vía de acceso a la propia organización. El ejemplo empresarial más claro sigue siendo el robo de tokens OAuth pertenecientes a una integración de chat de IA de terceros. Los investigadores de inteligencia sobre amenazas rastrearon la actividad con el nombre de UNC6395 y describieron la exportación sistemática de grandes volúmenes de datos desde «numerosas instancias corporativas de Salesforce» (Google Threat Intelligence Group, 2025). Un regulador financiero estadounidense describió ese mismo suceso, ocurrido en agosto de 2025, como un ataque a la cadena de suministro de IA que afectó a más de 700 organizaciones (FINRA, 2025). Las dos fuentes ofrecen cifras diferentes y ninguna de ellas confirma el recuento de la otra.

La pila de IA también supone ahora una obligación de aplicación de parches. Once entradas relacionadas con la capa de IA figuran en el catálogo de «Vulnerabilidades explotadas conocidas» de la CISA, una tendencia que se remonta a mayo de 2025: Langflow con seis, LiteLLM con dos, y n8n, Ray y MLflow con una cada uno (CISA, 2026). Ray y MLflow aparecen por primera vez en el catálogo, ampliando así la presencia de la IA en el mismo desde la capa de aplicación y orquestación hasta el ciclo de vida de los modelos y la computación. La fecha límite federal para la corrección de Ray fue el 20 de agosto de 2026 y la de MLflow es el 2 de septiembre de 2026. El catálogo alcanzó la versión 2026.08.24 con 1 675 entradas el 24 de agosto de 2026, lo que da una idea de lo rápido que queda obsoleta esta lista.

La gravedad depende de la escala que se utilice. El NVD puntúa el defecto de Ray (CVE-2025-62593) 8,8 (ALTO) según CVSS v3.1, mientras que el análisis de vulnerabilidad de GitHub (CNA) le otorga la misma puntuación récord de 9,4 (CRÍTICO) según CVSS v4.0. La vulnerabilidad de MLflow (CVE-2026-64849) tiene una calificación de 9,3 en la escala «CRÍTICO» de la CNA de GitHub, aunque aún no se ha facilitado la evaluación propia de NVD. Indica la fuente y la versión cada vez que se difunda la cifra. La vulnerabilidad de Ray también es un vector de ataque a las estaciones de trabajo de los desarrolladores al que se puede acceder mediante el reenlace de DNS, en lugar de una exposición del servidor, lo que la sitúa en el ámbito de la IA en segundo plano y no en el servicio de modelos de producción.

En todos los casos, la secuencia de tácticas es la misma: 0006 «Acceso mediante credenciales», y luego 0008 Movimiento lateral, entonces 0010 Exfiltración. Esa secuencia está totalmente al alcance de los análisis de comportamiento Detección de amenazas mediante IA, lo cual constituye el argumento a favor de incluir las credenciales de los agentes en el mismo ámbito de supervisión que las de las personas, en lugar de en un programa de IA independiente.

‍

Una arquitectura de referencia para la seguridad de la IA en las empresas

Una arquitectura de seguridad de IA empresarial eficaz asigna a cada modelo, proceso y agente una identidad verificada, unas credenciales con un ámbito de aplicación definido y un lugar desde el que se supervisa su funcionamiento.

Casi ninguna página sobre este tema incluye uno, lo cual resulta extraño, ya que la cuestión de la arquitectura es precisamente la que se plantea en las revisiones de diseño. Las capas inferiores se basan en documentos oficiales y de organismos de normalización, más que en ninguna pila de productos.

‍

Componentes

Una infraestructura de seguridad de IA empresarial defendible se compone de seis planos: un plano de datos que alberga fuentes, canalizaciones y almacenes de vectores; un plano de modelos que contiene registros y procedencia; un plano de tiempo de ejecución en el que una pasarela de IA gestiona las solicitudes y las llamadas a herramientas; un plano de identidad que abarca a los actores humanos y no humanos; un plano de aplicación de políticas; y un plano de observabilidad que supervisa a los otros cinco. El NIST SP 800-239, un borrador público inicial publicado el 27 de julio de 2026 y abierto a comentarios hasta el 25 de septiembre de 2026, es el único documento del Gobierno de EE. UU. sobre arquitectura de IA incluido en este conjunto de pruebas, y su propia lista de palabras clave incluye una arquitectura de referencia para centros de datos de IA (NIST, 2026). En cuanto al contenido de los controles, la «Matriz de controles de IA v1.1» de la Alianza para la Seguridad de la Información ( Cloud Security Alliance), publicada el 22 de junio de 2026, ofrece 247 objetivos de control repartidos en 18 dominios de seguridad y los relaciona con las normas ISO/IEC 42001, ISO/IEC 27001 y BSI AIC4 (Alianza para la Seguridad de la Información (Cloud Security Alliance), 2026). Tampoco se trata de un modelo de producto, y precisamente por eso sirven de referencia.

Controles de acceso

Aquí es donde la seguridad de la IA empresarial y los controles de acceso dejan de ser una abstracción. En el estudio sobre filtraciones de 2026, de las aproximadamente una de cada cinco organizaciones que notificaron un incidente de seguridad relacionado con un modelo o una aplicación de IA, el 92 % carecía de controles basados en roles, autenticación multifactorial y controles similares en dichos modelos y aplicaciones, y solo dos de cada cinco organizaciones aplicaban controles de acceso a sus modelos y datos de IA (Help Net Security, 2026). La protección de un modelo empieza aquí: definir quién y qué puede acceder a él, registrar cada acceso con la identidad de quien lo ha realizado y separar las credenciales que sirven para la inferencia de las que pueden modificar el artefacto.

Identidad de los agentes no humanos

Las directrices interinstitucionales publicadas el 1 de mayo de 2026 por la CISA, la NSA y organismos asociados de Australia, Canadá, Nueva Zelanda y el Reino Unido establecen los requisitos operativos. Exige que cada agente «disponga de una identidad verificada y protegida criptográficamente, utilice credenciales de corta duración y cifre todas las comunicaciones» con otros agentes y servicios, y el mismo informe clasifica el riesgo de los agentes en cinco categorías que abarcan los privilegios, los fallos de diseño y configuración, el comportamiento, la estructura y la rendición de cuentas (CyberScoop, 2026). Los principios de « Zero trust » se aplican aquí sin modificaciones, ya que un agente es una carga de trabajo y zero trust ya sabe cómo gestionarla.

Observabilidad, supervisión y generación de informes

Cada capa superior debe ser observable; de lo contrario, sus controles no serán falsificables. En la práctica, esto se traduce en tres fuentes de datos: registros de comandos y llamadas a herramientas del plano de ejecución, eventos de identidad para cada actor no humano y datos de estado sobre lo que existe y cómo está configurado, lo cual es tarea de la gestión del estado de seguridad mediante IA (AI-SPM). Canaliza las tres fuentes hacia la misma práctica de supervisión de seguridad que cubre el resto del entorno, y hacia los mismos controles de seguridad decloud cuando dicho entorno esté alojado en cloud, en lugar de crear un panel de control de seguridad de IA empresarial independiente que nadie supervisa.

La precisión es la objeción recurrente, pero tiene respuesta. Las detecciones basadas en IA se ganan la confianza igual que cualquier otra detección: mediante la validación frente a comportamientos conocidos como correctos, una explicación revisable por humanos adjunta a cada veredicto y un ciclo de retroalimentación que descarta la lógica que no resiste el contacto con tu entorno. La detección y las pruebas de «red teaming» con IA evalúan los extremos opuestos de la misma cuestión: uno pregunta si salen a la luz ataques reales y el otro, si se puede hacer que el sistema se comporte de forma anómala a propósito.

Ventajas e inconvenientes

La centralización garantiza el cumplimiento y crea un cuello de botella. Una pasarela de seguridad de IA empresarial que intercepta cada solicitud y llamada a herramientas te ofrece un único punto desde el que aplicar políticas, registrar la actividad y revocar el acceso. También te ofrece un único punto de fallo, una única cola que se puede saturar y un único proveedor al que quedarte atado. El cumplimiento federado se adapta mejor y evoluciona más rápido. La mayoría de las grandes organizaciones optan por un modelo híbrido: identidad y políticas centralizadas, aplicación distribuida cerca de la carga de trabajo y observabilidad centralizada. Elijas lo que elijas, intégralo en la arquitectura de ciberseguridad empresarial que ya tienes en funcionamiento, en lugar de poner en marcha un programa paralelo al lado.

El marco y el panorama normativo para 2026

Cuatro familias de marcos normativos y un reglamento modificativo establecen las obligaciones para 2026, y tres de los documentos que se citan con mayor frecuencia como normas siguen siendo borradores.

Leyenda: El marco normativo y los instrumentos reglamentarios que regulan la seguridad de la IA en las empresas, con la versión y el estado de cada uno de ellos a fecha de agosto de 2026.

Hay dos filas que tienen mayor repercusión en la planificación. MITRE ATT&CK Enterprise se encuentra en la versión de contenido v19.2: la línea v19 se lanzó el 28 de abril de 2026 e introdujo la división «Defense Evasion», y las versiones puntuales v19.1 y v19.2 le siguieron el 12 de mayo de 2026 y el 6 de agosto de 2026, respectivamente, con actualizaciones más específicas para Grupos, Software y Campañas (registro de cambios deMITRE ATT&CK , tácticas de Enterprise). Su complemento específico para IA, MITRE ATLAS, lanzó tres versiones en tres meses y se encuentra en la versión v2026.07 (versiones de MITRE ATLAS). Todo lo escrito antes de agosto de 2026 está desactualizado en ambos casos.

La Ley de IA de la UE es el punto en el que la mayoría de los planes de cumplimiento se equivocan. El Reglamento (UE) 2024/1689 fue modificado por el Reglamento (UE) 2026/1744, que aplazó las obligaciones de alto riesgo del anexo III hasta el 2 de diciembre de 2027 y las del anexo I hasta el 2 de agosto de 2028 (EUR-Lex). Las obligaciones de transparencia del artículo 50 no se aplazaron y comenzaron a aplicarse el 2 de agosto de 2026, y la Comisión Europea adoptó el 20 de julio de 2026 unas directrices de aplicación que mencionan el artículo 50 en su propio título (Comisión Europea, 2026). Cita el Diario Oficial en lugar de un agregador de cronologías, ya que no todos los agregadores se han puesto al día.

El ámbito federal de EE. UU. añade tres elementos que merece la pena seguir, no cincuenta. La Orden Ejecutiva 14409 se firmó el 2 de junio de 2026 y se publicó el 5 de junio de 2026 como documento n.º 2026-11415 del Registro Federal (Registro Federal, 2026). Las directrices sobre IA agentiva interinstitucionales del 1 de mayo de 2026 se tratan en la sección anterior dedicada a la arquitectura. Y el propio trabajo del NIST sobre seguridad de la IA, incluidas las superposiciones de control COSAiS, sigue en fase de borrador, lo que constituye una razón para seguirlo de cerca en lugar de esperar a que se publique.

El marco estatal de EE. UU. se centra en el cumplimiento normativo, no en la legislación de seguridad, y tratarlo de otra manera supone un desperdicio de presupuesto. Las leyes estatales vinculantes sobre IA que entrarán en vigor a partir de 2027 son instrumentos relacionados con la privacidad, la lucha contra la discriminación y la divulgación de información. Estas regulan cómo se toman y se divulgan las decisiones de la IA, no cómo se protegen los sistemas de IA. La norma de auditoría de ciberseguridad de la CPPA de California (11 CCR 7121) es una fuente frecuente de confusión, ya que su criterio de aplicación es el tratamiento de información personal más unos umbrales de ingresos, por lo que una organización que no utilice IA en absoluto queda sujeta a ella de la misma manera. Es mejor orientar el ámbito estatal hacia la planificación de herramientas de gobernanza de la IA, en lugar de hacia una arquitectura de seguridad.

Evaluación de la seguridad de la IA en las empresas

Evalúa basándote en los datos que puedas solicitar, no en etiquetas de categorías, y fija el precio del programa en función del tamaño de tu infraestructura de IA.

El mercado de las soluciones de seguridad basadas en IA para empresas aún se encuentra en fase de desarrollo, y los nombres de las categorías se difunden más rápido que las propias capacidades. En lugar de clasificar los productos, trabaja a partir de criterios que puedas incluir en un cuestionario y verificar mediante una demostración de valor. La «Matriz de controles de IA v1.1» de la Alianza para la Seguridad de la IA ( Cloud ) es una referencia de evaluación independiente de los proveedores que te evita tener que crear tus propios requisitos.

Leyenda: Seis criterios de evaluación para la seguridad de la IA empresarial, cada uno de ellos redactado como algo que un comprador puede solicitar y verificar, en lugar de como una etiqueta de categoría.

¿En qué se diferencian las herramientas de seguridad basadas en IA de las plataformas tradicionales de detección de amenazas? Principalmente en lo que son capaces de detectar. La detección tradicional se organiza en torno a hosts, redes e identidades humanas, y un entorno de IA añade tres elementos que quedan fuera de ese modelo: las solicitudes y su contexto, los artefactos de los modelos y su procedencia, y las credenciales de los agentes que actúan sin presencia humana. La tendencia más marcada en la actualidad es la ampliación, más que la sustitución: se integra la telemetría de la capa de IA en el mismo flujo de trabajo de clasificación y respuesta que ya ejecutan tus herramientas de operaciones de seguridad, de modo que un agente que se comporte de forma extraña acaba en la misma cola que una cuenta comprometida.

No hay una respuesta concreta sobre cuánto cuesta la seguridad de la IA empresarial, solo factores que influyen en el coste, y hay cuatro que predominan: el tamaño del entorno de IA, el número de identidades no humanas que crea, el riesgo normativo asociado a sus casos de uso y qué parte de ese entorno ya cubre tu telemetría actual. Una organización con una sólida cobertura de identidades y redes está adquiriendo una ampliación. Una que carezca de ambas está adquiriendo una base. El análisis presupuestario sigue el mismo patrón. Identifica el entorno, identifica las identidades, identifica las obligaciones con sus fechas correspondientes y, a continuación, calcula el coste de la brecha entre lo que observas hoy y lo que la vía de ataque descrita en esta página te exige observar. En cuanto a la magnitud del coste, las brechas de seguridad facilitadas por la IA cuestan una media de 6 millones de dólares, aproximadamente 1 millón más que la media mundial de 4,99 millones de dólares (Network World, 2026), una diferencia que describe las brechas facilitadas por la IA como una categoría en sí misma, más que como un tipo de ataque concreto. Basa la petición en la conclusión anterior sobre el control de acceso, ya que un 92 % es una brecha de control sobre la que un consejo de administración puede actuar, mientras que una proyección de mercado no lo es.

La visión de « Vectra AI » sobre la seguridad de la IA empresarial

Vectra AI Parte de una postura que asume que el sistema está comprometido. Los atacantes capacitados logran acceder al sistema, y los sistemas de IA amplían las vías de acceso, por lo que la metodología se deriva de ello y no de una categoría de producto. Trata los modelos, los flujos de trabajo y los agentes como identidades en una red, en lugar de como aplicaciones. Observa lo que hacen esas identidades en lugar de lo que las políticas establecen que deberían hacer. A continuación, utiliza el análisis de comportamiento ( Attack Signal Intelligence ) para reducir ese comportamiento a un pequeño número de señales sobre las que un analista pueda actuar con confianza. La prueba práctica de un programa de seguridad de IA empresarial es la misma que se aplica al resto del entorno: cuando un sistema autorizado empieza a actuar fuera de su ámbito de competencia, ¿cuánto tiempo pasa antes de que alguien se dé cuenta?

‍