Notificación de incidentes de IA: aplica las directrices de la OCDE, ETSI y NIST a fallos reales

La notificación de incidentes de IA consiste en documentar de forma estructurada los daños y los cuasiincidentes relacionados con sistemas de IA, para que los equipos de gobernanza puedan cumplir sus obligaciones regulatorias y aprender de los fallos. Beneficia por igual a los equipos de seguridad, cumplimiento y producto al convertir observaciones dispersas en evidencias. Un paso recomendable es adoptar un conjunto mínimo de datos de notificación alineado con los marcos de la OCDE y el NIST y, después, conectarlo con el seguimiento posterior a la comercialización.

En resumen:

• El EU AI Act establece plazos de 2 días para las perturbaciones generalizadas, 10 para los fallecimientos y 15 para otros incidentes graves; las notificaciones iniciales pueden estar incompletas.
• Los registros de incidentes necesitan un identificador del sistema, la persona notificante, las horas del suceso y de su detección, una descripción, el impacto, las partes interesadas y las evidencias, además de cuatro niveles de gravedad y una taxonomía de daños que permita clasificarlos.
• Conserve los registros, las instrucciones y las salidas antes de modificar el sistema, asigne una única persona responsable de la investigación e inicie el cómputo de los plazos regulatorios desde la detección, no desde la resolución.
• Un canal no punitivo, protecciones explícitas para los informantes y la separación entre quienes notifican y quienes toman decisiones fomentan la notificación de cuasiincidentes; los equipos de privacidad deben revisar los datos personales incluidos en las evidencias aportadas.
• Conecte el seguimiento posterior a la comercialización con la notificación de incidentes y exija a los proveedores plazos fijos de notificación, acceso a la causa raíz, intercambio de evidencias y tiempos de respuesta para las investigaciones conjuntas.

Índice

• Qué abarca la notificación de incidentes de IA y cuándo notificar
• Normas y marcos de notificación que conviene conocer
• Campos mínimos de notificación y una taxonomía práctica
• Ciclo de vida del incidente: de la detección al aprendizaje organizativo
• Diseño institucional: funciones, incentivos y anonimato
• Intercambio de datos, repositorios públicos e interoperabilidad
• Métricas e indicadores clave para gestionar un programa de notificación de incidentes
• Integración de la notificación con el seguimiento posterior a la comercialización y los contratos con proveedores
• Qué revelan las auditorías sobre los puntos de fallo de la notificación
• Perspectiva: la notificación de incidentes como mecanismo de confianza y resiliencia
• Cómo llevamos a la práctica la notificación de incidentes y el aseguramiento continuo
• Preguntas frecuentes
• Fuentes

Qué abarca la notificación de incidentes de IA y cuándo notificar

Un incidente es un daño confirmado: un chatbot ofrece consejos médicos peligrosos, un algoritmo de selección de personal descarta a grupos protegidos o un modelo de detección del fraude marca erróneamente transacciones legítimas a gran escala. Un cuasiincidente es el mismo modo de fallo detectado antes de que afecte a una persona, como una comprobación de sesgos que identifica salidas sesgadas durante las pruebas previas al lanzamiento. Ambos deben registrarse, porque los cuasiincidentes suelen anticipar el siguiente incidente confirmado.

Los supuestos que activan la obligación de notificar varían según la jurisdicción, pero el artículo 73 del EU AI Act establece una referencia útil: los proveedores deben notificar los incidentes graves a las autoridades de vigilancia del mercado de inmediato, en un plazo de 2 días para las perturbaciones generalizadas de infraestructuras, de 10 días para los incidentes con fallecimientos y de 15 días para otros incidentes graves. El artículo también permite presentar una notificación inicial incompleta seguida de otra completa, algo importante cuando confirmar la causa raíz exige más tiempo del que permite el plazo.

En el ámbito interno, los umbrales de escalado deben situarse muy por debajo del umbral regulatorio. Esperar a tener certeza antes de registrar cualquier suceso garantiza que se pasen por alto patrones.

• Registre todos los incidentes confirmados y todos los cuasiincidentes con potencial de causar daño, con independencia de su gravedad.
• Escale el caso a la dirección o solicite una revisión jurídica cuando un incidente afecte a la seguridad, implique discriminación o provoque pérdidas económicas.
• Notifique externamente solo cuando se cumpla un umbral definido por la jurisdicción o resulte aplicable una regla de plazos.

Normas y marcos de notificación que conviene conocer

Varios marcos determinan hoy cómo se documentan y comparten los incidentes de IA, y a los equipos de gobernanza les conviene tratarlos como complementarios, no como alternativas rivales.

El marco común de notificación de la OCDE normaliza la notificación de incidentes entre jurisdicciones y sectores mediante 29 criterios específicos que ayudan a identificar sistemas de alto riesgo, evaluar impactos y valorar riesgos emergentes. Esa amplitud es deliberada: un marco diseñado para la comparación transfronteriza necesita criterios lo bastante específicos para ser útiles y lo bastante generales para aplicarse a distintos sectores.

La especificación de expresión común de incidentes de IA del ETSI aborda un problema distinto: la interoperabilidad. Define un formato de contenedor y una estructura de registros JSON para que los datos de incidentes de distintas organizaciones y herramientas puedan intercambiarse y localizarse sin capas de traducción a medida.

El marco de gestión de riesgos de IA y el perfil de IA generativa del NIST se centran en el proceso. El perfil de IA generativa incluye orientaciones específicas, catalogadas con referencias como GV-1.5-001 y GV-4.3-002, sobre responsabilidades de revisión periódica, revisiones posteriores a la actuación y procedimientos de divulgación de incidentes que fundamenten las decisiones de gobernanza, en lugar de quedar archivados.

El EU AI Act conecta estos elementos en el plano operativo: el seguimiento posterior a la comercialización previsto en el artículo 72 genera las evidencias que exige después la notificación de incidentes graves del artículo 73 dentro de sus plazos establecidos.

• OCDE: normalización entre jurisdicciones mediante 29 criterios.
• ETSI AICIE: formato interoperable de contenedor y registro.
• Marco de gestión de riesgos de IA y perfil de IA generativa del NIST: procedimientos de revisión posterior a la actuación y divulgación.
• Artículos 72 a 73 del EU AI Act: el seguimiento aporta información para cumplir las obligaciones de notificación.

Campos mínimos de notificación y una taxonomía práctica

Todas las notificaciones que presente su equipo deben recoger los mismos campos básicos, con independencia de la herramienta o el equipo que las tramite. Las orientaciones del NIST y las investigaciones relacionadas coinciden en un conjunto mínimo de datos que hace que los registros sean útiles para el análisis posterior a la comercialización, y no solo para su archivo.

1. Identificador del sistema: un identificador único y coherente del sistema de IA implicado.
2. Título: un resumen breve de lo ocurrido que facilite las búsquedas.
3. Función de la persona notificante: quién presentó la notificación y qué relación tiene con el sistema.
4. Fecha y hora: cuándo ocurrió el incidente y cuándo se detectó.
5. Descripción: qué ocurrió, en lenguaje claro y sin especular sobre la causa.
6. Impacto observado: quién o qué se vio afectado y de qué manera.
7. Partes interesadas: todas las personas y entidades afectadas por el incidente, tanto internas como externas.
8. Evidencias: registros, capturas de pantalla, transcripciones o salidas del modelo vinculadas al suceso.

Las escalas de gravedad deben ser lo bastante sencillas para que pueda aplicarlas una persona sin perfil técnico: baja, moderada, grave y crítica, reservando la categoría crítica para sucesos relacionados con la seguridad, la discriminación o los supuestos que activan obligaciones regulatorias. Una taxonomía de tipos que abarque sesgos, seguridad, alucinaciones, fallos de escalado y privacidad de los datos permite clasificar las notificaciones para analizar tendencias posteriormente.

Consejo práctico: Genere automáticamente los identificadores de sistema a partir de su inventario de activos, en lugar de permitir que las personas notificantes los escriban libremente; los identificadores en texto libre son la principal causa de registros de incidentes duplicados o sin correspondencia.

Adjuntar evidencias estructuradas, en lugar de pegar texto, también reduce las tareas de depuración manual que deterioran la calidad de las notificaciones con el tiempo.

Ciclo de vida del incidente: de la detección al aprendizaje organizativo

La notificación es una etapa de un ciclo más amplio, y tratarla como un formulario aislado frustra su propósito. Las señales de detección llegan de varias fuentes: umbrales de monitorización automatizada, notificaciones directas de usuarios, fuentes de terceros y auditorías periódicas.

La clasificación inicial debe ser rápida y seguir criterios fijos, en lugar de valoraciones improvisadas. Una regla de decisión rápida resulta eficaz: ¿el incidente afecta a la seguridad, implica discriminación, causa perjuicios económicos o activa una obligación regulatoria? Cualquier respuesta afirmativa lo sitúa en la vía prioritaria.

La investigación exige disciplina. La conservación de evidencias es lo primero: capture los registros y el estado del sistema antes de que nadie intente corregirlo, porque los cambios prematuros destruyen el rastro necesario para confirmar la causa raíz. Quienes investiguen deben resistir la tentación de aplicar un parche y pasar a otra cosa hasta que el registro esté completo.

• Conserve los registros, las instrucciones y las salidas antes de modificar el sistema afectado.
• Asigne una única persona responsable de la investigación para evitar cambios contradictorios durante la revisión.
• Separe los plazos de corrección de los de notificación, ya que los plazos regulatorios empiezan a contar desde la detección, no desde la resolución.

Las notificaciones internas de cualquier caso marcado como prioritario deben llegar de inmediato a los responsables de riesgos y a la asesoría jurídica. La notificación externa sigue los plazos definidos por cada jurisdicción, como los establecidos en el artículo 73 para los incidentes graves en la UE.

Las revisiones posteriores a la actuación cierran el ciclo. Como sostiene el informe de Stanford HAI y RegLab, la finalidad es que la notificación de sucesos adversos permita tanto a las organizaciones como a los responsables de políticas públicas conocer los riesgos en condiciones reales y responder antes de que se repitan, en lugar de limitarse a cumplimentar documentación y pasar a otra cosa.

Diseño institucional: funciones, incentivos y anonimato

Quién notifica, cómo lo hace y con qué protección determina si un sistema de notificación llega a utilizarse. La investigación sobre el diseño de sistemas de notificación de incidentes para IA de uso general identifica decisiones de diseño, especialmente en torno al anonimato y a las medidas de cumplimiento, que afectan de forma drástica al uso del sistema y a la utilidad de la información recopilada.

Siete dimensiones configuran un sistema operativo: el objetivo de política al que sirven las notificaciones, quién puede presentarlas y recibirlas, qué tipos de incidentes se incluyen, cómo se asignan los niveles de riesgo, qué medidas de cumplimiento siguen a una notificación, si existe la opción de anonimato y qué ocurre después de presentarla.

Una matriz RACI clara ayuda a llevarlo a la práctica. La recepción debe estar a cargo de un único equipo, normalmente el de riesgos o cumplimiento, con producto e ingeniería como partes consultadas. La investigación suele dirigirla el equipo responsable del sistema afectado, mientras que riesgos asume la responsabilidad última de la revisión. Las decisiones de divulgación, interna o externa, corresponden a los equipos jurídico y de cumplimiento, con las aportaciones de ambos equipos anteriores.

• Ofrezca un canal de notificación no punitivo para que el personal comunique los cuasiincidentes en lugar de ocultarlos.
• Defina explícitamente y por escrito las protecciones para los informantes antes de que un incidente obligue a abordar la cuestión.
• Separe a la persona que notifica de quien decide las consecuencias.
• Integre una revisión de privacidad en la recepción, ya que las evidencias de incidentes suelen contener datos personales.

Consejo práctico: Un canal de notificación que se perciba como un procedimiento disciplinario producirá menos notificaciones, no sistemas más seguros. Dé prioridad a la seguridad psicológica en su diseño.

Las restricciones jurídicas y de privacidad deben planificarse antes del lanzamiento, no después del primer caso complicado. Las evidencias que incluyen datos de clientes activan sus propias normas de tratamiento, con independencia de la gravedad del incidente.

Intercambio de datos, repositorios públicos e interoperabilidad

Más allá de los registros internos, los repositorios públicos ofrecen a los equipos de gobernanza una forma de comparar su situación con la del conjunto del sector. El registro de seguimiento de incidentes de IA, mantenido por el AI Risk Lab del MIT, clasifica los incidentes por categorías de daño y añade etiquetas generadas por grandes modelos de lenguaje a la base de datos pública de incidentes de IA, ofreciendo a los investigadores una visión de fallos en condiciones reales que permite realizar búsquedas.

Ese mismo registro reconoce abiertamente sus limitaciones: señala la variabilidad de la calidad de las notificaciones y el sesgo de muestreo de los conjuntos de datos voluntarios, ya que los incidentes comunicados no constituyen una muestra aleatoria de los que ocurren. Quien cite los recuentos públicos de incidentes como una imagen completa de los daños de la IA está exagerando lo que muestran los datos.

Los 29 criterios de la OCDE y el formato de contenedor AICIE del ETSI existen precisamente para que las notificaciones de distintas organizaciones puedan compararse e intercambiarse, lo que convierte notificaciones aisladas en un recurso público útil, en lugar de una acumulación de texto no estructurado.

• La divulgación pública crea una base compartida de evidencias, pero puede exponer detalles operativos sensibles.
• El registro exclusivamente interno protege la confidencialidad, pero pasa por alto patrones visibles solo a escala sectorial.
• Es necesario realizar controles de calidad y etiquetar los metadatos antes de reutilizar datos públicos de incidentes para su análisis.

Métricas e indicadores clave para gestionar un programa de notificación de incidentes

Un programa de notificación necesita sus propias métricas de funcionamiento, separadas de los incidentes que registra. Indicadores operativos: tiempo de detección, tiempo de clasificación inicial y tiempo de notificación, medidos respecto a los umbrales internos de escalado y a cualquier plazo regulatorio aplicable.

Los indicadores de calidad son igual de importantes: grado de completitud de las notificaciones respecto al conjunto mínimo de datos, distribución de la gravedad a lo largo del tiempo y tasa de repetición de incidentes vinculados a una misma causa raíz. Una tasa de repetición elevada indica que las revisiones posteriores a la actuación no están cambiando nada.

Los indicadores de resultados cierran el ciclo: reducción de la recurrencia tras una corrección, número de correcciones efectivamente desplegadas a partir de los hallazgos de las investigaciones y preparación demostrable para una auditoría regulatoria. Los 29 criterios del marco de la OCDE ofrecen una lista de comprobación lista para usar en esta última métrica.

• Tiempos de detección, clasificación inicial y notificación, contrastados con los plazos internos y regulatorios.
• Puntuaciones de completitud respecto a los campos del conjunto mínimo de datos.
• Tasa de recurrencia de una misma causa raíz entre periodos de notificación.

Integración de la notificación con el seguimiento posterior a la comercialización y los contratos con proveedores

El seguimiento posterior a la comercialización previsto en el artículo 72 del EU AI Act genera las evidencias continuas que alimentan la notificación de incidentes graves conforme al artículo 73. Ambos no pueden funcionar como programas separados sin crear lagunas en las que se detecta un incidente, pero este nunca llega al circuito de notificación.

Los contratos con proveedores necesitan cláusulas específicas para cerrar esas lagunas cuando interviene un modelo o agente de terceros: plazos de notificación acordes con los umbrales internos de escalado, acceso a la causa raíz en lugar de comunicaciones limitadas a resúmenes, derechos de intercambio de evidencias y tiempos de respuesta definidos en acuerdos de nivel de servicio para las investigaciones conjuntas.

• Exija al proveedor que notifique dentro de un plazo fijo, alineado con su nivel de escalado más rápido.
• Exija acceso a la causa raíz, no solo al resumen de medidas correctoras del propio proveedor.
• Ensaye una investigación entre varios proveedores al menos una vez antes de necesitarla en un caso real.

Qué revelan las auditorías sobre los puntos de fallo de la notificación

Las auditorías revelan de forma recurrente un patrón de fallo específico: agentes conversacionales que gestionan correctamente la interacción hasta el momento en que debe intervenir una persona.

Esa laguna importa más de lo que contempla la mayoría de los marcos de notificación. Un conjunto mínimo de datos y una taxonomía clara solo ayudan una vez registrado el suceso, y el fallo de escalado es precisamente el punto en el que más suele fallar ese registro. La auditoría continua de la totalidad de las conversaciones, en lugar de una revisión por muestreo, permite detectar estos sucesos con la antelación suficiente para registrarlos antes de que se repitan a gran escala.

Perspectiva: la notificación de incidentes como mecanismo de confianza y resiliencia

La mayoría de las organizaciones tratan la notificación de incidentes como un documento de cumplimiento, algo que se elabora para un auditor en lugar de utilizarse. Ese enfoque invierte su valor. El verdadero resultado de un programa de notificación son las evidencias que demuestran a reguladores y clientes que los fallos se detectan y corrigen, en lugar de ocultarse.

Los programas maduros incorporan esas evidencias a las decisiones de diseño, no solo a un archivo. Las organizaciones que tratan la notificación como un mecanismo de resiliencia, y no como un requisito documental, terminan con sistemas que fallan con menos frecuencia porque realmente aprenden de los fallos que registran.

Ponga en marcha la notificación ahora, antes de que un incidente obligue a abordar la cuestión.

— Sergio Llorens

Cómo llevamos a la práctica la notificación de incidentes y el aseguramiento continuo

Hemos desarrollado nuestro enfoque en torno a la laguna que las auditorías siguen detectando: incidentes que nunca se registran porque nadie detectó inicialmente el fallo de escalado. Lexic Compass audita agentes conversacionales de cualquier proveedor, verifica su comportamiento efectivo frente a los requisitos regulatorios y aporta las evidencias que necesita un programa de notificación en el momento de la detección, no a posteriori.

Para ofrecer una cobertura continuada en lugar de una comprobación puntual, Lexic Pulse monitoriza continuamente el 100% de las conversaciones con clientes y genera las evidencias estructuradas y las alertas que alimentan directamente el conjunto mínimo de datos y los umbrales de escalado descritos anteriormente.

• Comience con una revisión preliminar para identificar dónde pueden fallar los agentes al escalar los casos.
• Valore la monitorización continuada para mantener una supervisión constante vinculada a su circuito de notificación.
• Elija plataformas que permitan conservar evidencias de acuerdo con los marcos de la OCDE y el ETSI según sus necesidades.

La conservación de evidencias y los datos de escalado generados se ajustan directamente a las estructuras de la OCDE y el ETSI descritas anteriormente. Consulte las opciones de auditoría y aseguramiento continuo disponibles para encontrar el punto de partida adecuado para su programa de gobernanza.

Preguntas frecuentes

¿La IA denuncia delitos?

Los sistemas de IA no denuncian delitos por sí mismos en sentido jurídico; pueden señalar anomalías o patrones a revisores humanos, quienes deciden después si procede comunicarlos a las autoridades. Los marcos de notificación de incidentes como los aquí descritos documentan fallos y daños de los sistemas de IA, no actividades delictivas.

¿Cuándo debe notificarse un incidente de seguridad?

Un incidente de seguridad vinculado a un sistema de IA debe notificarse internamente en cuanto se detecta, mientras que la notificación externa debe seguir los plazos regulatorios aplicables. Conforme al artículo 73 del EU AI Act, los incidentes graves están sujetos a plazos específicos, incluidos 2 días para las perturbaciones generalizadas y 10 días para los incidentes con fallecimientos.

¿Qué es la regla del 30% en IA?

No existe una «regla del 30%» establecida en la gobernanza de la IA ni en las normas de notificación de incidentes; las definiciones varían según el contexto y ninguno de los principales marcos aquí descritos, incluidos los de la OCDE, el NIST o el EU AI Act, define ese umbral. Quienes encuentren este término deben comprobar la fuente concreta que lo utiliza, ya que no forma parte de ninguna norma de notificación reconocida.

¿Cuál es la mejor IA para la notificación?

No hay una única herramienta que sea la mejor, porque la calidad de la notificación de incidentes depende más del conjunto mínimo de datos, la taxonomía y el proceso de escalado que de un programa informático concreto. Las plataformas que admiten campos estructurados, evidencias adjuntas y formatos alineados con la OCDE o el ETSI, como Lexic Compass para la recopilación de evidencias mediante auditorías, suelen producir registros más útiles que las herramientas de gestión de incidencias de uso general.

¿Cómo se documenta el sesgo en una notificación de incidente?

Un incidente de sesgo o equidad debe registrarse con el mismo conjunto mínimo de datos que cualquier otro incidente, especificando en el impacto observado qué grupos se vieron afectados y de qué manera. Las evidencias deben incluir las salidas o decisiones concretas que suscitaron la preocupación, ya que los incidentes de sesgo suelen ser objeto de controversia y necesitan un registro claro para poder investigarse.

Fuentes

• Hacia un marco común de notificación de incidentes de IA (OCDE)
• Marco de gestión de riesgos de inteligencia artificial: perfil de inteligencia artificial generativa (NIST)
• Notificación de sucesos adversos de IA: desarrollo de la infraestructura de información que las administraciones públicas necesitan para aprender y actuar (Stanford HAI / RegLab)
• Registro de seguimiento de incidentes de IA (MIT/AI Risk Lab)
• Marco global de expresión común de incidentes de IA (AICIE) (ETSI TS 104 158-01)