Nivel 5 · Práctica y cierre
This content is not available in your language yet.
Ejecútalo tú mismo
Sección titulada «Ejecútalo tú mismo»El arco corre en la CPU de un portátil, sobre el conjunto de datos real Campus Placement (~215 filas; sin GPU, sin credenciales, sin datos sintéticos). El resultado de cada comando es exactamente la etiqueta enlazada en el arco.
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 (con la fuga) → ROJO en el único bloqueante. Compila el contrato de la barrera y córrela. froga run sale con código de error a propósito (el bloqueante falla), y aun así firma la evidencia — con los dos hallazgos advisory ya medidos junto al rojo:
froga compilegit add -Agit commit -m "compile: assessment plan OSCAL (contrato del gate, antes del modelo)"
patch: params.patchpatch: dvc.patchpatch: train.patchpatch: evaluate.patchpatch: compliance-eval.patchfroga runmay failgit add -Agit commit -m "modelo: gradient-boosting V1 (train/evaluate + dvc.yaml) — run: V1 evidencia base (gate RED esperado; seed=42)"
2 · Trata la fuga (retira salary) → VERDE. El tratamiento es un único cambio versionado: edita params.yaml a mitigate: true —el diff de abajo es exactamente lo que cambias— y regístralo con el mensaje del guion. El flip retira la característica con fuga y, en el mismo paso, vuelves a correr la barrera: como es el único control bloqueante, la barrera global cierra:
git checkout -b tratamiento/retira-salarypatch: params-mitigate.patchfroga rungit add -Agit commit -m "treatment: retira la feature fugada salary (mitigate false→true; cierra model-feature-leakage; data-sample-adequacy sigue abierto)"
El paso 080 reproduce talent-v1.0.0-red; el 090 reproduce talent-v2.0.0-green. Fíjate en lo que no cambia: data-sample-adequacy sigue midiendo 0,43 (215/500) y selection-rate-disparity-gender sigue subpoderada — ninguno de los dos es bloqueante, así que no impiden el VERDE, pero tampoco desaparecen: viajan advisory hasta la aprobación. Una tarea de CI nocturna re-clona cada etiqueta y confirma rojo → verde.
Lo que acabas de ver
Sección titulada «Lo que acabas de ver»Tu tercera superposición, esta vez en empleo: un clasificador de cribado de candidaturas de alto riesgo por el Anexo III §4 (la ruta de empleo / gestión de trabajadores — ni la ruta de producto Art. 6(1) de la retina ni la ruta de uso Anexo III §5(b) del crédito). El programa de riesgos lleva tres controles medidos sobre un mismo conjunto de etiquetas, pero solo uno es bloqueante. El bloqueante cerró: un control de fuga de característica estaba ROJO en V1 porque el modelo entrenaba sobre salary (presente solo para candidatos colocados → colineal con la etiqueta → fuga total, un defecto de seguridad Art.15); Marta activó mitigate: true, el pipeline quitó la característica salary, y model-feature-leakage pasó de ROJO→VERDE — como era el único bloqueante, la barrera global cerró VERDE. Los otros dos quedaron advisory: data-sample-adequacy (sample_adequacy_ratio 0.43 = 215/500) y selection-rate-disparity-gender (paridad de selección por sexo, subpoderada con n=215) se midieron de verdad en V1 y V2, sin cambios, pero su enforcement: audit significa que nunca bloquearon el gate — la decisión de gobernanza (Opción B) fue no fabricar un umbral bloqueante que la muestra de 215 filas, topada por el propio dataset público, no puede sostener con fiabilidad estadística. En la gobernanza, Diego aprobó el sistema en VERDE, aceptando conscientemente ese residual advisory con un motivo registrado y vigilancia post-mercado trimestral (Art.72) de la disparidad de selección — la cláusula 11 de prEN 18228 pasó de Gap a Cubierta al leer el acto de aprobación. El Art. 10 fue en profundidad (la unión 10(3)/(5): una muestra demasiado pequeña limita —pero no bloquea, porque se declara honestamente— la certificación de sesgos). El derecho laboral nacional (ET Art. 64.4.d) + RGPD Art. 22 anclan la obligación viva, con la legislación nacional en rango 0 → sin presunción. Y Aitor debutó: un auditor externo que ejecutó froga verify --pubkey sobre la firma auténtica, leyó el estado honesto VERDE, aprobado, con el residual advisory en acta y — al no ser un organismo notificado — no certificó. La idea que hay que retener: el motor certifica lo que puede medir con fiabilidad; documenta y vigila honestamente lo que la muestra no le permite certificar — sin fabricar ni un rojo permanente ni una certificación que los datos no sostienen.
Autocomprobación
Sección titulada «Autocomprobación»El programa de riesgos mide tres controles sobre el mismo conjunto de etiquetas, pero solo uno bloquea el gate. Describe los tres — qué mide cada uno, cuál cierra el arco, y por qué los otros dos son advisory en vez de gate.
El bloqueante — fuga de característica. El control model-feature-leakage (métrica leaky_feature_flag, barrera < 1.0, enforcement: gate) está 1.0 → ROJO en V1 porque el modelo entrena sobre salary, una característica presente solo para candidatos colocados (NaN→0 en los demás) y por tanto colineal con la etiqueta de colocación — fuga total, un defecto de seguridad (Art.15). Marta activa mitigate: true, el pipeline quita la característica salary, y el control marca 0.0 → VERDE en V2 — un ROJO→VERDE real por el tratamiento (retirar la característica, un cambio versionado de params.yaml, ISO 23894 §6.5), con un residual acotado (risk.feature-leakage: residual_likelihood: UNLIKELY → MEDIUM, dentro del apetito). Como es el ÚNICO control enforcement: gate del programa, su cierre basta para que la barrera global sea VERDE. Los dos advisory — adecuación de datos y equidad de selección. data-sample-adequacy (sample_adequacy_ratio, barrera ≥ 1.0) mide 0.43 (215/500) en V1 y en V2 — sin cambios, porque quitar una columna no añade filas. selection-rate-disparity-gender (demographic_parity_diff por sexo) se mide de verdad sobre la cohort test, pero con n=215 (≈24 mujeres) el resultado queda subpoderado. Ambos son enforcement: audit: se miden y se firman, pero no entran en el cómputo del veredicto bloqueante — la decisión de gobernanza fue que certificarlos como gate fabricaría un umbral que la muestra, estructuralmente topada en 215 filas, no puede sostener con fiabilidad.
Diego abre el sistema para aprobar y ve el gate en VERDE, pero con dos hallazgos advisory sin certificar. ¿Qué acepta exactamente al aprobar, y en qué se diferencia de la 'barrera roja' de la aceptación con motivo que ves en otros niveles?
Diego acepta el residual advisory de datos/equidad: data-sample-adequacy (n=215/500=0.43, sin residual_likelihood declarado porque no se puede estimar un residual sobre una muestra que no permite medirlo) y selection-rate-disparity-gender (medido, subpoderado con n=215). La diferencia con la «barrera roja» de otros niveles (residual-exceeds-appetite / untreated-above-appetite) es que aquellas aplican a un control bloqueante que el motor marcó como fallo o inconcluso, y la aprobación anula conscientemente ESE bloqueo. Aquí no hay bloqueo que anular: data-sample-adequacy y selection-rate-disparity-gender nunca fueron enforcement: gate — la decisión de gobernanza (Opción B) los declaró advisory antes de medir, precisamente para no fabricar un umbral bloqueante que la muestra no puede sostener. Lo que Diego acepta es un hallazgo documentado y medido, no una excepción a un veredicto técnico — mismo acto de gobernanza consciente (ISO 23894 §6.5.2 / 42001 6.1.3), sin el rojo/ámbar de por medio. Diego fija además vigilancia post-mercado trimestral (Art.72) sobre la disparidad de selección.
El sistema declara ET Art. 64.4.d y Ley 15/2022 (derecho nacional español). ¿Por qué la legislación nacional NO lleva presunción de conformidad, y qué significa eso para cómo el motor trata ET 64.4.d?
Porque la legislación nacional es una autoridad NationalLegislation en rango 0 en la cadena de autoridad tipada del motor. Una norma armonizada (o una norma gobernada como prEN 18228 / ISO 23894) puede conferir una presunción de conformidad — demuestra sus cláusulas y el veredicto significa algo legalmente. Una autoridad NationalLegislation no confiere esa presunción, pero sí puede proyectarse contra su propio catálogo. Y en concreto, ET Art. 64.4.d SÍ tiene catálogo de cláusulas cableado en el motor (et.64-4-d-transparencia-algoritmica), y su veredicto puede ser Covered — lo satisface el dossier firmado (el registro accesible de los parámetros, reglas e instrucciones del algoritmo). Lo que el rango 0 le niega es la presunción, no el veredicto: un Covered de ET 64.4.d es una obligación nacional satisfecha, nunca una presunción de conformidad del AI Act. La consecuencia práctica: la obligación viva de esta superposición se ancla en el derecho laboral nacional + RGPD (lo que realmente exigen ahora), no en la aplazada fecha de barrera de alto riesgo de la Ley de IA — pero «ET 64.4.d Covered» nunca debe leerse como «el AI Act se presume cumplido».
A dónde ir ahora
Sección titulada «A dónde ir ahora»Ya has conocido tu tercera superposición, la distinción entre un defecto de seguridad certificable y un límite de datos/equidad declarado, una aprobación legítima con residual advisory en acta, el ancla viva en el derecho nacional + RGPD, el Artículo 10 en profundidad y la verificación solo-con-clave-pública de Aitor. Para profundizar en los mecanismos que tocó este nivel: