Análisis jurídico completo para empresas y administraciones públicas. La guía oficial de la AESIA más el criterio de iusia para el asesoramiento práctico.
El artículo 10 del AI Act establece que los datos usados para entrenar, validar y probar los sistemas de alto riesgo deben cumplir criterios de calidad que el Reglamento define con precisión. Esta disposición convierte la calidad de los datos en una obligación jurídica con consecuencias sancionadoras, no en una simple buena práctica técnica. La Guía 7, con 67 páginas, es la más extensa del paquete AESIA, lo que refleja la complejidad y la importancia de este requisito.
El punto de partida es reconocer que la calidad de los datos de entrenamiento determina en gran medida la calidad, la equidad y la fiabilidad del sistema de IA resultante. Un sistema entrenado con datos sesgados producirá outputs sesgados. Un sistema entrenado con datos no representativos de la población a la que se va a aplicar producirá outputs discriminatorios para los grupos infrarepresentados en los datos. El art. 10 del AI Act obliga a los proveedores a gestionar estos riesgos desde el origen — los datos — en lugar de intentar corregirlos solo a nivel del modelo.
La guía distingue tres conjuntos de datos que el art. 10 regula con criterios similares pero con funciones distintas en el ciclo de vida del sistema. Los datos de entrenamiento son los usados para ajustar los parámetros del modelo. Los datos de validación son los usados durante el entrenamiento para evaluar el rendimiento del modelo en datos no vistos y ajustar hiperparámetros. Los datos de prueba son los usados una vez completado el entrenamiento para evaluar el rendimiento final del sistema antes de su comercialización. El art. 10 se aplica a los tres conjuntos.
El artículo 10.3 establece que los datos de entrenamiento, validación y prueba deben presentar, en la medida de lo posible, las propiedades apropiadas de calidad. El Reglamento luego enumera cinco propiedades que los datos deben satisfacer.
La primera propiedad es la pertinencia: los datos deben ser relevantes para la finalidad prevista del sistema. Un sistema de scoring crediticio debe entrenarse con datos relacionados con el comportamiento crediticio de los solicitantes, no con datos demográficos o de otra naturaleza que puedan introducir sesgos o ser irrelevantes para la predicción. La guía advierte que la pertinencia es un criterio tanto técnico como jurídico — datos que son técnicamente útiles para el modelo pueden ser jurídicamente impermisibles si introducen sesgos discriminatorios.
La segunda propiedad es la representatividad: los datos deben representar de forma suficiente la diversidad de la población o los contextos de aplicación del sistema. Si el sistema va a aplicarse a toda la población española, los datos de entrenamiento deben reflejar la diversidad demográfica de esa población. Si solo se incluyen datos de ciertos grupos (por ejemplo, clientes de un banco con perfil de mayor renta), el sistema puede funcionar bien para ese grupo pero producir resultados sesgados para otros.
La tercera propiedad es que los datos deben estar libres de errores en la medida de lo posible. Los datos erróneos — etiquetas incorrectas, valores atípicos debidos a errores de medición, datos duplicados — degradan el rendimiento del sistema. El art. 10 exige que el proveedor establezca procesos para identificar y corregir los errores en los datos antes de usarlos para el entrenamiento. La guía detalla los procedimientos de control de calidad de datos que deben incluirse en el sistema de gestión de calidad del art. 17.
La cuarta propiedad es la completitud: los datos deben ser suficientes en términos de cantidad y diversidad para que el modelo generalice correctamente. Los sesgos de selección — la ausencia sistemática de ciertos tipos de datos — son tan perjudiciales como los errores explícitos. Un modelo entrenado principalmente con datos de ciudadanos de género masculino puede generalizar incorrectamente para ciudadanas de género femenino, aunque los datos de entrenamiento no contengan errores explícitos.
La quinta propiedad es que los datos deben tener las propiedades estadísticas apropiadas. Esto incluye que la distribución estadística de los datos de entrenamiento se corresponda con la distribución de los datos que el sistema encontrará en producción, y que las relaciones entre las variables en los datos de entrenamiento reflejen las relaciones causales relevantes y no solo las correlaciones espurias.
Además de los criterios de calidad del art. 10.3, el artículo establece que los proveedores deben implementar prácticas de gobernanza de datos que cubran las decisiones sobre diseño, recopilación de datos, preparación de datos y procesado de datos. La gobernanza de datos no es solo la calidad técnica de los datos — es la estructura organizativa y documental que garantiza que esa calidad se mantiene a lo largo del tiempo y que las decisiones sobre los datos son rastreables y justificables.
La guía describe los elementos mínimos de un sistema de gobernanza de datos conforme al art. 10. El primero es el catálogo de datos: un inventario documentado de todos los conjuntos de datos usados para el entrenamiento, validación y prueba del sistema, con información sobre su origen, las fechas de recopilación, las transformaciones aplicadas, y su papel en el proceso de desarrollo del modelo.
El segundo elemento es el linaje de datos: la trazabilidad de cada dato desde su origen hasta su uso en el modelo. El linaje permite reconstruir exactamente qué datos se usaron para entrenar qué versión del modelo, lo que es esencial cuando se detecta un problema en producción y es necesario determinar si tiene su origen en los datos de entrenamiento.
El tercer elemento es el control de acceso a los datos: las políticas que determinan quién puede acceder a los datos de entrenamiento, en qué circunstancias y con qué garantías. Cuando los datos contienen información personal, el control de acceso es también un requisito del RGPD. El art. 10 del AI Act añade la necesidad de que el acceso a los datos de entrenamiento sea suficientemente restringido para garantizar su integridad.
El cuarto elemento es el proceso de gestión del ciclo de vida de los datos: las reglas que determinan cuándo se actualizan los datos de entrenamiento, cuándo se eliminan datos obsoletos o de baja calidad, y cómo se valida que los datos actualizados cumplen los criterios de calidad antes de ser incorporados al proceso de entrenamiento.
La detección y mitigación de sesgos es el aspecto del art. 10 que más atención ha recibido por parte de las autoridades supervisoras europeas. Un sistema sesgado — uno que produce outputs sistemáticamente más desfavorables para un grupo protegido (por razón de género, raza, edad, discapacidad, u otras características) que para el resto de la población — viola simultáneamente el art. 10 del AI Act y la legislación antidiscriminatoria vigente.
La guía distingue tres tipos de sesgo en los datos de IA. El sesgo histórico surge cuando los datos de entrenamiento reflejan discriminaciones o desigualdades históricas. Un sistema de scoring crediticio entrenado con datos históricos puede perpetuar la mayor tasa de denegación de crédito que los grupos discriminados han recibido históricamente, aunque esa denegación tuviera causas exógenas al comportamiento crediticio individual. El sesgo de representación surge cuando la distribución de los datos de entrenamiento no refleja la distribución de la población real. El sesgo de medición surge cuando las variables proxy usadas en el modelo están correlacionadas con características protegidas de forma que el modelo efectivamente discrimina aunque no use explícitamente esas características.
El nuevo artículo 4 bis del AI Act, introducido por el Ómnibus Digital en sustitución del antiguo art. 10.5, permite excepcionalmente el tratamiento de categorías especiales de datos del art. 9 RGPD (datos sobre raza, origen étnico, opiniones políticas, salud, entre otros) cuando sea estrictamente necesario para detectar y corregir sesgos en el sistema de IA, con garantías estrictas que incluyen la minimización de datos, medidas de seguridad técnicas y organizativas, y la eliminación de los datos una vez alcanzado el objetivo de detección de sesgos.
Cuando los datos de entrenamiento contienen datos personales — lo que ocurre en la mayor parte de los sistemas de alto riesgo del Anexo III — el RGPD se aplica simultáneamente al art. 10 del AI Act. Las organizaciones deben identificar la base de legitimación del art. 6 RGPD para el tratamiento de los datos personales con la finalidad de entrenamiento de IA, y cumplir con todos los principios del art. 5 RGPD (licitud, lealtad y transparencia, limitación de la finalidad, minimización de datos, exactitud, limitación del plazo de conservación, integridad y confidencialidad).
La tensión más frecuente en la práctica es entre el principio de minimización de datos del RGPD y el requisito de representatividad del art. 10 AI Act. Minimizar los datos implica usar solo los estrictamente necesarios para la finalidad. Pero garantizar la representatividad puede requerir datos de grupos que, si se excluyeran, reducirían la cantidad total de datos disponibles. La guía proporciona criterios para navegar esta tensión: la minimización no exige usar menos datos de los necesarios para que el modelo sea representativo y equitativo — exige no usar datos que no sean necesarios para ese objetivo.
La documentación sobre los datos de entrenamiento, validación y prueba es parte obligatoria de la documentación técnica del Anexo IV del AI Act. El Anexo IV.2.d especifica que la documentación debe describir los conjuntos de datos utilizados, incluyendo su procedencia o fuente de datos, alcance y características principales, forma en que se han recopilado y procesado los datos, la forma en que se obtuvo el consentimiento cuando proceda, los procedimientos de selección de datos, las limitaciones de los datos de entrenamiento, la metodología de comprobación de calidad y todo lo relativo a la detección de sesgos.
Esta documentación tiene la función de un "data sheet" — una ficha técnica de los datos que permite a cualquier auditor o autoridad supervisora entender de dónde vienen los datos, cómo se han procesado, y cuáles son sus limitaciones conocidas. La transparencia sobre las limitaciones de los datos es tan importante como la demostración de su calidad: un proveedor que reconoce y documenta las limitaciones de sus datos de entrenamiento está en mejor posición que uno que las oculta, tanto desde la perspectiva regulatoria como de la gestión de riesgos.
El artículo 27 del AI Act introduce un instrumento específico para los desplegadores que sean organismos del sector público: la Evaluación Fundamental de Derechos e Impacto (Fundamental Rights Impact Assessment, FRIA). Cuando un organismo público — una administración, un tribunal, una agencia reguladora — despliega un sistema de IA de alto riesgo, debe realizar una FRIA que evalúe el impacto del sistema en los derechos fundamentales de las personas afectadas.
La FRIA es un instrumento distinto de la EIPD del RGPD y de la gestión de riesgos del art. 9. Comparte con la EIPD la lógica de evaluación de impacto previa al despliegue, pero su alcance es más amplio: cubre todos los derechos fundamentales de la Carta de los Derechos Fundamentales de la UE, no solo los relacionados con la protección de datos. Y comparte con la gestión de riesgos del art. 9 el análisis de los riesgos para los derechos fundamentales, pero tiene un enfoque específico en el contexto del sector público y en las garantías democráticas de rendición de cuentas.
La guía de la AESIA aclara que la FRIA del art. 27 solo es obligatoria para los desplegadores del sector público. Los desplegadores privados pueden realizarla voluntariamente, y la guía recomienda hacerlo cuando el sistema afecta a grupos vulnerables o cuando el nivel de riesgo para los derechos fundamentales es significativo. En la práctica, muchos inversores institucionales y grandes corporaciones están incorporando la FRIA como elemento estándar de su proceso de due diligence de AI ethics antes de desplegar sistemas de alto riesgo.
Las Administraciones Públicas que desarrollen o encarguen sistemas de IA de alto riesgo tienen consideraciones específicas sobre los datos de entrenamiento que la Guía 7 aborda en un capítulo dedicado. Las AAPP disponen de enormes conjuntos de datos públicos que pueden ser especialmente valiosos para el entrenamiento de sistemas de IA — datos de salud pública, datos del sistema judicial, datos fiscales, datos de prestaciones sociales — pero su uso para el entrenamiento de sistemas de IA está sujeto a restricciones específicas.
La limitación de finalidad del art. 5.1.b del RGPD plantea el problema de si los datos recogidos por las AAPP para una finalidad pública específica pueden reutilizarse para el entrenamiento de sistemas de IA con una finalidad diferente. La respuesta depende de si la nueva finalidad es compatible con la original en el sentido del art. 6.4 RGPD, lo que requiere un análisis caso por caso que debe incluir la naturaleza de los datos, el posible impacto en las personas interesadas, la existencia de garantías adecuadas y el contexto en que se recogieron los datos originalmente.
El Reglamento europeo de espacios de datos (Reglamento 2022/868 sobre gobernanza de datos) y el Reglamento de Datos (Reglamento 2023/2854) establecen marcos para la reutilización de datos del sector público que pueden facilitar el uso de datos públicos para el entrenamiento de sistemas de IA, dentro de los límites que el RGPD establece. La Guía 7 recomienda que las AAPP que quieran usar sus datos para el entrenamiento de sistemas de IA realicen un análisis jurídico completo que cubra simultáneamente el AI Act, el RGPD y los reglamentos de datos aplicables antes de iniciar el proceso de entrenamiento.
Para las grandes corporaciones que desarrollan múltiples sistemas de IA de alto riesgo, la gobernanza de datos del art. 10 no puede gestionarse de forma ad hoc sistema por sistema — requiere una infraestructura corporativa de gobernanza de datos que cubra todos los sistemas de IA de la organización de forma coherente. Esta infraestructura incluye una política corporativa de datos de IA, un registro centralizado de los conjuntos de datos usados en todos los sistemas de IA, procesos estandarizados de evaluación de calidad y representatividad, y roles y responsabilidades claramente definidos para la gestión de datos de IA en toda la organización.
La figura del Data Steward — el responsable de la calidad y el cumplimiento de un conjunto específico de datos — es especialmente relevante en el contexto del art. 10 del AI Act. El Data Steward es quien verifica que los datos de entrenamiento cumplen los cinco criterios de calidad del art. 10.3, quien mantiene el linaje de los datos, y quien aprueba los cambios en los conjuntos de datos de entrenamiento antes de que se incorporen al proceso de re-entrenamiento del modelo. Su papel es complementario al del DPO (que supervisa el cumplimiento del RGPD) y al del responsable del SGC (que gestiona el sistema de calidad del art. 17).
El artículo 27 del AI Act introduce un instrumento específico para los desplegadores que sean organismos del sector público: la Evaluación Fundamental de Derechos e Impacto (Fundamental Rights Impact Assessment, FRIA). Cuando un organismo público — una administración, un tribunal, una agencia reguladora — despliega un sistema de IA de alto riesgo, debe realizar una FRIA que evalúe el impacto del sistema en los derechos fundamentales de las personas afectadas.
La FRIA es un instrumento distinto de la EIPD del RGPD y de la gestión de riesgos del art. 9. Comparte con la EIPD la lógica de evaluación de impacto previa al despliegue, pero su alcance es más amplio: cubre todos los derechos fundamentales de la Carta de los Derechos Fundamentales de la UE, no solo los relacionados con la protección de datos. Y comparte con la gestión de riesgos del art. 9 el análisis de los riesgos para los derechos fundamentales, pero tiene un enfoque específico en el contexto del sector público y en las garantías democráticas de rendición de cuentas.
La guía de la AESIA aclara que la FRIA del art. 27 solo es obligatoria para los desplegadores del sector público. Los desplegadores privados pueden realizarla voluntariamente, y la guía recomienda hacerlo cuando el sistema afecta a grupos vulnerables o cuando el nivel de riesgo para los derechos fundamentales es significativo. En la práctica, muchos inversores institucionales y grandes corporaciones están incorporando la FRIA como elemento estándar de su proceso de due diligence de AI ethics antes de desplegar sistemas de alto riesgo.
Las Administraciones Públicas que desarrollen o encarguen sistemas de IA de alto riesgo tienen consideraciones específicas sobre los datos de entrenamiento que la Guía 7 aborda en un capítulo dedicado. Las AAPP disponen de enormes conjuntos de datos públicos que pueden ser especialmente valiosos para el entrenamiento de sistemas de IA — datos de salud pública, datos del sistema judicial, datos fiscales, datos de prestaciones sociales — pero su uso para el entrenamiento de sistemas de IA está sujeto a restricciones específicas.
La limitación de finalidad del art. 5.1.b del RGPD plantea el problema de si los datos recogidos por las AAPP para una finalidad pública específica pueden reutilizarse para el entrenamiento de sistemas de IA con una finalidad diferente. La respuesta depende de si la nueva finalidad es compatible con la original en el sentido del art. 6.4 RGPD, lo que requiere un análisis caso por caso que debe incluir la naturaleza de los datos, el posible impacto en las personas interesadas, la existencia de garantías adecuadas y el contexto en que se recogieron los datos originalmente.
El Reglamento europeo de espacios de datos (Reglamento 2022/868 sobre gobernanza de datos) y el Reglamento de Datos (Reglamento 2023/2854) establecen marcos para la reutilización de datos del sector público que pueden facilitar el uso de datos públicos para el entrenamiento de sistemas de IA, dentro de los límites que el RGPD establece. La Guía 7 recomienda que las AAPP que quieran usar sus datos para el entrenamiento de sistemas de IA realicen un análisis jurídico completo que cubra simultáneamente el AI Act, el RGPD y los reglamentos de datos aplicables antes de iniciar el proceso de entrenamiento.
Para las grandes corporaciones que desarrollan múltiples sistemas de IA de alto riesgo, la gobernanza de datos del art. 10 no puede gestionarse de forma ad hoc sistema por sistema — requiere una infraestructura corporativa de gobernanza de datos que cubra todos los sistemas de IA de la organización de forma coherente. Esta infraestructura incluye una política corporativa de datos de IA, un registro centralizado de los conjuntos de datos usados en todos los sistemas de IA, procesos estandarizados de evaluación de calidad y representatividad, y roles y responsabilidades claramente definidos para la gestión de datos de IA en toda la organización.
La figura del Data Steward — el responsable de la calidad y el cumplimiento de un conjunto específico de datos — es especialmente relevante en el contexto del art. 10 del AI Act. El Data Steward es quien verifica que los datos de entrenamiento cumplen los cinco criterios de calidad del art. 10.3, quien mantiene el linaje de los datos, y quien aprueba los cambios en los conjuntos de datos de entrenamiento antes de que se incorporen al proceso de re-entrenamiento del modelo. Su papel es complementario al del DPO (que supervisa el cumplimiento del RGPD) y al del responsable del SGC (que gestiona el sistema de calidad del art. 17).
Más recursos: calendario del AI Act tras el Ómnibus Digital · análisis del AI Act en 2026 · servicios para administraciones públicas (LexQuark).
Newsletter gratuita · Empresas y administraciones públicas · En español