Artículo 9 de la Ley de IA de la UE: sistema de gestión de riesgos para la IA de alto riesgo
El Artículo 9 de la Ley de IA de la UE exige un sistema de gestión de riesgos continuo para la IA de alto riesgo. Cubre los 4 pasos obligatorios, la prueba del riesgo residual y el plazo de diciembre de 2027.
El Artículo 9 del Reglamento (UE) 2024/1689 — la Ley de IA de la UE — exige a todo proveedor de un sistema de IA de alto riesgo establecer, implantar, documentar y mantener un sistema de gestión de riesgos (SGR). La obligación no termina en el lanzamiento. El Artículo 9 enmarca explícitamente el SGR como un proceso continuo e iterativo ejecutado a lo largo de todo el ciclo de vida del sistema, sujeto a una revisión sistemática periódica. Ese encuadre importa: un expediente de riesgos reunido una sola vez y archivado no satisface el Artículo 9.
En virtud del Ómnibus Digital acordado en mayo de 2026, el plazo del Artículo 9 para los sistemas de IA de alto riesgo autónomos (Anexo III) es el 2 de diciembre de 2027. Para la IA de alto riesgo integrada en productos cubiertos por el Derecho de seguridad de los productos de la UE (Anexo I), el plazo es el 2 de agosto de 2028. El incumplimiento expone a los proveedores a multas de 15 millones de euros o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor (Artículo 99).
Esta guía explica qué debe contener el SGR del Artículo 9, los cuatro pasos obligatorios de gestión de riesgos, cómo conecta el SGR con la pila más amplia de obligaciones de alto riesgo y cómo construir uno en la práctica.
Qué exige realmente el Artículo 9
La obligación de proceso continuo
El Artículo 9, apartado 1, describe el SGR como un conjunto de medidas establecidas, implantadas, documentadas y mantenidas que constituye un proceso continuo e iterativo ejecutado a lo largo de todo el ciclo de vida de un sistema de IA de alto riesgo, que requiere una revisión y actualización sistemáticas periódicas. La palabra «iterativo» es deliberada. Los riesgos que eran aceptables en el momento del entrenamiento pueden volverse inaceptables una vez que el sistema se despliega a escala, se encuentra con casos límite u opera en un contexto que el proveedor no anticipó plenamente.
Esta es una distinción estructural respecto de una auditoría de conformidad única. Su SGR debe ser un proceso de gestión vivo — no un documento.
Los cuatro pasos obligatorios
El Artículo 9, apartado 2, establece los pasos exigidos en orden:
Paso 1 — Identificar y analizar los riesgos conocidos y razonablemente previsibles. Debe examinar los riesgos para la salud, la seguridad y los derechos fundamentales derivados del sistema cuando se utiliza para su finalidad prevista. «Razonablemente previsible» extiende el análisis más allá del camino feliz: debe considerar cómo podría utilizarse indebidamente el sistema, cómo podrían los usuarios malinterpretar sus resultados y qué sucede cuando falla de forma silenciosa en lugar de ruidosa.
Paso 2 — Estimar y evaluar los riesgos que pueden surgir bajo el uso previsto y bajo un uso indebido razonablemente previsible. Esto se distingue del paso 1. La identificación pregunta qué puede salir mal; la estimación pregunta con qué probabilidad y con qué gravedad. Un modelo que clasifica erróneamente una solicitud de empleo con una tasa de error del 0,5 % tiene un aspecto distinto cuando tramita 500 000 solicitudes al año. Tanto la probabilidad como la magnitud del perjuicio deben evaluarse — incluidos los riesgos que se materializan únicamente en las condiciones que crea el responsable del despliegue.
Paso 3 — Evaluar los riesgos a la luz de los datos de vigilancia poscomercialización (Artículo 72). Una vez que el sistema está en funcionamiento, los datos de vigilancia retroalimentan el SGR. El Artículo 9, apartado 2, letra c), exige explícitamente que los resultados de la vigilancia poscomercialización se tengan en cuenta en la evaluación del riesgo. Esto crea un bucle cerrado: el despliegue genera pruebas, las pruebas actualizan el panorama del riesgo, y el panorama del riesgo actualizado impulsa una mayor mitigación o restricción.
Paso 4 — Adoptar medidas de gestión de riesgos adecuadas y específicas. El Artículo 9, apartado 4, especifica el orden de prioridad. Eliminar o reducir los riesgos a través de las elecciones de diseño y desarrollo en la medida de lo posible. Cuando la eliminación no sea posible, mitigar y controlar los riesgos residuales, incluso mediante información adecuada a los responsables del despliegue en virtud del Artículo 13 y mediante medidas de formación. El riesgo residual — tanto para cada peligro individual como en su conjunto — debe juzgarse aceptable antes de que el sistema se introduzca en el mercado o se ponga en servicio.
La prueba de aceptabilidad del riesgo residual
El Reglamento no define «aceptable» en una fórmula. En la práctica, el proveedor debe documentar un juicio razonado: dada la finalidad prevista del sistema, su contexto de uso, la disponibilidad de enfoques alternativos y el estado de la técnica en la reducción de riesgos, ¿es el riesgo restante proporcionado al beneficio? Ese juicio debe quedar registrado en la documentación técnica (Artículo 11, Anexo IV) y ser defendible ante una autoridad de vigilancia del mercado.
Personas vulnerables y menores de 18 años
El Artículo 9, apartado 9, singulariza explícitamente una categoría: cuando el sistema pueda interactuar con menores de 18 años o afectarles, o a otros grupos considerados vulnerables debido a la edad, la discapacidad u otras circunstancias personales, el proveedor debe prestar especial atención a su situación en la evaluación de riesgos. Esto no es una aspiración blanda. Una herramienta de contratación utilizada en ferias de empleo universitarias, o un modelo de calificación crediticia que afecta a jóvenes adultos que buscan su primer préstamo, debe abordar directamente esta población en el SGR.
Pruebas frente a métricas previamente definidas
El Artículo 9, apartado 7, exige realizar pruebas para garantizar que las medidas de gestión de riesgos son eficaces. Las pruebas deben realizarse frente a métricas y umbrales probabilísticos previamente definidos adecuados a la finalidad prevista. Las pruebas pueden realizarse a lo largo del desarrollo; deben tener lugar, a más tardar, antes de introducir el sistema en el mercado o ponerlo en servicio. Un proveedor que prueba el sistema por primera vez después del despliegue ya está fuera de cumplimiento.
Cómo encaja el Artículo 9 en la pila más amplia de alto riesgo
El Artículo 9 es la columna vertebral procedimental; los demás artículos de alto riesgo aportan el contenido que debe abordar. Comprender las conexiones evita el error habitual de tratar cada artículo como un compartimento estanco separado.
Artículo 10 (datos y gobernanza de datos): La calidad, la representatividad y el sesgo de los datos — los temas del Artículo 10 — son datos de entrada para los pasos de identificación y estimación de riesgos del Artículo 9. Un conjunto de datos de entrenamiento que infrarrepresenta a un grupo protegido es en sí mismo un riesgo que debe aparecer en el SGR y mitigarse.
Artículo 11 (documentación técnica, Anexo IV): El SGR y sus conclusiones deben quedar registrados en el expediente de documentación técnica. El Anexo IV, sección 2, enumera específicamente la descripción del sistema de gestión de riesgos como un elemento obligatorio de ese expediente.
Artículo 13 (transparencia e información a los responsables del despliegue): Cuando un riesgo no pueda eliminarse por diseño, el Artículo 9, apartado 4, permite la mitigación mediante información. Las instrucciones de uso que los proveedores deben facilitar en virtud del Artículo 13 son uno de los canales de mitigación reconocidos — pero solo después de haber agotado la reducción de riesgos a nivel de diseño.
Artículo 14 (supervisión humana): La supervisión humana es en sí misma una medida de mitigación de riesgos. Si el riesgo residual de un sistema en un escenario dado solo puede hacerse aceptable exigiendo que un humano revise los resultados antes de tomar una decisión, entonces el requisito de diseño de la supervisión humana del Artículo 14 viene impulsado directamente por el análisis del Artículo 9.
Artículo 15 (exactitud, robustez, ciberseguridad): El paso 2 del Artículo 9 (estimación del riesgo) debe cubrir los riesgos abordados en el Artículo 15: degradación de la exactitud, entradas de adversariedad y vulnerabilidades de ciberseguridad. Los requisitos del Artículo 15 fijan el suelo de rendimiento; el Artículo 9 es el proceso a través del cual usted verifica que se ha alcanzado ese suelo.
Artículo 17 (sistema de gestión de la calidad, SGC): El Artículo 9 no se sostiene por sí solo dentro de las obligaciones del proveedor. El Artículo 17 exige a los proveedores integrar el SGR en un sistema de gestión de la calidad más amplio que cubra los procesos de toda la organización. El SGC es el contenedor; el SGR de cada sistema de alto riesgo es uno de sus componentes.
Artículo 72 (vigilancia poscomercialización): La vigilancia poscomercialización no es una vía de cumplimiento separada — alimenta el Artículo 9 directamente, como el paso 3 anterior. Los datos de vigilancia que revelen una deriva del rendimiento, nuevos modos de fallo o patrones de uso inesperados deben desencadenar una revisión de la evaluación de riesgos y, si está justificado, nuevas medidas de mitigación.
Marcos voluntarios: qué son y qué no son
La norma ISO 31000 (principios de gestión de riesgos), el NIST AI RMF (marco de gestión de riesgos de la IA) y la ISO/IEC 42001 (sistemas de gestión de la IA) son arquitecturas de referencia útiles para estructurar un SGR. Confir asigna sus controles a la ISO/IEC 42001 y al NIST AI RMF. Sin embargo, ninguno de estos marcos es un sustituto de un SGR del Artículo 9. El cumplimiento de la ISO/IEC 42001 no certifica el cumplimiento de la Ley de IA de la UE. Los marcos pueden acelerar su construcción y mejorar su calidad, pero la obligación del Artículo 9 está definida por el Reglamento y debe cumplirse en sus propios términos.
Artículo 6, apartado 3: no todo sistema del Anexo III es automáticamente de alto riesgo
Antes de invertir en un SGR del Artículo 9, confirme que su sistema realmente activa la obligación. El Artículo 6, apartado 3, dispone que un sistema que entra en un ámbito 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. El Reglamento da cuatro ejemplos: el sistema desempeña una tarea procedimental limitada; mejora el resultado de una actividad humana previamente realizada; detecta patrones de toma de decisiones sin influir ni sustituir la evaluación humana individual; y realiza una tarea preparatoria para valorar la situación de una persona. Excepción: todo sistema que elabore perfiles de personas físicas es siempre de alto riesgo, con independencia de estos filtros.
Los proveedores que reclamen la exención del Artículo 6, apartado 3, deben documentar esa evaluación y registrarla en la base de datos de la UE en virtud del Artículo 49. La exención no es un resquicio para evitar el SGR — es un filtro de alcance estrecho para aplicaciones de consecuencias genuinamente bajas dentro de una categoría del Anexo III.
Ejemplo resuelto: SGR del Artículo 9 para una herramienta de cribado de currículos
Considere una empresa de tecnología de RR. HH. de 45 personas que ha construido un sistema de cribado de currículos. El sistema clasifica a los candidatos a un empleo para empresas clientes de sectores como la gestión minorista y la logística. Entra de lleno en el Anexo III, sección 4 (empleo y gestión de los trabajadores). La empresa es el proveedor en virtud del Artículo 16. Así es como se aplica el Artículo 9.
Alcance del ciclo de vida. El SGR comienza en el diseño del producto, no en el lanzamiento. La empresa lo documenta durante el desarrollo, lo actualiza antes de cada versión importante y lo mantiene a lo largo de la vida comercial del producto.
Paso 1 — Identificar riesgos. La empresa identifica: a) que el sistema puede producir clasificaciones discriminatorias correlacionadas con el sexo o la etnia debido a patrones en los datos históricos de entrenamiento; b) que puede perjudicar a los candidatos con currículos no estándar (interrupciones de carrera, sistemas educativos de fuera de la UE); c) que los responsables del despliegue pueden basarse en las clasificaciones sin revisar la justificación subyacente; d) que los candidatos preseleccionados o rechazados no reciben explicación alguna, lo que limita su capacidad de buscar reparación.
Paso 2 — Estimar y evaluar. La empresa modela la probabilidad y la magnitud de cada riesgo. El riesgo a) afecta a los derechos fundamentales y podría afectar a miles de candidatos al año en toda la base de clientes de la empresa — alta probabilidad, alta gravedad. El riesgo b) es de menor probabilidad, pero afecta a grupos ya infrarrepresentados en el mercado laboral. Ambos se clasifican como requeridos de mitigación activa antes del lanzamiento. La empresa modela explícitamente el uso indebido razonablemente previsible: un responsable del despliegue que desactiva el paso recomendado de revisión humana y utiliza las clasificaciones como decisiones finales, no como preselecciones.
Paso 3 — Bucle de vigilancia poscomercialización. Una vez desplegado, la empresa recopila datos agregados de resultados de los clientes (con consentimiento, anonimizados): tasas de preselección por aproximación demográfica, tasas de anulación por parte de los seleccionadores y reclamaciones en la fase de solicitud. Estos datos alimentan la revisión trimestral del SGR.
Paso 4 — Medidas de riesgo. Cambios de diseño: el algoritmo de clasificación se reentrena con un conjunto de datos sin sesgos, y el sistema se reestructura para producir preselecciones en lugar de puntuaciones clasificadas (reduciendo la autoridad percibida del resultado). Controles residuales: las instrucciones de uso en virtud del Artículo 13 prohíben utilizar el sistema como único determinante del rechazo; los responsables del despliegue deben confirmar la revisión humana antes de eliminar a cualquier candidato. Nota sobre personas vulnerables: la empresa señala que el sistema se utiliza a veces en programas de contratación de titulados dirigidos a menores de 25 años. El SGR aborda el perfil de riesgo de esta población por separado — en particular, el riesgo de que el modelo funcione peor en itinerarios de titulación no tradicionales.
Juicio sobre el riesgo residual. Tras la mitigación, la empresa documenta que el riesgo residual es aceptable dados: la función de preselección en lugar del rechazo binario, la instrucción obligatoria de revisión humana, el bucle de vigilancia activo y las tasas de exactitud alcanzables entre los grupos demográficos. Este juicio queda registrado en la documentación técnica del Anexo IV.
Cómo construir un SGR del Artículo 9: una secuencia práctica
La siguiente secuencia se aplica a un proveedor que construye un SGR desde cero para un sistema autónomo del Anexo III. El plazo es el 2 de diciembre de 2027; de forma realista, un SGR documentado y probado para un sistema de complejidad media lleva de cuatro a seis meses de construcción adecuada.
1. Confirme el alcance. Determine si el sistema es de alto riesgo con arreglo al Artículo 6 y al Anexo III, y si se aplica el filtro del Artículo 6, apartado 3. Documente el razonamiento. Si usted es un responsable del despliegue — no un proveedor — revise el SGR del proveedor y evalúe qué riesgos adicionales específicos del contexto introduce su despliegue; los responsables del despliegue tienen sus propias obligaciones del Artículo 9 dentro de su alcance operativo.
2. Asigne la titularidad. Designe a una persona concreta (o un pequeño comité en organizaciones más grandes) responsable del SGR. En virtud del Artículo 17, esto encaja dentro del sistema de gestión de la calidad. Asegúrese de que el rol tenga autoridad para retrasar un lanzamiento si los riesgos residuales aún no son aceptables.
3. Mapee el ciclo de vida. Identifique cada fase en la que pueden surgir nuevos riesgos: diseño, recopilación de datos, entrenamiento, validación, despliegue, operación, actualización y retirada del servicio. El SGR debe abordar cada fase, aunque las medidas en algunas fases sean simplemente vigilancia y revisión.
4. Realice una identificación sistemática de riesgos. Para cada fase del ciclo de vida, identifique los riesgos para la salud, la seguridad y los derechos fundamentales — incluido el uso indebido razonablemente previsible. Utilice técnicas estructuradas (análisis de modos de fallo, modelización de escenarios) en lugar de una lluvia de ideas ad hoc. Preste atención explícita a los grupos vulnerables y a los menores de 18 años cuando proceda.
5. Estime la probabilidad y la gravedad. Para cada riesgo identificado, registre una estimación de la probabilidad y el impacto. Esto no requiere precisión actuarial — requiere juicios razonados y documentados que resistan el escrutinio. Anote dónde no hay datos disponibles y cómo ha gestionado la incertidumbre.
6. Diseñe medidas de riesgo en orden de prioridad. Empiece por cambios de diseño y desarrollo para eliminar riesgos. Documente qué se consideró y por qué determinados cambios no eran viables. A continuación, defina los controles residuales, la documentación para los responsables del despliegue y las medidas de formación. Toda medida de mitigación debe ser rastreable hasta el riesgo que aborda.
7. Defina las métricas y los umbrales de prueba. Antes de que comiencen las pruebas, ponga por escrito qué aspecto tiene el éxito: tasas de exactitud, paridad de rendimiento entre los grupos demográficos, robustez frente a perturbaciones de entrada especificadas, respuesta a intentos de entradas de adversariedad. El Artículo 9, apartado 7, exige realizar pruebas frente a métricas previamente definidas. No defina las métricas después de haber visto los resultados.
8. Pruebe y valide. Ejecute las pruebas. Registre los resultados frente a los umbrales previamente definidos. Documente los fallos y las medidas correctoras adoptadas. Si no se cumplen los umbrales, vuelva al paso 6 antes de continuar.
9. Emita el juicio de aceptabilidad del riesgo residual. Para cada peligro y en su conjunto: documente el razonamiento que conduce a la conclusión de que el riesgo residual es aceptable. Esta es la puerta formal antes de la introducción en el mercado.
10. Registre todo en la documentación técnica. El Anexo IV, sección 2, exige que la descripción y las conclusiones del SGR queden registradas. Este es el documento que inspeccionará una autoridad de vigilancia del mercado.
11. Establezca el ciclo de vigilancia y revisión. Antes del lanzamiento, defina la cadencia y el método de la vigilancia poscomercialización (Artículo 72), las condiciones desencadenantes de una revisión ad hoc del SGR (nuevo modo de fallo, deriva significativa del rendimiento, orientación reglamentaria, notificación de incidente) y el proceso de actualización del SGR cuando una revisión revele nuevos riesgos.
12. Mantenga a lo largo del ciclo de vida. El SGR no se cierra cuando el producto se envía. Toda actualización sustantiva del sistema — nuevos datos de entrenamiento, finalidad prevista modificada, nuevo contexto de despliegue — desencadena una revisión proporcionada del SGR.
El Artículo 9 y la evaluación de la conformidad (Artículo 43)
El SGR es un requisito previo para la evaluación de la conformidad del Artículo 43 — el proceso formal por el cual un proveedor demuestra, antes de la introducción en el mercado, que el sistema de alto riesgo cumple todos los requisitos. Un proveedor no puede completar la documentación técnica del Anexo IV exigida para la evaluación de la conformidad sin un SGR en funcionamiento, porque la documentación debe incluir la descripción, las conclusiones y el juicio sobre el riesgo residual del SGR.
Para la mayoría de los sistemas del Anexo III, la evaluación de la conformidad adopta la forma de una revisión interna con arreglo al módulo A (el proveedor evalúa su propio sistema frente a los requisitos). Para los sistemas de identificación biométrica y algunas otras categorías, debe intervenir un organismo notificado tercero. En cualquier caso, el expediente del SGR es una prueba central.
Cómo ayuda Confir
Construir un SGR del Artículo 9 es principalmente un ejercicio de juicio, no un problema de software. Pero estructurar el ejercicio — y garantizar que no se omita nada — es donde las herramientas aportan valor.
El ámbito de cumplimiento AIGM de Confir (Gobernanza y Vigilancia Poscomercialización) se corresponde directamente con el Artículo 9 y el Artículo 72. Cuando usted registra un sistema de IA de alto riesgo y recorre la evaluación de Confir, el ámbito AIGM genera un registro de riesgos basado en reglas que asigna los riesgos identificados a Artículos concretos, hace seguimiento de las medidas de mitigación frente a cada riesgo y señala los elementos de riesgo residual pendientes. Dado que el motor es determinista y basado en reglas — no un LLM — las mismas entradas del sistema producen la misma salida estructurada cada vez, que es exactamente lo que requiere un registro de cumplimiento defendible ante una auditoría.
Confir también genera el paquete de documentación técnica del Artículo 11 / Anexo IV, incorporando las conclusiones del SGR, y la EIDF del Artículo 27 para los responsables del despliegue que la necesiten. Sin consultores.
Sanciones y el calendario de cumplimiento
El techo sancionador por incumplimiento del Artículo 9 (y de las demás obligaciones de alto riesgo) es de 15 millones de euros o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor (Artículo 99). Para las empresas y las empresas emergentes, la multa se limita a la cifra que sea menor — una disposición de proporcionalidad del Artículo 99, apartado 6, que reduce, pero no elimina, la exposición de los proveedores más pequeños.
Los plazos de cumplimiento en virtud del Ómnibus Digital:
- 2 de diciembre de 2027 — sistemas de IA de alto riesgo autónomos (Anexo III: contratación, crédito, biometría, garantía del cumplimiento del Derecho, etc.).
- 2 de agosto de 2028 — sistemas de IA de alto riesgo que son componentes de seguridad de productos cubiertos por el Derecho de seguridad de los productos del Anexo I.
Dieciocho meses parecen cómodos desde la distancia. No lo son, una vez que se tiene en cuenta el tiempo necesario para completar la documentación de gobernanza de datos, ejecutar las pruebas del Artículo 9 frente a umbrales previamente definidos, redactar el expediente técnico del Anexo IV y realizar la evaluación de la conformidad. Los proveedores que tendrán dificultades a finales de 2027 son los que tratan el plazo como la fecha de inicio.
Preguntas frecuentes
P: ¿Quién debe cumplir el Artículo 9 — el proveedor o el responsable del despliegue? Ambos tienen obligaciones, pero la estructura difiere. El proveedor (Artículo 16) construye y mantiene el SGR a lo largo de todo el ciclo de vida, desde el desarrollo hasta la vigilancia poscomercialización. El responsable del despliegue (Artículo 26) es responsable de los riesgos que surgen específicamente de su contexto de despliegue — en particular, los riesgos que el proveedor no podía anticipar sin saber cómo y dónde se utilizaría el sistema. Un responsable del despliegue que se da cuenta de que está operando el sistema de una manera que crea nuevos riesgos debe abordarlos, incluso informando al proveedor.
P: ¿Se aplica el Artículo 9 antes de que un sistema se introduzca en el mercado? Sí. El SGR debe estar establecido y documentado antes de la introducción en el mercado. El proceso del Artículo 9 comienza en el diseño del producto. La evaluación de la conformidad del Artículo 43, para la que el SGR es un requisito previo, también debe completarse antes de que el sistema se introduzca en el mercado o se ponga en servicio.
P: ¿Qué cuenta como riesgo residual aceptable en virtud del Artículo 9? El Reglamento no aporta una fórmula. El proveedor debe documentar un juicio razonado de que — dada la finalidad prevista, el contexto de despliegue, el estado de la técnica en la reducción de riesgos y las medidas de mitigación disponibles — el riesgo restante es proporcionado al beneficio y no excede de lo que una persona razonable consideraría tolerable en esa aplicación. Las autoridades de vigilancia del mercado evaluarán si ese juicio es defendible, no si se alcanzó por un método concreto.
P: ¿Cómo interactúa el Artículo 9 con la ISO/IEC 42001? La ISO/IEC 42001 es una norma de sistema de gestión de la IA. Proporciona una orientación estructural útil para construir un proceso de gestión de riesgos, y la alineación con ella puede acelerar la construcción de un SGR del Artículo 9. Pero la certificación ISO/IEC 42001 no equivale al cumplimiento de la Ley de IA de la UE. El SGR del Artículo 9 tiene requisitos legales concretos — en particular los cuatro pasos del Artículo 9, apartado 2, el juicio de aceptabilidad del riesgo residual y el bucle de vigilancia poscomercialización — que deben cumplirse en sus propios términos.
P: ¿Debe el SGR del Artículo 9 abordar los riesgos de ciberseguridad? Sí. El Artículo 15 exige que los sistemas de IA de alto riesgo sean resilientes frente a los intentos de terceros no autorizados de alterar su comportamiento, explotar sus vulnerabilidades o manipular sus resultados. Los riesgos abordados en el Artículo 15 — incluidos los ataques de adversariedad y el envenenamiento de datos — deben identificarse, estimarse y mitigarse a través del proceso del Artículo 9. Una evaluación de riesgos que cubre únicamente la exactitud y el sesgo, pero ignora la robustez frente a la adversariedad, es incompleta.
P: ¿Qué le sucede al SGR si el sistema se modifica sustancialmente? El Artículo 3, apartado 23, define una modificación sustancial como un cambio que afecta al cumplimiento o al rendimiento de forma material — reentrenamiento con nuevos datos, cambio de la arquitectura del modelo, ampliación de la finalidad prevista o despliegue en un nuevo contexto. Una modificación sustancial desencadena una revisión proporcionada de todo el SGR, pruebas actualizadas frente a métricas previamente definidas y, si la evaluación de la conformidad se basó en la versión anterior, una evaluación de la conformidad nueva o actualizada en virtud del Artículo 43.
P: ¿Cuál es la relación entre el Artículo 9 y la evaluación de impacto relativa a los derechos fundamentales (EIDF) del Artículo 27? La EIDF del Artículo 27 es una obligación independiente, impuesta a determinados responsables del despliegue (los que operan IA de alto riesgo en ámbitos como el empleo, la garantía del cumplimiento del Derecho, la migración, la educación y los servicios esenciales). Recurre a las conclusiones de gestión de riesgos del proveedor — en particular al trabajo de identificación y mitigación de riesgos — pero es distinta: la EIDF se centra específicamente en los impactos sobre los derechos fundamentales en el contexto operativo del responsable del despliegue, y debe ser preparada por el responsable del despliegue con independencia del SGR del proveedor.
Guías relacionadas
- niveles de clasificación de riesgo
- La Ley de IA de la UE explicada de forma sencilla: guía de cumplimiento de 2026
- Software de gestión de riesgos de la IA para el cumplimiento de la Ley de IA de la UE
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 →