Gestión de riesgos de la IA con arreglo a la Ley de IA de la UE: cómo construir su sistema del Artículo 9

Un sistema de gestión de riesgos (SGR) de la IA es un proceso documentado, continuo e iterativo —exigido por el Artículo 9 del Reglamento (UE) 2024/1689— que identifica y analiza los riesgos que un sistema de IA de alto riesgo plantea para la salud, la seguridad y los derechos fundamentales; estima y evalúa esos riesgos a partir del uso previsto y del uso indebido razonablemente previsible; evalúa los riesgos que afloran de los datos de vigilancia poscomercialización con arreglo al Artículo 72; y adopta medidas específicas y proporcionadas para reducir los riesgos hasta un nivel residual aceptable antes de la operación en el mercado y a lo largo de toda ella.

Merece la pena leer esa definición dos veces, porque contradice cómo funcionan en realidad la mayoría de los programas de cumplimiento. El SGR no es una lista de comprobación única previa al lanzamiento, ni un capítulo del expediente técnico, ni algo que el equipo jurídico gestiona una vez y archiva. El Artículo 9, apartado 1, emplea la expresión «proceso continuo e iterativo» a lo largo de «todo el ciclo de vida» del sistema. Cada vez que cambian las condiciones de despliegue, se reentrena el modelo, llegan nuevos datos de vigilancia o aflora un incidente grave, el bucle del SGR se reinicia.

En virtud del Ómnibus Digital acordado en mayo de 2026, las obligaciones para los sistemas de IA de alto riesgo autónomos (la lista del Anexo III) se aplican a partir del 2 de diciembre de 2027 —y a partir del 2 de agosto de 2028 para la IA de alto riesgo integrada en productos regulados con arreglo al Anexo I—. Eso amplía el margen que daba la fecha original de agosto de 2026, pero el trabajo de documentación y gobernanza necesario para demostrar a un organismo notificado o a una autoridad de vigilancia del mercado un SGR conforme con el Artículo 9 lleva mucho más de un año de construir como es debido. El plazo práctico es ahora, no a finales de 2027.

El incumplimiento del Artículo 9 se encuadra en el tramo intermedio de sanciones del Artículo 99: hasta 15 millones de euros o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Para las pymes con ingresos inferiores a 5 millones de euros, el umbral porcentual es la cifra vinculante —y el Artículo 99, apartado 6, limita las multas de las pymes al menor de los dos importes, lo que constituye una protección de proporcionalidad genuina, pero no un motivo para tomar atajos.

---

Quién debe operar un SGR formal del Artículo 9

El Artículo 9 se aplica a los proveedores de sistemas de IA de alto riesgo —organizaciones que desarrollan un sistema de alto riesgo y lo introducen en el mercado de la UE o lo ponen en servicio bajo su propio nombre o marca (Artículo 16)—. Si usted es una empresa de SaaS que comercializa un módulo de calificación crediticia, una función de cribado de currículos o un flujo de verificación biométrica, es un proveedor con la obligación plena del Artículo 9.

Los responsables del despliegue —organizaciones que utilizan un sistema de IA de alto riesgo en un contexto profesional— tienen obligaciones más ligeras con arreglo al Artículo 26, pero estas siguen incluyendo garantizar las medidas de supervisión humana especificadas en el Artículo 14, vigilar el funcionamiento y notificar incidentes. Los responsables del despliegue no operan el SGR completo del Artículo 9, pero deben integrarse en él: la documentación de riesgos del proveedor tiene que tener en cuenta los contextos de despliegue que el sistema encontrará realmente.

Un punto práctico importante: el Artículo 25 implica que un responsable del despliegue puede convertirse en proveedor de la noche a la mañana. Si reetiqueta con marca blanca un modelo de un tercero, lo integra en un nuevo producto bajo su nombre o modifica sustancialmente su finalidad prevista, las obligaciones plenas del proveedor —incluido el Artículo 9— recaen sobre usted desde ese momento.

Para los sistemas no clasificados como de alto riesgo con arreglo al Artículo 6 y al Anexo III, el Artículo 9 no es jurídicamente obligatorio. Dicho esto, operar una versión reducida del proceso del Artículo 9 es buena gobernanza y genera documentación que resulta inmediatamente útil si cambia la clasificación de un sistema —cosa que puede ocurrir, ya sea por una modificación regulatoria con arreglo al Artículo 7 o porque un contexto de despliegue desplace el perfil de riesgo.

Un matiz de clasificación que conviene señalar: el Artículo 6, apartado 3, ofrece un filtro. Un sistema que entra dentro de una categoría del Anexo III no es de alto riesgo si no plantea un riesgo significativo de perjuicio para la salud, la seguridad o los derechos fundamentales —por ejemplo, porque desempeña una tarea procedimental limitada, mejora el resultado de una actividad humana previamente realizada o detecta patrones de decisión sin influir en la evaluación humana—. La excepción no se aplica a ningún sistema que elabore perfiles de personas físicas, que sigue siendo de alto riesgo en todo caso. Los proveedores que reclamen la exención del Artículo 6, apartado 3, deben documentar su evaluación y registrarla en la base de datos de la UE con arreglo al Artículo 49. Si está considerando esta vía, el requisito de documentación para la reclamación de la exención es casi tan exigente como operar el propio proceso del Artículo 9 —téngalo en cuenta en su decisión.

---

Establecer la gobernanza del SGR antes de que arranque el bucle

El Artículo 17, apartado 1, letra b), enumera la gestión de riesgos como uno de los elementos que debe cubrir el sistema de gestión de la calidad. En la práctica, esto significa que el SGR necesita una capa de gobernanza antes de que pueda operarse: titularidad asignada, cadencias de revisión definidas, procedimientos documentados y un registro con control de versiones de cada actualización.

Para un proveedor que sea una pyme, esto no exige una función de riesgos dedicada. Lo que sí exige es: una persona designada y responsable del SGR (normalmente el director técnico o el responsable de producto), un proceso de aportación multifuncional que recabe el conocimiento técnico, de producto, jurídico y del contexto de despliegue para la identificación de riesgos, y un calendario documentado de revisión del SGR —trimestral como mínimo, y desencadenado de inmediato por cualquier cambio sustancial en el sistema, el contexto de despliegue o los datos de vigilancia.

La cuestión de la dotación de personal importa para la proporcionalidad. El Artículo 9 no exige la misma profundidad de gobernanza a una empresa emergente de 30 personas que a una gran empresa. El lenguaje de proporcionalidad de la Ley recorre la mayoría de las obligaciones del proveedor, y se espera que las autoridades competentes tengan en cuenta la escala y los recursos de una organización al evaluar el cumplimiento. Dicho esto, la proporcionalidad no excusa una laguna en la sustancia de los resultados del SGR —una empresa de 30 personas sigue necesitando un registro de riesgos con riesgos específicos identificados, evaluaciones documentadas y mitigaciones trazables—. Simplemente puede que no necesite un comité de gestión de riesgos dedicado.

Un documento en el que los proveedores que son pymes invierten sistemáticamente poco es la política del SGR: una breve declaración escrita, firmada por la persona responsable de mayor rango, que comprometa a la organización con las obligaciones del Artículo 9, asigne la responsabilidad y defina el alcance del SGR (qué sistemas cubre). Este documento tiene un peso desproporcionado en una inspección regulatoria porque indica que el proceso de gestión de riesgos es un compromiso organizativo, no un artefacto técnico ensamblado a posteriori.

---

El bucle del ciclo de vida del Artículo 9, paso a paso

El Artículo 9 estructura el SGR como un bucle con cuatro fases operativas. No son hitos secuenciales; se ejecutan de forma concurrente y se retroalimentan a lo largo de toda la vida del sistema.

Fase 1: identificar y analizar los riesgos conocidos y razonablemente previsibles

El Artículo 9, apartado 2, letra a), exige identificar y analizar «los riesgos conocidos y razonablemente previsibles para la salud, la seguridad o los derechos fundamentales». El criterio no son solo los riesgos que ya se han observado, sino que incluye los riesgos que un ingeniero competente preveería dada la tecnología, el contexto de despliegue y la población afectada.

Los riesgos «conocidos» se sustentan en pruebas empíricas: la literatura académica sobre los modos de fallo de la clase de modelo subyacente, las limitaciones declaradas por el proveedor, los resultados de las pruebas internas. Los riesgos «razonablemente previsibles» exigen anticipar cómo se comportará el sistema cuando los usuarios se desvíen del uso previsto, cuando lleguen entradas de casos límite o cuando las condiciones de despliegue se alejen de la distribución de entrenamiento.

Esta fase exige también una atención explícita al impacto sobre los grupos vulnerables, incluidos los menores. Los considerandos del Artículo 9 y el encuadre de los derechos fundamentales a lo largo de la Ley convierten esto en un requisito sustantivo, no en una casilla que marcar. Una IA de contratación evaluada para una plantilla profesional que después se despliega en contextos que implican a trabajadores jóvenes o a personas con discapacidad exige que se reabra la identificación de riesgos.

El resultado de esta fase es un registro de riesgos —no una lista de categorías de alto nivel, sino descripciones de riesgo específicas y acotadas, vinculadas a las características técnicas reales del sistema, al contexto de despliegue y a la población en riesgo.

Fase 2: estimar y evaluar los riesgos del uso previsto y del uso indebido razonablemente previsible

El Artículo 9, apartado 2, letras b) y c), separa el análisis de los escenarios de uso previsto del de los escenarios de uso indebido. Ambos son obligatorios. El uso indebido no significa sabotaje deliberado: significa error operativo previsible, deriva de contexto y usuarios que aplican el sistema a decisiones para las que no fue diseñado.

Para cada riesgo identificado, esta fase produce una estimación de la gravedad (la magnitud del perjuicio potencial) y de la probabilidad (la verosimilitud de que el perjuicio se materialice en condiciones reales). El Artículo 9 no prescribe una metodología concreta —puede usar una matriz cualitativa de gravedad/probabilidad, un modelo de puntuación semicuantitativo o un enfoque formal de AMFE—, pero la elección debe estar documentada y ser defendible. Sea cual sea el método que utilice, debe aplicarse de forma coherente a todos los riesgos identificados, y el juicio de aceptabilidad resultante debe ser explícito.

El riesgo residual —el riesgo que queda una vez aplicadas todas las medidas de mitigación— debe evaluarse y juzgarse aceptable. El Artículo 9, apartado 4, es claro en que los sistemas solo pueden introducirse en el mercado cuando los riesgos residuales «se consideren aceptables». Esto no es riesgo cero. Es el juicio de que el beneficio del sistema en su aplicación prevista supera al riesgo restante una vez aplicados controles proporcionados. Ese juicio debe documentarse, aprobarse formalmente y revisarse cada vez que cambien el sistema o su entorno operativo.

Fase 3: adoptar medidas de gestión de riesgos específicas y adecuadas

El Artículo 9, apartado 4, exige medidas de gestión de riesgos que sean «proporcionadas a los riesgos» y «teniendo en cuenta el estado de la técnica generalmente reconocido». Las medidas deben abordar los riesgos en su origen cuando sea técnicamente viable —lo que significa recorrer una jerarquía de mitigación antes de aceptar un control basado únicamente en la vigilancia.

La jerarquía práctica para los sistemas de IA tiene aproximadamente este aspecto:

1. Controles a nivel de diseño: modificar la arquitectura del modelo, los datos de entrenamiento o la lógica de salida para reducir el riesgo de forma mecánica. Restricciones de equidad sobre las distribuciones de salida, entrenamiento adverso para mejorar la robustez, validación de entradas para bloquear vectores de ataque conocidos.
2. Salvaguardas incorporadas en el sistema: umbrales de confianza que supriman las salidas de baja certeza, filtros de salida, repliegue automático a la revisión humana cuando el sistema opera fuera de su envolvente probada.
3. Información e instrucciones para los responsables del despliegue: la documentación técnica del Artículo 11 y las orientaciones para el responsable del despliegue del Artículo 13, que divulguen las limitaciones conocidas y especifiquen las condiciones de uso seguro.
4. Mecanismos de supervisión humana: los requisitos del Artículo 14 —la capacidad de vigilar, anular y detener el sistema—. Diseñar para la interpretabilidad de modo que los revisores humanos puedan ejercer realmente una supervisión significativa en lugar de validar sin más las salidas automatizadas.
5. Controles de vigilancia: la vigilancia poscomercialización del Artículo 72 como control residual para los riesgos que no puedan eliminarse por completo mediante el diseño.

Elegir la vigilancia como control principal para un riesgo de alta gravedad —en lugar de recorrer primero la jerarquía— es exactamente el tipo de laguna que atrae el escrutinio durante la evaluación de la conformidad.

Fase 4: probar contra métricas y umbrales predefinidos

El Artículo 9, apartado 6, exige que el sistema de gestión de riesgos «incluya la realización de pruebas del sistema de IA de alto riesgo con el fin de determinar las medidas de gestión de riesgos más adecuadas y específicas». El Artículo 9, apartado 7, es más específico: las pruebas «se efectuarán con respecto a métricas y umbrales probabilísticos previamente definidos».

Ese lenguaje importa. No se puede probar a posteriori contra cualesquiera métricas que resulten favorables. Las métricas, los umbrales y los conjuntos de datos de prueba deben definirse antes de que comiencen las pruebas y documentarse en el SGR. Las pruebas deben ser representativas de la población de despliegue prevista —el Artículo 9, apartado 8, exige expresamente que los datos de prueba sean adecuados y reflejen «la variación natural de los grupos demográficos» cuando proceda.

Las pruebas no son una actividad única. La obligación de probar se extiende a las versiones reentrenadas del modelo, a los cambios arquitectónicos significativos y a los casos en que los datos de vigilancia poscomercialización indiquen una degradación del rendimiento.

---

Taxonomía de riesgos específica de la IA

La Ley de IA de la UE no especifica una taxonomía de categorías de riesgo de la IA, pero la práctica del Artículo 9 ha convergido en un conjunto de tipos de riesgo que cualquier SGR de un sistema de alto riesgo debería abordar de forma sistemática. He aquí cómo estructuran los profesionales experimentados la fase de identificación de riesgos.

Sesgo y discriminación: la categoría de riesgo de IA más litigada. Incluye el sesgo directo (el sistema usa una característica protegida como variable de entrada), el sesgo por aproximación (el sistema usa una variable que correlaciona con una característica protegida —el código postal como aproximación de la etnia en un modelo crediticio—) y el sesgo de bucle de retroalimentación (un modelo entrenado con decisiones históricamente sesgadas replica y amplifica esas decisiones). La evaluación exige un análisis de rendimiento desagregado por subgrupos demográficos, documentado en el expediente técnico.

Fallos de exactitud y de rendimiento: un sistema de alto riesgo que produce salidas sistemáticamente incorrectas causa un perjuicio concreto —un producto sanitario que no detecta una afección, un sistema de detección de fraude que genera falsos positivos excesivos y congela cuentas legítimas—. La exactitud debe especificarse al nivel de la tarea y la población de despliegue, no informarse simplemente como una cifra agregada de titular.

Robustez y cambio distribucional: los sistemas de IA se comportan de forma diferente con datos que difieren de la distribución de entrenamiento. Un modelo entrenado con datos de préstamos anteriores a 2020 desplegado en condiciones económicas posteriores a 2023 puede tener un rendimiento sistemáticamente degradado. Las pruebas de robustez deben cubrir casos límite, entradas adversas y contextos de despliegue que difieran del conjunto de entrenamiento.

Seguridad: ataques adversos, envenenamiento de datos e inyección de instrucciones (prompt injection): el Artículo 15 aborda conjuntamente la exactitud, la robustez y la ciberseguridad. Para los sistemas que utilizan componentes de modelos lingüísticos de gran tamaño o que aceptan entradas en lenguaje natural, la inyección de instrucciones —manipular el comportamiento del modelo mediante entradas diseñadas— es una clase de amenaza concreta y documentada, no una preocupación teórica. El SGR debe abordarla explícitamente para cualquier sistema de esta categoría. Los riesgos de envenenamiento de datos son pertinentes siempre que los datos de entrenamiento procedan de fuentes que el proveedor no controla plenamente.

Deriva del modelo y deriva del concepto: la relación estadística entre las entradas y la salida correcta puede cambiar con el tiempo. Un sistema de clasificación de documentos entrenado con el lenguaje contractual de 2022 puede degradarse a medida que evolucionan las estructuras de los contratos. El SGR debe especificar los indicadores de vigilancia que harían aflorar la deriva y los umbrales que desencadenan el reentrenamiento o la revisión.

Riesgos de datos y de privacidad: el Artículo 10 rige la gobernanza de datos de los conjuntos de datos de entrenamiento, exigiendo conjuntos de datos que sean pertinentes, representativos y exentos de errores. Los riesgos de privacidad derivados de las salidas del sistema —la reidentificación de personas a partir de salidas supuestamente anonimizadas, la divulgación involuntaria de datos de entrenamiento mediante ataques de inversión del modelo— exigen una evaluación en el SGR y la coordinación con las obligaciones del RGPD.

Fallos de transparencia y lagunas de explicabilidad: si un sistema produce salidas que las personas afectadas o los supervisores humanos no pueden interrogar, el requisito de supervisión humana significativa del Artículo 14 se vuelve inaplicable en la práctica. Un riesgo que a menudo se pasa por alto: los responsables del despliegue pueden ser técnicamente capaces de anular el sistema, pero prácticamente incapaces de hacerlo porque no pueden interpretar la salida del sistema. El SGR debe evaluar si la información facilitada con arreglo al Artículo 13 es realmente suficiente para que la función de supervisión funcione.

Fallo de la supervisión humana: el Artículo 14 exige que los sistemas de IA de alto riesgo se diseñen de modo que las personas físicas puedan supervisarlos eficazmente, intervenir y anularlos. Una laguna habitual del SGR es tratar la supervisión humana como un control procedimental («exigimos que un humano confirme la decisión») sin evaluar si la persona en ese papel es realistamente capaz de detectar errores. El riesgo no es solo que la supervisión esté ausente, sino que sea nominal y, por tanto, proporcione una falsa garantía.

Riesgos de terceros y de la cadena de suministro: muchos sistemas de IA de alto riesgo se construyen sobre modelos de base, canalizaciones de datos de terceros o servicios de API que el proveedor no controla plenamente. Si un componente de la pila técnica de su sistema introduce una vulnerabilidad —un conjunto de datos de entrenamiento que contiene sesgos no divulgados, un modelo de base que se comporta de forma impredecible en condiciones adversas—, la obligación del Artículo 9 del proveedor sigue siendo aplicable. La fase de identificación de riesgos debe evaluar explícitamente las dependencias de terceros, y el SGR debe incluir procedimientos de contingencia ante el fallo o la modificación de esas dependencias. Esto no equivale a trasladar la responsabilidad: el Artículo 9 recae en el proveedor del sistema de IA de alto riesgo, no en el proveedor del componente subyacente.

Riesgos en cascada y sistémicos entre despliegues: un proveedor cuyo sistema se despliega en docenas o cientos de organizaciones cliente afronta un riesgo que el registro de riesgos debe abordar: el fallo sistémico. Si un episodio de degradación del modelo, un sesgo descubierto o una vulnerabilidad de seguridad afecta a todos los despliegues simultáneamente, el perjuicio combinado es muy superior al riesgo evaluado frente a cualquier despliegue individual. El plan de vigilancia poscomercialización del Artículo 72 debe diseñarse teniendo presente esta imagen de riesgo agregado —no solo una vigilancia cliente por cliente, sino la detección de patrones entre despliegues.

---

Evaluación del riesgo y juicio de aceptabilidad

El juicio de aceptabilidad —decidir que el riesgo residual es lo bastante bajo para proceder— es el resultado más trascendente del proceso del Artículo 9. Debe documentarse como una decisión explícita, no quedar implícito por la ausencia de señales de alarma.

En la práctica, un juicio de aceptabilidad defendible documenta: los riesgos residuales identificados y su gravedad y probabilidad estimadas tras los controles; la justificación para tratar el riesgo restante como aceptable (a menudo con referencia a la proporcionalidad del beneficio del sistema frente al perjuicio residual); las condiciones en las que se reabriría el juicio de aceptabilidad (umbrales de vigilancia específicos, cambios en el contexto de despliegue, nuevas pruebas procedentes de los datos poscomercialización); y la identidad y la autoridad de la persona o el comité que emite el juicio.

Para los sistemas en los que los riesgos residuales para los grupos vulnerables o los menores estén elevados, se aplica un nivel de exigencia superior. La atención del Artículo 9 a los «riesgos específicos para grupos específicos» no se satisface con un juicio de aceptabilidad general —exige una evaluación de riesgos específica del grupo y una evaluación de aceptabilidad específica del grupo.

---

Cómo alimenta el SGR las obligaciones conexas

El Artículo 9 no es una obligación aislada. Es la columna vertebral del proceso que conecta con casi todos los demás requisitos de alto riesgo.

Artículo 11 — Documentación técnica: el expediente técnico del Anexo IV debe incluir una descripción del sistema de gestión de riesgos y de las medidas adoptadas. El Anexo IV, punto 1, letra e), exige específicamente la descripción del SGR; el punto 2, letras a) a c), exige información sobre la metodología de entrenamiento, los conjuntos de datos de entrenamiento y los procedimientos de validación y prueba —todos ellos resultados o insumos del proceso del Artículo 9—. En la práctica, el expediente técnico es una instantánea estructurada del estado actual del SGR, no un documento separado redactado de forma independiente. El SGR está vivo; el expediente técnico es la instantánea que revisa un organismo de evaluación de la conformidad. Manténgalos vinculados estructuralmente de modo que actualizar el SGR haga aflorar automáticamente lo que hay que actualizar en el expediente técnico.

Uno de los fallos de documentación más habituales en las evaluaciones de la conformidad es que el expediente técnico describe un sistema de gestión de riesgos que parece distinto del que realmente opera el equipo de ingeniería. La brecha suele abrirse cuando el SGR se actualiza a mitad de ciclo pero el expediente técnico no. El control de versiones —con entradas fechadas y un registro de cambios— es la única solución fiable.

Artículo 10 — Gobernanza de datos: las prácticas de gestión de datos exigidas con arreglo al Artículo 10 (conjuntos de datos de entrenamiento pertinentes, representativos y exentos de errores; vigilancia de sesgos) deberían estar directamente informadas por los riesgos de datos y de sesgo identificados en el registro de riesgos del SGR. Si su proceso del Artículo 9 identifica el sesgo de los datos de entrenamiento como un riesgo de alta gravedad, sus controles del Artículo 10 deben abordar esa conclusión específicamente.

Artículo 14 — Supervisión humana: el diseño de los mecanismos de supervisión humana debe estar conformado por las conclusiones del SGR. Si el SGR concluye que una categoría de riesgo específica —por ejemplo, salidas incorrectas para un subgrupo demográfico concreto— no puede mitigarse plenamente a nivel de diseño, la supervisión del Artículo 14 debe diseñarse para detectar e interceptar ese riesgo específico. Los diseños de supervisión genéricos que no están conectados con las conclusiones del SGR son más difíciles de defender.

Artículo 15 — Exactitud, robustez y ciberseguridad: el Artículo 15 exige que los sistemas de IA de alto riesgo alcancen, y mantengan a lo largo de todo su ciclo de vida, niveles adecuados de exactitud, robustez y ciberseguridad. Los umbrales de lo «adecuado» deben derivarse de la evaluación del riesgo del Artículo 9 —el suelo de rendimiento aceptable lo fija lo que el análisis de riesgo residual haya determinado que es necesario para mantener el riesgo residual en un nivel aceptable.

Artículo 17 — Sistema de gestión de la calidad: el SGC del Artículo 17 es el contenedor organizativo dentro del cual se asienta el SGR. El SGC debe abarcar los procedimientos de gestión de riesgos (enumerados específicamente en el Artículo 17, apartado 1, letra b)), la gestión de cambios, las pruebas, la gestión de incidentes y la documentación. Si su organización dispone de un SGC con arreglo a la norma ISO 9001 o ISO/IEC 42001, el cumplimiento del Artículo 9 exige mapear el proceso del SGR dentro de esos marcos —no tratarlos como sustitutos mutuos.

Artículo 72 — Vigilancia poscomercialización: este es el canal de retroalimentación que cierra el bucle del Artículo 9. El Artículo 72 exige a los proveedores establecer un plan de vigilancia poscomercialización que recopile y analice activamente datos sobre el rendimiento del sistema en el despliegue real. Cuando esos datos hagan aflorar riesgos que no se identificaron antes del despliegue o que han empeorado tras él, el SGR del Artículo 9 debe actualizarse. Las dos obligaciones son intencionadamente interdependientes: el Artículo 9 aborda el riesgo previsible; el Artículo 72 aborda el riesgo que emerge de la operación real.

---

Pruebas, métricas y umbrales

La obligación de pruebas del Artículo 9 (Art. 9, apdos. 6 a 9) es una de las partes más específicas, y más infraimplementadas, del requisito del SGR. He aquí cómo es el cumplimiento operativo.

Defina sus métricas antes de que comiencen las pruebas. Para un sistema de clasificación, las métricas pertinentes podrían incluir la exactitud, la precisión, la exhaustividad (recall), la puntuación F1 y métricas de equidad (diferencia de paridad demográfica, diferencia de igualdad de oportunidades). Para un sistema de regresión, el error absoluto medio, la varianza del error entre subgrupos. Para un sistema de lenguaje natural, la coherencia de las salidas, las tasas de rechazo ante instrucciones adversas. Qué métricas se seleccionan debe justificarse en el SGR a partir de la tarea del sistema y de los riesgos identificados.

Defina sus umbrales antes de que comiencen las pruebas. Un umbral podría ser: exactitud global ≥ 92 %; diferencia de paridad demográfica ≤ 5 puntos porcentuales; tasa de falsos negativos ≤ 3 % para la clase de salida de mayor consecuencia. Los umbrales deben fundarse en el juicio de aceptabilidad —son la expresión cuantificada de lo que significa «riesgo residual aceptable» para este sistema.

Pruebe con datos que sean representativos de la población de despliegue real. Si su despliegue previsto incluye usuarios de varios Estados miembros de la UE con contextos lingüísticos y culturales distintos, su conjunto de prueba debe reflejarlo. El Artículo 9, apartado 8, exige que las pruebas «incluyan, en la medida de lo posible, datos que reflejen la variación natural de los grupos demográficos».

Cuando un sistema no alcance un umbral predefinido, el fallo debe documentarse, investigarse la causa y, o bien el sistema debe modificarse hasta que lo supere, o bien debe reabrirse el juicio de aceptabilidad. Rebajar el umbral tras un fallo en una prueba para que el resultado pase es exactamente el tipo de manipulación de ingeniería que la documentación estructurada del SGR está concebida para impedir.

---

Tabla de correspondencias de marcos: el Artículo 9 y las normas voluntarias

Las organizaciones que ya han invertido en marcos voluntarios de gestión de riesgos necesitan comprender las lagunas —y los solapamientos— entre esos marcos y la obligación jurídica del Artículo 9.

La conclusión práctica: si su organización ha implementado el ciclo Govern/Map/Measure/Manage del NIST AI RMF, ha construido una infraestructura útil de gobernanza de riesgos —pero no ha satisfecho automáticamente el Artículo 9—. La obligación del Artículo 9 es más específica en cuanto a la aceptabilidad del riesgo residual, las normas de prueba, el encuadre de los derechos fundamentales y el bucle de retroalimentación del Artículo 72. De forma análoga, la certificación ISO/IEC 42001 es valiosa a efectos del SGC y se corresponde razonablemente bien con el Artículo 17, pero no sustituye a la especificidad técnica que exige el Artículo 9. La ISO 31000 es una referencia metodológica útil para las fases de identificación y evaluación de riesgos, pero opera a un nivel de generalidad que requiere una elaboración sustancial específica de la IA antes de cumplir los criterios del Artículo 9.

La pregunta que los profesionales formulan a menudo es: ¿por dónde deberíamos empezar si ya hemos invertido en el NIST AI RMF? El puente más directo es la función «Measure». La práctica Measure 2.5 del NIST AI RMF (los riesgos de la IA que han de gestionarse se priorizan en función del impacto, la probabilidad y las mitigaciones disponibles) se corresponde estrechamente con las fases de evaluación y mitigación del Artículo 9, apartados 2 a 4. La Measure 2.7 (la fiabilidad del sistema de IA se evalúa a partir de los resultados de las pruebas alineados con los riesgos o perjuicios) es el análogo más próximo a la obligación de pruebas del Artículo 9, apartados 6 a 9. Partir de esas dos prácticas «Measure» e ir superponiendo los requisitos específicos del Artículo 9 —juicio explícito de aceptabilidad del riesgo residual, umbrales predefinidos, encuadre de los derechos fundamentales, atención a los grupos vulnerables— es más rápido que construir desde cero.

Para las organizaciones que disponen de la ISO/IEC 42001, la brecha es más estrecha en cuanto a la estructura de gobernanza y de SGC (que se corresponde con el Artículo 17) y más amplia en cuanto a la especificidad técnica de la evaluación del riesgo. Los controles del Anexo A de la ISO 42001 hacen referencia a la gestión de riesgos sin especificar el nivel de detalle del Artículo 9 sobre las normas de prueba, los criterios de aceptabilidad o los bucles de retroalimentación poscomercialización. Use la estructura de la 42001 como contenedor; construya dentro de ella el contenido específico del Artículo 9.

---

Ejemplo trabajado: un proveedor de tecnología de RR. HH. de 45 personas

Meridia es una empresa de tecnología de RR. HH. de 45 personas. Su producto estrella es una herramienta de puntuación de entrevistas asistida por IA que analiza las respuestas escritas a preguntas de entrevista estructuradas y proporciona preselecciones ordenadas a los equipos de RR. HH. de empleadores del segmento medio. El equipo jurídico de la empresa ha determinado que la herramienta entra en el epígrafe 4 del Anexo III (decisiones de empleo que afectan al acceso al autoempleo y a la gestión de los trabajadores). Con arreglo al Artículo 6, la herramienta es de alto riesgo. Meridia es un proveedor. El Artículo 9 se aplica en su totalidad. El plazo de cumplimiento es el 2 de diciembre de 2027.

Gobernanza del SGR: Meridia nombra a su director técnico responsable del SGR y convoca una revisión trimestral del SGR en la que participan el director técnico, el responsable de producto y un científico de datos a tiempo parcial. Esto satisface el requisito del Artículo 17 de que las responsabilidades de gestión de riesgos se asignen a personal con la competencia necesaria.

Identificación de riesgos: el equipo multifuncional documenta seis riesgos materiales. Los dos de mayor gravedad:

• Discriminación por aproximación: el modelo se entrenó con datos históricos de contratación de clientes que operaban en sectores con una contratación históricamente dominada por hombres. El modelo puede haber aprendido a asociar patrones lingüísticos correlacionados con candidatos varones con puntuaciones más altas.
• Fallo de transparencia/supervisión: los revisores de RR. HH. de las empresas cliente reciben una puntuación numérica y una clasificación, pero ninguna explicación de los factores que impulsan la puntuación. La anulación significativa con arreglo al Artículo 14 no es prácticamente alcanzable porque los revisores no pueden valorar qué motivó una puntuación baja.

Evaluación de riesgos: el riesgo de discriminación por aproximación se califica como grave/alta probabilidad y se evalúa como afectante de forma desproporcionada a candidatas y a candidatos de diversidad étnica —un impacto específico y relevante para los derechos fundamentales—. El riesgo de fallo de la supervisión se califica como grave/probabilidad media. Ambos se marcan como «todavía no aceptables».

Diseño de la mitigación:

• Discriminación por aproximación: Meridia reentrena el modelo con restricciones de paridad demográfica; elimina las variables con potencial documentado de discriminación por aproximación; encarga una auditoría de equidad independiente del modelo reentrenado, con un umbral de aceptación de ≤ 4 puntos porcentuales de diferencia de paridad demográfica.
• Fallo de la supervisión: añade una explicación de importancia de variables a cada salida de puntuación (las tres características de la respuesta que más contribuyen a la puntuación), rediseña la interfaz para exigir que el revisor acuse recibo de la explicación antes de confirmar la preselección.

Pruebas: Meridia ejecuta pruebas de equidad sobre un conjunto de datos reservado estratificado por sexo, grupo de edad y origen nacional. Los umbrales de aceptación predefinidos se documentan en el SGR antes de que comiencen las pruebas. La primera pasada falla en la paridad por grupo de edad (diferencia de 8 puntos porcentuales). Meridia modifica la canalización de entrenamiento y vuelve a probar. La segunda pasada supera todos los umbrales.

Aceptabilidad del riesgo residual: documentada por el director técnico y aprobada formalmente por el consejero delegado: diferencia de paridad demográfica ≤ 4 %, explicación facilitada para todas las puntuaciones, revisión humana exigida antes de finalizar la preselección. El riesgo residual se juzga aceptable en estas condiciones.

Vigilancia poscomercialización: informes mensuales de rendimiento demográfico a los equipos de RR. HH. de los clientes; alerta automática al panel de vigilancia de Meridia si algún despliegue de cliente muestra una diferencia de paridad demográfica superior a 6 puntos porcentuales; revisión trimestral de los datos de vigilancia incorporada a la reunión de revisión del SGR.

Esta estructura —gobernanza, identificación, evaluación, mitigación, pruebas, aceptabilidad, vigilancia— es el aspecto que tiene el cumplimiento del Artículo 9 para un proveedor a escala de pyme. No exige un documento de 200 páginas. Exige un proceso disciplinado y multifuncional con resultados trazables en cada etapa.

---

Cómo ayuda Confir

El cumplimiento del Artículo 9 genera mucha documentación que debe mantenerse coherente a medida que el sistema evoluciona, el registro de riesgos se actualiza y los datos de vigilancia poscomercialización se retroalimentan. Mantener esa coherencia en una hoja de cálculo es técnicamente posible para un sistema; se vuelve inmanejable rápidamente con varios sistemas o miembros del equipo.

El área de cumplimiento AIGM de Confir —que abarca el Artículo 9 y el Artículo 72— estructura el proceso del Artículo 9 como una serie de evaluaciones guiadas. El registro de riesgos está incorporado en el flujo de trabajo, los controles se evalúan frente a referencias concretas de los Artículos mediante lógica determinista y basada en reglas en lugar de sugerencias generadas por IA, y la Puntuación de Salud del Cumplimiento refleja el estado actual de su SGR a nivel de organización en todos los sistemas registrados. Cuando el SGR alimenta el paquete de documentación técnica del Artículo 11, el vínculo se mantiene automáticamente —de modo que una evaluación de riesgos actualizada se refleja en la documentación que llega a un organismo de evaluación de la conformidad.

Para las organizaciones que gestionan varios sistemas de alto riesgo —o las organizaciones que tienen una mezcla de funciones de proveedor y de responsable del despliegue—, el registro de riesgos a nivel de toda la organización es donde el cumplimiento del Artículo 9 se vuelve manejable en lugar de abrumador.

El trabajo de documentación sigue siendo suyo; la estructura y la exactitud a nivel de Artículo vienen incorporadas.

---

Preguntas frecuentes

¿Qué es exactamente el sistema de gestión de riesgos del Artículo 9, y es lo mismo que una evaluación de riesgos?

Una evaluación de riesgos es un único ejercicio —normalmente una evaluación puntual de los riesgos identificados—. El sistema de gestión de riesgos del Artículo 9 es el proceso continuo que envuelve a la evaluación de riesgos: estructura de gobernanza, procedimientos documentados, metodología de identificación de riesgos, protocolos de prueba, seguimiento de la mitigación, bucles de retroalimentación poscomercialización y la obligación permanente de actualizar el sistema cada vez que cambien las circunstancias. La evaluación de riesgos es uno de los resultados del SGR; el SGR es la infraestructura viva que la produce de forma continua.

¿Se aplica el Artículo 9 a los responsables del despliegue, o solo a los proveedores?

La obligación plena del Artículo 9 recae en los proveedores (Artículo 16). Los responsables del despliegue tienen obligaciones más ligeras con arreglo al Artículo 26 —principalmente seguir las instrucciones del proveedor, garantizar la supervisión humana con arreglo al Artículo 14 y vigilar el uso—. Dicho esto, los responsables del despliegue que modifican sustancialmente un sistema o cambian su finalidad prevista pasan a desempeñar el papel de proveedor con arreglo al Artículo 25 y heredan la obligación plena del Artículo 9 a partir de ese momento.

¿Qué significa en la práctica que «el riesgo residual debe ser aceptable»?

Significa que, una vez aplicadas todas las medidas de mitigación proporcionadas, el riesgo restante —cuantificado en términos de la gravedad y la probabilidad de los perjuicios potenciales para la salud, la seguridad y los derechos fundamentales— debe juzgarse aceptable en relación con el beneficio del sistema. La Ley no define un umbral universal. El juicio de aceptabilidad le corresponde a usted formularlo y documentarlo, pero debe ser explícito, fundado en las conclusiones de la evaluación del riesgo, específico de las condiciones y reabierto cada vez que cambien sustancialmente las condiciones de despliegue.

¿Cómo interactúa el Artículo 9 con el RGPD?

Operan con bases jurídicas distintas, pero abordan categorías de riesgo que se solapan. Un riesgo de sesgo de los datos de entrenamiento identificado con arreglo al Artículo 9 puede solaparse con los principios del RGPD de exactitud de los datos y de equidad en las decisiones automatizadas. Un riesgo de privacidad derivado de ataques de inversión del modelo se sitúa en la intersección de la ciberseguridad del Artículo 15 y las obligaciones de seguridad del RGPD. Los dos marcos no se sustituyen mutuamente; exigen programas de cumplimiento coordinados, en particular cuando la evaluación de impacto relativa a los derechos fundamentales del Artículo 27 se solapa con una evaluación de impacto relativa a la protección de datos del RGPD.

¿Cuál es la sanción por no operar un sistema de gestión de riesgos conforme con el Artículo 9?

El incumplimiento del Artículo 9 se encuadra en el tramo intermedio de sanciones del Artículo 99, apartado 4: hasta 15 millones de euros o el 3 % del volumen de negocios anual mundial total del ejercicio anterior, si esta última cifra es mayor. Para las pymes y las empresas emergentes, el Artículo 99, apartado 6, limita las multas al menor de los dos importes. Al margen de las sanciones, las autoridades de vigilancia del mercado también pueden exigir medidas correctoras, retirar un sistema del mercado o suspender su despliegue hasta que se cumpla.

¿Puede la certificación ISO/IEC 42001 sustituir al SGR del Artículo 9?

No. La ISO/IEC 42001 es una norma de sistema de gestión que se corresponde bien con los requisitos organizativos y de SGC del Artículo 17. No sustituye al SGR del Artículo 9. La Ley exige resultados técnicos específicos —un registro de riesgos documentado, métricas y umbrales de prueba predefinidos, un juicio explícito de aceptabilidad del riesgo residual, la integración con la vigilancia poscomercialización del Artículo 72— que van más allá de lo que aborda una certificación ISO 42001. La certificación es prueba útil de la madurez de la gobernanza; no completa la obligación del Artículo 9.

¿Cuándo es el plazo para que los sistemas de IA de alto riesgo dispongan de un SGR conforme con el Artículo 9?

En virtud del Ómnibus Digital acordado en mayo de 2026, la fecha de aplicación para los sistemas de IA de alto riesgo autónomos enumerados en el Anexo III es el 2 de diciembre de 2027. Para los sistemas de IA de alto riesgo que son componentes de seguridad de productos regulados con arreglo al Anexo I (productos sanitarios, máquinas, etc.), la fecha es el 2 de agosto de 2028. Estas fechas amplían el plazo original de agosto de 2026. Dado que un SGR creíble del Artículo 9 lleva un año o más de construir, documentar y probar, las organizaciones que no hayan iniciado el trabajo de gobernanza ya van por detrás del calendario efectivo.

---

Guías relacionadas

• comparar soluciones de cumplimiento de la Ley de IA de la UE
• obligaciones del responsable del despliegue del Artículo 26
• requisitos de gestión de la calidad del Artículo 17