Ver el Anexo IV

🟡 Parcial — El Anexo IV ensamblado por la nube puede marcar como PENDIENTE §2/§3/§4/§9 si falta su insumo; §7 y §8 nunca son pendientes. En el escenario loan, con datos/controles/medidas presentes, solo §3 y §9 quedarían pendientes.

El EU AI Act, Art. 11 + Anexo IV, exige que los proveedores de sistemas de IA de alto riesgo mantengan una documentación técnica que cubra nueve secciones: descripción general del sistema, descripción de los elementos y del proceso de desarrollo, información detallada sobre el funcionamiento, monitorización, registro, etc.

En Venturalítica, el motor no ensambla ni emite el Anexo IV. El motor solo produce evidencia firmada en .sei/ (el bundle, los informes de conformidad y la reconstrucción del ciclo). El Anexo IV se ensambla y renderiza en el plano cloud a partir de esa evidencia ya comprometida en el repositorio. No existe un comando sei annex-iv ni un artefacto .sei/annex-iv.json.

Quién ensambla el Anexo IV

El plano cloud lee el .sei/bundle.json firmado y comprometido en el repositorio y, combinándolo con el manifiesto sei.yaml, construye el documento de las nueve secciones. Las dos fuentes son:

El manifiesto sei.yaml — campos declarados por el proveedor (nombre del sistema, finalidad prevista, modalidad, clasificación de riesgo, marcos regulatorios, programa de riesgos en la sección risk:, etc.).
El bundle de evidencia .sei/bundle.json — resultados medidos y firmados (controles, análisis de riesgo, linaje, datos de gobernanza, eventos de tratamiento).

De la combinación de ambas fuentes, la nube determina la procedencia de cada campo y arma las nueve secciones.

Las nueve secciones, con los títulos que la nube ensambla (messages/es.json, annex.section):

§1 Descripción general del sistema
§2 Datos y gobernanza de datos                                  ⏳ PENDIENTE (si falta data_governance)
§3 Seguimiento, funcionamiento y control                        ⏳ PENDIENTE (si faltan misuse/residuales/medios Art.14)
§4 Idoneidad de las métricas de rendimiento                     ⏳ PENDIENTE (si faltan resultados de control)
§5 Gestión de riesgos (Art. 9)
§6 Cambios a lo largo del ciclo de vida
§7 Normas armonizadas aplicadas
§8 Declaración UE de conformidad
§9 Sistema de seguimiento posterior a la comercialización       ⏳ PENDIENTE (si no hay medidas post-market)

§7 (normas armonizadas) y §8 (Declaración UE de conformidad) nunca quedan pendientes: el motor siempre emite su estado derivado del bundle. §2/§3/§4/§9 pueden marcarse PENDIENTE si falta su insumo: §2 si falta data_governance (Croissant), §3 si faltan los pilares ex-ante (mal uso previsible, riesgos residuales, medios de supervisión Art.14), §4 si faltan resultados de control, y §9 si el manifiesto no declara medidas post-market. En el escenario loan —con datos, controles y medidas presentes— solo §3 y §9 aparecerían como pendientes.

Procedencia de campos

Al ensamblar el documento, la nube asigna a cada campo una de cuatro procedencias:

Procedencia	Significado
`declared`	El proveedor lo declaró explícitamente en `sei.yaml`
`derived_git`	Derivado del bundle firmado, `dvc.lock` o historia git
`derived_bom`	Derivado del BOM/métricas del bundle (p. ej. los valores de control de §4)
`pending`	Sin valor en la versión actual (solo en §2/§3/§4/§9 cuando falta su insumo)

Las secciones marcadas como PENDIENTE corresponden a campos de procedencia pending. Pueden quedar en este estado §2/§3/§4/§9 cuando falta su insumo (datos / mal uso + residuales + medios Art.14 / resultados de control / medidas post-market); §7 y §8 nunca. Esto se documenta en Estado e incompletitudes.

El plano cloud: renderiza, no calcula

El diseño del plano cloud de Venturalítica es stateless y de solo lectura respecto al cálculo de conformidad: la nube no ejecuta el motor Rust ni el pipeline MLOps. En su lugar, lee los artefactos .sei/* ya firmados y comprometidos en el repositorio, verifica su firma y ensambla el Anexo IV a partir de ellos.

Concretamente, el módulo cloud/lib/sei/ (TypeScript):

verify.ts — reproduce sei verify en TypeScript puro (ECDSA-P256 + DSSE + in-toto, con @noble/curves). Verifica la firma de cada artefacto antes de usarlo.
load.ts — carga y valida los artefactos contra el JSON Schema v1.
El ensamblado del Anexo IV (assembleAnnexIv / parseAnnexBundle) construye las nueve secciones con sus procedencias a partir del bundle.json cargado.

El Anexo IV se renderiza en web y se exporta como PDF (Typst) desde la nube. El depósito de la evidencia firmada (.sei/*) en el repositorio es el acto humano de “poner en el mercado”: el desarrollador committea el bundle tras sei run, y la nube lo lee, verifica y arma el documento del Art. 11 sin reprocesar el cálculo.

Este diseño preserva la trazabilidad: la bóveda de artefactos (Art. 18, retención) es el repositorio git, y la nube es una ventana de lectura sobre él que deriva el Anexo IV de la evidencia, sin crear un artefacto nuevo que haya que firmar y mantener sincronizado.

Flujo operativo completo

# 1. Ejecutar el ciclo (mide, ancla, firma el bundle)
sei run --repo .

# 2. Verificar la firma del bundle
sei verify --repo .

# 3. Committear la evidencia firmada (la nube la leerá y armará el Anexo IV)
git add .sei/
git commit -m "evidencia: ciclo T1 (bundle firmado)"

A partir de ahí, el plano cloud lee el repositorio, verifica el bundle.json y muestra el Anexo IV en web, con opción de exportarlo a PDF. No hay paso de motor que escriba ni firme un annex-iv.json.

Referencias

Artefactos .sei/* — estructura de SeiArtifact<T>, JSON Schema v1 y quién escribe cada artefacto
Estado e incompletitudes — secciones del Anexo IV aún pendientes
Firmar y verificar la evidencia — esquema criptográfico de los .sig
Referencia CLI sei — subcomandos del motor (el Anexo IV no es uno de ellos)