Articulo 10 del EU AI Act: Que Significa para tus Datos de Entrenamiento de IA
El Articulo 10 del EU AI Act establece requisitos estrictos de gobernanza de datos para sistemas de IA de alto riesgo. Esto es lo que significa para los equipos empresariales que preparan datos de entrenamiento de IA, y la fecha limite de cumplimiento de agosto 2026.
Cuando el EU AI Act entro en vigor en agosto de 2024, la mayoria de los comentarios se centraron en las practicas de IA prohibidas (Articulo 5) y los requisitos para sistemas de alto riesgo (Anexo III). Se ha prestado menos atencion al Articulo 10, la disposicion que gobierna los datos utilizados para construir sistemas de IA de alto riesgo. Esto es un problema, porque el Articulo 10 impone requisitos especificos y exigibles sobre tus datos de entrenamiento, datos de validacion y datos de prueba, requisitos que la mayoria de los equipos empresariales de IA no estan cumpliendo actualmente.
La fecha limite de aplicabilidad completa para sistemas de IA de alto riesgo es el 2 de agosto de 2026. Si estas construyendo IA en cualquiera de los dominios cubiertos, tienes una ventana estrecha para poner tus practicas de gobernanza de datos en cumplimiento.
Que Sistemas Estan Sujetos al Articulo 10?
El Articulo 10 aplica a proveedores de "sistemas de IA de alto riesgo" segun se definen en el Anexo III. La lista incluye IA utilizada en:
- Infraestructura critica (servicios publicos, transporte, suministro de agua)
- Educacion y formacion profesional (acceso a educacion, evaluacion de rendimiento)
- Empleo y RRHH (reclutamiento, promocion, gestion laboral, terminacion)
- Servicios esenciales (scoring crediticio, riesgo de seguros, despacho de servicios de emergencia)
- Aplicacion de la ley (evaluacion de riesgos, deteccion de mentiras, fiabilidad de evidencia)
- Migracion y control fronterizo (evaluacion de riesgos, verificacion de documentos)
- Administracion de justicia (IA asistiendo a tribunales)
- Dispositivos medicos (IA clasificada como dispositivos medicos bajo EU MDR)
Si tu organizacion esta desarrollando o desplegando IA en cualquiera de estas areas y colocandola en el mercado de la UE, el Articulo 10 aplica. Ten en cuenta que "proveedor" incluye equipos de desarrollo internos: no necesitas estar vendiendo IA comercialmente para ser un proveedor bajo la Ley.
Para organizaciones que no estan seguras de si su sistema califica, la Comision de la UE ha emitido orientacion, pero el enfoque mas seguro es asumir que la clasificacion de alto riesgo aplica si tu IA toma o asiste en decisiones consecuentes sobre personas.
Que Requiere Realmente el Articulo 10
El Articulo 10 se titula "Datos y Gobernanza de Datos." Sus requisitos cubren todo el pipeline de datos, no solo el conjunto de entrenamiento final.
Parrafo 1: Practicas para la Gestion de Datos
Los proveedores deben implementar practicas de gobernanza y gestion de datos que cubran:
- Las decisiones de diseno respecto a los datos (que incluir y por que)
- Los procesos de recopilacion de datos
- Las operaciones relevantes de procesamiento de preparacion de datos (limpieza, etiquetado, enriquecimiento, agregacion, anotacion)
- Como los datos se alinean con el proposito previsto del sistema de IA
Este no es un requisito de documentacion posterior. Las practicas deben estar implementadas durante el desarrollo, lo que significa que tu flujo de trabajo actual de preparacion de datos ya esta dentro del alcance.
Parrafo 2: Criterios de Calidad de Datos
Los datasets de entrenamiento, validacion y prueba deben cumplir cuatro criterios:
- Relevantes — los datos deben ser relevantes para el proposito previsto del sistema de IA
- Representativos — los datos deben ser suficientemente representativos de las condiciones bajo las cuales operara el sistema
- Libres de errores — en la medida de lo posible; esto requiere una evaluacion activa de calidad, no solo una suposicion
- Completos — respecto a las caracteristicas o propiedades necesarias para el proposito
La frase "en la medida de lo posible" para errores es significativa: reconoce que los datos perfectos no existen. Pero tambien significa que necesitas demostrar que has examinado y abordado activamente los problemas de calidad de datos, no simplemente los has ignorado.
Parrafo 3: Examen de Sesgos
Los datasets deben examinarse en busca de posibles sesgos que podrian afectar la salida del sistema de IA y generar riesgos para la salud, la seguridad o los derechos fundamentales. Si se encuentran sesgos, deben abordarse, o si no pueden abordarse completamente, el sesgo residual debe documentarse y mitigarse por otros medios.
Esto requiere un proceso de examen deliberado, no solo una suposicion general de que tus datos no tienen sesgo. La metodologia de examen y los resultados deben documentarse.
Parrafo 4: Datos Sensibles
Cuando sea necesario para detectar y corregir sesgos, el Articulo 10(4) permite la recopilacion y procesamiento de categorias sensibles de datos personales (datos del Articulo 9 del GDPR: raza, salud, opinion politica, etc.) — sujeto a condiciones estrictas incluyendo salvaguardas apropiadas y limitacion de proposito.
Esta disposicion a menudo se malinterpreta como una autorizacion amplia para el uso de datos sensibles. No lo es. Proporciona una excepcion estrecha, especificamente para la deteccion de sesgo, con obligaciones correspondientes.
Parrafo 5: Relevancia para el Contexto Operativo
El requisito de representatividad se extiende al entorno geografico, conductual y funcional especifico donde la IA realmente operara. Los datos de entrenamiento deben reflejar las condiciones del mundo real del despliegue, no solo condiciones de laboratorio o ideales.
Articulo 11: Documentacion Tecnica
Los requisitos de datos del Articulo 10 no funcionan de forma aislada. El Articulo 11 requiere que los proveedores preparen documentacion tecnica demostrando que su sistema de IA de alto riesgo cumple con la Ley. El Anexo IV especifica que debe incluir esta documentacion.
Para la gobernanza de datos, la documentacion tecnica debe contener:
- Una descripcion de la metodologia de entrenamiento y los datos utilizados
- Informacion sobre las caracteristicas, limitaciones y supuestos de los datos de entrenamiento
- Una descripcion de las practicas de gobernanza y gestion de datos aplicadas
- Documentacion de cualquier tecnica de aumento de datos utilizada
- Una descripcion de los procedimientos de examen de datos y evaluacion de calidad
Esta documentacion debe mantenerse actualizada durante todo el ciclo de vida del sistema. Si actualizas tus datos de entrenamiento o reentrenas tu modelo, la documentacion debe actualizarse para reflejar los cambios.
La fecha limite del 2 de agosto de 2026 significa que los proveedores de sistemas de IA de alto riesgo deben tener esta documentacion completa y actualizada para esa fecha para seguir en cumplimiento.
Que Requiere "Libre de Errores" en la Practica
El requisito de que los datos de entrenamiento sean "libres de errores en la medida de lo posible" es mas exigente operativamente de lo que parece. Implica:
Scoring activo de calidad: Necesitas una metodologia para evaluar la calidad de los datos, no solo detectar errores obvios, sino un scoring sistematico de completitud, consistencia, precision y relevancia.
Deduplicacion: Los registros duplicados sesgan el entrenamiento del modelo y pueden indicar un problema de calidad de datos. Tu pipeline debe incluir un paso de deduplicacion con metodologia documentada.
Examen de valores atipicos: Los valores atipicos estadisticos en los datos de entrenamiento pueden representar casos extremos genuinos (que quieres incluir) o errores de datos (que quieres eliminar). El Articulo 10 requiere que hagas esa distincion deliberadamente.
Calidad de etiquetas: Para el aprendizaje supervisado, los errores de anotacion son una forma de error de datos. La calidad de tu proceso de etiquetado (acuerdo inter-anotador, guias de anotacion, procedimientos de revision) es parte del cumplimiento del Articulo 10.
El Requisito del Rastro de Auditoria
Leyendo los Articulos 10 y 11 juntos, un proveedor de sistema de IA de alto riesgo debe poder reconstruir el historial de sus datos de entrenamiento: que se incluyo, que se excluyo, que transformaciones se aplicaron y por que.
Esto requiere un rastro de auditoria que documente:
- Documentos fuente y su procedencia
- Pasos de analisis y extraccion
- Operaciones de limpieza y deduplicacion
- Pasos de redaccion y desidentificacion
- Eventos de anotacion (quien etiqueto que, cuando, usando que guias)
- Operaciones de aumento (que datos sinteticos se generaron, con que parametros)
- Operaciones de exportacion (que version del dataset se exporto para entrenamiento)
La mayoria de los pipelines actuales de preparacion de datos, ensamblados con Docling, Label Studio, Cleanlab y scripts ad hoc, no producen un linaje compartido. Docling analiza archivos y escribe en una carpeta. Label Studio anota sin un vinculo estructural a esos archivos fuente. Los scripts de limpieza se ejecutan y sobrescriben. El resultado es un dataset de entrenamiento sin historial rastreable.
Reconstruir el linaje despues del hecho es mas dificil que incorporarlo desde el principio. Para agosto de 2026, la reconstruccion ya no es una opcion: necesitas cumplimiento actual.
Pasos Practicos para Lograr el Cumplimiento del Articulo 10
Paso 1: Clasifica tus Sistemas de IA
Determina si tus proyectos de IA caen bajo la clasificacion de alto riesgo. Si hay ambiguedad, tratalos como alto riesgo hasta que tengas una evaluacion de riesgos documentada que diga lo contrario.
Paso 2: Audita tu Pipeline de Datos Actual
Mapea cada paso desde los datos crudos hasta el dataset de entrenamiento. Identifica donde existen brechas de documentacion: etapas sin registro, herramientas sin salida de auditoria, transformaciones que ocurren en scripts no documentados.
Paso 3: Implementa Evaluacion de Calidad
Define tus criterios de calidad de datos para cada dataset. Ejecuta scoring sistematico de calidad. Documenta lo que encontraste y lo que hiciste al respecto.
Paso 4: Realiza un Examen de Sesgo
Esto no requiere un investigador de machine learning. Requiere una revision estructurada de la composicion de tu dataset contra la poblacion que servira la IA. Documenta la metodologia, los hallazgos y las mitigaciones.
Paso 5: Establece Registro de Auditoria
Cada paso de transformacion debe producir una entrada de registro: marca de tiempo, operador, accion, registros afectados. El registro debe preservarse y ser exportable.
Paso 6: Escribe la Documentacion Tecnica
Integra las piezas en documentacion conforme al Anexo IV. Este no es un ejercicio unico: debe mantenerse durante el ciclo de vida del sistema.
Como Ertas Data Suite Apoya el Cumplimiento del Articulo 10
Ertas Data Suite fue disenado con el cumplimiento del Articulo 10 como un requisito de primera clase, no una idea posterior. Cada transformacion a traves de las cinco etapas del pipeline (Ingest, Clean, Label, Augment, Export) se registra con marca de tiempo e ID del operador. El rastro de auditoria es una exportacion estructurada, no un registro de texto, lo que lo hace utilizable para documentacion tecnica sin reformateo manual.
El modulo Clean realiza scoring automatizado de calidad y deduplicacion, con resultados documentados en el registro del proyecto. El modulo Label rastrea eventos de anotacion a nivel de registro individual. El modulo Export produce un manifiesto del dataset junto con los datos de entrenamiento, registrando el historial de versiones y los parametros del pipeline.
El pipeline se ejecuta completamente on-premise sin egreso de datos, satisfaciendo los requisitos de soberania de datos que a menudo acompanan el cumplimiento del EU AI Act en sectores regulados.
Para los equipos que enfrentan la fecha limite de agosto de 2026, la pregunta no es si construir practicas de gobernanza de datos conformes, sino si construirlas en el pipeline desde el inicio o intentar adaptarlas retroactivamente a una cadena de herramientas fragmentada existente.
Your data is the bottleneck — not your models.
Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.
Lectura Relacionada
- On-Premise AI Data Preparation: The Compliance Guide for Regulated Industries — Cobertura completa de GDPR, HIPAA, EU AI Act y requisitos de soberania de datos en una sola guia.
- The Audit Trail Gap: How Most Enterprise AI Pipelines Fail EU AI Act Compliance Without Knowing — Por que las cadenas de herramientas fragmentadas no producen linaje compartido, y que hacer al respecto.
- GDPR and AI Training Data: What European Enterprises Must Do Before They Fine-Tune — Obligaciones del GDPR que aplican junto con los requisitos del EU AI Act para empresas europeas.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
Audit Trails for RAG Pipelines: What EU AI Act Article 30 Requires From Your Retrieval System
The EU AI Act mandates technical documentation and logging for high-risk AI systems. If your RAG pipeline feeds a high-risk application, every step from ingestion to retrieval needs an audit trail.
What Is Data Lineage — and Why Enterprise AI Teams Can't Ignore It in 2026
Data lineage tracks where training data came from and how it was transformed. In 2026, it's a compliance requirement under EU AI Act Article 10 and HIPAA — and most enterprise pipelines have none of it.
GDPR and AI Training Data: What European Enterprises Must Do Before They Fine-Tune
GDPR imposes specific obligations when personal data is used to train AI models. This guide covers lawful basis, data minimization, purpose limitation, and what 'consent' actually means for training datasets.