Estrategias de mitigación de riesgos de IA con arreglo a la Ley de IA de la UE
Cómo el artículo 9, apartado 5, estructura la mitigación de riesgos de IA: eliminar por diseño, controlar y, después, divulgar. Asigna los riesgos de sesgo, deriva y seguridad a controles concretos de la Ley.
El artículo 9, apartado 5, del Reglamento (UE) 2024/1689 establece un orden de prioridad explícito para la mitigación: primero, eliminar o reducir el riesgo mediante el diseño en la medida en que sea técnicamente viable; segundo, aplicar medidas adecuadas de mitigación y control cuando el riesgo persista; tercero, facilitar información con arreglo al artículo 13 y garantizar que los responsables del despliegue dispongan de la alfabetización y la capacidad de supervisión que exigen los artículos 4 y 14. Lo que sigue asigna cada nivel a los controles técnicos y organizativos que exige la Ley, los vincula a las cinco categorías de riesgo de IA más habituales y explica cuándo el riesgo residual es aceptable y cómo documentar ese juicio.
La jerarquía de mitigación del artículo 9, apartado 5
El artículo 9, apartado 5, se inspira directamente en el Derecho consolidado de seguridad de los productos: el riesgo se diseña primero para eliminarlo, luego se controla y, por último, se divulga. El orden importa: no puedes sustituir más advertencias por menos ingeniería.
Nivel 1 — eliminar o reducir mediante el diseño. En la fase de diseño y desarrollo, pregúntate si el riesgo puede eliminarse o reducirse por medios técnicos: prescindir de una variable de entrada sensible, restringir los resultados a un conjunto acotado o limitar el uso previsto para excluir escenarios de alto perjuicio. «En la medida en que sea técnicamente viable» no es una cláusula de escape. Optar por no eliminar un riesgo exige una justificación documentada.
Nivel 2 — medidas adecuadas de mitigación y control. Cuando el riesgo persiste, aplica controles técnicos —gobernanza de la calidad de los datos (artículo 10), exactitud, robustez y ciberseguridad (artículo 15), conservación de registros (artículo 12)— junto con controles organizativos: supervisión humana (artículo 14), un sistema de gestión de la calidad (artículo 17), vigilancia poscomercialización (artículo 72) y notificación de incidentes (artículo 73).
Nivel 3 — información y formación. El riesgo residual que sobreviva a los dos primeros niveles debe comunicarse a los responsables del despliegue a través de las instrucciones de uso (artículo 13). Los responsables del despliegue deben garantizar que el personal tenga suficiente alfabetización en materia de IA (artículo 4) y que la supervisión humana se ejerza realmente (artículo 14). Emitir documentación sin confirmar que los responsables del despliegue pueden actuar con base en ella no cumple el Nivel 3.
Riesgo residual: aceptabilidad y documentación
El artículo 9, apartado 4, establece que el riesgo residual debe ser coherente con «el estado actual de la técnica generalmente reconocido». Se trata de un estándar comparativo, no de un umbral de perjuicio cero. Un modelo de calificación crediticia en una entidad regional tendrá cierta tasa de rechazos falsos; la cuestión es si la tasa, y la distribución de errores entre grupos demográficos, se sitúa dentro del rango alcanzable por un proveedor competente que aplique las mejores prácticas actuales.
La aceptabilidad debe valorarse y documentarse. La documentación técnica del artículo 11 debe incluir los niveles de riesgo residual, la justificación para aceptarlos y los desencadenantes de seguimiento que reabrirían la evaluación. Un juicio formulado en el lanzamiento y nunca revisado no cumple el requisito de proceso continuo del artículo 9, apartado 1. Prueba práctica: si te incomodara explicar el nivel de riesgo residual a la autoridad de vigilancia del mercado, la documentación no es adecuada.
Controles técnicos
Calidad de los datos (artículo 10)
El sesgo, la fuga de privacidad y la deriva distribucional tienen a menudo su origen en los datos de entrenamiento. El artículo 10, apartado 3, exige que los conjuntos de datos de entrenamiento, validación y prueba sean pertinentes, representativos, estén libres de errores y sean completos para su finalidad prevista. Audita las fuentes de datos en busca de sesgos históricos antes del entrenamiento; documenta las lagunas de cobertura demográfica; define cohortes de validación que reflejen la población de despliegue; mantén un registro de linaje de datos que sobreviva a los cambios de personal. La calidad de los datos es una mitigación directa del sesgo, la privacidad y la deriva: tres de las cinco categorías de riesgo de la tabla siguiente.
Exactitud, robustez y ciberseguridad (artículo 15)
El artículo 15 exige que los sistemas de alto riesgo alcancen una exactitud adecuada, resiliencia frente a errores e incoherencias (robustez) y protección frente a la manipulación adversaria (ciberseguridad). En concreto: prueba el rendimiento entre subpoblaciones demográficas antes del despliegue; somete el modelo a ejercicios de red team frente a entradas adversarias e inyección de instrucciones cuando proceda; implementa el versionado de modelos para poder revertir un modelo comprometido o derivado; supervisa los vectores de envenenamiento de datos en el momento de la inferencia.
Las pruebas del artículo 15 no son una puerta de control puntual. Los resultados se reincorporan al ciclo continuo del artículo 9.
Conservación de registros y trazabilidad (artículo 12)
El artículo 12 exige el registro automático de los eventos pertinentes para detectar incidentes graves y posibilitar la vigilancia poscomercialización: los períodos de referencia de cada uso, la base de datos de referencia utilizada para la verificación (sistemas biométricos), los datos de entrada que dieron lugar a un resultado y las personas físicas implicadas. Los proveedores conservan bajo su control los registros generados automáticamente durante al menos seis meses (artículo 19); los responsables del despliegue conservan sus propios registros durante al menos seis meses (artículo 26).
La conservación de registros es a la vez un elemento disuasorio frente al uso indebido y la base probatoria de la respuesta a incidentes del artículo 73.
Controles organizativos
Supervisión humana (artículo 14)
El artículo 14 no es un requisito genérico de «mantener un humano en el bucle». Especifica cinco capacidades que deben tener las personas físicas encargadas de la supervisión: comprender las capacidades y limitaciones del sistema; vigilar el funcionamiento en busca de anomalías; interpretar correctamente los resultados; intervenir o anular; y decidir no utilizar el sistema en una situación determinada.
Esas capacidades exigen un trabajo de diseño activo: interfaces de explicabilidad, puntuaciones de confianza, mecanismos de anulación, protocolos de traspaso claros. Si un responsable del despliegue no puede ejercer de forma realista la supervisión porque el sistema es demasiado opaco o el flujo de trabajo demasiado rápido, el diseño del sistema no cumple.
Sistema de gestión de la calidad (artículo 17)
El artículo 17 exige un sistema documentado de gestión de la calidad que abarque todas las fases, desde el diseño hasta la vigilancia poscomercialización. Los elementos mínimos incluyen: una estrategia de cumplimiento normativo; técnicas de control del diseño; pruebas y exámenes antes de la puesta en circulación; procedimientos de vigilancia poscomercialización; obligaciones de notificación de incidentes; y asignaciones de responsabilidad.
Para una empresa de 40 personas, esto no es un programa ISO 9001 redactado por consultores. Son procedimientos documentados, control de versiones, una titularidad clara y pruebas de uso efectivo: el registro que sobreviviría a una inspección de vigilancia del mercado.
Vigilancia poscomercialización (artículo 72)
El artículo 72 exige que los proveedores recopilen y revisen datos de rendimiento de los sistemas desplegados a lo largo de toda su vida útil. El plan de vigilancia poscomercialización —parte de la documentación técnica— debe especificar las métricas, las fuentes de datos, los intervalos de revisión y los umbrales de escalado. Define qué aspecto tiene lo «normal» (banda de exactitud, métricas de equidad), instrumenta el despliegue para captarlo, configura alertas para las desviaciones y programa revisiones periódicas.
La vigilancia poscomercialización cierra el bucle del artículo 9: los riesgos detectados tras el despliegue se reincorporan a la evaluación de riesgos y pueden activar nuevas medidas de mitigación o, en casos graves, la retirada del mercado.
Respuesta a incidentes (artículo 73)
El artículo 73 exige que los proveedores notifiquen los incidentes graves a la autoridad de vigilancia del mercado del Estado miembro donde se produjo el incidente. Los plazos son estrictos: 15 días desde que se tiene conocimiento, con carácter general (artículo 73, apartado 2); 2 días en caso de infracción generalizada o de perturbación grave e irreversible de infraestructuras críticas (artículo 73, apartado 3); 10 días cuando haya fallecido una persona (artículo 73, apartado 4). Se admite un informe inicial incompleto, que se completa después.
Esto es una cuestión de plazo de cumplimiento. Un proveedor que no haya definido qué constituye un incidente grave, quién lo clasifica y cómo llega al equipo de notificación incumplirá estos plazos.
Cinco riesgos de IA habituales asignados a controles
| Riesgo | Causas raíz | Controles técnicos | Controles organizativos |
|---|---|---|---|
| Sesgo / discriminación | Datos de entrenamiento no representativos; variables proxy; patrones históricos | Calidad de los datos del art. 10; pruebas de exactitud por subpoblación (art. 15) | Supervisión del art. 14 con derechos de anulación; puerta de control de revisión de equidad del SGC del art. 17 |
| Alucinación / falta de fiabilidad | Mala calibración de la confianza del modelo; entradas fuera de distribución | Pruebas de exactitud y robustez del art. 15; salidas con puntuación de confianza | Requisito de verificación humana del art. 14; registro de los resultados para auditoría del art. 12 |
| Ciberseguridad / ataque adversario | Inversión del modelo; inyección de instrucciones; envenenamiento de datos | Robustez adversaria del art. 15; versionado y reversión de modelos | Revisión de seguridad en el SGC del art. 17; notificación de incidentes del art. 73 por brechas |
| Deriva del modelo | Cambio de distribución entre entrenamiento y producción; deriva conceptual a lo largo del tiempo | Seguimiento continuo del rendimiento del art. 15; conservación de registros del art. 12 | Plan de vigilancia poscomercialización del art. 72; reevaluación continua del art. 9 |
| Privacidad / reidentificación | Entrenamiento con datos personales; ataques de inferencia; fuga de salidas | Minimización y gobernanza de datos del art. 10; diseño con preservación de la privacidad del art. 15 | Controles de acceso del art. 14; EIPD del artículo 35 del RGPD cuando proceda |
La jerarquía del artículo 9, apartado 5, se aplica a cada fila: pregúntate primero si el riesgo puede eliminarse mediante el diseño (p. ej., eliminar la variable proxy; entrenar con datos sintéticos), luego qué controles lo reducen y, después, qué exposición residual debe divulgarse.
Cómo ayuda Confir
El registro de riesgos de Confir utiliza una lógica determinista y basada en reglas para vincular cada riesgo identificado a los controles concretos que exige la Ley. Registra un riesgo en un sistema de cribado de empleo y el registro lo asigna al nivel de mitigación del artículo 9, apartado 5, señala los controles aplicables de los artículos 10, 12, 14, 15 o 72 y hace un seguimiento de si cada uno se ha documentado. Las mismas respuestas de admisión producen la misma asignación cada vez: reproducible, explicable, defendible ante auditoría. El módulo de evaluación AIGM te indica que registres el juicio de aceptabilidad del riesgo residual y el desencadenante de seguimiento que lo reabriría.
Preguntas frecuentes
¿Qué significa «en la medida en que sea técnicamente viable» en el artículo 9, apartado 5?
No es un permiso general para saltarse la mitigación a nivel de diseño. Un proveedor que opte por aceptar un riesgo en el Nivel 1 en lugar de eliminarlo mediante el diseño debe documentar por qué la eliminación o la reducción no era técnicamente viable: limitaciones concretas, compensaciones con el rendimiento del sistema o el estado actual de la técnica en el ámbito. Los reguladores y los organismos notificados examinarán estas justificaciones; una mera afirmación de inviabilidad no se sostendrá.
¿Se aplica el artículo 9 también a los responsables del despliegue, además de a los proveedores?
El artículo 9 se aplica a los proveedores (artículo 16). Los responsables del despliegue operan con arreglo al artículo 26: seguir las instrucciones de uso del proveedor, garantizar la supervisión humana, vigilar el rendimiento y notificar los incidentes al proveedor y, cuando proceda, a la autoridad. Un responsable del despliegue que modifique sustancialmente un sistema o lo reutilice para otra finalidad se convierte en proveedor con arreglo al artículo 25 y hereda la obligación completa del artículo 9.
¿Cuándo es aceptable el riesgo residual con arreglo al artículo 9, apartado 4?
Cuando es coherente con el estado actual de la técnica generalmente reconocido y se ha documentado con un juicio razonado. La aceptabilidad no se autodeclara; es una evaluación comparativa frente a lo que un proveedor competente que aplique los métodos actuales podría lograr. El juicio debe figurar en la documentación técnica, ser accesible para la autoridad de vigilancia del mercado y revisarse cuando los datos de la vigilancia poscomercialización indiquen un cambio material.
¿Cómo funcionan los plazos de notificación de incidentes del artículo 73?
El plazo general es de 15 días desde que se tiene conocimiento de un incidente grave (artículo 73, apartado 2). Cuando se produce una infracción generalizada o una perturbación grave e irreversible de infraestructuras críticas, el plazo es de 2 días (artículo 73, apartado 3). Cuando ha fallecido una persona, es de 10 días (artículo 73, apartado 4). Se admite un informe inicial incompleto con arreglo al artículo 73, apartado 5, que se completa una vez disponible más información. Los proveedores deben incorporar la decisión de clasificación y escalado en su SGC antes de necesitarla.
¿Cuál es la exposición sancionadora por no mantener un sistema de gestión de riesgos del artículo 9?
El incumplimiento de las obligaciones de alto riesgo se rige por el artículo 99, apartado 4: hasta 15 000 000 EUR o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Las empresas que cumplen los requisitos de pyme o empresa emergente se benefician del artículo 99, apartado 6, que limita la multa al menor de los dos importes, el porcentaje o la cantidad fija. Las sanciones del artículo 99 se aplican desde el 2 de agosto de 2025: el reloj de la ejecución ya está en marcha.
¿Las obligaciones de alto riesgo se aplican desde agosto de 2026?
No. En virtud del Ómnibus Digital acordado en mayo de 2026, la aplicación de las obligaciones de alto riesgo se ha aplazado. Los sistemas de IA de alto riesgo autónomos de las categorías del Anexo III deben cumplir desde el 2 de diciembre de 2027. Los sistemas de IA de alto riesgo que son componentes de seguridad de productos cubiertos por el Derecho de la UE en materia de productos (Anexo I) deben cumplir desde el 2 de agosto de 2028. La fecha original del 2 de agosto de 2026 se ha aplazado. La ventana de cumplimiento es más amplia, pero solo la documentación tarda meses en reunirse.
¿Cuál es la diferencia entre la gestión de riesgos del artículo 9 y una EIPD del RGPD?
Una Evaluación de Impacto relativa a la Protección de Datos del RGPD (artículo 35 del RGPD) aborda los riesgos derivados del tratamiento de datos. La gestión de riesgos del artículo 9 cubre los riesgos para la salud, la seguridad y los derechos fundamentales derivados del comportamiento del sistema —sesgo algorítmico, fallos de robustez, exactitud de las decisiones—, que van mucho más allá del tratamiento de datos. Ambas se solapan cuando el sistema de IA trata datos personales; un plan del artículo 9 bien estructurado puede compartir entradas con una EIPD, pero responden a marcos distintos y no pueden sustituirse mutuamente.
Guías relacionadas
- requisitos del sistema de gestión de riesgos del Artículo 9
- exactitud, robustez y ciberseguridad del Artículo 15
- criterios de clasificación de IA de alto riesgo del Artículo 6
- marco de los niveles de clasificación de riesgo
- software de implementación de la gestión de riesgos de IA
- herramienta de árbol de decisión de clasificación de riesgo
- lista de comprobación de 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 →