La notificación obligatoria de incidentes de IA se está convirtiendo en un requisito operativo, no solo en una propuesta normativa. En virtud del Reglamento de IA de la UE, las normas sobre la notificación de incidentes graves relacionados con sistemas de IA de alto riesgo comenzaron a aplicarse el 2 de agosto de 2026, por lo que es importante que proveedores y responsables del despliegue sepan quién debe actuar, qué puede considerarse un incidente y con qué rapidez debe transmitirse la información.
La notificación sigue más de una vía. Los proveedores de sistemas de IA de alto riesgo tienen obligaciones en virtud del artículo 73, mientras que los proveedores de modelos de IA de uso general con riesgo sistémico tienen obligaciones distintas de seguimiento, documentación y notificación de incidentes graves. El reto práctico consiste en vincular esas obligaciones legales con la detección, la investigación, la escalada y las medidas correctivas, sin dar por sentado que todos los fallos de la IA siguen la misma vía de notificación.
Qué exige ahora la notificación obligatoria de incidentes de IA
Respuesta directa: En virtud del Reglamento de IA de la UE, los proveedores de sistemas de IA de alto riesgo deben notificar los incidentes graves a las autoridades pertinentes. Los responsables del despliegue que identifiquen un incidente grave deben informar inmediatamente al proveedor y, a continuación, al importador o distribuidor y a las autoridades de vigilancia del mercado pertinentes. Los proveedores de modelos de IA de uso general con riesgo sistémico tienen la obligación específica de hacer un seguimiento de los incidentes graves y las posibles medidas correctivas, documentarlos y notificarlos a la Oficina de IA y, según proceda, a las autoridades nacionales, sin demora indebida.
Es importante distinguir entre estas obligaciones. Una norma aplicable a un sistema de IA de alto riesgo no debe tratarse como intercambiable con una norma aplicable a un modelo de uso general con riesgo sistémico, aunque el modelo se utilice dentro de un sistema. La Comisión aborda ambas vías de notificación en orientaciones distintas, y el texto del Reglamento de IA sigue siendo la base jurídica para determinar qué obligación resulta aplicable.
En el caso de los sistemas de IA de alto riesgo, la Comisión indica que las normas que incluyen la notificación de incidentes graves comenzaron a aplicarse el 2 de agosto de 2026. El objetivo declarado de la notificación es detectar los riesgos de forma temprana, garantizar la rendición de cuentas y permitir una actuación rápida. Estos objetivos explican por qué un informe no es simplemente un registro administrativo que se elabora una vez terminada la investigación: forma parte del modo en que las autoridades conocen fallos potencialmente importantes cuando todavía puede ser necesario intervenir.
Antes de que las normas fueran aplicables, la Comisión publicó para recibir comentarios de las partes interesadas un proyecto de orientaciones y una plantilla para notificar incidentes graves. Este trabajo preparatorio ofrece una forma de organizar la notificación, pero las orientaciones y las plantillas deben consultarse junto con el Reglamento, no en sustitución de este. El texto consolidado del Reglamento de IA en EUR-Lex, incluido el artículo 73, es la referencia esencial para el procedimiento de notificación y las responsabilidades correspondientes de proveedores y responsables del despliegue.
La notificación también forma parte de un marco de cumplimiento más amplio. La descripción general del Reglamento de IA de la Comisión la vincula con el registro, la transparencia, las medidas correctivas y la cooperación con las autoridades de vigilancia del mercado. Una organización que pueda presentar un informe, pero no identificar el sistema afectado, explicar lo sucedido ni coordinar el seguimiento, solo habrá resuelto una parte del problema.
Quién notifica un incidente de IA: proveedores, responsables del despliegue y desarrolladores de modelos
La primera pregunta operativa no es qué formulario hay que rellenar. Es qué función desempeña la organización en relación con el sistema de IA o el modelo afectados. Distintos equipos pueden encontrarse con el mismo suceso en diferentes momentos: el responsable del despliegue puede observar las consecuencias en el mundo real, mientras que el proveedor puede disponer de los registros técnicos necesarios para examinar el comportamiento del sistema.
Los proveedores de sistemas de IA de alto riesgo tienen la obligación de notificar a las autoridades
El servicio de asistencia del Reglamento de IA indica que los proveedores de sistemas de IA de alto riesgo deben notificar los incidentes graves. Por eso, la escalada al proveedor es una vía fundamental cuando un incidente aparece primero fuera de sus propias operaciones. Los proveedores necesitan disponer de medios para recibir señales fiables, conservar la información pertinente, evaluar el suceso y determinar cómo cumplir el procedimiento de notificación aplicable.
Esto no significa que el proveedor deba esperar a disponer de una explicación técnica completa para tomarse en serio un posible incidente. La norma relativa a los fallecimientos se refiere expresamente a un vínculo causal presunto, no solo a uno demostrado de manera concluyente. Esta distinción es importante cuando las pruebas aún están incompletas y las personas que investigan el suceso deben cumplir un plazo legal.
Los responsables del despliegue deben comunicar los incidentes graves a las partes correspondientes
Los responsables del despliegue tienen su propia obligación cuando identifican un incidente grave. Deben informar inmediatamente primero al proveedor y, a continuación, al importador o distribuidor y a las autoridades de vigilancia del mercado pertinentes. Por tanto, no pueden dar por sentado que avisar a su proveedor constituye toda la respuesta prevista en las normas.
Esta secuencia exige un mapa práctico de contactos. El responsable del despliegue debe saber qué proveedor corresponde al sistema desplegado, qué importador o distribuidor es pertinente y cómo ponerse en contacto con la autoridad de vigilancia del mercado adecuada. La organización también debe poder comunicar lo que realmente sabe sin presentar observaciones inciertas como conclusiones técnicas definitivas.
Los proveedores de modelos de IA de uso general con riesgo sistémico siguen una vía distinta
En el caso de los proveedores de modelos de IA de uso general con riesgo sistémico, las orientaciones de la Comisión sobre IA de uso general exigen hacer un seguimiento de los incidentes graves y las posibles medidas correctivas, documentarlos y notificarlos a la Oficina de IA y, según proceda, a las autoridades nacionales, sin demora indebida. La Comisión también ha publicado una plantilla de notificación destinada a facilitar la aplicación práctica de las obligaciones de notificación del artículo 55 y ayudar a estos proveedores a demostrar que cumplen la normativa.
Esto no significa que todos los desarrolladores de todos los modelos de IA tengan las mismas obligaciones de notificación. Primero deben determinarse la clasificación pertinente del modelo y la función que desempeña la organización. Si un modelo con riesgo sistémico forma parte de un producto posterior, una comunicación clara entre el proveedor del modelo y el operador del sistema puede ayudar a cada parte a entender qué pruebas posee y qué vía de notificación debe seguir.
- Proveedor de un sistema de IA de alto riesgo: Establecer cómo llegan los incidentes graves al equipo responsable de la notificación y el seguimiento en virtud del artículo 73.
- Responsable del despliegue de un sistema de IA de alto riesgo: Establecer cómo reconoce el personal un posible incidente grave y cómo lo comunica inmediatamente a las partes indicadas en las normas.
- Proveedor de un modelo de IA de uso general con riesgo sistémico: Establecer cómo se hace el seguimiento de los incidentes graves relacionados con el modelo y las posibles medidas correctivas, cómo se documentan y cómo se comunican en virtud del marco específico para la IA de uso general.
Estas funciones pueden exigir coordinación, pero coordinarse no equivale a eludir responsabilidades. Un contrato puede especificar contactos y procedimientos para compartir información; no debe considerarse un sustituto de las obligaciones que el Reglamento de IA atribuye a cada parte según la función que desempeña.
¿Qué se considera un incidente grave de IA?
«Incidente» puede describir desde una interrupción menor del servicio hasta un suceso con consecuencias duraderas. La cuestión a efectos de notificación en la UE es más concreta y tiene mayor trascendencia: ¿cumple el suceso los criterios aplicables a los incidentes graves? Las orientaciones de la Comisión sobre los considerandos describen los incidentes graves de forma suficientemente amplia como para que los equipos no limiten la evaluación a las lesiones físicas.
- Fallecimiento: Un suceso que provoque la muerte de una persona requiere especial atención, porque el artículo 73 establece una norma específica de notificación cuando se establece o se sospecha un vínculo causal con el sistema de IA.
- Interrupción de infraestructuras críticas: La interrupción grave e irreversible de infraestructuras críticas figura entre las consecuencias identificadas en las orientaciones de la Comisión.
- Derechos fundamentales: Las vulneraciones de las protecciones de los derechos fundamentales establecidas en el Derecho de la Unión pueden formar parte de lo que se considera un incidente grave; la cuestión no se limita a los daños materiales.
- Daños materiales o medioambientales: La descripción de la Comisión también incluye los daños graves a la propiedad o al medio ambiente.
Estas categorías hacen que la evaluación inicial sea más compleja que la búsqueda de un único tipo de fallo del sistema. Un resultado preocupante puede detectarse mediante el seguimiento operativo, las reclamaciones, una investigación de seguridad o la información de una organización que utilice el sistema. Un proceso de recepción útil registra tanto la consecuencia comunicada como los motivos por los que el sistema de IA podría estar relacionado con ella, y permite revisar esa evaluación a medida que se obtienen nuevas pruebas.
La existencia de un daño no justifica, por sí sola, afirmar sin fundamento que el sistema de IA lo causó. Del mismo modo, la incertidumbre sobre la causalidad no debe utilizarse como excusa para ignorar una señal creíble. En cuanto al plazo relativo a los fallecimientos, la formulación jurídica incluye expresamente el vínculo causal presunto, por lo que la organización necesita poder distinguir entre una sospecha razonable que exige una escalada y una conclusión que aún debe investigarse.
Clasifique las consecuencias antes de debatir el formulario
Un registro práctico de evaluación inicial puede empezar por el resultado observado: quién o qué se vio afectado, si las consecuencias persisten y qué categoría de incidente grave podría estar implicada. Después puede identificar el sistema o modelo de IA involucrado, el contexto en el que se utilizó y la información que respalda o debilita una posible relación. Así, la evaluación inicial se centra en la cuestión de la notificación, en lugar de intentar completar todos los campos de un informe técnico definitivo.
Algunos sucesos serán difíciles de clasificar. Por ejemplo, un fallo técnico puede ser evidente, aunque todavía se desconozca su impacto en el mundo real; o las consecuencias graves pueden estar claras, mientras que se discute el papel del sistema de IA. Estos son motivos para conservar las pruebas y comunicar la incertidumbre, no para forzar una conclusión prematura de sí o no a partir de información incompleta.
El informe de la Comisión de 2026 sobre incidentes de IA indica que solo se analizaron con más detalle determinadas categorías de incidentes. Esto es una señal útil de la tendencia general hacia una clasificación estructurada, pero no permite decidir por sí solo si un suceso concreto debe notificarse. El punto de partida siguen siendo las disposiciones aplicables del Reglamento de IA y los hechos del suceso.
Cómo cambia la respuesta ante incidentes el plazo de notificación del Reglamento de IA relativo a los fallecimientos
La norma facilitada establece el plazo más claro para los incidentes en los que fallece una persona. El artículo 73 dispone que el informe debe presentarse inmediatamente después de que el proveedor o el responsable del despliegue establezca o sospeche un vínculo causal con el sistema de IA, y a más tardar en los 10 días siguientes a la toma de conocimiento del incidente. Ambos aspectos de la norma deben leerse conjuntamente: el plazo máximo no convierte la obligación de notificar inmediatamente en una autorización para esperar.
Esta formulación exige que el equipo encargado del incidente pueda reconstruir dos datos: cuándo tuvo conocimiento del incidente y cuándo el proveedor o el responsable del despliegue estableció o sospechó el vínculo causal. Si esos momentos no coinciden, ambos son importantes. Un proceso que solo registre la fecha en que se concluyó una investigación interna puede pasar por alto el momento en que ya había surgido la obligación de actuar.
- Registre la primera alerta fiable. Anote cuándo tuvo conocimiento la organización del suceso, la fuente de la alerta y qué se sabía en ese momento. Conserve el relato original en lugar de sustituirlo por un resumen posterior.
- Escalice cuanto antes las posibles causas. Remita las pruebas de una posible relación con el sistema de IA a las personas responsables de la evaluación jurídica y técnica. Distinga entre lo observado, lo que se deduce y lo que sigue sin resolverse.
- Avise a las partes obligadas. Si el responsable del despliegue identifica un incidente grave, debe respetar la secuencia de notificación inmediata. La tarea de notificación del proveedor debe tener un responsable designado y una vía para ponerse en contacto con la autoridad pertinente.
- Conserve un registro de las decisiones. Anote cuándo surgió la sospecha, quién realizó la evaluación, qué información la respaldaba y qué medidas se adoptaron. Una revisión posterior de los hechos no debe borrar la cronología anterior.
Este flujo de trabajo no pretende sustituir el artículo 73 por una lista de comprobación interna. Su objetivo es facilitar el cumplimiento cuando las pruebas están repartidas entre los equipos de operaciones, seguridad, protección y gestión de proveedores. La organización puede adaptar los pasos a su estructura, pero no puede dar por sentado que el ciclo habitual, más lento, de investigación se ajustará a una norma que exige actuar inmediatamente una vez sospechada la causalidad.
El plazo máximo de 10 días relativo a los fallecimientos no debe aplicarse sin más a todos los incidentes graves de IA. La información facilitada identifica ese plazo específico y la expresión distinta «sin demora indebida» para la notificación por parte de proveedores de modelos de IA de uso general con riesgo sistémico; no establece un plazo único para todos los sucesos. Los equipos deben consultar la disposición aplicable y las orientaciones oficiales vigentes para el suceso y la función de que se trate, en lugar de confiar en una fórmula simplificada para toda la empresa.
Por qué la notificación de incidentes relacionados con la IA de uso general incluye los eventos de ciberseguridad
En el caso de los modelos de IA de uso general con riesgo sistémico, un incidente puede afectar al modelo o a la infraestructura que lo sustenta, y no solo causar un daño inmediatamente visible en una aplicación desplegada. Las orientaciones de la Comisión sobre IA de uso general exigen que los proveedores hagan un seguimiento de los incidentes graves y las posibles medidas correctivas, los documenten y los notifiquen a la Oficina de IA y, cuando proceda, a las autoridades nacionales, sin demora indebida.
Las preguntas frecuentes de la Comisión relacionan expresamente esta obligación de notificación con las brechas graves de ciberseguridad relacionadas con el modelo o con su infraestructura física. Entre los ejemplos que pueden estar sujetos a esta obligación se mencionan la autoexfiltración de parámetros del modelo y los ciberataques. Esta relación amplía el abanico de equipos que podrían detectar una señal que deba notificarse: es posible que los especialistas en seguridad de los modelos no sean los primeros en detectar una alerta de intrusión o una anomalía en la infraestructura.
Vincule las alertas de seguridad con la evaluación de incidentes relacionados con modelos
Una alerta de ciberseguridad no resuelve automáticamente todas las cuestiones relativas a la notificación. El personal de seguridad puede saber que se ha producido un ataque, pero seguir investigando su alcance; entretanto, los equipos de modelos pueden entender las posibles consecuencias sin disponer de los registros de seguridad subyacentes. El proceso de notificación necesita una transferencia de información entre estas funciones para evaluar la relación del suceso con el modelo, su infraestructura y la obligación aplicable de notificar incidentes graves.
Entre los datos iniciales útiles se encuentran el sistema o la infraestructura afectados, el comportamiento observado, el momento en que el equipo tuvo conocimiento del suceso y las medidas de contención u otras medidas correctivas que se estén considerando. Estos datos no sustituyen a una evaluación jurídica. La hacen posible y ayudan al proveedor a explicar cómo fue evolucionando su comprensión de los hechos.
La plantilla de notificación de la Comisión para la IA de uso general está concebida para facilitar la aplicación práctica de las obligaciones de notificación del artículo 55 y ayudar a los proveedores a demostrar que cumplen la normativa. Una plantilla puede promover la coherencia de la información, especialmente cuando varios equipos internos contribuyen a un informe. Sin embargo, por sí sola no puede detectar una brecha, decidir si un suceso es grave ni garantizar que se contacte sin demora indebida con la Oficina de IA y con las autoridades nacionales pertinentes.
También conviene dejar claro un límite práctico: una reclamación de una organización usuaria sobre un producto que utiliza IA y una brecha grave de ciberseguridad relacionada con el modelo subyacente pueden llegar a personas distintas y plantear cuestiones de notificación diferentes. Un canal único para recibir incidentes puede ayudar a registrar ambos casos, pero la evaluación inicial debe identificar el sistema o modelo afectado y la vía de notificación pertinente, en lugar de fusionar obligaciones distintas en una categoría genérica de «incidente de IA».
Crear un proceso de notificación que facilite las medidas correctivas
La notificación obligatoria funciona mejor cuando está vinculada a la capacidad de la organización para comprender y abordar el suceso subyacente. La Comisión presenta la notificación junto con el registro, la transparencia, las medidas correctivas y la cooperación con las autoridades de vigilancia del mercado. Este enfoque apunta a un proceso con responsables claros y pruebas útiles, no simplemente a un formulario que aparece al final de una crisis.
Defina una vía de recepción antes de que se produzca un incidente
Las personas deben saber dónde comunicar una posible señal de incidente grave. Esto incluye al personal que opera un sistema de alto riesgo, los equipos que reciben reclamaciones de usuarios, el personal técnico que supervisa los fallos y los equipos de seguridad que vigilan la infraestructura de un modelo con riesgo sistémico. El canal de recepción debe permitir que se escale una notificación incierta sin exigir que la primera persona que la detecta haga una clasificación jurídica definitiva.
Un registro práctico de recepción distingue las observaciones de quien comunica el suceso del análisis posterior. Puede recoger el sistema o modelo afectado, las consecuencias aparentes, el primer momento conocido del suceso, el primer momento en que la organización tuvo conocimiento de este y las partes ya informadas. Mantener estos datos separados reduce el riesgo de que un relato posterior, ya depurado, oculte lo que se sabía cuando había que decidir si se efectuaba una notificación inmediata.
Asigne las decisiones a las personas adecuadas
Los investigadores técnicos pueden analizar el comportamiento del sistema, pero quizá no sepan qué autoridad de vigilancia del mercado es competente. El personal jurídico o de cumplimiento puede conocer la norma de notificación, pero necesita datos operativos fiables. Un grupo de escalada definido puede reunir los conocimientos necesarios y determinar quién está autorizado a enviar las notificaciones exigidas, aprobar los informes y coordinar las medidas correctivas.
Para los responsables del despliegue, esto también significa tratar los datos de contacto del proveedor como información operativa, en lugar de dejarlos como un detalle enterrado en los expedientes de contratación. Para los proveedores, significa recibir y evaluar las notificaciones de los responsables del despliegue de manera que se conserven su contenido y el momento en que se recibieron. Si intervienen importadores o distribuidores, la vía de notificación prevista para los responsables del despliegue debe quedar clara antes de que un suceso la convierta en urgente.
Utilice las plantillas como ayuda, no como sustituto de la toma de decisiones
El proyecto de orientaciones y la plantilla de la Comisión para notificar incidentes graves relacionados con sistemas de IA de alto riesgo, así como la plantilla específica para modelos con riesgo sistémico de IA de uso general, pueden ayudar a los equipos a organizar la información. Son valiosos precisamente porque los informes de incidentes suelen reunir datos que se encuentran en distintos lugares. Una plantilla debe facilitar la recopilación y la comunicación de información; no debe convertirse en un motivo para retrasar la escalada hasta que todas las respuestas estén claras.
- Detección: Asegúrese de que las señales relacionadas con la seguridad, las operaciones, los derechos, el medio ambiente, la propiedad y la ciberseguridad pertinente lleguen a las personas responsables de evaluar los incidentes.
- Evaluación inicial: Registre la posible consecuencia grave, la relación con la IA que se está examinando y la función aplicable de proveedor, responsable del despliegue o proveedor de IA de uso general.
- Notificación y comunicación de información: Mantenga las vías de contacto exigidas y un registro de cuándo se informó a cada parte o autoridad pertinente.
- Seguimiento: Vincule el registro del incidente con los resultados de la investigación, las posibles medidas correctivas y la cooperación con las autoridades cuando sea necesaria.
Este enfoque implica una contrapartida. Un proceso muy centralizado puede mejorar la coherencia, pero convertirse en un cuello de botella cuando se necesita actuar de inmediato. Un proceso totalmente descentralizado puede ser más rápido al principio, pero llevar a los equipos a aplicar definiciones distintas o a pasar por alto un destinatario obligatorio. La solución intermedia viable consiste en asignar claramente la responsabilidad de la escalada y, al mismo tiempo, permitir que el personal de primera línea comunique rápidamente las situaciones inciertas.
¿Se pueden armonizar las notificaciones de incidentes de IA entre las normas de la UE?
Es posible que las organizaciones ya gestionen procesos de notificación de incidentes de ciberseguridad y de otros ámbitos normativos, además de su trabajo relacionado con el Reglamento de IA. Esto plantea una pregunta evidente sobre la eficiencia: ¿puede un único registro interno de incidentes servir para varias obligaciones de notificación? La idea de lograr una mayor armonización normativa está ganando atención, pero armonizar no significa dar por sentado que distintas leyes tienen los mismos criterios de activación, destinatarios o plazos.
Un documento del Consejo de 2026 sobre el Ómnibus Digital relativo a la IA destaca la existencia de «importantes solapamientos» entre los requisitos de ciberseguridad del Reglamento de IA y otras normas de ciberseguridad de la UE, y señala expresamente la notificación de incidentes como ejemplo. Esta observación respalda una mayor coordinación entre los equipos internos de IA y ciberseguridad. No establece que una notificación realizada en virtud de un régimen cumpla automáticamente las obligaciones de otro.
La OCDE también ha impulsado un marco común para notificar incidentes de IA. Su informe de 2025 describe los datos que deben incluirse en cada informe de incidente y señala que el marco puede adaptarse añadiendo criterios obligatorios para un contexto de notificación concreto. De ahí se desprende un principio útil de diseño: recopilar, cuando sea posible, una sola vez un conjunto básico y coherente de datos sobre el incidente y, después, añadir los campos y las medidas exigidos por la vía legal aplicable.
Un registro interno compartido podría recoger la cronología del suceso, el sistema o modelo de IA afectado, las consecuencias observadas, las pruebas que respaldan un vínculo causal presunto, el estado de la investigación y las notificaciones ya realizadas. A continuación, flujos de trabajo independientes podrían determinar si el suceso está sujeto al artículo 73, a la obligación relativa a los modelos de IA de uso general con riesgo sistémico o a otro proceso aplicable. Esto reduce la duplicación en la recopilación de datos sin borrar diferencias jurídicas importantes.
La normalización tiene sus límites. Una vulneración grave de las protecciones de los derechos fundamentales puede requerir conocimientos distintos de los necesarios para abordar un ciberataque contra la infraestructura de un modelo. La obligación de notificación inmediata del responsable del despliegue también es distinta del informe del proveedor dirigido a las autoridades. Si un formulario común oculta estas diferencias, puede dar una apariencia de coherencia y, al mismo tiempo, dificultar la detección de decisiones urgentes.
El trabajo de la Comisión con datos sobre incidentes, incluido su informe de 2026, en el que se analizaron con más detalle solo determinadas categorías, apunta hacia una clasificación más estructurada. Una clasificación mejor puede ayudar a las organizaciones a comparar incidentes y aprender de ellos con el tiempo. Sin embargo, ante cualquier suceso concreto, la tarea inmediata sigue siendo práctica: determinar qué ha ocurrido, identificar quién tiene la obligación pertinente, conservar la cronología y actuar conforme a la norma aplicable.
La notificación obligatoria de incidentes de IA mejora la capacidad de la UE para identificar riesgos graves relacionados con la IA y responder a ellos, pero su eficacia depende de lo que ocurra antes de presentar un informe. Los proveedores de sistemas de alto riesgo y los responsables del despliegue necesitan una vía fiable de escalada; los proveedores de modelos de IA de uso general con riesgo sistémico necesitan una que conecte la supervisión de los modelos con la ciberseguridad y el seguimiento de la infraestructura.
El siguiente paso más útil es poner a prueba la vía de notificación de la organización ante un incidente plausible: ¿quién lo detectaría?, ¿cuándo se registraría la sospecha?, ¿a qué partes se informaría y quién decidiría qué debe notificarse? Las respuestas basadas en el texto del Reglamento de IA, las orientaciones vigentes de la Comisión y los sistemas reales de la organización son más valiosas que un formulario genérico de incidentes que nadie pueda utilizar bajo presión.
