El monitoreo de agentes de IA necesita intervención en tiempo de ejecución
El 15 de mayo de 2026, Parand A. Alamdari, Toryn Q. Klassen y Sheila A. McIlraith publicaron un artículo donde sostienen que la gobernanza de IA necesita auditoría fuera de línea, monitoreo en línea durante la ejecución y monitores capaces de intervenir antes de que una infracción prevista llegue a concretarse.1
Esa última palabra importa.
Un monitoreo que solo registra un fallo ayuda a la autopsia. Un monitoreo que puede pausar, bloquear, contener o redirigir al agente cambia la ejecución cuando el resultado todavía está abierto.
El monitoreo de agentes de IA necesita intervención en tiempo de ejecución. Los registros, las trazas, los paneles y los historiales de aprobación dan evidencia a los equipos. La intervención en tiempo de ejecución convierte esa evidencia en una decisión mientras el agente aún puede evitar la acción equivocada.
Resumen rápido
El monitoreo de agentes de IA falla cuando funciona como análisis forense posterior. Un entorno de ejecución serio para agentes debe observar la trayectoria activa, detectar infracciones de políticas y errores decisivos, y elegir una intervención acotada: continuar, advertir, pausar, bloquear, contener, recuperar o escalar.
La investigación reciente apunta en esa misma dirección desde varios ángulos. Los trabajos de métodos formales aplican lógica temporal al monitoreo en tiempo de ejecución y a monitores con capacidad de intervención.1 AgentForesight plantea la detección de fallos como auditoría en línea antes de que termine una trayectoria.2 AgentTrust intercepta llamadas riesgosas a herramientas antes de ejecutarlas y devuelve dictámenes estructurados.3 AIR incorpora la respuesta a incidentes dentro del ciclo del agente para que el sistema pueda detectar, contener, recuperar y sintetizar futuras reglas de protección.4
La lección práctica: no te quedes en la observabilidad. Construye la parte del entorno de ejecución que puede actuar sobre lo observado.
Ideas clave
Para equipos de plataformas de agentes: - Trata el monitoreo como un ciclo de control, no solo como un panel. - Define acciones de intervención antes de que el agente toque herramientas de alto riesgo.
Para equipos de seguridad: - Pasa de la revisión posterior a la detección en línea en los puntos de compromiso. - Registra cada intervención con regla, evidencia, decisión y resultado.
Para equipos de producto: - Muestra los eventos de intervención como objetos estructurados de revisión. - Permite que el usuario vea por qué se pausó la ejecución, qué evidencia activó la pausa y qué opciones seguras siguen disponibles.
Para operadores: - Confía más en las trazas que pueden cambiar el comportamiento que en las trazas que solo explican el daño después. - Pregunta si un monitor puede detener el siguiente paso incorrecto, no solo reconstruir el anterior.
¿Por qué el monitoreo de agentes de IA falla demasiado tarde?
La mayoría del monitoreo empieza cuando el agente ya actuó.
Un registro puede mostrar que el agente ejecutó un comando de shell. Una traza puede mostrar que el agente obtuvo una página web, llamó a un servidor MCP, escribió un archivo o solicitó aprobación. Un panel puede mostrar que una política de red bloqueó un dominio. Esos registros importan, pero no cambian automáticamente la siguiente acción.
La publicación de OpenAI sobre seguridad en Codex describe la base de evidencia correcta: ejecución acotada, configuración administrada, política de red, aprobaciones y telemetría nativa de agentes. Codex puede exportar eventos de OpenTelemetry para instrucciones de usuario, decisiones de aprobación de herramientas, resultados de ejecución de herramientas, uso de servidores MCP y eventos de permiso o denegación del proxy de red.5 OpenAI también describe el uso de registros de Codex con un agente de triaje de seguridad para que los revisores inspeccionen la solicitud original, la actividad de herramientas, las aprobaciones, los resultados de herramientas y las decisiones de política de red relacionadas con alertas de endpoints sospechosos.5
Esa visibilidad importa. La brecha aparece cuando la visibilidad no tiene un actuador.
Si un monitor detecta que un agente leyó contenido no confiable y luego intenta enviar datos a un nuevo dominio externo, el sistema no debería limitarse a registrar la secuencia. Debería pausar la ejecución o bloquear la solicitud. Si un agente de programación reintenta una migración fallida 3 veces y luego propone un comando destructivo más amplio, el entorno de ejecución no debería esperar a la revisión final. Debería interrumpir la trayectoria.
El monitoreo de agentes de IA debe responder 2 preguntas a la vez:
| Pregunta | Monitoreo débil | Monitoreo fuerte |
|---|---|---|
| ¿Qué pasó? | Registra eventos después de la ejecución. | Registra eventos tipados durante la ejecución. |
| ¿Qué debería pasar ahora? | Deja el juicio para una revisión posterior. | Continúa, advierte, pausa, bloquea, contiene, recupera o escala. |
La segunda pregunta convierte el monitoreo en intervención.
¿Qué aportan los nuevos artículos sobre tiempo de ejecución?
Este grupo reciente de investigaciones le da al campo un vocabulario más preciso.
El artículo de métodos formales se enfoca en restricciones de comportamiento extendidas en el tiempo: reglas que dependen del orden, la distancia y la secuencia, no solo de eventos aislados. Los autores combinan métodos formales con aprendizaje automático para auditoría fuera de línea y monitoreo en línea de sistemas de IA de caja negra, incluidos LLMs.1 También presentan monitores predictivos y con capacidad de intervención que pueden anticipar o mitigar infracciones previstas durante la ejecución.1
AgentForesight nombra el modo de fallo en términos de agentes. El artículo afirma que los sistemas multiagente de largo horizonte pueden aceptar un error decisivo y luego entrar en una cascada que termina en un fallo de toda la trayectoria.2 En lugar de diagnosticar el paso responsable después de que termina la trayectoria, AgentForesight pide que un auditor en línea inspeccione solo el prefijo actual y decida si continúa o activa una alarma ante el primer error decisivo.2
AgentTrust trabaja en el límite de las llamadas a herramientas. Intercepta las llamadas del agente antes de ejecutarlas y devuelve un dictamen estructurado: permitir, advertir, bloquear o revisar.3 Esa forma importa porque las operaciones de archivo, los comandos de shell, las solicitudes HTTP y las consultas de bases de datos producen efectos reales.3
AIR agrega la capa de respuesta a incidentes. El artículo sostiene que el trabajo de seguridad de agentes suele centrarse en prevenir fallos por adelantado, pero deja poca capacidad para responder, contener o recuperarse cuando aparecen incidentes.4 AIR integra la respuesta a incidentes en el ciclo de ejecución del agente: detecta incidentes, guía acciones de contención y recuperación, y sintetiza reglas de protección para ejecuciones futuras.4
En conjunto, estos artículos desplazan el centro de gravedad:
| Centro anterior | Nuevo centro |
|---|---|
| ¿La respuesta final parecía correcta? | ¿La trayectoria activa se mantuvo dentro de las restricciones? |
| ¿Los registros explicaron el fallo? | ¿Los monitores intervinieron antes del punto de compromiso? |
| ¿Un benchmark puntuó la tarea completada? | ¿El entorno de ejecución detectó pronto el error decisivo? |
| ¿Una instrucción de seguridad advirtió al modelo? | ¿Una capa de políticas cambió la siguiente acción permitida? |
Ese cambio encaja con el trabajo real de los agentes. Los efectos secundarios ocurren durante la ejecución, no en la respuesta final.
¿Qué cuenta como intervención en tiempo de ejecución?
Una intervención en tiempo de ejecución es una acción acotada que el sistema toma porque la evidencia en vivo cruzó un umbral de política, seguridad, calidad o riesgo.
La intervención debe ser más estrecha que el pánico y más fuerte que el registro.
| Intervención | Cuándo usarla |
|---|---|
| Continuar | El evento se mantiene dentro de la política y del plan esperado. |
| Advertir | El evento parece inusual, pero reversible. |
| Pausar | El siguiente paso necesita revisión humana o de política. |
| Bloquear | La acción infringe una regla estricta. |
| Contener | La ejecución solo puede continuar dentro de un entorno aislado o conjunto de capacidades reducido. |
| Recuperar | El sistema ejecuta una ruta compensatoria conocida. |
| Escalar | El evento necesita revisión de seguridad, producto o dominio. |
Una buena intervención no regaña al modelo. Cambia el estado del entorno de ejecución.
Una intervención debe producir un registro estructurado:
| Campo | Evidencia requerida |
|---|---|
| Ejecución | ID de ejecución del agente, tarea, fase y responsable. |
| Evento | Llamada a herramienta, solicitud de red, escritura de archivo, solicitud de aprobación o afirmación de salida. |
| Regla | La política o restricción temporal que se activó. |
| Evidencia | Fragmento de traza, argumentos, recurso objetivo, eventos previos y carril de riesgo. |
| Decisión | Continuar, advertir, pausar, bloquear, contener, recuperar o escalar. |
| Siguiente acción permitida | Qué puede hacer el agente después de la decisión. |
| Ruta humana | Quién puede revisar, anular o cerrar el incidente. |
| Resultado | Si la intervención previno, retrasó, reparó o no logró ayudar. |
El monitor gana confianza cuando otro revisor puede inspeccionar el evento y entender por qué el entorno de ejecución cambió de rumbo.
¿Por qué importan las restricciones temporales?
Muchos fallos de agentes dependen del orden.
“No publiques sin pruebas” no es una propiedad de un solo comando. Es una relación entre una acción de publicación y evidencia anterior. “No envíes tráfico de red externo después de leer contenido no confiable” depende de la secuencia. “No escribas en producción después de una migración fallida” depende del estado de fallo previo. “No apruebes un despliegue después de que falló la verificación de fuentes” depende tanto del evento de aprobación como del evento de verificación.
Linear Temporal Logic da a los investigadores una forma de expresar restricciones a lo largo del tiempo: antes, después, hasta que, eventualmente y nunca. El artículo de métodos formales del 15 de mayo informa que las técnicas de auditoría y monitoreo basadas en LTL superaron a los métodos de referencia de LLM para detectar infracciones de restricciones de comportamiento extendidas en el tiempo.1 Los autores también informan que incluso etiquetadores de modelos pequeños igualaron o superaron a jueces LLM de frontera bajo su enfoque, y que el razonamiento temporal de LLM se degradó a medida que aumentaban la distancia entre eventos, la cantidad de restricciones y la cantidad de proposiciones.1
La lección para producción no exige que todos los equipos lancen mañana una pila completa de métodos formales.
La lección inmediata es más simple: escribe reglas que entiendan la secuencia.
| Regla temporal | Significado en tiempo de ejecución |
|---|---|
| Ninguna escritura externa después de una obtención no confiable hasta revisión | Pausar antes del egreso si contenido no confiable entró en contexto. |
| Ningún despliegue hasta que pasen las pruebas y verificaciones renderizadas | Bloquear el despliegue cuando faltan eventos de evidencia. |
| Ningún comando destructivo después de correcciones fallidas repetidas | Pausar cuando la recuperación se convierte en escalamiento. |
| Ninguna aprobación persistente después de cambios de alcance | Vencer la concesión cuando cambia el objetivo, la herramienta o el carril de riesgo. |
| Ninguna finalización mientras falte evidencia requerida | Detener la respuesta final hasta que exista prueba. |
Estas restricciones piden que el entorno de ejecución recuerde suficiente historial para juzgar el siguiente paso. Una instrucción sin estado no puede hacerlo de forma confiable.
¿Dónde debe ubicarse el monitoreo en tiempo de ejecución?
El monitoreo en tiempo de ejecución pertenece a los puntos de compromiso.
Un punto de compromiso es cualquier momento en que el agente cruza de análisis reversible a efecto externo: mutación de archivos, escritura en base de datos, egreso de red, despliegue, envío de mensajes, cambio de permisos, pago, eliminación o publicación pública.
La documentación de OpenAI sobre Codex cloud da un límite concreto. Codex bloquea por defecto el acceso a internet durante la fase del agente, mientras que los scripts de configuración aún pueden usar internet para dependencias.6 Esa misma documentación advierte que habilitar el acceso a internet para agentes aumenta el riesgo, incluida la inyección de instrucciones desde contenido web no confiable, la exfiltración de código o secretos, malware o dependencias vulnerables, y contenido con restricciones de licencia.6 También recomienda límites por dominio y método HTTP, con protección adicional al restringir solicitudes a GET, HEAD y OPTIONS.6
Esa forma de política debe extenderse más allá del acceso a red.
| Punto de compromiso | Entrada del monitor | Intervención posible |
|---|---|---|
| Comando de shell | Comando, cwd, rutas objetivo, fallos previos | Permitir, reescribir, pausar o bloquear. |
| Escritura de archivo | Ruta, tamaño del diff, propiedad, estado generado | Continuar, contener o requerir revisión. |
| Llamada de red | Método, dominio, contexto de origen, clase de carga útil | Permitir, requerir aprobación o bloquear. |
| Cambio en base de datos | Tabla, clase de fila, entorno, ruta de reversión | Pausar para evidencia de migración. |
| Publicación pública | ruta, metadatos, citas de fuentes, estado de traducción | Bloquear hasta que pasen las verificaciones renderizadas. |
| Solicitud de aprobación | recurso, riesgo, vencimiento, denegaciones previas | Reducir alcance o escalar. |
Monitorear cada token desperdicia atención. Monitorear puntos de compromiso protege las partes de la ejecución donde los errores escapan de la transcripción.
¿Cómo debe experimentar el agente la intervención?
El agente debe recibir una actualización de estado precisa, no un reproche vago.
Respuesta débil:
Ten cuidado. Eso puede ser inseguro.
Mejor respuesta:
Bloqueado:
POSTexterno después de leer contenido no confiable. Siguientes acciones permitidas: resumir el riesgo, solicitar aprobación del operador con dominio objetivo y clase de carga útil, o continuar sin egreso de red.
La segunda respuesta le da al agente un espacio de planificación seguro. Dice qué se activó, por qué la acción no puede ejecutarse y qué alternativas siguen disponibles. La forma del dictamen de AgentTrust apunta en esa dirección: permitir, advertir, bloquear o revisar, con alternativas más seguras para comandos riesgosos.3
La intervención en tiempo de ejecución debe preservar la capacidad de actuar sin preservar el peligro.
El agente aún puede reparar la tarea. Puede solicitar aprobación. Puede cambiar de herramientas. Puede dividir el trabajo en una pasada de solo lectura. Puede producir un paquete de evidencia. El entorno de ejecución solo elimina las acciones que infringen el estado actual de la política.
¿Qué debe ver la persona?
La persona debe ver una tarjeta de intervención, no una pausa misteriosa.
| Campo de la tarjeta | Ejemplo |
|---|---|
| Estado | Pausado por intervención en tiempo de ejecución |
| Activador | Escritura externa después de leer una fuente no confiable |
| Regla | Ningún egreso después de una obtención no confiable hasta revisión |
| Evidencia | URL leída, dominio propuesto, método, clase de carga útil |
| Riesgo | Exfiltración de secretos o código fuente |
| Opciones del agente | Continuar en solo lectura, solicitar aprobación o eliminar egreso |
| Opciones humanas | Aprobar una vez, rechazar, reducir alcance o escalar |
| Auditoría | Guardada bajo ID de ejecución y puntero de traza |
Esa tarjeta pertenece a la misma familia de producto que las colas de aprobación, las líneas de tiempo de trazas y los paquetes de revisión. La diferencia es el momento. La aprobación pregunta si una acción planificada puede continuar. La intervención en tiempo de ejecución dice que el monitor vio un patrón vivo que cambió el siguiente paso permitido.
Una buena interfaz no debe obligar al usuario a leer toda la transcripción para entender la pausa. La tarjeta debe apuntar al fragmento de traza que importa.
¿Qué deberían construir primero los equipos?
Empieza con reglas de monitoreo simples en puntos de compromiso de alto valor.
- Define los puntos de compromiso. Nombra las llamadas a herramientas y los recursos donde los errores salen de la sesión local.
- Crea un flujo de eventos tipado. Registra herramienta, argumentos, objetivo, resultado, eventos previos relevantes y estado de ejecución.
- Escribe reglas conscientes de la secuencia. Empieza con relaciones de orden que importan una y otra vez: pruebas antes de desplegar, revisión antes de egreso, aprobación antes de escritura.
- Agrega intervenciones estrechas. Prefiere pausar, bloquear o contener antes que apagar todo.
- Devuelve dictámenes estructurados. Dile al agente qué se activó y qué acciones siguen permitidas.
- Muestra tarjetas de intervención. Da a las personas regla, evidencia, riesgo y próximas opciones.
- Revisa los resultados. Promueve verdaderos positivos, ajusta falsos positivos y retira reglas ruidosas.
La primera versión puede ser aburrida. Unas pocas reglas deterministas en el límite de las herramientas suelen superar a un juez de modelo amplio observando cada frase.
La versión más profunda puede agregar monitoreo predictivo, restricciones LTL, auditores aprendidos y ciclos de respuesta a incidentes. Construye esas capas después de que funcionen el flujo de eventos y la semántica de intervención.
El estándar digno
La intervención en tiempo de ejecución puede volverse teatro si cada pausa parece grave y cada advertencia pesa lo mismo.
El estándar debe mantenerse estrecho:
- Intervén solo donde la siguiente acción pueda importar.
- Nombra la regla que se activó.
- Muestra la evidencia.
- Conserva una siguiente ruta segura.
- Registra el resultado.
- Elimina reglas que generan ruido sin prevenir daño.
El buen monitoreo protege el trabajo. El mal monitoreo solo protege el relato de responsabilidad del proveedor.
El entorno de ejecución del agente no debe maximizar el movimiento. Debe maximizar el progreso responsable. A veces, el progreso responsable significa dejar que el agente continúe sin interrupciones. A veces significa rechazar el siguiente paso.
La vara de calidad está en saber distinguirlos.
Resumen breve
El monitoreo de agentes de IA necesita intervención en tiempo de ejecución porque los fallos de agentes ocurren dentro de trayectorias, no solo al final. Los registros y las trazas explican qué pasó. Los monitores con intervención pueden cambiar qué pasa después.
La dirección actual de la investigación es clara: restricciones temporales formales, auditores en línea, dictámenes de llamadas a herramientas y ciclos de respuesta a incidentes empujan el monitoreo hacia el control activo. Los equipos deberían empezar con flujos de eventos tipados, reglas en puntos de compromiso, dictámenes estructurados, tarjetas de intervención y revisión de resultados. El objetivo no es tener más alertas. El objetivo es tener menos errores irreversibles.
Preguntas frecuentes
¿Qué es la intervención en tiempo de ejecución para agentes de IA?
La intervención en tiempo de ejecución significa que el sistema cambia una ejecución activa del agente porque la evidencia en vivo cruzó un umbral de política, riesgo, seguridad o calidad. La intervención puede continuar, advertir, pausar, bloquear, contener, recuperar o escalar la ejecución.
¿En qué se diferencia la intervención en tiempo de ejecución de la observabilidad?
La observabilidad registra qué pasó. La intervención en tiempo de ejecución actúa mientras la ejecución sigue activa. Una traza puede servir para ambas, pero la intervención necesita una decisión de política y una siguiente acción permitida.
¿Cada acción del agente debe pasar por un monitor?
Cada acción significativa de herramienta debe producir un evento tipado. Solo los puntos de compromiso de alto valor necesitan reglas que interrumpan. Los eventos de solo lectura normalmente pueden registrarse en silencio. Los eventos con efectos secundarios merecen monitoreo más estricto.
¿Los equipos necesitan métodos formales para empezar?
No. Los equipos pueden empezar con reglas deterministas de secuencia: ningún despliegue antes de pruebas, ninguna escritura externa después de obtener contenido no confiable, ningún comando destructivo después de fallos repetidos de reparación y ninguna finalización sin la evidencia requerida. Los métodos formales se vuelven útiles cuando el conjunto de reglas crece y las relaciones temporales se vuelven difíciles de inspeccionar manualmente.
¿Qué hace confiable una intervención en tiempo de ejecución?
Una intervención confiable nombra la regla, muestra la evidencia, limita la siguiente acción, registra el resultado y da a una persona autorizada una ruta de revisión. Una advertencia vaga no cuenta.
Referencias
-
Parand A. Alamdari, Toryn Q. Klassen y Sheila A. McIlraith, “Formal Methods Meet LLMs: Auditing, Monitoring, and Intervention for Compliance of Advanced AI Systems,” arXiv:2605.16198v1, enviado el 15 de mayo de 2026. Fuente de las afirmaciones sobre auditoría fuera de línea, monitoreo en línea en tiempo de ejecución, monitoreo predictivo, monitores con intervención, restricciones de Linear Temporal Logic, comparación con etiquetadores de modelos pequeños y degradación del razonamiento temporal. ↩↩↩↩↩↩
-
Boxuan Zhang, Jianing Zhu, Zeru Shi, Dongfang Liu y Ruixiang Tang, “AgentForesight: Online Auditing for Early Failure Prediction in Multi-Agent Systems,” arXiv:2605.08715v2, revisado el 13 de mayo de 2026. Fuente sobre auditoría en línea de prefijos de trayectorias activas, alarmas de error decisivo, AFTraj-2K, encuadre de localización de pasos e intervención durante el despliegue. ↩↩↩
-
Chenglin Yang, “AgentTrust: Runtime Safety Evaluation and Interception for AI Agent Tool Use,” arXiv:2605.04785v1, enviado el 6 de mayo de 2026. Fuente sobre interceptación de llamadas a herramientas antes de la ejecución, dictámenes estructurados, desofuscación de shell, alternativas SafeFix, detección RiskChain, alcance del benchmark, precisión de dictámenes e integración con servidores MCP. ↩↩↩↩
-
Zibo Xiao, Jun Sun y Junjie Chen, “AIR: Improving Agent Safety through Incident Response,” arXiv:2602.11749v1, enviado el 12 de febrero de 2026. Fuente sobre respuesta a incidentes dentro del ciclo de ejecución de agentes LLM, detección semántica de incidentes, acciones de contención y recuperación, reglas de protección sintetizadas y tasas reportadas de éxito en detección, remediación y erradicación. ↩↩↩
-
OpenAI, “Running Codex safely at OpenAI,” OpenAI, 8 de mayo de 2026. Fuente sobre ejecución acotada de Codex, configuración administrada, política de red, aprobaciones, exportación de eventos de OpenTelemetry, registros de Compliance Platform y triaje de seguridad sobre actividad de Codex. ↩↩
-
OpenAI Developers, “Agent internet access,” consultado el 18 de mayo de 2026. Fuente sobre valores predeterminados de acceso a internet en Codex cloud, bloqueo de red durante la fase del agente, riesgos de inyección de instrucciones y exfiltración, listas de dominios permitidos y restricciones de métodos HTTP. ↩↩↩