Puntos clave
- La IA agentiva plantea nuevos riesgos de seguridad porque planifica, recuerda y actúa en distintos sistemas, en lugar de limitarse a un único ciclo de pregunta-respuesta.
- Los datos de entrenamiento «envenenados» pueden influir de forma imperceptible en el comportamiento del modelo a gran escala, incluso cuando el modelo parece seguir funcionando con normalidad en las pruebas estándar.
- Las bases de datos de vectores comprometidas pueden influir en las decisiones de los agentes al alterar el contexto en el que se basa el modelo, haciendo que un comportamiento incorrecto parezca legítimo.
- La identidad de los agentes no controlados plantea un problema de control de acceso a la velocidad de las máquinas que los sistemas de identidad tradicionales, centrados en las personas, no están diseñados para gestionar.
- Las decisiones en cadena basadas en un estado erróneo pueden propagar errores a través de varios agentes y flujos de trabajo, lo que complica mucho más la reversión y la recuperación.
Las herramientas, los controles y las políticas de gobernanza con las que cuentan la mayoría de las empresas se diseñaron para sistemas que responden a preguntas: herramientas de recuperación, copilotos, asistentes generativos. Sistemas que responden a una solicitud y se detienen. Cuando algo fallaba, el fallo era aislado. Se corregía la solicitud, se ajustaba la configuración y se seguía adelante.
La IA agentiva no funciona así. Estos sistemas planifican, recuerdan y ejecutan acciones en toda la empresa sin necesidad de instrucciones humanas paso a paso. Mantienen el estado. Se coordinan con otros agentes. Actúan en los sistemas de producción: escriben en bases de datos, activan flujos de trabajo y toman decisiones a la velocidad de una máquina. Ese cambio arquitectónico introduce cuatro vectores de amenaza para los que los marcos de seguridad actuales nunca se diseñaron. Si tu estrategia de gobernanza de la IA no los tiene en cuenta, es probable que tengas una vulnerabilidad que quizá ni siquiera puedas detectar.
1. Datos de entrenamiento contaminados
Un sistema de IA es tan fiable como los datos con los que se ha entrenado. Esa afirmación siempre ha sido cierta. Lo que ha cambiado es la superficie de ataque.
En las implementaciones de IA con agentes, los flujos de entrenamiento son más amplios, más complejos y, con frecuencia, se ensamblan a partir de múltiples fuentes: datos internos, fuentes de terceros, conjuntos de datos proporcionados por proveedores. Cada eslabón de esa cadena es un punto de inyección potencial. Un actor malintencionado que pueda influir en los datos de entrenamiento —mediante el compromiso de la cadena de suministro, el acceso de personal interno o la contaminación de una fuente de datos compartida— puede moldear el comportamiento del modelo a gran escala. Lo que hace que esto sea especialmente peligroso es que los modelos manipulados suelen funcionar con normalidad en las pruebas de rendimiento estándar. La manipulación puede ser muy precisa: diseñada para generar resultados específicos en contextos concretos, mientras que en el resto de casos se comporta correctamente.
Para cuando el problema sale a la luz en producción, el modelo ya lleva semanas o meses en uso, y rastrear el origen de la contaminación requiere precisamente ese tipo de trazabilidad relacional de los datos de la que carecen la mayoría de las organizaciones. La pregunta que hay que plantearse es: ¿puedes presentar un registro completo y verificable de los datos con los que se entrenaron tus modelos, en un momento concreto?
2. Bases de datos vectoriales comprometidas
Las bases de datos vectoriales constituyen la capa de memoria de los sistemas basados en agentes. Antes de actuar, un agente consulta un almacén vectorial para recuperar el contexto relevante —interacciones pasadas, conocimientos del dominio, datos de referencia— que determina cuál será su siguiente paso. La mayoría de los equipos de seguridad no abordan las bases de datos vectoriales de la misma manera que lo hacen con otros almacenes de datos confidenciales. Y deberían hacerlo. Una base de datos vectorial comprometida no solo devuelve respuestas erróneas. También influye en las decisiones posteriores. Las incrustaciones inyectadas —contenido malicioso insertado en el almacén de vectores— pueden redirigir el comportamiento del agente de formas que parecen totalmente legítimas desde fuera.
Un agente al que se le pide que apruebe una transacción recupera un contexto que replantea sutilmente los criterios de aprobación. Un agente que gestiona las comunicaciones con los clientes extrae un contexto que orienta las respuestas en la dirección preferida por el atacante. La acción parece correcta. El razonamiento parece sólido. Pero el contexto subyacente ha sido manipulado.
Este vector de ataque es especialmente difícil de detectar porque opera por debajo de la capa del modelo. La supervisión estándar del modelo no lo detectará. El modelo se comporta exactamente como se le ha entrenado; es el contexto a partir del cual razona el que ha sido corrompido. La pregunta que debes hacerte es: ¿Se trata tu base de datos vectorial como un activo de datos sensible y regulado, con controles de acceso, supervisión de la integridad y registros de auditoría comparables a los de tus bases de datos de producción más críticas?
3. Identidad de agente no regulado
En una arquitectura multiagente, los agentes no solo interactúan con los datos, sino que también interactúan entre sí. Generan subagentes, delegan tareas, solicitan resultados y sintetizan los resultados de agentes con los que nunca han estado conectados explícitamente. Para ello, se autentifican, presentan sus credenciales y establecen una relación de confianza.
La identidad del agente es la capa de control de acceso para la empresa autónoma y constituye una laguna que ni los proveedores de seguridad de identidad ni los proveedores de identidad (IDP) logran cubrir. Sus marcos de gobernanza están diseñados para la identidad humana.
Las identidades de los agentes creadas siguiendo esas mismas reglas parecen totalmente legítimas: se han configurado correctamente y cumplen con la política. El IDP no falla; simplemente no dispone de un marco para determinar si un agente está actuando fuera del contexto para el que fue creado, si se le ha concedido un nivel superior sin que se note o si está coordinando acciones donde no debería.
Esta vulnerabilidad es cualitativamente diferente del robo tradicional de credenciales. Cuando a un usuario humano le roban las credenciales, el atacante actúa dentro de los permisos de ese usuario, a la velocidad de una persona. Cuando se compromete la identidad de un agente, el atacante consigue acceso a la capa de toma de decisiones autónoma: la capacidad de activar flujos de trabajo, aprobar acciones, coordinarse con otros agentes y extraer datos a la velocidad de una máquina, a gran escala, a través de canales que parecen totalmente normales.
Los fallos en la capa de identidad también se encuentran entre los más difíciles de detectar a posteriori. Las acciones de los agentes realizadas bajo una identidad comprometida no parecen anómalas: parecen un comportamiento legítimo de los agentes. Y, dado que son generadas por un sistema en lugar de por un humano, el volumen puede ser enorme antes de que nadie se dé cuenta.
Recovery agrava el problema. La mayoría de los manuales de Recovery de IA se centran en restaurar datos: conjuntos de entrenamiento, pesos de modelos, configuraciones de flujos de trabajo. La identidad rara vez figura en la lista. Un sistema recuperado con datos limpios pero con configuraciones de identidad desalineadas no está realmente recuperado. Es un sistema limpio con una capa de acceso contaminada. La pregunta que hay que plantearse es: ¿Se gestiona la identidad de los agentes con el mismo rigor que la identidad de las personas —con gestión del ciclo de vida, acceso con privilegios mínimos e inclusión en los planes de recuperación?
4. Decisiones en cadena basadas en una situación errónea
Los tres primeros vectores de ataque son puntuales. Este es sistémico y, en muchos sentidos, puede ser el más difícil de contener. Las arquitecturas multiagente están diseñadas para la coordinación. Los agentes comparten contexto, se pasan resultados entre sí y se basan en el trabajo de los demás. Esa coordinación es lo que los hace poderosos. También es lo que hace que los fallos se propaguen.
Un agente que opera con memoria corrupta no falla de forma aislada. Genera resultados —decisiones, acciones, datos— que otros agentes utilizan. Esos agentes, a su vez, generan sus propios resultados. Para cuando la corrupción original se manifiesta de forma observable, el estado defectuoso puede haber afectado a docenas de procesos posteriores, a través de múltiples agentes, sin que exista una ruta clara para revertir los cambios.
Esto es lo que hace que la brecha de contexto sea tan importante. En cualquier momento dado, tu sistema de IA está formado por una versión del modelo, un conjunto de datos de entrenamiento, un almacén de artefactos, una configuración del proceso y un conjunto de interacciones de agentes activos; todos estos elementos deben reflejar el mismo estado operativo para constituir un sistema fiable y recuperable. Cuando no es así, no se trata simplemente de un error. Tienes un sistema que es coherente en sus partes, pero incoherente en su conjunto. Cada herramienta individual puede confirmar su propio fragmento. Ninguna puede confirmar que las piezas encajen entre sí. Ese no es un problema de monitorización que se pueda resolver añadiendo otra herramienta. Se trata de una laguna estructural, y la única forma de subsanarla es con un sistema que registre el estado de la IA de forma relacional: qué se estaba ejecutando, con qué datos, con qué configuración y en qué momento.
La pregunta que debes hacerte es: si tu infraestructura de IA se viera comprometida hoy mismo, ¿serías capaz de identificar exactamente en qué estado se encontraba cada componente antes del incidente y demostrarlo?
¿Qué significa esto para tu estrategia de seguridad?
Cada uno de estos cuatro vectores requiere una respuesta defensiva diferente. Pero todos tienen una consecuencia en común: los marcos de gobernanza y resiliencia diseñados para la era anterior de la IA no cubren los modos de fallo de la era de los agentes. Para conseguir una IA con capacidad de acción, tienes que ampliar tu marco de trabajo en tres direcciones:
- Más a fondo, en las capas de datos e identidad que se encuentran por debajo del modelo.
- Más amplio, para abarcar las interacciones entre agentes que el sistema de supervisión actual no detecta.
- Desde el punto de vista relacional, para reflejar no solo el estado de cada componente, sino también cómo encajan entre sí en un momento dado.
Este último requisito es el que la mayoría de las organizaciones aún no han abordado. Y es el que determinará si, cuando algo vaya mal, dispones de un sistema capaz de recuperarse o de un montón de informes que parecen precisos pero que describen algo que ya no existe. Lee «El punto ciego agencial: por qué la resiliencia de la IA exige un sistema de registro» para descubrir por qué necesitas un SOR que te ayude a proteger la coherencia y la precisión de tus datos de IA.
Preguntas frecuentes
P: ¿Por qué los sistemas de IA con capacidad de acción son más arriesgados que las herramientas tradicionales de IA generativa?
R: Los sistemas basados en agentes hacen mucho más que responder a indicaciones. Mantienen el estado, se coordinan con otros agentes y llevan a cabo acciones en entornos de producción, lo que amplía la superficie de ataque mucho más allá de la simple manipulación de indicaciones.
P: ¿Por qué es tan difícil detectar los datos de entrenamiento «envenenados»?
R: La manipulación puede ser muy selectiva, afectando solo a situaciones concretas y dejando intactos los puntos de referencia normales. Eso significa que un modelo puede parecer que funciona bien hasta que el comportamiento malicioso se manifiesta en el uso real.
P: ¿Cómo puede una base de datos vectorial convertirse en un problema de seguridad?
R: Una base de datos vectorial define el contexto que utiliza un agente antes de actuar. Si ese contexto se altera, el agente puede tomar decisiones que, a primera vista, parezcan razonables, pero que en realidad están guiadas por datos maliciosos.
P: ¿Por qué la identidad de un agente es diferente de la identidad de una persona?
R: La identidad de un agente está ligada a las acciones autónomas, la delegación y la ejecución a la velocidad de una máquina. La gestión tradicional de identidades está pensada para las personas, por lo que a menudo no detecta si un agente está actuando fuera del contexto previsto.
P: ¿Por qué la propagación en cascada de estados erróneos es un problema tan grave en los sistemas multiagente?
R: En cuanto un agente procesa datos erróneos, ese error puede propagarse a los agentes y flujos de trabajo posteriores. El resultado no es solo una mala decisión, sino una cadena de fallos encadenados.
P: ¿Cómo pueden las organizaciones mejorar la seguridad de la IA?
R: Ampliando la gobernanza hasta las capas de datos e identidad, supervisando las interacciones entre agentes y realizando un seguimiento relacional del estado de la IA para que puedan reconstruir lo que ocurrió durante un incidente.
Michael Thelander es director sénior de marketing de productos en Commvault.
Artículos relacionados
-
- Proteger la IA con una gobernanza unificada del acceso a los datos
- Datos más inteligentes, IA más sostenible
- Data Activate: Aprovechar el potencial de los datos fiables para la innovación en IA
- Los agentes de IA están por todas partes. ¿Sabes qué están haciendo?
- De la experimentación a la puesta en marcha: cómo crear agentes de IA en los que realmente puedas confiar
