Ir al contenido

EU AI Act — marco regulatorio

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 sei 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: sistemas de 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 sei: la finalidad prevista (intended_purpose del bloque system: de sei.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.


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 sei: el motor implementa el proceso ISO 23894 §6 como motor de conformidad con Art. 9. Cada ejecución de sei run evalúa los controles bloqueantes del AssuranceProgram. sei status permite integrar esta evaluación en un pipeline de CI/CD sin recomputación completa. El AssuranceProgram crece a lo largo del desarrollo: sei assess propone riesgos no declarados; el humano los cura y los commitea.

Ver ISO 23894 — gestión de riesgos de IA para la implementación del proceso.


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 sei: el descriptor Croissant (dataset.croissant en sei.yaml) declara la procedencia del dataset y sus atributos de equidad. El motor ancla el digest del dataset en la evidencia firmada. El KAG usa los metadatos Croissant para proponer riesgos de sesgo (ISO 23894 §6.4.2). 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 sei: el motor solo deja la evidencia firmada (.sei/bundle.json); la nube (plano de control) ensambla y renderiza el Anexo IV desde ese bundle firmado, con procedencia por campo (declarado en sei.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.


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 sei: el git log del bundle de evidencia (.sei/bundle.json) es el registro de tratamientos de riesgos: cada commit es fechado, atribuido y firmado. sei approve --by añade aprobaciones de dirección como commits con trailer Sei-Approved-by:. sei reconstruct convierte ese historial en el ciclo formal por riesgo. La bóveda de retención (Art. 18) es parte del plano cloud.


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 sei: 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 sei conformance y sei soa. Los campos system.intended_purpose y system.potential_misuses en sei.yaml documentan las limitaciones previstas.


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 sei: los gates del motor (sei run) son puntos de decisión humana: un gate fallido detiene el flujo hasta que el humano aplica un tratamiento (cambio de código, ajuste de parámetro, aceptación explícita con sei approve). sei 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 sei: las métricas de exactitud (p. ej. accuracy, Dice/es_dice) se evalúan como controles del AssuranceProgram con umbrales declarados (la métrica de borde NSD es línea futura, ver el caveat de sesgo-por-tamaño del Dice). Las estadísticas de potencia (bootstrap con cluster por paciente) 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.


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.


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.


ArtículoObligaciónCobertura del motor sei
Art. 6 + Anexo IIIClasificación alto riesgointended_purpose + potential_misuses — triaje declarado, decisión del operador
Art. 9Sistema de gestión de riesgosMotor ISO 23894 §6; gates bloqueantes; AssuranceProgram vivo
Art. 10Gobernanza de datosDescriptor Croissant; digest anclado; métricas de equidad como controles
Art. 11 + Anexo IVDocumentación técnicaEnsamblado 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. 12Registrosgit log + firma DSSE; sei approve; bóveda cloud
Art. 13TransparenciaMétricas con IC; sei conformance; sei soa
Art. 14Supervisión humanaGates como puntos de decisión; sei approve --by registra evaluador
Art. 15Exactitud y robustezControles con umbrales; power-stats bootstrap
Art. 27FRIAPlanificado
Art. 72Vigilancia poscomercializaciónPlanificado

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.
  • 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: Crosswalk de estándares.