Un cliente escribe para decir que el asistente le mostró datos de otra persona. El equipo de guardia abre el runbook y se encuentra con instrucciones que no aplican: no hay una firma que buscar, no hay un binario malicioso, no hay una IP desde la que se originó el ataque. Hay un sistema que hizo exactamente lo que le pidieron, con permisos que alguien le dio, a partir de un texto que alguien más escribió. Las primeras dos horas se van en discutir qué se supone que hay que hacer.
Las fases clásicas de la respuesta a incidentes siguen siendo válidas —detección, contención, erradicación, recuperación, lecciones aprendidas—. Lo que cambia es el contenido de cada una, y cambia lo suficiente como para que un runbook genérico no sirva. Estas son las tres diferencias que más pesan en la práctica.
La evidencia es otra cosa
En un incidente clásico la evidencia es razonablemente estable: registros de acceso, imágenes de disco, capturas de red, tablas de procesos. En un sistema de IA la evidencia central es el contexto que el modelo tenía delante en el momento de decidir, y esa reconstrucción es sorprendentemente difícil si no se preparó antes.
Lo que necesitas preservar en los primeros minutos, antes de que rote un log o alguien redespliegue: la versión exacta del prompt de sistema vigente en ese momento, la conversación completa incluyendo turnos anteriores, los fragmentos que el sistema recuperó y de qué documento vinieron, cada llamada a herramienta con sus parámetros y su respuesta, la versión del modelo, y la identidad con la que el agente actuó sobre cada sistema.
Hay dos trampas propias de este terreno. La primera es que el documento fuente puede haber cambiado: si el agente leyó una página, un ticket o un archivo compartido, ese contenido es editable y puede ya no contener lo que contenía. Consíguelo y consérvalo antes de nada. La segunda es que el comportamiento no es reproducible: intentar "repetir el caso" y no obtener el mismo resultado no descarta el incidente, y confundir eso con un falso positivo es un error frecuente. Si tu instrumentación no cubre esta cadena, ese es el trabajo previo, y lo tratamos en detalle en qué medir en un sistema de IA.
La contención se hace con el bisturí, no con el interruptor
El reflejo aprendido en incidentes tradicionales es aislar el activo comprometido: sacar la máquina de la red, deshabilitar la cuenta, cortar el servicio. Aplicado a un sistema de IA, apagar el asistente completo suele ser una reacción desproporcionada que detiene operaciones legítimas y, peor, destruye la posibilidad de observar el problema.
La contención efectiva casi siempre ocurre un nivel más abajo. La primera pregunta no es cómo apago el sistema, sino qué capacidad concreta hay que quitarle.
En un sistema de IA se contiene desactivando una herramienta, no apagando el modelo.
En orden aproximado de menor a mayor impacto operativo: revocar el permiso específico que permitió la acción dañina; desconectar la herramienta involucrada dejando el resto del asistente funcionando en modo consulta; forzar aprobación humana en toda acción con efecto, aunque enlentezca el flujo; excluir la fuente de contexto contaminada del índice de recuperación; y solo al final, si nada de lo anterior acota el daño, deshabilitar el caso de uso completo.
Esa gradación exige que los permisos y las herramientas sean desactivables de forma independiente y en caliente. Si tu arquitectura solo ofrece encendido y apagado global, la decisión de contención ya está tomada por el diseño, y siempre será la más cara. Vale la pena revisar cómo están repartidas esas capacidades antes del incidente, no durante; lo desarrollamos en permisos de agentes y herramientas.
La causa raíz rara vez es un exploit
Cuando estos incidentes se analizan hasta el fondo, el patrón se repite: el modelo no fue vulnerado en ningún sentido técnico. Hizo lo que se le pidió, usando una capacidad que legítimamente tenía, porque alguien le concedió más alcance del necesario y nadie definió qué acciones requerían un segundo par de ojos.
Las causas que encontramos con más frecuencia son de gobierno, no de código. Un agente que hereda los permisos completos de la persona que lo invoca, en vez de recibir los mínimos de su tarea. Una cuenta de servicio compartida entre varios agentes, que además vuelve imposible atribuir la acción. Una herramienta de escritura conectada para una prueba y que se quedó conectada. Una acción irreversible que se ejecuta directamente porque la aprobación humana se consideró fricción innecesaria. Una fuente de datos incorporada al índice de recuperación sin que nadie evaluara quién puede escribir en ella.
Esto tiene una consecuencia incómoda para el informe post incidente: la pregunta correcta no es "cómo lo engañaron", sino "por qué el sistema podía hacer eso". La primera lleva a endurecer el prompt, que es una medida frágil y consuela más de lo que protege. La segunda lleva a recortar permisos, que es lo que efectivamente cierra el caso.
Qué agregar a tu runbook esta semana
No hace falta reescribir el procedimiento completo. Con cuatro adiciones se cubre lo esencial. Un anexo de preservación de evidencia que enumere los artefactos de la cadena y su ubicación real, escrito por quien construyó el sistema. Una tabla de contención por caso de uso que liste, para cada agente, sus herramientas y cómo se desactiva cada una de forma independiente, con el comando o la ruta concreta. Un criterio de clasificación que reconozca daños propios de este terreno —exposición de datos entre clientes, acción irreversible no autorizada, contenido publicado hacia afuera— y no solo confidencialidad, integridad y disponibilidad en abstracto. Y la incorporación obligatoria de cada incidente como caso de prueba en tu suite adversarial, para que la lección quede en el pipeline y no en un documento.
El ensayo importa más que el documento. Toma el caso más probable de tu inventario, siéntate una hora con el equipo de guardia y el equipo que construyó el sistema, y recorre el escenario en voz alta hasta el final. Vas a descubrir en esa hora, y no a las tres de la mañana, que nadie sabe quién puede revocar el permiso de una herramienta un domingo.