Cumplimiento por diseño
Pasas tres semanas escribiendo el dossier de riesgos. Lo entregas. Al día siguiente reentrenas el modelo —y tu dossier ya describe un sistema que no existe. Ese es el agujero del cumplimiento a posteriori: nace obsoleto. El cumplimiento por diseño lo cierra haciendo de cada tratamiento de riesgo un commit firmado, no una nota en un documento ya muerto.
En concreto, el cumplimiento por diseño 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.
Por qué existe esta obligación — y por qué documentarla al final fracasa
Sección titulada «Por qué existe esta obligación — y por qué documentarla al final fracasa»El AI Act no es papeleo por el papeleo: existe para prevenir daños reales —una decisión discriminatoria, una lectura médica insegura, una denegación de crédito que nadie sabe explicar—, riesgos que, si no se tratan antes del despliegue, recaen sobre personas concretas. El coste de equivocarse tampoco es abstracto. El Art. 99 fija multas de hasta 35 M€ o el 7 % de la facturación anual mundial; y sin el expediente técnico del Anexo IV, la declaración UE de conformidad y el marcado CE, un sistema de alto riesgo simplemente no puede comercializarse en el mercado de la UE. Ese es el suelo regulatorio.
De ahí se sigue el argumento pragmático. Reconstruir un dossier de conformidad al final —a mano, sobre un sistema que se reentrena cada sprint— es inviable: el documento queda obsoleto antes de secarse la tinta, y choca de frente con el calendario de la evaluación de la conformidad y del organismo notificado, que necesita evidencia que se corresponda con el sistema que de verdad se evalúa. El diseño por construcción no es la opción elegante; es la única que sobrevive al contacto con un modelo que no deja de cambiar.
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 conjunto de datos. Cuando ese cambio se confirma en git (commit), queda fechado, atribuido a un autor y anclado a la tripleta (código, modelo, datos) 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 paquete de evidencia (.froga/bundle.json) es el registro de tratamientos de riesgos. No es una representación de él; es el registro mismo. froga 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 paquete firmado, pero en la nube (plano de control), no en el motor: la procedencia de cada campo es declarada (en froga.yaml), derivada del paquete 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 froga.yaml (intended_purpose) es la base del triaje regulatorio. |
| Art. 9 | Sistema de gestión de riesgos continuo | La barrera froga run evalúa controles bloqueantes en cada ejecución; froga 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 equipo los usa para declarar riesgos de sesgo (§6.4.2; el KAG futuro asistirá esa identificación). |
| Art. 11 + Anexo IV | Documentación técnica | La nube ensambla el Anexo IV desde el paquete firmado del motor (parcial; ver arriba). |
| Art. 12 | Registro de eventos | El git log del paquete es el registro de tratamientos; froga approve añade aprobaciones de dirección como commits con trailer Froga-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 reentrena, los parámetros se ajustan, el conjunto de datos 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.
La barrera de frescura (froga status) resuelve el primer problema: falla si la evidencia firmada no describe el sistema actual. La reejecución del historial con git (froga reconstruct) resuelve el segundo: el arco empírico FALLA→PASA por commit es la demostración.
El cumplimiento por diseño no equivale a conformidad completa
Sección titulada «El cumplimiento por diseño 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 peligro→daño 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: froga conformance y froga soa los emiten por cláusula y por control desde el paquete 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:
froga reconstruct, el AssuranceProgram vivo y la procedencia del Anexo IV.
Funciona con tu stack MLOps
Sección titulada «Funciona con tu stack MLOps»El motor froga no importa ninguna herramienta MLOps. La reproducibilidad del pipeline se delega en el seam Reproducer, y el campo pipeline.tool de tu froga.yaml elige el adapter. Hoy hay tres herramientas probadas en CI sobre el mismo escenario:
- DVC — git-native: la unidad de cambio es un fichero versionado en git.
- MLflow — experimento → Model Registry: la promoción a
@championes el tratamiento. - Dagster — orquestación por activos.