La brecha de datos (Artículo 10)

⚡ TL;DR

La mayoría de los riesgos que encuentras en este curso tienen un tratamiento que puedes escribir: quitar una característica con fuga, cambiar a un aprendiz con restricción de equidad, reentrenar. El git diff es el tratamiento, y el control pasa a VERDE. La brecha de datos es la excepción, y es la idea más difícil de aquí. Su tratamiento no es código en absoluto — es adquirir más datos representativos — así que su control es una barrera de suficiencia que ningún commit puede cerrar. Con n=215 ejemplos y un objetivo de n≥500, el ratio de suficiencia es 0,43 en cada commit, para siempre, hasta que los datos existan. Y como el riesgo está tratado (tienes un plan) y sujeto a una barrera (un control bloqueante) pero no tiene residual acotado (no puedes medir un residual que no tienes datos para estimar), el motor activa treated-without-residual — un bloqueo duro de integridad que oculta el botón Aprobar por completo. Esto es un escalón más abierto que la «barrera roja»: con un residual medido-pero-demasiado-alto puedes atravesarla con un motivo registrado; aquí el motor ni siquiera te ofrece la barrera, porque no puedes aceptar conscientemente un residual que todavía no puedes medir. La firma del paquete sigue verificándose — lo que está ROJO es el veredicto, no la integridad. La única salida honesta es conseguir los datos.

🎯 Al terminar sabrás…

• Situar la brecha de datos en la unión del Art. 10(3) (los datos deben ser pertinentes, suficientemente representativos y completos) y el Art. 10(5) (procesar atributos protegidos, excepcionalmente, para detectar y corregir sesgos).
• Explicar por qué un control de suficiencia no se puede cerrar con ningún cambio de código, mientras que un control de fuga o de equidad sí — y por qué eso hace que el tratamiento sea un data_gap, no un cambio de modelo.
• Enunciar con precisión qué significa treated-without-residual (tratado + sujeto a una barrera + sin residual acotado) y por qué el motor lo clasifica como un bloqueo duro que oculta «Aprobar».
• Contrastar la brecha de datos con la «barrera roja» (excepción manual con un motivo registrado obligatorio) y decir por qué la brecha de datos está un escalón más abierta.
• Reconocer el único remedio honesto — adquirir datos representativos, volver a medir y entonces avanzar — y por qué forzar la barrera sería fraude mientras la firma sigue siendo válida.

Artículo 10: la representatividad se encuentra con la detección de sesgos

El artículo 10 de la Ley de IA de la UE trata sobre datos y gobernanza de datos para sistemas de alto riesgo. Dos de sus apartados nos importan, y la lección vive donde se encuentran.

• El Art. 10(3) dice que los conjuntos de datos de entrenamiento, validación y prueba deben ser pertinentes, suficientemente representativos y — en la mayor medida posible — exentos de errores y completos, en vista de la finalidad prevista. Aquí es donde viven la suficiencia y representatividad de la muestra. «Suficientemente representativo» no es un eslogan: significa que realmente tienes suficientes datos, incluyendo suficientes de las poblaciones a las que pretendes servir, para sostener las afirmaciones que haces sobre el sistema.

• El Art. 10(5) dice que los proveedores pueden procesar excepcionalmente categorías especiales de datos personales — atributos protegidos como el origen étnico o el sexo — cuando sea estrictamente necesario para garantizar la detección y corrección de sesgos (leído junto con el 10(2)(f) y (g)), y solo bajo salvaguardas. En otras palabras, la ley anticipa que para comprobar si un modelo de contratación o cribado tiene impacto dispar puede que necesites conservar, cuidadosamente, el mismísimo atributo por el que no debes discriminar.

Ahora ponlos juntos, porque la brecha de datos vive en la unión de los dos. No puedes realizar la detección y corrección de sesgos que exigen el 10(5)/10(2) si no tienes una muestra adecuada según el 10(3) — es decir, suficientes datos, incluyendo suficientes ejemplos etiquetados del grupo protegido, para medir la disparidad con fiabilidad estadística. Una medición de equidad sobre 18 ejemplos de una clase minoritaria no es una medición; es ruido con una coma decimal.

Un matiz que conviene precisar

Una demo o una diapositiva pueden decir «la brecha de datos es un problema del Art. 10(5)» — porque el síntoma visible es no podemos ejecutar la comprobación de sesgos. Es una abreviatura razonable, pero sé preciso: la comprobación de sesgos necesita datos de atributos protegidos (10(5)), y el problema de fondo es que la muestra no es suficiente (10(3)). Enseña la unión: el 10(5) te dice qué debes medir; el 10(3) te dice que todavía no puedes, porque la muestra es demasiado pequeña para ser representativa.

Un control que el código no puede cerrar

La mayoría de los controles que encuentras se pueden cerrar con un cambio de código, y esa es la forma misma del Desarrollo Dirigido por el Riesgo: el tratamiento es un cambio versionado (ISO 23894 §6.5), y el git diff es el tratamiento.

• Un control de fuga: una característica está filtrando el objetivo, así que quitas la característica. Un commit. El control pasa a VERDE.
• Un control de equidad: un aprendiz produce impacto dispar, así que cambias a un aprendiz con restricción de equidad o reponderas. Un commit. El control pasa a VERDE.

Un control de suficiencia es diferente en su naturaleza. Considera un control cuyo criterio de aprobación es un ratio de adecuación de muestra:

sample_adequacy_ratio = n / 500 ≥ 1.0

Ninguna línea de código que puedas escribir cambia n. Puedes refactorizar el modelo, ajustar hiperparámetros, cambiar el aprendiz, reescribir el pipeline de datos — y el ratio no se mueve, porque la cantidad vinculante es cuántos datos representativos existen, no cómo está construido el modelo. El tratamiento para este riesgo no es, por tanto, un cambio de modelo en absoluto. Es una brecha de datos (data_gap): la afirmación honesta «el remedio es adquirir más datos representativos.»

Por qué ningún commit puede cerrar una barrera de suficiencia

Con n=215 ejemplos y un objetivo de n≥500, el ratio es 215 / 500 = 0,43. Ese número es el mismo en cada commit — en HEAD, en HEAD~1, en el commit que escribirás mañana — porque ninguno de esos commits añade datos. La barrera sigue en ROJO hasta que n supere realmente los 500. Lo único que mueve el ratio es la adquisición de datos. (Y los «arreglos» deshonestos — bajar el umbral por debajo de lo que la representatividad necesita, o falsear n — no son arreglos; son fraude. El motor deja la barrera honestamente en ROJO antes que blanquear un número.)

La apertura más profunda: tratado sin residual

Este es el mecanismo que hace de la brecha de datos el estado más difícil del curso. Está verificado en la capa de coherencia del motor (cloud/lib/approval/coherence.ts), no afirmado.

Un riesgo que está tratado (tiene un plan de tratamiento), y que depende de un control bloqueante (enforcement: gate), pero no tiene residual acotado (no se declara residual_likelihood), activa la infracción treated-without-residual. Y treated-without-residual se clasifica como un bloqueo duro (hardBlockingForApprove): el portal elimina la acción «Aprobar» por completo. Ni atenuada, ni tras una confirmación — desaparecida. Literalmente no puedes aprobar, con o sin motivo.

¿Por qué es ese el comportamiento correcto, y no una falta de cooperación del motor? Porque el razonamiento es profundo y merece decirse con claridad:

No puedes aceptar conscientemente un residual que ni siquiera puedes medir.

Un residual es el riesgo que queda tras el tratamiento. Para aceptarlo a sabiendas, primero debes poder enunciarlo: «tras el tratamiento, la probabilidad de daño es X, y eso es lo que estoy firmando». En una brecha de datos, los datos necesarios para estimar X no están ahí. No hay residual que certificar, así que no hay nada que aceptar todavía. El motor se niega a dejarte firmar por un número que no existe. En esa negativa, el motor es honesto sobre los límites de su propia evidencia.

Por qué el motor oculta aquí el botón Aprobar

Esto no es un accidente de la interfaz; es la capa de integridad funcionando. treated-without-residual es un bloqueo duro precisamente porque la aprobación es aceptación consciente de un residual enunciado, y en una brecha de datos no hay residual enunciado que aceptar. El sistema permanece en tested/treated/gap y el ciclo se pausa en request. El arreglo no está en el portal ni en el código — está aguas arriba, en los datos. Una vez que adquieres una muestra adecuada según el 10(3) y vuelves a medir, por fin existe un residual; solo entonces puede el ciclo de vida avanzar siquiera.

La barrera roja, y por qué esto está un escalón más allá

En otros puntos del curso encuentras la «barrera roja»: el caso en que el responsable puede aprobar un riesgo que está por encima del apetito, pero solo con un motivo registrado obligatorio. Ese mecanismo es real, y es diferente de la brecha de datos. Ambos están verificados en coherence.ts:

• residual-exceeds-appetite — el riesgo tiene un residual medido, y ese residual es superior al apetito. El responsable puede aprobar, pero el acto exige un motivo obligatorio que se registra en el servidor. (En la CLI, froga approve no tiene una opción --reason, así que este acto de aceptación consciente es solo del portal.)
• untreated-above-appetite — el riesgo está sin tratar y se sitúa por encima del apetito. La misma forma: la aprobación es posible con un motivo registrado.

Esa es la barrera roja: aceptación consciente del riesgo por encima del apetito, registrada — con los ojos abiertos, en acta. (Y fíjate: atravesarla es una decisión de gobernanza del responsable, no una base de conformidad. El veredicto sigue mostrando que el riesgo se aceptó por encima del apetito.)

La brecha de datos está un escalón MÁS abierta que la barrera roja

La barrera roja te deja atravesar un residual que está medido pero es demasiado alto — puedes ver exactamente qué estás aceptando, así que el motor ofrece la barrera previo registro de un motivo obligatorio. La brecha de datos no te da ninguna medición que atravesar. No hay residual sobre la mesa, así que el motor ni siquiera ofrece la barrera: treated-without-residual es un bloqueo duro y el botón «Aprobar» está oculto. La misma familia de apertura, pero la brecha de datos está más abierta — no puedes salir de ella con una excepción manual, porque todavía no hay nada que anular. La salida está aguas arriba, en los datos.

El único remedio honesto

Entonces, ¿qué haces con una brecha de datos? Adquieres más datos representativos — suficientes, incluyendo suficientes del grupo protegido, para que la comprobación de sesgos (10(5)) sea estadísticamente significativa y la muestra suficiente (10(3)). Luego vuelves a medir. Por fin existe un residual. Solo entonces puede el ciclo avanzar más allá de request.

Todo lo demás es una mentira disfrazada de arreglo:

• Bajar el umbral para que 0,43 «pase» no hace que la muestra sea representativa; solo oculta la inadecuación. Fraude.
• Falsear n para que el ratio marque ≥ 1.0 fabrica precisamente la evidencia que la barrera debe comprobar. Fraude.

El motor no hará ninguna de las dos cosas. Deja la barrera honestamente en ROJO y el ciclo de vida en pausa.

Qué está ROJO — y qué no

El paquete firmado sigue siendo criptográficamente válido: la firma se verifica, la evidencia es exactamente lo que el firmante registró. Lo que está ROJO es el veredicto de conformidad, no la integridad de la evidencia. Esa distinción es toda la filosofía del producto en una línea: el motor nunca afirma más de lo que la evidencia respalda, así que da un ROJO verdadero en lugar de un verde cómodo. El camino hacia delante es adquisición de datos → nueva medición → entonces (y solo entonces) el ciclo se mueve.

Autocomprobación

❓ ¿Por qué un control de suficiencia no puede cerrarse por un cambio de código, cuando un control de fuga o de equidad sí puede?

Un control de fuga o de equidad está ligado a cómo se construye el modelo, así que un cambio de código versionado lo cierra: quitas la característica con fuga, o cambias a un aprendiz con restricción de equidad, y el control pasa a VERDE — el git diff es el tratamiento (ISO 23894 §6.5). Un control de suficiencia está ligado a cuántos datos representativos existen — p. ej. sample_adequacy_ratio = n / 500 ≥ 1.0. Ningún commit cambia n: con n=215 el ratio es 0,43 en HEAD, en HEAD~1 y en cada commit futuro, porque ninguno añade datos. Lo único que lo mueve es adquirir más datos — un data_gap, no un cambio de modelo.

❓ ¿Qué significa `treated-without-residual`, y por qué es más difícil que la 'barrera roja'?

treated-without-residual se activa cuando un riesgo está tratado (tiene un plan) y depende de un control bloqueante (enforcement: gate) pero no tiene residual acotado (no hay residual_likelihood). El motor lo clasifica como un bloqueo duro (hardBlockingForApprove) y oculta el botón «Aprobar» por completo — no puedes aprobar con o sin motivo. Es más difícil que la barrera roja porque la barrera roja (residual-exceeds-appetite / untreated-above-appetite) te deja aprobar un residual medido-pero-demasiado-alto con un motivo registrado — con los ojos abiertos, en acta. La brecha de datos no te da ninguna medición que atravesar, así que el motor ni siquiera ofrece la barrera: no puedes aceptar conscientemente un residual que todavía no puedes medir. Está un escalón más abierta.

❓ Una demo dice que la brecha de datos es un problema del 'Art. 10(5)'. ¿Cuál es el encuadre más preciso?

El encuadre honesto es la unión del 10(3) y el 10(5). El Art. 10(5) te deja procesar excepcionalmente atributos protegidos cuando sea estrictamente necesario para la detección y corrección de sesgos — eso es qué debes medir. El Art. 10(3) exige que el conjunto de datos sea pertinente, suficientemente representativo y completo — y eso es por qué todavía no puedes, porque la muestra es demasiado pequeña para medir la disparidad de forma fiable (incluidos demasiado pocos ejemplos del grupo protegido). El «10(5)» de la demo es una abreviatura razonable del síntoma visible (la comprobación de sesgos no puede ejecutarse), pero el requisito vinculante bajo él es la suficiencia/representatividad del 10(3). Enseña la unión.

A dónde ir ahora

Nivel 5 · Cribado de candidaturasLa brecha de datos hecha concreta: un modelo de cribado de candidaturas cuyo único tratamiento honesto es adquirir más datos representativos, cuya barrera de suficiencia sigue en ROJO en cada commit, y cuyo ciclo de vida el motor se niega a dejarte aprobar — el bloqueo duro en acción.

¿Qué es un riesgo?El fundamento bajo todo lo de aquí: probabilidad, impacto, apetito y residual — y por qué un residual que no puedes medir es un residual que no puedes aceptar.

No solo la Ley de IACómo un régimen sectorial se apila sobre la columna vertebral de la Ley de IA, y dónde se sitúan las obligaciones de gobernanza de datos como el artículo 10 respecto a la porción por sistema que el motor proyecta sobre el paquete firmado.

Ley de IA de la UE — la columna vertebralLa página de referencia sobre cómo el motor proyecta la Ley de IA sobre el paquete, incluido el artículo 10 sobre datos y gobernanza de datos, y la diferencia entre un veredicto ROJO y una firma todavía válida.

ISO 23894 — gestión del riesgoLa disciplina de gestión del riesgo detrás del tratamiento como cambio versionado (§6.5), el riesgo residual y la aceptación consciente frente al apetito — el vocabulario que hace legible el bloqueo duro de la brecha de datos.