Los incidentes de agentes de IA suelen empezar con una señal de éxito aparentemente normal: terminó una tarea, respondió una solicitud web o se modificó un archivo. La pregunta difícil aparece después: ¿actuó el agente donde no debía hacerlo y puede el equipo demostrar exactamente qué ocurrió?
Los informes sobre agentes que escribieron en una wiki alemana externa ilustran por qué importa. La cobertura pública no sustituye un registro forense ni establece una conclusión legal. Sí muestra el problema operativo: cuando muchas ejecuciones pueden navegar, escribir, autenticarse o llamar herramientas, una acción externa inesperada puede convertirse en un ejercicio de evidencia y contención antes de que todos acuerden cómo llamarla.
La plantilla de la Comisión Europea para comunicar incidentes graves que involucren modelos de IA de propósito general con riesgo sistémico y el Código de prácticas GPAI son referencias útiles para esta disciplina. Subrayan la información relevante, la documentación y las medidas correctivas. Los equipos no necesitan esperar a un umbral formal de reporte para adoptar internamente los mismos hábitos.
Empiece con un registro factual del evento
El primer registro debe ser deliberadamente sobrio. Anote cuándo se detectó la actividad, de qué entorno procedía, qué agentes o ejecuciones participaron, qué destino externo se alcanzó y qué hizo realmente el sistema. Conserve registros de solicitudes, trazas de llamadas a herramientas, prompts pertinentes, versiones de políticas, credenciales o capacidades concedidas y la versión de la compilación o del modelo.
Evite convertir una etiqueta temprana en una conclusión. «Escritura no autorizada» puede ser una descripción preliminar útil; «escape del modelo» normalmente no lo es. Una persona revisora debe distinguir entre telemetría confirmada, declaraciones de terceros afectados e hipótesis sin resolver. Esa separación mantiene precisa la comunicación posterior cuando cambia la primera versión de los hechos.
Un registro práctico también nombra los momentos. Registre la hora de detección, la primera acción conocida, la última acción conocida, la contención y el contacto con cada parte afectada. Son instantes distintos. Decir de forma vaga que un incidente se gestionó con rapidez no sustituye una cronología que muestre qué se sabía en cada paso.
Delimite el impacto antes de elegir la solución
No cuente la actividad y se detenga ahí. Mil lecturas inocuas y una escritura en un servicio de producción crean riesgos diferentes. Pregunte qué datos se consultaron o cambiaron; qué sistemas y personas se vieron afectados; si el agente conserva una credencial o una vía para repetir la acción; y si el comportamiento puede extenderse a ejecuciones simultáneas.
Incluya también hallazgos negativos. Si no se utilizó ninguna credencial de producción, explique cómo se comprobó. Si se contactó un sitio público pero no quedó contenido después de retirarlo, registre la evidencia y los límites de esa conclusión. Una declaración de alcance acotada es más útil que asegurar que «no hubo impacto».
En sistemas multiagente, el alcance necesita una vista por ejecución. Agrupe la actividad por configuración compartida de herramientas, política de red, identidad, familia de tareas y ventana temporal. Esto puede revelar si un aparente enjambre fue una integración reutilizada, muchos prompts independientes o un fallo de control más amplio.
Contenga la capacidad, no solo el resultado visible
Borrar una página no deseada o revocar una sesión puede limpiar el síntoma y dejar abierta la ruta que permitió la acción. La contención debe eliminar o limitar la capacidad que la hizo posible: pause la familia de tareas afectada, revoque o rote la credencial pertinente, restrinja el conector, endurezca las reglas de salida de red y preserve los registros originales antes de cambiar la retención.
Después, pruebe la reparación con una reproducción deliberadamente limitada. Una prueba útil demuestra que la ruta original ahora falla de forma segura mientras el trabajo autorizado puede continuar. Debe quedar junto al ticket de cambio, porque futuros revisores necesitan saber si la mitigación se verificó o solo se pretendía aplicar.
Aquí el mínimo privilegio se vuelve operativo. Un agente que solo necesita leer una lista seleccionada de fuentes no debería heredar automatización amplia del navegador, acceso ilimitado a la red ni tokens con capacidad de escritura. Identidades separadas para evaluación, pruebas y producción permiten contener un incidente sin detener todos los sistemas.
Escriba el informe para la siguiente decisión
Una buena actualización responde cinco preguntas: qué está confirmado; qué sigue bajo investigación; quién está afectado; qué controles inmediatos están vigentes; y cuándo llegará la próxima actualización. Debe identificar a una persona responsable y un canal para operadores afectados, en vez de pedir al lector que infiera responsabilidad de un mensaje genérico de seguridad.
El compromiso del Código GPAI sobre incidentes graves ayuda porque vincula el reporte con el seguimiento de información y posibles medidas correctivas. El objetivo no es una divulgación performativa. Es un registro que permite a un regulador, cliente, operador de sitio o responsable interno de riesgo evaluar si la respuesta corresponde a la ruta de fallo.
La comunicación externa debe ser proporcional. Algunos detalles pueden ser sensibles durante una investigación activa, pero ocultar todos los hechos técnicos dificulta que las partes afectadas se protejan. Indique el límite: qué detalles están confirmados, cuáles se retienen por seguridad o privacidad y qué evidencia se compartirá después.
Convierta el incidente en una mejora de control
Cierre el incidente solo cuando la acción correctiva tenga responsable, fecha límite y método de verificación. Las acciones posteriores habituales incluyen una lista de destinos permitidos, un permiso de herramienta separado, una alerta para escrituras externas repetidas, una puerta de revisión para conectores nuevos y una simulación de la misma ruta de fallo. Relacione cada acción con la causa que contribuyó al problema, en lugar de crear una tarea genérica de «mejorar la seguridad».
Por último, conserve una breve nota de lecciones aprendidas antes del siguiente despliegue de agentes. Incluya el desencadenante, la capacidad afectada, la brecha de detección, el resultado de la contención y la evidencia de que la corrección funciona. Así, una sorpresa aislada se convierte en un control operativo reutilizable.
Para los equipos que despliegan agentes, la regla duradera es sencilla: redacte el informe de incidente como un registro de decisión, no como texto de relaciones públicas. Preserve la evidencia, describa el alcance con honestidad, cierre la vía que permitió el comportamiento y verifique el control de reemplazo. Eso hace que la próxima respuesta sea más rápida y creíble, se alcance o no un umbral regulatorio formal.
Combinamos fuentes primarias, documentación de producto y casos de uso reales para ayudarte a valorar si una herramienta encaja en tu flujo de trabajo.