Playbook de Implementacion del Articulo 10 del EU AI Act: De Datos Crudos a Pipeline Conforme

El Articulo 10 del EU AI Act es el articulo que afecta directamente a los equipos de datos. Mientras otros articulos abordan requisitos a nivel de sistema, gestion de riesgos y obligaciones de transparencia, el Articulo 10 se centra especificamente en los datos de entrenamiento, validacion y prueba. Establece como los sistemas de IA de alto riesgo deben manejar los datos que dan forma a su comportamiento.

El problema es que el Articulo 10 esta escrito en lenguaje legal. Dice cosas como "los datasets de entrenamiento, validacion y prueba estaran sujetos a practicas de gobernanza y gestion de datos apropiadas para el proposito previsto del sistema de IA." Correcto, pero no accionable. Un ingeniero de datos que lee esa frase no puede empezar a escribir codigo.

Este playbook traduce cada requisito del Articulo 10 en tareas concretas de ingenieria. Para cada sub-articulo, obtienes: el requisito legal, lo que significa en la practica, el trabajo de ingenieria especifico necesario y una plantilla para la documentacion que demuestra cumplimiento.

Articulo 10(2)(a): Practicas de Gobernanza y Gestion de Datos

Requisito legal: "Los datasets de entrenamiento, validacion y prueba estaran sujetos a practicas de gobernanza y gestion de datos apropiadas para el proposito previsto del sistema de IA."

Lo que significa en la practica: Necesitas un sistema documentado para gestionar los datos de entrenamiento a lo largo de su ciclo de vida, desde la recopilacion hasta el retiro. "Apropiado para el proposito previsto" significa que la gobernanza debe ser proporcional al riesgo. Un sistema de scoring crediticio de alto riesgo necesita una gobernanza mas rigurosa que una herramienta interna de busqueda de documentos.

Tareas de ingenieria:

1. Establecer un documento de politica de gobernanza de datos que cubra:

   • Quien es responsable de la calidad de los datos de entrenamiento (un rol nombrado, no un equipo)
   • Que proceso de aprobacion se requiere antes de que los datos entren al pipeline
   • Como se reportan y resuelven los problemas de calidad de datos
   • Con que frecuencia se revisa la calidad de los datos
   • Que sucede cuando la calidad de los datos cae por debajo de los umbrales

2. Implementar control de acceso basado en roles sobre los datos de entrenamiento:

   • Data steward: puede aprobar fuentes de datos y umbrales de calidad
   • Ingeniero de datos: puede procesar y transformar datos dentro de parametros aprobados
   • Anotador: puede etiquetar datos segun las guias aprobadas
   • Auditor: acceso de solo lectura a datos, registros y documentacion
   • Define estos roles en las herramientas de tu pipeline, no solo en un documento de politica

3. Crear un registro de datos que rastree:

   • Todos los datasets utilizados para entrenamiento, validacion y prueba
   • La version actual y el estado de cada dataset (borrador, aprobado, en uso, retirado)
   • El data steward asignado para cada dataset
   • Enlaces a informes de calidad, evaluaciones de sesgo y analisis de brechas

Plantilla de documentacion:

Data Governance Policy — [System Name]
1. Scope: This policy applies to all training, validation, and testing data for [system name].
2. Roles: Data Steward: [name]. Data Engineers: [names]. Annotators: [names].
3. Approval Process: New data sources require Data Steward approval before ingestion.
4. Quality Thresholds: [defined metrics and minimum values]
5. Review Cadence: Quality review conducted [monthly/quarterly].
6. Issue Resolution: Quality issues reported via [system] and resolved within [timeframe].

Articulo 10(2)(b): Decisiones de Diseno para Datasets

Requisito legal: Los datos de entrenamiento estaran sujetos a "decisiones de diseno relevantes."

Lo que significa en la practica: Documenta por que elegiste este dataset especifico. Que alternativas consideraste? Por que estos datos fueron apropiados para el proposito previsto? Esto previene el patron comun de usar cualquier dato disponible sin evaluar si era adecuado.

Tareas de ingenieria:

1. Crear un documento de diseno de dataset para cada dataset de entrenamiento que registre:

   • El proposito previsto del sistema de IA (caso de uso especifico, no una descripcion general)
   • Que datos serian ideales para este proposito
   • Que datos estan realmente disponibles
   • La brecha entre lo ideal y lo disponible, y como se abordo esta brecha
   • Datasets alternativos que se consideraron y por que no fueron seleccionados

2. Documentar la estrategia de division train/validacion/test:

   • Como se dividieron los datos (aleatorio, estratificado, temporal, basado en dominio)
   • La justificacion de los ratios de division
   • Como la division asegura que el conjunto de validacion sea representativo de las condiciones de produccion

3. Registrar cualquier supuesto hecho durante el diseno del dataset:

   • "Asumimos que las interacciones historicas de clientes de 2023-2025 son representativas de las interacciones futuras"
   • "Asumimos que la distribucion de tipos de quejas en los datos de entrenamiento coincide con la distribucion en produccion"
   • Estos supuestos son verificables, y los auditores pueden pedir evidencia

Plantilla de documentacion:

Dataset Design Document — [Dataset Name]
1. Intended Purpose: [specific use case description]
2. Ideal Data: [description of what perfect training data would look like]
3. Available Data: [description of what was actually available]
4. Gap Analysis: [how ideal and available differ, and how gaps were addressed]
5. Alternatives Considered: [other datasets evaluated and reasons for rejection]
6. Split Strategy: [train/val/test split method and rationale]
7. Assumptions: [listed with testability assessment]

Articulo 10(2)(c): Procesos de Recopilacion de Datos

Requisito legal: Los datos de entrenamiento estaran sujetos a "procesos relevantes de recopilacion de datos."

Lo que significa en la practica: Documenta como se obtuvieron los datos. Esto incluye las fuentes, los metodos de recopilacion, cualquier requisito de consentimiento o licencia, y las fechas de recopilacion.

Tareas de ingenieria:

1. Implementar seguimiento automatizado de fuentes en tu pipeline de ingestion:

   • Registra la URI de la fuente o la ruta del archivo para cada documento ingerido
   • Registra la fecha de recopilacion (cuando se obtuvieron los datos, no cuando se creo la fuente)
   • Registra el metodo de recopilacion (pull de API, carga de archivo, web scraping, entrada manual)

2. Mantener un registro de fuentes que rastree:

   • Todas las fuentes de datos actualmente en uso
   • La base legal para usar cada fuente (consentimiento, interes legitimo, licencia, dominio publico)
   • Restricciones de licencia (si aplica): pueden usarse los datos para entrenamiento de modelos? Hay restricciones geograficas?
   • Fechas de expiracion para licencias o consentimientos con tiempo limitado

3. Implementar seguimiento de consentimiento para datos obtenidos de individuos:

   • Que consentimiento se dio?
   • Cuando se dio?
   • Puede retirarse? Si es asi, cual es el proceso para eliminar los datos de esa persona del conjunto de entrenamiento?

Plantilla de documentacion:

Data Collection Record — [Source Name]
1. Source: [URI, database, file location]
2. Collection Method: [API, upload, scrape, manual]
3. Collection Date: [date range]
4. Legal Basis: [consent, license, legitimate interest, public domain]
5. License Details: [license name, restrictions, expiration]
6. Consent Status: [applicable/not applicable, withdrawal process]
7. Update Frequency: [how often this source is re-collected]

Articulo 10(2)(d): Operaciones de Preparacion de Datos

Requisito legal: Los datos de entrenamiento estaran sujetos a "operaciones relevantes de preparacion de datos, como anotacion, etiquetado, limpieza, actualizacion, enriquecimiento y agregacion."

Lo que significa en la practica: Cada transformacion aplicada a los datos debe documentarse y registrarse. Este es el requisito mas intensivo operativamente porque cubre todo el pipeline de datos.

Tareas de ingenieria:

1. Implementar registro automatizado para cada transformacion (consulta nuestro articulo sobre rastros de auditoria inmutables para la especificacion tecnica):

   • Limpieza: que se elimino, por que, cuantos registros afectados
   • Etiquetado: quien etiqueto, que taxonomia se uso, que verificaciones de calidad se aplicaron
   • Aumento: que metodo se uso, cuantos registros sinteticos se crearon
   • Agregacion: que registros se combinaron, que logica de agregacion se aplico

2. Versionar cada dataset intermedio:

   • Despues de cada etapa de transformacion, crear una instantanea versionada
   • Vincular cada instantanea a las entradas del registro de transformacion que la produjeron
   • Habilitar el rollback a cualquier version anterior

3. Validar en cada etapa:

   • Ejecutar verificaciones automatizadas de calidad despues de cada transformacion
   • Registrar los resultados de validacion junto con los registros de transformacion
   • Definir umbrales minimos de calidad: si una transformacion degrada la calidad por debajo del umbral, detener el pipeline y alertar al data steward

Plantilla de documentacion:

Data Preparation Log — [Dataset Version]
Generated automatically by pipeline logging system.
See audit trail entries [ID range] for detailed transformation records.
Summary:
- Cleaning: [X] operations, [Y] records modified, [Z] records removed
- Labeling: [X] records labeled by [Y] annotators, agreement rate [Z]%
- Augmentation: [X] synthetic records generated, [Y] passed quality filter
- Total input records: [N], Total output records: [M]

Articulo 10(2)(e): Evaluacion de Disponibilidad, Cantidad e Idoneidad

Requisito legal: Los datos de entrenamiento estaran sujetos a "una evaluacion de la disponibilidad, cantidad e idoneidad de los datasets necesarios."

Lo que significa en la practica: Antes del entrenamiento, evalua formalmente si tienes suficientes datos, si los datos que tienes son adecuados para el proposito previsto, y si hay brechas.

Tareas de ingenieria:

1. Evaluacion cuantitativa:

   • Total de registros en los conjuntos de entrenamiento, validacion y prueba
   • Registros por clase/categoria (para tareas de clasificacion)
   • Umbral minimo de representacion de clase (por ejemplo, al menos 50 ejemplos por categoria)
   • Analisis de potencia estadistica: es el dataset lo suficientemente grande para detectar los efectos que necesitas?

2. Evaluacion de idoneidad:

   • Cobertura de dominio: cubren los datos de entrenamiento todos los escenarios que el modelo encontrara en produccion?
   • Cobertura temporal: son los datos lo suficientemente actuales? Si se entreno con datos de 2024, funcionara bien el modelo con consultas de 2026?
   • Cobertura linguistica: cubren los datos todos los idiomas y dialectos que servira el sistema?
   • Cobertura de casos extremos: estan representados los escenarios raros pero importantes?

3. Evaluacion de disponibilidad:

   • Que datos mejorarian el modelo pero no estan disponibles?
   • Cual es el plan para adquirir datos adicionales?
   • Hay barreras legales o tecnicas para obtener los datos necesarios?

Plantilla de documentacion:

Data Assessment Report — [Dataset Version]
1. Quantity: [total records] training, [total] validation, [total] test
2. Class Distribution: [table of classes and record counts]
3. Minimum Representation: [threshold] — all classes meet/do not meet threshold
4. Domain Coverage: [assessment with specific gaps identified]
5. Temporal Coverage: Data from [date range]. Currency assessment: [current/stale/mixed]
6. Availability Gaps: [data that would improve the model but is unavailable]
7. Remediation Plan: [how gaps will be addressed]

Articulo 10(2)(f): Examen de Sesgos

Requisito legal: Los datos de entrenamiento estaran sujetos a "un examen en vista de posibles sesgos que probablemente afecten la salud y seguridad de las personas, tengan un impacto negativo en los derechos fundamentales o conduzcan a discriminacion."

Lo que significa en la practica: Analiza los datos de entrenamiento en busca de sesgos, no como un ejercicio unico de marcar casillas, sino como un proceso continuo. El enfoque esta en sesgos que podrian causar dano real: discriminacion en contratacion, decisiones crediticias sesgadas, trato injusto en educacion o aplicacion de la ley.

Tareas de ingenieria:

1. Analisis demografico (cuando aplique):

   • Medir la representacion de caracteristicas protegidas en los datos de entrenamiento
   • Comparar la demografia de los datos de entrenamiento con la poblacion que servira el modelo
   • Identificar grupos subrepresentados o sobrerrepresentados

2. Deteccion de sesgo en etiquetas:

   • Medir el acuerdo inter-anotador entre grupos demograficos
   • Verificar si las distribuciones de etiquetas difieren segun el contexto del anotador
   • Identificar patrones sistematicos de etiquetado que podrian codificar sesgo

3. Deteccion de variables proxy:

   • Identificar caracteristicas que correlacionen con caracteristicas protegidas (por ejemplo, codigo postal como proxy de raza)
   • Documentar la decision de incluir, excluir o mitigar cada variable proxy

4. Metricas de equidad:

   • Calcular metricas de equidad en el conjunto de validacion: paridad demografica, probabilidades igualadas, paridad predictiva
   • Definir umbrales aceptables para cada metrica
   • Documentar cualquier metrica que caiga fuera de los limites aceptables y la remediacion tomada

Plantilla de documentacion:

Bias Examination Report — [Dataset Version]
1. Demographic Representation: [table comparing training data demographics to target population]
2. Underrepresented Groups: [identified groups and degree of underrepresentation]
3. Label Bias Analysis: [inter-annotator agreement by group, findings]
4. Proxy Variables: [identified proxies, decision for each (include/exclude/mitigate)]
5. Fairness Metrics: [metric values vs thresholds, pass/fail for each]
6. Remediation Actions: [what was done to address identified biases]
7. Residual Risk: [biases that could not be fully mitigated, with justification]

Articulo 10(2)(g): Identificacion de Brechas en los Datos

Requisito legal: Los datos de entrenamiento estaran sujetos a "la identificacion de brechas o deficiencias relevantes en los datos, y como esas brechas y deficiencias pueden abordarse."

Lo que significa en la practica: Esto no es lo mismo que la evaluacion de idoneidad en (e). La identificacion de brechas se refiere especificamente a deficiencias que podrian afectar el rendimiento del sistema en su proposito previsto: escenarios faltantes, casos de uso subrepresentados, puntos ciegos.

Tareas de ingenieria:

1. Analisis de brechas de cobertura:

   • Mapear todos los casos de uso previstos a la cobertura de datos de entrenamiento
   • Para cada caso de uso, verificar que los datos de entrenamiento contengan ejemplos representativos
   • Identificar casos de uso con cero o insuficientes datos de entrenamiento

2. Analisis de errores en el conjunto de validacion:

   • Ejecutar el modelo en el conjunto de validacion y analizar errores
   • Categorizar errores por tipo (falsos positivos, falsos negativos, clase incorrecta)
   • Identificar patrones sistematicos de error que sugieran brechas en los datos

3. Planificacion de remediacion:

   • Para cada brecha identificada, definir un plan de remediacion: recopilar mas datos, sintetizar ejemplos, ajustar el alcance del modelo o agregar un humano en el bucle para los escenarios con brecha
   • Establecer plazos para la remediacion
   • Rastrear el progreso de la remediacion

Plantilla de documentacion:

Data Gap Analysis — [Dataset Version]
1. Use Case Coverage Matrix: [table mapping use cases to training data availability]
2. Identified Gaps: [list of gaps with severity assessment]
3. Error Pattern Analysis: [systematic errors linked to data gaps]
4. Remediation Plan:
   - Gap 1: [description] → [remediation action] → [timeline] → [status]
   - Gap 2: [description] → [remediation action] → [timeline] → [status]
5. Accepted Risks: [gaps that cannot be remediated, with impact assessment and mitigations]

Integrando Todo

El cumplimiento del Articulo 10 no es un proyecto unico. Es un requisito operativo continuo. La documentacion descrita anteriormente debe:

• Crearse antes de que el sistema se despliegue (o antes de la fecha limite del 2 de agosto de 2026 para sistemas existentes)
• Actualizarse cada vez que cambien los datos de entrenamiento, se reentrene el modelo o cambie el alcance del sistema
• Revisarse periodicamente (trimestralmente como minimo) para asegurar su precision
• Estar disponible para revision del auditor en un plazo razonable (mismo dia habil para sistemas de alto riesgo)

Las tareas de ingenieria son sustanciales pero bien definidas. Para un equipo que comienza desde cero, espera 8-12 semanas de trabajo de implementacion en los sistemas de registro del pipeline, evaluacion de calidad, analisis de sesgo y documentacion. Para equipos que usan Ertas Data Suite, gran parte de esta infraestructura esta integrada: la plataforma genera documentacion conforme al Articulo 10 a partir de los datos que su rastro de auditoria ya captura.

El principio clave: si no esta registrado, no sucedio. Cada evaluacion, cada decision, cada transformacion debe producir un registro verificable. Ese registro es la evidencia de que el cumplimiento del Articulo 10 es operativo, no aspiracional.

Lectura Adicional

• EU AI Act Article 10 Data Prep Documentation — Una mirada mas profunda a los requisitos de documentacion especificos para operaciones de preparacion de datos.
• EU AI Act Article 10 vs Article 30: Training Data Requirements — Como interactuan el Articulo 10 y el Articulo 30 y que requiere cada uno de tu pipeline de datos.
• EU AI Act Data Governance Checklist for High-Risk Systems — Lista de verificacion completa para requisitos de gobernanza de datos en todos los articulos relevantes del EU AI Act.