EU AI Act — marco regulatorio
El EU AI Act existe para evitar daños concretos que la IA de alto riesgo ya ha causado —discriminación, decisiones opacas que nadie puede rebatir, fallos de seguridad— regulando los sistemas que deciden sobre las personas: crédito, salud, empleo, educación y demás. No es un ejercicio de papeleo: es la condición para poder operar en la UE.
Equivocarse sale caro. Según el Art. 99, las prácticas prohibidas pueden acarrear multas de hasta 35 M€ o el 7% de la facturación anual mundial, y el incumplimiento de las obligaciones de alto riesgo hasta 15 M€ o el 3% —más estricto que el RGPD—. Y el propio mercado se cierra: sin el expediente técnico del Anexo IV, la Declaración UE de Conformidad (Art. 47) y el marcado CE (Art. 48), un sistema de alto riesgo no puede introducirse en el mercado de la UE, puede ser retirado por la vigilancia del mercado (Arts. 79–83) y queda excluido de las licitaciones públicas que exigen conformidad.
El EU AI Act (Reglamento UE 2024/1689) establece requisitos horizontales para sistemas de IA de alto riesgo. Esta página describe los artículos relevantes para los escenarios que cubre el motor froga y cómo el motor los aborda. Los huecos pendientes se listan en Estado e incompletitudes.
Clasificación de alto riesgo — Art. 6 + Anexo III
Sección titulada «Clasificación de alto riesgo — Art. 6 + Anexo III»Un sistema de IA se clasifica como de alto riesgo cuando entra en las categorías del Anexo III (entre ellas: biometría —identificación biométrica remota, categorización biométrica y reconocimiento de emociones—, crédito, empleo, educación, servicios esenciales, o dispositivos médicos) o cuando forma parte de productos regulados por el Anexo I.
Cómo lo aborda el motor froga: la finalidad prevista (intended_purpose del bloque system: de froga.yaml), junto con potential_misuses, constituye la base del triaje regulatorio. El motor no toma la decisión de clasificación —esa responsabilidad es del operador—, pero impone que la finalidad esté declarada antes de ejecutar cualquier evaluación.
Sistema de gestión de riesgos — Art. 9
Sección titulada «Sistema de gestión de riesgos — Art. 9»El Art. 9 exige un proceso documentado, iterativo y continuo de identificación, análisis, evaluación y tratamiento de riesgos a lo largo del ciclo de vida del sistema. Los riesgos deben contemplar tanto el uso previsto como el mal uso razonablemente previsible.
Cómo lo aborda el motor froga: el motor implementa el proceso ISO 23894 §6 como motor de conformidad con Art. 9. Cada ejecución de froga run evalúa los controles bloqueantes del AssuranceProgram. froga status permite integrar esta evaluación en un pipeline de CI/CD sin recomputación completa. El AssuranceProgram crece a lo largo del desarrollo: el humano declara y cura los riesgos a mano en froga.yaml (el KAG, asistente de identificación, es línea futura).
Ver ISO 23894 — gestión de riesgos de IA para la implementación del proceso, y De dónde nacen los riesgos para los tres orígenes que nombra el Art. 9(2): el fin previsto, el mal uso razonablemente previsible y la realidad poscomercialización.
Gobernanza de datos — Art. 10
Sección titulada «Gobernanza de datos — Art. 10»El Art. 10 requiere que los datasets de entrenamiento, validación y prueba sean relevantes, representativos, libres de errores en la medida de lo posible, y que se gestionen con prácticas documentadas de gobernanza. El proveedor debe evaluar posibles sesgos y sus efectos sobre grupos protegidos.
Cómo lo aborda el motor froga: el descriptor Croissant (dataset.croissant en froga.yaml) declara la procedencia del dataset y sus atributos de equidad. El motor ancla el digest del dataset en la evidencia firmada. El equipo usa los metadatos Croissant para declarar riesgos de sesgo (ISO 23894 §6.4.2; el KAG futuro asistirá esa identificación). Las métricas de equidad (demographic_parity_diff, group_min_positive_rate, es_dice) se evalúan como controles del AssuranceProgram.
Documentación técnica — Art. 11 + Anexo IV
Sección titulada «Documentación técnica — Art. 11 + Anexo IV»El Art. 11 exige que el proveedor elabore y mantenga la documentación técnica del sistema antes de ponerlo en el mercado. El Anexo IV especifica el contenido mínimo: descripción del sistema (§1), datos de entrenamiento (§2), monitorización y funcionamiento (§3–§4), descripción del ciclo de vida (§5–§6), supervisión humana (§7), exactitud y robustez (§8), vigilancia poscomercialización (§9).
Cómo lo aborda el motor froga: el motor solo deja la evidencia firmada (.froga/bundle.json); la nube (plano de control) ensambla y renderiza el Anexo IV desde ese bundle firmado, con procedencia por campo (declarado en froga.yaml, derivado del bundle o derivado del historial git), y lo entrega como PDF. La documentación no se redacta a mano: se genera a partir del estado real del sistema.
🟡 Parcial — En el Anexo IV ensamblado por la nube, §7 (normas) y §8 (DoC) nunca quedan pendientes; §2/§3/§4/§9 pueden marcarse PENDIENTE si falta su insumo (datos / misuse+residuales+Art.14 / resultados de control / medidas post-market). En el escenario loan, con datos/controles/medidas presentes, solo §3 y §9 aparecerían pendientes. Ver Estado e incompletitudes.
Registros — Art. 12
Sección titulada «Registros — Art. 12»El Art. 12 requiere que los sistemas de alto riesgo generen y conserven registros que permitan identificar el periodo de funcionamiento y los eventos relevantes a efectos de supervisión. Los registros deben mantenerse durante un periodo mínimo establecido en el acto de ejecución.
Cómo lo aborda el motor froga: el git log del bundle de evidencia (.froga/bundle.json) es el registro de tratamientos de riesgos: cada commit es fechado, atribuido y firmado. froga approve --by añade aprobaciones de dirección como commits con trailer Froga-Approved-by:. froga reconstruct convierte ese historial en el ciclo formal por riesgo. La bóveda de retención (Art. 18) es parte del plano cloud.
Transparencia — Art. 13
Sección titulada «Transparencia — Art. 13»El Art. 13 exige que los sistemas de alto riesgo sean suficientemente transparentes para que los operadores puedan interpretar las salidas y utilizarlos correctamente. La documentación de uso debe incluir las capacidades, limitaciones y condiciones de funcionamiento del sistema.
Cómo lo aborda el motor froga: el Anexo IV ensamblado por la nube incluye las métricas del sistema (exactitud, equidad, estadísticas de potencia) con sus intervalos de confianza. El perfil de riesgo y la evaluación de conformidad son accesibles vía froga conformance y froga soa. Los campos system.intended_purpose y system.potential_misuses en froga.yaml documentan las limitaciones previstas.
Supervisión humana — Art. 14
Sección titulada «Supervisión humana — Art. 14»El Art. 14 exige que los sistemas de alto riesgo estén diseñados para que personas físicas puedan supervisar, detectar y corregir disfunciones, y puedan interrumpir el sistema. Los operadores deben ser capaces de comprender las capacidades y limitaciones del sistema.
Cómo lo aborda el motor froga: las barreras del motor (froga run) son puntos de decisión humana: una barrera fallida detiene el flujo hasta que el humano aplica un tratamiento (cambio de código, ajuste de parámetro, aceptación explícita con froga approve). froga approve --by registra la identidad del evaluador en el bundle.
Exactitud, robustez y ciberseguridad — Art. 15
Sección titulada «Exactitud, robustez y ciberseguridad — Art. 15»El Art. 15 requiere que los sistemas de alto riesgo alcancen los niveles de exactitud y robustez apropiados, y sean resilientes frente a errores, fallos e intentos de manipulación. Los niveles deben documentarse en la documentación técnica.
Cómo lo aborda el motor froga: las métricas de exactitud (accuracy, y en escenarios de imagen médica Dice/es_dice, con la métrica de borde NSD como línea futura) se evalúan como controles del AssuranceProgram con umbrales declarados. Las estadísticas de potencia (bootstrap, con cluster por paciente cuando el escenario lo requiere) cuantifican si las muestras son suficientes para defender el resultado frente a un regulador. Los resultados y sus intervalos de confianza se incluyen en el bundle firmado.
La ciberseguridad y la resiliencia frente a la manipulación (Art. 15(4)/(5) —envenenamiento de datos/modelo, ejemplos adversarios, ataques a la confidencialidad del modelo, control de acceso) se modelan mediante el catálogo de cláusulas semánticas cyber.* que el motor gobierna. Ver prEN 18282 — ciberseguridad de sistemas de IA.
Evaluación de impacto sobre derechos fundamentales — Art. 27
Sección titulada «Evaluación de impacto sobre derechos fundamentales — Art. 27»El Art. 27 obliga a los operadores (en determinados casos) a realizar una evaluación de impacto sobre derechos fundamentales antes de poner en servicio un sistema de IA de alto riesgo de las categorías cubiertas.
🚧 Planificado — La Evaluación de Impacto sobre Derechos Fundamentales (FRIA) no está cubierta explícitamente en el bundle v1. Ver Estado e incompletitudes.
Vigilancia poscomercialización — Art. 72
Sección titulada «Vigilancia poscomercialización — Art. 72»El Art. 72 exige que los proveedores establezcan y ejecuten un sistema de vigilancia poscomercialización proporcional a la naturaleza del sistema. Los incidentes graves y el mal funcionamiento deben notificarse.
🚧 Planificado — El modelo de monitorización continua de Art. 72 no está modelado en el motor v1. Ver Estado e incompletitudes.
Tabla resumen
Sección titulada «Tabla resumen»Cada artículo de abajo no es papeleo: es condición para poder vender tu sistema en la UE.
| Artículo | Obligación | Cobertura del motor froga |
|---|---|---|
| Art. 6 + Anexo III | Clasificación alto riesgo | intended_purpose + potential_misuses — triaje declarado, decisión del operador |
| Art. 9 | Sistema de gestión de riesgos | Motor ISO 23894 §6; barreras bloqueantes; AssuranceProgram vivo |
| Art. 10 | Gobernanza de datos | Descriptor Croissant; digest anclado; métricas de equidad como controles |
| Art. 11 + Anexo IV | Documentación técnica | Ensamblado por la nube desde el bundle firmado — parcial (§2/§3/§4/§9 condicionalmente pendientes si falta su insumo; §7/§8 nunca; en loan solo §3/§9) |
| Art. 12 | Registros | git log + firma DSSE; froga approve; bóveda cloud |
| Art. 13 | Transparencia | Métricas con IC; froga conformance; froga soa |
| Art. 14 | Supervisión humana | Barreras como puntos de decisión; froga approve --by registra evaluador |
| Art. 15 | Exactitud y robustez | Controles con umbrales; power-stats bootstrap |
| Art. 27 | FRIA | Planificado |
| Art. 72 | Vigilancia poscomercialización | Planificado |
Estándares armonizados relevantes
Sección titulada «Estándares armonizados relevantes»El EU AI Act delega los requisitos técnicos del Art. 9 en estándares armonizados CEN/CENELEC:
- prEN 18228 — gestión de riesgos de IA (Art. 9); da presunción de conformidad por cláusula. Ver prEN 18228.
- prEN 18282 — ciberseguridad de sistemas de IA (Art. 15(4)/(5)); borrador armonizado, ids semánticos
cyber.*anclados al texto público del Art. 15. Ver prEN 18282. - prEN 18283 — gestión de sesgo en IA (Art. 10); borrador armonizado. Ver prEN 18283.
- ISO/IEC 23894 — proceso de gestión de riesgos de IA; implementado en el motor. Ver ISO 23894.
El crosswalk completo entre artículos y cláusulas de estándar está en Referencia: Correspondencia entre normas.