Por qué los incidentes de IA son diferentes

Un incidente de IA rara vez se parece a una caída clásica de sistemas. Los modos de fallo más costosos son silenciosos: un modelo que deriva y empieza a discriminar, un asistente que alucina información ante clientes, un sistema de scoring que excluye sistemáticamente a un colectivo. Sin monitoreo específico, estos fallos pueden operar durante meses antes de detectarse, acumulando daño legal, financiero y reputacional.

Qué cuenta como incidente de IA

Conviene definirlo de forma amplia en la política interna: resultados erróneos o dañinos con impacto en personas, comportamiento discriminatorio, fugas de datos a través de prompts o salidas del modelo, uso no autorizado de herramientas de IA (la llamada IA en la sombra), fallos de proveedores de IA de terceros y degradación significativa del rendimiento del modelo respecto a lo validado.

Fase 1: preparación

La respuesta empieza antes del incidente: un inventario actualizado de sistemas de IA con responsables nombrados, umbrales claros de qué constituye un incidente y de su severidad, un runbook por sistema crítico (cómo apagarlo, a qué proceso manual revertir) y registros activados. Tanto ISO/IEC 42001 como el marco NIST AI RMF (función Manage) exigen procesos documentados de gestión de incidentes.

Fase 2: detección

Combine monitoreo técnico (métricas de calidad y deriva del modelo, alertas), canales humanos (vías claras para que empleados y clientes reporten resultados extraños sin fricción) y revisión periódica de los registros. Muchos incidentes de IA los detecta primero un usuario, no un sistema.

Fase 3: contención y respuesta

Las decisiones clave deben estar predefinidas: cuándo desactivar el sistema o pasar a supervisión humana total, quién tiene autoridad para hacerlo y cuál es el proceso alternativo mientras tanto. Preserve la evidencia (entradas, salidas, versiones del modelo, registros): la necesitará para el análisis de causa raíz y ante cualquier autoridad.

Fase 4: notificación

Defina la escalada interna (dirección, legal, comunicación) y las obligaciones externas. Para proveedores de sistemas de alto riesgo, el artículo 73 de la Ley de IA de la UE establece plazos estrictos una vez aplicables las obligaciones de alto riesgo: notificación a la autoridad de vigilancia en general dentro de 15 días desde el conocimiento del incidente grave, 10 días si hay un fallecimiento y 2 días en caso de infracción generalizada o perturbación grave e irreversible de infraestructuras críticas. Se permite un informe inicial incompleto con ampliación posterior. Si hay datos personales implicados, pueden sumarse los plazos de notificación de las normas de protección de datos aplicables.

Fase 5: recuperación y revisión

Tras restablecer el servicio, realice una revisión posterior sin culpas: causa raíz (datos, modelo, integración, supervisión), corrección y reentrenamiento si procede, actualización de controles y de la matriz de riesgos, y comunicación de lecciones aprendidas. Cada incidente debe dejar el sistema de gobernanza más fuerte.

Por dónde empezar esta semana

Tres pasos de alto impacto: (1) nombre un responsable de incidentes de IA y un suplente; (2) cree una matriz de activación de una página que indique qué eventos disparan el proceso y a quién se avisa; (3) ejecute una simulación de 60 minutos con los equipos técnico, legal y de comunicación. La ejecución básica bajo presión vale más que otro documento de política.

Fuentes

Artículo 73, Ley de IA de la UE — Comisión Europea (AI Act Service Desk) · Reglamento (UE) 2024/1689 (EUR-Lex) · NIST AI Risk Management Framework · ISO/IEC 42001:2023. Información general, no asesoramiento jurídico; verifique siempre con las fuentes oficiales.