Análisis jurídico completo para empresas y administraciones públicas. La guía oficial de la AESIA más el criterio de iusia para el asesoramiento práctico.
El artículo 9 del AI Act establece la gestión de riesgos como el proceso que vertebra el cumplimiento de todos los requisitos técnicos de los sistemas de alto riesgo. No es un documento que se elabora una vez antes del lanzamiento del sistema y se archiva — es un proceso continuo que debe ejecutarse durante todo el ciclo de vida del sistema. Esta característica es la que más diferencia la gestión de riesgos del AI Act de instrumentos similares en otras normativas.
La Guía 5, con 58 páginas, es la más extensa de las guías técnicas del paquete AESIA. Su extensión refleja la complejidad del proceso y la cantidad de decisiones que el proveedor debe tomar al diseñarlo e implementarlo. La guía no se limita a reproducir el texto del artículo 9 — ofrece criterios prácticos para cada decisión, ejemplos de aplicación en distintos sectores, y orientación sobre cómo documentar el proceso de forma que sea verificable por las autoridades supervisoras.
La gestión de riesgos del art. 9 no sustituye a la Evaluación de Impacto en Protección de Datos (EIPD) del artículo 35 del RGPD cuando el sistema trata datos personales. Ambos procesos son obligatorios y deben realizarse de forma coordinada. La EIPD analiza los riesgos para los derechos de los interesados en materia de protección de datos. La gestión de riesgos del art. 9 analiza los riesgos para la salud, la seguridad y los derechos fundamentales en general — un ámbito más amplio que incluye, pero no se limita a, la protección de datos.
La guía estructura el proceso de gestión de riesgos del art. 9 en cuatro fases secuenciales pero que en la práctica se superponen y retroalimentan. La primera es la identificación de riesgos: el análisis sistemático de todos los riesgos razonablemente previsibles que el sistema puede generar para las personas físicas que interactúen con él, que sean afectadas por sus outputs, o que se vean afectadas por su funcionamiento anómalo.
La segunda fase es el análisis y evaluación de los riesgos identificados: para cada riesgo, determinar su probabilidad de materialización y la gravedad de su impacto potencial. La guía proporciona una metodología de evaluación cualitativa y cuantitativa, con matrices de priorización que permiten ordenar los riesgos por nivel de urgencia de mitigación.
La tercera fase es el diseño e implementación de medidas de mitigación: para cada riesgo evaluado como inaceptable o significativo, establecer medidas técnicas y organizativas que reduzcan la probabilidad de materialización o la gravedad del impacto. Las medidas de mitigación deben ser proporcionales al nivel de riesgo — no se exige la eliminación de cualquier riesgo hipotético, sino la reducción de los riesgos a un nivel razonablemente aceptable.
La cuarta fase es la verificación y documentación: comprobar que las medidas de mitigación son efectivas mediante pruebas y evaluaciones específicas, y documentar todo el proceso — los riesgos identificados, la evaluación realizada, las medidas adoptadas y los resultados de las verificaciones. Esta documentación es parte de la documentación técnica del Anexo IV.
La guía de la AESIA distingue tres tipos de riesgo que el proceso de gestión del art. 9 debe identificar y analizar. El primero son los riesgos técnicos: los riesgos derivados de las características del propio sistema de IA, como los errores del modelo (falsos positivos y falsos negativos), los sesgos algorítmicos, los fallos de ciberseguridad, la degradación del rendimiento con el tiempo, y los comportamientos inesperados frente a inputs fuera de la distribución de entrenamiento.
El segundo tipo son los riesgos de uso: los riesgos que emergen de cómo el sistema es usado en la práctica, incluyendo el uso incorrecto por desplegadores que no siguen las instrucciones del proveedor, el uso indebido deliberado por personas malintencionadas, y el uso en contextos no previstos en el diseño original del sistema. La guía destaca que el proveedor debe prever no solo el uso previsto del sistema sino también el uso razonablemente previsible, lo que incluye ciertos usos incorrectos.
El tercer tipo son los riesgos para derechos fundamentales: los riesgos que el sistema puede generar para derechos como la no discriminación, la privacidad, la dignidad humana, la autonomía individual, o el acceso a la justicia. Este tipo de riesgos es el más difícil de cuantificar porque sus consecuencias son frecuentemente indirectas y a largo plazo, pero es también el más relevante para las autoridades supervisoras y para la reputación de la organización.
Para cada riesgo significativo identificado, el proveedor debe establecer medidas de mitigación proporcionales. La guía clasifica las medidas en dos categorías principales: técnicas y organizativas. Las medidas técnicas actúan directamente sobre el sistema para reducir la probabilidad de que el riesgo se materialice. Las medidas organizativas actúan sobre los procesos, las personas y los procedimientos para gestionar el riesgo aunque el sistema técnicamente pueda fallare.
Entre las medidas técnicas más relevantes, la guía destaca los sistemas de umbrales de confianza: cuando la puntuación de confianza del modelo para un output específico está por debajo de un umbral establecido, el sistema no presenta ese output como definitivo sino que lo señala como incierto y activa automáticamente la revisión humana. Esta medida técnica es especialmente eficaz para reducir el riesgo de errores con consecuencias significativas en sistemas de clasificación o predicción.
Otra medida técnica relevante son los mecanismos de explicabilidad: funcionalidades que permiten al usuario o al supervisor comprender por qué el sistema ha generado un determinado output. En sistemas de scoring crediticio o de selección de personal, la explicabilidad es también un requisito del artículo 86 del AI Act, que reconoce el derecho de las personas afectadas a obtener una explicación de las decisiones tomadas con el apoyo del sistema.
Entre las medidas organizativas, la más importante es la supervisión humana efectiva del artículo 14: establecer procesos que garanticen que personas con la competencia adecuada revisan los outputs del sistema antes de que produzcan efectos sobre personas físicas, y que tienen la capacidad y la autoridad para modificar o anular esos outputs. La guía advierte que la supervisión humana no puede ser puramente formal — el proceso debe estar diseñado para que la revisión humana sea real y efectiva, no una mera ratificación automática.
El art. 9.4 del AI Act establece explícitamente que el proceso de gestión de riesgos no exige la eliminación de todos los riesgos. Solo se exige eliminar los riesgos que pueden eliminarse razonablemente y reducir los que no pueden eliminarse a un nivel razonablemente aceptable teniendo en cuenta el propósito del sistema y el estado de la técnica.
Este concepto de riesgo residual aceptable es fundamental para hacer el proceso de gestión de riesgos operativo en la práctica. Sin él, cualquier riesgo hipotético podría bloquear indefinidamente el desarrollo de un sistema. La guía proporciona criterios para determinar cuándo un riesgo residual es razonablemente aceptable: la probabilidad de materialización es baja, el impacto en caso de materialización es limitado o reversible, no existe tecnología disponible que lo reduzca significativamente sin comprometer la funcionalidad esencial del sistema, y el beneficio que el sistema aporta a quienes lo usan o a la sociedad supera el riesgo residual.
Los riesgos residuales identificados en el proceso de gestión de riesgos deben documentarse y, en su caso, comunicarse al desplegador a través de las instrucciones de uso del artículo 13. El desplegador debe conocer los riesgos residuales del sistema para poder establecer las medidas organizativas de supervisión humana adecuadas.
Cuando el sistema de IA trata datos personales — lo que ocurre en la gran mayoría de sistemas de alto riesgo — el proceso de gestión de riesgos del art. 9 del AI Act debe coordinarse con la EIPD del art. 35 del RGPD. La guía de la AESIA recomienda realizar ambos procesos de forma integrada, con un único equipo y un único documento que cubra los requisitos de ambas normas, para evitar duplicidades y garantizar que los análisis son coherentes entre sí.
La principal diferencia entre los dos procesos es el alcance del análisis de riesgos. La EIPD del RGPD se centra en los riesgos para los derechos de los interesados en materia de protección de datos — privacidad, control sobre los propios datos, no discriminación basada en el tratamiento de datos. La gestión de riesgos del art. 9 AI Act tiene un alcance más amplio: salud física, seguridad, derechos fundamentales en general, incluyendo derechos que no tienen que ver con la protección de datos como el acceso al empleo, el acceso al crédito o la presunción de inocencia.
La documentación del proceso de gestión de riesgos es parte de la documentación técnica obligatoria del Anexo IV del AI Act. Debe incluir: la descripción del proceso de gestión de riesgos adoptado, la lista de todos los riesgos identificados con su evaluación de probabilidad e impacto, las medidas de mitigación establecidas para cada riesgo significativo, los resultados de las verificaciones de la efectividad de las medidas, y la lista de riesgos residuales con la justificación de su aceptabilidad.
La guía recomienda estructurar esta documentación en forma de registro de riesgos — una tabla o base de datos que liste cada riesgo identificado con todos los atributos relevantes — y complementarla con los informes de las evaluaciones periódicas. Este registro de riesgos debe actualizarse cada vez que el proceso iterativo identifica nuevos riesgos o modifica la evaluación de riesgos existentes.
Una pregunta recurrente en el asesoramiento sobre AI Act es qué ocurre con los sistemas de alto riesgo que ya estaban en producción cuando el Reglamento entró en vigor. La respuesta del Reglamento es más matizada de lo que suele pensarse. Conforme al artículo 111.2, los sistemas de alto riesgo introducidos en el mercado o puestos en servicio antes de la fecha de aplicación —el 2 de diciembre de 2027 para el Anexo III tras el Ómnibus Digital— solo quedan sujetos al Reglamento si a partir de entonces sufren cambios significativos en su diseño; los destinados a ser utilizados por autoridades públicas deben adaptarse en todo caso antes del 2 de agosto de 2030. En la práctica, casi cualquier reentrenamiento o actualización relevante del modelo puede constituir un cambio significativo.
Por ello, la prudencia aconseja que las organizaciones con sistemas de IA ya desplegados realicen el proceso de gestión de riesgos del art. 9 sobre esos sistemas existentes — identificar los riesgos que el sistema presenta, evaluar su probabilidad e impacto, establecer medidas de mitigación y documentar todo el proceso — antes del 2 de diciembre de 2027. El proceso de gestión de riesgos de un sistema ya en producción es, si cabe, más urgente que el de un sistema en desarrollo, porque no hay posibilidad de corregir el diseño del sistema para mitigar riesgos detectados: las medidas de mitigación deben ser necesariamente organizativas o de configuración del sistema, no de rediseño fundamental.
La guía sugiere que para los sistemas ya desplegados, el proceso de gestión de riesgos comience con una evaluación del impacto que el sistema ha tenido en los usuarios y afectados hasta la fecha: ¿ha habido reclamaciones relacionadas con los outputs del sistema? ¿Ha habido incidentes o anomalías detectadas? ¿Existen datos de rendimiento del sistema en producción que permitan inferir el nivel de riesgo real? Esta información empírica del sistema en funcionamiento puede ser más valiosa para la gestión de riesgos que las evaluaciones teóricas realizadas antes del despliegue.
El proceso de gestión de riesgos del art. 9 tiene también relevancia desde la perspectiva de la responsabilidad civil por daños causados por sistemas de IA. La Directiva de Responsabilidad por Productos (DRP, Directiva 2024/2853), publicada en octubre de 2024, establece un régimen de responsabilidad objetiva del fabricante por los daños causados por productos defectuosos, y ha ampliado explícitamente su ámbito para cubrir el software, incluyendo los sistemas de IA.
Un sistema de IA que causa daños a una persona puede ser considerado un "producto defectuoso" bajo la DRP si no ofrece la seguridad que cabe legítimamente esperar. El proceso de gestión de riesgos del art. 9 del AI Act, correctamente documentado, puede servir como evidencia de que el proveedor realizó una evaluación razonable de los riesgos del sistema antes de su comercialización y tomó las medidas de mitigación apropiadas. En ausencia de esta documentación, el proveedor tiene más dificultades para demostrar que el sistema no era defectuoso en el momento de su comercialización.
La interacción entre el AI Act y la DRP es especialmente relevante para los juristas que asesoran a empresas en el diseño de sistemas de alto riesgo: no se trata solo de cumplir con el regulador, sino de construir la documentación que puede ser crucial en futuras reclamaciones de responsabilidad civil por daños. La gestión de riesgos bien documentada es la primera línea de defensa en esos procesos.
El ecosistema de herramientas para apoyar la gestión de riesgos de IA está creciendo rápidamente. La AESIA ha indicado que publicará plantillas y metodologías de referencia para el proceso de gestión de riesgos del art. 9, complementando los checklists de la Guía 16. La Oficina Europea de IA está desarrollando herramientas específicas para la evaluación de riesgos de los modelos GPAI. Y varios organismos de normalización están elaborando normas técnicas que especifican metodologías de gestión de riesgos para sistemas de IA.
La norma ISO/IEC 23894:2023 sobre gestión de riesgos de IA es una referencia útil como complemento al proceso de gestión de riesgos del art. 9. Aunque no es una norma armonizada del AI Act — es decir, no genera presunción de conformidad — proporciona una metodología estructurada y reconocida internacionalmente que puede adoptarse como base del proceso de gestión de riesgos del proveedor y complementarse con los requisitos específicos del art. 9.
Una pregunta recurrente en el asesoramiento sobre AI Act es qué ocurre con los sistemas de alto riesgo que ya estaban en producción cuando el Reglamento entró en vigor. La respuesta del Reglamento es más matizada de lo que suele pensarse. Conforme al artículo 111.2, los sistemas de alto riesgo introducidos en el mercado o puestos en servicio antes de la fecha de aplicación —el 2 de diciembre de 2027 para el Anexo III tras el Ómnibus Digital— solo quedan sujetos al Reglamento si a partir de entonces sufren cambios significativos en su diseño; los destinados a ser utilizados por autoridades públicas deben adaptarse en todo caso antes del 2 de agosto de 2030. En la práctica, casi cualquier reentrenamiento o actualización relevante del modelo puede constituir un cambio significativo.
Por ello, la prudencia aconseja que las organizaciones con sistemas de IA ya desplegados realicen el proceso de gestión de riesgos del art. 9 sobre esos sistemas existentes — identificar los riesgos que el sistema presenta, evaluar su probabilidad e impacto, establecer medidas de mitigación y documentar todo el proceso — antes del 2 de diciembre de 2027. El proceso de gestión de riesgos de un sistema ya en producción es, si cabe, más urgente que el de un sistema en desarrollo, porque no hay posibilidad de corregir el diseño del sistema para mitigar riesgos detectados: las medidas de mitigación deben ser necesariamente organizativas o de configuración del sistema, no de rediseño fundamental.
La guía sugiere que para los sistemas ya desplegados, el proceso de gestión de riesgos comience con una evaluación del impacto que el sistema ha tenido en los usuarios y afectados hasta la fecha: ¿ha habido reclamaciones relacionadas con los outputs del sistema? ¿Ha habido incidentes o anomalías detectadas? ¿Existen datos de rendimiento del sistema en producción que permitan inferir el nivel de riesgo real? Esta información empírica del sistema en funcionamiento puede ser más valiosa para la gestión de riesgos que las evaluaciones teóricas realizadas antes del despliegue.
El proceso de gestión de riesgos del art. 9 tiene también relevancia desde la perspectiva de la responsabilidad civil por daños causados por sistemas de IA. La Directiva de Responsabilidad por Productos (DRP, Directiva 2024/2853), publicada en octubre de 2024, establece un régimen de responsabilidad objetiva del fabricante por los daños causados por productos defectuosos, y ha ampliado explícitamente su ámbito para cubrir el software, incluyendo los sistemas de IA.
Un sistema de IA que causa daños a una persona puede ser considerado un "producto defectuoso" bajo la DRP si no ofrece la seguridad que cabe legítimamente esperar. El proceso de gestión de riesgos del art. 9 del AI Act, correctamente documentado, puede servir como evidencia de que el proveedor realizó una evaluación razonable de los riesgos del sistema antes de su comercialización y tomó las medidas de mitigación apropiadas. En ausencia de esta documentación, el proveedor tiene más dificultades para demostrar que el sistema no era defectuoso en el momento de su comercialización.
La interacción entre el AI Act y la DRP es especialmente relevante para los juristas que asesoran a empresas en el diseño de sistemas de alto riesgo: no se trata solo de cumplir con el regulador, sino de construir la documentación que puede ser crucial en futuras reclamaciones de responsabilidad civil por daños. La gestión de riesgos bien documentada es la primera línea de defensa en esos procesos.
El ecosistema de herramientas para apoyar la gestión de riesgos de IA está creciendo rápidamente. La AESIA ha indicado que publicará plantillas y metodologías de referencia para el proceso de gestión de riesgos del art. 9, complementando los checklists de la Guía 16. La Oficina Europea de IA está desarrollando herramientas específicas para la evaluación de riesgos de los modelos GPAI. Y varios organismos de normalización están elaborando normas técnicas que especifican metodologías de gestión de riesgos para sistemas de IA.
La norma ISO/IEC 23894:2023 sobre gestión de riesgos de IA es una referencia útil como complemento al proceso de gestión de riesgos del art. 9. Aunque no es una norma armonizada del AI Act — es decir, no genera presunción de conformidad — proporciona una metodología estructurada y reconocida internacionalmente que puede adoptarse como base del proceso de gestión de riesgos del proveedor y complementarse con los requisitos específicos del art. 9.
Más recursos: calendario del AI Act tras el Ómnibus Digital · análisis del AI Act en 2026 · servicios para administraciones públicas (LexQuark).
Newsletter gratuita · Empresas y administraciones públicas · En español