Plantilla de registro de riesgos de IA: estructura de columnas y cumplimiento del artículo 9
Plantilla de registro de riesgos de IA: todas las columnas que necesita su registro del artículo 9: ID de riesgo, categoría, puntuación, controles, riesgo residual, aceptación. Dic. 2027.
Todo proveedor de un sistema de IA de alto riesgo debe operar un sistema de gestión de riesgos con arreglo al artículo 9 del Reglamento (UE) 2024/1689. El registro de riesgos es el artefacto operativo que produce ese sistema: el documento estructurado y con control de versiones en el que se identifica cada riesgo material, se puntúa, se controla y se registra la decisión de que la exposición residual es aceptable.
Esta página se centra en la plantilla en sí: qué columnas debe contener, para qué sirve cada columna y cómo un registro completado alimenta la arquitectura de cumplimiento más amplia. Para una base conceptual sobre la obligación del artículo 9 y el papel del registro en el ciclo de vida del cumplimiento, véase la guía del registro de riesgos de IA. Para entradas elaboradas a partir de escenarios de despliegue realistas —cribado de currículos, deriva crediticia, inyección de instrucciones, lagunas de supervisión—, véanse los ejemplos de registro de riesgos de IA.
Por qué importa el conjunto de columnas
La Ley de IA de la UE especifica qué debe recoger un sistema de gestión de riesgos —riesgos identificados, probabilidad y gravedad estimadas, medidas de mitigación, riesgo residual, vigilancia poscomercialización—, pero no prescribe encabezados de columna. Esa flexibilidad crea una trampa. Los equipos que diseñan su registro de forma improvisada tienden a omitir los dos campos que más importan a un auditor: la decisión de aceptabilidad y el artículo vinculado. Un registro con diecisiete riesgos y sin aprobación sobre si la exposición residual es aceptable no es un documento conforme con el artículo 9; es una lista.
El conjunto de columnas que figura a continuación está diseñado para cerrar esa laguna sin dejar de ser lo bastante compacto como para mantenerlo en la práctica.
Las columnas del registro
Identificación primaria
ID de riesgo — una referencia única y estable, como RSK-009. La estabilidad importa: el ID aparece en el expediente técnico del artículo 11, en los informes de incidentes y en los registros de auditoría. Cuando cierre o sustituya un riesgo, retire el ID en lugar de reutilizarlo.
Sistema de IA — el nombre del sistema más la cadena de versión (por ejemplo, «LoanScorer v3.1.0»). Una entrada del registro se aplica a un sistema en una versión. Una nueva versión con funcionalidad sustancialmente modificada genera una nueva entrada vinculada a su predecesora, no una sobrescritura.
Categoría de riesgo — un vocabulario controlado hace que el registro sea consultable y comparable entre sistemas. Categorías recomendadas: Sesgo / Discriminación; Robustez / Exactitud; Seguridad (incluida la inyección de instrucciones y las entradas adversarias); Datos / Privacidad; Transparencia; Deriva; Fallo de supervisión. Un solo riesgo puede abarcar varias categorías: registre la primaria y la secundaria.
Caracterización del riesgo
Descripción — el campo de texto libre más importante. Redacte una afirmación concreta y específica: el mecanismo, la población afectada y el perjuicio probable. «Sesgo demográfico» no es una descripción. «El modelo asigna sistemáticamente puntuaciones crediticias más bajas a los solicitantes de códigos postales de menores ingresos debido a una correlación indirecta en los datos de entrenamiento, lo que crea una posible discriminación con arreglo al artículo 21 de la Carta de la UE» sí es una descripción. La especificidad es lo que hace defendible el registro bajo escrutinio.
Personas / derechos afectados — nombre a las personas o grupos que podrían sufrir un perjuicio: candidatos a un empleo mayores de 55 años, pacientes de zonas rurales, clientes sin un historial crediticio formal. Cuando el riesgo afecte a derechos fundamentales —no discriminación, privacidad, acceso a servicios—, hágalo explícito. El artículo 9, apartado 2, letra a, exige específicamente el análisis de los riesgos para la salud, la seguridad y los derechos fundamentales.
Artículo de la Ley de IA de la UE afectado — asigne cada riesgo a la obligación que activa. Asignaciones típicas:
- Sesgo / Discriminación → art. 9 (gestión de riesgos), art. 10, apdo. 2 (gobernanza de datos, incluida la detección de sesgos)
- Robustez / Exactitud / Seguridad → art. 15
- Transparencia / Explicabilidad → art. 13 (información a los responsables del despliegue), art. 14 (supervisión humana)
- Fallo de supervisión → art. 14
- Deriva / Poscomercialización → art. 72
- Datos / Privacidad → art. 10, apdo. 3 (datos personales en el entrenamiento), con remisión al artículo 35 del RGPD
Esta columna convierte el registro de un inventario de riesgos en un mapa de cumplimiento. Un auditor puede rastrear del artículo a las pruebas en un solo paso.
Puntuación
Probabilidad — una escala de 1 a 5 con anclajes definidos antes de empezar a puntuar. Ejemplo: 1 = teórica, sin pruebas en sistemas similares; 3 = observada en despliegues comparables o en pruebas previas al despliegue; 5 = observada en los datos de producción de este sistema. Ánclela a las pruebas, no a la intuición. Las puntuaciones sin anclajes definidos no pueden aplicarse de forma coherente entre evaluadores ni ser revisadas por un tercero.
Gravedad — independiente de la probabilidad; mide la magnitud del perjuicio si el riesgo se materializa. 1 = inconveniente menor sin efecto duradero; 3 = perjuicio material, reversible; 5 = perjuicio grave, potencialmente irreversible (denegación de empleo, denegación indebida de servicios esenciales, lesión física). Para los perjuicios a los derechos fundamentales, el suelo suele ser 4.
Puntuación de riesgo inherente — probabilidad × gravedad, antes de cualquier control. Esta puntuación previa a la mitigación es la que se compara con la puntuación residual. Sin ella, no se puede demostrar que los controles reducen realmente el riesgo.
Controles
Mitigación / control — describa la acción específica e implementable: no «mejorar la calidad de los datos», sino «añadir una auditoría de equidad obligatoria que compare las tasas de aprobación entre las cohortes de edad, sexo y nacionalidad con la línea de base de los datos de entrenamiento antes de cada versión del modelo». Cada entrada puede contener varios controles; numérelos para la trazabilidad.
Responsable del control — la persona o el rol nominados como responsables de implementar y mantener el control. La propiedad colectiva produce inacción colectiva. El responsable del control es también la persona encargada de aportar pruebas de la implementación.
Estado del control — Planificado / En curso / Implementado / Verificado. Un control implementado sin pruebas de verificación no satisface el requisito del artículo 9 de que las medidas de mitigación se prueben en cuanto a su eficacia antes de la introducción en el mercado.
Riesgo residual y aceptación
Puntuación de riesgo residual — probabilidad × gravedad tras los controles. Se calcula del mismo modo que el riesgo inherente, utilizando estimaciones posteriores a la mitigación. Documente la lógica: «el reentrenamiento redujo la probabilidad de 4 a 2; la gravedad se mantiene en 4; residual = 8».
Decisión de aceptación y responsable — este es el campo que más a menudo se omite y el más significativo a efectos de auditoría. El artículo 9, apartado 5, exige que los riesgos residuales considerados aceptables se documenten explícitamente. «Aceptable» es una decisión, no una ausencia de objeción. Registre: la decisión (Aceptado / En revisión / Inaceptable — se requiere acción), el nombre y el rol de la persona que la toma, y la fecha. Para los riesgos residuales de alta gravedad, la aprobación debe darse a nivel ejecutivo.
Mantenimiento
Fecha de revisión — la fecha en la que esta entrada debe reevaluarse, con independencia de que se haya producido un evento desencadenante. Fíjela en un máximo de doce meses para la mayoría de las entradas; trimestral para los riesgos residuales de alta gravedad. Cuando se realice una revisión, registre el resultado y restablezca la fecha.
Estado — Abierto / En curso / Mitigado / Aceptado / Cerrado. «Cerrado» significa que el riesgo se ha eliminado por completo o que el sistema se ha desmantelado; «Aceptado» significa que el riesgo residual está documentado como tolerable y se está vigilando.
Ejemplo elaborado — tres entradas
La tabla siguiente muestra el conjunto de columnas cumplimentado para tres tipos distintos de riesgo: un riesgo de sesgo en una herramienta de contratación, un riesgo de seguridad en un asistente interno agéntico y un riesgo de deriva en un modelo de calificación crediticia.
| Campo | RSK-001 | RSK-002 | RSK-003 |
|---|---|---|---|
| ID de riesgo | RSK-001 | RSK-002 | RSK-003 |
| Sistema de IA | CVRanker v2.0 | InternalAgent v1.3 | LoanScorer v3.1 |
| Categoría de riesgo | Sesgo / Discriminación | Seguridad | Deriva / Robustez |
| Descripción | El modelo asigna puntuaciones de pertinencia un 12 % más bajas a los candidatos de 55 años o más debido a indicadores indirectos correlacionados con la edad en los datos de entrenamiento de 2019-2022; riesgo de discriminación indirecta por edad en la preselección | La inyección de instrucciones a través del contenido de correo electrónico controlado por un atacante hace que el agente ejecute llamadas a herramientas no autorizadas (por ejemplo, exfiltrar correo a una dirección externa) | El modelo entrenado con datos de renta de los hogares de 2021-2023 se degrada en las cohortes posteriores a 2024; deniega en exceso a solicitantes solventes; señala de menos el riesgo de impago elevado |
| Personas afectadas | Candidatos a un empleo de 55 años o más; no discriminación del art. 21 de la Carta de la UE | Usuarios cuyos datos puede consultar el agente; sistemas internos | Solicitantes de préstamos al consumo; prestatarios que incurren en impago; grupos protegidos afectados de forma desproporcionada por la denegación excesiva |
| Probabilidad | 4 (confirmada en pruebas previas al despliegue) | 3 (teórica pero demostrada en un ejercicio de red team) | 4 (cambio de distribución confirmado en la vigilancia del 1.er trimestre de 2026) |
| Gravedad | 4 (denegación de una oportunidad de empleo) | 4 (posible exfiltración de datos de los sistemas internos) | 4 (perjuicio financiero material; posible discriminación) |
| Riesgo inherente | 16 — Alto | 12 — Alto | 16 — Alto |
| Artículo de la Ley de IA de la UE | Art. 9, apdo. 2, letra a; art. 10, apdo. 2 | Art. 15, apdo. 1; art. 15, apdo. 5 | Art. 9, apdo. 3; art. 72 |
| Mitigación / control | (1) Reentrenar con un conjunto de datos equilibrado por edad; (2) Añadir una restricción de equidad al objetivo del modelo; (3) Revisión humana obligatoria antes de que cualquier preselección llegue al seleccionador | (1) Capa de saneamiento de la entrada; (2) Puerta de aprobación para las llamadas a herramientas privilegiadas; (3) Registro de auditoría de cada invocación de herramienta con la instrucción de origen | (1) Vigilancia trimestral del AUC; (2) Umbral de exactitud rígido por debajo del cual se suspenden las decisiones automatizadas; (3) Alerta de cambio de distribución con una divergencia del 15 % respecto de la línea de base |
| Responsable del control | Director de Ciencia de Datos (reentrenamiento); responsable de cumplimiento (proceso de revisión) | Ingeniero de seguridad | Responsable de riesgo de modelos |
| Estado del control | Reentrenamiento En curso; proceso de revisión Implementado / Verificado | Los tres Implementados / Verificados | Vigilancia Implementada; sistema de alerta Implementado / Verificado |
| Puntuación de riesgo residual | 8 — Medio (el reentrenamiento reduce la probabilidad a 2; la gravedad se mantiene) | 6 — Medio (los nuevos vectores de inyección no quedan totalmente cubiertos por el saneamiento estático) | 4 — Bajo (la puerta de suspensión limita el perjuicio posterior; la deriva intratrimestral es exposición residual) |
| Decisión de aceptación / responsable | Aceptado a la espera de completar el reentrenamiento en el 3.er trimestre de 2027; aprobación del director general el 2026-06-01 | Aceptado con repetición trimestral de pruebas de red team; aprobación del director de seguridad de la información el 2026-06-01 | Aceptado con umbral de suspensión documentado; aprobación del director de riesgos el 2026-06-01 |
| Fecha de revisión | 2027-01-15 (o en el próximo reentrenamiento) | 2026-09-01 (próximo ejercicio de red team) | 2026-09-30 (próximo ciclo de vigilancia trimestral) |
| Estado | En curso | Aceptado | Aceptado |
El registro tiene control de versiones, no es una instantánea
Un registro creado una sola vez en el momento de la evaluación de la conformidad y nunca actualizado no satisface el artículo 9. El Reglamento exige que el sistema de gestión de riesgos sea continuo. En la práctica, eso significa dos cosas.
En primer lugar, el registro debe versionarse por versión publicada. Cuando se lance una nueva versión del sistema de IA —en particular, cualquier cambio que altere los pesos del modelo, los datos de entrenamiento o el alcance del despliegue—, se crea una nueva versión del registro vinculada a esa versión. La versión anterior se conserva, no se sobrescribe. La documentación técnica del artículo 11 debe reflejar el sistema de gestión de riesgos en la versión introducida en el mercado.
En segundo lugar, los datos de vigilancia poscomercialización del artículo 72 retroalimentan el registro. Los proveedores deben operar un sistema de vigilancia que recopile y analice activamente los datos de los sistemas desplegados y los utilice para actualizar el sistema de gestión de riesgos. Cuando la vigilancia revela un nuevo riesgo, se abre una nueva entrada. Cuando confirma que una mitigación funciona, se actualizan el estado y la puntuación residual. La fecha de revisión de cada entrada lo impone: si la fecha vence sin una acción, eso es una laguna de cumplimiento documentada.
Cómo alimenta el registro las obligaciones derivadas
Expediente técnico del artículo 11. El Anexo IV, sección 2, letra d, exige que la documentación técnica incluya «una descripción del sistema de gestión de riesgos y de sus resultados». El registro es esa descripción. Una exportación formateada del registro —que muestre el conjunto de columnas, todas las entradas actuales, sus puntuaciones de riesgo residual y las decisiones de aceptación— se presenta como una sección del paquete del Anexo IV. Mantenga el registro y el expediente técnico en el mismo sistema para evitar que se desvíen.
Vigilancia poscomercialización del artículo 72. El plan de vigilancia poscomercialización remite a las fechas de revisión y a los umbrales del registro. Cuando llegan los datos de vigilancia, el registro es el instrumento para registrar su efecto en las puntuaciones de riesgo existentes y abrir nuevas entradas. El bucle de retroalimentación no es opcional: es lo que «continuo» significa en el artículo 9, apartado 3.
Notificación de incidentes del artículo 73. Cuando se produce un incidente grave, la entrada pertinente del registro se actualiza de inmediato con la fecha de descubrimiento, la evaluación inicial de la gravedad y el control provisional. Si el incidente cumple la definición de incidente grave del artículo 3, punto 49, se sigue la notificación del artículo 73 a la autoridad de vigilancia del mercado: 15 días desde que se tiene conocimiento en la mayoría de los casos, 10 días cuando una persona ha fallecido, 2 días para los incidentes generalizados o de infraestructuras críticas. La entrada del registro con marca de tiempo forma parte del rastro probatorio que la autoridad revisará.
Cómo ayuda Confir
Confir mantiene el registro como un documento vivo y vinculado. Cuando se clasifica un sistema de IA —utilizando la admisión determinista y basada en reglas de Confir—, las categorías de riesgo pertinentes se activan automáticamente en función del punto del Anexo III. Cada entrada se vincula directamente a los controles y artículos que activa; los mismos datos alimentan tanto el registro interno como la exportación de la documentación técnica del artículo 11 / Anexo IV. Cada actualización se recoge en un registro de auditoría inmutable con marcas de tiempo, de modo que el historial de versiones que exige el Reglamento se mantiene sin esfuerzo manual.
Preguntas frecuentes
¿Cuál es el número mínimo de columnas que debe tener un registro de riesgos conforme?
La Ley de IA de la UE no especifica nombres de columnas. Especifica qué debe documentarse: riesgos identificados, probabilidad y gravedad estimadas en condiciones realistas, medidas de mitigación con eficacia verificada y documentación explícita de que los riesgos residuales son aceptables (artículo 9, apartado 5). Un registro que recoja todos esos elementos —incluso en un formato más sencillo— puede satisfacer el artículo 9. El conjunto de columnas anterior refleja el mínimo necesario para producir un documento auditable y trazable. Los dos campos que más a menudo se omiten y más trascendentales son la decisión de aceptación y la referencia al artículo de la Ley de IA de la UE.
¿Necesita un responsable del despliegue mantener un registro de riesgos con arreglo al artículo 9?
El artículo 9 es una obligación del proveedor. Los responsables del despliegue no están obligados a mantener un registro de riesgos del artículo 9, pero los responsables del despliegue, con arreglo al artículo 26, deben vigilar el sistema de IA en funcionamiento y notificar las anomalías y los incidentes al proveedor. Los responsables del despliegue de sistemas de IA de solvencia o de seguros de vida/salud también deben realizar una evaluación de impacto relativa a los derechos fundamentales (EIDF) con arreglo al artículo 27. Cuando un proveedor haya estructurado las instrucciones de uso para asignar tareas específicas de gestión de riesgos al responsable del despliegue, esas tareas deben documentarse. Un responsable del despliegue que modifica sustancialmente un sistema o estampa en él su propio nombre con arreglo al artículo 25 se convierte en proveedor y hereda íntegramente la obligación del artículo 9.
¿Con qué frecuencia debe revisarse el registro?
El artículo 9 exige que el sistema de gestión de riesgos sea continuo; no hay un intervalo legal fijo. Las revisiones desencadenadas por eventos son obligatorias cuando los datos de vigilancia revelan un nuevo patrón, cuando se produce un incidente grave, cuando el sistema se modifica sustancialmente con arreglo al artículo 3, punto 23, o cuando el contexto de despliegue cambia de forma material. Más allá de las revisiones desencadenadas por eventos, la mayoría de los programas fijan una cadencia programada mínima: trimestral para los riesgos residuales de alta gravedad, anual para las entradas aceptadas de bajo residual. El campo de fecha de revisión de cada entrada impone la rendición de cuentas. Una fecha que ha vencido sin una actualización es una laguna de cumplimiento documentada.
¿Qué significa que «el riesgo residual es aceptable» con arreglo al artículo 9, apartado 5?
El artículo 9, apartado 5, exige que los riesgos residuales considerados aceptables se documenten explícitamente. «Aceptable» no es lo mismo que «pequeño». Un riesgo residual puede ser de gravedad media y aun así aceptarse, siempre que la decisión la tome una persona nominada, se registre la justificación y se vigile el riesgo. Lo que el Reglamento prohíbe es la aceptación implícita: dejar una entrada de riesgo con una puntuación residual distinta de cero, sin decisión de aceptación y sin responsable. Si el riesgo residual realmente no es aceptable —no puede reducirse más y el perjuicio es demasiado significativo para tolerarlo—, eso es una señal de adelante/no adelante para la introducción en el mercado.
¿Debe el registro de riesgos estar en formato digital?
No se exige un formato específico. Una hoja de cálculo bien mantenida con control de versiones y un historial de ediciones completo puede satisfacer el artículo 9. La preocupación práctica es la defensibilidad ante una auditoría: una hoja de cálculo sin marcas de tiempo no puede probar que un riesgo se identificó en una fecha determinada y no de forma retroactiva. Para los sistemas sujetos a escrutinio regulatorio, un sistema que registra cada cambio con marca de tiempo e identidad del usuario es sustancialmente más seguro. Los requisitos de residencia de datos de la UE se aplican dondequiera que se almacene el registro: confirme que la ubicación del alojamiento coincide con sus compromisos de gobernanza de datos.
¿En qué se diferencia el registro de riesgos de la documentación técnica del artículo 11?
El expediente técnico exigido por el artículo 11 y el Anexo IV es el dosier de cumplimiento más amplio: descripción del sistema, decisiones de diseño, documentación de gobernanza de datos, resultados de la validación y el sistema de gestión de riesgos. El registro es el núcleo operativo del sistema de gestión de riesgos: el registro vivo de riesgos específicos, sus puntuaciones y sus controles. El artículo 11 / Anexo IV exige que el expediente técnico incluya una descripción del sistema de gestión de riesgos y de sus resultados; el registro es esa descripción. El registro de riesgos no debe mantenerse por separado del expediente técnico y reconciliarse después en la auditoría: deben ser la misma fuente.
Guías relacionadas
- ejemplos prácticos de registro de riesgos
- gestión del inventario de sistemas de IA
- registro en la base de datos del artículo 49
- comparación de herramientas de gestión de riesgos
- sistema de gestión de riesgos del artículo 9
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 →