La mayoría de equipos se prepara cuidadosamente para lanzar modelos. Muy pocos se preparan para fallos en producción. En IA en producción, los incidentes no son casos excepcionales: son una certeza operativa. Bypasses 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. Todas estas cosas le ocurren a equipos que están haciendo todo lo demás bien.
La diferencia entre un equipo que se recupera limpiamente y uno que no, no es si tuvieron un incidente. Es si tenían un playbook.
Para qué debe optimizar la respuesta a incidentes
Para sistemas de IA, la respuesta debe producir 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 mediante rollback o mitigación controlada, y evitar recurrencia con hardening de políticas y arquitectura.
La mayoría de equipos funciona razonablemente bien en el primero y el tercero. El segundo y el cuarto son donde aparecen los huecos.
Clasificación de severidad
Usa un modelo de tres niveles simple desde el principio. El objetivo no es la precisión teórica, sino la velocidad de decisión.
SEV-1: impacto activo grave, exposición legal o alto radio de clientes afectados. Deja todo. Respuesta completa de incidente.
SEV-2: fallo de control significativo con impacto real pero acotado. Investigación inmediata. Escalado parcial.
SEV-3: problema localizado sin impacto externo material por ahora. Asigna owner. Resuelve en horario normal.
El error más común es pasar los primeros 20 minutos de un incidente debatiendo la severidad. Define los umbrales de antemano y respétalos. Siempre puedes escalar si la situación cambia.
El flujo de respuesta en 60 minutos
Minutos 0–10: Detectar y clasificar
Confirma el origen de la señal: puede venir de una alerta, un reporte de cliente o una revisión de analista. Asigna una severidad provisional. Abre un canal dedicado de incidente y nombra un incident commander de inmediato. El incident commander toma decisiones. El resto ejecuta.
Minutos 10–20: Contener
Activa modo de política de emergencia, escalando de warn a block donde sea necesario. Desactiva la ruta, modelo, scope de tenant o feature flag afectado. Activa un fallback temporal de proveedor o modelo si hay uno disponible. El objetivo es parar la sangría, no entender aún por qué empezó.
Minutos 20–40: Preservar evidencia
Este paso es crítico y frecuentemente se salta en la prisa por arreglar las cosas. Haz snapshot de metadata de request y response, logs de decisión y versiones de reglas. Captura el contexto de modelo, proveedor y routing en el momento del incidente. Registra el timeline: quién cambió qué y cuándo. La evidencia capturada en los primeros 40 minutos es dramáticamente más fiable que la reconstruida después.
Minutos 40–60: Estabilizar y comunicar
Confirma que la mitigación está funcionando revisando métricas en vivo, sin asumir que el fix es efectivo por el hecho de haberlo desplegado. Publica un estado interno a ingeniería, producto, soporte y legal si el impacto supera un umbral que necesitan conocer. Prepara un mensaje externo si el impacto es visible para clientes. Mantén el mensaje factual y evita especular sobre la causa raíz hasta que la investigación esté completa.
Checklist de evidencia
Tu análisis post-incidente es tan bueno como la calidad de tu evidencia. Un set mínimo incluye: incident ID, severidad, owner y timestamps; tenants, casos de uso y endpoints afectados; versiones de rulepack y política activas en el momento del incidente; decisiones de block y warn con su justificación; deltas de coste, latencia y tasa de éxito durante la ventana del incidente; y acciones de contención con resultados de validación.
Si falta alguno de estos elementos, tu análisis de causa raíz será incompleto. La evidencia faltante es casi siempre una señal de un hueco de logging que hay que corregir antes del próximo incidente.
Estructura de revisión post-incidente
Mantenla sin blame y con foco técnico. El objetivo es entender qué pasó y corregirlo, no asignar responsabilidad.
Una estructura útil: qué pasó (solo hechos y timeline, sin interpretación todavía); por qué los controles existentes no lo evitaron; qué señal de detección se activó primero, o no se activó; qué cambios permitieron la recuperación; y qué correcciones permanentes se requieren ahora, con owners y fechas.
Cierra cada revisión con acciones concretas asignadas. Los ítems de acción sin asignar tienen una tasa de completitud cercana a cero.
Cómo evitar la recurrencia
La mejor respuesta a incidentes termina con controles de runtime más fuertes. Tras cada incidente: endurece las rutas de alto riesgo, amplía la cobertura de patrones en las áreas donde hubo huecos, reduce el tiempo de actualización de políticas para la clase de problema que causó el incidente, y añade tests sintéticos que repliquen el escenario del incidente para que las regresiones se detecten antes de llegar a producción.
Los incidentes son caros. Los incidentes repetidos de la misma clase son una señal de que tu proceso de respuesta genera recomendaciones pero no las implementa.
El estándar operativo
Si tu equipo no puede responder a incidentes de forma predecible y estructurada, aún no tienes gobernanza de IA lista para producción. El hueco normalmente no es técnico: nadie ha escrito el playbook y lo ha ensayado antes del primer incidente real.
Empieza simple. Un modelo de severidad claro, un flujo de respuesta y un checklist de evidencia son suficientes para comenzar. Haz un ejercicio de simulación mensual. La primera vez que uses el playbook bajo presión real, agradecerás haberlo practicado antes.