Seguridad de la IA más allá del modelo: qué debe importar a las empresas y por qué

La IA avanza rápidamente, y la mayoría de las empresas solo protegen una pequeña parte de su superficie de riesgo real. Este informe de investigación de NSS Labs, elaborado en colaboración con F5, AWS y Microsoft, analiza los vectores de amenaza, las carencias de gobernanza y las áreas de capacidad más relevantes cuando la IA pasa de la fase de experimentación a la producción.

Índice

Introducción: Por qué la seguridad de la IA es una cuestión de riesgo empresarial

Pilares fundamentales de la IA responsable en la seguridad

Por qué la seguridad del modelo por sí sola es insuficiente

Delimitación de las responsabilidades en materia de seguridad de la IA

El nuevo modelo de amenazas: por qué fallan los supuestos de seguridad tradicionales

Las áreas de capacidad que realmente importan

Integridad de las entradas y control de las instrucciones

Gestión del riesgo de salida y de la exfiltración de datos

Resiliencia y robustez del sistema

Precisión de las políticas y gestión de las compensaciones

Verificación determinista para decisiones críticas para la seguridad

IA agéntica y autoridad delegada

Observabilidad, auditoría y análisis forense

Por qué fracasará la seguridad de la IA sin GRC

Conclusión: gobernar la IA a escala empresarial

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

Resumen ejecutivo

La inteligencia artificial ha pasado rápidamente de la fase de experimentación a su implantación en entornos de producción empresariales. Los modelos de IA generativa, los asistentes conversacionales y los sistemas basados en agentes cada vez más autónomos ya están integrados en aplicaciones orientadas al cliente, flujos de trabajo internos, procesos de desarrollo de software y procesos de apoyo a la toma de decisiones. Como consecuencia, los fallos en los sistemas de IA ya plantean riesgos empresariales, jurídicos, reputacionales y operativos tangibles, además de suponer un importante desafío para una gobernanza eficaz.

Gran parte de la atención en torno a la seguridad de la IA se centra en los propios modelos de IA, concretamente en cómo se entrenan, qué datos contienen y cómo se comportan en condiciones controladas. Aunque la seguridad del modelo de IA es claramente muy importante, solo aborda una parte de la superficie de riesgo. En los entornos de producción, las vulnerabilidades más graves suelen encontrarse fuera del modelo: en los datos a los que está conectado, las herramientas que puede utilizar, los permisos que hereda y las prácticas de gobernanza —o la ausencia de ellas— que limitan su comportamiento.

Este documento expone los aspectos que más deberían preocupar a las empresas al evaluar soluciones de seguridad de la IA y explica por qué son importantes. Sin centrarse en productos concretos ni en los mecanismos de las pruebas, presenta una visión de la seguridad de la IA basada en capacidades y enmarcada desde la perspectiva de la gestión de riesgos empresariales, la gobernanza y la rendición de cuentas. El objetivo es ofrecer orientación práctica a los responsables de seguridad de la información (CISO), los compradores empresariales y los responsables de Gobernanza, Riesgo y Cumplimiento (GRC) sobre las preguntas que deben plantearse antes de que los fallos de la IA en situaciones reales revelen respuestas indeseadas ante el escrutinio regulatorio, jurídico, de los clientes o del consejo de administración.

Introducción: por qué la seguridad de la IA es una cuestión de riesgo empresarial

El uso de la IA en los sistemas empresariales se está acelerando, lo que plantea importantes retos para quienes tienen la responsabilidad de implantar los controles destinados a gestionarla. Las unidades de negocio están desplegando funcionalidades basadas en IA para mejorar la productividad, automatizar la toma de decisiones, acelerar el desarrollo de software y diferenciar la experiencia del cliente. Muchos de estos sistemas se implantan mucho antes de someterse a una revisión formal de seguridad, riesgos o gobernanza. Este ritmo está ampliando la brecha entre la innovación y la rendición de cuentas.

Proteger el propio modelo de IA es esencial, pero no basta por sí solo. La mayoría de las empresas ya aplican controles directamente en la capa del modelo: seleccionan y depuran los datos de entrenamiento; utilizan técnicas de ajuste de seguridad y alineación; restringen quién puede acceder al modelo; limitan la frecuencia de uso; y recurren a filtros de contenido y mecanismos de rechazo integrados. Estas medidas condicionan los resultados que genera el modelo y reducen los usos indebidos más evidentes, pero no abordan cómo funcionan los sistemas de IA en entornos empresariales reales, donde los resultados interactúan con datos en tiempo real, desencadenan acciones y operan en contextos de autorización complejos.

En el contexto de la seguridad de la IA, la IA responsable (RAI) engloba el marco general de gobernanza y gestión del ciclo de vida, así como las políticas y prácticas técnicas empleadas para garantizar que los sistemas de inteligencia artificial sean seguros, resilientes y fiables durante todo su ciclo de vida. Va más allá de limitarse a detener ataques, pues busca garantizar que los sistemas sean robustos frente a daños involuntarios, vulneraciones de la privacidad y sesgos, al tiempo que se mantiene la supervisión humana.

Pilares fundamentales de la IA responsable en la seguridad

Desde una perspectiva específicamente centrada en la seguridad, el marco de IA responsable se traduce en varios ámbitos de control prácticos: garantizar que los sistemas de IA sean resistentes a errores, entradas inesperadas y ataques adversarios intencionados; proteger el proceso de entrenamiento y despliegue para garantizar la privacidad y la protección de los datos; mantener la transparencia y la auditabilidad; y establecer procesos de gobernanza que definan el uso aceptable y la rendición de cuentas.

Dentro del marco de la IA responsable (RAI), las capacidades de seguridad centradas en los modelos mitigan de forma proactiva vulnerabilidades específicas propias del aprendizaje automático, como:

• Envenenamiento de datos: manipulación de los datos de entrenamiento para corromper el modelo
• Inversión/extracción de modelos: robo de modelos propietarios o filtración de datos de entrenamiento confidenciales
• Ataques adversarios: introducción de pequeños cambios imperceptibles en los datos de entrada para provocar decisiones erróneas
• Inyección de prompts: engañar a la IA generativa para que eluda los límites establecidos por las políticas y las instrucciones

Estos controles de seguridad de los modelos son necesarios para garantizar un nivel básico de seguridad, pero funcionan en gran medida sin tener en cuenta el contexto empresarial y, por lo general, no permiten una validación independiente o externa. Las empresas suelen tener una visibilidad limitada sobre cómo se implementan los controles o cómo se comportan en condiciones límite.

En los despliegues empresariales, el modelo de IA es solo un componente de un sistema más amplio que incluye capas de recuperación, conectores a datos empresariales, señales de identidad y autorización, así como la invocación de herramientas capaces de alterar drásticamente el estado de los sistemas posteriores. La superficie de riesgo empresarial está determinada principalmente por estas integraciones y por los componentes circundantes del sistema de IA. Incluso un modelo bien alineado puede utilizarse de forma insegura si está conectado a datos inadecuados, si se le conceden permisos excesivos para usar herramientas, si la aplicación de las políticas es incoherente o si la supervisión resulta insuficiente para detectar usos indebidos.

Aquí es donde los controles externos de seguridad de la IA en tiempo de ejecución (denominados de diversas formas como barreras de protección para la IA, cortafuegos de IA o sistemas de protección de la IA) se vuelven esenciales. Las barreras de protección en tiempo de ejecución son controles específicos, técnicos y en tiempo real, implementados fuera del modelo para aplicar políticas de seguridad y límites de comportamiento en el momento de la interacción con la aplicación, que es cuando se materializa el riesgo empresarial. Estos controles observan y restringen el comportamiento de la IA utilizando el contexto del sistema, incluida la identidad del usuario, la sensibilidad de los datos, el estado de la aplicación y los requisitos de gobernanza. Los controles en tiempo de ejecución aportan auditabilidad, resiliencia y rendición de cuentas, y constituyen la base de una seguridad de la IA de nivel empresarial.

La terminología varía según los proveedores y los marcos de trabajo, pero la conclusión práctica es sencilla: la seguridad del modelo reduce el riesgo intrínseco del modelo, mientras que las medidas de protección en tiempo de ejecución gestionan el riesgo empresarial en el punto de interacción.

Por qué la seguridad del modelo por sí sola no es suficiente

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.

Abordar estos riesgos requiere controles en tiempo de ejecución que funcionen con un conocimiento integral del sistema y bajo supervisión de gobernanza. Esto incluye aplicar políticas basadas en los roles y la sensibilidad de los datos, limitar la invocación de herramientas y la autoridad delegada, gestionar los modos de fallo de forma predecible y generar pruebas que respalden la investigación, la auditoría y el cumplimiento normativo.

Sin gobernanza, observabilidad y resiliencia, la seguridad de los modelos por sí sola no puede proporcionar el nivel de garantía necesario para los sistemas de IA que operan a escala empresarial. Por tanto, las organizaciones más maduras abordarán la seguridad de la IA como un problema de sistemas y gobernanza, y no únicamente como un problema de modelos.

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 desarrolló 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

Delimitación de las responsabilidades de seguridad de la IA

Las organizaciones que utilizan servicios de IA se enfrentan a riesgos fundamentalmente distintos de los que afrontan aquellas que desarrollan modelos personalizados o los entrenan desde cero. Comprender el alcance de la implementación permite determinar qué controles de seguridad se gestionan internamente y cuáles corresponden al proveedor.

Cinco ámbitos de implementación

1. En el nivel más básico, las aplicaciones de IA orientadas al consumidor como ChatGPT, Claude o Gemini atribuyen casi todas las responsabilidades de seguridad al proveedor. El proveedor se encarga de la seguridad del modelo, la protección de la infraestructura, las medidas de protección básicas y la protección de los datos. La organización se centra en establecer políticas de uso aceptable, controlar el acceso de los usuarios y validar los resultados en función del contexto empresarial. Los esfuerzos de seguridad se centran en evitar que los empleados introduzcan datos confidenciales y en supervisar posibles infracciones de las políticas.
2. Aplicaciones empresariales con funciones de IA, como Salesforce Einstein o Microsoft Copilot, representan un modelo de responsabilidad compartida. Los proveedores gestionan la seguridad del modelo, los controles a nivel de aplicación y la seguridad de las integraciones, mientras que el cliente gestiona el acceso basado en roles, la clasificación de los datos y los permisos de los flujos de trabajo. El enfoque de la seguridad se desplaza hacia la integración de identidades, la gobernanza de datos y los registros de auditoría que demuestran un uso adecuado.
3. Las organizaciones que implementan modelos fundacionales preentrenados mediante plataformas como Amazon Bedrock o Azure OpenAI asumen una responsabilidad mucho mayor en materia de seguridad. Aunque los proveedores gestionan la seguridad del modelo y la infraestructura, el cliente se encarga de la ingeniería de prompts, la arquitectura de recuperación, el filtrado de resultados y los permisos de las herramientas. El enfoque de seguridad se amplía para abarcar la integridad de las entradas, la prevención de riesgos en los resultados y una observabilidad integral de todo el sistema.
4. Los modelos ajustados aumentan aún más la carga de seguridad para la organización. Los proveedores solo gestionan la infraestructura y la seguridad del modelo base, mientras que el cliente se encarga de la selección de los datos de entrenamiento, la seguridad del ajuste, los controles de despliegue y toda la seguridad en tiempo de ejecución. Las medidas de seguridad deben abordar la prevención del envenenamiento de datos, la evaluación de modelos y la aplicación de medidas de protección integrales durante todo el ciclo de vida de desarrollo y producción.
5. En el nivel de mayor complejidad, los modelos entrenados internamente hacen que prácticamente toda la responsabilidad en materia de seguridad recaiga sobre la organización. Los proveedores solo gestionan la infraestructura, mientras que el cliente se encarga de todos los aspectos relacionados con el desarrollo del modelo, la seguridad del proceso de entrenamiento, el despliegue y los controles en tiempo de ejecución. La seguridad abarca todo el ciclo de vida, desde la recopilación de datos hasta la supervisión en producción y la respuesta ante incidentes.

Comprender la responsabilidad compartida

El alcance de la implementación determina en gran medida las obligaciones de seguridad del cliente. En las aplicaciones de IA de consumo, la mayoría de las responsabilidades de seguridad recaen en el proveedor, mientras que la organización se centra en regular cómo utilizan los empleados esos servicios. Las aplicaciones empresariales aumentan la responsabilidad del cliente en cuanto a la integración de identidades y la gobernanza de datos, mientras que los proveedores protegen la infraestructura subyacente. Los modelos fundacionales preentrenados trasladan una parte importante de la responsabilidad de seguridad a la organización, lo que incluye la ingeniería de prompts, la arquitectura de recuperación y controles exhaustivos en tiempo de ejecución. Por último, en los modelos ajustados y entrenados internamente, casi todas las responsabilidades de seguridad recaen en el cliente, desde la selección y preparación de los datos de entrenamiento hasta la supervisión en producción y la respuesta ante incidentes.

Este modelo de responsabilidad compartida refleja el funcionamiento actual de la seguridad en la nube. Antes de abordar la planificación de la seguridad de la IA, es fundamental definir claramente el alcance de la implementación. Esto determina qué capacidades de seguridad deben desarrollarse internamente, cuáles gestiona el proveedor y en qué ámbitos se requiere una supervisión conjunta. Si no comprenden y adoptan claramente este alcance, las organizaciones pueden invertir en exceso en controles que el proveedor ya gestiona o dejar sin abordar carencias críticas.

El nuevo modelo de amenazas: por qué fallan los supuestos de seguridad tradicionales

La seguridad tradicional de las aplicaciones se basa en supuestos como unas entradas acotadas, unas rutas de ejecución predecibles y unos resultados deterministas. Los sistemas de IA no cumplen estos supuestos y, a menudo, los invalidan. Aceptan entradas de lenguaje natural no estructuradas, generan respuestas no deterministas y suelen mantener el contexto a lo largo de varios turnos de conversación. Incluso cuando la aplicación que los integra está bien diseñada, el modelo introduce un comportamiento probabilístico difícil de gestionar únicamente mediante el modelado de amenazas clásico.

Las implementaciones modernas de IA también son más complejas que un simple «se introduce una instrucción y se obtiene una respuesta». En las empresas reales, los sistemas de IA suelen estar conectados a documentos internos, bases de datos, API y servicios externos. Una arquitectura habitual es la generación aumentada por recuperación (RAG), en la que el modelo obtiene dinámicamente contenido externo durante la ejecución (como documentos de políticas, artículos de bases de conocimiento o registros de clientes) para responder a preguntas complejas con mayor precisión de la que permitirían únicamente sus datos de entrenamiento.

Muchas implementaciones irán aún más lejos y utilizarán sistemas autónomos o basados en agentes capaces de decidir qué pasos dar a continuación sin intervención ni instrucciones humanas directas. Estos agentes de IA determinan sus acciones mediante la interacción con herramientas externas, es decir, interfaces programáticas que amplían las capacidades de la IA más allá de la generación de texto. Las herramientas son funciones independientes que permiten a los sistemas de IA interactuar con sistemas externos y realizar acciones, como consultar bases de datos, llamar a API REST, ejecutar código, acceder a sistemas de archivos o invocar aplicaciones empresariales. A diferencia de la generación aumentada por recuperación (RAG), que obtiene información contextual para fundamentar las respuestas, las herramientas permiten a los sistemas de IA actuar y modificar el estado de los sistemas posteriores.

Cada herramienta representa un límite de seguridad con sus propios permisos y «radio de impacto»: cuando un agente de IA accede a una herramienta, hereda la capacidad de realizar cualquier acción que esta permita. Aunque estas capacidades aumentan la eficiencia y la escalabilidad, amplían la superficie de ataque de formas que resultan desconocidas para muchos equipos de seguridad y difíciles de gestionar mediante controles tradicionales.

Hay un viejo dicho: «No hay nada nuevo bajo el sol». Esto se aplica tanto a las amenazas de seguridad como a cualquier otro aspecto de la vida, lo que significa que los ingenieros de seguridad de IA deben ser tan conscientes de las superficies de ataque tradicionales, como los desbordamientos de búfer y las técnicas de evasión a nivel de red, como de las específicas de la IA. Al mismo tiempo, está claro que las amenazas para los sistemas de IA van mucho más allá de los exploits clásicos.

Entre ellas se incluyen la manipulación de instrucciones (inyección de prompts), el envenenamiento del contexto mediante contenido recuperado, la exfiltración de datos a través del contenido generado, el abuso de la autoridad delegada en sistemas con acceso a herramientas y los ataques de degradación que socavan la fiabilidad en lugar de la confidencialidad. Por ejemplo, ¿de cuántas formas distintas podría una IA codificar u ocultar un número de la Seguridad Social estadounidense? Es más, ¿de cuántas maneras se podría engañar a una IA para que revelara dicha información, especialmente cuando se trata de sistemas a los que se puede pedir que interpreten el papel de la persona cuyos datos de identificación personal se están extrayendo?

Estos patrones de amenazas están documentados en marcos y metodologías de pruebas estandarizados elaborados por organizaciones independientes de reconocido prestigio. Estos marcos proporcionan taxonomías estructuradas de vulnerabilidades específicas de la IA que las empresas deben comprender y abordar.

Las áreas de capacidad que realmente importan

Al evaluar soluciones de seguridad de IA para escenarios de implantación empresarial, conviene centrarse en un número reducido de áreas de capacidad directamente relacionadas con riesgos reales. Estas capacidades reflejan cómo se utilizan los sistemas de IA en producción y cómo se producen los fallos en la práctica, y deben funcionar como capas integradas, no como controles independientes.

Los modelos de IA no pueden aplicar de forma fiable y por sí solos los límites de seguridad de una empresa; por diseño, tratan las entradas como instrucciones y carecen de una semántica nativa y auditable de control de acceso. Las defensas de una sola capa generan brechas explotables: una sólida integridad de las entradas sin validación de las salidas permite la exfiltración indirecta de datos mediante el envenenamiento de RAG; el filtrado de las salidas sin observabilidad impide detectar desviaciones de las políticas; y los controles de agentes sin resiliencia del sistema fallan en condiciones de estrés. Las organizaciones que implementan estas capacidades de forma aislada sufren fallos en cascada cuando los atacantes eluden una capa y aprovechan la ausencia de defensas posteriores. Las arquitecturas maduras de seguridad de la IA tratan estas capacidades como componentes interdependientes de un sistema de defensa unificado.

Estas capacidades también se corresponden de forma natural con cuestiones de gobernanza y permiten responder a preguntas como: ¿qué está permitido?, ¿qué está prohibido?, ¿qué se supervisa?, ¿qué se registra? y ¿qué puede defenderse a posteriori?

Integridad de las entradas y control de instrucciones

Los sistemas de IA son especialmente sensibles a las instrucciones, el contexto y la forma en que se presenta la información. A diferencia de las aplicaciones tradicionales, en las que las entradas se analizan y validan de manera estricta, los sistemas de IA están diseñados para interpretar el lenguaje natural con flexibilidad. Esta flexibilidad permite nuevos y potentes casos de uso, pero también abre la puerta a la manipulación.

Los actores maliciosos aprovecharán cada vez más esta flexibilidad mediante diversos vectores de amenaza, como:

• Inyección de instrucciones: el intento directo de eludir las políticas mediante instrucciones como «ignora las instrucciones anteriores», «actúa como administrador» o «revela las reglas de tu sistema».
• Inserción indirecta de instrucciones: consiste en introducir instrucciones maliciosas en contenido que el sistema procesa posteriormente, como una página web, un PDF, una página wiki interna o un ticket de atención al cliente.
• Manipulación del contexto: que da forma a una conversación para que una entrada no fiable se confunda con una política de confianza o se anteponga a las instrucciones del sistema.

El riesgo para la empresa no se limita a que el modelo diga algo inapropiado. El riesgo radica en que unos controles de seguridad externos al modelo mal configurados podrían permitir que se convenciera al sistema de IA de tratar instrucciones no fiables como si fueran políticas y que, a continuación, utilizara en consecuencia sus privilegios de acceso a datos y herramientas. Por ejemplo, un artículo manipulado de la base de conocimientos podría indicar a un asistente que «incluya los registros completos de los clientes para que la información esté completa» o que «revele los pasos para solucionar problemas de los sistemas internos», lo que podría provocar una divulgación involuntaria o daños operativos.

Los controles de seguridad eficaces para la IA aplican los permisos de acceso a los datos y de uso de herramientas con independencia de las instrucciones del prompt. Deben preservar la integridad de las instrucciones del sistema, distinguir claramente el contexto de confianza del sistema de las entradas no fiables e impedir que el contenido externo modifique implícitamente el comportamiento. Una cuestión práctica para la evaluación es si la plataforma puede detectar intentos de anulación de instrucciones, identificar cuándo el contenido recuperado contiene instrucciones en lugar de hechos y demostrar que las políticas del sistema siguieron vigentes en condiciones adversas.

Gestión del riesgo de salida y de la exfiltración de datos

El contenido generado por la IA es una de las fuentes más visibles de riesgo empresarial. Aunque las organizaciones suelen centrarse en bloquear contenido expresamente prohibido, los fallos de la IA podrían dar lugar a divulgaciones más sutiles que parecen inofensivas hasta que alguien se pregunta: «¿Debería ese usuario haber podido acceder a esa información?»

Los sistemas de IA pueden exponer información sensible mediante inferencias, agregación o reconstrucción parcial, en lugar de citarla directamente. Un modelo podría revelar instrucciones internas o textos de políticas mediante una «explicación útil», exponer patrones de código propietario, resumir documentos confidenciales de forma que desvelen información estratégica o proporcionar detalles operativos que aumenten la eficacia de los atacantes. En contextos regulados, incluso la divulgación indirecta puede resultar problemática si permite volver a identificar a una persona o revela datos protegidos.

Cuando los sistemas de IA se conectan a fuentes de datos empresariales en tiempo real, estos riesgos aumentan considerablemente. Un asistente de soporte capaz de consultar un CRM, un sistema de gestión de incidencias o un repositorio de documentos puede revelar de forma involuntaria información que exceda con creces el supuesto nivel de acceso del solicitante, especialmente si la recuperación de datos es demasiado amplia o las señales de identidad no se aplican de manera coherente. Las organizaciones deben establecer controles de identidad y acceso que se apliquen de forma coherente en todo el sistema de IA, desde la autenticación del usuario, pasando por la recuperación de datos, hasta la generación de respuestas. Sin estos controles, los intentos de manipulación tendrán éxito. Incluso en organizaciones con controles de acceso sólidos, la IA puede difuminar los límites al combinar múltiples fuentes en una única respuesta narrativa.

La gestión de los riesgos asociados a los resultados generados requiere algo más que un simple filtrado por palabras clave. Los controles deben comprender qué datos se están exponiendo, por qué son sensibles y en qué condiciones es aceptable divulgarlos. Las empresas deben plantearse si los controles funcionan con el nivel de granularidad adecuado (categorías, niveles de sensibilidad, jurisdicciones), si las políticas tienen en cuenta los roles y si el sistema ofrece explicaciones justificables cuando se bloquean o modifican los resultados. Desde el punto de vista de la gobernanza, el requisito es poder demostrar que existen controles sobre los datos sensibles y que estos funcionan de manera coherente.

Resiliencia y robustez del sistema

No todos los fallos de la IA son espectaculares. Algunos de los más perjudiciales se producen de forma silenciosa, a medida que los sistemas se degradan bajo presión. Las sesiones prolongadas, las entradas mal formadas (incluidas aquellas cuyo tamaño se hace desmesuradamente grande), las consultas repetidas o las tareas inusualmente complejas pueden menoscabar la coherencia en la aplicación de las medidas sin provocar una interrupción evidente. En estas situaciones, el sistema sigue funcionando, pero puede hacerlo de forma insegura o con un rendimiento reducido.

Los sistemas degradados suelen fallar de forma abierta en lugar de cerrada. Un clasificador de seguridad puede agotar el tiempo de espera y ser omitido; un paso de recuperación puede devolver resultados más amplios de lo previsto; los límites de frecuencia pueden aplicarse de forma incoherente; o la invocación de herramientas puede continuar incluso cuando falla una comprobación de políticas. En los sistemas agénticos que encadenan varios pasos, pequeñas degradaciones pueden propagarse y dar lugar a acciones inseguras en etapas posteriores.

La resiliencia no es solo una cualidad técnica, sino también una cuestión de gobernanza. Un control que solo funciona en condiciones ideales no es realmente un control. Los equipos de seguridad deben evaluar cómo se comportan los controles de seguridad de la IA en condiciones no ideales y si los fallos se detectan a tiempo y se gestionan de forma predecible. Esto incluye realizar pruebas de estrés ante picos de volumen, patrones de consultas maliciosas,

interacciones de contexto largo y fallos de dependencias, como la latencia del proveedor de identidades, las interrupciones en la recuperación de información o los errores de los conectores.

Una plataforma de seguridad de IA madura debe ayudar a las organizaciones a comprender y gestionar los modos de fallo, no solo los modos de ataque. Esto incluye configuraciones predeterminadas seguras, una gestión clara de los errores, un comportamiento coherente de los mecanismos de protección cuando se degradan los subsistemas y telemetría operativa que permita a los equipos de seguridad detectar dicha degradación antes de que se convierta en un problema empresarial.

Precisión de las políticas y gestión de las compensaciones

Los controles de seguridad que son técnicamente eficaces, pero que generan disrupciones operativas, rara vez son sostenibles. En los entornos de IA, esta tensión es especialmente acusada, ya que los límites de las políticas suelen depender del contexto en lugar de ser binarios. Por ejemplo, una misma solicitud puede ser legítima para un rol y estar prohibida para otro, y una respuesta puede ser aceptable si se basa en fuentes públicas, pero inaceptable si se basa en datos internos. En última instancia, la política «adecuada» es una decisión de gobernanza, no una cuestión meramente técnica.

Los controles excesivamente restrictivos pueden obstaculizar actividades empresariales legítimas y fomentar el uso de sistemas de «IA en la sombra», mientras que una aplicación insuficiente expone a las organizaciones a riesgos legales y reputacionales. Lograr el equilibrio adecuado no es solo una cuestión de ajuste, sino también una decisión de gobernanza basada en la tolerancia al riesgo, el contexto empresarial y los requisitos de rendición de cuentas.

Las plataformas de seguridad de IA deben ofrecer visibilidad sobre los falsos positivos y los falsos negativos, explicar por qué se tomaron determinadas decisiones y permitir que las políticas evolucionen mediante un control de cambios estructurado. Si un sistema bloquea una solicitud, las organizaciones necesitan saber si se bloqueó porque contenía datos sensibles, porque parecía un intento de anular las instrucciones, porque el usuario carecía de autorización o porque coincidía con un patrón de alto riesgo. Sin esa claridad, los equipos no pueden ajustar los controles de forma responsable ni justificar los resultados ante la dirección o los auditores externos.

Desde la perspectiva de GRC, la precisión de las políticas también demuestra el grado de madurez. Los controles opacos, impredecibles o imposibles de ajustar se convierten en una fuente de riesgo, ya que no pueden auditarse ni justificarse eficazmente. Por el contrario, los controles ajustables que carecen de rigor pueden debilitarse mediante excepciones puntuales. Las plataformas maduras permiten una gestión estructurada de las políticas, con funciones como el control de versiones, las aprobaciones, la aplicación basada en roles y la elaboración de informes que permiten a la dirección comprobar si el riesgo se reduce con el tiempo.

Verificación determinista para decisiones críticas de seguridad

Las medidas de protección probabilísticas basadas en IA detectan eficazmente la mayoría de las infracciones de las políticas, pero determinadas decisiones críticas para la seguridad requieren certeza matemática en lugar de confianza estadística. Las políticas de autorización, la validación del cumplimiento normativo y los controles de infraestructuras críticas para la seguridad no pueden tolerar la incertidumbre inherente a los sistemas de aprendizaje automático.

El razonamiento automatizado —mediante técnicas de verificación formal— complementa las medidas de protección probabilísticas al ofrecer una corrección demostrable en puntos de control específicos. A diferencia de la detección basada en aprendizaje automático, que asigna puntuaciones de confianza, el razonamiento automatizado demuestra matemáticamente si una política se cumple en todas las condiciones posibles.

La verificación determinista es importante en las siguientes situaciones:

• Decisiones de autorización: Verificar que las políticas de control de acceso se apliquen correctamente a todos los roles de usuario y clasificaciones de datos
• Validación del cumplimiento: Demostrar que se cumplen los requisitos normativos (residencia de datos del RGPD y restricciones de acceso de la HIPAA) antes de la implementación
• Sistemas críticos para la seguridad: Garantizar que los sistemas de IA que controlan infraestructuras físicas o transacciones financieras no puedan infringir las restricciones de seguridad

Las organizaciones deben determinar qué controles requieren demostración y cuáles detección: el filtrado de contenidos y las medidas de protección generales se benefician de la flexibilidad del aprendizaje automático, mientras que la aplicación de autorizaciones y la validación del cumplimiento normativo requieren la certeza de la verificación formal. Las plataformas maduras de seguridad de IA integran ambos enfoques: detección probabilística para ofrecer una amplia cobertura frente a amenazas y verificación determinista para los controles que nunca deben fallar.

Las organizaciones deben determinar qué controles requieren demostración y cuáles detección: el filtrado de contenidos y las medidas de protección generales se benefician de la flexibilidad del aprendizaje automático; la aplicación de las autorizaciones y la validación del cumplimiento normativo requieren la certeza de la verificación formal. Las plataformas maduras de seguridad de IA integran ambos enfoques: detección probabilística para ofrecer una amplia cobertura frente a amenazas y verificación determinista para los controles que nunca deben fallar.

IA agéntica y autoridad delegada

A medida que los sistemas de IA pasan de ser asistentes pasivos a participantes activos en los flujos de trabajo de las organizaciones, surge una nueva clase de riesgo: la autoridad delegada. Los sistemas de IA agéntica pueden utilizar herramientas externas, realizar llamadas a API, modificar registros o activar flujos de trabajo de forma autónoma. En la práctica, actúan como empleados digitales con amplios permisos de acceso y una gran velocidad de ejecución.

Esto plantea cuestiones de gobernanza conocidas en un contexto desconocido. ¿Qué acciones está autorizado a realizar el sistema y en qué condiciones? ¿Cómo se restringen los permisos? ¿Cómo se evita una escalada? ¿Cómo se mantiene la separación de funciones? Sin límites claros a la autonomía, los pequeños errores pueden propagarse rápidamente entre sistemas. Un modelo que malinterprete la intención de un usuario podría enviar un correo electrónico a los destinatarios equivocados, crear un ticket que contenga información confidencial, aprobar una acción que debería haber requerido una revisión o modificar un registro de forma que desencadene consecuencias operativas en procesos posteriores.

Los controles eficaces deben aplicar el principio de mínimo privilegio, impedir el uso no autorizado de herramientas y garantizar la rendición de cuentas. Esto incluye: gestionar explícitamente los permisos de las herramientas; restringir las acciones de alto impacto (especialmente las que modifican el estado del sistema); exigir confirmación para las acciones de impacto moderado (como redactar comunicaciones externas sin enviarlas, proponer cambios de configuración sin aplicarlos o preparar consultas de datos sin ejecutarlas); y exigir la aprobación humana para operaciones sensibles (como modificar registros financieros, cambiar permisos de acceso, ejecutar comandos de infraestructura con privilegios elevados, iniciar comunicaciones externas en nombre de la organización o aprobar transacciones). También incluye detectar cadenas de acciones inseguras, en las que una secuencia de acciones permitidas individualmente produce un resultado que nunca debería darse sin supervisión.

Una forma práctica de evaluar esta capacidad consiste en preguntarse si el sistema puede aplicar una autonomía gradual, permitiendo quizá libremente las acciones inocuas, exigiendo confirmación para las acciones de impacto moderado y prohibiendo o derivando a una instancia superior las acciones de alto impacto. Los responsables de gobernanza deben abordar la IA agéntica como un problema de delegación, no como un problema del modelo. Si no concedería a un empleado júnior autoridad unilateral para realizar una determinada acción, tampoco debería concedérsela a un agente de IA.

Observabilidad, auditoría y análisis forense

Cuando algo falla en un sistema de IA, la cuestión más importante no es simplemente qué ha ocurrido, sino si la organización puede demostrar claramente cómo y por qué ha ocurrido. En entornos empresariales, la capacidad de aportar pruebas sólidas de un problema marca la diferencia entre un incidente que puede explicarse y cerrarse y otro que se convierte en un problema de gobernanza prolongado.

Sin una visibilidad suficiente, los equipos de seguridad deben basarse en registros parciales, suposiciones e intuición a la hora de responder a incidentes. Los esfuerzos de gobernanza se ven perjudicados porque las políticas y los controles no pueden demostrarse, defenderse ni mejorarse si su comportamiento no puede examinarse y medirse a posteriori. Esto es especialmente cierto en el caso de los sistemas de IA, donde el no determinismo y el contexto pueden hacer que los resultados sean difíciles, cuando no imposibles, de reproducir.

Las plataformas de seguridad de IA deben proporcionar registros detallados, una atribución clara y alertas oportunas, y las empresas deben poder reconstruir de principio a fin las interacciones con la IA: la entrada recibida; el contexto de identidad y autorización aplicado; el contenido recuperado (cuando corresponda); las instrucciones del sistema vigentes; la salida del modelo; y cualquier herramienta o acción posterior que se haya activado. Cuando intervenga un control —ya sea para bloquear una solicitud, modificar una salida o impedir una acción—, debe registrar el motivo y la política en virtud de la cual lo hace.

Desde la perspectiva de la gobernanza, el riesgo y el cumplimiento (GRC), la capacidad de auditoría es esencial. Se espera que las organizaciones demuestren que existían controles, que estos funcionaban según lo previsto, que las excepciones se gestionaban adecuadamente y que se realizó un seguimiento de los cambios a lo largo del tiempo.

Por qué la seguridad de la IA sin GRC fracasará

Los sistemas de IA operan a velocidades y escalas que superan los procesos de gobernanza tradicionales. Cuando se produzcan fallos, las organizaciones serán evaluadas por su capacidad para demostrar control, intencionalidad y rendición de cuentas. En ese entorno, la seguridad de la IA desvinculada de la gobernanza, la gestión de riesgos y el cumplimiento normativo es frágil por definición.

Los reguladores y los consejos de administración necesitarán saber si se identificaron los riesgos, si los controles fueron proporcionales y si las decisiones pueden explicarse. Los equipos de seguridad que no puedan aportar pruebas tendrán dificultades para defender los resultados, independientemente de sus intenciones.

Las funciones de gobernanza, riesgo y cumplimiento (GRC) desempeñan un papel fundamental a la hora de convertir los controles técnicos en prácticas empresariales justificables. Esto incluye definir el uso aceptable, documentar las decisiones sobre riesgos, validar la eficacia de los controles y garantizar que los cambios se registren, revisen y puedan auditarse a lo largo del tiempo.

Conclusión: gobernar la IA a escala empresarial

La IA ya no es una tecnología periférica; se está convirtiendo en una infraestructura esencial que determina cómo operan, compiten y toman decisiones las empresas.

A medida que los sistemas de IA se integran en procesos críticos para el negocio, las empresas deben pasar de forma deliberada de la experimentación a la rendición de cuentas. Para ello, es necesario definir expectativas más claras para los proveedores de seguridad de IA, como la transparencia sobre las limitaciones, el apoyo a la validación independiente y el compromiso con la mejora continua, en lugar de ofrecer garantías puntuales.

La rendición de cuentas también requiere coordinación interna. Los responsables de seguridad, TI, asuntos jurídicos, riesgos y negocio deben acordar la tolerancia al riesgo, las vías de escalado y las estrategias de respuesta antes de que se produzcan incidentes. La seguridad de la IA no es responsabilidad de un único equipo, sino una responsabilidad compartida por toda la empresa.

Las organizaciones que triunfen con la IA serán aquellas que combinen la innovación con la disciplina. La innovación por sí sola no genera una ventaja duradera; el éxito sostenible se consigue comprendiendo, monitorizando y gestionando el riesgo a medida que los sistemas crecen. Una seguridad eficaz de la IA no consiste en eliminar la incertidumbre, sino en gestionarla de forma transparente, responsable y capaz de resistir un examen riguroso.

© 2026 NSS Labs. Todos los derechos reservados. Los Términos de servicio y la Política de derechos de autor y citas de NSS Labs pueden consultarse aquí: https://nsslabs.com/terms-of-service/