Cuando un chatbot se equivoca, normalmente puedes notarlo y volver a preguntar. Cuando un agente autónomo se equivoca, el error puede acumularse a través de pasos, herramientas y memoria antes de que alguien lo vea. Esa brecha es la razón por la que una encuesta de mayo de 2026 sobre fallos de agentes importa para cualquiera que lance agentes con datos y dinero reales.

Doce investigadores liderados por Jinhu Qi (incluyendo a Irwin King) publicaron "Towards Trustworthy Agentic AI: A Comprehensive Survey of Safety, Robustness, Privacy, and System Security" (arXiv:2605.23989; Academia AI and Applications, 2026). Muestran cómo fallan los sistemas agenticos, qué defensas existen y dónde siguen los agujeros.

Qué cambia cuando el sistema actúa, no solo responde

Un modelo estándar recibe un prompt y devuelve texto. Un agente recibe un objetivo y actúa: planea, llama a herramientas, almacena resultados intermedios, encadena acciones y se adapta a lo que devuelve el entorno.

Ese diseño genera fallos que las pruebas de prompt-respuesta no detectan. Una sola llamada errónea a una herramienta puede envenenar todos los pasos posteriores. La memoria puede almacenar una creencia falsa y seguir actuando en consecuencia. Pasos aparentemente inofensivos pueden combinarse para causar daño. El mundo cambia a medida que el agente actúa, y esos cambios alimentan la siguiente decisión.

Seguridad y robustez

Aquí el riesgo es la propia trayectoria del agente. Los ataques no son solo prompts de usuarios. Un documento malicioso que el agente lea a mitad de tarea puede desviar el resto de la ejecución sin que el usuario lo sepa. Eso es inyección de prompts desde el entorno.

El cambio de distribución es peor para los agentes que para los chatbots. Un chatbot que se encuentra con un caso desconocido da una respuesta peor. Un agente en la misma situación toma una secuencia de acciones confiadas que pueden empeorar la situación con cada paso.

La brecha de métricas

La mayoría de los benchmarks de agentes siguen preguntando si la tarea se completó. Muchos menos preguntan si se mantuvieron las restricciones durante el proceso. Un sistema puede «tener éxito» mientras rompe reglas en cada ejecución. El centro unificado de métricas de la encuesta es útil porque rastrea tanto el resultado como el proceso: éxito de la tarea, violaciones de restricciones, trazas incompletas, tasas de éxito de ataques.

Privacidad y seguridad del sistema

Aquí el adversario controla parte del entorno. La encuesta documenta fallos reales en pilas de agentes de código abierto, no solo ataques de juguete.

La memoria de largo plazo es un problema de privacidad que los chatbots suelen evitar. Un agente que investiga a lo largo de una sesión puede acumular secretos y luego filtrarlos mediante llamadas a herramientas o inyecciones. El envenenamiento de memoria (corromper el contexto almacenado para dirigir el comportamiento posterior) no tiene equivalente limpio en una sola interacción.

Los entornos multiagente amplían la brecha. Un agente comprometido puede introducir basura a través de canales normales entre pares. Los filtros diseñados para la entrada de usuarios pueden confiar por defecto en los agentes pares.

Qué sigue sin resolverse

1
Agentes autoevolutivos. Los sistemas que reescriben su propio comportamiento a partir de la experiencia pueden dejar atrás sus propiedades de seguridad originales. Las pruebas de sistemas fijos no cubren un objetivo en movimiento. La verificación continua aún es escasa.
2
Monitoreo en tiempo de ejecución. La mayoría de los agentes implementados carecen de verificaciones continuas de los rastros de ejecución contra las reglas de seguridad. Las pruebas de liberación en un momento dado no detectan desviaciones entre sesiones.
3
Memoria útil sin un depósito con fugas. Los agentes necesitan contexto para ayudar. La mayoría de los diseños actuales o bien descartan la memoria (y pierden utilidad) o mantienen memoria fácil de explotar.

La objeción popular

La objeción más fuerte es que esto es la seguridad informática de ayer con una etiqueta nueva: aislar las herramientas, registrar las acciones, enviar. En parte es cierto. Los entornos aislados y los registros importan. El punto de la encuesta es que los agentes añaden compounding de horizonte largo, ataques procedentes del entorno y confianza entre pares que las listas de verificación de seguridad de aplicaciones ordinarias siguen subestimando. Tratar el riesgo de agentes como "otra API más" es la forma en que los equipos pasan por alto la pila.

Qué hacer con el mapa

Los equipos que ya ponen agentes sobre datos de clientes, dinero o herramientas externas necesitan métricas de proceso, monitoreo en tiempo de ejecución y revisión independiente del diseño de herramientas y memoria, no solo una evaluación de lanzamiento que pregunte si la tarea de demostración se completó.

Para la Fundación, los mapas de fallos de agentes son una capa a corto plazo. No reemplazan el trabajo más grande. Un mundo que corre hacia la superinteligencia artificial todavía necesita límites vinculantes, reglas de cómputo y verificación para que la capacidad no supere al control. Usa la encuesta para endurecer los agentes que despliegas ahora. Usa la vía del tratado para que el estado final no sea un agente que nadie pueda anular. Documento completo: arXiv:2605.23989.