Nivel 1 · Práctica y cierre
Ejecútalo tú mismo
Sección titulada «Ejecútalo tú mismo»El arco completo corre en la CPU de un portátil, sobre el conjunto de datos Iris de ~5 KB (flores reales, Fisher 1936; dominio público). Sin GPU, sin credenciales de Kaggle, sin datos sensibles — cero fricción. Usa el chip del hito V1 (en el arco) para clonar el repositorio y situarte en el punto de partida, e instala las dependencias del proyecto:
uv sync # instala las deps del pyproject.toml + uv.lock (reproducible)Con el entorno del proyecto activo, reproduce el arco. Cada bloque de abajo es el paso REAL del guion steps/ —el mismo que construye el repositorio publicado, no una copia a mano—; el botón «copiar» te da el comando exacto:
1 · Mide la V1 (solo sépalo) → ROJO. Compila el contrato de la barrera desde froga.yaml y córrela. froga run sale con código de error a propósito (barrera roja), y aun así firma la evidencia:
froga compilegit add -Agit commit -m "compile: assessment plan OSCAL (contrato del gate, antes del modelo)"
patch: params.patchpatch: dvc-evaluate.patchpatch: train.patchpatch: evaluate.patchpatch: compliance-eval.patchfroga runpuede fallargit add -Agit commit -m "modelo: logreg V1 solo-sépalo (train/evaluate + dvc.yaml) — run: V1 evidencia base (gate RED esperado; seed=42)"git push -u origin main
2 · Trata el riesgo y vuelve a medir → VERDE. El tratamiento es un único cambio versionado: edita train.py para añadir petal_length y petal_width a la lista FEATURES del modelo —el diff de abajo es exactamente lo que cambias— y regístralo con el mensaje que ves, el mismo que usa el guion; en el mismo paso vuelves a correr la barrera y, con los pétalos dentro, la exhaustividad macro sube y cierra en verde:
git checkout -b tratamiento/anadir-petalospatch: train-petals.patchfroga rungit add -Agit commit -m "treatment: añade las features de pétalo (las discriminativas) — ISO 23894 §6.5"git push -u origin tratamiento/anadir-petalosfroga pr open --base main --title "iris V2: features de pétalo (cierra el gate de recall)"
Cada paso llega al mismo color de barrera que su etiqueta: el paso 080 reproduce iris-v0.1.0-red, el 090 reproduce iris-v0.2.0-green. Una tarea de CI nocturna vuelve a clonar cada etiqueta y comprueba que el color sigue coincidiendo, así que los enlaces nunca se pudren silenciosamente.
Lo que acabas de construir
Sección titulada «Lo que acabas de construir»Un sistema de IA declarado, clasificado, tratado, con la evidencia firmada en git, que cierra limpiamente en VERDE — y un bucle ISO 23894 completo ejecutado sobre un sistema que ninguna ley toca. El riesgo era real (el solapamiento versicolor/virginica en el espacio del sépalo es un hecho sobre las flores), el tratamiento fue un commit versionado (añadir las características del pétalo), el residual quedó confirmado por un control que pasó (exhaustividad macro 0,81 → 0,95) y la aprobación es un acto firmado .froga/acts/NNNN-approve.json que solo Diego pudo producir (firmado con su clave). Responsabilidad dividida como debe ser: Marta aportó y firmó la evidencia desde la CLI; Diego declaró el riesgo, revisó y aprobó desde el portal.
Lo hicimos todo porque es buena ingeniería, no porque nadie nos obligara. Esa es la lección completa del Nivel 1. En el Nivel 2 entra la ley — un sistema de selección de estudiantes que sí es de alto riesgo según el EU AI Act — y la honestidad se complica: el control de equidad sale ÁMBAR (poca potencia), y el sistema cierra con brechas, no en verde.
Autocomprobación
Sección titulada «Autocomprobación»No aplica ninguna ley a un clasificador de flores. ¿Para qué ejecutar un bucle de riesgo entonces?
Porque la gestión del riesgo es buena ingeniería, independiente de cualquier obligación legal. El bucle es la forma de descubrir, de forma deliberada, dónde es débil tu sistema — aquí, que un modelo solo-sépalo confunde dos especies — y demostrar que lo has tratado. El Nivel 1 elige deliberadamente un sistema que ninguna ley toca (flores, fuera del Anexo III del EU AI Act) para que el punto sea irrefutable: el método aporta valor por sus propios méritos. La ley llega en el Nivel 2; el valor del método no depende de ella.
¿Qué fue exactamente el tratamiento, y por qué cambió la barrera de ROJO a VERDE?
El tratamiento fue un cambio de código: añadir petal_length y petal_width a la lista FEATURES de train.py, para que el modelo use también las medidas de pétalo. Las características del pétalo son las discriminativas — separan a versicolor de virginica con claridad, mientras que las del sépalo se solapan. Con los pétalos, la exhaustividad macro subió de 0,81 (ROJO, por debajo de la barrera > 0,90) a 0,95 (VERDE). Y lo esencial: el cambio vive en git como un commit, así que el motor atribuye el cierre del riesgo a él (el evento de tratamiento) y el residual queda confirmado por un control que pasa, no meramente declarado.
¿Por qué Marta firma pero Diego aprueba — y podría Marta aprobar ella misma?
Son responsabilidades diferentes, aplicadas por rol. Marta (maintainer) trata, mide y firma la evidencia técnica — su firma demuestra autoría e integridad. Diego (owner) es la autoridad de aprobación: revisa la evidencia y aprueba, aceptando el riesgo residual. El motor no cuenta una aprobación firmada con la clave que solicitó, así que Marta no puede aprobar su propia solicitud aunque ejecute froga approve — la persona que produce la evidencia no es quien acepta el riesgo. La aprobación queda registrada como un acto DSSE firmado (.froga/acts/NNNN-approve.json) con la identidad de Diego, no como un clic en una base de datos.