La gobernanza de IA está migrando del modelo al runtime
Durante mucho tiempo, "gobernanza de IA" significó básicamente una pregunta: qué modelo estamos autorizados a usar. Tres papers recientes sobre sistemas multiagente muestran que esa pregunta ya no cubre dónde vive realmente el riesgo. El riesgo migró al runtime - a lo que ocurre después de que el modelo ya decidió actuar.
El argumento central: el comportamiento emergente no cabe en controles pre-deploy
El paper MI9, sobre gobernanza de runtime para sistemas de IA agentic, parte de una constatación simple: agentes que razonan, planifican y actúan de forma autónoma exhiben "comportamientos emergentes e inesperados durante la ejecución" que no pueden anticiparse completamente solo con gobernanza pre-deployment. Un modelo aprobado en evaluación estática puede, en producción, encadenar herramientas, memoria y contexto de una forma que ninguna prueba pre-lanzamiento simuló.
Seis mecanismos para vigilar lo que ocurre en tiempo real
La respuesta que propone MI9 ya no es más control sobre el modelo - es instrumentar el runtime. El framework integra seis mecanismos: un índice de riesgo de agencia (cuantifica el nivel de amenaza ligado a la autonomía del agente), captura de telemetría semántica del agente, monitoreo continuo de autorización (no una verificación única al inicio de la sesión), motores de conformidad basados en máquinas de estados finitos, detección de desvío condicionada al objetivo, y estrategias de contención graduales. Cada uno de estos seis es, en la práctica, una respuesta a una pregunta que "qué modelo usar" nunca hizo: ¿qué está haciendo el agente ahora mismo, con qué herramientas, con qué permisos, y eso todavía coincide con el objetivo original?
La autorización no es un evento único - es un estado que cambia
El paper sobre fallas de "confused deputy" en LLMs agentic ataca directamente el punto más frágil de esa migración: la autorización. Un agente que recibe permiso para una tarea puede, en pasos posteriores, ser manipulado para usar ese mismo permiso en una acción que el usuario nunca autorizó - el clásico problema del "confused deputy", ahora a escala agentic. La mitigación probada en ese paper (ScopeGate) trata la autorización como algo que debe recalcularse en cada llamada a herramienta, no concedido una vez y olvidado.
El costo de errar del lado seguro también es real
"The Containment Gap" muestra el otro lado de esa ecuación: sistemas de contención mal calibrados no solo fallan en bloquear acciones peligrosas - también bloquean en exceso acciones legítimas, con una tasa de denegación indebida que compromete la utilidad del agente. Eso reformula el problema de gobernanza: no es solo "impedir que el agente haga algo malo", es hacerlo sin destruir la razón de ser del agente. El memory poisoning - memoria de sesión contaminada con instrucciones maliciosas que persisten más allá de la sesión original - es otro vector que solo aparece en runtime, nunca en evaluación de modelo aislada.
Qué cambia en la práctica para quien implementa agentes
La convergencia de estas tres fuentes apunta al mismo lugar: los equipos de plataforma que hoy tienen un proceso de aprobación de modelo, pero ningún proceso de monitoreo continuo de herramientas, memoria y permisos durante la ejecución, están vigilando la puerta equivocada. La pregunta que la gobernanza de 2026 necesita responder ya no es "¿este modelo es seguro?", es "¿qué puede hacer este agente ahora mismo, con lo que tiene acceso ahora mismo, y hay alguien observando mientras ocurre?".
Fuentes
- Arxiv - Runtime Governance in Multi-Agent Systems - https://arxiv.org/abs/2508.03858
- Arxiv - The Containment Gap - https://arxiv.org/abs/2606.12797
- Arxiv - Authorization Confused Deputy Failures in Agentic LLMs - https://arxiv.org/abs/2606.28679