Los reguladores están sacando la notificación de incidentes de IA del ámbito de la ética voluntaria para llevarla al de la gobernanza formal. El ejemplo más claro es el Reglamento de IA de la UE, que exige a los proveedores de sistemas de IA de alto riesgo que notifiquen los incidentes graves a las autoridades pertinentes. Al mismo tiempo, las plantillas de la Comisión Europea, las obligaciones de registro para los responsables del despliegue del sector público y el trabajo de supervisión internacional de la OCDE están creando una expectativa más amplia: los fallos significativos de la IA deben documentarse de forma coherente para que los reguladores, operadores, responsables políticos y el público puedan aprender de ellos.
Esto no significa que todos los expedientes de incidentes se conviertan automáticamente en documentos totalmente públicos. La notificación reglamentaria a una autoridad, el registro en una base de datos oficial y la publicación de un resumen público del incidente son mecanismos diferentes. Un análisis fiable de los informes públicos de incidentes de IA debe mantener esas distinciones. Aun así, la orientación de las políticas es clara. Las autoridades quieren notificaciones más rápidas, pruebas más estructuradas, medidas correctivas documentadas y una mayor visibilidad de los patrones de daños reales y peligros emergentes.
Por qué la notificación de incidentes de IA se está convirtiendo en una prioridad regulatoria
Los sistemas de IA pueden influir en decisiones y servicios a una escala que dificulta la evaluación de fallos aislados. Un funcionamiento defectuoso que afecte a una persona puede revelar una debilidad de diseño capaz de afectar a muchas otras. Una interrupción relacionada con infraestructuras críticas puede poner de manifiesto dependencias que ni el proveedor ni el responsable del despliegue comprendían plenamente antes del suceso.
Los informes de incidentes ayudan a convertir esos sucesos individuales en información útil para la gobernanza. Pueden mostrar qué ocurrió, qué sistema estuvo implicado, cómo se produjo el daño, si las personas o las infraestructuras siguen expuestas y qué medidas correctivas se han adoptado. Cuando los informes utilizan categorías compatibles, las autoridades también pueden ir más allá de un único caso e identificar modalidades de fallo recurrentes.
La OCDE afirma que la notificación y la supervisión de incidentes de IA deben ser “coherentes e interoperables a escala mundial” para que los responsables políticos y los operadores puedan aprender de los riesgos e incidentes notificados en todo el mundo.
Este énfasis en el aprendizaje es importante. La notificación de incidentes no es solo un mecanismo para atribuir responsabilidades después de que se produzca un daño. También puede contribuir a la prevención al mostrar dónde fallaron los controles técnicos, la supervisión humana, los procedimientos de despliegue o la comunicación organizativa.
Están convergiendo varios objetivos regulatorios:
- Rendición de cuentas: Los proveedores y responsables del despliegue deben poder explicar qué ocurrió y cómo respondieron.
- Intervención rápida: Las autoridades necesitan recibir una notificación inmediata cuando un sistema de IA pueda estar relacionado con una muerte, daños graves para la salud, vulneraciones de derechos fundamentales, interrupciones de infraestructuras u otros daños graves.
- Aprendizaje normativo: Los informes estructurados pueden revelar patrones que no resultan visibles a partir de reclamaciones individuales o noticias de prensa.
- Acción correctiva: La notificación puede vincular un incidente con medidas de contención, subsanación, supervisión o cambios en la forma de desarrollar y utilizar un sistema.
- Confianza pública: Una divulgación adecuada puede demostrar que los fallos significativos se reconocen en lugar de ocultarse.
Los informes públicos de incidentes de IA pueden contribuir a todos estos objetivos, pero su publicación requiere un diseño cuidadoso. Un registro público útil debe proporcionar suficientes detalles para permitir el escrutinio sin exponer innecesariamente datos personales, información confidencial o detalles técnicos sensibles para la seguridad. Este equilibrio es una de las razones por las que son importantes los marcos normalizados de notificación: pueden separar la información que necesitan los reguladores de la que resulta adecuada para una divulgación más amplia.
Qué exige el Reglamento de IA de la UE para los incidentes graves
El Reglamento de IA de la UE establece para los proveedores de sistemas de IA de alto riesgo una obligación vinculante de notificar los incidentes graves. Esto hace que la notificación vaya más allá de las declaraciones generales sobre una IA responsable. Cuando se cumplen las condiciones pertinentes, los proveedores deben notificarlo a las autoridades, en lugar de decidir únicamente mediante una política interna voluntaria si un suceso es lo bastante significativo como para divulgarlo.
El significado de un incidente grave
En virtud del Reglamento, un incidente grave es un incidente o funcionamiento defectuoso de un sistema de IA que provoca directa o indirectamente uno o varios resultados graves especificados. La definición se centra en las consecuencias, incluidas las indirectas, y no solo en si un componente de software sufrió un fallo visible.
- Muerte o daños graves para la salud de una persona
- Una interrupción grave de infraestructuras críticas
- El incumplimiento de obligaciones derivadas del Derecho de la UE destinadas a proteger los derechos fundamentales
- Daños graves a la propiedad o al medio ambiente
Este alcance es importante porque puede producirse un comportamiento perjudicial de la IA incluso cuando un sistema continúa funcionando según lo previsto desde una perspectiva técnica limitada. Un resultado puede generarse correctamente y, aun así, contribuir a una vulneración grave de derechos. Del mismo modo, un modelo puede seguir estando disponible mientras provoca un problema operativo en cascada dentro de un entorno que depende de sus recomendaciones.
Por tanto, las organizaciones necesitan algo más que una supervisión convencional de la disponibilidad del software. Necesitan procesos capaces de detectar consecuencias para la salud, la seguridad, los derechos, las infraestructuras, la propiedad y el medio ambiente. Los equipos técnicos pueden observar el comportamiento del modelo, mientras que los equipos jurídicos, de cumplimiento normativo, seguridad, protección, atención al cliente u operaciones pueden disponer de las pruebas que eleven un suceso a la categoría de incidente grave.
Los plazos de notificación son deliberadamente estrictos
El Reglamento de IA no considera la notificación de incidentes graves como una investigación sin un plazo definido. En caso de muerte, debe presentarse un informe inmediatamente después de que el proveedor o el responsable del despliegue determine o sospeche que existe una relación causal entre el sistema de IA y el suceso. En cualquier caso, el informe debe presentarse como máximo diez días después de tener conocimiento del incidente.
Los demás incidentes graves deben notificarse, por lo general, en un plazo de quince días. El marco establece plazos más breves para los incumplimientos graves de obligaciones y las interrupciones graves de infraestructuras críticas. Dado que el plazo aplicable depende del incidente, las organizaciones deben consultar los requisitos vigentes en lugar de suponer que siempre se aplica el plazo general de quince días.
La referencia a una relación causal sospechada es significativa desde el punto de vista operativo. Un proveedor puede tener que notificar a una autoridad antes de haber completado el análisis de la causa raíz o de haber alcanzado una conclusión jurídica definitiva. Esperar a tener una certeza absoluta puede ser incompatible con un plazo que comienza a contar desde que se tiene conocimiento del incidente y se albergan sospechas.
- Debe registrarse el momento en que se tuvo conocimiento. La organización necesita una forma definida de determinar cuándo tuvo conocimiento del incidente el personal pertinente.
- La posible causalidad debe evaluarse rápidamente. Los equipos deben examinar si el sistema de IA pudo haber contribuido directa o indirectamente al resultado.
- La gravedad debe someterse a una clasificación inicial. Las consecuencias deben evaluarse con arreglo a las categorías de incidentes graves del Reglamento.
- La notificación no debe esperar a que concluya toda la investigación. Un informe inicial puede reflejar lo que se sabe en ese momento, siempre que la incertidumbre se presente con honestidad.
- Deben documentarse las pruebas posteriores y las acciones correctivas. El registro del incidente debe desarrollarse a medida que avance la investigación.
Esta estructura favorece una escalada temprana y un seguimiento disciplinado. También hace que el mantenimiento de registros sea esencial. Si posteriormente una autoridad pregunta por qué se notificó o no un suceso, la organización debe poder mostrar cómo evaluó la gravedad, la causalidad, los plazos y la información disponible en cada etapa.
Los informes reglamentarios, el registro en bases de datos y la divulgación pública no son lo mismo
La expresión “informes públicos de incidentes de IA” puede difuminar varias formas diferentes de transparencia. El Reglamento de IA de la UE exige que los incidentes graves relacionados con sistemas de IA de alto riesgo se notifiquen a las autoridades. Este requisito no significa, por sí solo, que cada notificación y cada documento justificativo deban publicarse sin restricciones.
Deben mantenerse separados tres niveles:
- La notificación reglamentaria confidencial proporciona a las autoridades competentes la información necesaria para evaluar un incidente, coordinar la supervisión y considerar medidas correctivas.
- El registro en una base de datos oficial crea una visibilidad estructurada sobre los sistemas cubiertos y su despliegue, con arreglo al diseño y las normas de acceso de la base de datos.
- La divulgación pública de incidentes comunica determinados hechos a las comunidades afectadas, investigadores, clientes, periodistas, organizaciones de la sociedad civil y otras partes interesadas.
Estos niveles pueden reforzarse mutuamente, pero se dirigen a públicos diferentes. Los reguladores pueden requerir detalles personales, comerciales o técnicamente sensibles que no sería adecuado incluir en un registro público sin restricciones. Por el contrario, una comunicación técnica concebida para una autoridad puede resultar demasiado especializada para ayudar a una persona afectada a comprender las consecuencias de un incidente.
Las autoridades públicas tienen responsabilidades adicionales
El Servicio de Información sobre el Reglamento de IA de la UE señala que las autoridades públicas que despliegan sistemas de IA de alto riesgo deben garantizar su registro en la base de datos de la UE. Si una autoridad pública identifica un incidente grave, debe informar inmediatamente al proveedor, al importador o distribuidor y a las autoridades de vigilancia del mercado pertinentes.
Esto crea una cadena de comunicación en lugar de hacer recaer toda la carga sobre un único participante. Un proveedor puede comprender el diseño, el entrenamiento, las pruebas y las actualizaciones del modelo, mientras que un responsable del despliegue del sector público puede ser el primero en observar cómo afecta el sistema a las personas en un entorno administrativo real. Los importadores, distribuidores y autoridades de vigilancia del mercado pueden tener otras responsabilidades o información necesaria para dar una respuesta eficaz.
El registro y la notificación de incidentes también tienen finalidades diferentes. El registro ayuda a determinar dónde se utiliza un sistema de alto riesgo y quién lo utiliza. La notificación de incidentes indica que un suceso perjudicial o un funcionamiento defectuoso puede requerir atención urgente. Juntos, pueden ayudar a las autoridades a relacionar un incidente con el sistema, el proveedor y el contexto de despliegue pertinentes.
Para los organismos públicos, la transparencia tiene especial importancia porque el uso de la IA puede vincularse con los servicios públicos y el ejercicio de la autoridad oficial. Sin embargo, la comunicación pública debe seguir siendo precisa. Una declaración prematura que presente una sospecha como una causalidad demostrada puede inducir a error, mientras que el silencio puede dejar a las personas afectadas sin conocimiento de un riesgo significativo. Una divulgación bien diseñada debe distinguir claramente entre hechos confirmados, evaluaciones actuales, cuestiones no resueltas y actualizaciones previstas.
Cómo pueden las organizaciones crear un proceso de notificación de incidentes defendible
Los plazos estrictos no pueden cumplirse de forma fiable mediante una cadena improvisada de correos electrónicos. Los proveedores y responsables del despliegue necesitan un proceso de gestión de incidentes que conecte la supervisión técnica con las obligaciones jurídicas y los daños del mundo real. El proceso debe establecerse antes de que se produzca un suceso grave.
1. Definir ampliamente los canales de recepción
Los incidentes de IA pueden aparecer inicialmente en alertas de supervisión, reclamaciones de usuarios, recursos, informes de seguridad, incidencias de ciberseguridad, conclusiones de auditorías, noticias de prensa o información de un socio de despliegue. Un programa defendible debe identificar todos los canales de recepción significativos y dirigir las señales pertinentes a una función común de evaluación.
El personal de primera línea necesita criterios prácticos para la escalada. No tiene que tomar la decisión reglamentaria definitiva, pero debe saber que los informes relacionados con muertes, daños graves para la salud, infraestructuras críticas, derechos fundamentales, propiedad o daños medioambientales requieren una revisión urgente.
2. Conservar las pruebas necesarias para reconstruir el suceso
Una investigación puede depender de las versiones del sistema, los registros de configuración, las entradas y salidas pertinentes, los registros de actividad, los pasos de revisión humana, las instrucciones de despliegue y el calendario de actualizaciones. La conservación debe ser proporcionada y lícita, con controles adecuados para los datos personales y la información sensible.
El objetivo no es recopilarlo todo indiscriminadamente. Consiste en conservar las pruebas necesarias para comprender qué hizo el sistema, qué hicieron las personas, qué controles estaban activos y cómo se desarrolló el resultado. Si los registros se sobrescriben antes de tomar una decisión de escalada, tanto la notificación como la acción correctiva resultan más difíciles.
3. Evaluar la gravedad y la causalidad sin exigir certeza
El equipo de revisión debe determinar si el suceso encaja en un resultado propio de un incidente grave y si el sistema de IA pudo haber contribuido directa o indirectamente. Esta evaluación debe incluir el entorno de despliegue, porque el daño puede surgir de la interacción entre un modelo, una interfaz, los procedimientos operativos, los datos y las decisiones humanas.
Los equipos deben registrar la incertidumbre en lugar de utilizarla como motivo para detener el análisis. Una cronología concisa del incidente puede identificar los sucesos confirmados, los vínculos plausibles, las lagunas probatorias y las explicaciones alternativas. Esto es especialmente importante cuando el plazo de notificación puede vencer antes de que concluya el análisis de la causa raíz.
4. Asignar de antemano los derechos de decisión
Un plan eficaz establece quién puede clasificar un incidente, autorizar un informe, ponerse en contacto con la autoridad pertinente y aprobar una declaración pública. Se necesitan suplentes para las ausencias y los sucesos que se produzcan fuera del horario laboral habitual. El plan también debe abordar la comunicación entre proveedores, responsables del despliegue, importadores, distribuidores y autoridades cuando estos actores estén implicados.
La responsabilidad no debe limitarse al equipo técnico. Una respuesta interfuncional puede requerir conocimientos especializados de ingeniería, producto, seguridad, asuntos jurídicos, cumplimiento normativo, privacidad, ciberseguridad, comunicación y operaciones. La alta dirección debe tener visibilidad de los casos graves sin convertirse en un cuello de botella que consuma el plazo disponible para la notificación.
5. Preparar un informe inicial y un proceso controlado de actualización
La primera notificación debe describir con precisión qué se sabe y qué sigue bajo investigación. Debe identificar el sistema y el incidente, resumir las consecuencias, explicar la relación sospechada, describir las medidas inmediatas de contención e indicar, cuando proceda, las medidas correctivas que se estén considerando.
Después de la notificación, la organización debe mantener un registro controlado de las nuevas pruebas, decisiones y medidas de subsanación. Las actualizaciones no deben sustituir silenciosamente a las versiones anteriores. Un historial claro ayuda a demostrar cómo evolucionó la comprensión del incidente y por qué las conclusiones posteriores pueden diferir de la evaluación inicial.
6. Separar los detalles reglamentarios de la comunicación pública
Un regulador puede necesitar información que no pueda divulgarse íntegramente de forma segura o lícita. Por tanto, las organizaciones deben preparar una vía de divulgación pública paralela a la vía reglamentaria. La versión pública puede explicar la naturaleza del suceso, las repercusiones conocidas, las protecciones vigentes y las vías de asistencia sin exponer información personal ni detalles que puedan generar riesgos para la seguridad.
Esta separación no debe convertirse en una excusa para utilizar un lenguaje impreciso. Declaraciones como “se produjo un problema” ofrecen muy poca rendición de cuentas. Un informe público útil debe describir la función del sistema de IA, el contexto de despliegue pertinente, la categoría del daño, el estado de la investigación y las acciones correctivas significativas, sujeto a restricciones legítimas.
Las plantillas normalizadas están convirtiendo las políticas en infraestructura
La notificación de incidentes resulta más valiosa cuando los informes pueden compararse. Las narraciones en formato libre pueden contener datos importantes, pero una terminología incoherente dificulta la agregación de sucesos, la detección de tendencias o el intercambio de información entre autoridades y países.
La Comisión Europea ha avanzado hacia una divulgación normalizada. En 2025 publicó una plantilla de notificación de incidentes graves relacionados con modelos de IA de uso general con riesgo sistémico. El trabajo de la Comisión sobre la aplicación de la IA en 2026 también incluye expresamente una “Plantilla para la notificación de incidentes graves por parte de los proveedores de sistemas de IA de alto riesgo”.
Estas plantillas indican una fase operativa de la aplicación. Pueden orientar a los proveedores hacia categorías comunes, reducir la incertidumbre sobre la información esperada y facilitar a las autoridades el procesamiento de los informes. La normalización también puede favorecer futuros resúmenes públicos al crear campos coherentes que puedan divulgarse cuando resulte adecuado.
Modelos de IA de uso general con riesgo sistémico
El Servicio de Información sobre el Reglamento de IA señala que los proveedores de modelos de IA de uso general con riesgo sistémico deben llevar un seguimiento y documentar los incidentes graves. Deben notificar esos incidentes y las posibles medidas correctivas sin demora indebida a la Oficina de IA y, cuando proceda, a las autoridades nacionales competentes.
La referencia a las medidas correctivas amplía el valor del informe. Las autoridades necesitan saber no solo que se produjo un daño, sino también qué está haciendo el proveedor para evitar que se repita. Es posible que las medidas propuestas sigan sometidas a evaluación, por lo que los proveedores deben evitar presentar una respuesta no probada como una solución completada.
Los modelos de uso general también pueden generar dificultades particulares para la notificación porque el proveedor puede no controlar todos los usos posteriores. Las organizaciones responsables del despliegue pueden tener la visión más clara de las consecuencias locales, mientras que el proveedor del modelo puede estar mejor situado para determinar si un comportamiento similar podría aparecer en múltiples aplicaciones. Por tanto, la gestión eficaz de incidentes depende de canales contractuales y operativos para compartir información.
La base de datos de la UE forma parte del entorno emergente de notificación
Un documento del Consejo de 2026 señaló que se esperaba que la base de datos de la UE para sistemas de IA de alto riesgo estuviera operativa en el segundo trimestre de 2026, junto con otras directrices de aplicación del Reglamento de IA. Este calendario indica que la infraestructura de apoyo para el registro y la supervisión se está haciendo operativa, en lugar de seguir siendo un proyecto normativo puramente conceptual.
Una base de datos no resuelve automáticamente el problema de la calidad. Su utilidad depende de que las entradas sean precisas, las clasificaciones coherentes, las actualizaciones oportunas y las normas de acceso claras. Sin embargo, puede proporcionar una estructura compartida que facilite la conexión entre los sistemas regulados, los actores responsables, los entornos de despliegue y la información sobre incidentes.
El trabajo de la OCDE muestra por qué es importante la interoperabilidad mundial
Los sistemas de IA y las cadenas de suministro atraviesan fronteras, pero las normas de notificación de incidentes suelen aplicarse en jurisdicciones jurídicas concretas. Sin conceptos compatibles, el mismo suceso podría clasificarse de manera diferente en distintos países, lo que dificultaría el aprendizaje internacional.
OECD.AI sostiene que la notificación y la supervisión de incidentes deben ser coherentes e interoperables a escala mundial. La interoperabilidad no exige necesariamente que todos los países adopten leyes idénticas. Sí requiere una alineación suficiente de las definiciones y las estructuras de datos para que las autoridades y los operadores puedan comprender y comparar los informes.
No deben confundirse los incidentes y los peligros
El marco de la OCDE distingue entre un incidente de IA y un peligro de IA. Un incidente es un suceso en el que el desarrollo o uso de un sistema de IA provoca un daño real. Un peligro es un suceso potencialmente dañino.
Esta distinción permite un análisis más claro:
- La notificación de incidentes registra los resultados perjudiciales reales y las circunstancias que los produjeron.
- La notificación de peligros puede revelar señales de advertencia, incidentes evitados por poco o condiciones que podrían causar daños aunque todavía no se haya producido ninguno.
- El análisis combinado puede relacionar las señales preventivas con resultados posteriores y ayudar a las organizaciones a priorizar los controles.
Las obligaciones reglamentarias del Reglamento de IA de la UE se centran en los incidentes graves que cumplen los criterios jurídicos. Un programa interno de seguridad puede adoptar un alcance más amplio mediante el seguimiento de peligros y sucesos de menor gravedad. Esta perspectiva interna más amplia puede ayudar a identificar debilidades recurrentes antes de que produzcan un resultado sujeto a notificación.
La supervisión casi en tiempo real aporta visibilidad, pero no una verificación completa
El Monitor de Incidentes y Peligros de IA de la OCDE se puso en marcha en 2023. Según la OCDE, realiza un seguimiento en tiempo real de incidentes reales de IA notificados en la prensa y utiliza un marco de notificación para estructurar los datos.
Este enfoque proporciona visibilidad oportuna sobre los sucesos que surgen en distintos lugares y sectores. Puede ayudar a investigadores y responsables políticos a identificar cuestiones que requieran una investigación más profunda. Sin embargo, no debe considerarse un registro completo de todos los incidentes de IA ni una prueba definitiva de todas las relaciones causales notificadas.
Un documento de la Comisión Europea de 2026 explicita esta limitación al analizar las bases de datos de incidentes. Señala que las bases de datos analizadas no contienen información completa y verificada sobre todos los incidentes de IA. También indica que algunas bases de datos utilizan IA y recopilan incidentes a partir de fuentes públicas, principalmente de la cobertura de los medios de comunicación.
Estas pruebas respaldan una interpretación prudente. Las bases de datos derivadas de los medios de comunicación son herramientas valiosas de descubrimiento, pero pueden reflejar una cobertura desigual, detalles técnicos incompletos y acusaciones no resueltas. Los sistemas oficiales de notificación pueden mejorar el acceso a pruebas estructuradas, mientras que los monitores públicos pueden sacar a la luz casos que, de otro modo, podrían quedar fuera de los canales formales. Ambos enfoques son complementarios, no intercambiables.
Qué debe comunicar un informe público fiable de incidentes de IA
Un informe público debe ayudar a los lectores a comprender el suceso sin exagerar lo que sabe la organización. Debe estar redactado para las personas afectadas y los observadores informados, no solo para especialistas que ya comprendan la arquitectura del sistema.
Una divulgación pública sólida puede abordar varias preguntas esenciales:
- ¿Qué sistema estuvo implicado? Identifique su función y el contexto de despliegue pertinente con un lenguaje claro.
- ¿Qué ocurrió? Describa el suceso y el tipo de daño real o sospechado sin minimizarlo.
- ¿Cuándo fue informada la organización? Proporcione una cronología significativa cuando resulte adecuado divulgarla.
- ¿Quién puede verse afectado? Explique el grupo o servicio afectado sin exponer datos personales.
- ¿Qué se sabe sobre la causalidad? Separe las conclusiones confirmadas de las relaciones sospechadas o no resueltas.
- ¿Qué medidas inmediatas se adoptaron? Indique, cuando proceda, si se restringió el uso, se intensificó la supervisión o se introdujo otra medida de contención.
- ¿Qué medidas correctivas se están considerando o aplicando? Distinga las medidas propuestas de los cambios completados y probados.
- ¿Se actualizará el informe? Explique cómo se comunicarán los nuevos hallazgos relevantes.
La fiabilidad depende de la precisión. Un informe no debe dar a entender que la notificación reglamentaria demuestra que el sistema de IA causó el daño; la notificación puede producirse mientras la causalidad siga siendo una sospecha. Tampoco debe sugerir que un incidente fue inocuo simplemente porque la investigación siga abierta.
La transparencia necesita límites
La publicación debe tener en cuenta la privacidad, la seguridad, los procedimientos jurídicos y la confidencialidad legítima. Es posible que los expedientes personales, los detalles de seguridad que puedan aprovecharse con fines maliciosos y la información que pueda comprometer una investigación deban omitirse o resumirse.
Esos límites deben aplicarse de manera restringida y explicarse siempre que sea posible. Un secretismo excesivo puede impedir el aprendizaje externo y debilitar la confianza, mientras que una divulgación indiscriminada puede generar nuevos daños. Un modelo por niveles puede proporcionar una notificación detallada a las autoridades, un registro controlado para los socios pertinentes y un resumen público diseñado para garantizar la rendición de cuentas.
Las correcciones forman parte de una notificación fiable
Los primeros informes de incidentes contendrán en ocasiones información provisional. Las organizaciones deben hacer las correcciones de forma visible, en lugar de modificar silenciosamente el registro. Cada actualización debe indicar qué ha cambiado, si se ha modificado la evaluación del daño o de la causalidad y qué nuevas pruebas han fundamentado el cambio.
Este enfoque refleja cómo funcionan realmente las investigaciones graves. La precisión no exige fingir que se sabe todo de inmediato. Exige ser transparente sobre la incertidumbre, conservar el historial de la evaluación y corregir los errores cuando se disponga de mejores pruebas.
Qué deben hacer ahora los proveedores, los responsables del despliegue y los responsables políticos
Los proveedores de sistemas de alto riesgo deben vincular sus obligaciones de notificación con desencadenantes operativos reales. Necesitan saber qué equipos reciben las señales de incidentes, quién evalúa una posible relación causal, quién controla el plazo aplicable y quién se comunica con las autoridades pertinentes. Los proveedores de modelos de IA de uso general con riesgo sistémico también deben estar preparados para documentar los incidentes y las posibles medidas correctivas a fin de notificarlos a la Oficina de IA y, cuando proceda, a las autoridades nacionales competentes.
Los responsables del despliegue no deben suponer que la respuesta a los incidentes corresponde únicamente al proveedor. El entorno de despliegue puede determinar cómo afecta un resultado de IA a una persona, servicio o infraestructura. Las autoridades públicas que utilizan sistemas de alto riesgo tienen responsabilidades explícitas de registro y notificación, incluida la obligación de informar inmediatamente a los actores pertinentes de la cadena de suministro y a las autoridades de vigilancia del mercado cuando identifiquen un incidente grave.
Los responsables políticos y los operadores de bases de datos deben dar prioridad a definiciones compatibles, campos estructurados, procedencia de los datos, mecanismos de corrección y normas de acceso claras. Los datos públicos deben indicar si una entrada procede de una comunicación oficial, una divulgación de un proveedor, un responsable del despliegue, informaciones de los medios de comunicación u otra fuente. Este contexto permite a los usuarios evaluar el nivel de verificación en lugar de tratar todos los registros como si estuvieran igualmente acreditados.
Las organizaciones pueden prepararse poniendo a prueba el flujo de trabajo de notificación mediante simulacros basados en diferentes escenarios de daños. El ejercicio debe examinar si una señal llega al equipo correcto, si pueden conservarse las pruebas pertinentes, si los responsables de tomar decisiones comprenden la definición jurídica y si puede prepararse una notificación inicial dentro de un plazo reducido. También debe probar la transición desde la notificación confidencial hasta una comunicación pública responsable.
El avance hacia los informes públicos de incidentes de IA se refiere, en última instancia, al aprendizaje institucional. El Reglamento de IA de la UE establece obligaciones vinculantes para los incidentes graves, las plantillas de la Comisión están normalizando la información que reciben las autoridades y la OCDE está desarrollando conceptos y herramientas de supervisión que favorecen la comprensión internacional. Cada elemento aborda una parte diferente del problema: obligación, estructura, visibilidad y aprendizaje transfronterizo.
El éxito no debe medirse únicamente por la publicación. Un sistema fiable debe producir informes oportunos, preservar la incertidumbre, proteger la información sensible, permitir las correcciones y vincular la divulgación con las acciones correctivas. Cuando existen estas salvaguardias, la notificación de incidentes puede hacer algo más que documentar un fallo a posteriori: puede ayudar a los reguladores, proveedores, responsables del despliegue y al público a reducir la probabilidad de que vuelva a repetirse el mismo daño.
