Desde que el Reglamento Europeo de Inteligencia Artificial (IA Act, Reglamento (UE) 2024/1689) empezó a desplegar sus obligaciones, la mayoría de las organizaciones ha puesto el foco donde parecía natural: en los modelos. Inventariar sistemas de IA, clasificarlos por riesgo, revisar los casos de uso prohibidos, preparar la documentación técnica. Todo ello es necesario. Pero hay una lectura del reglamento que muchas organizaciones todavía no han hecho y que cambia por completo el orden de prioridades: el IA Act es, en gran medida, una norma sobre datos.
No es una interpretación forzada: el propio reglamento dedica su artículo 10, titulado precisamente «Datos y gobernanza de datos», a establecer requisitos detallados sobre los conjuntos de datos con los que se entrenan, validan y prueban los sistemas de IA de alto riesgo. Y lo que ese artículo describe no es otra cosa que un programa de gobierno del dato aplicado al ciclo de vida de la IA. En este artículo —que continúa la reflexión que iniciamos al hablar del papel del CDO en la era de la inteligencia artificial— explicamos qué exige exactamente el IA Act en materia de datos, por qué es imposible cumplirlo con esfuerzos puntuales y cómo convertir la obligación en ventaja.
¿Qué exige el artículo 10 del IA Act?
Para los sistemas de IA de alto riesgo —los que operan en ámbitos como el empleo, la educación, el crédito, la sanidad o los servicios esenciales—, el artículo 10 exige que los conjuntos de datos de entrenamiento, validación y prueba estén sujetos a prácticas de gobernanza y gestión de datos apropiadas. En concreto, el reglamento pide, entre otras cosas:
-
- Decisiones de diseño documentadas: por qué se han elegido esos datos y no otros para el propósito del sistema.
- Trazabilidad del origen: de dónde proceden los datos, cómo se recogieron y, en el caso de datos personales, con qué finalidad original.
- Transparencia en la preparación: qué operaciones se han aplicado (anotación, etiquetado, limpieza, enriquecimiento, agregación) antes de entrenar.
- Evaluación de la idoneidad: si los datos son relevantes, suficientemente representativos y, en la medida de lo posible, completos y libres de errores para la finalidad prevista.
- Gestión de sesgos: examinar los posibles sesgos de los datos que puedan afectar a la salud, la seguridad o los derechos fundamentales, y adoptar medidas para detectarlos, prevenirlos y mitigarlos.
- Identificación de carencias: detectar las lagunas o deficiencias de los datos que impidan cumplir el reglamento, y cómo se van a subsanar.
- Adecuación al contexto: que los datos tengan en cuenta las características propias del entorno geográfico, conductual o funcional donde el sistema se va a utilizar.
Leída con ojos de gestión, esta lista tiene un mensaje inequívoco: no se puede responder a ninguno de estos puntos «para la auditoría». Quien no sepa de dónde vienen sus datos de entrenamiento no puede reconstruir su linaje a posteriori; quien no mida la calidad de sus datasets no puede acreditar su completitud; quien no tenga catalogados sus datos no puede siquiera identificar cuáles alimentan cada sistema.
Del artículo 10 al gobierno del dato: la traducción
Lo interesante es que cada exigencia del artículo 10 se corresponde, casi línea por línea, con una capacidad clásica del gobierno del dato, de las que las especificaciones UNE 0077 a 0081 vienen sistematizando para las organizaciones españolas:
|
Lo que pide el IA Act (art. 10) |
La capacidad de gobierno del dato que lo hace posible |
Referencia |
|
Trazabilidad del origen y la preparación de los datos |
Linaje del dato y gestión de metadatos, de los que hablamos en nuestro post sobre data lineage |
UNE 0078 (gestión del dato) |
|
Idoneidad: relevancia, representatividad, completitud, ausencia de errores |
Medición y evaluación de la calidad con características y métricas definidas |
UNE 0081 (evaluación de la calidad) |
|
Decisiones de diseño documentadas y responsabilidades claras |
Políticas, roles y responsabilidades sobre el dato (propietarios, custodios) |
UNE 0077 (gobierno del dato) |
|
Gestión de sesgos y de riesgos sobre derechos fundamentales |
Gestión de riesgos del dato, integrada con la ética y el cumplimiento |
UNE 0077 y marcos de riesgo del dato |
|
Identificación y subsanación de carencias |
Ciclo de vida del dato y planes de mejora de la calidad |
UNE 0078 para ciclo de vida y UNE 0079 para gestión de la calidad |
|
Datos personales tratados con base y finalidad adecuadas |
Cumplimiento normativo integrado (RGPD) en las políticas de datos |
UNE 0077 +UNE 0078+ RGPD |
La conclusión de la tabla es la tesis de este artículo: el artículo 10 no pide nada que un gobierno del dato maduro no tenga ya. Y su reverso: para una organización sin gobierno del dato, el cumplimiento del IA Act no es un proyecto de compliance, es un proyecto de transformación que conviene empezar cuanto antes, porque las capacidades que exige (catálogo, linaje, calidad medida, roles) tardan meses o años en construirse, no semanas.
No es solo el artículo 10 (ni solo el alto riesgo)
Aunque el artículo 10 es el corazón «de datos» del reglamento, la dependencia es más amplia:
-
- La documentación técnica que debe acompañar a los sistemas de alto riesgo exige describir los datos utilizados, algo imposible sin catálogo ni metadatos.
- Los proveedores de modelos de IA de uso general deben elaborar y publicar un resumen suficientemente detallado del contenido utilizado para el entrenamiento, lo que presupone saber —y poder demostrar— qué datos se usaron y con qué derechos.
- Las obligaciones de supervisión humana y monitorización poscomercialización requieren detectar degradaciones del comportamiento del sistema que, en la práctica, suelen empezar por degradaciones de los datos de entrada.
- Y el régimen sancionador da la medida de la seriedad del asunto: las multas del IA Act pueden alcanzar, en los tramos más graves, decenas de millones de euros o porcentajes significativos de la facturación global, en una escala comparable a la del RGPD.
Además, hay una conexión directa con los espacios de datos que venimos explorando en esta serie: si los datos de entrenamiento provienen de terceros, las garantías del artículo 10 hay que traerlas de fuera. Un producto de datos con su etiqueta de calidad, su linaje documentado y su data contract permite a quien lo consume acreditar origen, preparación e idoneidad; un fichero descargado de procedencia difusa, no. El dato bien gobernado y bien empaquetado vale más precisamente porque transfiere cumplimiento junto con el contenido.
Convertir la obligación en ventaja
Sería un error leer todo lo anterior solo en clave defensiva. Las organizaciones que se toman en serio el gobierno de sus datos de IA obtienen tres retornos que exceden el cumplimiento:
-
- Mejores modelos: los datos relevantes, representativos y de calidad medida no solo satisfacen al regulador; producen sistemas que aciertan más y fallan de forma menos costosa. La factura de un modelo entrenado con datos deficientes no la pone la autoridad: la ponen los clientes.
- Velocidad: el equipo de ciencia de datos que encuentra los datos catalogados, documentados y con calidad conocida empieza a modelar en días; el que tiene que reconstruir el origen de cada dataset, en meses. El gobierno del dato es, contra el tópico, un acelerador.
- Confianza demostrable: poder enseñar el linaje, la calidad y la gestión de sesgos de los datos de un sistema de IA es un argumento comercial creciente ante clientes y socios, especialmente en sectores regulados, y la base de cualquier sello o certificación de IA responsable a la que se aspire.
¿Por dónde empezar?
Para una organización que desarrolla o adquiere sistemas de IA, el camino razonable combina la vista «IA» y la vista «dato»:
-
- Inventariar los sistemas de IA propios y adquiridos, y clasificarlos según el riesgo del IA Act, para saber a cuáles aplica el artículo 10.
- Mapear sus datos: identificar qué conjuntos de datos entrenan, validan y alimentan cada sistema, y catalogarlos con sus metadatos y su origen.
- Medir la calidad de esos conjuntos conforme a un método normalizado como UNE 0081, priorizando los sistemas de mayor riesgo.
- Documentar el linaje y las operaciones de preparación, idealmente de forma automatizada e integrada en los pipelines.
- Establecer el proceso de gestión de sesgos, con responsables, métricas y revisiones periódicas, no como ejercicio único.
- Institucionalizar: llevar todo lo anterior a las políticas, roles y órganos del gobierno del dato de la organización, para que sobreviva al proyecto que lo puso en marcha.
El IA Act ha hecho explícito lo que la práctica llevaba años demostrando: no hay inteligencia artificial confiable sobre datos ingobernados. Su artículo 10 convierte en obligación jurídica lo que el gobierno del dato —con marcos como las especificaciones UNE 0077 a 0081— venía proponiendo como buena práctica: saber qué datos se tienen, de dónde vienen, qué calidad tienen y qué riesgos incorporan. Las organizaciones pueden vivirlo como una carga regulatoria más o como la ocasión definitiva para financiar la asignatura pendiente. Nuestra experiencia es clara: las segundas no solo cumplirán antes; competirán mejor.
Si tu organización quiere evaluar si sus datos están preparados para el IA Act, construir su catálogo, su linaje y su medición de calidad, o integrar la IA en su modelo de gobierno del dato, en DQTeam podemos ayudarte. ¡Hablemos de datos!
