Runbook de incidente

Qué hacer cuando un agente hace algo que nadie esperaba. Un runbook es una guía de pasos para un incidente.
Los primeros 5 minutos cortan el daño: cortar las herramientas de escritura, pasar a solo lectura, apagar. Después vienen el diagnóstico con el registro de acciones y la comunicación. Al final viene un postmortem sin culpables: un análisis de qué falló en el sistema, no de quién falló.
Copiá el bloque con el botón de la esquina, o abrí el archivo en GitHub.
# Runbook: incidente con [nombre del agente]

<!--
Cómo usar esta plantilla:
- Un runbook es el procedimiento escrito para actuar en un incidente.
- Completala antes de que el agente salga a producción. En un incidente no hay tiempo para buscar dónde está cada cosa.
- Probá los interruptores una vez por [periodo]. Un interruptor sin probar no cuenta.
- Cada paso es una orden. Seguilos en orden.
-->

## Datos para tener a mano

- Dueño del agente: [nombre, contacto]
- Guardia: [rotación, contacto]
- Quién lidera el incidente: [rol]
- Cortar herramientas de escritura: [comando o panel]
- Pasar a solo lectura: [comando o panel]
- Apagar el agente: [comando o panel]
- Cola humana de respaldo: [dónde]
- Registro de acciones: [dónde y cómo se consulta]
- Revocar credenciales del agente: [cómo]
- Cancelar aprobaciones pendientes y trabajos en cola: [comando o panel]
- Revocar o rotar la clave de API del proveedor del modelo: [cómo]

## Síntomas

Usá este runbook si ves al menos uno de estos síntomas:

- El agente hizo una acción que nadie esperaba: un mensaje, un pago, un borrado, un cambio de datos.
- El gasto sube fuera de lo normal.
- El registro muestra la misma llamada repetida (un bucle).
- Llegan quejas por respuestas inventadas o datos de otra persona.
- El agente leyó contenido con instrucciones raras (posible inyección de instrucciones).
- La compuerta (el control que frena acciones antes de ejecutarlas) bloquea muchas más acciones que de costumbre.

## Primeros 5 minutos

1. Abrí un canal de incidente y anotá la hora (UTC). Nombrá a una persona que lidera el incidente.
2. Si el agente sigue actuando hacia afuera, cortá sus herramientas de escritura.
3. Si no sabés qué herramienta causa el daño, pasá el agente a solo lectura.
4. Si el daño sigue, apagá el agente. Mandá los casos nuevos a la cola humana.
5. Cancelá las aprobaciones pendientes y los trabajos en cola, en reintento o programados.
6. Si sospechás inyección o fuga de datos, revocá las credenciales del agente.
7. Si el gasto se dispara, revocá o rotá la clave de API del proveedor del modelo.
8. No borres ni edites nada. Guardá una copia del registro y de las trazas (el registro paso a paso de cada corrida).

No le pidas al agente que explique lo que hizo. Su explicación no es evidencia. Buscá la respuesta en el registro.

## Diagnóstico con el registro de acciones

| Pregunta | Dónde mirar | Respuesta |
|---|---|---|
| ¿Cuál fue la primera acción anómala y a qué hora? | Registro, ordenado por hora | [...] |
| ¿Qué contenido leyó el agente justo antes? | Traza de la corrida | [...] |
| ¿La acción pasó por la compuerta? ¿Con qué nivel y qué regla? | Registro: nivel y regla | [...] |
| ¿Alguien la aprobó? ¿Con qué información a la vista? | Registro: autorización | [...] |
| ¿Qué credencial usó y qué alcance tenía? | Registro (identidad) y gestor de credenciales | [...] |
| ¿Qué datos, clientes o montos tocó? | Registro: parámetros | [...] |
| ¿Se puede revertir? ¿Están los backups? | Backups en la otra cuenta | [...] |

## Comunicar

- A los [n] minutos: aviso interno al dueño, a seguridad y a [área].
- Si hay clientes afectados: un mensaje con qué pasó, qué hicimos y qué tienen que hacer ellos. Escribí horas y hechos, sin "podría haber".
- Si hay datos personales en juego: avisá a [responsable de datos]. Esa persona revisa el plazo legal de notificación de cada país.
- Actualización siguiente: cada [n] minutos hasta cerrar.

## Volver a encender

Encendé el agente de nuevo cuando se cumpla todo esto:

- [ ] Entendemos la causa.
- [ ] Hay un control nuevo que no depende del prompt.
- [ ] El caso está en el plan de evaluación y el agente lo pasa con pass^k.
- [ ] El agente vuelve en solo lectura o con confirmación, y sube de nivel por etapas.

## Postmortem sin culpables

<!--
El postmortem es el análisis escrito después del incidente.
Buscá el control que faltó, no a la persona que se equivocó.
Preguntá "¿por qué el agente tenía ese permiso?" antes que "¿quién lo dejó?".
Escribí la línea de tiempo en pasado simple y con hora.
-->

- Resumen (tres oraciones): [...]
- Impacto: [clientes, montos, datos, tiempo]
- Línea de tiempo (UTC): [hora: hecho]
- Causa: [qué control faltaba o falló]
- Qué funcionó: [...]
- Acciones, con dueño y fecha: [...]

## Por qué está esto acá

- Una base de producción se borró con sus backups por un token (credencial) con demasiado alcance. Quienes comentaron el caso lo leyeron como una falla de permisos y de backups: *An AI agent deleted our production database* (Hacker News, 2026).
- Quien deja que un agente consulte bases de producción lo hace con controles previos: cortar las consultas que no terminan, un rol de solo lectura y una forma de recuperar una tabla borrada: *Are people actually letting AI agents run SQL directly on production databases?* (r/dataengineering, 2026).
- Si un agente borró una base o sacó datos, el alcance ya estaba mal antes. Responde quien lo construyó y lo desplegó, no el agente: *AI agents aren’t ‘going rogue.’ Frontier labs are skipping security basics.* (r/cybersecurity, 2026).