Herramientas de gestión de riesgos de IA: una guía de compra para el cumplimiento de la Ley de IA de la UE
Cómo elegir herramientas de gestión de riesgos de IA para el cumplimiento de la Ley de IA de la UE. Cubre los registros de riesgos del Artículo 9, las categorías de herramientas, las sanciones del Art. 99 y diciembre de 2027.
No todas las herramientas etiquetadas como «gestión de riesgos de IA» se construyen en torno a la misma obligación jurídica. Algunos productos son suites de prueba de modelos —miden la exactitud, la equidad y la robustez adversarial—. Otros son plataformas de registro GRC adaptadas para registrar los sistemas de IA junto con los activos de TI. Una tercera categoría está construida específicamente para el ciclo de vida del sistema de gestión de riesgos del Artículo 9 de la Ley de IA de la UE, que va desde la clasificación previa al mercado hasta la gestión de incidentes poscomercialización. Elegir la categoría equivocada malgasta el presupuesto y deja lagunas reales cuando una autoridad de vigilancia del mercado pide su documentación.
Esta guía explica qué exige realmente la Ley de IA de la UE, mapea esos requisitos a las categorías de herramientas y le ofrece una lista de comprobación concreta para evaluar lo que compra. El plazo de cumplimiento para los sistemas de IA de alto riesgo autónomos (la lista del Anexo III) es el 2 de diciembre de 2027 en virtud del Ómnibus Digital acordado en mayo de 2026 —que es un respiro, no una ampliación del trabajo de documentación subyacente—.
Qué exige realmente la Ley de IA de la UE a las herramientas
El bucle del ciclo de vida del Artículo 9
El Artículo 9 del Reglamento (UE) 2024/1689 define el sistema de gestión de riesgos para la IA de alto riesgo —y es una obligación de ciclo de vida, no una evaluación puntual—. Los proveedores deben:
- Identificar y analizar los riesgos conocidos y razonablemente previsibles para la salud, la seguridad y los derechos fundamentales —en el uso previsto y en el uso indebido razonablemente previsible—.
- Estimar y evaluar esos riesgos, incluidos los que surgen de las interacciones con otros sistemas.
- Adoptar medidas de gestión de riesgos —eliminando o reduciendo los riesgos mediante el diseño, y añadiendo luego controles e información a los usuarios—.
- Probar el sistema frente a esas medidas antes de la introducción en el mercado, y registrar los resultados.
Crucialmente, el Artículo 9 no se detiene en la introducción en el mercado. El bucle debe nutrirse de los datos poscomercialización. Una herramienta útil debe dar soporte a las cuatro etapas, no solo a la recopilación inicial.
Un registro de riesgos forma parte del sistema
El sistema de gestión de riesgos del Artículo 9 implica un registro estructurado: qué riesgos se identificaron, cómo se evaluaron, qué se hizo y qué riesgo residual se aceptó. Eso es, en términos operativos, un registro de riesgos —el artefacto vivo que examinarán los auditores y las autoridades de vigilancia del mercado—. Un registro de riesgos que vive en una hoja de cálculo al margen de cualquier flujo de trabajo estructurado es difícil de mantener actualizado y casi imposible de auditar.
La clasificación de riesgo va primero (Artículo 6 y Anexo III)
Antes de que pueda comenzar el bucle del Artículo 9, hay que saber si el sistema es de alto riesgo en absoluto. La clasificación con arreglo al Artículo 6 y los ocho epígrafes del Anexo III —biometría, infraestructuras críticas, educación, empleo, acceso a servicios esenciales (incluidas la calificación de la solvencia y los seguros de salud/vida), garantía del cumplimiento del Derecho, migración y control fronterizo, administración de justicia— es la puerta de entrada. Si se equivoca en la clasificación, o bien se pierde toda la pila de obligaciones, o bien construye un proceso innecesario para un sistema que es solo de riesgo limitado o mínimo.
El filtro del Artículo 6, apartado 3, importa aquí: un sistema que entra en un ámbito del Anexo III no es automáticamente de alto riesgo si no plantea un riesgo significativo de perjuicio —por ejemplo, si desempeña una tarea procedimental acotada o realiza un trabajo preparatorio sin influir en la evaluación humana—. Cualquier sistema que elabore perfiles de personas físicas es siempre de alto riesgo, sin excepción.
Pruebas de sesgo y equidad (Artículo 10)
El Artículo 10 rige los datos y la gobernanza de datos para los sistemas de alto riesgo: los conjuntos de datos de entrenamiento, validación y prueba deben estar sujetos a procedimientos documentados que cubran la calidad de los datos, la representatividad y la detección de sesgos. Esto es distinto de lo que normalmente miden las herramientas de prueba de modelos —el Artículo 10 exige una gobernanza documentada del ciclo de vida de los datos, no solo una métrica de equidad en una evaluación de un momento concreto—.
Exactitud, robustez y seguridad (Artículo 15)
El Artículo 15 exige que los sistemas de alto riesgo alcancen niveles adecuados de exactitud, robustez y ciberseguridad. Obliga a la resiliencia frente a los intentos de terceros de alterar el uso o el rendimiento mediante técnicas adversariales. Aquí es donde las herramientas de prueba de modelos y de equipo rojo (red team) se conectan al marco jurídico —aunque el cumplimiento del Artículo 15 requiere pruebas documentadas, no solo una puntuación de prueba aprobatoria—.
Supervisión humana (Artículo 14)
El Artículo 14 exige que los sistemas de alto riesgo se diseñen para permitir que las personas físicas supervisen su funcionamiento, comprendan los resultados, intervengan o anulen, y detengan el sistema. Las herramientas deben, o bien ayudarle a diseñar funciones de supervisión en el sistema, o bien documentar que existen flujos de trabajo de supervisión a nivel operativo del responsable del despliegue.
Vigilancia poscomercialización (Artículo 72) y gestión de incidentes (Artículo 73)
Una vez desplegada, los proveedores de IA de alto riesgo deben operar un sistema de vigilancia poscomercialización con arreglo al Artículo 72 —recopilando y analizando proactivamente datos sobre el rendimiento del sistema, la aparición de sesgos y la experiencia del usuario—. Los incidentes graves (los que causan la muerte, un perjuicio grave a las personas o daños a infraestructuras críticas) deben notificarse a las autoridades de vigilancia del mercado con arreglo al Artículo 73: en un plazo de 15 días desde el primer conocimiento en la mayoría de los casos, 2 días para los incidentes generalizados o de infraestructura crítica, y 10 días cuando se ha producido una muerte.
Los responsables del despliegue tienen deberes relacionados pero distintos: el Artículo 26 les exige vigilar el sistema en su contexto operativo, señalar los riesgos y los incidentes graves al proveedor y conservar los registros durante al menos seis meses.
Aceptación del riesgo residual
Al final del ciclo del Artículo 9, el proveedor debe documentar que los riesgos residuales —los que permanecen tras toda mitigación razonable— se consideran aceptables dados los beneficios del sistema. Este es un visto bueno formal, no algo por defecto. Las herramientas deberían solicitarlo y preservar el registro.
El proceso de gobernanza frente a la prueba de modelos
Esta es la distinción más importante que un comprador necesita hacer.
Las herramientas de prueba de modelos / equipo rojo miden lo que hace un modelo: exactitud en un conjunto de datos reservado, métricas de equidad entre grupos demográficos, robustez adversarial, tasas de alucinación. Son valiosas para las pruebas del Artículo 15 y para los requisitos de detección de sesgos del Artículo 10. No son, por sí mismas, un sistema de gestión de riesgos del Artículo 9. Generan artefactos de prueba; no hacen el seguimiento de los riesgos identificados a lo largo del ciclo de vida de un sistema, ni gestionan la decisión de clasificación, ni producen el expediente de documentación técnica del Anexo IV.
Las plataformas de GRC / registro de riesgos registran y hacen el seguimiento de los riesgos. Muchas se han adaptado para aceptar los sistemas de IA como categoría de registro. Son buenas para mantener un registro de riesgos vivo y pueden gestionar los flujos de trabajo de aceptación del riesgo residual. Su laguna está normalmente en el lado de la clasificación —distinguir un sistema de alto riesgo del Anexo III de un chatbot de riesgo mínimo requiere una lógica específica de la Ley de IA de la UE que las herramientas GRC generales no incluyen por defecto—.
Las plataformas dedicadas a la Ley de IA de la UE cubren todo el bucle de gobernanza: recopilación de la clasificación, determinación de la función (proveedor frente a responsable del despliegue con arreglo a los Artículos 16 y 26), el ciclo de gestión de riesgos del Artículo 9 mapeado a controles específicos, la EIDF del Artículo 27 para los responsables del despliegue que reúnan los requisitos, el paquete de documentación técnica del Anexo IV y la declaración de conformidad del Artículo 47. Son la vía más corta hacia un registro de cumplimiento completo y defendible en una auditoría.
Las herramientas puntuales (escáneres de sesgo, generadores de documentación, aplicaciones de listas de comprobación) cumplen funciones acotadas. Útiles como componentes de un programa más amplio; insuficientes por sí solas.
Dimensiones para el comprador
Cobertura: registro de gobernanza frente a prueba de modelos frente a ambos
Pregunte si la herramienta aborda el ciclo de vida del proceso del Artículo 9 o solo las métricas de rendimiento técnico. Un programa bien diseñado necesita ambos, pero el registro de gobernanza es el fundamento jurídico —es lo que revisan los reguladores y los organismos notificados—. Las pruebas de la prueba de modelos se incorporan a él como adjunto.
Conclusiones deterministas frente a generadas por LLM
Para un caso de uso de cumplimiento, la defensibilidad en auditoría importa. Una conclusión que diga «este sistema puede ser de alto riesgo porque el Anexo III cubre algo parecido a esto» no es una conclusión que pueda adjuntar a una declaración de conformidad. La lógica de clasificación debería ser determinista y basada en reglas —la misma recopilación produce siempre el mismo resultado, y la regla que se activó es legible por humanos y citable—. Las evaluaciones de cumplimiento generadas por LLM introducen un riesgo de alucinación: una cita de artículo segura pero incorrecta, un subapartado inexistente, una exención inventada. Eso es lo contrario de lo que necesita un registro de cumplimiento.
Alojamiento de datos en la UE
Si almacena datos personales sobre personas en su registro de IA —nombres, funciones, descripciones de sistemas que hacen referencia a poblaciones de usuarios—, considere dónde se alojan esos datos. Las herramientas alojadas en la UE eliminan la cuestión de la transferencia transfronteriza con arreglo al RGPD.
Adecuación al tamaño de la organización
Las plataformas GRC empresariales están construidas para grandes equipos de cumplimiento con presupuestos de implementación dedicados y plazos de incorporación de 3 a 6 meses. Para una empresa de 30 personas que gestiona dos o tres sistemas de IA, la carga de un despliegue empresarial puede superar el propio trabajo de cumplimiento. Las herramientas de autoservicio con pago con tarjeta de crédito y una recopilación guiada cubren el mismo terreno jurídico sin el coste de implementación.
Integraciones
Las integraciones con las herramientas de desarrollo (GitHub, Jira, canalizaciones de CI/CD) son útiles para incorporar los controles del Artículo 9 al proceso de construcción. Para la mayoría de las empresas, la necesidad de integración más inmediata es con su registro de riesgos o de cumplimiento existente —poder exportar el registro de riesgos y la documentación técnica en un formato que un auditor o una autoridad pueda leer—.
Precio y tiempo hasta el valor
El trabajo de cumplimiento tiene un alcance fijo. Lo que varía entre herramientas es cuánto tiempo lleva completar ese alcance y cuánto cuesta llegar a un registro defendible. Una herramienta que le guía por 40 controles mapeados a Artículos específicos en unas horas ofrece un tiempo hasta el valor más rápido que otra que requiere semanas de configuración y consultoría.
Categorías de herramientas y compromisos
| Categoría | Puntos fuertes | Lagunas |
|---|---|---|
| Herramientas de prueba de modelos / equipo rojo | Pruebas del Art. 15; métricas de sesgo; cobertura adversarial | Sin registro de ciclo de vida; sin lógica de clasificación; sin generación de documentación |
| Plataformas de GRC / registro de riesgos | Registro de riesgos vivo; flujos de trabajo de auditoría maduros | Normalmente sin clasificación específica de la Ley de IA de la UE; sin salida del Anexo IV |
| Plataformas dedicadas a la Ley de IA de la UE | Bucle completo del Artículo 9; clasificación; generación de documentación; delimitación de funciones | Varían en la profundidad de la cobertura de la prueba de modelos |
| Herramientas puntuales (escáneres de sesgo, aplicaciones de listas de comprobación) | Bajo coste; específicas | Insuficientes por sí solas; sin un programa coherente |
Ninguna de estas categorías carece de compromisos. La cuestión es qué combinación le da un expediente de pruebas completo a un coste proporcionado al número de sistemas y al tamaño de su equipo.
Cómo encaja Confir
Confir es una herramienta dedicada al cumplimiento de la Ley de IA de la UE —basada en reglas, alojada en la UE y diseñada para el uso en autoservicio por equipos de cumplimiento, jurídicos y de TI que no disponen de un presupuesto de implementación empresarial—. La lógica de clasificación es determinista: las mismas respuestas de recopilación producen siempre la misma determinación del nivel de riesgo y la misma asignación de función, basadas en la lógica explícita del Artículo 6 y del Anexo III. No hay inferencia de LLM en las conclusiones.
La cobertura abarca la clasificación de los Artículos 5 y 6, la determinación de la función (proveedor con arreglo al Artículo 16 o responsable del despliegue con arreglo al Artículo 26), una evaluación estructurada en clasificación de riesgo (Artículos 5, 6, 43, 50), robustez técnica y de datos (Artículos 10, 11, 15), transparencia y supervisión humana (Artículos 13, 14, 27, 50) y gobernanza y vigilancia poscomercialización (Artículos 9, 72, 73). Confir genera el paquete de documentación técnica del Anexo IV y la declaración de conformidad del Artículo 47, y ejecuta la EIDF del Artículo 27 para los responsables del despliegue que reúnan los requisitos. Sin consultores, sin una implementación de seis meses.
Si su laguna principal es la cobertura de la prueba de modelos o del equipo rojo (pruebas del Artículo 15), Confir no es un sustituto de eso. El uso apropiado es como capa de registro de gobernanza y de documentación —con los artefactos de la prueba de modelos adjuntos como prueba dentro del registro—.
Lista de comprobación para la selección
Antes de comprometerse con una herramienta, verifique:
- Lógica de clasificación: ¿distingue correctamente la herramienta el alto riesgo del Anexo III del riesgo mínimo, aplica el filtro del Artículo 6, apartado 3, e identifica la función de proveedor frente a responsable del despliegue?
- Soporte del ciclo de vida del Artículo 9: ¿hace el seguimiento de los riesgos identificados, las medidas de mitigación y la aceptación del riesgo residual a lo largo del tiempo —no solo en la recopilación inicial—?
- Salida de documentación: ¿genera un expediente estructurado de documentación técnica del Anexo IV y una declaración de conformidad del Artículo 47?
- Vigilancia poscomercialización: ¿da soporte a la recopilación de datos del Artículo 72 y a los plazos de notificación de incidentes del Artículo 73 (umbrales de 15 días / 2 días / 10 días)?
- Delimitación de la EIDF: ¿delimita correctamente la EIDF del Artículo 27 a los responsables del despliegue que son organismos públicos y a los responsables del despliegue de sistemas de solvencia (Anexo III, punto 5, letra b)) y de seguros de vida/salud (Anexo III, punto 5, letra c)) —y no la extiende en exceso a los empleadores privados en general—?
- Conclusiones deterministas: ¿son los resultados de clasificación fruto de una lógica de reglas explícita, o están generados por LLM? ¿Puede citar la regla que se activó?
- Rastro de auditoría: ¿hay un registro inmutable de quién evaluó qué y cuándo?
- Alojamiento en la UE: ¿dónde se almacenan los datos y satisface sus obligaciones del RGPD?
- Tiempo hasta el valor: ¿puede completar el registro básico del Artículo 9 y generar la documentación en días, o requiere meses de configuración?
- Transparencia de precios: ¿son los costes fijos por sistema o por usuario, y escalan proporcionalmente para una empresa que gestiona de 1 a 5 sistemas?
El plazo del 2 de diciembre de 2027 para los sistemas autónomos del Anexo III es real, pero el trabajo de documentación y de pruebas que alimenta el registro de conformidad lleva meses. Empezar con una comprensión clara de qué categoría de herramientas necesita realmente es el paso que determina todo lo demás.
Preguntas frecuentes
¿Cuál es la diferencia entre una herramienta de gestión de riesgos de IA y una herramienta de prueba de modelos?
Una herramienta de prueba de modelos mide lo que hace un sistema de IA —exactitud, métricas de equidad, robustez adversarial— y genera artefactos de prueba. Una herramienta de gestión de riesgos de IA (en el sentido de la Ley de IA de la UE) gestiona el ciclo de vida del Artículo 9: clasificar el sistema, identificar y hacer el seguimiento de los riesgos a lo largo del tiempo, registrar las medidas de mitigación y generar la documentación técnica del Anexo IV y la declaración de conformidad del Artículo 47. Ambas son necesarias para un programa de cumplimiento completo, pero no son intercambiables. El registro de gobernanza es el fundamento jurídico; los artefactos de prueba son las pruebas que se incorporan a él.
¿Qué es el sistema de gestión de riesgos del Artículo 9 y qué deben hacer las herramientas para darle soporte?
El Artículo 9 del Reglamento (UE) 2024/1689 exige a los proveedores de IA de alto riesgo establecer un sistema de gestión de riesgos que cubra cuatro etapas: identificación y análisis de los riesgos, estimación y evaluación de esos riesgos, adopción de medidas de gestión de riesgos, y pruebas y vigilancia poscomercialización. Las herramientas deben dar soporte a las cuatro etapas —no solo a la recopilación inicial—. Deben hacer el seguimiento de los riesgos identificados a lo largo del ciclo de vida del sistema, registrar qué mitigación se aplicó, documentar la aceptación del riesgo residual y nutrirse de los datos poscomercialización del sistema de vigilancia del Artículo 72.
¿Cuándo se aplican las obligaciones de alto riesgo de la Ley de IA?
En virtud del Ómnibus Digital acordado entre el Parlamento Europeo y el Consejo en mayo de 2026, las obligaciones de alto riesgo para los sistemas autónomos del Anexo III se aplican a partir del 2 de diciembre de 2027 (aplazado respecto de la fecha original de agosto de 2026). La IA de alto riesgo integrada en productos regulados del Anexo I se aplica a partir del 2 de agosto de 2028. Las prácticas prohibidas del Artículo 5 están en vigor desde el 2 de febrero de 2025. Las obligaciones de GPAI (Artículos 51 a 55) se aplican desde el 2 de agosto de 2025. La transparencia de riesgo limitado del Artículo 50 se aplica a partir del 2 de agosto de 2026.
¿Quién necesita realizar una Evaluación de Impacto relativa a los Derechos Fundamentales (Artículo 27)?
La EIDF del Artículo 27 se aplica a responsables del despliegue específicos —no a todos—. Es obligatoria para los responsables del despliegue que son organismos públicos, y para los responsables del despliegue que utilizan sistemas de alto riesgo para la evaluación de la solvencia (Anexo III, punto 5, letra b)) o el riesgo y la fijación de precios de los seguros de vida/salud (punto 5, letra c)). No se aplica automáticamente a los empleadores privados que despliegan IA de selección de personal o de RR. HH., aunque esos sistemas siguen conllevando toda la pila de obligaciones de alto riesgo para el proveedor. El Artículo 27, apartado 4, permite que la EIDF se base en una EIPD del RGPD existente, lo que reduce la duplicación.
¿Qué significa «determinista» para las herramientas de cumplimiento y por qué importa?
Una herramienta determinista aplica reglas explícitas y legibles por humanos: dada la misma recopilación —la misma descripción del sistema, el mismo uso previsto y el mismo contexto de despliegue—, devuelve siempre la misma clasificación y las mismas conclusiones. La regla que se activó es citable. Esto importa para la defensibilidad en auditoría: cuando una autoridad de vigilancia del mercado revisa su registro de conformidad, el razonamiento de la clasificación debe ser rastreable y explicable. Una conclusión generada por un LLM puede parecer plausible mientras cita un artículo inexistente o un subapartado incorrecto —un problema difícil de detectar y potencialmente fatal para el registro—.
¿Qué niveles de multa se aplican a los incumplimientos de las obligaciones de alto riesgo?
El incumplimiento de la mayoría de las obligaciones de la Ley de IA de la UE —incluidos el sistema de gestión de riesgos del Artículo 9, los deberes del proveedor del Artículo 16 y los deberes del responsable del despliegue del Artículo 26— entra en 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. Para las pymes y las empresas emergentes, el Artículo 99, apartado 6, limita la multa a la menor de las dos cifras, el importe fijo o el porcentaje. La vulneración de las prohibiciones del Artículo 5 conlleva el nivel más alto: 35 000 000 EUR o el 7 %.
Guías relacionadas
- obligaciones del responsable del despliegue del Artículo 26
- requisitos de inventario de sistemas de IA
- requisitos de cumplimiento de la Ley de IA de la UE
- niveles de clasificación de riesgo de IA
- requisitos de gestión de riesgos del Artículo 9
- registro de riesgos de IA
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 →