Tu chatbot inventa una política de devolución, tu sistema de scoring deniega crédito por un sesgo no detectado, o un prompt injection extrae datos de clientes. ¿Tienes un plan? Te explicamos cómo construir un plan de incidentes específico para IA con las 6 fases, los roles clave y un runbook operativo
Los planes de incidentes de TI existen desde hace décadas. Toda empresa medianamente seria tiene un procedimiento para responder a una caída de servidor, una brecha de seguridad o una pérdida de datos. Pero los incidentes de IA son diferentes.
Un sistema de IA puede fallar de formas que ningún plan de incidentes tradicional contempla: alucinaciones que generan información falsa en comunicaciones al cliente, sesgos que discriminan sistemáticamente a un colectivo sin que nadie se dé cuenta, prompt injections que extraen datos confidenciales, o degradaciones graduales del rendimiento que pasan desapercibidas durante semanas.
El AI Act exige explícitamente que los deployers de sistemas de alto riesgo tengan procedimientos de gestión de incidentes. Pero incluso para sistemas de riesgo limitado o mínimo, un plan de incidentes de IA no es un lujo: es una necesidad operativa. Porque cuando tu IA falla —y en algún momento fallará—, la diferencia entre un incidente menor y una crisis está en la velocidad y calidad de tu respuesta.
En este artículo te explicamos los tipos de incidentes específicos de IA, las 6 fases de un plan de respuesta, los roles que necesitas definir y cómo construir un runbook operativo que tu equipo pueda ejecutar cuando las cosas fallen.
Tipos de incidentes de IA (y por qué son diferentes)
Un incidente de IA no es lo mismo que un incidente de TI clásico. La diferencia fundamental es que muchos fallos de IA son silenciosos, progresivos y difíciles de detectar con las herramientas de monitorización tradicionales.
- Privacidad/PII: Acceso no autorizado a datos personales a través del sistema de IA, fuga de datos en respuestas del modelo, uso incompatible con la finalidad declarada. Ejemplo: un chatbot que incluye datos de un cliente en la respuesta a otro.
- Seguridad: Prompt injection (manipulación del modelo a través de entradas maliciosas), exfiltración de datos, caída de la API del proveedor de IA, compromiso de credenciales de acceso al modelo.
- Ético/Contenido: Sesgo sistemático detectado en las decisiones del modelo, generación de contenido ofensivo o desinformación, daño reputacional por output inapropiado.
- Operacional: Alucinaciones críticas (datos falsos en comunicaciones externas), errores masivos en lote, degradación gradual de la calidad del modelo, indisponibilidad del servicio.
Cada tipo de incidente requiere una respuesta diferente. Un incidente de privacidad activa obligaciones legales (notificación a la autoridad en 72 horas según RGPD). Un incidente ético puede requerir la desactivación inmediata del sistema. Un incidente operacional puede resolverse con un rollback a una versión anterior.
Niveles de severidad
- Alta: Impacto en clientes, datos personales comprometidos, incumplimiento legal, daño reputacional. Acción inmediata: contención en menos de 2 horas.
- Media: Impacto interno relevante, degradación de calidad significativa, riesgo de escalada si no se actúa. Acción: clasificación y contención en menos de 8 horas.
- Baja: Incidente acotado, sin impacto externo, detectado en fase de piloto o en entorno controlado. Acción: registro y corrección en el siguiente ciclo.
El mayor riesgo de los incidentes de IA no es que ocurran. Es que nadie se entere hasta que es demasiado tarde.
Las 6 fases del plan de respuesta a incidentes de IA
- Detección. El primer paso es saber que algo va mal. Para sistemas de IA, esto requiere: alertas automáticas (latencia, tasas de error, acceso anómalo), monitorización de métricas de calidad (tasa de alucinaciones, faithfulness si usas RAG, métricas de sesgo), un canal de reporte para usuarios internos y externos (correo, Teams, ticket), y logging activo de todas las interacciones con retención mínima de 90 días.
- Contención. Una vez detectado el incidente, la prioridad es limitar el daño. Las acciones típicas incluyen: desactivar la integración del sistema de IA (modo degradado), limitar el alcance (restringir a usuarios internos, bloquear canales públicos), activar el fallback humano (redirigir consultas a agentes), y preservar evidencias (logs, capturas, configuración del momento del incidente).
- Notificación. Según el tipo de incidente, pueden activarse obligaciones legales. Para incidentes de privacidad con datos personales comprometidos: notificación a la autoridad de protección de datos en 72 horas (RGPD), evaluación de la obligación de notificar a los afectados, comunicación al DPO y al comité de IA. Para incidentes de alto riesgo AI Act: registro del incidente en el expediente técnico, comunicación a las partes interesadas.
- Erradicación. Identificar y eliminar la causa raíz. Puede implicar: corregir el prompt del sistema, actualizar la base de conocimiento (si es RAG), reentrenar o reconfigurar el modelo, parchear una vulnerabilidad de seguridad, o modificar los guardrails del sistema.
- Recuperación. Restaurar el servicio de forma controlada: verificar la integridad del sistema antes de reactivar, hacer un despliegue gradual (primero interno, luego externo), monitorizar de forma intensiva durante las primeras 24-48 horas post-restauración, y confirmar que las métricas de calidad vuelven a los umbrales definidos en el expediente técnico.
- Lecciones aprendidas. La fase más ignorada y la más valiosa. Incluye: informe de incidente (causa raíz, impacto, tiempo de respuesta, medidas), post-mortem con los equipos involucrados, actualización de controles preventivos, y revisión del propio plan de incidentes si se han identificado carencias.
Semáforo: En el framework de gobernanza IA, un incidente de severidad alta activa automáticamente el semáforo Rojo (KILL) para ese sistema. No se reactiva hasta completar las fases 4 y 5, y la reactivación requiere aprobación del AI Steering Committee.
Roles clave: quién hace qué cuando falla la IA
Un plan de incidentes sin roles claros es un documento inútil. Define estas responsabilidades antes de que las necesites:
- Product Owner (PO): Responsable último del sistema. Accountable (A) en la matriz RACI. Aprueba la contención y la restauración. Comunica a stakeholders de negocio.
- Seguridad/CISO: Responsible (R) en incidentes de seguridad y privacidad. Lidera la contención, gestiona la forense, coordina la notificación técnica.
- TI/Plataforma (on-call): Responsible (R) en continuidad y disponibilidad. Ejecuta el modo degradado, gestiona el rollback, monitoriza la recuperación.
- Legal/DPO: Consulted (C). Evalúa las obligaciones de notificación (RGPD 72h, AI Act), gestiona la comunicación legal, documenta para el expediente técnico.
- Data Owner/Steward: Consulted (C). Verifica la integridad de los datos, evalúa si la causa raíz está en los datos de entrenamiento o en la base de conocimiento.
El runbook: de la teoría a la acción ejecutable
El plan de incidentes define el qué y el quién. El runbook define el cómo. Es el documento operativo que tu equipo de guardia puede seguir paso a paso a las 3 de la mañana cuando suena la alerta.
Un runbook de incidentes de IA debe incluir:
- Casos cubiertos: Lista explícita de escenarios (caída de API, degradación de índice RAG, fuga de credenciales, prompt injection, alucinación crítica, sesgo detectado).
- Procedimiento paso a paso: Para cada escenario, los pasos concretos: qué comando ejecutar, qué sistema desactivar, a quién llamar, qué canal usar.
- Criterios de escalado: Cuándo pasar de severidad baja a media, de media a alta. Qué umbrales activan la escalada. Quién tiene autoridad para escalar.
- Evidencias a capturar: Extractos de logs, capturas de pantalla, configuración del momento, tickets, comunicaciones. Todo con sello temporal.
- Contactos de emergencia: Nombres, correos, teléfonos. No solo los internos: también el contacto del proveedor de IA, el DPO y el contacto de la autoridad de supervisión si es necesario.
El runbook debe ser práctico, no teórico. Si tu equipo no puede seguirlo sin necesitar explicaciones adicionales, no está terminado. La mejor prueba: haz un simulacro. Presenta un escenario ficticio y mide cuánto tarda tu equipo en seguir el runbook. Si tarda más de lo previsto, revisa el documento.
Obligaciones regulatorias: AI Act, RGPD y NIS2
El plan de incidentes de IA no es solo una buena práctica. Tres regulaciones europeas lo exigen o lo implican:
- AI Act: Los deployers de sistemas de alto riesgo deben notificar incidentes graves a las autoridades y documentar todos los incidentes en el expediente técnico. El artículo 26 establece obligaciones de post-market monitoring que incluyen la gestión de incidentes.
- RGPD: Si un incidente de IA compromete datos personales, se activa la obligación de notificación a la autoridad de protección de datos en 72 horas (art. 33) y, si hay riesgo alto para los interesados, notificación a los afectados (art. 34).
- NIS2: Para entidades esenciales e importantes, la directiva NIS2 exige planes de respuesta a incidentes de seguridad con notificación en 24 horas y un informe detallado en 72 horas. Si tu sistema de IA es parte de una infraestructura crítica, NIS2 aplica.
Consejo: Integra tu plan de incidentes de IA con el plan de incidentes de seguridad existente. No necesitas dos planes separados: necesitas un plan unificado que cubra los escenarios específicos de IA con los mismos SLAs y la misma cadena de escalado.
Simulacros: la prueba de que tu plan funciona
Un plan de incidentes que no se ha probado es una teoría, no un plan. Los simulacros son la única forma de verificar que tu equipo sabe qué hacer, que los contactos están actualizados, que los procedimientos son ejecutables y que los tiempos de respuesta son realistas.
Recomendamos al menos dos simulacros al año:
- Simulacro de alucinación crítica: Escenario: tu chatbot de ecommerce ha estado generando información falsa sobre políticas de devolución durante las últimas 4 horas. ¿Cuánto tarda tu equipo en detectarlo, contenerlo y comunicarlo?
- Simulacro de brecha de datos: Escenario: se detecta que un prompt injection ha provocado que el modelo exponga datos de clientes en sus respuestas. ¿Se activa la notificación RGPD en menos de 72 horas? ¿Se preservan las evidencias?
Después de cada simulacro, documenta los hallazgos y actualiza el plan. Los simulacros no son un examen: son una oportunidad de mejora.
El plan de incidentes dentro del marco de gobernanza IA
El plan de incidentes no es un documento aislado. Se integra en el ecosistema de gobernanza de tu organización:
- Expediente técnico: La sección 14 del expediente técnico registra todos los incidentes y los post-mortems. Cada incidente cerrado alimenta el expediente con evidencias y lecciones.
- Sistema de Gates: En la Gate 2 (pre-despliegue), se verifica que el plan de incidentes está definido y que el runbook es ejecutable. Sin plan de incidentes, la puerta no se abre.
- Semáforo GO/FIX/KILL: Un incidente de severidad alta activa el Rojo (KILL) automáticamente. La reactivación requiere pasar por las fases 4-5 y la aprobación del AI Steering Committee.
- FRIA: Si un incidente revela un riesgo no identificado en la FRIA, se dispara una revisión de la evaluación de impacto. Los incidentes son triggers de recategorización.
- Política IA Lite: El principio de reversibilidad se materializa en el modo degradado del plan de incidentes. El principio de observabilidad se materializa en el logging y la detección.
Conclusión: prepara la respuesta antes de necesitarla
El plan de incidentes de IA es uno de esos documentos que esperas no necesitar nunca. Pero cuando lo necesitas, agradeces haberlo preparado. La diferencia entre una empresa que gestiona un incidente de IA con profesionalidad y una que improvisa está en la preparación previa.
No necesitas un plan perfecto. Necesitas un plan que exista, que tu equipo conozca, que se haya probado al menos una vez y que se actualice cuando las cosas cambien. Con las 6 fases, los roles claros y un runbook ejecutable, tienes la base.
Si necesitas ayuda para diseñar tu plan de incidentes de IA, construir el runbook operativo o realizar simulacros con tu equipo, en Impulsa3 te acompañamos en todo el proceso.
impulsa3.com · Transformación Digital e IA para pymes y ecommerce · servicios@impulsa3.com
La respuesta operativa se completa con supervisión humana en IA.
