Análisis jurídico completo para empresas y administraciones públicas. La guía oficial de la AESIA más el criterio de iusia para el asesoramiento práctico.
El artículo 73 del AI Act establece la obligación de los proveedores de sistemas de alto riesgo de notificar los incidentes graves a las autoridades supervisoras. Esta obligación tiene plazos muy cortos — 15 días como regla general, 10 días si el incidente ha causado la muerte de una persona y 2 días en caso de infracción generalizada o de alteración grave de infraestructuras críticas —. El artículo 73 no figura entre las obligaciones enumeradas en el artículo 99.4, por lo que la cuantía de la sanción dependerá del régimen que fije cada Estado miembro conforme al artículo 99.1 (en España, todavía pendiente); si además se facilita a la autoridad información incorrecta, incompleta o engañosa sobre el incidente, se aplica el artículo 99.5, con multas de hasta 7,5 millones de euros o el 1% del volumen de negocio global.
La Guía 14 de la AESIA analiza en sus 37 páginas todos los elementos de la obligación de notificación: qué es un incidente grave, cuándo y cómo debe notificarse, qué información debe incluir la notificación, quién notifica (proveedor o desplegador, o ambos), y cómo se coordina la notificación del AI Act con la obligación paralela de notificación de brechas de datos personales del artículo 33 del RGPD.
La guía destaca que la obligación de notificación debe activarse incluso cuando el incidente no ha producido daños reales pero existe un riesgo serio de que los produzca. El concepto de incidente "que podría haber provocado" daños es deliberadamente amplio para garantizar que las autoridades supervisan no solo los incidentes que ya han causado consecuencias sino también los que revelan vulnerabilidades del sistema que podrían causar consecuencias en el futuro.
El artículo 3.49 del AI Act define el incidente grave como "cualquier incidente o mal funcionamiento de un sistema de IA de alto riesgo que dé lugar directa o indirectamente a cualquiera de los siguientes: la muerte de una persona o daños graves para la salud de una persona, una perturbación grave e irreversible de la gestión y explotación de infraestructuras críticas, infracción de obligaciones establecidas en el Derecho de la Unión destinadas a proteger los derechos fundamentales, o daños graves a los bienes o el medio ambiente."
La guía analiza cada elemento de esta definición con ejemplos prácticos que ayudan a determinar en casos concretos si un incidente es o no un incidente grave. La muerte o los daños graves a la salud incluyen tanto los casos directos — un sistema de diagnóstico médico que produce un error que lleva a un tratamiento incorrecto con consecuencias graves para el paciente — como los casos indirectos — un sistema de gestión de infraestructuras críticas cuyo mal funcionamiento causa una avería con consecuencias para la salud de personas.
La perturbación grave e irreversible de infraestructuras críticas incluye interrupciones del suministro eléctrico, del agua, del transporte o de otros servicios esenciales causadas o amplificadas por el mal funcionamiento de un sistema de IA. El carácter "irreversible" no significa que la perturbación sea permanente — significa que los efectos no pueden corregirse inmediatamente sin consecuencias duraderas.
La infracción de obligaciones destinadas a proteger los derechos fundamentales es la categoría más amplia y potencialmente la más relevante para la práctica diaria. La guía aclara que esta categoría incluye, entre otras: decisiones discriminatorias que afecten de forma sistemática a grupos protegidos, decisiones que violen el derecho a la protección de datos personales (lo que puede activar simultáneamente la obligación de notificación del art. 33 RGPD), y decisiones que comprometan el derecho a la tutela judicial efectiva o el derecho a un proceso equitativo.
El artículo 73.2 establece que los proveedores deben notificar los incidentes graves a la autoridad de vigilancia del Estado miembro donde haya tenido lugar el incidente. El plazo máximo es de 15 días naturales desde que el proveedor tuvo conocimiento del incidente. Sin embargo, la guía aclara que este plazo máximo no significa que el proveedor deba esperar 15 días para notificar — el plazo es un máximo, y la notificación debe realizarse "de manera inmediata" y "sin demora injustificada" conforme al texto del artículo.
El artículo 73 fija además dos plazos más cortos. Si el incidente constituye una infracción generalizada o una alteración grave e irreversible de la gestión o el funcionamiento de infraestructuras críticas, la notificación debe hacerse de inmediato y, a más tardar, en 2 días desde que se tiene conocimiento (art. 73.3). Si ha causado la muerte de una persona, el plazo máximo es de 10 días (art. 73.4). En ambos casos cabe presentar primero un informe inicial incompleto y completarlo después (art. 73.5).
La guía advierte sobre un error frecuente: retrasar la notificación mientras se investiga la causa del incidente, esperando tener una imagen completa antes de informar a las autoridades. Este enfoque viola el espíritu de la norma. La notificación debe hacerse tan pronto como el proveedor tiene conocimiento del incidente, aunque la investigación no esté completada, y puede complementarse con información adicional a medida que la investigación avanza.
El artículo 73 establece un sistema de notificación en dos escalones que requiere coordinación entre proveedor y desplegador. El desplegador que identifica un incidente grave o sospecha de su existencia debe notificarlo inmediatamente al proveedor (art. 26.5). El proveedor es entonces responsable de notificar el incidente a la autoridad supervisora.
En algunos casos, el desplegador puede también tener la obligación de notificar directamente a la autoridad supervisora, especialmente cuando el proveedor no reacciona con suficiente rapidez o cuando el incidente afecta directamente a la actividad del desplegador de una forma que hace necesaria la intervención inmediata de la autoridad supervisora.
La guía recomienda que los contratos entre proveedores y desplegadores establezcan con precisión el protocolo de comunicación de incidentes: el desplegador se compromete a notificar al proveedor en un plazo determinado (por ejemplo, 24 horas) desde que tenga conocimiento de un posible incidente grave; el proveedor se compromete a acusar recibo en un plazo determinado y a iniciar la investigación; y ambas partes coordinan la notificación a las autoridades supervisoras.
La notificación a la AESIA debe incluir la información mínima que permita a la autoridad comprender la naturaleza del incidente y evaluar si es necesaria una intervención inmediata. La guía establece el contenido mínimo de la notificación inicial: identificación del proveedor y del sistema de IA afectado, descripción del incidente incluyendo cuándo ocurrió y cuándo se detectó, descripción de las personas o sistemas afectados, descripción del daño o del riesgo de daño identificado, las medidas adoptadas inmediatamente para limitar el daño o el riesgo, y el estado de la investigación en el momento de la notificación.
La notificación inicial puede ser incompleta si la investigación está en curso — lo que es habitual en las primeras 15 horas tras la detección del incidente. El proveedor debe comprometerse a proporcionar actualizaciones a medida que la investigación avanza, incluyendo una notificación final que describa las causas raíz del incidente y las medidas adoptadas para prevenir su recurrencia.
Cuando el incidente grave del AI Act implica también una brecha de seguridad de datos personales en el sentido del artículo 4.12 del RGPD — una brecha de confidencialidad, integridad o disponibilidad de datos personales — se activa simultáneamente la obligación de notificación a la AEPD del artículo 33 RGPD. La diferencia fundamental es el plazo: el RGPD exige la notificación en 72 horas desde que el responsable del tratamiento tenga conocimiento de la brecha, que es significativamente más corto que el plazo máximo de 15 días del AI Act.
En la práctica, cuando un incidente de un sistema de IA de alto riesgo implica datos personales, la organización debe gestionar simultáneamente dos procesos de notificación con plazos distintos y destinatarios distintos. La guía recomienda establecer un protocolo interno que identifique desde el primer momento si el incidente puede constituir una brecha de datos personales, y si es así, activar el protocolo de notificación a la AEPD en 72 horas con independencia de que la investigación del incidente bajo el AI Act continúe en paralelo.
La guía insiste en la necesidad de establecer un protocolo interno de gestión de incidentes de IA antes de que ocurra el primero. El error más común es intentar diseñar la respuesta cuando el incidente ya ha ocurrido, con la presión del plazo de notificación y la urgencia de gestionar el impacto. En ese momento, la organización no está en condiciones de tomar decisiones bien fundamentadas sobre si el incidente es grave en el sentido del Reglamento, quién debe notificarlo y qué información debe incluir la notificación.
El protocolo interno debe designar a un responsable de la gestión de incidentes de IA — que puede ser el DPO, el responsable de ciberseguridad, o un rol específico creado para este fin — con la autoridad para decidir si un incidente es grave y para ejecutar la notificación. Debe establecer los criterios de clasificación de incidentes — qué situaciones activan automáticamente el protocolo de incidente grave — y los pasos del proceso de notificación, incluyendo las validaciones internas que deben completarse antes de enviar la notificación a la AESIA.
Antes de notificar un incidente grave a la AESIA, el proveedor debe documentar internamente el incidente con suficiente detalle para que la notificación sea completa y precisa. La guía recomienda implementar un registro de incidentes de IA — un sistema de documentación estructurada de todos los incidentes, tanto los que eventualmente se clasifican como graves como los que no alcanzan ese umbral — que sirva como fuente de información para las notificaciones y como herramienta de aprendizaje organizacional.
El registro de incidentes debe incluir para cada incidente: la fecha y hora de ocurrencia y de detección, la descripción del incidente, los sistemas y datos afectados, las personas afectadas (con los datos mínimos necesarios para el análisis y respetando la protección de datos), las acciones inmediatas tomadas para limitar el impacto, la decisión sobre si el incidente es un incidente grave que requiere notificación, y, si la notificación no se considera necesaria, la justificación de esa decisión. Este último elemento es especialmente importante porque, si las autoridades supervisoras cuestionan posteriormente esa decisión, la organización debe poder demostrar que la evaluación fue razonada y documentada.
La notificación de un incidente grave a la AESIA puede tener implicaciones en los procedimientos de responsabilidad civil que los afectados puedan iniciar. La notificación es un reconocimiento formal de que ha ocurrido un incidente con consecuencias potencialmente graves, lo que puede ser usado como prueba en procedimientos judiciales. Sin embargo, la alternativa — no notificar un incidente que debería haberse notificado — implica una infracción autónoma del art. 73 que expone a la organización a una sanción adicional.
La guía recomienda que los departamentos jurídicos de las organizaciones estén involucrados desde el primer momento en la gestión de incidentes graves, coordinando la obligación de notificación regulatoria con la gestión del riesgo de responsabilidad civil. Esta coordinación es especialmente relevante cuando el incidente puede haber causado daños a terceros, donde la notificación regulatoria y la gestión de las reclamaciones de daños deben gestionarse de forma coherente.
Los seguros de responsabilidad civil por daños de IA están emergiendo como un producto de mercado relevante en el contexto del AI Act. Algunas aseguradoras están empezando a ofrecer coberturas específicas para los riesgos derivados del uso de sistemas de IA de alto riesgo, incluyendo la cobertura de las sanciones regulatorias (en la medida en que las sanciones sean asegurables bajo el derecho español) y la cobertura de las reclamaciones de responsabilidad civil. La guía recomienda que los responsables de gestión de riesgos de las organizaciones evalúen la contratación de este tipo de cobertura como complemento a las medidas de cumplimiento del AI Act.
De la misma forma que las organizaciones realizan simulacros de incidentes de ciberseguridad para preparar a sus equipos antes de que ocurra un incidente real, la guía recomienda realizar ejercicios de simulación de incidentes graves de IA. Estos ejercicios permiten verificar que el protocolo de gestión de incidentes funciona en la práctica, identificar los cuellos de botella en el proceso de decisión y notificación, y garantizar que todas las personas con roles en la respuesta al incidente conocen sus responsabilidades.
Un simulacro típico de incidente grave de IA puede construirse a partir de un escenario realista para el tipo de sistema que opera la organización: un sistema de scoring que produce outputs discriminatorios detectados por un grupo de usuarios, un sistema de diagnóstico médico que falla en una cadena de casos similares, o un sistema de selección de personal que es víctima de un ataque adversarial. El simulacro debe ejecutarse con el protocolo real de gestión de incidentes, incluyendo la comunicación al proveedor (si la organización es desplegadora), la evaluación de si el incidente es grave, y la preparación de la notificación a la AESIA.
Antes de notificar un incidente grave a la AESIA, el proveedor debe documentar internamente el incidente con suficiente detalle para que la notificación sea completa y precisa. La guía recomienda implementar un registro de incidentes de IA — un sistema de documentación estructurada de todos los incidentes, tanto los que eventualmente se clasifican como graves como los que no alcanzan ese umbral — que sirva como fuente de información para las notificaciones y como herramienta de aprendizaje organizacional.
El registro de incidentes debe incluir para cada incidente: la fecha y hora de ocurrencia y de detección, la descripción del incidente, los sistemas y datos afectados, las personas afectadas (con los datos mínimos necesarios para el análisis y respetando la protección de datos), las acciones inmediatas tomadas para limitar el impacto, la decisión sobre si el incidente es un incidente grave que requiere notificación, y, si la notificación no se considera necesaria, la justificación de esa decisión. Este último elemento es especialmente importante porque, si las autoridades supervisoras cuestionan posteriormente esa decisión, la organización debe poder demostrar que la evaluación fue razonada y documentada.
La notificación de un incidente grave a la AESIA puede tener implicaciones en los procedimientos de responsabilidad civil que los afectados puedan iniciar. La notificación es un reconocimiento formal de que ha ocurrido un incidente con consecuencias potencialmente graves, lo que puede ser usado como prueba en procedimientos judiciales. Sin embargo, la alternativa — no notificar un incidente que debería haberse notificado — implica una infracción autónoma del art. 73 que expone a la organización a una sanción adicional.
La guía recomienda que los departamentos jurídicos de las organizaciones estén involucrados desde el primer momento en la gestión de incidentes graves, coordinando la obligación de notificación regulatoria con la gestión del riesgo de responsabilidad civil. Esta coordinación es especialmente relevante cuando el incidente puede haber causado daños a terceros, donde la notificación regulatoria y la gestión de las reclamaciones de daños deben gestionarse de forma coherente.
Los seguros de responsabilidad civil por daños de IA están emergiendo como un producto de mercado relevante en el contexto del AI Act. Algunas aseguradoras están empezando a ofrecer coberturas específicas para los riesgos derivados del uso de sistemas de IA de alto riesgo, incluyendo la cobertura de las sanciones regulatorias (en la medida en que las sanciones sean asegurables bajo el derecho español) y la cobertura de las reclamaciones de responsabilidad civil. La guía recomienda que los responsables de gestión de riesgos de las organizaciones evalúen la contratación de este tipo de cobertura como complemento a las medidas de cumplimiento del AI Act.
De la misma forma que las organizaciones realizan simulacros de incidentes de ciberseguridad para preparar a sus equipos antes de que ocurra un incidente real, la guía recomienda realizar ejercicios de simulación de incidentes graves de IA. Estos ejercicios permiten verificar que el protocolo de gestión de incidentes funciona en la práctica, identificar los cuellos de botella en el proceso de decisión y notificación, y garantizar que todas las personas con roles en la respuesta al incidente conocen sus responsabilidades.
Un simulacro típico de incidente grave de IA puede construirse a partir de un escenario realista para el tipo de sistema que opera la organización: un sistema de scoring que produce outputs discriminatorios detectados por un grupo de usuarios, un sistema de diagnóstico médico que falla en una cadena de casos similares, o un sistema de selección de personal que es víctima de un ataque adversarial. El simulacro debe ejecutarse con el protocolo real de gestión de incidentes, incluyendo la comunicación al proveedor (si la organización es desplegadora), la evaluación de si el incidente es grave, y la preparación de la notificación a la AESIA.
Más recursos: calendario del AI Act tras el Ómnibus Digital · análisis del AI Act en 2026 · servicios para administraciones públicas (LexQuark).
Newsletter gratuita · Empresas y administraciones públicas · En español