Playbook de incidente de IA

Mientras el daño sigue ocurriendo, la prioridad es detenerlo, no explicarlo. El playbook ordena la contención de lo más pequeño a lo más grande: primero limitar o suspender la herramienta o la función afectada, después volver a la última versión validada si el problema coincide con un despliegue, y apagar el asistente solo si lo anterior no basta. Las medidas pequeñas son más rápidas, se revierten con más facilidad y dejan funcionando lo que no está roto.

Antes de tocar nada se conservan los registros del incidente. La investigación depende de ellos, y borrar o rotar logs por prisa borra justo la evidencia que explicará la causa.

Volver a una versión anterior solo ayuda si esa versión es una que se sabe segura. El playbook lo dice con una regla: la última versión con estado «validada», es decir, que pasó el banco de evaluación antes de salir a todos. La versión inmediatamente anterior a la que falló no siempre cumple, y la más reciente casi nunca: de eso trata el historial de despliegues.

Consulta los despliegues y aplica la regla de reversión del playbook. Anota la versión a la que se volvió.

La suspensión de una herramienta es la medida que más rápido detiene un daño cuando se sabe por dónde sale. Aquí lo que se veía en las conversaciones eran entregas de otros alumnos, y eso apunta a la herramienta que las muestra. Suspenderla quita capacidad al asistente, pero no lo apaga: sigue respondiendo dudas de los cursos.

Lee la línea de tiempo y anota la herramienta que se suspendió como primera medida de contención.

Los plazos de comunicación de un playbook corren desde un hecho concreto: aquí, la clasificación del incidente. Cada nivel de severidad tiene su plazo para avisar a la dirección, y el aviso tardío es un hallazgo del post-mortem aunque la contención haya ido bien. Para medirlo se suma el plazo a la hora de clasificación y se compara con la hora en que se avisó.

Calcula cuántos minutos después del plazo del playbook llegó el primer aviso a la dirección.

El primer aviso de un incidente de IA se escribe con lo que hay, no con lo que se quisiera. Cuenta qué se sabe, qué no se sabe todavía, qué ya se contuvo y a qué hora habrá la siguiente actualización. Callar lo que no se sabe obliga a la dirección a adivinarlo; inventarlo, a corregirse después. Y la pregunta de quién tuvo la culpa no entra: se responde en el post-mortem, con los hechos completos.