git cierra el bucle de tratamiento ISO 23894

Bucle RDD: commit → medir → tratar → re-anclar → commit

El diagrama muestra el ciclo completo: cada tratamiento termina en un commit que actualiza el ancla del bundle, y el ciclo vuelve a medir sobre esa base.

La tesis central

El tratamiento de riesgo (ISO 23894 §6.5) es un cambio: a código, a un parámetro, a un dataset. Ese cambio, cuando se commitea a git, queda:

versionado — identificable por hash y attributable a un autor con fecha
anclado — el motor firma el bundle de evidencia con ECDSA-P256+DSSE+in-toto contra la tripleta (code digest, model digest, dataset digest)
trazable por cláusula — sei conformance proyecta el bundle sobre los catálogos de ISO 23894 y prEN 18228

Esta era la limitación del producto anterior: los tratamientos eran cambios de código que había que recoger a mano en el registro de riesgos. Hacer que git cierre el bucle —que el git log del bundle sea el registro de tratamientos— es lo que hace Venturalítica.

`sei reconstruct`: replay del ciclo por riesgo

sei reconstruct reconstruye el ciclo de tratamiento por riesgo mediante replay del historial git del bundle de evidencia (.sei/bundle.json). El proceso es determinista y no requiere un modelo de lenguaje.

Por cada riesgo identificado, el informe recorre cinco fases:

Fase	Qué hace `sei reconstruct`
① Identificación	Localiza el commit que introdujo el riesgo en el AssuranceProgram (`git log -S <risk_id>`)
② Análisis	Recupera el análisis likelihood × impacto → nivel inherente del bundle histórico
③ Evaluación	Comprueba el nivel inherente vs el apetito declarado en `sei.yaml`
④ Tratamiento	Reconstruye el arco empírico FALLA → PASA por commit (el tratamiento aplicado)
⑤ Residual	Clasifica el ciclo: CERRADO / ABIERTO / DISCREPANCIA / ACEPTADO (ISO 23894 §6.5)

La salida puede escribirse como artefacto firmado con --out (.sei/reconstruct.json + .sig).

Consulta la Referencia del CLI sei para el detalle de flags y artefactos.

git blame = el registro de auditoría

En Venturalítica, git blame sobre el AssuranceProgram —la sección risk: de sei.yaml— es el registro de auditoría de identificación: cada riesgo tiene un autor (quién lo identificó), una fecha (cuándo) y un mensaje de commit (por qué se añadió). git log -S "<risk_id>" sei.yaml localiza el commit que introdujo cada riesgo.

Esto satisface el requisito de trazabilidad de la ISO 23894 §6.4.2 (identificación de riesgos) sin ninguna infraestructura adicional: el historial git ya contiene toda la información.

El Anexo IV sale por construcción

Porque cada tratamiento es un cambio versionado y el bundle de evidencia se firma sobre la tripleta, la nube (plano de control) puede ensamblar el Anexo IV (EU AI Act Art. 11) directamente desde el bundle.json firmado. El motor no emite el Anexo IV: solo deja la evidencia firmada.

La procedencia por campo es declarada/derivada-bundle/derivada-git
No hay ningún paso manual de redacción del Anexo IV
El Anexo IV refleja el estado real del sistema en el momento del último sei run

El mecanismo está construido y demostrado en el escenario loan. La completitud es parcial: §7 y §8 del Anexo IV nunca quedan pendientes; §2/§3/§4/§9 pueden marcarse pendientes si falta su insumo. En loan, con datos, controles y medidas presentes, solo §3 y §9 aparecerían pendientes (ver Estado e incompletitudes).

Relevancia normativa

Cláusula	Cómo la cubre Venturalítica
ISO 23894 §6.4.2 — identificación	`git blame` + `sei assess` (KAG propone riesgos no declarados)
ISO 23894 §6.4.3 — análisis	Likelihood × impacto 5×5, nivel inherente en el bundle
ISO 23894 §6.4.4 — evaluación	Nivel inherente vs apetito; bloqueo por-criterio en `sei conformance`
ISO 23894 §6.5 — tratamiento y residual	Arco empírico FALLA→PASA por commit; clasificación del ciclo en `sei reconstruct`
EU AI Act Art. 9 — sistema de gestión de riesgos	Gate `sei run` (controles blocking); supervisión continua vía `sei status` en CI/CD
EU AI Act Art. 11 — documentación técnica	La nube ensambla el Anexo IV desde el bundle firmado (parcial)