Construir un programa de gobernanza de datos de IA con arreglo al Artículo 10
Cómo implementar el Artículo 10 de la Ley de IA de la UE en la práctica: procedencia de los conjuntos de datos, evaluación del sesgo, la excepción del Art. 10, apdo. 5, el solapamiento con el RGPD y la documentación del Anexo IV.
El Artículo 10 del Reglamento (UE) 2024/1689 exige a los proveedores de sistemas de IA de alto riesgo someter sus conjuntos de datos de entrenamiento, validación y prueba a prácticas de gobernanza documentadas. No es una norma general de protección de datos — ese es el territorio del RGPD. El Artículo 10 trata específicamente de la calidad, la procedencia, la representatividad y la trazabilidad de los conjuntos de datos que moldean el comportamiento de un modelo de alto riesgo. Si su sistema se encuadra en el Anexo III (cribado de contratación, calificación crediticia, identificación biométrica y los otros seis ámbitos de alto riesgo), el Artículo 10 le vincula como proveedor. Los responsables del despliegue también tienen un papel más ligero pero real, como se explica más abajo.
Esta página trata de cómo implementar un programa de gobernanza de datos del Artículo 10 en la práctica. El texto legal del propio Artículo 10 — lo que dice y por qué existe — se cubre en la página de referencia del Artículo 10. Lea esa página junto con esta.
El plazo de alto riesgo se ha movido. En virtud del Ómnibus Digital acordado en mayo de 2026, los sistemas autónomos del Anexo III deben cumplir a partir del 2 de diciembre de 2027 (los sistemas integrados del Anexo I a partir del 2 de agosto de 2028), aplazando la fecha original de agosto de 2026. Eso es tiempo de margen, no un motivo para aplazar — construir un registro de gobernanza de datos defendible lleva varios meses incluso para un equipo bien organizado.
Qué cubre realmente el Artículo 10
El Artículo 10 se aplica a tres tipos de conjuntos de datos: datos de entrenamiento (utilizados para ajustar el modelo), datos de validación (utilizados para afinar los hiperparámetros y seleccionar la arquitectura durante el desarrollo) y datos de prueba (reservados para la evaluación final previa al despliegue). Los tres deben gobernarse. Los datos de validación se pasan por alto con frecuencia porque parecen internos al proceso de desarrollo — los reguladores que examinen un expediente de evaluación de la conformidad los buscarán.
Para cada tipo de conjunto de datos, el Artículo 10 impone cuatro requisitos sustantivos:
- Pertinencia y representatividad — los conjuntos de datos deben reflejar la finalidad prevista y la población de despliegue. Un modelo de calificación crediticia entrenado con solicitantes de una sola región no es representativo de un despliegue paneuropeo, y su expediente técnico debe o bien justificar esa limitación, o bien documentar cómo la compensó.
- Cantidad suficiente — datos suficientes para alcanzar la fiabilidad estadística que el caso de uso exige. No hay un umbral fijo; el estándar es una justificación documentada.
- Integridad y ausencia de errores — los procesos de aseguramiento de la calidad deben identificar los valores faltantes, las incoherencias y los duplicados. No necesita cero errores; necesita procedimientos documentados y registros de subsanación.
- Evaluación del sesgo y el deber de mitigarlo — el Artículo 10, apartado 2 le exige examinar los conjuntos de datos en busca de sesgos que pudieran dar lugar a resultados discriminatorios u otros riesgos. Cuando se detecte un sesgo, debe adoptar medidas para abordarlo. Este deber de mitigar, no meramente documentar, a menudo se infravalora.
Una disposición merece destacarse por sí sola: el Artículo 10, apartado 5. Normalmente, el Artículo 9 del RGPD prohíbe el tratamiento de datos de categorías especiales (origen racial o étnico, salud, orientación sexual y los demás). El Artículo 10, apartado 5 establece una excepción estricta: los proveedores pueden tratar datos de categorías especiales — con sujeción a las salvaguardas adecuadas — específica y exclusivamente con el fin de detectar y corregir el sesgo en los sistemas de IA de alto riesgo. La excepción no se extiende a otros fines. Si la invoca, documente las salvaguardas explícitamente; la justificación debe figurar en su expediente técnico.
La intersección con el RGPD
La gobernanza de datos para la IA no opera de forma aislada del RGPD. Los dos marcos se solapan de maneras importantes.
El Artículo 5 del RGPD (principios de tratamiento de datos) exige que los datos personales sean exactos, adecuados, pertinentes y limitados a lo necesario. Estos principios discurren en paralelo con los requisitos de representatividad e integridad del Artículo 10. Un conjunto de datos que incumple el principio de exactitud del Artículo 5 probablemente incumple también el estándar de integridad del Artículo 10 — pero las obligaciones son independientes, y cada una necesita su propio rastro documentado de cumplimiento.
El Artículo 9 del RGPD (datos de categorías especiales) se cruza directamente con la excepción de detección de sesgos del Artículo 10, apartado 5. Si trata datos de salud, biométricos o de origen para auditar su modelo en busca de sesgos, necesita tanto una base jurídica válida con arreglo al RGPD como una invocación documentada de la excepción del Artículo 10, apartado 5 con arreglo a la Ley de IA. Ninguna por sí sola es suficiente.
El Artículo 35 del RGPD (evaluación de impacto relativa a la protección de datos) y el Artículo 27 de la Ley de IA (evaluación de impacto relativa a los derechos fundamentales) son instrumentos distintos. Una EIPD examina los riesgos del tratamiento de datos personales; una EIDF — exigida a determinados responsables del despliegue que son organismos públicos y a los responsables del despliegue de los sistemas del Anexo III, puntos 5, letras b) y c) — examina el impacto en los derechos fundamentales. El Artículo 27, apartado 4 permite que la EIDF se base en una EIPD existente. No son intercambiables.
Si su equipo jurídico mantiene un registro de actividades de tratamiento con arreglo al Artículo 30 del RGPD, el inventario de conjuntos de datos exigido por el Artículo 10 puede desarrollarse junto a él — pero el registro del Artículo 10 necesita un detalle que un registro del RGPD normalmente no capta: procedencia a nivel de campo, transformaciones de preprocesamiento, resultados de las pruebas de sesgo, historial de versiones.
Procedencia y recopilación: de dónde proceden los datos importa
Un programa de gobernanza de datos comienza antes de que una sola fila entre en un modelo. El Artículo 10 le exige documentar cómo se recopiló cada conjunto de datos y dónde se originó. Para los datos de entrenamiento ensamblados a partir de registros históricos, las preguntas son: ¿quién generó los datos, en qué condiciones, en qué momento y con sujeción a qué criterios de selección? Para los datos obtenidos de terceros o de conjuntos de datos públicos, necesita la documentación del proveedor sobre la metodología de recopilación, y si esa documentación no existe o es inadecuada, usted asume el riesgo.
En la práctica, esto significa mantener un registro de conjuntos de datos que capte para cada conjunto de datos: el nombre y la versión, la fuente (sistema interno, proveedor tercero, corpus público), el intervalo de fechas de recopilación, el método de recopilación, cualquier condición de licencia o consentimiento, la finalidad prevista y el preprocesamiento aplicado antes del uso. No es un registro opcional — alimenta directamente el Anexo IV (las áreas de contenido de la documentación técnica exigidas por el Artículo 11), concretamente la sección sobre las metodologías de entrenamiento y los conjuntos de datos.
Para una empresa de tecnología de RR. HH. de 40 personas que construye una herramienta de cribado de currículos (Anexo III, punto 4, letra a)), el registro de conjuntos de datos podría mostrar que los datos de entrenamiento procedían de las propias decisiones históricas de contratación de la empresa a lo largo de cinco años. Esa procedencia plantea de inmediato una pregunta que el Artículo 10 le obliga a responder: ¿reflejan esas decisiones históricas patrones discriminatorios del pasado? La respuesta moldea el trabajo de evaluación del sesgo que viene a continuación.
Preparación: etiquetado, limpieza y el rastro documental
La preparación de los datos — limpieza, etiquetado, anotación — también debe documentarse. Si utiliza datos etiquetados, el protocolo de etiquetado importa: quién los etiquetó, qué instrucciones se dieron, qué tasa de concordancia entre anotadores se alcanzó y cómo se resolvieron las discrepancias. Si las instrucciones de etiquetado codificaron una categoría controvertida (por ejemplo, «candidato cualificado» definido por criterios que contienen ellos mismos un sesgo), el modelo hereda ese sesgo con independencia de lo cuidadosamente que se limpien los datos.
Los procedimientos de limpieza deben registrarse. Si imputó valores faltantes, documente el método de imputación y la proporción de registros afectados. Si excluyó registros, documente los criterios de exclusión y el volumen eliminado. Si estandarizó formatos entre fuentes de datos, documente las reglas de transformación. Los reguladores no esperan un conjunto de datos impecable; esperan pruebas de que se tomó en serio la calidad y tomó decisiones documentadas.
Controle las versiones de sus conjuntos de datos. Si reentrena con un conjunto de datos actualizado seis meses después del despliegue inicial, la nueva versión necesita su propio registro de gobernanza. La evaluación de la conformidad realizada con arreglo al Artículo 43 cubre el sistema en un momento dado; si los datos de entrenamiento cambian materialmente, puede ser necesario reexaminar la evaluación.
Representatividad y la población de despliegue
El requisito de representatividad del Artículo 10 tiene una prueba práctica: ¿refleja su conjunto de datos la población que el sistema encontrará en producción? Un modelo de calificación crediticia entrenado con datos de un único Estado miembro no es representativo si va a desplegarse en toda la UE. Una herramienta de contratación entrenada con solicitudes de un único sector industrial se comportará de forma diferente cuando se aplique a otro.
La representatividad no es lo mismo que el equilibrio demográfico. No necesita números iguales de cada subgrupo. Lo que necesita son pruebas documentadas de que la distribución en su conjunto de datos es adecuada para el contexto de despliegue previsto y, cuando existan lagunas, una evaluación razonada de si esas lagunas crean un riesgo material de sesgo.
Un error habitual: confundir la representatividad con el tamaño. Un conjunto de datos grande que excluye sistemáticamente a una población es menos representativo que uno más pequeño y bien estratificado. Documente tanto el tamaño como la composición.
Evaluación del sesgo y el deber de mitigación
Esta es la parte más exigente desde el punto de vista técnico del Artículo 10, y la que se malinterpreta con más frecuencia. La obligación no es meramente detectar el sesgo — es detectarlo y después adoptar medidas para abordarlo. Documentar un sesgo sin actuar no satisface el Artículo 10.
Un proceso práctico de evaluación del sesgo para un sistema de alto riesgo implica:
- Identificar las características demográficas pertinentes para el caso de uso (sexo, edad, origen nacional y otras protegidas en virtud de la Carta de los Derechos Fundamentales de la UE y del Derecho nacional aplicable).
- Desglosar las métricas de rendimiento del modelo (exactitud, tasa de falsos positivos, tasa de falsos negativos) por esas características.
- Documentar las disparidades observadas y su magnitud.
- Evaluar si las disparidades son aceptables dada la finalidad y el nivel de riesgo del sistema, o si indican un problema que debe abordarse.
- Si se requiere mitigación: implementarla (reequilibrar los datos, ajustar los umbrales, reentrenar, excluir características sesgadas) y documentar lo que se hizo.
- Volver a probar tras la mitigación y documentar los resultados.
No se le exige lograr un rendimiento idéntico en todos los grupos — eso a menudo es imposible y puede introducir distorsiones por sí mismo. Se le exige haber examinado la cuestión, haber documentado sus conclusiones y haber adoptado medidas proporcionadas. El conjunto de datos de prueba es el vehículo principal para esto; debe diseñarse para permitir el análisis desglosado, lo que significa que debe contener suficientes ejemplos de cada subgrupo pertinente para sustentar comparaciones estadísticamente significativas.
Si la información demográfica no está disponible en su conjunto de datos, documente esa limitación. Utilice el análisis por sustitutos cuando proceda y documente la metodología. Si la laguna no puede cerrarse, documente medidas compensatorias — por ejemplo, una supervisión humana reforzada en virtud del Artículo 14 en el despliegue, o la vigilancia poscomercialización en virtud del Artículo 72 con comprobaciones de detección de sesgos una vez que se acumulen los resultados del mundo real.
Compuertas de calidad de los datos
Una compuerta de calidad es un punto de control en el que los datos se evalúan frente a criterios definidos antes de avanzar a la siguiente fase del desarrollo. Incorporar compuertas de calidad a su cadena de datos operativiza el Artículo 10; también es más defendible que una revisión de calidad retrospectiva realizada solo cuando lo piden los reguladores.
Un conjunto mínimo de compuertas para un proceso de desarrollo de IA de alto riesgo:
- Compuerta de ingestión: comprobaciones automatizadas de integridad (campos obligatorios cumplimentados), coherencia de formato (fechas en el formato esperado, valores numéricos dentro del rango esperado) y ausencia de patrones de registros corruptos conocidos.
- Compuerta previa al entrenamiento: revisión de la composición del conjunto de datos frente a los requisitos de representatividad documentados para este sistema; confirmación de que los conjuntos de entrenamiento y de validación están separados.
- Compuerta previa a la prueba: confirmación de que los datos de prueba no se han utilizado en ninguna fase previa del desarrollo; revisión de la composición del conjunto de datos de prueba para la cobertura de la evaluación del sesgo.
- Compuerta posterior a la evaluación del sesgo: aprobación de que se ha realizado el análisis del sesgo, se han documentado los resultados y se ha completado cualquier mitigación requerida antes de que el sistema avance a la evaluación de la conformidad.
Cada compuerta produce un registro — una entrada de registro, una lista de comprobación aprobada, un informe automatizado. Esos registros alimentan el expediente técnico del Artículo 11.
Documentación que alimenta el Anexo IV
El Artículo 11 exige a los proveedores de sistemas de IA de alto riesgo mantener la documentación técnica especificada en el Anexo IV. El Anexo IV enumera nueve áreas de contenido. Varias de ellas requieren directamente pruebas del Artículo 10:
- Anexo IV, punto 3: descripción de los datos de entrenamiento, validación y prueba, incluidas la procedencia, el preprocesamiento, los criterios de selección, las características y cómo los datos cumplen los requisitos del Artículo 10.
- Anexo IV, punto 5: descripción de cualquier modelo preentrenado utilizado y su gobernanza de datos.
- Anexo IV, punto 6: descripción de la metodología de desarrollo, que debe incluir cómo se llevó a cabo la gobernanza de datos.
Su registro de conjuntos de datos del Artículo 10, los registros de las compuertas de calidad, los informes de evaluación del sesgo y las decisiones de mitigación son la materia prima que nutre estas secciones del Anexo IV. Si trata la gobernanza de datos como una actividad de desarrollo y la documentación técnica como una actividad de cumplimiento separada, duplicará esfuerzos y creará incoherencias. El enfoque más eficiente: diseñe sus registros de gobernanza de datos de modo que puedan incorporarse directamente al expediente técnico del Anexo IV.
La documentación técnica debe compilarse antes de la evaluación de la conformidad con arreglo al Artículo 43, conservarse durante diez años tras la introducción del sistema en el mercado (Artículo 18) y ponerse a disposición de las autoridades competentes que la soliciten.
Papeles y trazabilidad
Los proveedores soportan la carga principal del Artículo 10. Si desarrolla un sistema de IA de alto riesgo bajo su propio nombre y lo introduce en el mercado o lo pone en servicio, es proveedor con arreglo al Artículo 16 y el Artículo 10 se aplica en su totalidad. Esto incluye a las empresas SaaS que envían productos impulsados por IA y a las empresas que integran modelos de terceros en sistemas que etiquetan y venden.
Los responsables del despliegue — organizaciones que utilizan un sistema de alto riesgo desarrollado por otra persona — no están directamente vinculados por los requisitos de la fase de desarrollo del Artículo 10. Pero los responsables del despliegue no son pasivos. El Artículo 26 exige a los responsables del despliegue utilizar los sistemas de conformidad con las instrucciones del proveedor, y cuando un responsable del despliegue utiliza sus propios datos con un sistema de alto riesgo (para ajuste fino o tratamiento operativo), ese uso de datos entra dentro de la expectativa de gobernanza. Los responsables del despliegue también soportan la responsabilidad de la vigilancia poscomercialización en virtud del Artículo 72, que incluye detectar la deriva del sesgo a medida que se acumulan los resultados del mundo real.
El cambio de papel en virtud del Artículo 25 merece destacarse explícitamente. Un responsable del despliegue que modifica sustancialmente un sistema de alto riesgo, o que lo introduce en el mercado bajo su propio nombre, se convierte en proveedor del sistema modificado o remarcado. Las obligaciones del Artículo 10 se aplican entonces en su totalidad a todo aquello que los registros de gobernanza del proveedor original no cubrieran.
La trazabilidad de los datos — el rastro de auditoría que muestra de dónde proceden los datos, cómo se transformaron y cómo se utilizaron — cumple dos funciones del Artículo 10. Primero, permite a la autoridad competente verificar sus afirmaciones de gobernanza. Segundo, le permite rastrear una conclusión de sesgo hasta su origen: si una detección de sesgo poscomercialización revela un problema, la documentación de trazabilidad le dice si la cuestión se origina en la composición de los datos de entrenamiento, en las decisiones de preprocesamiento o en la deriva del contexto de despliegue.
Cómo ayuda Confir
El módulo AITR de Confir estructura las pruebas de gobernanza de datos que necesita su expediente técnico. Las preguntas de admisión se asignan a los requisitos del Artículo 10 — procedencia de los conjuntos de datos, procedimientos de preparación, evaluación de la representatividad, metodología de detección del sesgo y documentación de la mitigación. Como la lógica se basa en reglas y es determinista, los mismos datos de entrada producen el mismo resultado estructurado cada vez; no hay una brecha de inferencia entre lo que introduce y lo que aparece en el paquete de documentación del Anexo IV generado.
La documentación técnica generada incluye las secciones de conjuntos de datos del Artículo 11 precumplimentadas a partir de sus respuestas de AITR, listas para su revisión y aprobación antes de la evaluación de la conformidad del Artículo 43.
Preguntas frecuentes
¿Se aplica el Artículo 10 a los sistemas de IA que no son de alto riesgo?
No. Las obligaciones de gobernanza de datos del Artículo 10 se aplican únicamente a los sistemas de IA de alto riesgo clasificados con arreglo al Artículo 6 con referencia al Anexo III (y al Anexo I para los componentes de seguridad de productos). Los sistemas de riesgo limitado (Artículo 50) y los sistemas de riesgo mínimo no tienen obligaciones del Artículo 10. Si no está seguro de si su sistema cumple los requisitos de alto riesgo, el filtro del Artículo 6, apartado 3 permite excluir un sistema que se encuadre en un ámbito del Anexo III si no plantea un riesgo significativo de perjuicio — pero cualquier sistema que elabore perfiles de personas físicas es siempre de alto riesgo, y debe documentar su razonamiento de clasificación en cualquier caso.
¿Qué es la excepción de datos de categorías especiales del Artículo 10, apartado 5 y cuándo puedo utilizarla?
El Artículo 10, apartado 5 permite a los proveedores tratar datos de categorías especiales del RGPD (datos de salud, datos biométricos, origen racial o étnico y otros enumerados en el Artículo 9 del RGPD) con el fin específico de detectar y corregir el sesgo en los conjuntos de datos de IA de alto riesgo, con sujeción a las salvaguardas adecuadas. La excepción es estricta: cubre la detección y la corrección del sesgo, no el entrenamiento general del modelo. Debe documentar las salvaguardas aplicadas, mantener una base jurídica conforme con el RGPD junto a la invocación del Artículo 10, apartado 5 e incluir la justificación en su expediente técnico. Invocar la excepción para fines más allá del trabajo de sesgo anula su protección.
¿Quién soporta la responsabilidad del Artículo 10 cuando el proveedor utiliza un modelo de base de un tercero?
El proveedor del sistema de alto riesgo es responsable del cumplimiento del Artículo 10 para todo el sistema — incluido cualquier modelo de base de un tercero incorporado en él. Si el proveedor del modelo de base suministra documentación de gobernanza de datos (características de los datos de entrenamiento, evaluaciones de sesgo), debe obtenerla e incorporarla. Si esa documentación no está disponible o es inadecuada, debe realizar su propia evaluación del comportamiento del modelo de base en su contexto de despliegue y documentar las conclusiones. No puede cumplir su obligación del Artículo 10 simplemente remitiendo a un tercero.
¿Qué significa la «representatividad» en la práctica para una empresa que despliega en varios Estados miembros de la UE?
La representatividad se evalúa en relación con la población de despliegue prevista y el contexto de uso. Si su sistema de alto riesgo va a tomar decisiones trascendentes sobre personas de varios Estados miembros, sus datos de entrenamiento deben reflejar la distribución de las características que esas personas aportan — incluida la variación geográfica, lingüística, socioeconómica y demográfica. No necesita un muestreo exactamente proporcional, pero sí una evaluación documentada de si los subgrupos materiales están representados a un nivel suficiente para sustentar un rendimiento fiable del modelo y, cuando no lo estén, una justificación documentada o una medida compensatoria.
¿Cómo interactúa el Artículo 10 con el principio de minimización de datos del RGPD?
El Artículo 5, apartado 1, letra c) del RGPD exige que los datos personales se limiten a lo necesario para la finalidad (minimización de datos). El Artículo 10 exige que los conjuntos de datos sean pertinentes, representativos y suficientes. Estos pueden tirar en direcciones opuestas: puede necesitar más datos de determinados subgrupos para satisfacer la representatividad, mientras que el RGPD desfavorece recopilar datos más allá de lo necesario. La resolución es la especificidad de la finalidad y la proporcionalidad documentada: los datos recopilados específicamente para la detección de sesgos en virtud de la excepción del Artículo 10, apartado 5 están expresamente permitidos; los datos recopilados de forma amplia «por si ayudan» no lo están. Diseñe sus protocolos de recopilación de datos para servir a finalidades definidas y documente esas finalidades antes de la recopilación.
¿Qué sanción se aplica si no se cumplen los requisitos del Artículo 10?
El incumplimiento del Artículo 10 es un incumplimiento de un requisito de IA de alto riesgo, que se encuadra en el Artículo 99, apartado 4 del Reglamento: multas de hasta 15 000 000 EUR o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Para las pymes y las empresas emergentes, el Artículo 99, apartado 6 limita la multa al menor del porcentaje o el importe fijo — una protección de proporcionalidad genuina. No existe una categoría separada de «Artículo 84», y cifras como «30 millones de euros o el 6 %» no existen en el Reglamento.
¿Debe la documentación estar en un formato o idioma concretos?
El Reglamento no prescribe un formato. El Anexo IV establece el contenido exigido para la documentación técnica; cómo organiza y presenta ese contenido es decisión suya. Las autoridades competentes de cada Estado miembro operan en su propia lengua, así que si prevé una auditoría en Alemania o Francia, tener la documentación disponible en esa lengua es una gestión práctica del riesgo aunque no sea un requisito legal estricto. Las herramientas automatizadas que generan un resultado estructurado del Anexo IV en forma exportable ayudan significativamente aquí.
Guías relacionadas
- requisitos de gobernanza de datos del Artículo 10
- visión general de la gobernanza de la IA
- herramientas de comparación de software de gobernanza
- documentación técnica del Artículo 11
- sistema de gestión de riesgos del Artículo 9
- requisitos de gestión de la calidad del Artículo 17
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →