Gestión de incidentes de IA: cómo responder cuando la IA falla
Qué es un incidente de IA, cómo gestionarlo, cómo integrar el reporte con el canal de denuncias del MPD y el mapa de las notificaciones obligatorias en Chile (ANCI, APDP y futura ley de IA).
Tarde o temprano, un sistema de IA falla: una decisión sesgada, una alucinación usada como verdad, una fuga de datos. La pregunta no es si ocurrirá, sino si tu empresa sabrá detectarlo, contenerlo y a quién avisar. En Cognitiva, agencia chilena de IA, vemos que la mayoría no tiene un plan de respuesta a incidentes de IA, y en Chile eso es riesgoso porque un solo incidente puede activar varios deberes legales en paralelo: la alerta temprana de 3 horas a la ANCI bajo la Ley 21.663 (ya vigente), la notificación de brechas a la Agencia de Protección de Datos bajo la Ley 21.719 (desde diciembre de 2026) y, cuando sea ley, el reporte de incidentes de IA de alto riesgo del proyecto en trámite. Este artículo explica qué es un incidente de IA, cómo gestionarlo con marcos reconocidos, cómo montar el canal de reporte sobre el que tu empresa ya tiene, y el mapa de notificaciones chileno. No es asesoría legal: es la guía para no improvisar el día que ocurra.
Qué es un incidente de IA (y qué es un cuasi-incidente)
La OECD define un incidente de IA como un evento donde el desarrollo, uso o mal funcionamiento de un sistema de IA causa un daño: a personas, a infraestructura crítica, a derechos fundamentales o a la propiedad y el medioambiente. La distinción clave es con el "cuasi-incidente" (hazard o near miss): el mismo evento, pero donde el daño pudo ocurrir y aún no se materializó.
Esa diferencia importa para la gestión: un buen programa registra ambos, no solo los incidentes consumados. Los tipos más frecuentes: sesgo o discriminación, alucinación dañina usada sin verificar, fuga de datos vía IA, fallo de seguridad (prompt injection, jailbreak), uso indebido (deepfakes, fraude) y daño directo a personas. Como referencia de magnitud, el AI Index de Stanford (2025) registró 233 incidentes de IA en 2024, un récord histórico.
Cómo gestionarlos: marcos y ciclo de respuesta
Dos marcos estructuran la respuesta. El NIST AI RMF, en su función Manage, pide planes de monitoreo post-despliegue con respuesta a incidentes y una base de datos de errores, cuasi-incidentes e incidentes con fecha, severidad y respuesta. ISO/IEC 42001 incluye controles de comunicación de incidentes (A.8.4) y de reporte de preocupaciones (A.3.3).
El ciclo de respuesta adapta el estándar de ciberseguridad (detección y análisis, contención, erradicación y recuperación, lecciones aprendidas) a las particularidades de la IA:
- **La causa raíz es difusa.** Un fallo no mapea a una línea de código: puede estar en los datos de entrenamiento, el fine-tuning, el contexto o el prompt.
- **La severidad depende del contexto.** Una recomendación médica errada no es lo mismo que un dato trivial equivocado.
- **Hay brechas de telemetría.** El monitoreo de seguridad estándar no detecta alucinaciones ni deriva del modelo; hay que instrumentar la salida.
- **Requiere observación post-remediación.** Como el comportamiento es probabilístico, un solo test no valida el arreglo.
- **Es cross-funcional.** Define antes del incidente los roles de seguridad, ingeniería/ML, legal, comunicaciones y soporte.
El canal de reporte: reutiliza el que ya tienes
Quien primero detecta que una IA falla suele ser el empleado que la usa a diario. Sin un canal y sin protección contra represalias, ese empleado calla y el riesgo se acumula. NIST (Govern) recomienda explícitamente protecciones para quienes reportan problemas serios de sistemas de IA, e ISO 42001 exige un proceso para reportar preocupaciones.
En Chile no hace falta crear un canal nuevo: conviene integrar el reporte de incidentes de IA como una categoría del canal de denuncias del Modelo de Prevención de Delitos que la Ley 20.393, reforzada por la Ley de Delitos Económicos (21.595), ya exige —confidencial, con opción de anonimato y protección contra represalias—. Una advertencia honesta: Chile aún no tiene un estatuto de protección al denunciante del sector privado puro (la Ley 21.592 cubre principalmente el ámbito público y empresas con vínculo estatal), por lo que esa protección debe anclarse contractualmente en la política interna.
El mapa de las tres notificaciones chilenas
Esto es lo que vuelve el tema urgente y propio de Chile: un mismo incidente de IA puede gatillar deberes de notificación ante autoridades distintas, con plazos distintos, que corren desde que se conoce el incidente —es decir, en paralelo, no en secuencia—.
| Marco | A quién | Plazo / estado |
|---|---|---|
| Ley 21.663 (Ciberseguridad) | ANCI / CSIRT Nacional | Alerta temprana 3 h; vigente |
| Ley 21.719 (Datos) | Agencia de Protección de Datos y titulares | Sin dilaciones indebidas; desde dic-2026 |
| Proyecto Ley de IA | Autoridad de IA (futura) | 72 h alto riesgo; aún proyecto |
| Ley 20.393 (MPD) | Canal interno de denuncias | Permanente (si hay delito) |
El caso límite: una empresa de un sector esencial (banca, salud, energía) que opera IA sobre datos personales puede deber, por un mismo evento, alerta a la ANCI en 3 horas hoy, notificación a la Agencia de Datos y a los titulares desde diciembre de 2026, y —cuando el proyecto sea ley— reporte del incidente de IA. El plazo de la Ley 21.719 se establece como "sin dilaciones indebidas"; varias fuentes lo interpretan en torno a 72 horas por analogía con el estándar europeo, pero conviene verificar el reglamento. El proyecto de ley de IA sigue en trámite: aún no obliga.
El registro que casi nadie lleva
NIST no pide solo responder al incidente: pide mantener una base de datos de incidentes y cuasi-incidentes. Ese registro es lo que convierte cada fallo en aprendizaje y, ante una fiscalización, en evidencia de diligencia. Un registro mínimo de incidentes de IA debería capturar:
- Fecha y descripción del evento.
- Tipo de daño (según la taxonomía de la OECD) y severidad.
- Sistema de IA involucrado y causa raíz probable.
- Acciones de contención y remediación.
- Notificaciones realizadas (a quién y cuándo).
- Lecciones aprendidas y cambios al sistema.
Llevar este registro desde el primer día —incluso de los cuasi-incidentes— es barato y es exactamente lo que un auditor o la autoridad esperan ver. No tenerlo es la diferencia entre "tuvimos un incidente y lo gestionamos" y "no sabíamos que estaba pasando".
Cómo prepararse antes de que ocurra
La respuesta a incidentes no se improvisa el día del incidente. Lo que conviene tener listo: un inventario de los sistemas de IA y los datos que tratan, roles asignados antes de la crisis, el canal de reporte integrado al del MPD, el registro de incidentes operativo y el mapa de notificaciones claro para saber a quién avisar y en qué plazo.
Este artículo no constituye asesoría legal. Los plazos y deberes específicos dependen del sector, del tipo de dato y del estado de la tramitación legislativa; conviene validarlos con un especialista. Cognitiva acompaña el diseño del programa de gestión de incidentes y su integración con la gobernanza de datos y el cumplimiento.
Montar un plan de respuesta a incidentes de IA
De cero a un programa que la autoridad espera ver.
- Semanas 1-2
Preparación
Antes del incidente.
- Inventariar sistemas de IA y datos que tratan
- Asignar roles cross-funcionales
- Definir niveles de severidad
- Semanas 3-4
Canal y registro
Detectar y documentar.
- Integrar el reporte al canal de denuncias del MPD
- Crear el registro de incidentes y cuasi-incidentes
- Instrumentar el monitoreo de la salida de la IA
- Semana 5
Mapa de notificación
A quién avisar y cuándo.
- Mapear deberes (ANCI, Agencia de Datos, MPD)
- Definir el árbol de decisión de notificación
- Preparar plantillas de reporte
- Semana 6+
Ensayo
Probar antes de la crisis.
- Simulacro de incidente (tabletop)
- Ajustar plazos y roles
- Revisión periódica del plan
Preguntas frecuentes
Da el siguiente paso
Hablemos
Cuéntanos sobre tu negocio. Respondemos en 24 horas.
Otros canales
Escríbenos por WhatsApp o agenda una llamada de 30 minutos.