Nivel 4 · Práctica y cierre
This content is not available in your language yet.
Ejecútalo tú mismo
Sección titulada «Ejecútalo tú mismo»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 (incluye fairlearn)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 (sin mitigar) → ÁMBAR. Primero compila el contrato de la barrera; luego añade el modelo base y córrelo. El punto NO pasa (≈ 0,1050 > 0,092), pero el IC bootstrap 95% cruza la línea por el extremo inferior (ci_low ≈ 0,0425, medido OUT-OF-FOLD sobre las 1.000 filas, 5-fold) → INCONCLUSO:
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 runmay failgit add -Agit commit -m "modelo: logreg base V1 sin mitigación (train/evaluate + dvc.yaml) — run: V1 evidencia base (gate ÁMBAR infrapotenciado; seed=42)"
Lee la evidencia que produjo la ejecución — tu PROPIO paquete firmado: .froga/bundle.json → control_results[unfair-credit-exclusion] muestra actual_value ≈ 0,1050, threshold 0,092, passed: false, y power.ci_low ≈ 0,0425 / power.ci_high ≈ 0,1702 — el intervalo cruza el umbral → ÁMBAR / inconcluso (ni un rojo concluyente ni un verde limpio), con potencia real (n=1.000, no n=200).
2 · Trata el riesgo (activa el aprendizaje justo) → VERDE. El tratamiento es un único cambio versionado: reemplaza train.py —el diff de abajo es exactamente lo que cambias— y regístralo con el mensaje del guion. El estimador pasa de una regresión logística plana al ExponentiatedGradient(DemographicParity) de fairlearn:
git checkout -b tratamiento/mitiga-paridadpatch: train.patchfroga runmay failgit add -Agit commit -m "treatment: aplica mitigación de paridad demográfica (fairlearn DemographicParity) sobre el sexo — ISO 23894 §6.5"
El paso 2 es el núcleo honesto: con la MISMA potencia (1.000 filas, OOF) la barrera aterriza en VERDE, porque esta vez el IC bootstrap entero (ci_high ≈ 0,0645) queda por debajo del umbral — el motor lo informa honestamente en cuanto la evidencia lo demuestra, ni antes ni después. El paso 080 reproduce loan-v1.0.0-amber; el 100 reproduce loan-v2.0.0-green.
3 · Revisión periódica: la cadena de aprobaciones. El arco no termina en la aprobación del hito 5. El froga.yaml declaró review_interval: P6M: pasados seis meses, el sistema entra en su revisión periódica (ISO 23894 §6.6). Aquí no hay nada que re-medir —el doble residual de gobernanza (proxy + opacidad) es una decisión, no un número—, así que la revisión y la re-aprobación son actos de gobernanza sobre el mismo bundle V2, sin froga run entre medias:
Reason: «Re-aprobación tras la revisión periódica (P6M) sobre la MISMA evidencia vigente: se re-confirma la aceptación consciente del doble residual (proxy-discrimination above-appetite sin tratar + opacidad por encima del apetito). El aprobador efectivo del expediente pasa a ser esta re-aprobación (cadena aprobar→revisar→re-aprobar).»
La revisión (froga review) reabre el ciclo —el motor pasa el sistema a «en revisión» y suspende la aprobación— y la re-aprobación (froga approve) lo re-cierra. El efecto interesante está en el expediente: ya no hay una aprobación sino una cadena — aprobar → revisar → re-aprobar —, y el motor marca al aprobador efectivo, el último acto de aprobación que cubre la evidencia vigente (la re-aprobación). El paso 080 reproduce loan-v1.0.0-amber; el 100, loan-v2.0.0-green; y la re-aprobación queda en loan-v2.0.0-reapproved.
Lo que acabas de ver
Sección titulada «Lo que acabas de ver»Tu segunda superposición, esta vez en finanzas: un modelo de puntuación de crédito al consumo bajo dos regímenes a la vez — de alto riesgo bajo la Ley de IA de la UE (vía Anexo III §5(b), la ruta del uso, en contraste con la ruta de producto Art. 6(1) de la retina) y DORA, porque el operador es una entidad financiera, por lo que el modelo es un activo TIC. La barrera de equidad fue ÁMBAR → VERDE honesto: medida OUT-OF-FOLD sobre las 1.000 filas (5-fold, no un held-out de 200), la V1 sin tratar era inconclusa (punto 0,1050 por encima de la barrera, pero el IC bootstrap cruza por el extremo inferior, 0,0425), y el tratamiento DemographicParity de fairlearn bajó el número (punto 0,0065) y cerró la potencia (el IC entero queda por debajo, ci_high ≈ 0,0645) — así que el motor certificó un veredicto que esta vez su evidencia sí podía demostrar. Al revisar la V1, Nerea identificó un segundo riesgo (A.1.c): proxy-discrimination —el código postal como proxy de origen étnico— que dejó above-appetite sin tratar; no cambia el color de la barrera, pero abre una puerta en la aprobación. El ciclo cerró con una aprobación legítima — solicitud + aprobación que acepta conscientemente el doble residual de gobernanza (el proxy sin tratar y el residual de opacidad — la equidad ya no es parte de lo que se acepta, está resuelta), con el motivo en el acta del portal (cl. 11 pasa de Gap a Cubierta) — porque el crédito §5(b) se autodeclara (sin organismo externo), a diferencia de la pausa de la retina. El Art. 12 fue en profundidad como registro de actividades git-nativo, ex ante (el grafo de commits es el registro; los actos firmados .froga/acts/ y el pipeline_lock_digest), y DORA aportó un Registro de Información firmado (xBRL-OIM) — un entregable, nunca un veredicto. La línea que hay que retener: el veredicto de equidad es Ley de IA / ISO (VERDE tras el tratamiento); DORA es documentación — nunca «DORA gobernada». Y un sexto hito: la revisión periódica (P6M) reabre la aprobación sobre el mismo bundle y forma una cadena aprobar → revisar → re-aprobar; el motor expone la cadena entera y marca al aprobador efectivo —el último responsable del expediente— con froga status y el portal ahora de acuerdo (issue #667).
Autocomprobación
Sección titulada «Autocomprobación»Nerea declara risk.proxy-discrimination al revisar la V1 pero NO lo trata. ¿Por qué el color de la barrera no cambia — y qué obliga entonces ese riesgo?
Porque el color de la barrera lo pintan los controles medidos (control_results), y un riesgo identificado pero sin tratar no lleva ningún bloque treat: ni ninguna medida, así que no aporta ningún control_result — no hay número que compare contra un umbral, luego la barrera se queda como estaba (ÁMBAR por la disparidad de V1, medida OOF y aún sin tratar). Lo que hace el proxy no es pintar de rojo: al quedar above-appetite (impacto individual ALTO × probabilidad PROBABLE, por encima del apetito individual), abre una puerta en la aprobación — el motor exige que alguien lo acepte conscientemente, con motivo, o el sistema no se aprueba. Es el beat A.1.c del proceso ISO 23894 (§6.4.2, análisis del riesgo): el riesgo aflora al examinar el modelo, no al declararlo de antemano, y su residual viaja hasta la decisión de gobernanza en vez de desaparecer.
En la revisión periódica, Diego re-aprueba el MISMO bundle sin volver a medir. ¿Qué es la 'cadena de aprobaciones' que aparece entonces, y quién es el 'aprobador efectivo'?
Al re-aprobar sobre el mismo bundle (la revisión de un residual de gobernanza no exige re-medir: no hay parámetro que cambiar), el expediente deja de tener una aprobación y pasa a tener una cadena de actos: aprobar (hito 5) → revisar (la revisión P6M) → re-aprobar. El motor la expone entera —ninguna aprobación se descarta, es la traza que exige la trazabilidad del Art. 12— y marca al aprobador efectivo: el último acto de aprobación que cubre la evidencia vigente, es decir, la re-aprobación. En esta demo las dos aprobaciones son de Diego, así que el efectivo es su re-aprobación (el commit más reciente), no la aprobación original. Lo que cierra el issue #667 es que froga status (la CLI) y el portal ahora coinciden en cuál es el efectivo — ambos apuntan a la re-aprobación —; antes divergían (la CLI mostraba la original, el portal la re-aprobación), dando dos «últimos responsables» distintos para el mismo sistema. Contrasta con el Nivel 2: allí la revisión sí devolvió a medir, y como hubo evidencia nueva la cadena arrancó de cero (un solo acto sobre el bundle fresco); aquí, sin evidencia nueva, la cadena crece sobre el mismo bundle.
El motor ensambla un Registro de Información DORA para este sistema. ¿Por qué eso es un 'entregable, no un veredicto', y por qué nunca debes decir que el sistema está 'DORA gobernado'?
Porque DORA es derecho sectorial vinculante, no una norma armonizada de gestión del riesgo en IA citada para el artículo 9 — así que se sitúa fuera de la cadena de autoridad de veredictos del motor y no confiere ninguna presunción. La salida DORA es por tanto un entregable firmado + cruce documental: el motor proyecta lo que se midió y declaró en la plantilla de Registro de Información xBRL-OIM de las AES (B_01.01 entidad / B_07.01 función TIC / B_05.01 terceros del ML-BOM) — documentación que un responsable de cumplimiento entrega a un supervisor, la contrapartida financiera del cruce documental MDR de la retina. No es una declaración de que el sistema «es conforme a DORA». Concretamente, ninguna medida en el manifiesto cita una cláusula dora.* (DORA es solo una etiqueta frameworks consultiva), así que no hay veredicto por cláusula que enseñar — enseñas el Registro, no la cobertura de cláusulas. El veredicto de conformidad sobre la equidad del modelo pertenece a la Ley de IA / ISO 23894, y en esta demo cierra en VERDE tras el tratamiento (medido con potencia real, OOF sobre las 1.000 filas). Llamar al sistema «DORA gobernado» porque lleva un Registro es exactamente la reclamación excesiva a evitar: DORA es resiliencia operativa digital TIC, no gobernanza de modelo.
La barrera de equidad es ÁMBAR en V1 y pasa a VERDE tras el tratamiento con fairlearn. ¿Por qué ÁMBAR → VERDE es el veredicto honesto aquí, y no una historia ROJO → VERDE fabricada ni un ÁMBAR forzado por falta de datos?
Porque el conjunto se mide con potencia real: las 1.000 filas del dataset, cada una con una predicción OUT-OF-FOLD (5-fold StratifiedKFold — ninguna fila la predice un modelo que la vio entrenar), no un held-out de 200. En V1 el demographic_parity_diff medido ≈ 0,1050 queda por encima de la barrera < 0,092, y el IC 95% bootstrap va de 0,0425 a 0,1702 — cruza la línea por el extremo inferior — así que el intervalo no puede demostrar la violación con certeza y el motor activa inconclusive() → ÁMBAR. El tratamiento DemographicParity de fairlearn baja entonces el número a ≈ 0,0065 y esta vez el IC entero queda por debajo del umbral (ci_high ≈ 0,0645) — el tratamiento demuestra el residual, con la misma potencia que dejó V1 en ÁMBAR — así que el veredicto pasa a VERDE concluyente. Fabricar un ROJO o un VERDE que los datos no pudieran soportar violaría la regla de honestidad del motor: nunca reclama más certeza de la que lleva su evidencia — y tampoco se queda en ÁMBAR una vez que la evidencia sí demuestra el residual. ÁMBAR y VERDE limpio (como en la retina, n ≈ 1.279) son la misma regla honesta aplicada a la evidencia disponible en cada momento del arco.
El artículo 12 se enseña aquí como 'registro de actividades git-nativo'. ¿Qué significa eso, qué habilita y dónde está su límite honesto?
Significa que el grafo de commits es el registro: los eventos de gobernanza son commits que llevan actos firmados, el estado del ciclo de vida vive en los actos firmados del ledger .froga/acts/ (NNNN-request.json, NNNN-approve.json) en lugar de en un campo de base de datos mutable, y el paquete firmado fija exactamente lo que se aprobó mediante el pipeline_lock_digest (modelo + datos + parámetros + umbral + residual). Es un entregable / pista de papel, no un control de barrera — no hay «Art. 12 ROJO»; su calidad es completitud y resistencia a la manipulación. Lo que habilita es el derecho a revisión humana de una decisión crediticia automatizada (RGPD Art. 22 / TJUE SCHUFA, C-634/21): un revisor puede hacer git diff del modelo, datos, umbral y residual firmado para ver exactamente qué se decidió y por qué. Su límite honesto: el Art. 12 git-nativo cubre código / modelo / conjunto de datos / reproducibilidad de decisiones, no resiliencia de infraestructura (copias de seguridad, RTO/RPO, conmutación por error, pruebas de penetración, clasificación de incidentes) — esos son registros operativos TIC que pertenecen al mundo de DORA, no al registro de reproducibilidad.
A dónde ir ahora
Sección titulada «A dónde ir ahora»Ya has conocido tu segunda superposición, el arco ÁMBAR→VERDE honesto, el riesgo de proxy sin tratar del beat A.1.c, una aprobación legítima que acepta conscientemente el doble residual de gobernanza (proxy + opacidad), el Art. 12 git-nativo y la regla del entregable-no-veredicto de DORA. Para profundizar en los regímenes que tocó este nivel: