Lo esencial
- Un incidente de IA es cualquier suceso en el que el desarrollo, el despliegue o el fallo de un sistema de IA provoca, de forma directa o indirecta, un daño real. La noción va más allá del simple error de software y del accidente laboral.
- El artículo 73 del Reglamento de IA obliga a los proveedores de sistemas de IA de alto riesgo a notificar los incidentes graves a las autoridades de vigilancia del mercado. La obligación se aplica desde el 2 de agosto de 2026.
- Los plazos son breves y escalonados: 2 días en caso de infracción a gran escala o de perturbación grave de una infraestructura crítica, 10 días en caso de fallecimiento, 15 días para los demás incidentes graves.
- El incidente grave se define en el artículo 3, punto 49: fallecimiento o daño grave a la salud, perturbación grave e irreversible de una infraestructura crítica, vulneración de obligaciones de protección de los derechos fundamentales, o daño grave a bienes o al medio ambiente.
- La notificación de incidentes de IA solo se sostiene si descansa sobre un proceso interno repetible: detectar, calificar, decidir la notificabilidad, comunicar en plazo, y luego investigar y subsanar.
Qué es la notificación de incidentes y qué hace distinto a un incidente de IA
La notificación de incidentes consiste en documentar un suceso inesperado para entender qué ocurrió, contener el daño y evitar que se repita. En seguridad laboral, sanidad y gestión de servicios de TI la práctica está asentada: un cuasi accidente, una lesión o una caída de servicio se registran en un formulario normalizado, y el registro alimenta la investigación y la acción correctiva. La IA desplaza el problema, y es justo ahí donde la notificación de incidentes de IA se separa de su versión genérica. El daño de un sistema de IA suele ser indirecto. El modelo no hace tropezar a nadie ni derrama ninguna sustancia; produce una salida sobre la que una persona u otro sistema actúa, y el daño aflora aguas abajo. Una sugerencia de triaje médico equivocada, una denegación de crédito sesgada o un fallo de moderación de contenidos pueden causar un daño serio sin avería visible alguna. La cadena entre causa y consecuencia es larga, estadística y difícil de imputar. Por eso reguladores y organismos de normalización han elaborado definiciones propias de la IA. En su informe de 2024 Defining AI Incidents and Related Terms, la OCDE fija la taxonomía de referencia: un incidente de IA es un suceso en el que el desarrollo, el uso o el fallo de un sistema de IA conduce, de forma directa o indirecta, a un daño (lesiones a personas, perturbación de infraestructuras críticas, vulneración de derechos humanos, daño a bienes o al medio ambiente). La OCDE distingue el peligro de IA, una circunstancia que podría conducir de forma plausible a un incidente, del incidente de IA, en el que el daño se materializa, y añade el desastre de IA como incidente grave que desorganiza a una colectividad. Estas distinciones determinan qué debe vigilar, registrar y, en ocasiones, notificar la organización. También orientan el modo en que AI Sigil aborda la gestión del riesgo de IA.
La obligación del Reglamento de IA: la notificación de incidentes graves del artículo 73
Para quien opera en el mercado de la Unión o vende en él, la buena práctica se convierte en obligación legal. El mecanismo es el artículo 73 del Reglamento de IA, el eje de todo programa de cumplimiento del Reglamento de IA para los sistemas de alto riesgo.
Quién debe notificar, y a quién
El texto es tajante: los proveedores de sistemas de IA de alto riesgo introducidos en el mercado de la Unión notifican cualquier incidente grave a las autoridades de vigilancia del mercado del Estado miembro en el que se haya producido el incidente (Reglamento de IA, artículo 73). El responsable del despliegue no es un mero espectador: cuando tiene conocimiento de un incidente grave, la obligación le lleva a informar al proveedor y, en los casos previstos, a la autoridad. En España, la AESIA, primera agencia de supervisión de la IA de la Unión, junto con la AEPD, vertebra el marco nacional de vigilancia.
Qué constituye un incidente grave
El disparador es la definición del artículo 3, punto 49. Un incidente grave es un incidente o un mal funcionamiento que provoca, de forma directa o indirecta, una de cuatro consecuencias: el fallecimiento de una persona o un daño grave a su salud; una perturbación grave e irreversible de la gestión o el funcionamiento de una infraestructura crítica; una vulneración de obligaciones del Derecho de la Unión destinadas a proteger los derechos fundamentales; o un daño grave a bienes o al medio ambiente. A falta de ello, el suceso puede merecer un registro interno sin ser por ello un incidente grave notificable.
Los plazos de notificación
El artículo 73 fija un reloj de varias velocidades, y corre deprisa.
- 2 días: una infracción a gran escala, o una perturbación grave e irreversible de una infraestructura crítica.
- 10 días: el fallecimiento de una persona.
- 15 días: todos los demás incidentes graves.
La regla de base lo une todo: el proveedor notifica de inmediato tras establecer un nexo causal, o la probabilidad razonable de tal nexo, entre el sistema de IA y el incidente, y en cualquier caso a más tardar 15 días después de tener conocimiento. Como las ventanas son estrechas, el Reglamento admite una notificación inicial incompleta, seguida de un informe completo una vez aclarados los hechos.
Después de la notificación
La notificación no es un punto final. Tras un incidente grave, el proveedor realiza sin demora las investigaciones necesarias, incluida una evaluación del riesgo del incidente, y adopta medidas correctivas. La autoridad de vigilancia del mercado dispone entonces de siete días para adoptar las medidas oportunas.
Cuándo empieza el reloj y las directrices de la Comisión de septiembre de 2025
La cuestión operativa más delicada es saber cuándo empieza el plazo. La obligación se ata al conocimiento y al nexo causal: el plazo corre desde el momento en que el proveedor establece, o podría razonablemente establecer, un vínculo entre el sistema de IA y el daño. En septiembre de 2025 la Comisión Europea publicó un proyecto de directrices y un modelo de notificación para hacer viable el cumplimiento. El proyecto, difundido el 26 de septiembre de 2025 y abierto a consulta hasta el 7 de noviembre de 2025, aclara que basta un nexo causal indirecto, con ejemplos como un análisis médico erróneo que provoca un daño posterior o una evaluación crediticia viciada (Latham & Watkins, 2025). También aborda el solapamiento con las normas sectoriales: para un operador de infraestructuras críticas ya obligado a notificar conforme a NIS2, solo un incidente que afecte a los derechos fundamentales requiere una notificación distinta conforme al artículo 73, mientras que los demás siguen el canal sectorial. La obligación se aplica desde el 2 de agosto de 2026, fecha de efectos de las normas sobre sistemas de alto riesgo. Aplazar el diseño del proceso hasta entonces obliga a construirlo bajo presión, durante un incidente real.
Incidentes de los modelos de propósito general y riesgo sistémico
Los sistemas de alto riesgo no son los únicos afectados. Los proveedores de modelos de IA de propósito general con riesgo sistémico cargan con obligaciones propias conforme al artículo 55: rastrear, documentar y notificar los incidentes graves a la Oficina de IA, junto con las posibles medidas correctivas. El código de buenas prácticas para los modelos de propósito general, cuyo capítulo de seguridad y protección se finalizó en julio de 2025, traduce ese deber en compromisos concretos: mantener un seguimiento de los incidentes graves, trasladar la información pertinente a la Oficina de IA y a las autoridades nacionales en plazos definidos, y conservar la documentación que sustente el análisis posterior. Para los mayores proveedores de modelos, la notificación de incidentes de IA pasa a ser una obligación de vigilancia continua en lugar de una presentación ocasional. AI Sigil lo integra en una única plataforma de gobernanza de la IA, no en un silo aparte.
Dónde encaja la notificación en las normas: NIST e ISO
La regulación fija el suelo. Las normas voluntarias aportan el modelo operativo. El marco de gestión del riesgo de IA del NIST organiza el trabajo en cuatro funciones: Govern, Map, Measure y Manage. La respuesta a incidentes recae sobre todo en Manage, que exige una supervisión posterior al despliegue, mecanismos para recoger y tratar los problemas, y una respuesta a incidentes, una recuperación y una gestión del cambio documentadas. Govern añade las políticas y la rendición de cuentas que impiden que esos mecanismos caigan en desuso. La norma ISO/IEC 42001 sobre el sistema de gestión de la IA sitúa la gestión de incidentes en un ciclo certificable Planificar-Hacer-Verificar-Actuar. La organización que opera un sistema 42001 mantiene un proceso definido para los incidentes de IA, lo vincula al tratamiento del riesgo y demuestra al auditor que el ciclo se cierra. Para un equipo ya certificado en ISO/IEC 27001, el proceso de incidentes de IA puede engranar con el proceso de incidentes de seguridad existente en lugar de duplicarlo.
Cómo construir un proceso interno de notificación de incidentes de IA
Una obligación de notificación vale lo que el proceso que la sostiene. Un proceso operativo de notificación de incidentes de IA tiene cuatro fases, cada una con un responsable designado.
Detectar y recibir
La mayoría de los incidentes de IA los advierte primero un usuario, un agente de soporte o un sistema aguas abajo, no un cuadro de mando. Ofrezca a cada canal un único punto de recepción: un formulario, una cola o una línea dedicada, abierto a todos sin tener que juzgar de antemano la notificabilidad. Recoja lo esencial en la recepción (qué ocurrió, qué sistema, cuándo, qué daño observado) para que los hechos relevantes para el cómputo del plazo existan desde el primer minuto.
Calificar y decidir la notificabilidad
Es la decisión de la que dependen los plazos. Confronte cada recepción con la prueba del artículo 3, punto 49: ¿provocó el suceso, de forma directa o indirecta, fallecimiento o daño grave a la salud, perturbación de una infraestructura crítica, vulneración de derechos fundamentales o daño grave a bienes o al medio ambiente? Un breve árbol de decisión, asignado a un rol designado, mantiene la calificación coherente y trazada. Anote el razonamiento incluso cuando la respuesta sea no, porque ese registro es la defensa de la organización si la decisión se cuestiona después.
Notificar en plazo
Una vez calificado el suceso como incidente grave, se aplica el reloj escalonado. Identifique la autoridad de vigilancia del mercado competente, prepare la notificación con el modelo de la Comisión y presente dentro de 2, 10 o 15 días según la categoría. Prefiera la notificación inicial incompleta antes que incumplir el plazo.
Investigar, subsanar y registrar
Tras la presentación, busque la causa raíz, lleve a cabo la evaluación del riesgo que exige el artículo 73 y adopte medidas correctivas. Registre todo en un registro que enlace el incidente con el sistema, la versión del modelo, los usuarios afectados y la subsanación. Bases de datos externas como la AI Incident Database (AIID), el repertorio AIAAIC y el OECD AI Incidents Monitor sirven de puntos de referencia para aprender de los incidentes del sector, una práctica que el CSET revisó en su nota de enero de 2025.
En qué se diferencia la notificación de incidentes de IA de otros regímenes
Un mismo suceso puede activar varias obligaciones a la vez. Una fuga de datos en un sistema de IA puede ser una violación de datos personales conforme al RGPD, con su notificación en 72 horas a la autoridad de control conforme al artículo 33, un incidente grave conforme al artículo 73 y, para una entidad financiera, una notificación de incidente TIC conforme a DORA. NIS2 añade obligaciones para las entidades esenciales e importantes, y las normas sectoriales para productos sanitarios, aviación o servicios financieros añaden más. La lección práctica: cartografiar las obligaciones de notificación una sola vez, por anticipado, y diseñar un único punto de recepción capaz de ramificarse hacia los regímenes correctos. El equipo que trate la notificación de incidentes de IA como una tarea aislada del Reglamento de IA acabará notificando el mismo suceso tres veces, en tres formatos y bajo tres relojes, o peor, olvidará uno. Centralizar el mapa de obligaciones es precisamente aquello para lo que se construye una plataforma de gobernanza de la IA.
Preguntas frecuentes
¿Qué es la notificación de incidentes de IA? La notificación de incidentes de IA es el proceso estructurado de detectar, documentar y, cuando la ley lo exige, comunicar a las autoridades los sucesos en los que un sistema de IA causa o contribuye a un daño. Conforme al Reglamento de IA es una obligación legal para los proveedores de sistemas de alto riesgo y de ciertos modelos de propósito general, no solo una buena práctica interna. ¿Cuáles son los pasos para notificar un incidente de IA? Detectar y registrar el suceso en un único punto de recepción; calificarlo respecto a la definición de incidente grave del artículo 3, punto 49; si encaja, notificar a la autoridad de vigilancia del mercado competente dentro del plazo aplicable; luego buscar la causa raíz, evaluar el riesgo y adoptar medidas correctivas. Conserve una traza escrita en cada paso, incluido el razonamiento de los sucesos no notificados. ¿Qué contiene un informe de incidente de IA? Como mínimo: una descripción de los hechos, el sistema de IA y la versión del modelo implicados, la fecha en que se tuvo conocimiento, el tipo y la gravedad del daño, las personas o bienes afectados, el nexo causal presunto y las medidas correctivas adoptadas o previstas. El modelo de notificación de la Comisión para el artículo 73 estructura estos campos. ¿Qué es un incidente grave conforme al Reglamento de IA? El artículo 3, punto 49, lo define como un incidente o un mal funcionamiento que provoca, de forma directa o indirecta, el fallecimiento de una persona o un daño grave a la salud, una perturbación grave e irreversible de una infraestructura crítica, una vulneración de obligaciones del Derecho de la Unión de protección de los derechos fundamentales, o un daño grave a bienes o al medio ambiente. ¿Cuándo se aplica el artículo 73 y con qué rapidez hay que notificar? La obligación se aplica desde el 2 de agosto de 2026. Los plazos corren desde el conocimiento y la posibilidad de establecer un nexo causal: 2 días para una infracción a gran escala o una perturbación grave de infraestructuras críticas, 10 días en caso de fallecimiento, 15 días para los demás incidentes graves. ¿En qué se diferencia de una notificación de violación de datos? Una violación conforme al RGPD afecta a datos personales y conlleva una notificación en 72 horas. Un incidente grave conforme al Reglamento de IA afecta al daño causado por el propio sistema de IA, sobre el reloj de 2, 10 o 15 días. El mismo suceso puede activar ambos, además de regímenes sectoriales como NIS2 o DORA: conviene cartografiar los deberes en conjunto.
Conclusión
La notificación de incidentes de IA pasa de ser una virtud de cultura de seguridad a una obligación legal estricta, con plazos breves y responsabilidades nombradas. La afrontará con serenidad quien decida ahora quién custodia la recepción, cómo se califica un incidente grave y a qué autoridad notificar dentro de qué ventana. El trabajo a realizar antes del 2 de agosto de 2026 no es solo interpretación jurídica: es el proceso permanente que convierte el artículo 73 en una rutina gobernable. AI Sigil ayuda a los equipos de los sectores regulados a convertir obligaciones como esta en procesos vivos y auditables dentro de un único sistema de gobernanza.