Incidentes graves de IA: cómo preservar evidencia, contener el daño y decidir si un fallo debe notificarse bajo el artículo 73 del AI Act

Un fallo no es automáticamente un incidente grave

La respuesta a un resultado peligroso de un sistema de IA empieza por separar conceptos que a menudo se mezclan. Un error de modelo puede ser una salida inexacta, incoherente o no deseada. Una incidencia operativa puede incluir una caída de servicio, una configuración incorrecta, una integración fallida o un uso de herramientas fuera del comportamiento previsto. Un daño es una consecuencia negativa concreta para una persona, una organización, bienes, el medio ambiente o un proceso. Un incidente grave, en el sentido regulatorio aplicable a esta guía, es una categoría más estrecha y vinculada a efectos específicos definidos por el AI Act.

No toda alucinación, reducción de calidad, reclamación de usuario o respuesta ofensiva activa por sí sola el régimen del artículo 73. Tampoco sería prudente descartar un caso porque la salida aislada parezca menor: una respuesta aparentemente ordinaria puede haber influido en una decisión clínica, de contratación, de acceso a un servicio, de seguridad física o de operación de infraestructura. El análisis debe partir de hechos observables, no de etiquetas internas como “bug menor” o “queja no crítica”.

El texto consolidado del AI Act define el incidente grave mediante categorías de resultado, entre ellas fallecimiento o daño grave a la salud, perturbación grave y sostenida de la gestión u operación de infraestructura crítica, infracción de obligaciones destinadas a proteger derechos fundamentales y daño grave a bienes o al medio ambiente. La clasificación exige examinar el hecho, el sistema afectado y el posible vínculo entre ambos. No debe sustituirse por una puntuación de severidad interna sin correspondencia documentada con esas categorías.

Conviene mantener dos carriles desde el primer aviso. El carril técnico busca detener un comportamiento no seguro y restaurar un servicio controlado. El carril de evidencia y cumplimiento busca conservar los hechos, evaluar el posible nexo causal, coordinar a proveedor y desplegador y determinar si procede preparar una comunicación a la autoridad competente. Pueden avanzar en paralelo, pero una corrección precipitada puede dificultar el segundo carril si modifica o elimina la información necesaria para explicar qué ocurrió.

Alcance: identificar el sistema, el operador y la vía de alto riesgo

El artículo 73 se dirige a proveedores de sistemas de IA de alto riesgo que se hayan introducido en el mercado de la Unión. Por tanto, el primer dato que debe verificarse no es la gravedad percibida por el equipo, sino qué sistema exacto intervino, quién es su proveedor a efectos del Reglamento y si estaba sujeto a la clasificación de alto riesgo pertinente. El AI Act contempla dos vías principales de clasificación en su artículo 6: determinados sistemas relacionados con productos o componentes de seguridad regulados y los casos de uso enumerados en el anexo III, con las condiciones y excepciones previstas en el propio Reglamento.

No es suficiente afirmar que un modelo fundacional, una interfaz conversacional o una automatización “es de alto riesgo” por su tema. La unidad de análisis debe ser el sistema puesto a disposición o usado en el contexto concreto: versión, finalidad prevista, integración, funciones habilitadas, usuarios, datos de entrada y resultado que produjo. Un mismo componente puede formar parte de configuraciones con obligaciones distintas. El proyecto de directrices de la Comisión sobre clasificación puede ayudar a estructurar la revisión, pero sigue siendo un borrador y no sustituye al texto vinculante ni a la valoración jurídica del caso.

La planificación temporal debe distinguir entre preparación y aplicabilidad efectiva. Las organizaciones pueden construir desde ahora sus procesos de registro, preservación, contacto y escalado. Sin embargo, las fechas de aplicación concretas para distintas categorías de alto riesgo deben comprobarse contra la versión jurídicamente aplicable del Reglamento y cualquier modificación vigente al decidir un caso. No es recomendable convertir una fecha de planificación interna en una conclusión sobre una obligación ya exigible.

Para navegar el trabajo relacionado, el equipo puede separar este protocolo de las revisiones generales de Seguridad, de la evaluación de alternativas en Comparar y de la identificación de capacidades en Descubrir. Esas actividades pueden aportar contexto, pero la investigación de un incidente requiere un expediente centrado en el hecho ocurrido y en la configuración efectivamente desplegada.

Las primeras horas: preservar antes de corregir

Cuando se detecte un caso potencialmente relevante, nombre un responsable del incidente con capacidad para coordinar operaciones, producto, seguridad, calidad y cumplimiento. Su primera obligación operativa es fijar una línea temporal: cuándo ocurrió el hecho, cuándo fue detectado, quién recibió cada aviso, qué sistemas siguieron activos y qué decisiones se tomaron. La hora de conocimiento del proveedor y, cuando corresponda, la del desplegador deben registrarse separadamente, junto con la fuente que las acredita.

Preservar evidencia no significa copiar indiscriminadamente todos los datos disponibles. Significa conservar de forma proporcionada, íntegra y con acceso controlado los elementos que permitan reconstruir el comportamiento investigado. Como mínimo, el expediente debería vincular identificadores de solicitud y sesión, entradas y salidas, versión y parámetros del modelo, prompt de sistema y plantillas, políticas, configuración de recuperación, documentos recuperados o sus identificadores, llamadas y respuestas de herramientas, autorizaciones humanas, identidad o rol del operador y cambios de configuración cercanos al evento.

La preservación debe incluir metadatos de integridad: origen, fecha de extracción, responsable, método de exportación, huella de archivo cuando sea viable, controles de acceso y toda transformación posterior. Si existen datos personales, secretos empresariales o información de seguridad, el acceso debe limitarse según las reglas aplicables. Restringir el acceso no justifica borrar los elementos necesarios para investigar. Cuando no pueda conservarse un dato, el expediente debe explicar qué se eliminó, por qué, cuándo y qué alternativa probatoria queda.

El AI Act exige que el proveedor investigue de inmediato el incidente grave y el sistema relacionado, incluida una evaluación de riesgos y medidas correctoras. También establece que el sistema no debe alterarse antes de informar cuando la alteración pueda afectar a la evaluación posterior de las causas del incidente. En la práctica, esto obliga a diseñar la contención de modo que limite el daño sin borrar el estado que debe examinarse.

Contener el daño sin inutilizar la investigación

La contención no tiene una única forma correcta. Suspender todo el sistema puede ser necesario si persiste un riesgo grave, pero también puede afectar a procesos esenciales o llevar a los usuarios a soluciones no controladas. Otras medidas pueden ser más proporcionales: retirar temporalmente una herramienta de ejecución, reducir permisos, impedir acciones automatizadas de alto impacto, bloquear un conjunto identificado de entradas, desactivar una fuente de recuperación comprometida o exigir una comprobación humana para una decisión específica.

Cada medida debe responder a una hipótesis explícita de daño y tener condiciones de revisión. “Poner el sistema en modo seguro” no es una descripción verificable si no se define qué capacidad se bloqueó, qué continuó disponible, qué población resultó afectada, qué alternativas se ofrecieron y cómo se comprobó el efecto. La comunicación a clientes, usuarios y operadores puede ser parte de la contención, pero debe basarse en hechos confirmados y no atribuir causalidad antes de que la investigación la sostenga.

La reversión a una versión anterior requiere cautela. Puede resolver el síntoma inmediato, pero no prueba que la causa estuviera en la versión retirada y puede introducir diferencias que impidan reproducir el caso. Antes de cambiar, preserve el artefacto desplegado, la configuración y los registros que permitan comparar el estado anterior con el posterior. Si el cambio es inevitable para evitar daño, documente la necesidad y el alcance de la desviación.

La autoridad de vigilancia del mercado puede disponer de facultades propias frente a productos que presenten un riesgo grave, incluidas medidas de evaluación y restricciones. Estas actuaciones no sustituyen la investigación interna ni convierten a la organización en autoridad. El equipo debe estar preparado para aportar hechos verificables, evaluaciones y medidas aplicadas si recibe un requerimiento.

Reconstruir el caso como una cadena de decisiones

Una investigación útil debe poder responder a una pregunta sencilla: ¿qué sistema exacto produjo o contribuyó al resultado y mediante qué secuencia? Para ello no basta la transcripción de una conversación. Un expediente reproducible conecta el identificador del caso con el modelo y su versión, los parámetros de inferencia, las instrucciones de sistema, el prompt ensamblado, los datos adjuntos, la configuración de recuperación, los documentos seleccionados, las herramientas disponibles, las llamadas realizadas, las políticas activas y las decisiones humanas.

También deben separarse los hechos del mecanismo supuesto. Hecho: una herramienta recibió determinados parámetros y se produjo una acción registrada. Hipótesis: el modelo interpretó mal una instrucción ambigua. Hecho: un operador aprobó una recomendación. Hipótesis: la interfaz no mostraba suficiente contexto para detectar el error. Esta separación evita que el primer diagnóstico se convierta en relato definitivo y permite revisar hipótesis alternativas, incluidas fallas de datos, integración, interfaz, formación, procesos humanos o factores externos.

La reproducibilidad completa no siempre será posible. Puede que el servicio externo haya cambiado, que falte una entrada, que un resultado dependa de aleatoriedad o que la conservación de datos esté limitada. En esos casos, el expediente debe describir con precisión la laguna, su impacto sobre las conclusiones y los ensayos sustitutos empleados. La ausencia de reproducción no demuestra por sí sola que el sistema no estuviera relacionado con el incidente.

La reconstrucción debe incluir los cambios introducidos durante la respuesta. Sin ese registro, una mejora posterior podría confundirse con la configuración original, y un resultado seguro obtenido después de la contención podría presentarse erróneamente como evidencia de que el incidente no era posible. Mantener comparabilidad entre estado inicial, estado contenido y estado corregido es una condición práctica para aprender del caso.

Clasificar gravedad y nexo causal sin adelantar el veredicto

La clasificación debe partir de preguntas concretas. ¿Hubo fallecimiento o daño grave a la salud? ¿La operación o gestión de infraestructura crítica sufrió una perturbación grave y sostenida? ¿Se produjo una infracción de obligaciones orientadas a proteger derechos fundamentales? ¿Hubo daño grave a bienes o al medio ambiente? Para cada pregunta, el expediente debe identificar el hecho alegado, las fuentes que lo respaldan, la extensión conocida, las personas o activos afectados y los elementos aún inciertos.

Después debe analizarse el vínculo con el sistema. El artículo 73 no exige que la organización espere a una prueba causal definitiva si existe una probabilidad razonable de relación, pero tampoco permite usar una mera coincidencia temporal como sustituto de análisis. Deben documentarse las rutas causales plausibles, las pruebas que las apoyan, los factores alternativos y las pruebas pendientes. Por ejemplo, una salida errónea puede ser relevante, pero la decisión final pudo depender de una revisión humana independiente o de datos externos incorrectos; ambos elementos deben investigarse.

Una matriz interna de severidad puede facilitar el escalado, pero no debe reemplazar la definición legal. Es recomendable que el formulario interno contenga campos separados para “impacto observado”, “riesgo de impacto adicional”, “categoría regulatoria potencial”, “nexo confirmado”, “nexo razonablemente probable” y “nexo no establecido”. Esta estructura deja visible qué parte es un hecho y cuál es un análisis provisional.

La decisión de que un caso no cumple el umbral debe quedar motivada y ser revisable. Puede aparecer información nueva procedente de un desplegador, un usuario, una herramienta conectada o una autoridad. Cerrar la notificación no equivale a cerrar el expediente técnico ni a eliminar la evidencia.

Proveedor y desplegador: coordinar información, no transferir el problema

Proveedor y desplegador pueden disponer de partes distintas de la evidencia. El proveedor suele controlar la documentación del sistema, versiones, pruebas, registros de operación y medidas correctoras del producto. El desplegador puede conocer el contexto de uso, la población afectada, las decisiones humanas, los datos locales, las consecuencias materiales y las comunicaciones recibidas. Un contrato puede distribuir tareas operativas, pero no debería impedir la entrega rápida de información necesaria para cumplir obligaciones aplicables.

Conviene preparar una matriz de contacto y una cláusula operativa de incidente antes de que ocurra un caso. Debe incluir interlocutores disponibles fuera de horario, categorías mínimas de información, canales seguros, plazos internos más breves que los máximos regulatorios, reglas de preservación, procedimiento de aprobación de comunicaciones y tratamiento de datos protegidos. El objetivo no es trasladar automáticamente la responsabilidad, sino reducir el tiempo entre el conocimiento de un hecho y la obtención de los elementos para evaluarlo.

El desplegador debe conservar y facilitar los datos que estén bajo su control y resulten necesarios, dentro de los límites legales aplicables. El proveedor no debería exigir una reproducción perfecta como condición para iniciar la evaluación. A la inversa, el desplegador no debería aplicar cambios locales, borrar registros o comunicar una causa técnica como confirmada sin coordinar el expediente. Cuando varias entidades intervienen, un registro compartido de solicitudes de evidencia ayuda a distinguir lo entregado, lo pendiente y lo que no puede obtenerse.

Las obligaciones de transparencia, registro y cooperación asociadas a los sistemas de alto riesgo pueden ser relevantes para que esta coordinación funcione, pero no convierten automáticamente al desplegador en responsable de la notificación prevista para el proveedor en el artículo 73. La asignación final depende del papel efectivo de cada entidad y de las circunstancias del sistema investigado.

Notificación: gestionar los relojes sin convertirlos en una fórmula automática

El artículo 73 establece una obligación de comunicar incidentes graves a las autoridades de vigilancia del mercado de los Estados miembros en los que haya ocurrido el incidente, en las condiciones previstas por el Reglamento. La comunicación está conectada tanto al conocimiento del incidente como a la determinación de un nexo causal o de su probabilidad razonable. Por ello, el equipo debe registrar por separado el momento de conocimiento, el momento en que se adoptó una conclusión provisional sobre el vínculo y la evidencia que sustentó ambos hitos.

El Reglamento contempla plazos máximos de dos, diez y quince días para supuestos diferentes, así como la posibilidad de un informe inicial incompleto seguido de información adicional. La asignación exacta de cada plazo depende de la categoría concreta del incidente y de la redacción aplicable al supuesto. No debe deducirse de una tabla interna abreviada ni de la mera severidad técnica. El protocolo debe activar revisión jurídica inmediata, calcular el plazo desde un hito documentado y registrar por qué se ha escogido ese reloj.

Un informe inicial no debe rellenarse con certeza artificial. Si no se conoce la causa, debe indicarse que está bajo investigación, describir los hechos confirmados, el alcance conocido, las medidas de contención, la evidencia disponible y el plan para completar la información. La posibilidad de aportar un informe incompleto no justifica demorar una comunicación requerida ni omitir una investigación diligente.

La plantilla y la orientación publicadas por la Comisión sobre incidentes graves son materiales de consulta útiles para organizar campos y secuencias, pero se presentan como borradores sometidos a consulta. No deben tratarse como guía final vinculante. Para un caso real, el equipo debe contrastar el contenido de la comunicación con el Reglamento aplicable y la instrucción de la autoridad competente.

Investigación, corrección y reanudación controlada

La investigación no termina al enviar una comunicación. Debe explicar la causa o las causas contribuyentes con un nivel de confianza proporcionado: comportamiento del modelo, datos de entrada, recuperación, herramienta, interfaz, permisos, configuración, supervisión humana, formación, proceso operativo o una combinación. Una causa raíz única puede ser una simplificación engañosa cuando el incidente depende de varios controles que fallaron o no existían.

La acción correctora debe vincularse a la ruta de daño identificada. Ajustar un prompt puede ser insuficiente si el problema era un permiso excesivo de una herramienta; añadir una revisión humana puede ser insuficiente si el revisor no recibe los datos necesarios; eliminar un documento puede ser insuficiente si el conector sigue incorporando fuentes no autorizadas. Para cada medida, defina qué riesgo reduce, qué riesgo residual deja, qué efectos secundarios podría introducir y cómo se validará.

La validación debe incorporar el caso incidente y una regresión más amplia. Probar solo la conversación original puede favorecer una corrección demasiado ajustada. Es preferible combinar pruebas representativas, casos límite, pruebas de permisos y flujos completos hasta la acción externa, además de revisar el efecto sobre usuarios y grupos afectados cuando corresponda. Conserve los resultados, el entorno de prueba, las versiones y los criterios de aceptación.

La reanudación no debe ser una decisión implícita tomada al cerrar un ticket. Debe tener un responsable, criterios de autorización, alcance inicial, métricas de vigilancia reforzada, mecanismo de reversión y condiciones que obliguen a volver a suspender. Si permanece una incertidumbre material, la organización puede optar por mantener limitada la capacidad afectada mientras completa la investigación. Esa decisión y su fundamento deben constar en el expediente.

Preparación trimestral: comprobar que el protocolo funciona antes del incidente

La capacidad de responder no se demuestra porque existan registros técnicos o una política escrita. Debe probarse que el equipo puede recuperar un caso realista sin depender de una sola persona ni de herramientas que no retienen los datos necesarios. Un ejercicio trimestral puede seleccionar un flujo de riesgo, simular una alerta y medir cuánto tarda la organización en identificar la versión desplegada, aislar la capacidad afectada, obtener registros del desplegador y producir una línea temporal con fuentes verificables.

La revisión debe incluir cambios de proveedores, modelos, herramientas, corpus, permisos, responsables y mercados de despliegue. Un protocolo preparado para un modelo estático puede fallar cuando hay enrutamiento entre modelos, despliegues graduales, recuperación dinámica o herramientas de terceros. También conviene comprobar si los acuerdos con clientes y proveedores permiten compartir con rapidez la evidencia necesaria, con controles adecuados de confidencialidad y protección de datos.

El resultado de cada ejercicio debe generar mejoras observables: campos faltantes en los registros, decisiones sin responsable, imposibilidad de recuperar configuraciones, falta de un canal de emergencia o criterios ambiguos de suspensión. No se trata de declarar conformidad general con el AI Act, sino de reducir incertidumbre en una respuesta concreta a un incidente. La preparación más útil es la que permite decir qué se sabe, qué no se sabe y qué se hizo para evitar que el daño continúe.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.