Registro de riesgos de IA: cómo crearlo y mantenerlo con arreglo al artículo 9
El artículo 9 de la Ley de IA de la UE exige un registro de riesgos vivo. Campos recomendados, cadencia de actualización y un ejemplo práctico para proveedores y responsables del despliegue. Dic. 2027.
El artículo 9 de la Ley de IA de la UE (Reglamento (UE) 2024/1689) exige a todo proveedor de un sistema de IA de alto riesgo que ponga en marcha un sistema continuo de gestión de riesgos a lo largo del ciclo de vida del sistema — y que lo documente. El registro de riesgos es la forma operativa que adopta esa documentación: un registro estructurado y vivo de cada riesgo identificado, su ciclo de vida y lo que usted está haciendo al respecto.
El Reglamento no utiliza la expresión «registro de riesgos». Lo que el artículo 9 exige es un sistema de gestión de riesgos con fases definidas — identificación, estimación, evaluación, mitigación y vigilancia poscomercialización. El registro es la manera de ejecutar y acreditar esas fases. Los reguladores y los organismos notificados que revisen su expediente técnico del artículo 11 lo buscarán de inmediato.
Qué exige realmente el artículo 9
El artículo 9 establece cuatro obligaciones que el registro operacionaliza:
- Identificar y analizar los riesgos conocidos y razonablemente previsibles — tanto del uso previsto como del uso indebido previsible.
- Estimar y evaluar los riesgos que puedan surgir del uso en condiciones realistas, incluidos los derivados de las interacciones con otros sistemas o entre poblaciones de usuarios diversas.
- Adoptar medidas de mitigación adecuadas, documentarlas y asignar la titularidad.
- Probar la eficacia de esas medidas antes de introducir el sistema en el mercado, y continuar probándolas tras el despliegue.
El registro es el único artefacto que enlaza estas cuatro fases. Una entrada que solo recoge la evaluación inicial, pero ningún estado de mitigación ni fecha de revisión, no puede satisfacer el requisito de seguimiento continuo del artículo 9. La palabra «continuo» importa — el artículo 9, apartado 3, exige explícitamente que el sistema de gestión de riesgos se actualice a la luz de los datos de vigilancia poscomercialización recopilados con arreglo al artículo 72.
El registro en la arquitectura de cumplimiento más amplia
El registro de riesgos no se sostiene por sí solo. Se conecta con otras tres obligaciones:
Documentación técnica del artículo 11 / Anexo IV. Su expediente técnico debe incluir una descripción del sistema de gestión de riesgos y sus resultados. El registro es esa descripción. Un auditor o un organismo notificado que revise el paquete del artículo 11 comprobará si los riesgos identificados en el diseño se reflejan en el registro, y si el registro muestra pruebas de actualizaciones continuas.
Vigilancia poscomercialización del artículo 72. Los proveedores deben operar un sistema de vigilancia poscomercialización y retroalimentar sus datos al sistema de gestión de riesgos. En la práctica, esto significa crear un bucle de retroalimentación: los datos de vigilancia generan nuevas entradas en el registro o revisan las puntuaciones de riesgo existentes. Un registro que no se ha tocado desde el día de la introducción en el mercado es prueba de incumplimiento del artículo 72.
Seguimiento del responsable del despliegue del artículo 26. Los responsables del despliegue de sistemas de IA de alto riesgo tienen sus propios deberes de seguimiento y deben informar a los proveedores de los riesgos e incidentes detectados durante el uso. Cuando un responsable del despliegue también deba aplicar partes del sistema de gestión de riesgos — lo que puede ocurrir cuando el proveedor lo incorpora expresamente a las instrucciones de uso —, el responsable del despliegue debe mantener una sección de registro paralela que cubra los riesgos del contexto de despliegue. Los responsables del despliegue de sistemas de IA de calificación crediticia o de servicios públicos también deben evaluar las implicaciones para los derechos fundamentales con arreglo al artículo 27.
Campos recomendados para cada entrada del registro
El Reglamento especifica qué debe captar el sistema de gestión de riesgos, pero no dicta los encabezados de columna. Los siguientes campos satisfacen los artículos 9, 11 y 72 y dan a un auditor todo lo necesario para verificar el registro:
| Campo | Finalidad |
|---|---|
| ID de riesgo | Referencia única (p. ej., RSK-004) para la trazabilidad entre documentos y registros de auditoría |
| Sistema de IA | A qué sistema registrado se refiere esta entrada |
| Descripción del riesgo | Enunciado específico del perjuicio potencial, el mecanismo y las personas afectadas |
| Categoría | Sesgo / robustez / seguridad / privacidad / transparencia / deriva — o una combinación |
| Personas / grupos afectados | Quién podría sufrir el perjuicio (p. ej., candidatos a un empleo mayores de 50 años, pacientes, clientes de tramos de renta más bajos) |
| Probabilidad | Escala de 1 a 5, con umbrales definidos; ancle a pruebas, no a la intuición |
| Gravedad | Independiente de la probabilidad; magnitud si el riesgo se materializa |
| Nivel de riesgo inherente | Probabilidad × gravedad antes de cualquier control |
| Mitigaciones + titular | Acciones específicas y mensurables; persona o equipo responsable nombrado |
| Nivel de riesgo residual | Probabilidad × gravedad tras los controles; si sigue siendo inaceptable, escalar |
| Decisión de aceptabilidad + visto bueno | Decisión explícita de que el riesgo residual es aceptable (o no), con visto bueno nombrado |
| Artículo / control vinculado | p. ej., art. 9, apdo. 2, letra a); art. 10, apdo. 3; art. 14, apdo. 4; art. 15, apdo. 1 |
| Fecha de revisión | Próxima revisión programada; obligatoria cuando lleguen datos de vigilancia |
| Estado | Abierto / En curso / Mitigado / Aceptado / Cerrado |
Dos campos que los equipos de cumplimiento nuevos omiten habitualmente: la decisión de aceptabilidad (aceptar un riesgo residual sin documentar el fundamento no es una estrategia de cumplimiento válida) y el artículo/control vinculado (sin él, el registro no puede leerse frente a los requisitos legales que pretende satisfacer).
Categorías de riesgo que conviene cartografiar explícitamente
El artículo 9 exige que los riesgos se analicen tanto en el uso conforme a lo previsto como en el uso indebido razonablemente previsible. En la práctica, cinco categorías cubren el terreno para la mayoría de los sistemas de alto riesgo:
Sesgo y discriminación. La categoría más litigada. Un modelo de cribado para selección de personal entrenado con datos históricos de contratación reflejará los patrones históricos. La entrada del registro debe nombrar al grupo demográfico afectado, cuantificar la disparidad cuando sea posible y especificar la prueba que verificará que la mitigación funcionó.
Robustez y deriva del rendimiento. Los modelos se degradan cuando la distribución de los datos del mundo real se desplaza respecto de la distribución de entrenamiento. Un modelo de calificación crediticia entrenado con datos económicos anteriores a 2022 se comporta de forma distinta en un entorno de tipos de interés altos. El artículo 15 exige que la exactitud, la robustez y la ciberseguridad se mantengan a lo largo del ciclo de vida — el registro vincula los umbrales de seguimiento del rendimiento a esa obligación.
Seguridad y entradas adversariales. El artículo 15 también cubre la ciberseguridad. Los sistemas de IA pueden ser vulnerables al envenenamiento de datos (en el momento del entrenamiento) o a los ejemplos adversariales (en el momento de la inferencia). Registre los vectores de ataque conocidos, los controles y la exposición residual.
Privacidad. Cuando el sistema trate datos personales, registre los riesgos de privacidad junto al análisis de riesgos del RGPD. Los dos marcos son complementarios — una EIPD (artículo 35 del RGPD) no sustituye al registro de riesgos del artículo 9, pero las conclusiones deben remitirse mutuamente.
Transparencia y explicabilidad. El artículo 13 exige que los proveedores faciliten a los responsables del despliegue información suficiente sobre el funcionamiento del sistema. Si el modelo no es interpretable, eso crea un riesgo: los responsables del despliegue no pueden cumplir los requisitos de supervisión humana del artículo 14 si no pueden comprender qué está haciendo el sistema. Regístrelo y especifique la mitigación (p. ej., explicación de los resultados, puntuación de confianza, capacidad de anulación).
Cómo crear el registro: una secuencia práctica
Empiece antes de que termine el desarrollo. Los riesgos que puede identificar durante el diseño — en el momento en que aún tiene el control sobre la arquitectura y los datos de entrenamiento — son los más baratos de mitigar. Un registro abierto únicamente en las pruebas previas al despliegue pasará por alto las decisiones de la fase de diseño.
Titularidad interfuncional desde el principio. La identificación de riesgos exige la aportación de los científicos de datos (que conocen los datos de entrenamiento), los gestores de producto (que conocen los casos de uso y las poblaciones de usuarios), el área jurídica/de cumplimiento (que asigna las obligaciones) y, para las herramientas orientadas al responsable del despliegue, el equipo de ventas o de implementación (que ha visto cómo utilizan realmente el sistema los clientes). Un registro mantenido por cumplimiento de forma aislada es un documento de cumplimiento. Un registro del que es titular todo el equipo es un documento operativo.
Ancle las estimaciones de probabilidad a pruebas. «Alta probabilidad» carece de sentido sin una definición. Defina su escala antes de empezar a poblarla: probabilidad 4 significa «ha ocurrido en sistemas similares o en sus propias pruebas; frecuencia > una vez por cada 1000 transacciones». De lo contrario, el registro se convierte en una colección de conjeturas subjetivas que no resistirá el escrutinio.
Fije una cadencia de revisión y respétela. El artículo 9 es continuo; una revisión trimestral es un mínimo razonable para la mayoría de los sistemas de alto riesgo, con revisiones desencadenadas siempre que los datos de vigilancia revelen un nuevo patrón, se produzca un incidente o se realice una modificación sustancial con arreglo al artículo 3, punto 23. Una modificación lo bastante sustancial como para volver a activar la evaluación de la conformidad del artículo 43 debe generar una reevaluación completa del registro.
Distinga la aceptación de la evitación. Algunos riesgos residuales serán aceptables; otros no. Documente ambos. Si el riesgo se acepta, nombre a la persona que adoptó esa decisión y el fundamento. Si no es aceptable y no puede reducirse más, eso es una señal de aprobación/no aprobación para la introducción en el mercado.
Ejemplo práctico: una empresa de tecnología de RR. HH. de 40 personas
Supongamos que una empresa construye una herramienta de cribado de currículos clasificada como de alto riesgo con arreglo al Anexo III, punto 4, letra a) (selección de personal — elección de personas para un empleo). Su registro se abre con la siguiente entrada:
RSK-001 | Cribador de CV v2 | Impacto dispar por edad
- Descripción del riesgo: el modelo asigna puntuaciones de relevancia más bajas a los CV de candidatos mayores de 55 años debido a su infrarrepresentación en los datos de entrenamiento; podría constituir discriminación indirecta con arreglo al artículo 21 de la Carta de la UE.
- Categoría: sesgo
- Personas afectadas: candidatos a un empleo de 55 años o más
- Probabilidad: 4 (confirmada en las pruebas previas al despliegue: tasa de aprobación un 14 % inferior para la cohorte de 55 años o más)
- Gravedad: 4 (denegación de oportunidad de empleo; impacto sobre los derechos fundamentales)
- Riesgo inherente: alto
- Mitigaciones: (1) reentrenar con un conjunto de datos equilibrado por edad antes del 3.er trimestre de 2027; (2) añadir una restricción de equidad por grupo de edad al objetivo del modelo; (3) un revisor humano debe aprobar todos los rechazos antes de notificar a los candidatos — art. 14, apdo. 5
- Titular: responsable de Ingeniería (reentrenamiento); responsable de Cumplimiento (proceso de revisión humana)
- Riesgo residual: medio (el reentrenamiento reduce, pero no elimina; la revisión humana aporta una detección)
- Decisión de aceptabilidad: aceptado a la espera del reentrenamiento del 3.er trimestre; visto bueno del CEO el 28-05-2026
- Artículo vinculado: art. 9, apdo. 2, letra a); art. 14, apdo. 4; art. 26, apdo. 7 [notificación a los representantes de los trabajadores si lo despliega el cliente]
- Fecha de revisión: 15-01-2027 (o antes si los datos de vigilancia lo desencadenan)
- Estado: en curso
Esta entrada es auditable. Un evaluador puede remontar el riesgo hasta las pruebas (pruebas previas al despliegue), avanzar hacia controles específicos y cruzarlo con los artículos pertinentes.
Mantenimiento del registro a lo largo del tiempo
En la introducción en el mercado. Confirme que todos los riesgos de alta gravedad se encuentran en un nivel residual aceptable. Cierre cualquier riesgo previo a la comercialización que se haya mitigado por completo. Fije la primera fecha de revisión poscomercialización.
Ciclo poscomercialización. El artículo 72 exige a los proveedores que recopilen y analicen activamente los datos de los sistemas desplegados. Cuando lleguen datos de vigilancia — informes de incidentes, reclamaciones de usuarios, métricas de exactitud, resultados de auditorías de sesgo —, actualice las entradas del registro afectadas. Si los datos revelan un nuevo riesgo, abra una nueva entrada. Si confirman que una mitigación funciona, consigne esa prueba en el campo de estado.
Incidentes graves. El artículo 73 exige a los proveedores que notifiquen los incidentes graves a la autoridad de vigilancia del mercado del Estado miembro en el que se produjo el incidente — en un plazo de 15 días desde que se tiene conocimiento por primera vez, o 2 días en caso de incidentes generalizados o de infraestructuras críticas, o 10 días cuando haya fallecido una persona (artículo 73, apartados 2 a 4). El incidente también debe generar o actualizar de inmediato una entrada del registro; el registro pasa a formar parte de la traza de pruebas que la autoridad revisará.
Modificaciones sustanciales. Si un cambio en el sistema es sustancial en el sentido del artículo 3, punto 23, trate el sistema modificado como un nuevo ciclo de cumplimiento: reevalúe los riesgos existentes, valore si surgen otros nuevos y actualice el expediente técnico con arreglo al artículo 11. El registro marca con fecha esta reevaluación.
Retirada del sistema del servicio. Cierre todas las entradas con un fundamento de cierre documentado. Conserve el registro completo como parte de la documentación técnica del artículo 11 durante los 10 años posteriores a la retirada del mercado (artículo 18).
Cómo ayuda Confir
Confir mantiene un registro de riesgos para toda la organización vinculado directamente a los controles de cumplimiento y a los artículos a los que se asignan sus entradas. Cuando usted registra y clasifica un sistema de IA — Confir deriva su rol (proveedor o responsable del despliegue con arreglo al art. 16/26) y su nivel de riesgo mediante una lógica determinista y basada en reglas —, el registro se siembra previamente con las categorías de riesgo pertinentes para la clasificación del Anexo III de ese sistema. Los controles se activan frente a artículos concretos (art. 9, 10, 14, 15, 72), y cada actualización se consigna en un registro de auditoría inmutable. El mismo registro alimenta el paquete de documentación técnica del artículo 11 / Anexo IV en el momento de la exportación, de modo que usted no mantiene dos documentos separados que puedan distanciarse.
Preguntas frecuentes
¿Es el registro de riesgos un requisito legal o solo una buena práctica?
El término «registro de riesgos» no aparece en la Ley de IA de la UE, pero el contenido es obligatorio. El artículo 9 exige un sistema de gestión de riesgos documentado y continuo, con riesgos identificados, gravedad estimada, medidas de mitigación y vigilancia poscomercialización. El registro es la forma operativa de ese sistema. Llamarlo de otra manera — bitácora de riesgos, rastreador de riesgos — no cambia la obligación. Para los sistemas de IA de alto riesgo, el resultado de ese sistema es un componente esencial del expediente técnico del artículo 11 que los organismos notificados y las autoridades de vigilancia del mercado inspeccionarán.
¿Necesita un registro de riesgos el responsable del despliegue, o es solo tarea del proveedor?
Los proveedores soportan la obligación principal del artículo 9, pero los responsables del despliegue tienen deberes de seguimiento con arreglo al artículo 26 y deben informar a los proveedores de los riesgos e incidentes detectados durante el uso. Cuando un proveedor ha estructurado las instrucciones de uso para asignar tareas de gestión de riesgos al responsable del despliegue, esas tareas deben documentarse — una bitácora de riesgos del lado del responsable del despliegue es la forma natural. Además, los responsables del despliegue de determinados sectores (solvencia, servicios públicos) deben realizar una evaluación de impacto relativa a los derechos fundamentales con arreglo al artículo 27, que documenta los riesgos desde la perspectiva del responsable del despliegue. Los dos registros — el registro del proveedor y la EIDF del responsable del despliegue — son complementarios.
¿Qué categorías de riesgo debe cubrir todo registro de IA de alto riesgo?
Como mínimo: sesgo y discriminación (el artículo 9, apartado 2, letra a), menciona explícitamente los derechos fundamentales); degradación de la robustez y la exactitud (artículo 15); seguridad y entradas adversariales (artículo 15); privacidad (en particular cuando se traten datos personales con arreglo al RGPD); y fallos de transparencia que socaven la supervisión humana (artículo 14). Un sistema que trate categorías sensibles de datos personales con arreglo al artículo 9 del RGPD debe tener entradas de privacidad específicas que remitan a la EIPD.
¿Con qué frecuencia debe actualizarse el registro?
El artículo 9 dice «de manera continua», lo que en la práctica significa por eventos más programado. Actualizaciones desencadenadas: siempre que los datos de vigilancia poscomercialización revelen un nuevo patrón, siempre que se produzca un incidente, siempre que se realice una modificación sustancial (artículo 3, punto 23) y siempre que cambie el uso previsto. Programadas: la mayoría de las organizaciones realizan revisiones trimestrales o semestrales. El campo de fecha de revisión de cada entrada hace esto exigible — si la fecha pasa sin una actualización, eso es una laguna de cumplimiento.
¿Puede una hoja de cálculo satisfacer el artículo 9, o importa el software?
Una hoja de cálculo puede satisfacer el requisito legal si está sujeta a control de versiones, se respalda y almacena un historial de ediciones completo. El riesgo es práctico: una hoja de cálculo sin traza de auditoría no puede demostrar que un riesgo se identificó en una fecha determinada y no se antedató. Para los sistemas sujetos a escrutinio regulatorio, los registros con marca de tiempo e inmutables son materialmente más seguros. Las consideraciones de residencia de datos de la UE se aplican al lugar donde se almacene el registro — confirme su ubicación de alojamiento.
¿Cómo se relaciona el registro de riesgos con el expediente técnico del artículo 11?
El expediente técnico exigido por el artículo 11 y el Anexo IV debe incluir «una descripción del sistema de gestión de riesgos y sus resultados». El registro es esa descripción. En la práctica, esto significa que el registro (o una exportación con formato de él) se presenta como una sección del paquete de documentación del Anexo IV. Un registro desactualizado o incompleto hará que el expediente técnico no supere la revisión. Mantener el registro y el expediente técnico sincronizados — en lugar de mantenerlos por separado — evita el fallo de auditoría más habitual.
¿Qué ocurre si un riesgo se materializa después de la introducción en el mercado?
Añada una nueva entrada de inmediato con la fecha de descubrimiento, la evaluación inicial de gravedad y la mitigación provisional. Si el incidente cumple la definición del artículo 3, punto 49, pueden activarse las obligaciones de notificación del artículo 73 — notifique a la autoridad de vigilancia del mercado pertinente dentro del plazo aplicable (15, 10 o 2 días según la gravedad). Actualice el expediente técnico del artículo 11 para reflejar el nuevo riesgo y cualquier cambio en el sistema realizado en respuesta. Documéntelo todo con marcas de tiempo; los reguladores que evalúen un expediente técnico posterior a un incidente examinarán si el riesgo era previsible, cuándo se identificó por primera vez y con qué rapidez respondió usted.
Guías relacionadas
- Requisitos de gestión de riesgos del artículo 9
- comparar herramientas de gestión de riesgos
- panorama general de la Ley de IA de la UE
- software de inventario de sistemas de IA
- guía de los niveles de clasificación de riesgo
- Clasificación de alto riesgo del artículo 6
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →