Puntos clave
- Los sistemas de IA agentiva tienen estado y funcionan de forma continua, lo que hace que los modelos de recuperación tradicionales resulten insuficientes.
- La capa de memoria (bases de datos vectoriales y almacenamiento de contexto) es una superficie de ataque clave, pero a la que no se presta suficiente atención.
- Los flujos de trabajo de toma de decisiones en tiempo de ejecución pueden modificarse sin que se activen las alertas de seguridad habituales.
- Las lagunas en la observabilidad de las interacciones entre agentes hacen que la mayoría de las organizaciones no tengan una visión completa de los riesgos.
- Para que la recuperación sea efectiva, se necesita un registro unificado y sincronizado de todas las capas del sistema que permita volver a un estado fiable.
La mayoría de las empresas que se adentran en la era de la IA agente están gestionando la resiliencia con un modelo mental erróneo, y los datos lo confirman: solo 1 de cada 5 empresas cuenta con un modelo maduro para gestionar los agentes de IA autónomos. Se plantean la IA igual que se plantean las aplicaciones: como algo discreto, sin estado y recuperable restaurando datos limpios en un entorno limpio.
La IA agentiva no funciona así. Estos sistemas tienen estado, operan de forma continua y presentan una arquitectura por capas que genera modos de fallo para los que la mayoría de los marcos de seguridad y resiliencia no fueron diseñados. La brecha no está en las herramientas. Está en comprender qué es lo que realmente se está ejecutando —y qué debe significar «Recovery» para los sistemas construidos de esta manera—.
Hay cuatro capas arquitectónicas que definen el problema. Cada una es distinta. Cada una está insuficientemente protegida. Y, en conjunto, explican por qué un sistema de IA agentiva puede parecer recuperable sin dejar de estar fundamentalmente comprometido.
Capa 1: Memoria del agente – La superficie de ataque que no estás vigilando
Las aplicaciones empresariales tradicionales no recuerdan nada entre sesiones. La IA agentiva sí lo hace. La capa de memoria —compuesta principalmente por bases de datos vectoriales que almacenan representaciones, pero también el estado de la sesión y el contexto recuperado— es lo que aporta continuidad a los agentes a lo largo de las interacciones. Es lo que permite a un agente retomar el hilo donde lo dejó, basarse en el contexto anterior y construir una visión coherente de un flujo de trabajo complejo a lo largo del tiempo.
Además, es una de las superficies de ataque más importantes en la infraestructura empresarial moderna, y una de las menos supervisadas. El vector de ataque es lo suficientemente sutil como para eludir la mayoría de las herramientas de seguridad convencionales. Un adversario capaz de influir en lo que se escribe en una base de datos vectorial puede moldear lo que el agente considera cierto. Las representaciones inyectadas o manipuladas no tienen por qué parecer maliciosas: deben parecer fiables.
Si se compromete el almacenamiento en memoria, se puede alterar el comportamiento del agente, filtrar datos a través de sus acciones o hacer que el agente tome decisiones que parezcan legítimas, pero que en realidad sirvan a los objetivos del atacante. Para nada de esto es necesario alterar el modelo en sí. El problema de la detección se ve agravado por el volumen y la velocidad de las escrituras en las bases de datos vectoriales en implementaciones activas de agentes. Las herramientas de detección de anomalías diseñadas para datos estructurados no se adaptan bien al ámbito de las representaciones vectoriales. La señal está ahí, pero la mayoría de las organizaciones no están preparadas para interpretarla.
Lo que requiere la resiliencia en este caso: una supervisión continua de la integridad de las bases de datos vectoriales, no solo copias de seguridad. Incrustaciones con control de versiones y una cadena de custodia demostrable. La capacidad de identificar, en cualquier momento, exactamente qué contenía la capa de memoria, y de restaurarla a un estado limpio y verificado, no solo a uno reciente.
Nivel 2: Control en tiempo de ejecución: cuando el flujo de trabajo es la amenaza
La IA agencial no ejecuta guiones fijos. Planifica. Durante la ejecución, un agente recibe un objetivo, determina los pasos necesarios para alcanzarlo, selecciona las herramientas que necesita y lo lleva a cabo, a menudo creando subagentes para gestionar flujos de trabajo paralelos. El flujo de trabajo es dinámico, se construye sobre la marcha y suele ser de larga duración.
Esto es lo que hace que la IA con capacidad de acción sea realmente útil. Y también es lo que hace que sea realmente difícil protegerla. En un entorno de automatización convencional, un flujo de trabajo predefinido tiene límites. Hace lo que se le ha configurado y se detiene. Un flujo de trabajo «agente» es diferente: se adapta.
Si un atacante logra influir en la capa de planificación —ya sea mediante una indicación maliciosa, una respuesta manipulada de una herramienta o un modelo de planificación corrompido—, el agente perseguirá el objetivo del atacante utilizando cualquier herramienta y acceso legítimos de los que disponga. Parecerá un funcionamiento normal. Los registros, en la medida en que existan, mostrarán llamadas autorizadas a las herramientas. Pensemos en un agente de compras encargado de validar las facturas de los proveedores según los términos del contrato. En condiciones normales, comprueba los importes de las facturas, cruza los datos con los umbrales de aprobación y señala las excepciones para su revisión humana. Un atacante que pueda influir en la capa de planificación —mediante una respuesta manipulada de una herramienta procedente de la base de datos de contratos— no necesita intervenir directamente en la lógica de aprobación. Basta con que le pase al agente un registro de contrato con los umbrales modificados. El agente planifica correctamente a partir de datos corruptos. Cada llamada que realiza a una herramienta es legítima. Cada decisión a la que llega es errónea. Para cuando la anomalía sale a la luz en una conciliación financiera, el flujo de trabajo ya ha procesado semanas de facturas y el registro de auditoría no muestra más que acciones autorizadas.
El intervalo entre la intrusión y la detección en estos escenarios no se mide en segundos. Los flujos de trabajo basados en agentes operan de forma continua. Para cuando surgen resultados anómalos, es posible que el flujo de trabajo haya afectado a docenas de sistemas, tomado cientos de decisiones y dejado cambios en los entornos de producción que son difíciles de enumerar y aún más difíciles de revertir.
Lo que requiere la resiliencia en este caso: una supervisión en tiempo de ejecución que observe lo que los agentes están decidiendo, no solo lo que están haciendo. Mecanismos de intervención capaces de detener de forma limpia un flujo de trabajo en ejecución sin provocar fallos en cadena. Guiones de Recovery diseñados para procesos basados en agentes de larga duración, no solo para transacciones discretas.
Capa 3: Observabilidad de los agentes – La brecha en el registro de datos a la velocidad de las máquinas
La infraestructura de registro de las empresas se diseñó para operaciones a escala humana. Registra lo que hacen los sistemas, con un nivel de detalle y una latencia pensados para que los humanos puedan revisarlo. La IA basada en agentes funciona a una velocidad totalmente diferente.
En una implementación activa con múltiples agentes, estos generan subagentes, intercambian información entre sí, realizan llamadas a herramientas y sintetizan resultados —de forma continua, en paralelo y a una velocidad superior a la que las cadenas de registro convencionales fueron diseñadas para capturar—. Las interacciones más importantes para la seguridad —las comunicaciones entre agentes, los traspasos de contexto y las invocaciones de herramientas que traspasan los límites de confianza— son precisamente las que los marcos de monitorización actuales dejan más desatendidas.
Hoy en día, solo el 17 % supervisa de forma continua las interacciones entre agentes. El 83 % restante gestiona la IA basada en agentes a partir de una visión parcial: una que capta lo que hacen los agentes de forma aislada, pero que pasa por alto el nivel de interacción, donde se producen los incidentes de seguridad más graves.
Esta no es una brecha que se pueda resolver simplemente aumentando el volumen de registros. El problema no es la cantidad de datos que se recopilan, sino que las estructuras de datos y los requisitos de latencia de las interacciones de los agentes no encajan bien en los marcos de observabilidad diseñados para sistemas más lentos y estructurados. Para subsanar esta deficiencia se necesitan herramientas de observabilidad de agentes diseñadas específicamente para ello, o una adaptación significativa de la infraestructura existente.
Lo que requiere la resiliencia en este caso: visibilidad de extremo a extremo de las interacciones entre agentes, no solo de los resultados de cada agente individual. Arquitecturas de registro capaces de funcionar a la velocidad de los agentes sin perder eventos. La capacidad de reconstruir, a posteriori, la secuencia completa de decisiones e interacciones de los agentes para cualquier flujo de trabajo dado.
Capa 4: Coordinación entre múltiples agentes: dónde se esconden los fallos emergentes
El riesgo arquitectónicamente más novedoso de la IA agentiva no proviene de un único agente comprometido. Proviene de cómo los agentes dependen unos de otros, y de cómo los fallos se propagan a través de esas dependencias antes de que nadie se dé cuenta de que algo va mal. En una arquitectura multiagente, los agentes comparten contexto. Un agente coordinador transmite las instrucciones de una tarea a un subagente; el subagente devuelve un resultado que el coordinador incorpora a su siguiente decisión.
Si la salida del subagente está corrompida —ya sea por una capa de memoria comprometida, una respuesta manipulada de una herramienta o un modelo de planificación viciado—, el coordinador no tiene ninguna forma nativa de detectarlo. Considera que esa salida es fiable. La incorpora. Actúa en función de ella. Y transmite su propia salida, ahora comprometida, a las etapas siguientes.
Este es el modo de fallo emergente: una corrupción que se origina en una capa, se propaga a través de las interacciones entre agentes y se manifiesta como un resultado anómalo en un sistema situado a varios pasos de distancia de la vulneración original. Para cuando se hace visible, la cadena causal ya es larga y el alcance del impacto es considerable.
Imagina un proceso de inteligencia sobre amenazas en el que un agente de recopilación de datos recoge información de fuentes externas, un agente de clasificación la categoriza y le asigna una puntuación, y un coordinador integra esa inteligencia puntuada en recomendaciones sobre el estado de seguridad que se envían a los equipos de niveles inferiores. Si la capa de memoria del agente de recopilación de datos se ve comprometida —de forma sutil, mediante incrustaciones inyectadas que hacen que considere a ciertos actores maliciosos como de bajo riesgo—, el agente de clasificación recibe información que no tiene motivos para cuestionar. Clasifica con precisión en función de lo que se le proporciona. Clasifica con precisión en función de lo que se le proporciona.
El coordinador incorpora los resultados con confianza. Los equipos de seguridad de las fases posteriores restan prioridad a la categoría de amenaza relevante basándose en lo que parece un consenso coherente y procedente de múltiples fuentes. El fallo se originó en la capa 1. Se manifestó en la capa 4. Nada entre medias señaló una anomalía porque nada entre medias tenía visibilidad de toda la cadena.
Los marcos de gobernanza que la mayoría de las empresas aplican a la IA se diseñaron pensando en los resultados de los modelos, es decir, en lo que dice la IA. Los fallos de coordinación entre múltiples agentes no son fallos en los resultados de los modelos. Son fallos del sistema, que surgen de la capa de interacción entre los modelos, y requieren un tipo diferente de gobernanza: una que supervise y controle no solo el comportamiento de cada agente, sino también las relaciones de confianza entre ellos, la integridad del contexto a medida que pasa de uno a otro, y los derechos de acceso que regulan lo que cualquier agente puede solicitar a cualquier otro.
Lo que exige la resiliencia en este caso es una gestión de la identidad de los agentes que trate la confianza entre ellos como una cuestión de seguridad de primer orden. La verificación de la integridad del contexto a medida que traspasa los límites de los agentes. Políticas de gobernanza que abarquen el comportamiento de los agentes autónomos, y no solo los resultados de los modelos individuales.
El problema relacional que une a los cuatro
Estas cuatro capas tienen modos de fallo distintos, pero comparten una vulnerabilidad común: ninguna de ellas dispone de un registro compartido de cómo se relacionan entre sí en un momento concreto.
El registro de modelos sabe qué versión se está ejecutando. La base de datos vectorial sabe qué hay en la memoria. La capa de orquestación sabe qué flujo de trabajo está activo. El sistema de identidad sabe qué agentes tienen qué acceso. Cada uno puede confirmar su propia parte del panorama. Ninguno puede confirmar si esas partes encajan entre sí —si reflejan el mismo estado operativo, el mismo momento, la misma configuración fiable—.
Esa es la brecha de contexto. Y por eso la recuperación tras un ataque a una IA agentiva no es un problema de restauración de datos. Es un problema de coherencia, uno que requiere un registro unificado de las relaciones entre las capas, no solo de los propios componentes. Resuelve este problema antes de que se produzca un incidente, o tendrás que dedicar todo el tiempo que dure el incidente a intentar solucionarlo.
Los retos arquitectónicos que se abordan aquí son solo una parte de lo que los responsables de seguridad y resiliencia deben comprender sobre el riesgo de la IA agentiva. El artículo «El punto ciego agentivo: por qué la resiliencia de la IA exige un sistema de registro
» va más allá y analiza cuál es la situación real de la mayoría de las empresas en cuanto a su preparación para la resiliencia de la IA, cómo se manifiestan en la práctica las lagunas de gobernanza y qué hace falta para que la afirmación «nuestra IA es fiable» sea algo demostrable, y no solo una simple afirmación.
Preguntas frecuentes
P: ¿Por qué la recuperación ante desastres tradicional no funciona con la IA agentiva?
R: La recuperación tradicional parte de la base de que los sistemas no tienen estado y se pueden restaurar a partir de copias de seguridad limpias. Los sistemas de IA basados en agentes conservan la memoria, evolucionan con el tiempo y dependen de interacciones en capas, por lo que una simple restauración no basta para recuperar la confianza.
P: ¿Qué hace que la capa de memoria de la IA agentiva sea vulnerable?
R: La capa de memoria almacena representaciones y datos contextuales que influyen en las decisiones del agente. Si se ve comprometida, los atacantes pueden manipular sutilmente lo que el agente «cree», lo que da lugar a acciones incorrectas pero que parecen legítimas.
P: ¿Cómo pueden los atacantes aprovechar los flujos de trabajo en tiempo de ejecución de la IA basada en agentes?
R: Los atacantes pueden manipular los datos de planificación, las instrucciones o las respuestas de las herramientas, lo que hace que los agentes ejecuten acciones maliciosas utilizando procesos legítimos. Estas acciones suelen parecer normales en los registros, lo que dificulta su detección.
P: ¿Por qué la observabilidad supone un reto en los sistemas multiagente?
R: Los sistemas basados en agentes funcionan a la velocidad de la máquina, con interacciones continuas entre los agentes. Los sistemas de registro tradicionales no están diseñados para capturar ni procesar este nivel de actividad dinámica y de alta frecuencia.
P: ¿Qué son los fallos emergentes en entornos multiagente?
R: Los fallos emergentes se producen cuando una pequeña vulnerabilidad en un agente o capa se propaga por los agentes interconectados, lo que da lugar a problemas a gran escala cuyo origen es difícil de rastrear.
P: ¿Cómo sería una recuperación eficaz para una IA agentiva?
R: Una recuperación eficaz requiere algo más que restaurar los datos: exige una instantánea coherente de todas las capas del sistema, incluyendo la memoria, los flujos de trabajo, las identidades y las interacciones, alineada con un estado verificado y fiable.
Tim Zonca es vicepresidente de gestión de carteras en Commvault.
