El AssuranceProgram vivo

El AssuranceProgram no es un documento que se redacta al inicio y se archiva. Es un registro vivo que crece durante el desarrollo, siguiendo el mandato de identificación continua de riesgos de la ISO 23894 §6.4.2.

---

git blame como registro de auditoría de identificación

En Venturalítica, el AssuranceProgram no es un fichero aparte: vive inline en froga.yaml, en la sección risk: (junto a context: y system.potential_misuses). Cada riesgo que se añade al registro es un cambio versionado a ese fichero: tiene un autor, una fecha y un mensaje de commit que explica por qué se identificó.

Auditar la historia de identificación de riesgos

git log --follow -p froga.yaml             # historia completa del manifiesto, incluida la sección risk:
git blame froga.yaml                       # quién añadió cada riesgo y cuándo
git log -S "unfair-credit-exclusion"     # primer commit que introdujo ese riesgo

Esta trazabilidad satisface el requisito de identificación continua de la ISO 23894 §6.4.2 sin ninguna infraestructura adicional. La pregunta “¿quién identificó este riesgo y cuándo?” tiene respuesta exacta en el historial git.

---

Procedencia por riesgo

Cada riesgo en el AssuranceProgram lleva un campo provenance que clasifica su origen:

Valor	Significado
declared (por defecto)	El operador lo identificó directamente y lo añadió al registro
proposed_by_kag	Reservado para riesgos de identificación asistida (el dominio del KAG futuro). Hoy el operador puede marcarlo a mano para distinguir un riesgo emergente —detectado a mitad del desarrollo— de los declarados al inicio
derived_from_gap	Emergió de un data_gap detectado por el motor (EU AI Act Art. 10(5)) y propagado como riesgo de sesgo

La procedencia no afecta al tratamiento del riesgo: un riesgo proposed_by_kag sigue el mismo ciclo ISO 23894 que uno declared. Su función es de auditoría: permite identificar qué parte del registro proviene de identificación asistida y qué parte de declaración directa.

---

Identificación hoy (humana) y el KAG (línea futura)

Hoy la identificación de riesgos la realiza el humano: el equipo declara los riesgos a mano en la sección risk: de froga.yaml. El KAG (Knowledge Assessment Graph) será, en el futuro, el componente que asista esa identificación proponiendo riesgos candidatos a partir del contexto del sistema. Hoy no está disponible —el mock determinista se eliminó para no simular automatización— y froga assess es un stub honesto que recuerda declarar la evaluación a mano.

Los momentos en que conviene revisar si han emergido riesgos nuevos (hoy lo hace el equipo; el KAG los asistirá en el futuro):

• Deriva detectada — froga status reporta un artefacto STALE
• Data gap — el motor detecta insuficiencia estadística (SUBPODERADO) y la señala como data_gap
• Ciclo de reporting — revisión periódica de conformidad (EU AI Act Art. 72 para incidentes graves)
• Revisión directa — el equipo revisa el registro en cualquier momento del desarrollo

La identificación es humana y deliberada: ningún componente añade riesgos automáticamente al AssuranceProgram. El equipo los declara, los analiza y commitea los cambios.

El humano declara; froga.yaml es el registro; froga compile genera OSCAL

La evaluación (clasificación + riesgos) se declara a mano en froga.yaml (el registro de riesgos vive ahí). El motor no infiere ni propone nada: froga run lee esa declaración directamente. El OSCAL (assessment_plan, Open Security Controls Assessment Language) lo genera froga compile a partir de froga.yaml. Al vivir el registro en git, el git blame sobre froga.yaml es el audit log de identificación; no se necesita ningún sistema externo de trazabilidad. El KAG, cuando exista, asistirá esta declaración sin sustituir el juicio humano.

---

El escenario loan_growth: un riesgo emergente

El escenario loan_growth —una variante del escenario loan, no un demostrador independiente— ilustra cómo el AssuranceProgram crece durante el desarrollo. A mitad del ciclo de desarrollo del modelo de crédito, emerge un riesgo de discriminación por edad que no estaba declarado en el registro inicial.

El flujo es:

1. El equipo identifica, mediante análisis de la decisión, que el grupo de edad >60 tiene una tasa de aprobación significativamente diferente al resto.
2. Declara el riesgo age_discrimination a mano, con procedencia proposed_by_kag (identificación asistida: la clase que el KAG futuro propondrá).
3. Lo añade al registro y commitea:

Declarar un riesgo emergente (identificación asistida)

# Añadir el riesgo a la sección risk: de froga.yaml
git add froga.yaml
git commit -m "risk(loan): añadir riesgo age_discrimination (identificación asistida)"

4. El nuevo riesgo activa una nueva iteración del ciclo ISO 23894: identificación → análisis → evaluación → tratamiento → residual.
5. froga reconstruct puede reconstruir ese arco desde el commit en que el riesgo apareció (git log -S "age_discrimination" froga.yaml).

Este patrón demuestra que el AssuranceProgram no es un artefacto estático de cumplimiento inicial; es el registro operativo del ciclo de vida de riesgos durante el desarrollo.

---

Compilación del AssuranceProgram

El AssuranceProgram completo (riesgos + análisis + evidencia) se compila en el bundle firmado mediante:

Compilar el AssuranceProgram en el bundle

froga compile         # lee la sección risk: de froga.yaml y genera el OSCAL assessment_plan
froga run             # re-mide y escribe el bundle firmado (.froga/bundle.json)

Consulta la Referencia del CLI froga para el detalle de froga compile y froga run, y la guía de identificación de riesgos para el flujo completo.