La mayoría de equipos se prepara para lanzar modelos.
Pocos equipos se preparan para fallos en producción.
En IA en producción, los incidentes no son excepciones. Son una certeza operativa:
- bypass de controles por prompt injection
- outputs inseguros llegando al usuario final
- fuga de datos sensibles
- deriva de políticas tras ciclos rápidos de release
Un buen playbook convierte el caos en un proceso controlado.
Objetivos de respuesta a incidentes
Para sistemas de IA, la respuesta debe optimizar cuatro resultados:
- Contener rápido el impacto en usuarios y negocio
- Preservar evidencia para análisis de causa raíz y compliance
- Recuperar operación segura con rollback o mitigación controlada
- Evitar recurrencia con hardening de políticas y arquitectura
Modelo de severidad (simple y útil)
Define niveles claros desde el principio:
- SEV-1: Impacto activo grave, exposición legal o alto radio de clientes afectados
- SEV-2: Fallo de control significativo con impacto real pero acotado
- SEV-3: Problema localizado sin impacto externo material por ahora
No lo compliques más de la cuenta. Umbrales claros mejoran la velocidad de decisión.
Flujo de respuesta en 60 minutos
Minuto 0-10: Detectar y clasificar
- Confirmar origen de la señal (alerta, reporte de cliente, revisión analista).
- Clasificar severidad provisional.
- Abrir canal de incidente y asignar incident commander.
Minuto 10-20: Contener
- Activar modo de política de emergencia (escalar block/warn según necesidad).
- Desactivar ruta, modelo, scope de tenant o feature flag afectado.
- Activar fallback temporal de proveedor/modelo.
Minuto 20-40: Preservar evidencia
- Snapshot de metadata de request/response, logs de decisión y versión de reglas.
- Capturar contexto de modelo/proveedor/routing del momento del incidente.
- Registrar timeline: quién cambió qué y cuándo.
Minuto 40-60: Estabilizar y comunicar
- Verificar efectividad de mitigación con métricas en vivo.
- Publicar estado interno (ingeniería, producto, soporte y legal si aplica).
- Preparar comunicación externa si el impacto supera umbral acordado.
Checklist de evidencia
El análisis posterior depende totalmente de la calidad de evidencia.
Set mínimo:
- Incident ID, severidad, owner y timestamps
- Tenants/casos de uso/endpoints afectados
- Versiones de policy y rulepack activas
- Decisiones block/warn con justificación
- Deltas de coste, latencia y tasa de éxito
- Acciones de contención y validación
Estructura de revisión post-incidente
Hazla sin blame y con foco técnico:
- Qué pasó (hechos y timeline)
- Por qué los controles no lo evitaron
- Qué señal detectó primero (o falló)
- Qué cambios permitieron recuperar de forma segura
- Qué correcciones permanentes quedan comprometidas
Luego asigna acciones concretas con owner y fecha.
Cómo evitar recurrencia
La mejor respuesta a incidentes termina con controles de runtime más fuertes:
- endurecer rutas de alto riesgo
- ampliar cobertura de patrones donde hubo huecos
- reducir tiempo de actualización de políticas críticas
- añadir tests sintéticos que repliquen el escenario del incidente
Los incidentes son caros. Los incidentes repetidos son inaceptables.
Conclusión
Si tu equipo no puede responder a incidentes de forma predecible,
aún no tienes gobernanza de IA lista para producción.
Empieza con un playbook simple. Ensáyalo cada mes.
Velocidad, evidencia y disciplina son lo que protege la confianza.