Compliance by design
La conformidad by design designa un enfoque en el que los requisitos regulatorios se incorporan como restricciones del proceso de desarrollo —no como una capa de documentación añadida al final. En sistemas de IA de alto riesgo bajo el EU AI Act, la alternativa (documentar a posteriori) no es viable: el Art. 9 exige un sistema de gestión de riesgos continuo y actualizado, no un informe puntual.
La tesis central
Sección titulada «La tesis central»El tratamiento de riesgo (ISO 23894 §6.5) es un cambio versionado: a código, a un parámetro, a un dataset. Cuando ese cambio se commitea a git, queda fechado, atribuido a un autor y anclado a la tripleta (código, modelo, dataset) mediante firma ECDSA-P256+DSSE+in-toto.
git cierra el bucle de tratamiento ISO 23894.
Esta afirmación tiene una consecuencia directa: el git log del bundle de evidencia (.sei/bundle.json) es el registro de tratamientos de riesgos. No es una representación de él; es el registro mismo. sei reconstruct lo convierte en el ciclo formal ISO 23894 por riesgo, sin intervención manual.
Como corolario, el Anexo IV (EU AI Act Art. 11) se ensambla por construcción desde el bundle firmado, pero en la nube (plano de control), no en el motor: la procedencia de cada campo es declarada (en sei.yaml), derivada del bundle o derivada del historial git. No se redacta a mano.
Marco normativo — EU AI Act
Sección titulada «Marco normativo — EU AI Act»Venturalítica opera sobre los requisitos siguientes del EU AI Act para sistemas de alto riesgo:
| Artículo | Requisito | Cómo lo cubre Venturalítica |
|---|---|---|
| Art. 6 + Anexo III | Clasificación como sistema de alto riesgo | La finalidad prevista declarada en sei.yaml (intended_purpose) es la base del triaje regulatorio. |
| Art. 9 | Sistema de gestión de riesgos continuo | El gate sei run evalúa controles bloqueantes en cada ejecución; sei status puede integrarse en CI/CD como condición necesaria sin coste de recomputación. |
| Art. 10 | Gobernanza de datos | El descriptor Croissant (dataset.croissant) declara procedencia y atributos de equidad; el KAG los usa para proponer riesgos de sesgo (§6.4.2). |
| Art. 11 + Anexo IV | Documentación técnica | La nube ensambla el Anexo IV desde el bundle firmado del motor (parcial; ver arriba). |
| Art. 12 | Registro de eventos | El git log del bundle es el registro de tratamientos; sei approve añade aprobaciones de dirección como commits con trailer Sei-Approved-by:. |
Por qué no es suficiente auditar a posteriori
Sección titulada «Por qué no es suficiente auditar a posteriori»Un sistema de IA de alto riesgo cambia durante su ciclo de vida: el modelo se re-entrena, los parámetros se ajustan, el dataset evoluciona. Cada cambio puede alterar el perfil de riesgo y el estado de conformidad.
Auditar a posteriori —recopilar evidencia una vez y redactar documentación— genera dos problemas prácticos:
- Obsolescencia inmediata. La documentación describe el sistema en el momento de la auditoría, no el sistema en producción.
- Ausencia de trazabilidad del tratamiento. La ISO 23894 §6.5 exige demostrar que los tratamientos aplicados han reducido el riesgo. Sin historial versionado, esa demostración es narrativa, no empírica.
El gate de frescura (sei status) resuelve el primer problema: falla si la evidencia firmada no describe el sistema actual. El replay de git (sei reconstruct) resuelve el segundo: el arco empírico FALLA→PASA por commit es la demostración.
Compliance by design no equivale a conformidad completa
Sección titulada «Compliance by design no equivale a conformidad completa»Incorporar la conformidad en el proceso no elimina los huecos regulatorios. Algunos requisitos —el riesgo residual global (prEN 18228 cl. 10), la cadena hazard→harm explícita, la vigilancia poscomercialización (Art. 72)— no están completamente cubiertos en v1 del motor.
La diferencia con el enfoque tradicional es que los huecos son declarados como código: sei conformance y sei soa los emiten por cláusula y por control desde el bundle firmado. No hay documentación de conformidad que oculte los huecos; hay un informe que los lista.
Ver Estado e incompletitudes para el inventario completo.
El cómo
Sección titulada «El cómo»Los mecanismos que implementan este enfoque se describen en las páginas de metodología:
- Qué es Risk-Driven Development — el marco conceptual: cómo el bucle de tratamiento de riesgos dirige el desarrollo.
- git cierra el bucle de tratamiento ISO 23894 — la tesis central desarrollada:
sei reconstruct, el AssuranceProgram vivo y la procedencia del Anexo IV.