Nivel 5 · En profundidad — Opción B, Aitor y el Artículo 10

§4 — Opción B: un defecto que se corrige, un límite que se declara

Este es el corazón del Nivel 5: tres controles miden lo mismo — un mismo tratamiento, un mismo conjunto de etiquetas —, pero solo uno puede convertirse en un veredicto bloqueante honesto. La decisión de gobernanza (que el curso llama Opción B) es distinguir el defecto certificable del límite estructuralmente no certificable, en vez de o bien bloquear sobre un umbral que la muestra no puede sostener, o bien fabricar un verde donde no lo hay.

Recuerda los tres controles del manifiesto firmado:

risk.feature-leakage — impacto {individual HIGH, organization HIGH}, probabilidad LIKELY; tratamiento = REDUCE (eliminar la característica salary con fuga), residual_likelihood: UNLIKELY → residual MEDIUM (dentro del apetito); control model-feature-leakage, enforcement: gate (el ÚNICO bloqueante del programa). Un defecto de seguridad (Art.15) que un cambio de código corrige y un control técnico confirma — plenamente resoluble, y de hecho resuelto en V2.
risk.inadequate-data — impacto {individual HIGH, society HIGH}, probabilidad LIKELY → inherente HIGH; tratamiento = REDUCE, pero la acción real es «adquirir ≥500 registros representativos» (Art.10(3), línea futura) — una brecha de DATOS, no un cambio de código; NO se declara residual_likelihood (no se puede estimar un residual sobre una muestra que no permite medirlo); control data-sample-adequacy, enforcement: audit — se mide, no bloquea.
risk.selection-fairness — impacto {individual HIGH, society HIGH}, probabilidad LIKELY; tratamiento = REDUCE con residual_likelihood: UNLIKELY → residual MEDIUM (dentro del apetito, como objetivo); control medido de no-discriminación selection-rate-disparity-gender, enforcement: audit (paridad de selección por sexo, cita Ley 15/2022 Art. 23). Se mide de verdad, pero con n=215 queda subpoderado — el objetivo declarado (residual_likelihood: UNLIKELY) es lo que se perseguía con el tratamiento; el runtime honesto es que la muestra no permite certificarlo, así que el control queda advisory en vez de gate.
Apetito: {individual: MEDIUM, society: MEDIUM, organization: HIGH}. overall_residual: nivel HIGH, criterio HIGH, evaluation = “within” — el residual agregado no excede el criterio global, y ningún riesgo queda above_appetite_untreated (los tres tienen bloque treat: declarado).

El hecho decisivo es que solo model-feature-leakage es enforcement: gate. Los otros dos son controles medidos, no declarativos (no son «hallazgos de auditoría manual» — el motor los mide con datos reales, demographic_parity_diff y sample_adequacy_ratio son números calculados, no casillas) pero su enforcement es audit: se calculan, se firman, se reportan — y no entran en el cómputo de blocks_gate(). Esa es la diferencia técnica precisa entre «no medimos esto» (que sería una brecha real) y «lo medimos, y medirlo con honestidad significa no fabricar un umbral bloqueante que la muestra no sostiene».

Por qué esto NO es lo mismo que la barrera roja de la aceptación con motivo

El curso enseña en otros niveles la «barrera roja» de la aceptación con motivo: un residual medido y bloqueante que queda por encima del apetito (residual-exceeds-appetite), o un riesgo sin tratar por encima del apetito (untreated-above-appetite). En ambos casos hay un veredicto bloqueante de por medio que la aprobación anula conscientemente. Aquí es distinto: data-sample-adequacy y selection-rate-disparity-gender nunca fueron gate — la decisión de gobernanza los declaró audit antes de que hubiera nada que aceptar en el sentido de la barrera roja. Lo que Diego acepta en la aprobación no es una excepción a un bloqueo técnico; es la aceptación consciente de un hallazgo advisory documentado — el mismo acto de gobernanza (ISO 23894 §6.5.2 / 42001 6.1.3), pero sin el veredicto rojo/ámbar de por medio. La honestidad no depende de si algo bloquea; depende de si se mide, se documenta y se vigila.

El paquete es criptográficamente válido en cada hito — y ahora el veredicto también es VERDE limpio

No confundas el veredicto con la integridad de la evidencia — como en los demás niveles, el paquete firmado se verifica en V1, V2, la solicitud y la aprobación: la firma es auténtica y los resúmenes están anclados en cada hito, incluido el V1 en rojo. Lo nuevo aquí es que, a diferencia de otros arcos de este curso, el veredicto en V2 es VERDE limpio: froga run sale con código 0, sin bandera ámbar ni roja — porque el único control bloqueante pasa y ningún control bloqueante queda inconcluso (selection-rate-disparity-gender y data-sample-adequacy no cuentan para el veredicto por no ser enforcement: gate). El VERDE no es una fachada: es lo que el motor certifica cuando el único defecto que declaró bloqueante está genuinamente corregido.

¿Qué es un riesgo?El vocabulario ROJO / ÁMBAR / VERDE, inherente vs. residual, apetito, y la diferencia entre un control gate (bloqueante) y un control audit (medido, advisory) — el eje que organiza la Opción B de este nivel.

§5 — Aitor verifica (y no certifica)

Este nivel presenta una persona nueva: Aitor, un auditor externo / comprador. Mientras que Nerea (producto), Diego (Calidad) y Marta (ingeniera) trabajan dentro de Example Talent Corp, Aitor está fuera — una contraparte que necesita saber si la evidencia firmada del proveedor es auténtica y en qué estado está.

Aitor ejecuta un comando:

# Aitor tiene SOLO la clave pública del proveedor — sin clave privada, sin datos de origen, sin modelo.
froga verify --pubkey <clave-publica-del-proveedor>
# → confirma: la firma es AUTÉNTICA (el paquete es lo que el firmante dice que es)
# → y lee el estado honesto: barrera VERDE, ciclo APROBADO, con el residual advisory de datos/equidad en acta

Pasan dos cosas, y ambas importan. Primero, la firma se verifica: con solo la clave pública — sin clave privada, sin datos que salgan del proveedor — Aitor confirma que el paquete es auténtico, exactamente lo que el firmante confirmó (Marta la evidencia, Diego la aprobación). Segundo, Aitor lee el estado honesto completo: puede ver que la barrera es VERDE, que el ciclo está aprobado, y que el acto de aprobación de Diego lleva anclado el motivo de la aceptación consciente del residual advisory (adecuación de datos + equidad de selección, ambos con n=215). El motor no oculta el residual a un verificador externo detrás de un «VERDE» limpio: la evidencia dice la verdad completa a todos los que tienen la clave pública — incluida la parte que no se certificó.

Aitor verifica autenticidad — NO certifica conformidad

Aitor no es un organismo notificado y no certifica. Verificar una firma confirma que la evidencia es lo que el firmante dice que es — no confirma que el producto cumple la ley. Que Aitor lea «las firmas verifican, la barrera está VERDE y el residual advisory está en acta» es un juicio de contratación / aceptación (un comprador decidiendo si confía en la evidencia de un proveedor y en su estado honesto, incluido lo que el proveedor eligió NO certificar), no un juicio de conformidad (un organismo acreditado e independiente emitiendo un certificado reconocido). No tiene acreditación, ni designación en NANDO, ni certificado que emitir. Su valor es exactamente su honestidad: puede establecer autenticidad y leer el estado completo — el verde certificado y el advisory documentado por igual — y le dice la verdad a su mandante.

Organismo notificado o autodeclaraciónDónde encaja Aitor: un auditor externo / comprador que ejecuta froga verify solo con una clave pública para confirmar autenticidad y leer el estado — pero que NO es un organismo notificado y NO certifica. La página traza la línea nítida entre verificar una firma y certificar conformidad.

§6 — El Artículo 10 en profundidad, y los Artículos 9 / 13 / 14 revisitados

Cada nivel profundiza en un artículo de la columna vertebral de los artículos 9 a 15. El del Nivel 4 fue el Art. 12 (registro de actividades). El artículo en profundidad del Nivel 5 es el Art. 10 (datos y gobernanza de los datos) — porque es exactamente donde vive la distinción entre lo certificable y lo declarable.

Art. 10 (gobernanza de datos) — el artículo en profundidad. El límite de datos/equidad se sitúa en la unión de dos apartados:

El Art. 10(3) exige conjuntos de datos de entrenamiento/validación/prueba que sean pertinentes, suficientemente representativos y, en la mayor medida posible, exentos de errores y completos en vista de la finalidad prevista. Una muestra de n=215 para una afirmación de equidad de selección es justamente de lo que trata el 10(3): no es suficientemente representativa ni completa para certificar que la selección es justa. data-sample-adequacy (sample_adequacy_ratio 0.43) es la expresión medida por el motor de una insuficiencia del Art. 10(3) — y precisamente por eso el control es audit, no gate: certificar contra un umbral que la muestra no puede sostener sería el error opuesto.
El Art. 10(5) permite procesar datos de categoría especial estrictamente para la detección y corrección de sesgos en sistemas de alto riesgo. El truco: no puedes hacer la detección de sesgos del 10(5) sin una muestra adecuada según el 10(3). Con demasiado pocos registros, ni siquiera el procesamiento de categoría especial que permite el 10(5) puede producir una medición de equidad defendible con la fiabilidad que exigiría un gate bloqueante. Así que los dos apartados están vinculados: la brecha del 10(3) limita la certificación del 10(5) — que es precisamente por qué selection-rate-disparity-gender se mide, se documenta y se acepta conscientemente, en vez de bloquear o de certificarse.

La brecha de datos — cuando el residual no puede medirseLa página complementaria de Fundamentos que fundamenta el Art. 10(3)/(5): una muestra inadecuada según el 10(3) limita la certificación de sesgos del 10(5). Esta demo resuelve el caso con Opción B (advisory + aceptación consciente); la página también cubre el caso hermano donde el motor bloquea con un hard-block de integridad.

Los demás artículos de la columna vertebral se repasan brevemente, todos declarados / solo de auditoría aquí (rastreados, no sujetos a barrera):

Art. 9 (gestión de riesgos). El mismo programa de risk impulsa el sistema: apetito {individual MEDIUM, society MEDIUM, organization HIGH}, la matriz 5×5, el criterio de residual global (HIGH, evaluación within) y los tres controles (un bloqueante + dos advisory). Fíjate en la honestidad: el overall_residual.evaluation es “within” y ningún riesgo queda above_appetite_untreated (los tres tienen treat: declarado) — el motor no necesita forzar el residual agregado para reflejar que el sistema sale a mercado con un límite conscientemente aceptado, no con un incumplimiento oculto.
Art. 13 (transparencia hacia el candidato). Declarado (solo de auditoría): se debe informar al candidato de que un sistema automatizado lo criba, ligado a los deberes de transparencia del RGPD. No es una barrera medida.
Art. 14 (supervisión humana / HITL). Declarado (solo de auditoría), anclado al derecho del RGPD Art. 22 a la intervención humana en una decisión automatizada significativa. El humano en el bucle se nombra y rastrea, pero — honestamente — es un compromiso declarado, no un control medido, y el RGPD Art. 22 está declarado, no litigado (sin DPIA cláusula a cláusula; SCC/DPA pendientes).

El mapa de modalidades — dónde se sitúa este nivel

El curso nombra la clase de tratamiento y la clase de control en cada nivel. Aquí:

El bloqueante (cierra) — modalidad de tratamiento: un cambio de código — mitigate: true quita la característica salary con fuga. Control: model-feature-leakage (leaky_feature_flag, objetivo, bloqueante, enforcement: gate), ROJO→VERDE. Residual acotado (UNLIKELY → MEDIUM, dentro del apetito). Contrasta el Nivel 1 (un cambio de parámetro), el Nivel 3 (un cambio de código que cierra limpio), el Nivel 4 (un cambio de aprendiz con fairlearn que cierra con un residual en acta).
Adecuación de datos (advisory) — modalidad de tratamiento: una acción de datos — adquirir ≥500 registros representativos, que no es un commit. Control: data-sample-adequacy (sample_adequacy_ratio, objetivo, medido, enforcement: audit), sin cambios entre V1 y V2. Sin residual acotado (residual_likelihood ausente) → se documenta y se acepta conscientemente en la aprobación, sin bloquear.
Equidad de selección (advisory, subpoderada) — modalidad de tratamiento: selection-rate-disparity-gender (demographic_parity_diff por sexo, medido, enforcement: audit, cita Ley 15/2022 Art. 23). Se mide de verdad, pero n=215 lo deja subpoderado. Declara residual_likelihood como objetivo (UNLIKELY), pero el runtime honesto es advisory; su lectura remite a la adquisición de datos.
Artículo en profundidad: Art. 10 (gobernanza de datos) — la unión 10(3)/(5) donde vive la distinción certificable/declarable.
Estado final: VERDE, aprobado, con el residual advisory de datos/equidad conscientemente aceptado y vigilado post-mercado (Art.72).