Exactitud-RGPD y calidad de datos en la IA: la nota de la AEPD

La Agencia Española de Protección de Datos ha publicado una nota técnica que aborda un problema que la práctica regulatoria venía arrastrando sin resolver: la confusión entre dos nociones que suenan idénticas pero que no lo son, la calidad de los datos propia de la ingeniería de datos y la exactitud que exige el artículo 5.1.d) del Reglamento General de Protección de Datos. El documento, disponible para su descarga íntegra a continuación, formula esa distinción con una precisión que tiene consecuencias directas sobre cómo deben gobernarse los conjuntos de datos que alimentan el desarrollo y el despliegue de sistemas de inteligencia artificial¹.

📄 Descargar la nota técnica completa de la AEPD (PDF)

La genealogía de una confusión: calidad técnica frente a exactitud jurídica

Los estándares de la economía del dato —UNE 0079, ISO 25012, ISO 5259, ISO 8000— definen la calidad de los datos como el grado en que sus características satisfacen necesidades declaradas e implícitas en condiciones de uso específicas. La norma ISO 22989, referida en concreto a sistemas de IA, describe el proceso de verificación de calidad como el examen de completitud, sesgo y demás factores que condicionan la utilidad de un dato para un sistema de IA². Son definiciones técnicas, no jurídicas, y ahí radica el primer problema: comparten vocabulario con el RGPD sin compartir contenido normativo.

El RGPD, de hecho, no emplea el término "calidad de los datos" salvo en el artículo 47.2.d), referido a las normas corporativas vinculantes. Lo que sí establece son dos principios autónomos y complementarios en el artículo 5.1: la minimización, letra c), que limita el tratamiento a lo adecuado, pertinente y necesario respecto de los fines; y la exactitud, letra d), que exige que los datos sean exactos y, si fuera necesario, actualizados, con obligación de suprimir o rectificar sin dilación los que resulten inexactos con respecto a los fines para los que se tratan. Esa coletilla final —"con respecto a los fines"— es la clave de bóveda de todo el documento: la exactitud del RGPD nunca se predica en abstracto, sino siempre en relación con una finalidad concreta.

De ahí que la AEPD proponga distinguir terminológicamente "exactitud-RGPD" de "exactitud-ISO". La segunda es el grado en que un dato representa correctamente el valor verdadero de un atributo en un contexto de uso específico; podría ser una condición necesaria para alcanzar la primera, pero no lo es necesariamente, y desde luego no la agota. Para alcanzar la exactitud-RGPD pueden requerirse otras propiedades del estándar —precisión, granularidad, frecuencia de actualización— y también propiedades ajenas al estándar, como la ausencia de sesgo, que ningún catálogo ISO enumera pero que puede resultar decisiva para que un tratamiento sea idóneo.

Esta genealogía tiene una consecuencia inmediata que la nota técnica subraya sin rodeos: una interpretación expansiva de la exactitud-RGPD, que exigiera a los responsables alcanzar niveles máximos de veracidad, actualidad o precisión con independencia de la finalidad perseguida, terminaría contradiciendo el principio de minimización, porque habilitaría el acceso y tratamiento de datos más allá de lo estrictamente necesario. La AEPD advierte, además, del riesgo práctico de esa lectura extensiva para quienes desarrollan o evolucionan sistemas de IA: cargas desproporcionadas de gestión de datos, exigencia de derechos más allá de lo previsto en el RGPD, y en el peor de los casos, el descarte de conjuntos de datos que sí eran aptos para la finalidad prevista.

La crisis del concepto bajo el desarrollo de sistemas de IA

El desplazamiento hacia el aprendizaje automático somete esta distinción a una tensión que la normativa de protección de datos, pensada originalmente para registros individuales, no anticipaba con claridad: la diferencia entre la calidad de un dato tomado aisladamente y la calidad de un conjunto de datos. La nota técnica ilustra el punto con un ejemplo que merece reproducirse conceptualmente por su fuerza persuasiva: una tabla de ocho registros de recursos humanos —género, provincia, sueldo, experiencia— puede satisfacer el estándar ISO evaluado registro por registro y, sin embargo, estar sesgada de forma flagrante en su composición de género, con siete hombres y una mujer³. Si la finalidad del tratamiento es entrenar un modelo cuyas estimaciones afecten a personas de ambos sexos, ese conjunto de datos —pese a su limpieza formal— no es idóneo, y por tanto no es exacto-RGPD, aunque cada dato individual sea intachable.

Esta distinción entre calidad del registro y calidad del conjunto no es un matiz académico. Cambia el objeto sobre el que recae el juicio de conformidad. Cuando la finalidad de un tratamiento es el desarrollo de un sistema de IA mediante aprendizaje automático, el cumplimiento no depende tanto del dato de un usuario concreto cuanto de propiedades emergentes del conjunto: la ausencia de sesgos que comprometan la finalidad, las propiedades estadísticas adecuadas, la representatividad del contexto geográfico, conductual o funcional en el que operará el sistema, la frecuencia de recogida cuando resulte relevante —geolocalización, consumo energético, actividad en línea—, el poder predictivo de las variables seleccionadas y la relevancia de las muestras para el proceso de aprendizaje, esta última vinculada a las técnicas de active learning⁴.

Ninguna de estas características figura en el listado cerrado de ISO 25012 —exactitud, completitud, consistencia, credibilidad, actualidad, accesibilidad, conformidad, confidencialidad, eficiencia, precisión, trazabilidad, comprensibilidad, disponibilidad, portabilidad, recuperabilidad—. La AEPD es explícita al señalar que ese catálogo no es exhaustivo ni todas sus características resultan exigibles por igual en cada contexto; tratarlo como una lista de verificación aplicada en abstracto, sin conexión con la finalidad concreta, constituye lo que el documento denomina, con acierto descriptivo, "calidad de checkbox". El error simétrico —dar por agotadas en el estándar todas las características relevantes— es igualmente desaconsejado: para el desarrollo de sistemas de IA hace falta ampliar el catálogo con las variables señaladas, muchas de las cuales encuentran ya un anclaje normativo en el considerando 67 y el artículo 10, apartados 1 a 4, del Reglamento de IA.

Veracidad y actualidad como exigencias relativas, no absolutas

Uno de los puntos más productivos —y más susceptibles de generar fricción con lecturas tradicionales de la protección de datos— es la relación entre exactitud-RGPD y veracidad. La nota técnica sostiene que la actualidad de un dato personal es un requisito de exactitud-RGPD únicamente cuando resulta necesaria para la finalidad del tratamiento, y no como exigencia autónoma predicable de cualquier dato en cualquier circunstancia.

De ahí se sigue una tesis con recorrido práctico considerable: técnicas de anonimización orientadas a minimizar datos, de privacidad diferencial, de eliminación de sesgos o de generación de datos sintéticos pueden producir conjuntos de datos en los que algunos valores no reflejen directamente la realidad de un individuo concreto, sacrificando exactitud-ISO a cambio de otras propiedades. Ese sacrificio no equivale, sin más, a una infracción del principio de exactitud del RGPD, siempre que el conjunto resultante sea idóneo para la finalidad perseguida. El documento ofrece un ejemplo especialmente ilustrativo: ante campos vacíos en una tabla de sueldos, completar los valores faltantes con la media general o con la media por provincia introduce datos formalmente falsos —sacrifica exactitud-ISO— pero puede incrementar la completitud y la utilidad del conjunto para el entrenamiento del modelo⁵. De igual modo, la corrección de sesgos mediante normalización grupal —por ejemplo, ajustar la puntuación de historial crediticio para eliminar la penalización sistemática asociada a un código postal— introduce valores que no reflejan la realidad individual estricta, pero que mejoran la idoneidad del conjunto para una finalidad que exige neutralidad frente a variables espurias.

La AEPD matiza inmediatamente esta flexibilidad: la relevancia de la veracidad varía según el tipo de tratamiento. En tratamientos agregados o estadísticos caben mayores niveles de abstracción; en tratamientos que producen efectos sobre personas concretas —una decisión, un perfilado, una calificación—, la exigencia de veracidad y actualidad en el resultado debe ser más estricta, sin perjuicio de que en ningún caso puede generarse una representación distorsionada del interesado ni un efecto adverso sobre sus derechos e intereses. El uso de datos que no reflejan la realidad exige, en consecuencia, un juicio de proporcionalidad ligado al impacto sobre la toma de decisiones y a la generación de perfiles, que ha de quedar justificado y documentado por el responsable.

Los tres tipos de tratamiento y la cadena de exigibilidad

La nota técnica ordena los tratamientos de datos personales que incorporan IA según un criterio de entrada y salida que resulta especialmente útil para la práctica de cumplimiento. El primer tipo combina datos personales y no personales de entrada para producir un resultado que también es un dato personal —una decisión de concesión de beca, una evaluación de solvencia, un perfilado laboral—. Aquí la cadena de exigencia es completa: tanto los datos de entrada como el resultado de salida deben ser exactos-RGPD y mínimos-RGPD, y el conjunto total de datos de entrada, incluidos los no personales, debe alcanzar la calidad suficiente para que la finalidad se cumpla tal como está diseñado el tratamiento.

El segundo tipo utiliza datos personales para producir un resultado que no es un dato personal —el diseño de una política pública de distribución de recursos educativos, por ejemplo—. Aunque el resultado final escape a la calificación de dato personal, el tratamiento de los datos personales empleados debe seguir siendo leal y legítimo, y el resultado debe tener la calidad suficiente para que la finalidad se cumpla; los datos de entrada, a su vez, deben cumplir las mismas condiciones de exactitud y minimización del primer supuesto. El tercer tipo, más difícil de imaginar en la práctica pero relevante por su valor de cierre del sistema, es aquel en el que, sin datos personales de entrada, el tratamiento acaba afectando a una persona física concreta —un sorteo de plazas, la generación de un número de lotería que produce efectos individualizados—; en la medida en que el resultado sea un dato personal, se aplican idénticas exigencias que en los casos anteriores.

Un aspecto que la nota técnica trata con especial cuidado es la exigibilidad de calidad respecto de los datos no personales que participan en un tratamiento de datos personales. La AEPD lo ejemplifica con un caso de evaluación relativa del alumno: si la nota media del centro —un dato no personal— es incorrecta, el resultado de la evaluación del alumno concreto puede resultar inexacto-RGPD aun cuando su propia nota individual sea perfectamente exacta⁶. El error de calidad se traslada por contaminación desde el dato de contexto hacia el resultado final, lo que obliga a extender el juicio de calidad a todo insumo del tratamiento, sea o no personal, en la medida en que pueda incidir en la idoneidad del resultado o en los derechos y libertades de las personas afectadas.

El desarrollo de un sistema de IA como tratamiento autónomo

Uno de los aportes estructurales del documento consiste en diferenciar nítidamente el tratamiento de desarrollo de un sistema de IA respecto del tratamiento en que ese sistema, ya desplegado, se emplea para procesar datos personales de terceros. Son tratamientos distintos, con finalidades distintas y, en consecuencia, con exigencias de calidad de los datos distintas y evaluables de forma diferenciada. Utilizando las fases del ciclo de vida del estándar ISO 5338 —inicio, diseño y desarrollo, verificación y validación, despliegue, producción y monitorización, reevaluación, retirada—, la AEPD sitúa las primeras tres fases dentro del tratamiento de desarrollo y las restantes dentro del tratamiento de explotación, cuando este último implica datos personales.

La consecuencia práctica más relevante de esta autonomía conceptual es que los requisitos de calidad de los datos de entrada al desarrollo solo pueden fijarse una vez conocidas las condiciones de idoneidad de los tratamientos de explotación en los que se prevé desplegar el sistema. Es una secuencia inversa a la intuición ingenieril habitual, que tiende a fijar primero el conjunto de entrenamiento y después evaluar su aptitud: la AEPD invierte esa lógica y sitúa la finalidad de despliegue como punto de partida obligado para determinar la calidad exigible en origen. Este razonamiento tiene una derivación adicional de calado: los conjuntos de datos que no reúnan la calidad necesaria para el desarrollo de un sistema de IA concreto no son "necesarios" en el sentido del artículo 5.1.c) del RGPD, y por tanto el acceso a ellos únicamente puede justificarse en la medida estrictamente precisa para evaluar su calidad y determinar su eventual aptitud, no para explotarlos de forma general.

Sobre el rendimiento del sistema resultante, la nota enumera factores adicionales que trascienden la calidad del dato en sí: la metodología de desarrollo empleada, las decisiones de diseño, los contextos y finalidades previstas, factores de implementación en el despliegue como la cuantización del modelo, la evolución del contexto en el tiempo —lo que la literatura técnica denomina context-drift y data-drift— y, en el caso de modelos que evolucionan tras su despliegue, los sesgos generados por bucles de realimentación. Ninguno de estos factores es reducible a una propiedad estática del dataset original, lo que reafirma la tesis central del documento: la calidad de los datos no es un requisito fijado de una vez en la fase de diseño, sino un proceso de gestión continuo que exige monitorización, revisión y actualización a lo largo de todo el ciclo de vida, tanto del sistema de IA como del tratamiento de datos personales que lo envuelve.

El acceso a datos como operación regulada por sí misma

La nota técnica conecta esta arquitectura con el Reglamento de Gobernanza de Datos, cuyo artículo 2.13 define el acceso a datos como toda utilización conforme a requisitos técnicos, jurídicos u organizativos específicos, sin que ello implique necesariamente transmisión o descarga. Esta definición legitima un modelo de acceso —"llevar los algoritmos a los datos"— frente al modelo tradicional de centralización —"llevar los datos a los algoritmos"—. El primero, conocido en el desarrollo de sistemas de IA como aprendizaje federado, no solo protege los datos personales sino que garantiza la soberanía del dato en origen; la AEPD recuerda que en ciertos supuestos, como los usos secundarios dentro del Espacio Europeo de Datos de Salud a través de entornos de tratamiento seguro, este modelo de acceso resulta obligatorio y no meramente preferible.

Antes de iniciar cualquier proceso de acceso o recogida masiva de datos para desarrollo de IA, el responsable debe evaluar la legitimación de ese acceso conforme al test de necesidad del principio de minimización: si los conjuntos son adecuados, pertinentes y limitados a lo necesario respecto de los fines. Ese test exige, a su vez, una evaluación previa de la calidad de los datos en origen, sea de forma aislada o en conjunción con otros conjuntos disponibles —un ejercicio que, según la propia AEPD, resulta aplicable tanto al acceso a datos para IA como a la ejecución de cualquier otro tratamiento, sin especialidad alguna que lo distinga en este punto.

El doble riesgo de los requisitos de calidad mal calibrados

El documento cierra su análisis sustantivo con una advertencia de política regulatoria que merece leerse como una guía de proporcionalidad aplicable a cualquier ejercicio de auditoría o diseño normativo interno. Fijar requisitos de calidad insuficientes compromete la idoneidad del tratamiento de desarrollo, al impedir que el sistema resultante alcance las prestaciones previstas. Pero fijar requisitos excesivos no es una opción prudente por defecto: contradice el principio de minimización al forzar el acceso a un volumen de datos, o a una granularidad, precisión o frecuencia, superiores a los necesarios; encarece el acceso a los conjuntos de datos y la gestión de los procesos de gobierno del dato —la nota remite aquí a los veintidós procesos de gobernanza y gestión de calidad de la norma UNE 0080:2023—; y, en el peor de los escenarios, puede llevar a descartar iniciativas empresariales o de investigación por la asunción errónea de que no existe un conjunto de datos con calidad suficiente, cuando en realidad el obstáculo era un umbral de exigencia mal calibrado.

Esta doble advertencia sitúa a la AEPD en una posición doctrinal que merece subrayarse: la autoridad no defiende una interpretación maximalista de la protección de datos como estrategia de precaución regulatoria, sino un ejercicio de proporcionalidad estricta en el que tanto el defecto como el exceso de exigencia son igualmente disfuncionales. Es una posición coherente con el resto del razonamiento del documento, pero que exige de los responsables un ejercicio de motivación mucho más fino que la mera invocación abstracta del principio de cautela: cada nivel de calidad exigido debe justificarse por referencia a la finalidad concreta del tratamiento y al impacto sobre los derechos de las personas afectadas, ni un grado más, ni un grado menos.

Gobernanza, responsabilidad proactiva y el equipo multidisciplinar

La nota técnica insiste, como condición de cierre del sistema, en que la definición, evaluación y revisión de los requisitos de calidad de los datos exige un enfoque multidisciplinar que involucre, como mínimo, a especialistas en ciencia de datos y en protección de datos, guiados por criterios objetivos y evidencia verificable durante todo el ciclo de vida del tratamiento. El responsable del tratamiento, bajo el principio de responsabilidad proactiva del artículo 24 del RGPD, debe documentar la trazabilidad del conjunto de datos utilizado —origen, transformaciones aplicadas, criterios de selección y exclusión— y, cuando adquiera sistemas de IA de terceros, tener en cuenta los requisitos de calidad documentados por el proveedor junto con las salvaguardas necesarias para un despliegue adecuado en su propio diseño de tratamiento.

Esta exigencia de gobernanza conecta con una reflexión final que atraviesa todo el documento: no existen tratamientos perfectos, ni sistemas de IA perfectos. La AEPD lo formula sin ambages —el sistema perfecto es una ilusión, sea IA o no-IA— para trasladar el criterio de conformidad desde la búsqueda imposible de la perfección hacia la determinación de un grado de calidad mínimo aceptable, verificable mediante métricas objetivas y sostenido mediante mecanismos de seguimiento, control y gestión de incidencias. La ausencia de tales métricas de calidad del resultado de salida, advierte el documento, impide demostrar que el tratamiento cumple con eficacia e idoneidad los fines para los que fue diseñado, lo que convierte la métrica en un elemento no accesorio sino constitutivo del cumplimiento normativo.

El precedente normativo español: de la Directiva 95/46/CE a la LOPDGDD

El anexo de la nota técnica reconstruye la evolución del concepto de exactitud en el ordenamiento español y aporta una clave de lectura histórica que explica buena parte de la confusión doctrinal actual. La Directiva 95/46/CE vinculaba exactitud y minimización a la finalidad del tratamiento, en términos sustancialmente idénticos a los que hoy recoge el artículo 5.1 del RGPD. La Ley Orgánica 15/1999, sin embargo, al transponerla, desvinculó la exactitud de esa referencia finalista: definió el dato exacto como aquel que responde con veracidad a la situación actual del afectado, en términos absolutos, sin condicionarlo a la necesidad derivada de los fines del tratamiento. La AEPD advierte que de esa redacción podían extraerse dos lecturas problemáticas: que un dato podía considerarse exacto aunque afectase negativamente a la finalidad del tratamiento, y que un dato debía ser veraz respecto de la situación actual del afectado incluso cuando esa veracidad resultara innecesaria para dicha finalidad.

La Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales, al desarrollar el artículo 5.1.d) del RGPD en su artículo 4, no define expresamente qué debe entenderse por exactitud, aunque la remisión directa al RGPD debería conducir a vincularla de nuevo al cumplimiento de los fines. La AEPD atribuye a un sesgo de resistencia cognitiva —o sesgo de perseverancia, la dificultad para abandonar una idea pese a la evidencia en contrario— la persistencia, en la práctica aplicativa, del concepto absoluto heredado de la Ley Orgánica 15/1999. Esa persistencia, señala el documento, puede perjudicar tanto a los interesados —al exigir datos que exceden las necesidades del tratamiento, o al permitir el uso de datos inadecuados para la finalidad perseguida— como a los responsables y encargados, y en particular a quienes desarrollan sistemas de IA, al imponerles niveles de veracidad y actualidad innecesarios que terminan siendo contrarios a la propia calidad de los datos requerida para desarrollar sistemas adecuados.

Balance doctrinal

La nota técnica de la AEPD no introduce una norma nueva ni reinterpreta el RGPD en un sentido divergente de su tenor literal; su aportación consiste en hacer explícito, con un aparato conceptual depurado y ejemplos técnicamente rigurosos, algo que el artículo 5.1.d) siempre exigió mediante su cláusula final de finalidad, pero que la práctica —lastrada por el arrastre conceptual de la Ley Orgánica 15/1999 y por el préstamo terminológico acrítico de los estándares de calidad de datos— tendía a pasar por alto. La operación doctrinal central del documento es reconciliar exactitud y minimización bajo un mismo principio rector, la finalidad del tratamiento, y proyectar esa reconciliación sobre el terreno donde resulta más urgente: el desarrollo y despliegue de sistemas de inteligencia artificial basados en aprendizaje automático, donde la calidad relevante rara vez reside en el dato individual y casi siempre reside en las propiedades emergentes del conjunto.

Quedan, con todo, cuestiones abiertas que la propia nota deja para desarrollo posterior. La más evidente es la operatividad práctica del test de necesidad cuando la finalidad de un tratamiento de desarrollo de IA es, en sí misma, extraordinariamente amplia o experimental —proyectos de investigación básica, modelos de propósito general—, escenario en el que determinar ex ante las condiciones de idoneidad del despliegue, presupuesto metodológico central del documento, resulta considerablemente más difícil que en los tratamientos de finalidad acotada que ilustran sus ejemplos. La segunda es la articulación fina entre este marco y las obligaciones de gobernanza de datos de calidad previstas en el artículo 10 del Reglamento de IA para los sistemas de alto riesgo, que la nota menciona como fuente pero no desarrolla en detalle comparativo. Ambas cuestiones, sin embargo, no restan valor a la aportación central: un marco conceptual que permite a responsables, encargados y delegados de protección de datos distinguir, con precisión operativa, cuándo están ante una exigencia de exactitud jurídica y cuándo ante un estándar técnico de calidad que, por sí solo, no basta ni sobra para el cumplimiento normativo.

Notas

Agencia Española de Protección de Datos, Exactitud, idoneidad y calidad de los datos en tratamientos de datos personales con Inteligencia Artificial, nota técnica, 2026.
ISO/IEC 22989, Artificial intelligence concepts and terminology; ISO/IEC 25012, Data quality model.
Ejemplo desarrollado en el apartado II.E de la nota técnica de la AEPD, sobre calidad del dato individual frente a calidad del conjunto de datos.
Características enumeradas en el considerando 67 y el artículo 10, apartados 1 a 4, del Reglamento (UE) 2024/1689 (Reglamento de IA).
Apartado II.F de la nota técnica, sobre calidad de los datos frente a veracidad y actualidad.
Apartado III.C de la nota técnica, sobre exigibilidad de calidad en los datos no personales dentro de tratamientos de datos personales.

📄 Descargar la nota técnica completa de la AEPD (PDF)