La discusión sobre seguridad de agentes de inteligencia artificial suele partir de una unidad cómoda: un modelo, una aplicación, una prueba y una organización responsable.[2] Ese marco se vuelve insuficiente cuando varios agentes —creados por proveedores distintos, conectados a herramientas diferentes y operados por empresas distintas— negocian, delegan tareas o consumen mutuamente sus resultados.[2]

Ese es el argumento central de un nuevo memorando de la Cooperative AI Foundation y Brookings Institution, elaborado a partir de un taller celebrado en IASEAI 2026.[1][2] El documento no anuncia una crisis ya observada a escala social ni demuestra que las redes de agentes autónomos estén fuera de control.[2] Plantea algo más preciso: las auditorías individuales no permiten inferir automáticamente la seguridad del sistema que emerge cuando esos agentes interactúan, y la responsabilidad queda repartida entre demasiados actores.[1][2]

La oportunidad editorial del informe no depende solo de una hipótesis futura. Los agentes de uso de computadora ya pueden operar navegadores, terminales, archivos y servicios externos; un preprint publicado el 14 de septiembre, HazardAuditor, evalúa precisamente riesgos que aparecen durante la ejecución y no únicamente en el texto generado.[4] Al mismo tiempo, el OWASP GenAI Security Project ya incluye sistemas agénticos dentro de su alcance de seguridad, señal de que la superficie operacional dejó de ser un problema puramente académico.[7]

De un modelo que responde a un sistema que actúa

Conviene separar conceptos. Un modelo produce salidas a partir de entradas.[5][6] Un agente combina ese modelo con memoria, herramientas, permisos y un ciclo de decisión.[2] Una ejecución es la secuencia concreta de observaciones y acciones que ocurre cuando el agente intenta completar una tarea.[4] Un sistema multiagente aparece cuando varios agentes —humanos o artificiales, del mismo operador o de operadores distintos— interactúan entre sí.[2]

Esta distinción importa porque una respuesta riesgosa no equivale a una acción ejecutada.[4] HazardAuditor, por ejemplo, clasifica trayectorias completas y distingue entre un agente que encuentra una instrucción maliciosa y la rechaza, y otro que la convierte en una llamada a una herramienta.[4] Su infraestructura normaliza eventos de Claude Code, Codex, Hermes y OpenClaw para comparar comportamiento entre marcos heterogéneos.[4]

Lo confirmado aquí es limitado pero relevante: existen agentes con acceso a navegadores, terminales, sistemas de archivos y servicios externos; existen entornos de evaluación capaces de registrar sus trayectorias; y los marcos actuales de seguridad ya reconocen amenazas contra aplicaciones y sistemas agénticos.[4][7] No está confirmado que una red abierta de agentes haya producido por sí sola un fallo económico o de infraestructura de escala sistémica.[2] Ese escenario permanece prospectivo.[2]

El salto que una auditoría individual no captura

El memorando sostiene que un agente que supera una prueba aislada puede comportarse de otra manera al entrar en un entorno con otros agentes.[2] Las nuevas variables incluyen conflicto, mala coordinación, influencia adversaria, fallos correlacionados y posible colusión.[2] También incluye un problema de velocidad: si los sistemas intercambian decisiones más rápido de lo que una persona puede revisarlas, la supervisión humana reactiva llega tarde.[2]

Esa afirmación es una tesis de gobernanza respaldada por estudios y simulaciones citados por el informe, no una medición universal de sistemas desplegados.[2] El documento menciona experimentos sobre conducta colusoria en mercados simulados, combinaciones de modelos que producen resultados maliciosos sin activar controles individuales y escenarios donde datos falsificados se propagan por sistemas conectados.[2] También reconoce que las opiniones del memorando no necesariamente representan consenso entre los participantes del taller.[2]

La lección práctica es que una puntuación de seguridad individual no puede tratarse como propiedad transitiva.[2] Si el agente A pasa su evaluación y el agente B también, no se sigue que A+B sea seguro.[2] El canal de comunicación, los incentivos, los permisos y la autoridad de cada herramienta forman parte del sistema evaluado.[2]

Lo que sí muestran las evaluaciones actuales

HazardAuditor ofrece un ejemplo concreto de cómo mover la evaluación desde el contenido hacia la ejecución.[4] El trabajo entrena un guardia a partir de trayectorias normalizadas y reporta mejoras de hasta 16.5 puntos porcentuales sobre el guardia previo más fuerte en sus pruebas.[4] En ASSE-Safety informa 91.5% de exactitud y F1.[4]

Esos números son resultados experimentales controlados, no garantía de seguridad en producción.[4] El propio diseño conserva los eventos iniciales cuando una trayectoria excede el límite de 16,000 tokens, lo que implica que parte de una ejecución larga puede quedar fuera del contexto de entrenamiento.[4] Además, el trabajo es un preprint: debe leerse como evidencia técnica reciente y reproducible en principio, no como estándar validado por años de despliegue independiente.[4]

El estudio también ayuda a precisar el problema multiagente.[4] Antes de preguntar si varios agentes cooperarán o coludirán, una organización debe poder reconstruir qué vio cada uno, qué herramienta seleccionó, qué llamada ejecutó y qué resultado recibió.[2][4] Sin esa telemetría, un incidente distribuido puede parecer una serie de decisiones locales inocuas.[2]

Cinco controles, y dónde termina la evidencia

El memorando organiza su propuesta en cinco verbos: identificar, evaluar, monitorear, reportar e incentivar. Propone identificadores estandarizados de agentes y registros de modelos; sandboxes que prueben conflicto, colusión e influencia adversaria; monitoreo continuo con mecanismos de contención preautorizados; canales de reporte de terceros; y herramientas económicas como responsabilidad, seguros y requisitos de contratación pública o privada.[1][2][3]

Son recomendaciones de política, no capacidades desplegadas de forma general.[2] Un identificador puede mejorar atribución, pero también crea preguntas sobre privacidad, interoperabilidad y quién administra el registro.[2] Un “interruptor” automatizado puede frenar una cascada, pero primero necesita umbrales verificables y autoridad institucional.[2] Un seguro puede premiar mejores controles, pero solo si las aseguradoras pueden medir exposición y distinguir una mala integración de una falla del modelo.[2]

Aquí aparece una diferencia importante con la seguridad tradicional.[2][5] NIST ofrece una taxonomía extensa de ataques y mitigaciones de aprendizaje automático, mientras OWASP documenta riesgos de aplicaciones generativas y agénticas.[5][7] Esos marcos aportan vocabulario, controles y prácticas, pero el memorando argumenta que todavía falta una capa para interacciones entre agentes pertenecientes a dominios administrativos distintos.[2]

La ley regula actores y sistemas; la interacción puede cruzarlos

El Reglamento de IA de la Unión Europea reconoce explícitamente que múltiples partes suministran modelos, herramientas, servicios y otros componentes a lo largo de la cadena de valor.[6] También distingue entre un modelo de propósito general y el sistema de IA en el que ese modelo se integra.[6] Esto confirma que la regulación no reduce todo a un único modelo.[6]

Sin embargo, afirmar que la ley “no cubre” los sistemas multiagente sería demasiado amplio.[6] La norma sí asigna obligaciones a proveedores, desplegadores y otros actores según el tipo de sistema y riesgo.[6] La crítica del memorando es más estrecha: cuando una conducta emerge de agentes de distintos proveedores y operadores, la atribución causal, el reporte y la coordinación de respuesta pueden quedar fragmentados.[2][6]

Ese vacío no se resuelve añadiendo una cláusula genérica de “supervisión humana”.[2] Si una interacción ocurre a velocidad de máquina, la intervención humana debe diseñarse antes del despliegue: permisos mínimos, límites de gasto o impacto, registros inmutables, reglas de parada y rutas claras de escalamiento.[2] La persona sigue siendo responsable del marco, pero no necesariamente puede aprobar cada acción en tiempo real.[2]

Qué debe separar una empresa antes de desplegar

Una evaluación seria debería distinguir cinco capas:

1. Hechos y capacidades desplegadas: qué herramientas puede usar el agente, con qué credenciales, sobre qué datos y con qué límites.
2. Resultados experimentales: qué ocurrió en benchmarks, sandboxes o simulaciones, bajo qué modelos y condiciones.
3. Opiniones y estimaciones: qué consideran probable investigadores, compañías o reguladores, sin convertir esas opiniones en hechos.
4. Escenarios prospectivos: qué podría pasar si los agentes se conectan a mercados, infraestructura o procesos empresariales críticos.
5. Hipótesis sobre capacidades futuras: funciones aún no demostradas que no deben justificar por sí solas decisiones urgentes.

Esta separación evita dos errores opuestos: minimizar riesgos porque todavía no hay un desastre sistémico, o describir simulaciones como si fueran incidentes reales.[2] El valor del memorando está en convertir una preocupación amplia en controles observables, no en probar que el peor escenario ya llegó.[2]

Indicadores que vale la pena vigilar

Durante los próximos meses, la evidencia mejorará si aparecen señales verificables: evaluaciones multiagente con código y datos públicos; registros de incidentes que describan cadenas completas de ejecución; estándares para identidad y trazabilidad entre proveedores; contratos que asignen responsabilidad por acciones delegadas; y pruebas de mecanismos automáticos de contención bajo carga real.

También habrá que observar si los proveedores exponen telemetría compatible. Si cada plataforma registra herramientas, permisos y resultados de manera incompatible, una empresa no podrá reconstruir un incidente que cruce varias. Si, por el contrario, surgen formatos comunes para eventos y políticas de capacidad, la seguridad podrá evaluarse sobre la trayectoria completa y no solo sobre la respuesta final.

La conclusión no es que todo sistema multiagente sea inseguro. Es que su seguridad no puede calcularse sumando certificados individuales. El objeto de auditoría debe ampliarse: del modelo al agente, del agente a la ejecución y de la ejecución a la red de relaciones, permisos e incentivos que determina lo que realmente puede ocurrir.

Fuentes

[1] Leer Más — New Memo: Multi-Agent AI Governance
[2] Leer Más — Establishing Foundational Principles and Thresholds for Multi-Agent AI Governance
[3] Leer Más — IASEAI summary: Multi-Agent AI Governance
[4] Leer Más — HazardAuditor
[5] Leer Más — NIST Adversarial Machine Learning Taxonomy
[6] Leer Más — EU Artificial Intelligence Act
[7] Leer Más — OWASP GenAI Security Project