Responder a incidentes, rollback y fallbacks

Un incidente de IA puede ser una caída técnica, una degradación de calidad, una filtración, un tool effect incorrecto o un coste fuera de control. La respuesta necesita una estructura común y rutas específicas según el impacto.

Durante el incidente, la prioridad es mitigar.

Declara temprano

Google SRE recomienda una respuesta estructurada con:

• mando claro;
• roles;
• registro de decisiones;
• comunicación.

Define criterios:

• severidad;
• usuarios;
• datos;
• derechos;
• efectos externos;
• duración.

No esperes a entender la causa para declarar.

Roles

En un incidente mayor:

Incident Commander Coordina.

Operations Mitiga.

Communications Actualiza.

SMEs Analizan.

En equipos pequeños, una persona puede cubrir varios roles, pero las funciones deben estar claras.

Mitigación antes de RCA

Opciones:

• desactivar tool;
• read-only;
• rollback;
• limitar tenant;
• volver a workflow;
• apagar RAG;
• cambiar a modelo anterior;
• bloquear inputs.

Google SRE enfatiza que la mitigación del impacto debe priorizarse antes de completar root-cause analysis.

Fallbacks

Un fallback debe estar evaluado.

Ejemplos:

Manual Humano completa la tarea.

Determinista Workflow básico.

Modelo anterior Si sigue disponible.

Degradado Sin tools.

No hagas fallback silencioso si cambia privacidad, calidad o funcionalidad.

Rollback no deshace efectos

Volver a código anterior no:

• borra emails enviados;
• revierte pagos;
• elimina datos copiados;
• restaura decisiones humanas.

Necesitas:

• compensación;
• reconciliación;
• comunicación.

Distingue rollback de software y reparación del estado.

Conserva evidencia

Durante incidente registra:

• timeline;
• versions;
• traces;
• deploys;
• decisiones;
• efectos;
• usuarios.

Sin copiar información sensible a canales no autorizados.

Incidentes de calidad

Ejemplo:

• respuestas erróneas desde 14:00.

Acción:

1. limitar función;
2. identificar versión;
3. tomar muestra;
4. reproducir;
5. rollback;
6. evaluar impacto.

No esperes a que los 5xx suban.

Incidentes de seguridad

Si:

• cross-tenant;
• secreto;
• tool no autorizada;

prioriza:

• detener capacidad;
• revocar;
• aislar;
• seguridad/privacidad.

La investigación técnica no sustituye obligaciones de notificación que puedan ser aplicables.

Comunicación

Define:

• frecuencia;
• audiencia;
• canal;
• owner.

No publiques causas especulativas.

Postmortem

Después:

• impacto;
• timeline;
• trigger;
• causas;
• factores;
• detección;
• mitigación;
• qué funcionó;
• qué no;
• acciones.

Google SRE promueve una cultura de postmortem sin culpabilización y basada en hechos y acciones.

Action items

Cada acción:

• owner;
• fecha;
• prioridad;
• criterio de cierre.

Evita:

«tener más cuidado».

Prefiere:

«añadir gate cross-tenant a suite de release».

Drills

Practica:

• provider outage;
• bad model release;
• prompt injection;
• tool misfire;
• runaway cost.

Usa el runbook real.

Severidad

Diseña una matriz:

SEV1: daño/seguridad amplio
SEV2: impacto importante
SEV3: degradación

No copies nombres; adapta.

AI-specific triggers

Declara incidente por:

• toxic output masivo;
• hallucination crítica;
• stale corpus;
• tool loops;
• cost runaway.

No solo uptime.

Decision log

Durante el incidente registra:

time
decision
owner
evidence
result

Evita perder contexto en chat.

Mitigation library

Prepara:

• disable model;
• disable tool;
• switch index;
• read-only;
• block tenant;
• manual fallback.

Estas herramientas deben existir antes.

Data repair

Después de una tool incorrecta:

• identifica objetos;
• compara;
• corrige;
• valida.

No confíes en rollback de código.

Customer remediation

Puede ser necesario:

• avisar;
• regenerar;
• corregir;
• compensar.

Coordina con negocio/legal según el caso.

Root cause vs contributing factors

Evita buscar una única causa.

Ejemplo:

• prompt permisivo;
• tool amplia;
• sin approval;
• eval no cubría caso.

Las cuatro contribuyen.

Postmortem quality

Un postmortem útil contiene:

• evidencia;
• fechas;
• acciones.

No opiniones culpabilizadoras.

Verify fixes

Cada action item debe tener un test.

Ejemplo:

«añadir control de tenant» → regression test.

Recurrence

Monitoriza:

• incidentes repetidos;
• action items vencidos.

Un postmortem sin ejecución no mejora fiabilidad.

Caso operativo: degradación tras un cambio de índice

Supón que el groundedness de una aplicación RAG cae después de publicar index_v42, pero disponibilidad y 5xx siguen normales.

El equipo debería poder:

1. declarar un incidente de calidad si supera el umbral de impacto;
2. congelar nuevos cambios;
3. comparar trazas de index_v41 y index_v42;
4. limitar la función o volver temporalmente al índice anterior;
5. tomar una muestra de respuestas afectadas;
6. verificar que el rollback recupera la métrica y no restaura fuentes retiradas;
7. abrir un postmortem;
8. añadir el patrón que escapó al regression set.

El artefacto de cierre no es solo el postmortem. Debe quedar también una prueba que reproduzca el fallo y una acción con owner que impida su reaparición silenciosa.

Ejercicio

Simula un incidente:

Una release ha enviado respuestas de otro tenant a tres usuarios.

Escribe:

• severidad;
• declaración;
• contención;
• rollback;
• evidencia;
• roles;
• comunicación;
• postmortem;
• 5 acciones.

Entregable

El entregable de esta lección es un proceso que reduce tiempo a mitigación y convierte incidentes en mejoras verificables. La siguiente lección transformará señales cotidianas, no solo incidentes, en un ciclo continuo de aprendizaje.