Los dos gates: frescura y riesgo

El flujo RDD exige pasar dos gates secuenciales antes de afirmar conformidad. Ninguno sustituye al otro: una evidencia fresca con métricas fuera de umbral no es conforme, y unas métricas válidas sobre evidencia obsoleta tampoco.

Gate 1 — Frescura

Pregunta: ¿la evidencia firmada está al día respecto a sei.lock?

sei status compara los digests actuales de la tripleta (código, modelo, dataset) con los anclajes en sei.lock. Si cualquier digest ha divergido, el gate de frescura falla:

sei status          # exit 0 → fresco; exit ≠ 0 → obsoleto

Este gate puede integrarse como condición necesaria en cualquier pipeline CI/CD. Su fallo no indica un problema de métricas; indica que el bundle firmado no describe el sistema que está en ejecución, lo que hace inválida cualquier afirmación de conformidad sobre él.

La lógica del gate de frescura se describe en detalle en Deriva tipada.

Gate 2 — Riesgo

Pregunta: ¿pasan todos los controles blocking sus umbrales?

sei run ejecuta el pipeline, mide las métricas y evalúa cada control declarado en sei.yaml (ISO 23894 §6.4.4 — evaluación del riesgo vs apetito). Si algún control blocking supera su umbral, el gate de riesgo falla con exit ≠ 0:

sei run             # exit 0 → todos los controles blocking en verde

El bundle de evidencia se firma y ancla independientemente del resultado del gate: la evidencia del fallo también queda registrada, lo que permite trazar el arco empírico FALLA → PASA a través de los commits de tratamiento.

Los detalles de cómo un control define el estado rojo/verde están en El bucle rojo/verde.

El flujo combinado

sei status          →  gate 1: ¿fresco?
   ↓ (exit 0)
sei run             →  gate 2: ¿riesgo dentro del apetito?
   ↓ (exit 0)
sei conformance     →  proyección sobre catálogos ISO 23894 / prEN 18228

Ambos gates deben estar verdes para que sei conformance emita una conformidad sin bloqueos. Un gate rojo en cualquiera de los dos pasos interrumpe la cadena.

Los dos escenarios, el mismo motor

Los escenarios de demostración —loan y medical— colapsan al mismo motor porque el motor no distingue entre tipos de tratamiento, solo entre colores de gate:

Escenario	Tipo de tratamiento	Marco regulatorio
`loan` (crédito, EU AI Act Anexo III §5)	Cambio de código (V1 → V2)	DORA
`retinopathy` (retina, EU AI Act Anexo III §6)	Ajuste de parámetro (`params.yaml: use_mitigated: false → true`)	EU AI Act
`medical` (imagen médica, EU AI Act Anexo III §6)	Supervisión humana HOTL (Art.14)	MDR

El campo frameworks en la evidencia firmada dirige la proyección a los catálogos de cláusulas correspondientes (sei conformance --standard eu/pren-18228@2026 / --standard iso/23894@2023). El mismo bundle se proyecta sobre marcos distintos.

Las modalidades de tratamiento (cambio de código, ajuste de parámetro, ajuste de prompt) se describen en Modalidades de tratamiento.

Relevancia normativa

Gate	Cláusula cubierta
Gate 1 (frescura)	EU AI Act Art. 9(1)(d) — supervisión continua; ISO 23894 §6.5 (evidencia del tratamiento)
Gate 2 (riesgo)	ISO 23894 §6.4.4 — evaluación vs apetito; EU AI Act Art. 9(2) — proporcionalidad de controles
`sei conformance` post-gates	ISO 23894 §6.4–§6.5 completo; prEN 18228 §9–§10; EU AI Act Art. 9 y Art. 11 (parcial)

Consulta la Referencia del CLI sei para los flags de sei status, sei run y sei conformance.