Notificación de incidentes de IA: aplique 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 recomendado es adoptar un conjunto mínimo de datos de notificación alineado con los marcos de la OCDE y del 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 interrupciones generalizadas, 10 para los fallecimientos y 15 para otros incidentes graves; los informes iniciales pueden estar incompletos.
• Los registros de incidentes necesitan un identificador del sistema, la persona que notifica, las fechas y 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 ordenar los registros.
• Conserve los registros, los prompts y las salidas antes de modificar el sistema, asigne un único responsable de la investigación y compute 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 presentadas.
• 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 información sobre las causas 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 del informe 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 contratación descarta a grupos protegidos o un modelo de detección de 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 las obligaciones regulatorias 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 interrupciones generalizadas de infraestructuras, de 10 días para los incidentes que impliquen un fallecimiento y de 15 días para otros incidentes graves. El artículo también permite presentar un informe inicial incompleto seguido de uno completo, algo importante cuando confirmar la causa raíz requiere más tiempo del que permite el plazo.

A nivel 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ños, independientemente de su gravedad.
• Escale el caso a la dirección o sométalo a revisión jurídica cuando un incidente afecte a la seguridad, implique discriminación o provoque pérdidas económicas.
• Notifíquelo externamente solo cuando resulte aplicable un umbral o una regla de plazos definidos por la jurisdicción.

Normas y marcos de notificación que conviene conocer

Actualmente, varios marcos determinan 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, valorar sus impactos y evaluar riesgos emergentes. Esa amplitud es deliberada: un marco diseñado para la comparación transfronteriza necesita criterios lo bastante específicos para resultar útiles y lo bastante generales para aplicarse en distintos sectores.

La especificación de expresión común de incidentes de IA de ETSI aborda un problema distinto: la interoperabilidad. Define un formato 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 conversió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 bajo 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 comunicación de incidentes que sirven de base para las decisiones de gobernanza, en lugar de quedar archivados.

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

• OCDE: normalización entre jurisdicciones mediante 29 criterios.
• ETSI AICIE: formato interoperable de contenedor y registros.
• 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 de comunicación.
• Artículos 72 a 73 del EU AI Act: el seguimiento aporta la información necesaria para cumplir las obligaciones de notificación.

Campos mínimos del informe y una taxonomía práctica

Todos los informes que presente su equipo deben recoger los mismos campos básicos, independientemente de la herramienta o del equipo que los presente. Las orientaciones del NIST y las investigaciones relacionadas coinciden en un conjunto mínimo de datos que permite 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 para el sistema de IA implicado.
2. Título: un resumen breve de lo ocurrido que facilite las búsquedas.
3. Función de la persona que notifica: quién presentó el informe y su relación con el sistema.
4. Fecha y hora: cuándo ocurrió el incidente y cuándo se detectó.
5. Descripción: qué ocurrió, en un 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 partes 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 la activación de obligaciones regulatorias. Una taxonomía de tipos que abarque sesgos, seguridad, alucinaciones, fallos de escalado y privacidad de los datos permite ordenar los informes para analizar tendencias posteriormente.

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

Los archivos adjuntos de evidencias estructuradas, en lugar de texto pegado, también reducen la depuración manual que deteriora la calidad de los informes 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 desvirtúa su finalidad. Las señales de detección proceden de varias fuentes: umbrales de supervisión automatizada, notificaciones directas de usuarios, fuentes de información de terceros y auditorías periódicas.

La clasificación inicial debe realizarse con rapidez y seguir criterios fijos, en lugar de basarse en valoraciones improvisadas. Una regla de decisión rápida funciona bien: ¿el incidente afecta a la seguridad, implica discriminación o daños 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 preservación de evidencias es lo primero: capture los registros y el estado del sistema antes de que alguien intente corregirlo, porque los cambios prematuros destruyen el rastro necesario para confirmar la causa raíz. Los investigadores deben resistir la tentación de aplicar un parche y pasar a otra cosa hasta que el registro esté completo.

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

La notificación interna debe llegar de inmediato a los responsables de riesgos y a la asesoría jurídica en todos los casos clasificados como prioritarios. La notificación externa sigue el plazo definido por la jurisdicción, tal como establece 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 eventos 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 archivar documentos 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 la 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 de notificación y a la utilidad de la información recopilada.

Siete dimensiones configuran un sistema eficaz: el objetivo de política al que sirven los informes, quién puede presentarlos y recibirlos, qué tipos de incidentes están incluidos, cómo se asignan los niveles de riesgo, qué medidas de cumplimiento se derivan de un informe, si se permite el anonimato y qué ocurre tras presentar un informe.

Una matriz RACI clara ayuda a llevarlo a la práctica. Un único equipo, normalmente el de riesgos o cumplimiento, debe responsabilizarse de la recepción, con producto e ingeniería como partes consultadas. La investigación suele estar dirigida por el equipo responsable del sistema afectado, mientras que riesgos asume la responsabilidad última de la revisión. Las decisiones de comunicació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 de los informantes antes de que un incidente obligue a abordar la cuestión.
• Separe a la persona que notifica de la persona que decide sobre las consecuencias.
• Integre la 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 generará menos informes, no sistemas más seguros. Dé prioridad a la seguridad psicológica en su diseño.

Las restricciones jurídicas y de privacidad requieren planificación antes de la puesta en marcha, no después del primer caso complicado. Las evidencias que incluyen datos de clientes están sujetas a sus propias reglas 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 compararse con el panorama general. El rastreador de incidentes de IA, mantenido por el AI Risk Lab del MIT, clasifica los incidentes por categorías de daños y añade etiquetas generadas por modelos de lenguaje de gran tamaño a la base de datos pública de incidentes de IA, lo que ofrece a los investigadores una visión de los fallos en condiciones reales en la que pueden realizar búsquedas.

El propio rastreador reconoce sus limitaciones: señala la variabilidad de la calidad de los informes y el sesgo de muestreo en los conjuntos de datos voluntarios, ya que los incidentes notificados no son una muestra aleatoria de los incidentes que se producen. 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 contenedor AICIE de ETSI existen precisamente para que los informes de distintas organizaciones sean comparables e intercambiables, lo que convierte informes aislados en un recurso público utilizable, en lugar de en una acumulación de texto no estructurado.

• La divulgación pública crea una base de evidencias compartida, pero puede exponer detalles operativos sensibles.
• El registro exclusivamente interno protege la confidencialidad, pero pasa por alto patrones que solo son visibles 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, independientes de los incidentes que registra. Los indicadores clave operativos son el tiempo hasta la detección, el tiempo hasta la clasificación inicial y el tiempo hasta la notificación, medidos con respecto a los umbrales internos de escalado y a cualquier plazo regulatorio aplicable.

Los indicadores de calidad son igual de importantes: el grado de integridad de los informes respecto al conjunto mínimo de datos, la distribución de la gravedad a lo largo del tiempo y la tasa de incidentes repetidos 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: la reducción de la recurrencia tras una corrección, el número de correcciones efectivamente implantadas a partir de los hallazgos de las investigaciones y la 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 hasta la detección, la clasificación inicial y la notificación, supervisados con respecto a los plazos internos y regulatorios.
• Puntuaciones de integridad 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 independientes sin crear brechas en las que un incidente se detecta, pero nunca llega al proceso de notificación.

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

• Exija que el proveedor notifique dentro de un plazo fijo, ajustado a su nivel de escalado más rápido.
• Exija acceso a la información sobre la causa raíz, no solo al resumen de las medidas correctoras elaborado por el proveedor.
• Realice un simulacro de investigación entre proveedores al menos una vez antes de necesitarlo en un caso real.

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

El trabajo de auditoría revela sistemáticamente un patrón de fallo concreto: agentes conversacionales que gestionan correctamente la interacción hasta el momento en que debe intervenir una persona.

Esa brecha tiene más importancia de la que contemplan la mayoría de los marcos de notificación. Un conjunto mínimo de datos y una taxonomía bien definida solo ayudan una vez que se ha registrado un suceso, y el fallo de escalado es precisamente el punto en el que ese registro falla con mayor frecuencia. La auditoría continua de todo el volumen de conversaciones, en lugar de la 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 trata la notificación de incidentes como un documento de cumplimiento, algo que se elabora para un auditor en lugar de algo que alguien utiliza. Ese enfoque invierte su verdadero valor. El resultado real 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 se limitan a archivarlas. Las organizaciones que tratan la notificación como un mecanismo de resiliencia, y no como un requisito burocrático, terminan teniendo 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 diseñado nuestro enfoque en torno a la brecha 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 permanente en lugar de una comprobación puntual, Lexic Pulse supervisa de forma continua 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.
• Considere un seguimiento permanente para mantener una supervisión continua vinculada a su proceso de notificación.
• Elija plataformas que permitan conservar evidencias de acuerdo con los marcos de la OCDE y de 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 de 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, que después deciden si procede informar a las autoridades. Los marcos de notificación de incidentes como los descritos aquí 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 detecte, y la notificación externa debe respetar el plazo regulatorio aplicable. 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 interrupciones generalizadas y 10 días para los incidentes que impliquen un fallecimiento.

¿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 descritos aquí, incluidos los de la OCDE y del NIST o el EU AI Act, define ese umbral. Los lectores que encuentren este término deben consultar 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 existe 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 software concreto. Las plataformas que admiten campos estructurados, archivos adjuntos de evidencias y formatos alineados con la OCDE o ETSI, como Lexic Compass para la captura de evidencias mediante auditorías, tienden a producir registros más útiles que las herramientas de gestión de incidencias de uso general.

¿Cómo se documenta el sesgo en un informe 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 investigarlos.

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 eventos adversos de IA: desarrollo de la infraestructura de información que necesita la Administración para aprender y actuar (Stanford HAI / RegLab)
• Rastreador 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)