Artículo 10 de la Ley de IA de la UE: gobernanza de datos para los sistemas de IA de alto riesgo

El Artículo 10 del Reglamento (UE) 2024/1689 establece las obligaciones de gobernanza de datos que se aplican a los sistemas de IA de alto riesgo entrenados con datos. Abarca los conjuntos de datos de entrenamiento, validación y prueba — la calidad de los datos a partir de los cuales aprende un modelo, no la competencia de las personas que lo operan. La competencia del personal y la alfabetización en materia de IA residen en el Artículo 4, que se aplica desde el 2 de febrero de 2025. Ambos se confunden a menudo en la planificación del cumplimiento; abordan obligaciones completamente distintas.

Si su organización desarrolla o introduce en el mercado un sistema de IA de alto riesgo que utiliza aprendizaje automático, el Artículo 10 rige las decisiones sobre datos adoptadas antes de entrenar un solo peso. Acertar en esas decisiones — y documentarlas — no es opcional. El techo sancionador por el incumplimiento de los requisitos de alto riesgo es de 15 millones de euros o el 3 % del volumen de negocios anual mundial, si esta última cifra es mayor (Artículo 99). El plazo para los sistemas autónomos del Anexo III, en virtud del Ómnibus Digital acordado en mayo de 2026, es el 2 de diciembre de 2027.

---

Lo que el Artículo 10 regula realmente

La obligación es precisa: los sistemas de IA de alto riesgo que se entrenan con datos deben utilizar conjuntos de datos de entrenamiento, validación y prueba que cumplan criterios de calidad específicos. El Artículo no se aplica a los sistemas basados en reglas o deterministas que no contienen parámetros aprendidos — esos quedan sujetos a las demás obligaciones de los Artículos 9 a 15 sin la capa específica de conjuntos de datos.

Para los sistemas que sí utilizan modelos aprendidos, los requisitos se agrupan en torno a seis áreas:

1. Decisiones de diseño — documentar las decisiones de diseño que orientaron la selección de los conjuntos de datos.
2. Recopilación y origen de los datos — registrar de dónde proceden los datos y cómo se recopilaron.
3. Preparación de los datos — documentar la anotación, el etiquetado, la depuración, la actualización, el enriquecimiento y la agregación.
4. Supuestos — exponer explícitamente qué se supone que miden o representan los datos.
5. Disponibilidad, cantidad e idoneidad — evaluar si los datos son adecuados para la finalidad prevista.
6. Examen de sesgos — identificar los sesgos que puedan afectar a la salud o la seguridad o causar discriminación, y establecer medidas para detectarlos, prevenirlos y mitigarlos.

A lo largo de todas estas áreas, los conjuntos de datos deben ser pertinentes, suficientemente representativos, lo más exentos de errores posible y completos para su finalidad prevista — teniendo en cuenta el entorno geográfico, contextual, conductual y funcional en el que se utilizará el sistema (Artículo 10, apartado 3).

---

El Artículo 10 trata de los datos, no de la formación de las personas

Esta distinción importa lo suficiente como para enunciarla con claridad. Las antiguas orientaciones de cumplimiento en este ámbito confunden con frecuencia los requisitos sobre conjuntos de datos del Artículo 10 con la obligación de formar al personal en el uso de la IA. Son cosas distintas:

• El Artículo 4 (alfabetización en materia de IA) exige a los proveedores y a los responsables del despliegue que adopten medidas para garantizar que el personal tenga suficiente alfabetización en materia de IA. Se aplica desde el 2 de febrero de 2025.
• El Artículo 10 (datos y gobernanza de datos) exige que los conjuntos de datos utilizados para entrenar, validar y probar un sistema de IA de alto riesgo cumplan normas de calidad y gobernanza. Es una obligación técnica y de documentación, no de gestión de personas.

Una empresa que haya formado plenamente a sus empleados en herramientas de IA pero que no tenga una evaluación de sesgos documentada para su modelo de contratación no cumple el Artículo 10. Las dos obligaciones no se sustituyen entre sí.

---

Los seis requisitos de gobernanza de datos en detalle

Decisiones de diseño pertinentes (Artículo 10, apartado 2, letra a))

Antes de que comience la recopilación de datos, las decisiones de diseño que configuran el conjunto de datos — qué variables incluir, cuáles excluir, qué medidas indirectas utilizar — deben adoptarse de forma consciente y dejarse registradas. Los reguladores que examinen un modelo a posteriori deberían poder rastrear por qué se construyó el conjunto de datos tal como se hizo.

Para un modelo de calificación crediticia, esto significa documentar por qué se utilizaron los ingresos como característica, por qué se incluyó o excluyó el historial de pagos de alquiler y por qué la ventana temporal abarca 2018-2023 y no otro período. No son ocurrencias tardías; configuran lo que el modelo aprende a optimizar.

Procesos de recopilación y origen de los datos (Artículo 10, apartado 2, letra b))

La cadena de procedencia debe estar completa: ¿de dónde procedían los datos brutos, quién los recopiló, mediante qué método y sobre qué base jurídica? Las fuentes de datos de terceros requieren registros de licencias. Los conjuntos de datos públicos requieren documentación de la fuente y una comprobación de las condiciones de la licencia. Los datos internos requieren la confirmación de que la recopilación fue lícita.

Este requisito se solapa con las obligaciones del RGPD. Cuando los datos de entrenamiento incluyen datos personales, deben documentarse la base jurídica de la recopilación (Artículo 6 del RGPD) y, para los datos de categorías especiales, la condición adicional (Artículo 9 del RGPD). Los registros de gobernanza de datos del Artículo 10 y los registros del RGPD deben mantenerse de forma coherente; las incoherencias saldrán a la luz en una auditoría.

Preparación de los datos (Artículo 10, apartado 2, letra c))

Debe registrarse cada paso que transforma los datos brutos en un formato listo para el entrenamiento: las instrucciones de anotación y las cualificaciones de los anotadores, la metodología de etiquetado, las reglas de deduplicación, el tratamiento de valores atípicos, la estrategia de imputación de valores faltantes, las decisiones de normalización y escalado, y cualquier enriquecimiento o agregación de datos a partir de fuentes adicionales.

En la práctica, es aquí donde la documentación de la mayoría de las organizaciones se queda corta. La canalización de preprocesamiento suele tratarse como un detalle de implementación de ingeniería más que como un entregable de cumplimiento. Con arreglo al Artículo 10 es ambas cosas.

Formulación de supuestos (Artículo 10, apartado 2, letra d))

¿Qué representan los datos? ¿De qué fenómeno del mundo real son una medida indirecta? Estos supuestos deben exponerse explícitamente, porque un modelo optimizado para una medida indirecta puede divergir del resultado del mundo real de formas que causen daño.

Un modelo de cribado de candidatos entrenado con decisiones de contratación históricas no mide «quién tendrá éxito en este puesto». Mide «a quién se seleccionó históricamente, y quién lo hizo». Si la contratación histórica estuvo sesgada, la medida indirecta codifica ese sesgo. Articular y documentar este supuesto es el paso que obliga a una reflexión honesta sobre lo que los datos pueden y no pueden sustentar.

Evaluación de la disponibilidad, la cantidad y la idoneidad (Artículo 10, apartado 2, letra e))

El conjunto de datos debe ser adecuado para el caso de uso. La inadecuación puede deberse al tamaño (demasiados pocos ejemplos de una clase), a la obsolescencia temporal (entrenar con comportamiento prepandémico para un producto pospandémico), al desajuste geográfico (entrenar con datos de EE. UU. y desplegar en Europa Central) o al desajuste funcional (entrenar con decisiones de contexto profesional y desplegar en contextos de consumo).

Esta evaluación debe documentarse y revisarse cuando cambien la finalidad prevista o el contexto de despliegue. Un modelo reutilizado en una nueva geografía o sector hereda la evaluación de idoneidad de los datos de su predecesor, que puede haber dejado de ser válida.

Examen de sesgos (Artículo 10, apartado 2, letra f))

Este es el requisito que atrae la mayor atención regulatoria. Los proveedores deben identificar y examinar los conjuntos de datos de entrenamiento, validación y prueba en busca de posibles sesgos que puedan afectar a la salud o la seguridad, o causar una situación de discriminación prohibida por el Derecho de la Unión — en particular la discriminación por motivos de raza, origen étnico, color, sexo, lengua, religión, opinión política, nacionalidad, origen social, patrimonio, nacimiento, discapacidad, edad u orientación sexual.

Cuando se identifiquen tales sesgos, el proveedor debe aplicar medidas para detectarlos, prevenirlos y mitigarlos. «Medidas aplicadas» significa medidas documentadas: qué se encontró, qué se hizo al respecto y qué disparidad residual (si la hay) persiste y por qué motivos se considera aceptable.

El Artículo no exige que se elimine toda disparidad — eso a menudo es técnicamente imposible. Exige que el sesgo se examine de forma genuina y que se diseñen y apliquen medidas de mitigación. La documentación de ese proceso es el entregable de cumplimiento.

Identificación de lagunas y deficiencias de datos (Artículo 10, apartado 2, letra f), continuación)

Más allá del sesgo activo, los proveedores deben identificar las lagunas y deficiencias de datos y documentar cómo se abordan. Un conjunto de datos que infrarrepresenta a un grupo demográfico tiene una laguna; uno que utiliza variables indirectas inexactas tiene una deficiencia. Ambas requieren documentación y una respuesta meditada — ya sea la recopilación de datos adicionales, una restricción del uso previsto o una limitación documentada señalada a los responsables del despliegue.

---

Artículo 10, apartado 5: tratamiento de datos personales de categorías especiales para la detección de sesgos

Una disposición del Artículo 10 se pasa por alto con frecuencia. El Artículo 10, apartado 5, crea un permiso acotado y condicional para tratar datos personales de categorías especiales con arreglo al Artículo 9 del RGPD — incluidos el origen racial o étnico, los datos de salud, la orientación sexual y categorías similares — estrictamente con el fin de detectar y corregir sesgos en los datos de entrenamiento.

Este permiso se aplica únicamente cuando:

• el tratamiento es estrictamente necesario para la finalidad de detección de sesgos;
• se han establecido salvaguardias adecuadas para los derechos y libertades fundamentales de los interesados;
• se aplican limitaciones técnicas a la reutilización;
• se implantan medidas de seguridad acordes con el estado de la técnica;
• los datos se han anonimizado o, cuando ello no sea posible, seudonimizado y protegido; y
• los datos no se transmiten a terceros ni se utilizan para ningún otro fin.

No es una licencia general para recopilar datos sensibles. Es una excepción estrictamente delimitada para permitir que los proveedores midan la disparidad demográfica en los resultados — algo que, de otro modo, es difícil de hacer sin los atributos demográficos subyacentes. Utilizarla requiere todo el aparato de gobernanza del Artículo 9 del RGPD (evaluación de impacto relativa a la protección de datos, base jurídica adecuada, participación del DPD cuando proceda) además de las salvaguardias del Artículo 10.

En la práctica, un proveedor de tecnología de contratación que desee medir si su modelo produce resultados distintos para candidatos de diferentes orígenes étnicos puede, en virtud del Artículo 10, apartado 5, tratar datos de origen étnico para esa finalidad limitada — siempre que se cumplan las salvaguardias. No puede conservar ni reutilizar esos datos para ningún otro fin.

---

El Artículo 10 y el RGPD: dónde se cruzan ambos regímenes

Los sistemas de IA de alto riesgo se entrenan habitualmente con datos personales. Eso significa que el cumplimiento del Artículo 10 y el cumplimiento del RGPD discurren en paralelo, y las obligaciones de documentación se solapan de formas que pueden hacer tropezar a las organizaciones que las tratan como flujos de trabajo separados.

Base jurídica para el entrenamiento. El RGPD exige una base jurídica válida para cada actividad de tratamiento (Artículo 6 del RGPD). Entrenar un modelo con registros de empleados, transacciones de clientes o datos de salud es una actividad de tratamiento. Si la recopilación de datos original carecía de una base jurídica adecuada para fines de entrenamiento de modelos, utilizar esos datos con arreglo al Artículo 10 crea una infracción acumulativa — una vulneración del RGPD incrustada en su paquete de cumplimiento de la Ley de IA.

Limitación de la finalidad. El principio de limitación de la finalidad del RGPD (Artículo 5, apartado 1, letra b)) restringe la reutilización de datos personales para fines incompatibles con la finalidad de recopilación original. Entrenar un modelo de contratación con datos de nóminas recopilados con fines de nómina puede quedar fuera de la finalidad original. Los proveedores deben analizar esto antes de incluir cualquier dato en un conjunto de entrenamiento, y documentar el análisis. Las evaluaciones de «finalidad compatible» deben figurar junto a la documentación de origen del Artículo 10.

Minimización y conservación de los datos. El Artículo 5, apartado 1, letras c) y e), del RGPD exige que los datos personales sean adecuados, pertinentes, no excesivos y que no se conserven más tiempo del necesario. El Artículo 10 tira en sentido contrario: una mayor representatividad suele implicar más datos a lo largo de períodos de tiempo más prolongados. La tensión es real. Los proveedores deben demostrar que consideraron la minimización — que el conjunto de datos no era mayor de lo necesario para la finalidad de entrenamiento declarada — y que los períodos de conservación de los datos de entrenamiento se ajustan a una política documentada. Los calendarios de destrucción de los conjuntos de entrenamiento deben especificarse en el registro de origen del Artículo 10.

Derechos de los interesados. El RGPD otorga derechos de acceso, supresión y oposición. Un interesado que ejerce un derecho de supresión después de que sus datos se hayan utilizado para entrenar un modelo plantea una cuestión de cumplimiento que el registro del Artículo 10 debe poder abordar: ¿se eliminaron los datos del conjunto de entrenamiento antes del entrenamiento y, si no, pueden suprimirse de un modelo desplegado? La respuesta suele ser que no. Documente esta limitación y las medidas compensatorias — normalmente, anonimización, privacidad diferencial o límites de entrenamiento basados en épocas — antes de que comience el entrenamiento.

Ninguna de estas interacciones significa que el Artículo 10 y el RGPD sean redundantes entre sí. Son marcos paralelos con finalidades distintas, organismos de ejecución distintos (las autoridades nacionales de vigilancia del mercado para la Ley de IA; las autoridades de protección de datos para el RGPD) y vías de reparación distintas. Pero un expediente técnico que guarde silencio sobre la interacción con el RGPD no satisfará a un regulador sofisticado y, para los sistemas de IA que tratan datos personales, ambos flujos de trabajo de cumplimiento deben codiseñarse desde el principio.

---

Brechas de cumplimiento habituales que corregir antes de 2027

La mayoría de los fallos de gobernanza de datos con arreglo al Artículo 10 no son fallos de intención. Son fallos de documentación. Las decisiones sobre datos se tomaron — simplemente no se registraron de un modo que resista el escrutinio regulatorio.

Brecha: ausencia de declaraciones de supuestos por escrito. Los equipos de ingeniería toman decisiones sobre medidas indirectas de forma implícita. El modelo de contratación que trata «años en el puesto» como señal de competencia ha hecho un supuesto sobre lo que mide esa variable; simplemente no lo dejó por escrito. Los reguladores esperan encontrar declaraciones explícitas por escrito. Si están ausentes, la inferencia es que los supuestos no se examinaron.

Brecha: evaluación de sesgos realizada únicamente tras el entrenamiento. El Artículo 10 exige el examen de los propios conjuntos de datos, no meramente de los resultados del modelo. Una evaluación de equidad realizada sobre las predicciones del modelo a posteriori no sustituye a un examen de sesgos a nivel de conjunto de datos. Ambos son necesarios; solo el examen a nivel de conjunto de datos satisface directamente el Artículo 10.

Brecha: ausencia de control de versiones de los conjuntos de datos de entrenamiento. Cuando se investiga un sistema tras un incidente, la autoridad investigadora preguntará qué versión del conjunto de datos se utilizó para entrenar el modelo desplegado. Si la respuesta es «no lo sabemos» o «no podemos reconstruirlo», la investigación empieza mal y empeora. El versionado de los conjuntos de datos — etiquetar cada ejecución de entrenamiento con la versión exacta del conjunto de datos utilizado — es un control de ingeniería básico que la mayoría de los programas de cumplimiento subestiman.

Brecha: evaluación de idoneidad no actualizada tras cambios de alcance. Un modelo entrenado para su uso en Alemania y desplegado posteriormente en Rumanía tiene una evaluación de idoneidad redactada para el contexto alemán. La expansión geográfica no es un cambio neutro. Se requiere una nueva evaluación de idoneidad antes del despliegue ampliado, y el registro del Artículo 10 debe reflejarlo. Los proveedores tratan a menudo la expansión del despliegue como una decisión comercial cuando también es una decisión de cumplimiento.

Brecha: documentación del RGPD y del Artículo 10 mantenida por separado y de forma incoherente. Un delegado de protección de datos que documenta un conjunto de datos de entrenamiento de una manera y un equipo de ingeniería que documenta el mismo conjunto de datos de forma distinta en el expediente del Anexo IV crean una discrepancia que se detectará. Armonice los registros desde el principio.

---

Cómo se conecta el Artículo 10 con el resto del marco de alto riesgo

El Artículo 10 no funciona de forma aislada. Sus resultados alimentan directamente otros tres requisitos:

Artículo 9 (sistema de gestión de riesgos): Las deficiencias en la calidad de los datos son entradas de riesgo. El sistema de gestión de riesgos debe identificar los riesgos previsibles, y unos datos de entrenamiento deficientes o sesgados son una fuente previsible de daño. El registro de gestión de riesgos debe remitir a las conclusiones de la evaluación de sesgos del Artículo 10.

Artículo 11 (documentación técnica, Anexo IV): El Anexo IV, sección 2, exige que el expediente técnico contenga una descripción de las metodologías de entrenamiento, las técnicas, los conjuntos de datos utilizados y las medidas de gobernanza de datos. El paquete de documentación del Artículo 10 alimenta directamente esta sección del expediente del Anexo IV. Si la documentación técnica está incompleta, la evaluación de la conformidad con arreglo al Artículo 43 fracasará.

Artículo 15 (exactitud, robustez, ciberseguridad): La calidad de los datos es el determinante previo de la exactitud del modelo y de la coherencia del rendimiento entre subgrupos. Una representatividad deficiente o errores sistemáticos de etiquetado se manifestarán como fallos de exactitud en subpoblaciones — un riesgo que el Artículo 15 aborda de forma independiente.

Un programa de cumplimiento que trate los Artículos 9, 10, 11 y 15 como tareas separadas en lugar de como un sistema integrado generará documentación internamente incoherente. Los reguladores leen todo el expediente.

---

Ejemplo práctico: revisión del conjunto de datos de un modelo de contratación

Considere una empresa de tecnología de RR. HH. de 60 personas que desarrolla un modelo de cribado de currículos para su uso por empleadores de tamaño medio en toda la UE. El modelo se entrena con registros de contratación históricos: solicitudes, decisiones de cribado y resultados de empleo posteriores a lo largo de cinco años.

El sistema entra en el Anexo III, sección 4 (empleo y gestión de los trabajadores), que incluye la IA utilizada para la contratación y el cribado de personas físicas. Con arreglo al Artículo 6, si influye en las decisiones de contratación de personas, es de alto riesgo. Las obligaciones del Artículo 10 se aplican desde el desarrollo.

Paso 1 — Decisiones de diseño. La empresa decide utilizar como características la categoría de la oferta de empleo, los años de experiencia pertinente, el máximo nivel de cualificación y las palabras clave de competencias. Decide explícitamente no utilizar el nombre del candidato, la institución de graduación ni el código postal de residencia — y registra por qué (el nombre y el código postal portan medidas indirectas de la etnia y el origen socioeconómico; la institución de graduación es una mala medida indirecta de la competencia en este contexto). Esa decisión y su justificación quedan documentadas.

Paso 2 — Origen. Los datos de entrenamiento proceden de cinco clientes empleadores que proporcionaron registros históricos anonimizados con arreglo a acuerdos de tratamiento de datos. Los acuerdos especifican que los datos pueden utilizarse para el desarrollo del modelo. Se documenta la base jurídica del tratamiento (interés legítimo, con un test de ponderación).

Paso 3 — Preparación. Las anotaciones fueron aplicadas por tres revisores internos utilizando una rúbrica definida. La concordancia entre anotadores (medida mediante el kappa de Cohen) fue de 0,78, lo que la empresa documenta como adecuado. Se eliminaron las solicitudes duplicadas, los registros con campos obligatorios faltantes y los registros anteriores a 2019 (la empresa considera no representativos los datos anteriores a la reestructuración posterior a la COVID). Todo ello queda registrado.

Paso 4 — Supuestos. La empresa documenta explícitamente que las etiquetas de entrenamiento («seleccionado para entrevista» / «no seleccionado») reflejan decisiones de contratación humanas pasadas, no la realidad objetiva sobre la calidad del candidato. Señala que esto introduce el riesgo de codificar el sesgo humano histórico y lo marca como el principal riesgo de sesgo que requiere examen.

Paso 5 — Evaluación de idoneidad. La empresa revisa la composición demográfica. De 40 000 registros de entrenamiento, el 31 % corresponde a mujeres y el 69 % a hombres. Se observa que esto refleja la distribución por sexo de los solicitantes en los datos históricos de los sectores cubiertos, pero la empresa lo anota como una característica de los datos que debe tenerse en cuenta al interpretar las conclusiones sobre sesgos.

Paso 6 — Examen de sesgos. La empresa realiza un análisis de impacto dispar por sexo y edad. Constata que las candidatas con niveles de experiencia equivalentes fueron seleccionadas a una tasa de 0,84 veces la de los candidatos varones. También constata que los candidatos mayores de 50 años fueron seleccionados a una tasa de 0,71 veces la de los candidatos de entre 30 y 40 años con experiencia equivalente. Ambas conclusiones se documentan. La empresa elimina las características basadas en la antigüedad que se correlacionaban con la edad y reponderar el conjunto de entrenamiento para igualar la representación por sexo. Tras la mitigación, la ratio por sexo mejora a 0,97 veces; la ratio por edad mejora a 0,89 veces. La disparidad de edad residual se investiga más a fondo y se atribuye a interacciones entre experiencia y campo en categorías de empleo con grupos de solicitantes sesgados por edad; la empresa documenta esta conclusión y la señala a los responsables del despliegue como una limitación conocida que requiere supervisión de revisión humana.

Paso 7 — Artículo 10, apartado 5. La empresa no dispone de datos de origen étnico en sus registros de entrenamiento y, por tanto, no puede realizar un análisis de impacto dispar por origen étnico. Esta laguna se documenta explícitamente, con una nota de que se aconseja a los responsables del despliegue que realicen su propio seguimiento demográfico en producción.

El resultado de este proceso — siete artefactos documentados — pasa a ser la sección 2 del expediente técnico del Anexo IV y alimenta el registro de gestión de riesgos del Artículo 9. La evaluación de la conformidad con arreglo al Artículo 43 puede proceder sobre esta base.

---

El límite entre proveedor y responsable del despliegue con arreglo al Artículo 10

Las obligaciones del Artículo 10 recaen sobre los proveedores — organizaciones que desarrollan sistemas de IA de alto riesgo y los introducen en el mercado o los ponen en servicio con su propio nombre (Artículo 16). La empresa de tecnología de RR. HH. del ejemplo anterior es un proveedor; sus clientes empleadores son responsables del despliegue.

Los responsables del despliegue no están exentos de obligaciones relacionadas con los datos, pero sus obligaciones emanan de otros artículos. Los responsables del despliegue deben seguir las instrucciones del proveedor (Artículo 26), garantizar la supervisión humana (implementación del Artículo 14) y supervisar el funcionamiento — pero no están obligados a volver a realizar la gobernanza del conjunto de datos del proveedor con arreglo al Artículo 10. Esa carga recae sobre el proveedor.

Donde el límite importa es en el cambio de rol con arreglo al Artículo 25. Un responsable del despliegue que modifica sustancialmente un sistema de alto riesgo, o que entrena un modelo base con sus propios datos para sus propios fines, puede pasar a ser un proveedor y heredar las obligaciones del Artículo 10 en consecuencia. Lo mismo se aplica si un responsable del despliegue cambia la finalidad prevista de un sistema.

Para una empresa que compra una herramienta de contratación de terceros: verifique que el proveedor ha completado la documentación del Artículo 10 y puede facilitar un extracto de ella. Ese extracto alimenta su propia diligencia debida del Artículo 26 y su EIDF con arreglo al Artículo 27 si su organización es un organismo público o utiliza el sistema de un modo que active una evaluación de los derechos fundamentales.

---

Cómo ayuda Confir

El cumplimiento del Artículo 10 genera documentación que, con el tiempo, debe acabar dentro del expediente técnico del Anexo IV. El área de cumplimiento AITR de Confir (Datos y Robustez Técnica de la IA, que abarca los Artículos 10, 11 y 15) estructura la evaluación de la gobernanza de datos como una serie de controles documentados: registros de origen y preparación de los conjuntos de datos, conclusiones del examen de sesgos, declaraciones de supuestos y evaluaciones de idoneidad. Cada control se asigna a un subapartado concreto del Artículo 10 para que el registro resultante sea auditable por referencia.

El paquete de documentación del Anexo IV que genera Confir incluye una sección de gobernanza de datos preformateada. Los proveedores la rellenan; el resultado es un registro listo para imprimir en lugar de un ejercicio de redacción a partir de una página en blanco. Para los responsables del despliegue, la evaluación AITR incluye una lista de comprobación de verificación de proveedores que cubre qué pruebas del Artículo 10 solicitar al proveedor.

El cumplimiento del Artículo 10 es una pieza de la pila de alto riesgo. El panorama completo — gestión de riesgos del Artículo 9, documentación técnica del Artículo 11, supervisión humana del Artículo 14, exactitud del Artículo 15 y evaluación de la conformidad del Artículo 43 — discurre por la misma evaluación estructurada en Confir.

---

Pasos prácticos para el plazo del 2 de diciembre de 2027

El acuerdo del Ómnibus Digital de mayo de 2026 desplazó el plazo de alto riesgo del Anexo III de agosto de 2026 al 2 de diciembre de 2027 para los sistemas autónomos. Ese desplazamiento es un respiro para la implementación, no una señal para aplazar. La documentación del Artículo 10 es previa a todo lo demás: no se puede elaborar un expediente técnico completo del Anexo IV sin ella, y no se puede completar una evaluación de la conformidad con arreglo al Artículo 43 sin un expediente técnico completo.

La secuencia realista:

1. Clasifique primero. Confirme si su sistema entra en el Anexo III mediante el análisis del Artículo 6, incluido el filtro del Artículo 6, apartado 3 (tareas procedimentales acotadas, ausencia de elaboración de perfiles de personas físicas, etc.). Si no entra, las obligaciones del Artículo 10 sobre conjuntos de datos no se aplican en su forma plena.

2. Identifique el rol. ¿Proveedor, responsable del despliegue o responsable del despliegue con cambio de rol en virtud del Artículo 25? El titular de la obligación cambia en consecuencia.

3. Audite los conjuntos de datos existentes. Para los sistemas ya en desarrollo o desplegados, recorra hacia atrás los seis requisitos del Artículo 10 y documente qué existe y qué falta.

4. Aborde primero la brecha del examen de sesgos. Es el requisito que más recursos consume y el más probable que exija rehacer el conjunto de datos o el modelo.

5. Construya la sección de datos del Anexo IV en paralelo con el resto de la documentación técnica. No las trate como fases secuenciales.

Las empresas que no hayan empezado deberían empezar ya. La documentación no es breve, y la evaluación de sesgos requiere acceso a los datos de entrenamiento originales — que pueden ser más difíciles de recuperar cuanto mayor sea el retraso.

---

Guías relacionadas

• plataforma de cumplimiento de gobernanza de la IA
• documentación de inventario de sistemas de IA
• soluciones de software de gobernanza de la IA
• soluciones de software de cumplimiento de la Ley de IA de la UE