Evaluación de la seguridad de la IA empresarial: preguntas que todo comprador debería poder responder

La seguridad de la IA empresarial avanza rápidamente, y la mayoría de las organizaciones aún tienen dificultades para evaluar con rigor las afirmaciones de los proveedores. Este informe de investigación de NSS Labs, elaborado en colaboración con F5, AWS y Microsoft, proporciona a los responsables de seguridad y a los compradores empresariales las preguntas concretas que deben plantear a los proveedores, las señales de alerta a las que deben prestar atención y los criterios de evaluación necesarios para tomar decisiones fundamentadas y defendibles sobre la seguridad de la IA.

Resumen ejecutivo

La seguridad de la IA empresarial tiene un problema para los compradores. Las organizaciones saben que la seguridad de la IA es importante, pero la mayoría carece de un marco fiable para evaluar las afirmaciones de los proveedores, distinguir los controles eficaces de los superficiales o exigir a los proveedores que respalden sus afirmaciones con pruebas obtenidas en situaciones reales.

Este informe —el segundo de una serie de dos partes de NSS Labs, elaborado en colaboración con F5, AWS y Microsoft— pasa de definir el problema a proporcionar a los compradores las herramientas necesarias para abordarlo. Mientras que la primera parte explicó por qué no basta con proteger únicamente el modelo de IA, la segunda convierte esa base en criterios prácticos de evaluación para siete áreas de capacidades críticas.

El argumento central: las decisiones de compra en materia de seguridad de la IA son decisiones de gobernanza, no meramente técnicas. Los compradores deben exigir pruebas cuantificables, no diagramas de arquitectura. Esto implica establecer valores de referencia cuantitativos para la eficacia de la detección, el rendimiento operativo, los requisitos de auditoría y la adecuación a los marcos normativos, todo ello validado en condiciones reales y no en escenarios de prueba aislados.

Las siete áreas de capacidad que analiza el documento son el control de las amenazas de entrada y de las instrucciones, el riesgo asociado a las salidas y a la exfiltración de datos, la resiliencia del sistema ante la degradación, la gobernanza de políticas y filtros, la IA agéntica y la autoridad delegada, la observabilidad y el análisis forense, y la integración y la interoperabilidad. Cada sección relaciona el riesgo principal con preguntas específicas que los compradores deben plantear a los proveedores, las características de las soluciones eficaces y señales de alarma concretas a las que prestar atención.

El documento concluye con dos mandatos contundentes: exija una validación independiente antes de comprar y considere dicha validación una práctica continua, no un control puntual. Los proveedores que se resisten a someterse a pruebas rigurosas demuestran inmadurez, no solidez.

La idea fundamental se resume en tres frases de la conclusión que conviene tomarse en serio: la adquisición de soluciones de seguridad para la IA es una decisión de gobernanza con consecuencias a largo plazo. Las empresas que plantean las preguntas difíciles desde el principio están mejor preparadas para gestionar los riesgos y evitar fallos prevenibles. Y la seguridad de la IA no prosperará gracias a la novedad ni a la abstracción, sino únicamente mediante la rendición de cuentas, la transparencia y una evaluación rigurosa.

Índice

Introducción: Del conocimiento a la evaluación

Establecimiento de criterios de evaluación cuantitativos

Áreas de capacidades críticas y preguntas que los compradores deberían plantear

• Detección de amenazas en las entradas, control de instrucciones y evasión
• Gestión de riesgos de salida y exfiltración de datos
• Gestión de la resiliencia, la robustez, los fallos y la degradación
• Eficacia de las políticas y los filtros y alineación con la gobernanza
• IA agéntica, seguridad en la invocación de herramientas y autoridad delegada
• Observabilidad, auditoría y análisis forense
• Integración e interoperabilidad

Qué deben exigir los compradores antes de comprar

Preparación para una validación independiente

Conclusión: de las afirmaciones a la rendición de cuentas

DESCARGAR LA PARTE 1: Seguridad de la IA más allá del modelo: qué debe preocupar a las empresas y por qué

Introducción: del conocimiento a la evaluación

A medida que la IA se integra cada vez más en los sistemas empresariales de distintas formas, abre nuevas superficies de ataque que obligan a las empresas a tener en cuenta los riesgos de seguridad asociados a la IA. Los consejos de administración, los organismos reguladores y los equipos directivos están empezando a reconocer que los sistemas de IA introducen nuevas categorías de exposición operativa, jurídica y reputacional, además de ampliar la superficie de ataque. Como resultado, los productos de seguridad de la IA destinados a reducir estos riesgos se han convertido en una prioridad para los equipos de seguridad empresarial.

Sin embargo, esa concienciación no garantiza que las empresas estén preparadas y, aunque cada vez son más las que reconocen la importancia de la seguridad de la IA, muchas tienen dificultades para evaluar de forma eficaz las afirmaciones de los proveedores que operan en este mercado emergente. La terminología no es uniforme, las demostraciones suelen tener un alcance limitado y las garantías se basan con frecuencia en la arquitectura, en lugar de en pruebas obtenidas en entornos reales. Los compradores deben tomar decisiones sin una forma clara de distinguir los controles realmente eficaces de los superficiales ni de determinar hasta qué punto la cobertura es verdaderamente efectiva.

En nuestro anterior libro blanco, titulado «AI Security Beyond the Model», NSS Labs explicó por qué proteger únicamente el modelo de IA no es suficiente y por qué la seguridad de la IA empresarial debe abordarse como un reto de gobernanza y a nivel de sistema. Los verdaderos retos de seguridad surgen en los sistemas que rodean al modelo: allí donde se recuperan datos, se utilizan herramientas y se ejecutan decisiones automatizadas.

Este documento parte de esa base y pasa de comprender el problema a evaluar posibles soluciones y ayudar a los compradores empresariales a formular mejores preguntas al preseleccionar proveedores de seguridad de IA. En consonancia con «AI Security Beyond the Model», este documento se centra principalmente en las salvaguardas en tiempo de ejecución (los controles externos al modelo que aplican las políticas, protegen los datos y generan evidencias de auditoría), al tiempo que reconoce que la seguridad del modelo y la IA responsable reducen el riesgo intrínseco del modelo, pero no pueden gestionar por sí solas el riesgo derivado de las interacciones empresariales. A medida que los sistemas de IA se integran en los flujos de trabajo empresariales, las decisiones de seguridad convergen cada vez más con la gobernanza, la gestión de riesgos y la responsabilidad regulatoria. Las organizaciones deben ser capaces de explicar no solo cómo funcionan los sistemas de IA, sino también cómo se controlan, supervisan y auditan los riesgos.

Las secciones siguientes tratan de reformular las principales áreas de capacidad de la seguridad de la IA como criterios de evaluación. En lugar de prescribir tecnologías o arquitecturas específicas, se centran en lo que los compradores deberían poder comprender, probar y justificar al seleccionar controles de seguridad de la IA para entornos de producción.

Establecimiento de criterios de evaluación cuantitativos

Evaluar la seguridad de la IA exige ir más allá de las afirmaciones cualitativas y recurrir a una validación cuantificable. Los compradores deben establecer unas expectativas de referencia que permitan comparar objetivamente a los proveedores.

Eficacia de la detección: Los proveedores deben demostrar sus capacidades de detección mediante marcos y metodologías de prueba estandarizados de organizaciones independientes reconocidas. Las organizaciones deben exigir tasas de precisión cuantificables frente a patrones de ataque conocidos, y los proveedores deben informar sobre la metodología de prueba, los límites de cobertura y las concesiones en cuanto a falsos positivos. La prevención de la exposición de datos sensibles debe distinguir entre tipos de datos estructurados e información sensible contextual, manteniendo una precisión de detección uniforme en distintos modelos fundacionales y niveles de complejidad de las instrucciones.

Rendimiento operativo: Los compradores deben establecer umbrales de latencia que equilibren la seguridad y la facilidad de uso. Los sistemas deben demostrar su rendimiento con cargas a escala de producción, no en condiciones de prueba aisladas. Las tasas de falsos positivos también son importantes: un exceso de falsos positivos provoca fatiga por alertas e impulsa la adopción de IA en la sombra. Los proveedores deben ser capaces de proporcionar métricas de producción correspondientes a periodos de tiempo significativos.

Requisitos de auditoría: El cumplimiento normativo depende de un registro exhaustivo y lo suficientemente detallado como para reconstruir incidentes meses después. Los eventos deben exportarse al SIEM en formatos estándar y con una latencia mínima. Los requisitos de conservación variarán según el sector y el caso de uso.

Alineación con marcos de referencia: Los proveedores deben vincular los controles con marcos consolidados de organizaciones independientes de pruebas reconocidas. Los compradores deben exigir a los proveedores que demuestren estas capacidades mediante conjuntos de pruebas estandarizados y muestras de tráfico de producción. La validación independiente por parte de terceros aporta pruebas fiables de la eficacia de los controles.

Áreas de capacidades críticas y preguntas que los compradores deberían plantearse

En el nivel más básico, las medidas de seguridad de los modelos pueden bloquear instrucciones maliciosas, filtrar contenido no permitido y aplicar reglas de uso sencillas. Estas capacidades son necesarias, pero muchos fallos de gran impacto de la IA empresarial no se deben a la falta de reglas, sino a la falta de contexto, resiliencia y visibilidad.

Por ejemplo, un sistema de IA puede cumplir todas las políticas de contenido definidas y, aun así, revelar información confidencial mediante la agregación, la inferencia o una combinación inadecuada de contextos. Del mismo modo, un sistema puede aplicar correctamente las reglas en condiciones normales, pero fallar de forma impredecible cuando está sometido a una carga elevada, se producen interrupciones parciales o fallan sus dependencias.

Detección de amenazas en las entradas, control de instrucciones y evasión

La mayoría de los controles de seguridad para la IA afirman «filtrar prompts» o «bloquear entradas maliciosas», pero este planteamiento suele simplificar demasiado el problema. En la mayoría de los sistemas de IA, el riesgo no solo procede de lo que los usuarios introducen directamente en un sistema, sino también de las instrucciones integradas en el contenido que consumen los sistemas en fases posteriores. Puede tratarse de documentos, páginas web, tickets, correos electrónicos o bases de conocimiento, cuyo contenido debe ser lo suficientemente fiable como para considerarse un contexto autorizado.

Autores

Bob Walder - Analista sénior, NSS Labs
lan Foo - Director de Tecnología y vicepresidente ejecutivo de Producto, NSS Lab

Colaboradores

Esta investigación se llevó a cabo en colaboración con líderes del sector en materia de seguridad, nube e IA.

Cameron Delano - Arquitecto sénior de soluciones, F5
Jeanette Hurr - Arquitecta global de soluciones, F5
Riggs Goodman III - Arquitecto principal de soluciones de seguridad y privacidad de IA, AWS
Raj Bagwe - Arquitecto sénior de soluciones, AWS
Zachary Riffle - Arquitecto de seguridad, Microsoft

Los compradores deben preguntar cómo distingue un sistema, durante la ejecución, entre las instrucciones del sistema, la intención del desarrollador, el contenido recuperado y la entrada del usuario. En las arquitecturas que utilizan generación aumentada por recuperación (RAG), esta distinción es fundamental. Si el contenido recuperado puede anular implícitamente las políticas del sistema, este será vulnerable a la inyección indirecta de instrucciones, aunque nunca se envíe ninguna consulta manifiestamente maliciosa.

Las empresas deben esperar respuestas claras a preguntas como las siguientes:

• ¿Hasta qué punto puede el sistema detectar, evaluar y bloquear solicitudes e instrucciones prohibidas por las políticas?
• ¿Hasta qué punto puede el sistema detectar y evitar los intentos de alterar su comportamiento previsto mediante instrucciones de entrada?
• ¿Hasta qué punto gestiona bien el sistema las instrucciones ambiguas o dudosas cuya intención no está clara, minimizando al mismo tiempo las interferencias con el uso legítimo?
• ¿Con qué eficacia puede el sistema evitar que las instrucciones integradas en el contenido enviado influyan en el modelo de formas no deseadas?
• ¿Con qué eficacia puede el sistema hacer frente a los intentos de eludir los controles mediante formatos inusuales, codificaciones o transformaciones del prompt?
• ¿Hasta qué punto logra el sistema equilibrar la seguridad con casos de uso legítimos basados en roles (por ejemplo, simulaciones de formación, ejercicios de red teaming o trabajos creativos) sin crear vías fáciles para eludir los controles?
• ¿Con qué eficacia impide el sistema que los usuarios (o el contenido externo) influyan en las instrucciones del sistema o del agente, las reglas de enrutamiento, las restricciones de uso de herramientas u otros controles de «mayor prioridad», o que los anulen?
• ¿Es capaz el sistema de detectar, identificar y regular eficazmente el uso del modelo para evitar un uso abusivo o excesivo (más allá de lo permitido por la política), así como los costes asociados?
• ¿Puede el sistema mostrar en los registros qué fuente de instrucciones prevaleció cuando se produjeron conflictos (sistema frente a desarrollador, recuperación o usuario)?

En la práctica, los fallos en este ámbito suelen producirse sin que haya ninguna instrucción manifiestamente maliciosa y, en cambio, surgen por la forma en que se introduce contenido no fiable en el contexto de la IA. Un atacante puede insertar instrucciones ocultas en un documento (por ejemplo, un documento de políticas, una página de una wiki interna o un artículo de atención al cliente) que posteriormente el sistema de IA incorpora mediante un complejo proceso de recuperación a partir de múltiples fuentes. Cuando el modelo recupera ese contenido, puede interpretar las instrucciones insertadas como directrices autorizadas en lugar de como información no fiable. En entornos empresariales donde el contenido interno puede editarse ampliamente, esta forma de inyección indirecta de instrucciones puede resultar especialmente difícil de detectar.

Por ejemplo, no es necesario —ni, desde el punto de vista de un actor malicioso, necesariamente conveniente— que la modificación de una única fuente de información haga saltar las alarmas e impida causar daños graves de inmediato. En su lugar, introducir pequeños cambios en varias fuentes de datos puede ser una estrategia más eficaz, ya que puede provocar alteraciones sutiles pero persistentes en el comportamiento del sistema a lo largo del tiempo, como relajar las restricciones de respuesta, revelar flujos de trabajo internos o dar prioridad al contexto controlado por el atacante frente a las políticas del sistema. El resultado final puede ser una extracción de datos confidenciales a mayor escala.

Por lo tanto, los compradores deben evaluar si los controles de seguridad de la IA tratan todo el contenido recuperado como potencialmente hostil y si los límites de las instrucciones se aplican de forma coherente, independientemente de dónde procedan dichas instrucciones.

Las soluciones eficaces distinguen con gran precisión entre las entradas del usuario y el contenido recuperado. Cuando se detectan intentos de anular instrucciones en las solicitudes de los usuarios, los sistemas los bloquean; cuando aparecen frases similares en artículos legítimos de soporte, las gestionan adecuadamente. La detección se basa en la intención semántica, no en palabras clave, lo que permite identificar ataques ofuscados mediante la manipulación de la codificación o escenarios de juego de roles. Los proveedores deben demostrar la capacidad de detección utilizando la arquitectura RAG real de la organización con recuperación desde múltiples fuentes. Los sistemas deben proporcionar métricas de producción correspondientes a periodos de tiempo significativos que muestren las tasas de detección, las tasas de falsos positivos y la latencia.

Entre las señales de alarma se incluyen: la dependencia de un filtrado genérico de prompts; afirmaciones vagas de que «el modelo se encarga»; la incapacidad de demostrar que se aplican los límites de las instrucciones en condiciones adversas; la falta de métricas de producción correspondientes a periodos de tiempo significativos; la incapacidad de demostrar la detección utilizando la arquitectura RAG interna; y la detección basada únicamente en palabras clave, sin analizar la intención semántica.

La integridad de las entradas no consiste en bloquear lenguaje malicioso, sino en preservar la autoridad de las políticas en entornos dinámicos y no fiables.

Gestión de riesgos de salida y exfiltración de datos

Los resultados generados por la IA plantean claramente un riesgo significativo, dado que un agente no humano puede haber extraído datos de numerosos sistemas distintos para formular su respuesta, y esta puede revelar a usuarios externos más información de la prevista inicialmente. Muchos fallos de gran impacto no implican contenido expresamente prohibido, sino la divulgación sutil de información que no debería haberse revelado a un usuario concreto, en un contexto determinado y en un momento específico.

Un atacante o usuario no autorizado puede formular una serie de preguntas que, a primera vista, parezcan inocuas y que, por separado, devuelvan datos permitidos, pero que, en conjunto, permitan inferir o reconstruir información confidencial. Por ejemplo, un asistente de IA conectado a sistemas internos de gestión de incidencias y documentación podría resumir problemas operativos, funciones del personal o configuraciones de sistemas de tal forma que revelase indirectamente la arquitectura interna o datos sujetos a regulación. Estos fallos rara vez se detectan mediante filtros de palabras clave. El riesgo surge, en cambio, de la agregación y el contexto. Los compradores deben evaluar si los controles de salida tienen en cuenta la exposición acumulada y si los sistemas pueden explicar por qué se ha restringido una respuesta, un requisito esencial para la gobernanza y la auditabilidad.

Los compradores deben esperar respuestas claras a preguntas como las siguientes:

• ¿Cómo determinan los controles de seguridad de la IA qué información concreta se está exponiendo en función del contexto, en lugar de limitarse a detectar qué palabras clave o frases aparecen en el resultado?
• ¿Puede el sistema distinguir entre información pública, información interna y datos regulados?
• ¿Con qué eficacia evita el sistema que el modelo revele datos sensibles en sus respuestas, incluso cuando la solicitud del usuario parece legítima o ambigua?
• ¿Qué tipos de datos sensibles abarca la protección (por ejemplo, datos personales, datos financieros e información corporativa confidencial) y cómo puede adaptarse a la organización?
• ¿Los controles tienen en cuenta el rol del usuario, la jurisdicción o el origen de los datos?
• ¿Puede el sistema explicar por qué se ha bloqueado o modificado un resultado?
• ¿Puede el sistema aplicar controles tanto a las solicitudes como a las respuestas, incluidos el rechazo, la ocultación de información y la transformación segura, aportando pruebas para auditoría?
• ¿Qué medidas puede adoptar el sistema para evitar que el modelo revele datos sensibles (bloquear, ocultar, transformar, advertir o exigir una revisión/aprobación adicional)?
• ¿Hasta qué punto evita el sistema los trucos en los prompts y las estrategias de evasión que intentan engañar al modelo para que revele datos de forma indirecta (por ejemplo, solicitando «ejemplos», «plantillas», «datos de prueba» o «resúmenes» que contengan información real)?
• ¿Puede el sistema prevenir y detectar fugas de datos entre sesiones o entre inquilinos, garantizando que la información de la sesión, el contexto o las fuentes de datos consultadas de un usuario no aparezca en las respuestas de otro usuario?
• ¿Con qué eficacia impide el sistema que el modelo revele prompts del sistema, instrucciones internas, políticas ocultas o detalles de la configuración operativa?
• ¿Con qué eficacia evita el sistema la exposición de credenciales o secretos (por ejemplo, claves de API o tokens) que puedan existir en los datos de entrenamiento, el contexto del sistema, los registros, los conectores o el contenido recuperado?
• ¿Con qué eficacia evita el sistema que el modelo genere respuestas dañinas, despectivas o marcadamente sesgadas, especialmente en casos extremos en los que un usuario intenta provocarlo?
• ¿Hasta qué punto puede el sistema evitar que el modelo genere extensos pasajes protegidos por derechos de autor de forma literal o que reproduzca de cualquier otro modo contenido protegido?
• Si el modelo está conectado a contenido corporativo interno (p. ej., documentos, una wiki o sistemas de gestión de incidencias), ¿puede el sistema impedir que reproduzca material interno restringido que el usuario no esté autorizado a ver?
• ¿Con qué eficacia puede el sistema evitar que el modelo «guíe paso a paso» a un usuario en flujos de trabajo perjudiciales o genere artefactos operativos (por ejemplo, scripts, comandos o código) que puedan crear vulnerabilidades de seguridad o provocar un comportamiento inseguro del sistema?

Cuando los sistemas de IA están conectados a fuentes de datos empresariales en tiempo real, estos riesgos aumentan considerablemente y pueden producirse fallos relacionados con los resultados cuando los sistemas de IA combinan información de varias fuentes en una única respuesta.

La evaluación de los controles de salida requiere comprender cómo gestionan las soluciones maduras la exposición contextual de los datos. Los sistemas sensibles al contexto comprenden el significado semántico, no solo las palabras clave. Esto debería permitir bloquear la información de identificación personal (PII) estructurada y, al mismo tiempo, autorizar la información pública en función del contexto. La aplicación de controles basados en roles garantiza que distintos usuarios vean resultados diferentes para consultas idénticas según sus niveles de autorización. Los sistemas deben detectar la exposición acumulativa entre sesiones, cuando varias preguntas que por separado son inocuas revelan en conjunto información confidencial. Las decisiones de bloqueo deben incluir referencias específicas a las políticas, los tipos de datos y los requisitos de autorización. La integración con las políticas de clasificación de datos existentes evita duplicar la configuración.

Entre las señales de alarma se incluyen: el filtrado basado únicamente en palabras clave; las decisiones de aplicación de políticas poco transparentes; la incapacidad del sistema para demostrar la aplicación de controles basados en roles (por ejemplo, que una misma consulta devuelva el mismo resultado independientemente del nivel de autorización del usuario); la incapacidad del proveedor para explicar en términos comprensibles por qué se bloqueó un resultado concreto; y la ausencia de registros de auditoría. Las empresas deben buscar pruebas de que los controles de salida tienen en cuenta el contexto y la intención, y garantizan la rendición de cuentas.

Gestión de la resiliencia, la robustez, los fallos y la degradación

Las empresas están acostumbradas a evaluar los controles de seguridad en función de su eficacia en condiciones normales de red, pero la seguridad de la IA exige un enfoque diferente. Algunos de los fallos más importantes no se producen cuando los sistemas son atacados directamente, sino cuando se ven sometidos a un volumen o una complejidad elevados, a fallos en las dependencias o a patrones de interacción inesperados.

Las preguntas clave que convendría plantearse son:

• ¿Hasta qué punto mantiene el sistema su disponibilidad y capacidad de respuesta durante interacciones con el usuario inusualmente largas o complejas (por ejemplo, sesiones «maratonianas»)?
• ¿Se aplican los controles de forma coherente durante las sesiones prolongadas o los flujos de trabajo de agentes con varios pasos?
• ¿Cómo evita el sistema el agotamiento de recursos o la degradación del servicio cuando recibe ráfagas de entradas repetitivas, mal formadas o sin sentido?
• ¿Qué ocurre cuando se degradan los controles de seguridad de la IA?
• ¿Se agota el tiempo de espera de las comprobaciones de políticas y, en caso de fallo, la aplicación de estas permite o bloquea el acceso?
• ¿Cómo equilibra el sistema la seguridad y el tiempo de actividad durante los fallos de las dependencias, y se puede configurar y auditar ese comportamiento?

Los sistemas de IA del mundo real funcionan en condiciones variables, como picos de uso, interrupciones de servicios externos, proveedores de identidad lentos o servicios de recuperación degradados. En estas situaciones, los componentes de aplicación de controles pueden fallar parcialmente en lugar de hacerlo por completo. Por ejemplo, un servicio de evaluación de políticas puede agotar el tiempo de espera, o puede omitirse un paso de clasificación para mantener la capacidad de respuesta. Si estos fallos no se gestionan con cuidado, los sistemas pueden adoptar de forma predeterminada un comportamiento permisivo sin alertar a los operadores y, en los flujos de trabajo con agentes, esto puede permitir que se ejecuten acciones sin las comprobaciones adecuadas. No se trata de casos extremos hipotéticos, sino de modos de fallo habituales en los sistemas distribuidos. Por tanto, los compradores deben exigir demostraciones de cómo se comportan los controles de seguridad de la IA cuando se degradan las dependencias, y comprobar si los modos de fallo son predecibles, visibles y acordes con la tolerancia al riesgo de la empresa.

Un sistema resiliente no debería limitarse a bloquearlo todo cuando algo sale mal, ni permitir silenciosamente comportamientos inseguros. En su lugar, debería degradarse de forma predecible, informar claramente de los errores y seguir ofreciendo una protección adecuada a medida que las condiciones empeoran.

Los sistemas bien diseñados deben documentar modos de fallo explícitos para cada dependencia. Cuando se agote el tiempo de espera de los servicios, los sistemas deben responder adecuadamente ante el fallo, registrar los eventos, alertar a los equipos de seguridad y mostrar mensajes claros a los usuarios. En las pruebas de estrés, la precisión de la detección debe mantenerse alta, la latencia debe permanecer dentro de unos umbrales aceptables y las solicitudes no deben poder eludir los controles de seguridad. La degradación debe producirse de forma predecible y generar alertas, no ocurrir de manera silenciosa, y los disyuntores deben detener rápidamente los procesos descontrolados. Los proveedores deben poder describir los objetivos de disponibilidad de los mecanismos de aplicación y su comportamiento ante fallos; cuando dicha aplicación sea crítica para la misión, los compradores podrán exigir compromisos contractuales.

Entre las señales de alarma se incluyen: la incapacidad para describir los modos de fallo; la falta de pruebas de estrés o las afirmaciones de que «el sistema no ha fallado en la práctica»; la degradación silenciosa sin alertas; la ausencia de disyuntores para procesos fuera de control; la incapacidad para demostrar que la precisión de la detección se mantiene alta durante las pruebas de estrés; y los sistemas que permiten que las solicitudes eludan los controles de seguridad durante la degradación.

Eficacia de las políticas y los filtros y alineación con la gobernanza

Los controles de seguridad de la IA que son técnicamente sofisticados, pero no están alineados con las operaciones, rara vez resisten el contacto con la primera línea: el negocio. En los entornos empresariales, las decisiones sobre políticas no suelen ser binarias ni inamovibles y, en última instancia, son decisiones de gobernanza.

Los compradores deberían preguntar:

• ¿Cómo se definen, aprueban, versionan y auditan las políticas?
• ¿Se puede definir el ámbito de aplicación de las políticas según el rol, la sensibilidad de los datos, la ubicación geográfica o el contexto empresarial?
• ¿Puede el sistema explicar por qué se tomó una decisión?
• ¿En qué medida permite el sistema aplicar políticas que reflejen la postura de cumplimiento específica de la organización (normativas del sector, políticas internas y restricciones de uso aceptable), y cómo se mantienen dichas políticas a lo largo del tiempo?
• ¿Con qué eficacia ayuda el sistema a evitar respuestas que puedan generar riesgos legales o de incumplimiento normativo (por ejemplo, consejos u orientaciones que infrinjan las normas o estándares aplicables)?

Los fallos en las políticas no suelen deberse a una mala intención, sino al desfase entre la aplicación técnica y la realidad empresarial. Por ejemplo, un sistema de IA puede bloquear correctamente el acceso a determinadas categorías de datos, pero hacerlo de tal forma que impida flujos de trabajo empresariales legítimos, lo que lleva a los usuarios a eludir por completo los controles mediante herramientas no autorizadas. Por el contrario, unas políticas definidas de forma demasiado laxa pueden permitir que se exponga información sensible en contextos que incumplan obligaciones normativas o contractuales. Con el tiempo, los ajustes puntuales para atender reclamaciones pueden menoscabar la integridad de las políticas y la rendición de cuentas. Por tanto, los compradores deben evaluar si las plataformas de seguridad de IA permiten una gobernanza estructurada de las políticas, que incluya aprobaciones documentadas, un historial de versiones y la posibilidad de revisar los resultados de su aplicación. Sin esta disciplina, la precisión de las políticas se vuelve subjetiva y difícil de defender tras un incidente de seguridad.

Una aplicación excesivamente estricta puede generar disrupciones y llevar a usuarios frustrados a implementar sistemas de IA «en la sombra» no autorizados, mientras que una aplicación insuficiente puede conllevar riesgos normativos y reputacionales. Ambas situaciones reflejan un fallo de gobernanza, no del modelo.

Una gestión eficaz de las políticas debe tratarlas como código, con control de versiones, flujos de trabajo de aprobación y registros de auditoría. Los cambios en las políticas deben requerir la aprobación documentada de las partes interesadas de los ámbitos de seguridad, jurídico y empresarial antes de su despliegue en producción. Cada decisión de aplicación debe poder vincularse a una cláusula, versión y sección concretas de la política, así como a la lógica de autorización correspondiente. Siempre que sea posible, el perfeccionamiento de las políticas debe basarse en los datos de los paneles del sistema, que proporcionen información como las tendencias de falsos positivos, los bloqueos de alto impacto y, cuando sea posible, recomendaciones de ajuste.

Las señales de alerta incluyen: una toma de decisiones opaca; ajustes improvisados o afirmaciones de que las políticas «aprenden por sí solas» sin que exista una rendición de cuentas; la ausencia de control de versiones y flujos de aprobación para los cambios en las políticas; decisiones de aplicación que no pueden vincularse a cláusulas específicas de las políticas; y conflictos entre políticas sin reglas de resolución documentadas.

IA agéntica, seguridad en la invocación de herramientas y autoridad delegada

A medida que los sistemas de IA dejan atrás la asistencia pasiva y comienzan a actuar en nombre de los usuarios y de otros sistemas, surge una nueva categoría de riesgo conocida como autoridad delegada. Los sistemas de IA agéntica pueden utilizar otras herramientas, modificar registros y activar flujos de trabajo complejos a la velocidad de una máquina.

Los compradores que evalúen la seguridad de la IA agéntica deben examinar varias áreas de control clave:

• ¿Qué acciones puede realizar el sistema de forma autónoma?
• ¿Cómo se restringen los permisos?
• ¿Hasta qué punto garantiza el sistema que un agente haga únicamente aquello que tiene permitido cuando se le delega autoridad para actuar en nombre de un usuario?
• ¿Se puede graduar la autonomía en función del riesgo o del contexto, dado que, sin límites claros, los pequeños errores pueden propagarse rápidamente entre sistemas?
• ¿Hasta qué punto impiden los controles del sistema que una instrucción lo lleve a realizar acciones fuera de los límites previstos (aunque el usuario «lo pida amablemente») cuando puede interactuar con herramientas y agentes externos o utilizarlos?
• ¿Evita o contiene el sistema de forma eficaz los bucles recursivos o los comportamientos «descontrolados» en los que un agente sigue actuando sin alcanzar el objetivo?
• ¿Hasta qué punto es eficaz el sistema para impedir el uso no autorizado de herramientas, la escalada de API/acciones, la autonomía o los bucles excesivos y el encadenamiento no seguro entre herramientas?
• En las arquitecturas multiagente, ¿con qué eficacia evita el sistema que los datos sensibles recuperados o generados por un agente se propaguen innecesariamente a agentes posteriores o a herramientas que realizan tareas relacionadas?
• En las arquitecturas multiagente, es fundamental que la autoridad se propague correctamente entre los distintos límites del sistema. ¿Con qué eficacia conserva el sistema el contexto de identidad a lo largo de las cadenas de agentes, garantizando que los agentes y las herramientas posteriores operen estrictamente dentro de los permisos del usuario original, en lugar de hacerlo con privilegios elevados del sistema?

Los fallos en la delegación de autoridad suelen producirse cuando se concede a los sistemas de IA un amplio acceso a herramientas para facilitar la automatización sin las restricciones adecuadas. Por ejemplo, un agente de IA encargado de resolver incidencias de soporte podría consultar bases de datos, actualizar registros y enviar notificaciones a los usuarios. Una instrucción malinterpretada o un contexto inesperado podrían provocar modificaciones incorrectas de los datos o comunicaciones prematuras a los clientes. Dado que estas acciones se ejecutan a la velocidad de una máquina, los errores pueden propagarse antes de que la supervisión humana pueda intervenir. En flujos de trabajo complejos, varias acciones individuales de bajo riesgo pueden combinarse y generar consecuencias de gran impacto. Los compradores deben evaluar si los controles de seguridad de la IA aplican el principio de mínimo privilegio, exigen confirmación para las acciones sensibles y ofrecen mecanismos para limitar o revocar la autonomía de forma dinámica. Tratar el comportamiento de los agentes como una cuestión de gobernanza es esencial para evitar una escalada silenciosa.

En los sistemas bien diseñados, estos riesgos se mitigan mediante controles arquitectónicos. Los sistemas debidamente restringidos aplican el principio de mínimo privilegio a cada herramienta, con límites de permisos documentados. La autonomía gradual debe exigir confirmación para las acciones de impacto moderado y aprobación humana para las de alto impacto, mientras que la conservación del contexto de identidad garantiza que los agentes hereden los permisos del usuario, no los permisos del sistema. Cuando los usuarios soliciten operaciones sensibles, los agentes deben recuperar únicamente la información autorizada y bloquear el acceso no autorizado. Los mecanismos de interrupción deben detener rápidamente los bucles descontrolados, y todas las acciones de los agentes deben registrarse íntegramente, incluidos el razonamiento, las comprobaciones de autorización y los resultados.

Estos controles reflejan una distinción importante entre las restricciones arquitectónicas, mediante las cuales el sistema impide técnicamente que un agente invoque determinadas herramientas o acciones, y las restricciones de comportamiento, en las que el agente podría realizar la acción, pero recibe instrucciones de no hacerlo. Siempre que sea posible, los límites críticos para la seguridad deben basarse en controles arquitectónicos, en lugar de depender únicamente de instrucciones de comportamiento.

Entre las señales de alerta se incluyen: Entre los indicios de una gobernanza deficiente de los agentes se encuentran el acceso indiscriminado a herramientas o la dependencia exclusiva del alineamiento del modelo para evitar usos indebidos; la ausencia de límites de permisos documentados para cada herramienta; la falta de conservación del contexto de identidad que garantice que los agentes hereden los permisos del usuario; la incapacidad para detectar secuencias de acciones inseguras mediante el análisis de cadenas; y el registro incompleto de las acciones de los agentes, sin incluir el razonamiento ni las comprobaciones de autorización.

Observabilidad, auditoría y análisis forense

Cuando algo falla en un sistema de IA, es importante poder demostrar cómo y por qué ocurrió, e incluso, quizá, reproducirlo.

Los compradores deben preguntar si es posible reconstruir de principio a fin las interacciones con la IA, incluidas las entradas, el contexto, las políticas, los resultados, las acciones, las herramientas utilizadas y los datos a los que se ha accedido. Los sistemas eficaces también deben permitir una supervisión continua y la generación de alertas, de modo que los equipos de seguridad puedan detectar comportamientos anómalos, cadenas de acciones inseguras o interacciones inesperadas entre agentes antes de que los incidentes se agraven. Sin una visibilidad suficiente sobre el comportamiento del sistema, la respuesta ante incidentes se basa en conjeturas y los esfuerzos de gobernanza pierden credibilidad.

Cuando se producen incidentes relacionados con la IA, es posible que se exija a las organizaciones que aporten pruebas en lugar de explicaciones. Sin registros detallados de las entradas, el contexto recuperado, las políticas aplicadas, los resultados y las acciones, los equipos de respuesta a incidentes se ven obligados a reconstruir los hechos basándose en suposiciones y no en datos objetivos, algo especialmente problemático en los sistemas de IA, cuyo comportamiento puede no ser reproducible debido a su carácter no determinista. Por ejemplo, un organismo regulador o un auditor interno puede preguntar por qué se divulgó determinada información o por qué se llevó a cabo una acción automatizada, pero, sin una observabilidad integral, las organizaciones no pueden demostrar la intencionalidad, la proporcionalidad ni la eficacia de los controles. Por tanto, los compradores deben evaluar si las plataformas de seguridad de IA ofrecen el nivel de visibilidad necesario para respaldar la respuesta a incidentes, los informes de cumplimiento normativo y el aprendizaje posterior a los incidentes.

Un registro exhaustivo debe permitir reconstruir las solicitudes de principio a fin, incluidos el prompt original, el contexto recuperado con sus fuentes, el contexto de identidad y autorización, las políticas evaluadas y sus versiones, la salida del modelo, las modificaciones realizadas, la respuesta final al usuario y las acciones posteriores. Los eventos de seguridad de la IA deben poder integrarse con sistemas SIEM con una latencia mínima, lo que permite correlacionarlos con el tráfico de red y los eventos de autenticación. Las infracciones críticas deben generar alertas de inmediato y aportar suficiente contexto para responder rápidamente, además de ofrecer paneles unificados para supervisar las métricas de seguridad, rendimiento y calidad, así como analizar sus tendencias.

Desde la perspectiva de la gobernanza, el riesgo y el cumplimiento (GRC), los sistemas que no pueden observarse no pueden gobernarse.

Integración e interoperabilidad

Los controles de seguridad de la IA que funcionan de forma aislada generan lagunas de visibilidad e impiden una respuesta coordinada. Las arquitecturas de defensa en profundidad requieren controles que compartan datos de telemetría y coordinen la aplicación de medidas en las distintas capas de seguridad.

Gestión de identidades y accesos: Los límites de autorización deben abarcar desde la autenticación del usuario hasta la salida final, pasando por la recuperación de datos. Las organizaciones deben evaluar cómo se integran los sistemas con los proveedores de identidad y si los cambios de rol se propagan correctamente. Los sistemas deben conservar el contexto de autorización cuando los agentes de IA actúen en nombre de los usuarios, con cadenas de permisos trazables; asimismo, las políticas de acceso deben heredarse de los modelos RBAC existentes sin duplicar la configuración. En la capa de recuperación, los sistemas deben aplicar el principio de mínimo privilegio y filtrar los documentos según el nivel de autorización del usuario solicitante.

Integración con SIEM: Los eventos de seguridad de la IA deben correlacionarse con el conjunto más amplio de datos de telemetría de seguridad. Para ello, los sistemas deben exportar los eventos a plataformas SIEM en formatos estándar como OCSF o CEF y con una latencia mínima. Los formatos de registro propietarios impiden correlacionarlos con el tráfico de red, los eventos de autenticación y los patrones de acceso a los datos. Las organizaciones deben comprobar si es posible crear reglas de detección personalizadas a partir de los eventos de seguridad de la IA y si las alertas se integran con los flujos de trabajo existentes de respuesta ante incidentes.

Alineación con los marcos de cumplimiento: Las soluciones deben vincular los controles con marcos establecidos, indicando la cobertura específica de cada control y aportando pruebas de auditoría. Además, los informes de cumplimiento deben poder personalizarse según los requisitos normativos específicos. Las afirmaciones genéricas sobre cumplimiento que no incluyan correspondencias concretas con los controles son insuficientes.

Compatibilidad con API y automatización: Las operaciones de seguridad modernas requieren un control programático, con sistemas que admitan flujos de trabajo de políticas como código y la integración de infraestructura como código. Las API sin documentar o que cambian con frecuencia generan integraciones frágiles.

Qué deben exigir los compradores antes de comprar

Las empresas deben exigir pruebas en lugar de diagramas de arquitectura y materiales de marketing llamativos, reproducibilidad en lugar de demostraciones impecables y validación independiente en lugar de afirmaciones sin respaldo.

Los compradores deben exigir a los proveedores que expliquen las limitaciones, faciliten pruebas realistas y proporcionen materiales que resistan un examen riguroso.

No se debe confiar la protección de sistemas de IA críticos para el negocio a controles de seguridad que no puedan probarse ni explicarse.

Preparación para la validación independiente

Evaluar la seguridad de la IA es difícil, pero esa dificultad no justifica la falta de validación. Las pruebas independientes siguen siendo una de las pocas formas en que las empresas pueden confiar en que los controles y las funcionalidades se comportan según lo previsto.

Los compradores deben exigir métodos de validación que reflejen condiciones reales, incluidas las entradas maliciosas, los escenarios de degradación y los requisitos de gobernanza. Los proveedores que no estén dispuestos a participar en una validación rigurosa demuestran inmadurez, no solidez.

La validación tampoco debe considerarse un ejercicio puntual. Los controles de seguridad de la IA que ofrecen buenos resultados en la evaluación inicial pueden perder eficacia a medida que evolucionan las amenazas, avanzan las capacidades de los modelos y surgen nuevas técnicas de ataque. El panorama de amenazas cambia rápidamente, y los incidentes de seguridad relacionados con la IA pueden implicar métodos de ataque nunca vistos hasta ahora. Por tanto, las organizaciones deben establecer requisitos de validación continua, además de realizar pruebas iniciales.

Integración de inteligencia sobre amenazas: Las organizaciones deben evaluar la frecuencia con la que los proveedores actualizan sus sistemas para incorporar vulnerabilidades recién divulgadas por proveedores de inteligencia sobre amenazas y organizaciones de investigación en seguridad. Los proveedores deben demostrar que pueden detectar ataques publicados recientemente, y no limitarse a utilizar datos históricos de entrenamiento. La incorporación automatizada de inteligencia sobre amenazas permite responder con mayor rapidez que los procesos de revisión manual.

Compatibilidad con la evolución de los modelos: Las capacidades de los modelos fundacionales evolucionan rápidamente, por lo que los controles de seguridad deben adaptarse. Las organizaciones deben solicitar datos sobre la eficacia de la detección específica de cada modelo en distintos modelos fundacionales y desconfiar de las afirmaciones genéricas sin pruebas cuantitativas, ya que pueden ocultar puntos ciegos. Los proveedores deben facilitar plazos explícitos para certificar las nuevas versiones de los modelos y medidas de mitigación provisionales durante los periodos en los que aún no estén certificadas.

Validación impulsada por el comprador: Las organizaciones deben probar continuamente los controles en lugar de depender únicamente de la validación del proveedor. Los compradores deben negociar derechos contractuales para realizar ejercicios periódicos de equipo rojo, pruebas automatizadas continuas para eludir los controles y pruebas A/B de los cambios de políticas en producción. Los proveedores que restringen las pruebas de los clientes o no facilitan datos telemétricos detallados dan muestras de inmadurez.

Las organizaciones deben considerar la validación como una colaboración continua, en lugar de una evaluación puntual, para mantener su eficacia a medida que evoluciona el panorama de amenazas. Sin esta práctica, incluso los controles bien diseñados pueden acabar resultando insuficientes frente a nuevas técnicas de ataque.

Conclusión: de las afirmaciones a la rendición de cuentas

Adquirir soluciones de seguridad para la IA no es solo una decisión técnica, sino también una decisión de gobernanza con consecuencias a largo plazo.

Las empresas que plantean desde el principio las preguntas difíciles están mejor preparadas para gestionar los riesgos, defender sus decisiones y evitar fallos prevenibles.

La seguridad de la IA no tendrá éxito gracias a la novedad ni a la abstracción, sino mediante la rendición de cuentas, la transparencia y una evaluación rigurosa.

© 2026 NSS Labs®. Todos los derechos reservados. Ninguna parte de esta publicación podrá reproducirse, copiarse o escanearse, almacenarse en un sistema de recuperación, enviarse por correo electrónico ni difundirse o transmitirse de cualquier otro modo sin el consentimiento expreso por escrito de NSS Labs («nosotros»).