Playbook de Respuesta a Incidentes de IA: Qué Hacer Cuando Tu Modelo Se Equivoca

Los incidentes de IA no son como los incidentes de software. Cuando un sistema de software tiene un bug, encuentras la línea de código, la corriges y despliegas el parche. El modo de fallo es determinístico: la misma entrada siempre produce la misma salida incorrecta.

Los modos de fallo de la IA son estadísticos. Un modelo no "se rompe" en el sentido tradicional — produce la salida incorrecta con alguna probabilidad a través de alguna distribución de entradas. El fallo puede haber estado ocurriendo durante semanas antes de que alguien lo notara. La población afectada puede ser identificable y grande, lo que activa obligaciones de divulgación. La causa raíz puede ser algo que ocurrió durante el entrenamiento — meses antes de que el fallo apareciera — haciendo la remediación significativamente más complicada que un rollback de código.

Estas diferencias requieren un proceso distinto de respuesta a incidentes. Este playbook cubre el ciclo de vida completo: detección, triaje, investigación, remediación, divulgación y revisión post-incidente.

Clasificación de Severidad de Incidentes

No todos los fallos de IA son iguales. Clasifica la severidad inmediatamente al detectarlos para asegurar una respuesta proporcional.

Severidad	Definición	Ejemplos
P0 — Crítico	El sistema de IA causó o contribuyó a daño físico; pérdida financiera mayor a $100K; brecha regulatoria; o más de 1,000 individuos afectados por decisiones incorrectas	Recomendación médica incorrecta ejecutada; decisiones de préstamo discriminatorias a escala; brecha de datos notificable bajo GDPR que involucra procesamiento de IA
P1 — Alto	El sistema de IA produjo salidas sistemáticamente incorrectas para un grupo definido; brecha de cumplimiento descubierta; riesgo reputacional si el incidente se hiciera público	Modelo de detección de fraude bloqueando un grupo demográfico a tasas significativamente más altas; LLM generando afirmaciones factualmente falsas en contexto orientado al cliente
P2 — Medio	El sistema de IA produce salidas incorrectas para un subconjunto de entradas; sin daño inmediato a individuos; corregible sin notificación	Modelo de resumen de documentos fallando en un formato específico de documento; modelo de recomendación produciendo resultados irrelevantes para una categoría específica de entrada
P3 — Bajo	Degradación de calidad notada; sin daño individual; sin implicación de cumplimiento	Métricas de precisión del modelo declinando hacia pero no más allá del umbral de alerta; reducción en calidad de salida reportada por usuarios

Escalación de severidad: Comienza con tu mejor estimación y escala si la investigación revela un alcance más amplio. Es mejor sobre-clasificar y des-escalar que sub-clasificar y perder una fecha límite de notificación.

Fase 1: Detección y Triaje

Objetivo: 0-2 horas para incidentes P0 y P1

Fuentes de Detección

Los incidentes de IA típicamente aparecen a través de uno de cinco canales. Asegúrate de que tu monitoreo cubra todos:

Alertas de monitoreo automatizado — brechas de umbral en métricas de precisión del modelo, anomalías en distribución de salidas, picos en latencia o tasa de error
Reportes de usuarios — tickets de soporte al cliente, reportes internos de empleados usando herramientas de IA
Anomalías en métricas downstream — métricas de negocio comportándose inesperadamente en sistemas que dependen de salidas de IA (ej., tasas de aprobación de préstamos cambiando sin cambios en la política)
Anomalías en logs de auditoría — patrones en el log de auditoría que indican comportamiento inesperado (ej., tasas de anulación inusualmente altas de revisores humanos, patrones de entrada inusuales)
Reportes de terceros — consulta regulatoria, consulta periodística, notificación de socio, divulgación de investigador de seguridad

Lista de Verificación de Triaje

Completar dentro de las primeras 2 horas para P0/P1:

Paso 1: Determinar severidad

¿Cuál es la naturaleza del fallo? (clasificación incorrecta, generación incorrecta, salida faltante, modelo no disponible)
¿Están afectadas personas individuales? Si es así, ¿cuántas y con qué gravedad?
¿Hay una obligación regulatoria de reporte (EU AI Act, GDPR Artículo 33, HIPAA)?
Asignar severidad inicial: P0 / P1 / P2 / P3

Paso 2: Identificar el sistema afectado

¿Qué sistema está afectado? (Referenciar ID de inventario de modelos)
¿Cuál es la versión actual del modelo en producción?
¿Cuándo se desplegó esta versión? ¿Ha cambiado recientemente?
¿El fallo está limitado a una versión del modelo, o podría afectar otros despliegues?

Paso 3: Estimar alcance

¿Cuánto tiempo ha estado ocurriendo probablemente el fallo? (Revisar logs antes de la detección)
¿Cuántas decisiones o salidas están potencialmente afectadas?
¿El fallo es en todas las entradas o en un subconjunto específico?

Paso 4: Preservar evidencia — hacer esto antes de cualquier remediación

Exportar logs de auditoría cubriendo el período del incidente (mínimo: 48 horas antes de la primera anomalía detectada hasta ahora)
Guardar entradas y salidas de muestra que demuestren el fallo
Registrar la versión y configuración actual del modelo
Capturar pantalla de dashboards de monitoreo mostrando la anomalía
NO actualizar, revertir o modificar el modelo antes de preservar la evidencia

Paso 5: Notificaciones inmediatas

P0/P1: Propietario del Sistema de IA → Oficial de Riesgo de IA → CISO/DPO → Legal (misma hora)
P2: Propietario del Sistema de IA → Oficial de Riesgo de IA (dentro de 4 horas)
P3: Propietario del Sistema de IA (registrar y revisar)

Contención Inmediata

Después de preservar la evidencia, decidir sobre contención:

Opción A: Redireccionamiento de tráfico — Redirigir tráfico lejos de la versión afectada del modelo (a una versión de respaldo, lógica de fallback o flujo de trabajo solo humano). Usar cuando un fallback esté disponible y el fallo sea específico de la versión.

Opción B: Pausar el caso de uso — Suspender el procesamiento asistido por IA y dirigir todos los casos a revisión humana o procesamiento manual. Usar cuando no exista un fallback seguro o cuando la revisión humana sea requerida por la severidad del incidente.

Documenta tu decisión de contención y su justificación. La elección entre Opción A y Opción B, y el momento de esa decisión, será revisada en la revisión post-incidente y puede ser examinada por reguladores.

Fase 2: Investigación

Objetivo: 2-24 horas para P0/P1; hasta 5 días para P2

Marco de Análisis de Causa Raíz

Los incidentes de IA típicamente se rastrean a una de cuatro causas raíz. Trabaja cada una sistemáticamente:

Tipo de Causa Raíz 1: Cambio de comportamiento del modelo

¿Ha cambiado la versión del modelo recientemente? Revisa el Log de Cambios del Modelo.
Para modelos de API de proveedor: ¿el proveedor actualizó el modelo sin aviso? Compara el comportamiento actual del modelo contra tu línea base registrada.
Para modelos internos: ¿se reentrenó el modelo recientemente? ¿Con datos diferentes?
Diagnóstico: ejecuta tu conjunto de evaluación estándar a través de la versión actual del modelo y compara puntuaciones con la línea base pre-incidente.

Tipo de Causa Raíz 2: Cambio de distribución de datos

¿Las entradas que fallan son cualitativamente diferentes de los datos de entrenamiento del modelo?
¿Ha cambiado algo en tu pipeline de datos upstream que afecte lo que el modelo recibe?
Diagnóstico: compara la distribución estadística de entradas recientes con la distribución de datos de entrenamiento. Señala entradas que caen fuera de la distribución de entrenamiento.

Tipo de Causa Raíz 3: Bug de prompt o integración

Para sistemas basados en LLM: ¿ha cambiado la plantilla de prompt? ¿Hay un bug en cómo se ensambla el contexto?
Para sistemas de pipeline: ¿ha cambiado la lógica de preprocesamiento de una manera que produce entradas malformadas?
Diagnóstico: rastrea manualmente un caso fallido a través de la capa de integración, paso a paso, antes de que el modelo lo reciba.

Tipo de Causa Raíz 4: Fallo de supervisión humana

¿Los revisores humanos estaban aprobando salidas que deberían haber rechazado?
¿La tasa de anulación es inusualmente baja? (Posible rubber-stamping)
¿Los revisores recibieron contexto suficiente para identificar el fallo?
Diagnóstico: revisar el log de auditoría de decisiones de revisión humana durante el período del incidente. Calcular tasa de anulación y tiempo-de-decisión. Entrevistar revisores.

Evidencia a Recopilar

Tipo de Evidencia	Dónde Encontrarla	Por Qué Importa
Versión del modelo al momento del incidente	Inventario de modelos + logs de despliegue	Establece exactamente qué estaba ejecutándose
Muestra de entradas y salidas afectadas	Logs de auditoría	Caracteriza el patrón de fallo
Rendimiento del modelo en eval set antes y después	Registros de validación del modelo	Cuantifica el cambio de rendimiento
Decisiones de revisión humana durante el período del incidente	Logs de auditoría	Determina si un fallo de supervisión contribuyó
Estadísticas de datos upstream	Logs del pipeline de datos	Identifica cambio de distribución
Notificaciones de cambios del proveedor (si aplica)	Email/changelogs de API	Establece si el proveedor causó el cambio

Confirmación de Alcance

Una vez que tengas una hipótesis para la causa raíz, ejecuta una confirmación de alcance:

Identifica la población completa de entradas procesadas durante el período afectado
Aplica la hipótesis de causa raíz para clasificar cada una como probablemente-afectada o no
Para una muestra de casos probablemente-afectados, verifica el fallo manualmente
Produce un conteo confirmado y porcentaje de decisiones afectadas

Este número es lo que reportas a reguladores y lo que determina las obligaciones de notificación individual. Tómate el tiempo para hacerlo bien — tanto sobre-reportar como sub-reportar tienen consecuencias.

Fase 3: Remediación

La remediación ocurre en tres fases con cronogramas distintos.

Remediación Inmediata (Día 1-2)

Revertir a la última versión conocida como buena del modelo, O suspender el caso de uso si no existe una versión segura
Verificar que el rollback realmente resuelve el fallo probando en los tipos de entrada afectados
Restaurar operación normal solo después de confirmar la resolución — no antes

Remediación a Corto Plazo (Días 3-30)

Identificar todos los casos procesados durante el período del incidente que pueden haber sido afectados
Re-procesar casos afectados con el modelo corregido (o revisión humana, dependiendo de la severidad)
Notificar a individuos afectados si lo requiere la regulación o la política (ver Fase 4)
Implementar monitoreo mejorado dirigido al patrón de fallo para detectar recurrencia

Remediación a Largo Plazo (Días 30+)

Causa Raíz	Corrección a Largo Plazo
Cambio de comportamiento del modelo (proveedor)	Negociar fijación de versión; evaluar scorecard del proveedor; considerar proveedor alternativo o modelo propio
Cambio de comportamiento del modelo (reentrenamiento interno)	Mejorar proceso de evaluación antes de promover modelos reentrenados a producción; agregar período de prueba A/B
Cambio de distribución de datos	Implementar monitoreo de distribución de entrada; actualizar datos de entrenamiento para incluir la nueva distribución
Bug de prompt/integración	Agregar pruebas de integración cubriendo el tipo de caso fallido; agregar validación de entrada antes de la inferencia del modelo
Fallo de supervisión humana	Recalibrar revisores; ajustar interfaz de revisión para mostrar contexto relevante; revisar configuración de umbrales

Fase 4: Divulgación

Divulgación Interna

P0: Notificación a nivel de junta directiva dentro de 24 horas de la confirmación de severidad
P1: Notificación ejecutiva (C-suite) dentro de 24 horas; notificación a junta directiva en la próxima reunión regular o antes si está justificado

Divulgación Regulatoria

Las obligaciones de divulgación regulatoria dependen de la jurisdicción, la industria y lo que ocurrió:

EU AI Act (si aplica): El Artículo 73 requiere que los proveedores de sistemas de IA de alto riesgo reporten incidentes graves a la autoridad de vigilancia del mercado del estado miembro. "Incidente grave" significa mal funcionamiento o uso que lleva a muerte, daño físico grave o daño significativo a la propiedad. Cronograma: sin demora indebida.

GDPR Artículo 33: Las brechas de datos personales (incluyendo las causadas por o que involucran procesamiento de IA) deben ser reportadas a la autoridad supervisora dentro de 72 horas. Si el procesamiento de IA causó decisiones incorrectas que afectan a individuos cuyos datos personales estaban involucrados, evalúa si esto constituye una brecha.

Regla de Notificación de Brecha HIPAA (EE.UU., salud): Si PHI estuvo involucrada en el incidente, evalúa las obligaciones de notificación de brecha. Los asociados de negocios deben notificar a las entidades cubiertas dentro de 60 días.

SR 11-7 (reguladores bancarios de EE.UU.): Los eventos de riesgo de modelo deben ser documentados y reportados a través de los canales existentes de reporte de gestión de riesgo de modelo. Los incidentes P0 pueden requerir notificación directa al regulador dependiendo del acuerdo de tu institución con su regulador principal.

Documenta tu evaluación de divulgación incluso si determinas que no se requiere notificación. El análisis documentado que muestra por qué concluiste que la notificación no era requerida es en sí mismo un artefacto de cumplimiento.

Notificación Individual

Si individuos recibieron decisiones incorrectas generadas por IA que afectaron sus derechos o acceso a servicios, Legal asesorará sobre las obligaciones de notificación (que varían por jurisdicción e industria). La investigación técnica debe producir: la lista de individuos afectados, la naturaleza de la decisión incorrecta que recibieron y el resultado corregido.

Fase 5: Revisión Post-Incidente

Realizar dentro de 10 días hábiles del cierre del incidente. Documentar los resultados y almacenar con el registro del incidente.

Reconstrucción del cronograma

¿Cuándo comenzó el fallo? (No cuándo fue detectado — ¿cuándo comenzó realmente?)
¿Cuándo fue detectado?
¿Cuándo fue contenido?
¿Cuándo fue resuelto?
¿Cuál fue el tiempo total desde el inicio hasta la resolución?

Causa raíz confirmada

¿Cuál fue la causa raíz confirmada?
¿Qué evidencia la confirmó?

Lecciones aprendidas

¿Qué controles fallaron en prevenir o detectar este incidente?
¿Qué controles funcionaron como se pretendía?
¿Se siguió el proceso de respuesta? Si no, ¿por qué no?
¿Qué habría detectado esto más rápido?

Actualizaciones de políticas y procesos

¿Qué cambios al monitoreo, umbrales o procesos de revisión prevendrán la recurrencia?
¿Qué cambios al proceso de respuesta a incidentes mejorarían la respuesta futura?
Responsable y fecha límite para cada cambio

Actualizaciones de documentación de gobernanza de modelos

Actualizar la entrada del Inventario de Modelos (estado de validación, enlace al log del incidente)
Actualizar la tarjeta del modelo si la causa raíz revela limitación de capacidad
Actualizar el Log de Cambios del Modelo si se realizó un rollback

Errores Comunes en Incidentes de IA

No preservar logs antes de la remediación. El error más común y dañino. Una vez que reviertes el modelo o limpias las colas de procesamiento, la evidencia de exactamente qué ocurrió puede desaparecer. Preserva primero, remedia después — siempre.

Asumir que el rollback arregló todo sin validación. Prueba en los tipos de entrada específicos que dispararon el fallo antes de declarar el incidente resuelto. Los rollbacks pueden introducir problemas diferentes, o la causa raíz puede no ser la versión del modelo en absoluto.

Tratar el incidente como puramente técnico y no involucrar a Legal y Cumplimiento. Incluso los incidentes P2 pueden tener implicaciones regulatorias que no son aparentes al principio. Incluye a Legal temprano y déjalos determinar si se requiere reporte — esa determinación no debe ser hecha solo por el equipo de ingeniería.

Estimación de alcance basada en intuición en lugar de datos. "Creemos que unos cientos de registros fueron afectados" no es una estimación de alcance aceptable para reporte regulatorio. Ejecuta el análisis. Si no puedes ejecutarlo con precisión a tiempo para una fecha límite regulatoria, dilo y proporciona tu mejor estimación con límites de incertidumbre explícitos.

No actualizar el inventario de modelos después del incidente. La entrada del inventario debe reflejar lo que ocurrió: estado de validación, referencia al log del incidente y cualquier cambio al nivel de supervisión. Los auditores verifican la consistencia entre registros de incidentes y entradas del inventario.

Conectando Logs de Auditoría con la Investigación

El análisis de causa raíz para incidentes de IA depende completamente de la calidad y completitud de tus logs de auditoría. Si tus logs no capturan la versión del modelo al momento de la inferencia, no puedes confirmar cuándo ocurrió un cambio de versión. Si no capturan la entrada completa, no puedes caracterizar el patrón de fallo. Si no capturan las decisiones de revisión humana, no puedes evaluar el fallo de supervisión como factor contribuyente.

Ertas Data Suite genera registros de auditoría inmutables y con marca de tiempo para cada paso de procesamiento — quién lo ejecutó, qué entradas se usaron, cuáles fueron las salidas y qué operador lo revisó. Para investigaciones de incidentes, esto significa que tienes un registro completo y a prueba de manipulaciones para trabajar en lugar de reconstruir eventos de logs incompletos.

Agenda una llamada de descubrimiento con Ertas →