Estado e incompletitudes
🟡 Parcial — El Anexo IV que ensambla la nube desde el bundle del motor aún no es completo; esta página enumera los huecos.
Venturalítica se construye en paralelo con su documentación y es incompleto por honestidad de diseño. Declaramos los huecos en lugar de ocultarlos. Esta página es la fuente de verdad sobre la madurez del proyecto y el camino hacia un Anexo IV completo conforme al EU AI Act Art. 11.
Taxonomía de estados
Sección titulada «Taxonomía de estados»| Estado | Significado |
|---|---|
| ✅ Estable | Implementado y cubierto por tests de integración o e2e |
| 🟡 Parcial | Funciona en los casos documentados; falta cobertura completa |
| 🚧 Planificado | Diseñado en spec, sin implementar todavía |
| 🧪 Experimental | Prototipo; la API puede cambiar sin preaviso |
Puntos abiertos hacia un Anexo IV completo
Sección titulada «Puntos abiertos hacia un Anexo IV completo»Los ítems siguientes son huecos identificados entre el estado actual del motor froga y el requisito de un Anexo IV verificable (EU AI Act Art. 11; ISO/IEC 42001 Annex B).
| Estado | Hueco | Cláusula relevante |
|---|---|---|
| 🚧 | Anclaje de identidad keyless (Sigstore): la firma ECDSA-P256+DSSE+in-toto está implementada, pero el anclaje del firmante a una raíz de confianza externa está pendiente. | Sigstore (firma keyless); in-toto (integridad de cadena) |
| 🟡 | Vigilancia poscomercialización / post-market monitoring (Art. 72): los manifiestos de los sistemas de alto riesgo YA declaran medidas post-market (article: "72" con disparador, cadencia ISO 8601 y art72_citation: eu/ai-act@2024#art-72); la barrera de completitud Art.72 las reconoce como Declaradas. Lo que falta es el bucle de operación continua en producción (ejecución viva, ingesta de deriva, disparo automático de revisiones): la monitorización se diseña ex-ante pero todavía no se opera. | EU AI Act Art. 72; Anexo IV §9 |
| ✅ | Riesgo residual global del sistema (prEN 18228 cl. 10): ya es criterio en froga conformance cl. 10 (criterion: overall_residual, agregado por evaluate_overall_residual() y persistido en EvidenceBundle.overall_residual) y bloquea la barrera del ciclo de vida; solo es advisory en la barrera de froga run. | prEN 18228 cl. 10 |
| 🚧 | Cadena hazard→harm explícita y jerarquía de control (prEN 18228 cl. 9): el modelo actual sigue ISO 23894 (proceso de gestión de riesgos); la cadena product-safety y la jerarquía de medidas de control no están construidas. | prEN 18228 cl. 9; ISO 23894 §6.4 |
| 🚧 | Derechos fundamentales (FRIA): la Evaluación de Impacto sobre Derechos Fundamentales (EU AI Act Art. 27) no está cubierta explícitamente en el bundle. | EU AI Act Art. 27 |
| 🚧 | Modalidad de tratamiento por prompt (caso LLM): solo están construidas las modalidades de cambio de código y de ajuste de parámetro. La modalidad prompt-tuning está aplazada. | ISO 23894 §6.5; EU AI Act Art. 10 |
| 🚧 | Anexo IV §2/§3/§4/§9 condicionalmente pendientes: §2 (datos) si falta data_governance; §3 (seguimiento/funcionamiento/control) si faltan los pilares ex-ante (mal uso previsible, riesgos residuales, medios de supervisión Art.14); §4 (idoneidad de métricas) si faltan resultados de control; §9 (seguimiento post-market) si el manifiesto no declara medidas post-market. §7 (normas armonizadas) y §8 (Declaración UE de conformidad) NUNCA son pendientes: el motor siempre emite su estado derivado del bundle. En los escenarios actuales, con datos/controles/medidas presentes, solo §3 y §9 aparecen pendientes. | EU AI Act Anexo IV §2, §3, §4, §9 |
| ✅ | El portal hace cumplir el veredicto de apetito agregado (con aceptación consciente): RESUELTO — el desajuste de nombre quedó corregido (la nube lee overall_residual.evaluation → aboveAppetite). Si el residual agregado supera el apetito, aprobar exige un override con motivo de aceptación consciente (no bloqueo duro ni permiso silencioso; las violaciones de integridad sí bloquean duro). El motor firma el veredicto; el portal lo proyecta y lo enforcea. | prEN 18228 cl. 10 (proyección del portal) |
El currículo del taller
Sección titulada «El currículo del taller»El taller de dos roles (Diego, QM/owner por la UI; Marta, ingeniera/maintainer por la CLI) se estructura hoy en tres partes:
- Fundamentos (
/foundations/*): qué es un riesgo, prEN frente a ISO, superposiciones sectoriales, el organismo notificado, la brecha de datos y la cadena de suministro. - Metodología RDD (
/metodologia/*): el Desarrollo Dirigido por Riesgo y cómo git cierra el bucle de tratamiento. - Niveles N1–N6 (
/cursos/level-1-iris…/cursos/level-6-supply-chain): el espinazo limpio N1–N2, los overlays sectoriales N3 (salud/MDR), N4 (finanzas/DORA) y N5 (empleo), y el capstone N6 de cadena de suministro.
Las Guías, Conceptos y Referencia completan el material. Su madurez NO es uniforme y lo declaramos:
| Estado | Nivel | Validación |
|---|---|---|
| ✅ | N1 · Iris (tu primer sistema) | Validado de extremo a extremo en vivo: recorrido real contra platformpre + froga 0.1.0 + un fork del starter. |
| 🟡 | N2–N6 (estudiantes, retina/MDR, crédito/DORA, empleo, cadena de suministro) | Escritos y revisados (anti-fabricación, atados al código y al estado real del producto) y enlazados por commit a repos vldemo-* públicos, con una barrera de reproducción nocturna que re-deriva el veredicto de cada nivel. Validación más ligera que N1: sin el bucle de agente-alumno en vivo. |
El ciclo de tratamiento completo —cómo el portal hace cumplir el veredicto de apetito agregado con una aceptación consciente: el motor firma el veredicto, el portal lo proyecta y lo enforcea— se desarrolla a fondo en git cierra el bucle de tratamiento.
Qué está construido
Sección titulada «Qué está construido»Los subsistemas siguientes están estables y cubiertos por tests:
- Firma ECDSA-P256+DSSE+in-toto de artefactos
.froga/*. - Modelo de riesgo ISO 23894 §6.4.2–6.4.4 y §6.5 (likelihood × impact 5×5, residual híbrido, apetito).
- Conformidad dual por proyección: prEN 18228 (prioritario) + ISO 23894, desde un único bundle.
froga reconstruct— replay del ciclo de tratamiento por riesgo desde elgit log.- Ensamblado del Anexo IV en la nube (plano de control) desde el bundle firmado; el motor solo emite la evidencia.
- Modalidades de tratamiento: cambio de código (loan-scoring:
mitigate: false→trueenparams.yaml, fairlearn DemographicParity) y ajuste de parámetro (retina-screening:mitigate: false→trueenparams.yaml, reentrena el cribador DR con clase balanceada + umbral 0.30). - Tres backends MLOps probados en el arnés de escenarios e2e (pre-merge / runners auto-hospedados;
ci.ymlsolo correcargo test --workspace --lib): DVC (cat1), MLflow (cat2), Dagster (cat3).
Los huecos como código
Sección titulada «Los huecos como código»Los huecos anteriores no son solo texto: froga conformance y froga soa ya emiten los gaps por cláusula y por control desde el bundle firmado. Consulta la Referencia del CLI froga; froga conformance acepta los flags --standard y --out.