Qué regula el artículo 10
El artículo 10 del AI Act, bajo el título "Datos y gobernanza de datos", obliga a los proveedores de sistemas de IA de alto riesgo a aplicar prácticas de gobernanza y gestión de calidad sobre los conjuntos de datos de entrenamiento, validación y test. No es una recomendación de buenas prácticas: es una obligación legal con evidencia documental exigible en la evaluación de conformidad.
Los cuatro criterios de calidad que exige
El artículo 10 exige que los conjuntos de datos sean, en la medida en que el propósito del sistema lo permita, relevantes, suficientemente representativos, libres de errores en la mayor medida posible y completos. Estos cuatro criterios están directamente conectados con las dimensiones de calidad del dato que ya deberías estar midiendo en cualquier programa de data quality management, pero aquí dejan de ser una buena práctica interna para convertirse en un requisito auditable.
| Criterio del AI Act | Qué exige en la práctica |
|---|---|
| Relevancia | Los datos usados deben corresponder al propósito real del sistema, no a lo que resultaba más fácil de conseguir |
| Representatividad | El dataset debe reflejar el contexto geográfico, conductual y funcional real de despliegue, no una muestra sesgada hacia un segmento |
| Libre de errores | Umbrales medibles de exactitud, no una afirmación genérica de "los datos están limpios" |
| Completitud | Cobertura suficiente de los casos y variables necesarias para que el sistema funcione según su propósito declarado |
Un matiz importante que introduce el propio artículo 10: estos criterios se definen en relación con el propósito previsto del sistema y el estado del arte generalmente reconocido. No existe un estándar único de "representatividad"; lo que es suficiente para un sistema cambia según su contexto de uso. Un modelo de scoring crediticio entrenado mayoritariamente con datos de fuera de la UE, por ejemplo, puede fallar precisamente en representar patrones socioeconómicos específicos del mercado europeo donde se despliega.
Gobernanza del proceso de preparación de datos
Más allá de las características del dataset final, el artículo 10 obliga a documentar el proceso de preparación: decisiones de diseño relevantes, procesos de recolección y origen de los datos, operaciones de procesamiento como anotación, etiquetado, limpieza, actualización, enriquecimiento y agregación, y las hipótesis asumidas durante ese proceso. En otras palabras, no basta con entregar un dataset que cumpla los cuatro criterios; hay que poder reconstruir el camino que llevó hasta él.
Detección y mitigación de sesgos
El artículo 10 exige examinar los datos en busca de posibles sesgos que puedan afectar a la salud, seguridad de las personas, tener un impacto negativo en los derechos fundamentales o dar lugar a discriminación, especialmente cuando los datos de salida influyen en datos de entrada de operaciones futuras. Cuando resulta estrictamente necesario, y con las salvaguardas adecuadas, la norma permite el tratamiento de categorías especiales de datos personales con el único fin de detectar y corregir esos sesgos.
Aquí es donde el Digital Omnibus sí introduce un cambio sustantivo: la propuesta amplía esta base legal, sustituyendo el actual apartado 5 del artículo 10, para permitir también a proveedores y responsables de sistemas que no son de alto riesgo usar categorías especiales de datos para detectar y corregir sesgos, y suaviza el umbral de "estrictamente necesario" a simplemente "necesario". Si tu organización ha estado bloqueada para hacer testing de equidad por restricciones sobre datos sensibles, esta es la vía legal que se está abriendo; conviene construir ya el pipeline de testing gobernado y minimizado en lugar de esperar a la adopción formal.
Qué deben documentar las empresas
- Inventario y procedencia del dataset: fuente de cada conjunto de datos, fecha de captura, propietario y base legal cuando incluya datos personales.
- Registro de preparación: qué transformaciones, limpiezas y enriquecimientos se aplicaron, y quién los aprobó.
- Evidencia de representatividad: métricas concretas, no afirmaciones, sobre cobertura de segmentos relevantes al propósito del sistema.
- Análisis de sesgo: metodología usada para detectar sesgo, resultados y medidas de mitigación aplicadas.
- Umbrales de calidad y su justificación: por qué esos umbrales son adecuados para el propósito y contexto del sistema, no solo que existen.
Cómo conecta con tu programa de data quality management
Si ya tienes un framework de data quality management funcionando, con profiling, reglas definidas y KPIs monitorizados, gran parte del trabajo de cumplimiento del artículo 10 ya está hecho. Lo que falta habitualmente es la capa de trazabilidad específica para sistemas de alto riesgo: vincular cada dataset de entrenamiento con su análisis de sesgo, su justificación de representatividad y su documentación de linaje, de forma que un auditor pueda seguir el hilo completo sin depender de que alguien lo recuerde de memoria.
Errores comunes al justificarlo
- Afirmar representatividad sin métricas que la sustenten: una declaración de intenciones no sobrevive a una auditoría en 2026.
- Tratar el análisis de sesgo como un ejercicio puntual en lugar de un proceso repetible cada vez que cambia el dataset.
- Asumir que el retraso del calendario a diciembre de 2027 significa que no hay prisa: la clasificación de sistemas, el inventario y la documentación de procedencia no dependen de que los estándares técnicos estén cerrados, y montarlo con tiempo evita trabajo apresurado en el último trimestre.
El calendario se ha movido, pero el fondo del artículo 10 no: la calidad de los datos de entrenamiento dejó de ser una cuestión puramente técnica para convertirse en un requisito legal con evidencia exigible. Cuanto antes conectes tu trabajo de calidad de datos con esa capa de documentación, menos trabajo de última hora tendrás cuando se acerque la fecha definitiva.