Después de unos cuantos proyectos de IA en producción, uno acaba con una convicción incómoda: el modelo casi nunca es el problema. El problema es el dato. Datasets construidos con lo que había a mano, etiquetas puestas por tres personas con criterios distintos, históricos que describen un negocio que ya no existe y salidas que nadie vuelve a mirar una vez pasan a producción.
Hasta ahora eso era una conversación de ingeniería. Desde el 21 de julio de 2026 también es una conversación regulatoria: la AEPD publicó una nota técnica que analiza la calidad, exactitud y minimización de datos personales en tratamientos realizados con sistemas de IA. La propia Agencia lo presenta como uno de los primeros trabajos sistemáticos del mundo sobre esta materia, y para quien construye IA es probablemente el documento más accionable del trimestre.
Este artículo traduce sus seis criterios a decisiones concretas de arquitectura, ingeniería y contrato: qué documentar, cómo medir la representatividad de un dataset, qué monitorizar en producción y qué exigirle a un proveedor.
Qué dice el art. 5.1.d del RGPD y por qué casi todo el mundo lo interpreta mal
El principio de exactitud del RGPD obliga a que los datos personales sean exactos y, si es necesario, se mantengan actualizados, adoptando medidas razonables para suprimir o rectificar sin dilación los datos inexactos con respecto a los fines del tratamiento.
La lectura habitual —y errónea— es literal: "todo dato tiene que ser verdad y estar al día siempre". La tesis central de la AEPD apunta en otra dirección: el principio de exactitud no exige veracidad absoluta ni actualización permanente del dato, sino adecuación a la finalidad del tratamiento. Exigirlo en términos absolutos entraría además en conflicto directo con el principio de minimización y generaría cargas desproporcionadas.
Ese matiz cambia el trabajo diario. La pregunta correcta ante un dataset no es "¿este dato es cierto?", sino "¿este dato es suficientemente exacto para lo que voy a hacer con él?".
Ejemplo mental que uso en las reuniones: una edad aproximada por franja ("35-44") es un dato menos preciso que la fecha de nacimiento exacta, pero para un modelo de segmentación agregada es más correcto en términos de RGPD, porque cumple la finalidad con menos dato. Precisión y exactitud no son lo mismo.
De ahí se derivan dos consecuencias prácticas: acumular datos "por si acaso" con la excusa de la exactitud es un antipatrón, y renunciar a precisión innecesaria puede ser una decisión de cumplimiento correcta, no una chapuza técnica.
Los seis criterios de la AEPD, en una tabla
| # | Criterio | Qué implica para quien construye |
|---|---|---|
| 1 | El estándar de exactitud varía según el tipo de tratamiento | Los usos estadísticos o agregados admiten mayor abstracción; los que producen efectos directos sobre personas, no |
| 2 | La calidad se evalúa a nivel de conjunto de datos | Representatividad, ausencia de sesgo y pertinencia del dataset, no solo corrección dato a dato |
| 3 | Las salidas del sistema también están sujetas | Predicciones, inferencias y decisiones no deben generar representaciones incorrectas o desproporcionadas de las personas |
| 4 | Desarrollo y explotación tienen requisitos distintos | El despliegue con impacto individual exige garantías reforzadas frente a la fase de entrenamiento |
| 5 | Sintéticos, anonimización y corrección de sesgos son compatibles | Son vías legítimas cuando están justificadas por la finalidad, no atajos sospechosos |
| 6 | Exige gobernanza proactiva del dato | Requisitos de calidad documentados y objetivos, con monitorización continua durante todo el ciclo de vida |
A partir de aquí, uno por uno y aterrizado.
Criterio 1: el listón de exactitud depende de lo que hace el sistema
El primer criterio es el que evita que todo esto se convierta en burocracia uniforme: el estándar de exactitud no es el mismo para todos los tratamientos. Los usos estadísticos o agregados admiten mayor abstracción que los que producen efectos directos sobre individuos.
En la práctica, esto se traduce en clasificar cada tratamiento antes de fijar requisitos de dato. Nosotros usamos tres niveles:
| Nivel | Tipo de tratamiento | Ejemplos | Exigencia sobre el dato |
|---|---|---|---|
| A | Agregado / estadístico | Previsión de demanda, análisis de tendencias de tickets, cuadros de mando | Agregación y abstracción aceptables; foco en representatividad del conjunto |
| B | Asistencia con revisión humana | Sugerencia de respuesta, priorización de cola, extracción de datos de facturas | Trazabilidad de origen, corrección accesible, revisión previa a efectos |
| C | Efecto directo sobre la persona | Scoring, cribado de candidaturas, detección de fraude, decisiones automatizadas | Exactitud individual verificable, supervisión humana efectiva y vía de impugnación |
El error típico es tratar todo el proyecto de IA como un único bloque. Casi nunca lo es: el mismo sistema suele tener módulos de nivel A conviviendo con módulos de nivel C. Documentar esa clasificación por caso de uso cuesta media mañana y es lo primero que te preguntarán si alguna vez tienes que justificar el diseño.
Escribe el nivel (A/B/C) en la ficha de cada caso de uso y deriva de él tres cosas: qué campos se conservan, cuánto tiempo, y si hace falta o no revisión humana antes de que la salida produzca efectos. Si el nivel no está escrito, cada desarrollador aplicará el suyo.
Criterio 2: la calidad se mide en el conjunto, no dato a dato
Este es el criterio que más impacto tiene en ingeniería y el que la AEPD subraya como especialmente relevante en machine learning: la calidad debe evaluarse a nivel de conjunto de datos —representatividad, ausencia de sesgo, pertinencia—, no únicamente registro a registro.
Un dataset puede estar compuesto al 100% por datos ciertos y ser, aun así, de mala calidad: si todos tus ejemplos de "cliente que impaga" vienen de un único sector, el conjunto es exacto y a la vez inservible.
Cómo medir la representatividad de un dataset sin montar un departamento de data science
No hace falta un aparato estadístico sofisticado. Con una tarde de trabajo y una hoja de cálculo se cubre el 80% del valor:
- Define la población de referencia por escrito. ¿A quién va a aplicarse el sistema? Clientes activos de España, candidatos a puestos operativos, pacientes de una especialidad. Sin población definida, "representativo" no significa nada.
- Elige entre tres y seis variables de corte relevantes: territorio, tamaño de cliente, canal de entrada, antigüedad, tipo de producto. Incluye variables sensibles solo si puedes tratarlas lícitamente para control de sesgo, y con acceso restringido.
- Compara distribuciones. Porcentaje de cada segmento en el dataset frente a su porcentaje en la población de referencia. Una desviación grande es una alerta, no necesariamente un fallo: puede ser deliberada y justificable.
- Comprueba el mínimo por segmento. Un segmento con un puñado de ejemplos no sostiene ninguna conclusión. Si un grupo no llega a un volumen razonable, o recoges más datos, o lo excluyes del alcance del sistema y lo dices explícitamente.
- Mide la deriva temporal del histórico. Compara la distribución del último trimestre con la del conjunto completo. Si el negocio cambió de mercado o de proceso hace dos años, media base histórica está describiendo otra empresa.
- Audita las etiquetas. Coge una muestra aleatoria y que dos personas la etiqueten por separado. El desacuerdo entre ellas es el techo real de calidad de tu modelo: ningún sistema aprende a distinguir mejor de lo que tus criterios distinguen.
- Busca duplicados y fugas. Registros repetidos que inflan un segmento, y variables que contienen la respuesta de forma encubierta (fecha de cierre en un modelo que predice cierres, por ejemplo).
Qué documentar del conjunto
La documentación no tiene que ser larga, tiene que ser objetiva y comprobable. Una ficha por dataset con: origen y base jurídica, población de referencia, ventana temporal, volumen, distribución por las variables de corte, criterios de etiquetado, transformaciones, exclusiones conscientes, responsable y fecha de última revisión.
El sesgo más caro que vemos no es demográfico: es el sesgo de proceso. Se entrena con los casos que el equipo humano decidió revisar, y el modelo aprende el criterio de selección del equipo, no el fenómeno real. Antes de mirar métricas, pregunta siempre cómo llegaron esos registros al dataset.
Esta es exactamente la fase que en nuestro framework de validación de un caso de uso de IA en cuatro semanas revienta los proyectos en la semana 2: el POC con datos reales destapa que el conjunto no representa el problema. Mejor descubrirlo entonces que después de firmar.
Criterio 3: las salidas del sistema también son datos que pueden ser inexactos
Este es, para mí, el criterio más importante del documento y el que menos gente tiene interiorizado. Las salidas del sistema —predicciones, inferencias, decisiones— no deben generar representaciones incorrectas o desproporcionadas de las personas.
Dicho de forma directa: una inferencia errónea sobre una persona es un dato personal inexacto. Si tu sistema infiere que un cliente tiene "alta probabilidad de impago", esa inferencia es un dato personal nuevo que tú has creado, que se almacena, que se usa para decidir y sobre el que caben derechos. No es un artefacto interno del modelo. Y "desproporcionado" añade una segunda dimensión: una etiqueta categórica y estigmatizante derivada de una señal débil puede ser inexacta aunque el modelo acierte bastante en agregado.
Qué implica esto en el diseño
- Persiste la inferencia con su contexto. Versión del modelo, fecha, entradas relevantes, umbral aplicado y nivel de confianza. Una inferencia guardada como un simple booleano en una columna es indefendible: no puedes explicarla, ni revisarla, ni rectificarla con criterio.
- Guarda el score, no la etiqueta. Almacenar "riesgo 0,63" y aplicar el umbral en el momento de usarlo es más honesto y más rectificable que escribir "moroso" en la ficha del cliente para siempre.
- Haz que las salidas sean rectificables y suprimibles. Si un cliente ejerce rectificación sobre un dato de entrada, tienes que poder identificar y recalcular o invalidar las inferencias derivadas. Eso es un requisito de modelo de datos, no un proceso manual: necesitas linaje.
- Pon caducidad a las inferencias. Una predicción de hace catorce meses sobre el comportamiento de una persona rara vez sigue siendo un dato exacto. Si no vas a recalcularla, márcala como caducada o bórrala.
- Cuidado con los textos generados. Con LLMs el riesgo se dispara: un resumen automático de la relación con un cliente, una nota de reunión o una respuesta de un asistente interno pueden afirmar cosas sobre personas que nadie ha verificado, y quedarse escritas en el CRM como si fueran hechos.
Si usas un LLM para generar texto que menciona a personas identificables y ese texto se guarda en un sistema corporativo, estás creando datos personales nuevos con una tasa de error no medida. Marca siempre el contenido como generado, guarda la fuente en la que se apoya y exige revisión humana antes de que pase a un expediente.
- Mide la exactitud de la salida por segmento, no solo en global. Un 92% de acierto global puede esconder un 60% en el segmento que menos representado estaba. Ahí es donde el criterio 2 y el 3 se cruzan.
Criterio 4: desarrollo y explotación no juegan con las mismas reglas
Los requisitos de calidad difieren entre la fase de desarrollo y la fase de explotación, y el despliegue con impacto individual exige garantías reforzadas. Es una distinción sensata: en entrenamiento trabajas con conjuntos históricos y el daño potencial es indirecto; en producción cada salida puede afectar a una persona concreta hoy.
| Aspecto | Fase de desarrollo | Fase de explotación |
|---|---|---|
| Foco de la calidad | Representatividad y pertinencia del conjunto | Exactitud de cada entrada y de cada salida |
| Datos | Históricos, muestras, sintéticos, anonimizados | Datos reales de personas identificadas |
| Control principal | Evaluación offline por segmentos | Monitorización continua y supervisión humana |
| Documentación | Ficha de dataset y criterios de evaluación | Registro de decisiones, versiones y revisiones |
| Riesgo dominante | Aprender un mundo que no existe | Producir un efecto injusto sobre alguien concreto |
Dos consecuencias que se suelen pasar por alto. La primera: el entorno de desarrollo no es una zona franca; que sea "solo pruebas" no elimina la base jurídica ni la minimización, simplemente cambia el énfasis. La segunda: pasar a producción es un cambio de régimen, no un despliegue. Merece su propia lista de comprobación —umbrales, supervisión, canal de reclamación, plan de reversión— y no colarse en el sprint como una tarea más de infraestructura.
Criterio 5: datos sintéticos, anonimización y corrección de sesgos son vías legítimas
La AEPD reconoce expresamente que los datos sintéticos, la anonimización y la corrección de sesgos son compatibles con el principio de exactitud cuando están justificados por la finalidad. Esto merece subrayarse, porque en muchas empresas estas técnicas se ven como trampas: "si el dato no es real, no es exacto".
Es al revés. Si la finalidad se cumple igual con datos anonimizados o sintéticos, esa es la opción alineada con minimización y con exactitud: reduce el riesgo sin degradar la adecuación al fin. Ahora, "legítimo" no es "gratis". Cada técnica tiene su letra pequeña:
- Datos sintéticos. Sirven para ampliar cobertura de segmentos poco representados, probar casos límite y desarrollar sin exponer datos reales. Riesgo: si el generador se entrena con datos reales puede memorizar y reproducir registros identificables, y un dataset demasiado sintético produce modelos que fallan justo donde la realidad es sucia. Regla: sintéticos para desarrollo y cobertura, datos reales para la evaluación final.
- Anonimización. Útil y exigente. Quitar el nombre y el DNI no anonimiza nada si quedan combinaciones de atributos que reidentifican (código postal + fecha + producto suele bastar). Si el resultado sigue siendo reidentificable con medios razonables, sigues tratando datos personales. Documenta la técnica y el análisis de riesgo de reidentificación.
- Corrección de sesgos. Rebalancear clases, ponderar segmentos o recoger datos adicionales del grupo infrarrepresentado son intervenciones válidas, pero deja constancia: un rebalanceo altera las prevalencias reales, y quien luego lea las probabilidades del modelo como frecuencias del mundo se equivocará.
Traducción práctica: no tienes que elegir entre proteger datos y tener un modelo decente. Anonimizar bien, sintetizar donde falta cobertura y corregir sesgos documentándolo es, a la vez, mejor ingeniería y mejor cumplimiento. Lo que no es aceptable es hacerlo sin dejar rastro de por qué.
Si tu caso maneja datos especialmente sensibles, estas técnicas se combinan de forma natural con una arquitectura en la que el dato no sale de tu perímetro; lo tratamos en detalle en cómo desplegar IA sin enviar datos fuera de la UE.
Criterio 6: gobernanza proactiva, o el fin del "ya lo miraremos"
El sexto criterio ata todos los anteriores: se exige gobernanza proactiva del dato, con requisitos de calidad documentados y objetivos, y monitorización continua a lo largo de todo el ciclo de vida. "Documentados y objetivos" descarta la fórmula habitual de "revisamos la calidad de los datos periódicamente": un requisito objetivo tiene métrica, umbral, responsable y frecuencia.
El mínimo viable de gobernanza para una pyme
No hace falta una oficina de gobierno del dato. Hace falta esto, y cabe en cuatro documentos y un panel:
- Inventario de tratamientos con IA, con el nivel A/B/C del criterio 1 y su finalidad.
- Ficha por dataset (la del criterio 2), con propietario y fecha de revisión.
- Requisitos de calidad por dataset: dos o tres métricas con umbral. Por ejemplo, porcentaje máximo de registros con campos críticos vacíos, antigüedad máxima del histórico usado, cobertura mínima por segmento.
- Procedimiento de rectificación que alcance a las salidas: cómo se localizan las inferencias derivadas de un dato rectificado y qué se hace con ellas.
- Panel de monitorización en producción.
Qué monitorizar en producción
| Señal | Qué detecta | Frecuencia razonable |
|---|---|---|
| Distribución de las entradas frente a la del entrenamiento | Deriva de datos: el mundo cambió | Semanal |
| Distribución de las salidas (tasa de positivos, media del score) | Deriva del modelo o de un umbral mal calibrado | Semanal |
| Tasa de corrección humana sobre las sugerencias | Degradación real percibida por quien usa el sistema | Continua |
| Exactitud por segmento sobre muestra revisada | Sesgo que la métrica global esconde | Mensual |
| Campos críticos vacíos o fuera de rango | Roturas de integración aguas arriba | Diaria, automática |
| Rectificaciones, quejas y casos escalados | Impacto real sobre personas | Continua |
| Volumen de inferencias caducadas sin recalcular | Datos personales obsoletos acumulándose | Mensual |
Empieza por dos señales, no por siete. La tasa de corrección humana y los campos críticos vacíos son las dos que más avisos tempranos dan por unidad de esfuerzo, y ambas se implementan en un día sobre datos que ya tienes.
La monitorización tiene, además, un beneficio nada regulatorio: es lo que convierte un sistema de IA en un activo mantenible. Sin ella, la degradación es invisible hasta que alguien se queja.
Qué exigirle a un proveedor de IA
Si no construyes tú el sistema, buena parte de estos criterios se juegan en el contrato y en la fase de selección. Preguntas que conviene poner por escrito antes de firmar:
- ¿Con qué datos se ha entrenado el modelo y cuál es su población de referencia? Si la respuesta es vaga, el criterio 2 no está cubierto.
- ¿Qué métricas de exactitud aportáis por segmento, no solo globales? ¿Sobre qué conjunto de evaluación?
- ¿Cómo se documentan las transformaciones, exclusiones y correcciones de sesgo aplicadas?
- ¿Las salidas se almacenan con versión de modelo, fecha y nivel de confianza? ¿Podemos exportarlas?
- ¿Qué ocurre cuando un interesado ejerce rectificación sobre un dato de entrada? ¿Existe linaje hasta las inferencias derivadas?
- ¿Qué monitorización de deriva ofrecéis y qué se nos notifica cuando salta?
- ¿Qué pasa al actualizar la versión del modelo? ¿Hay evaluación comparativa previa y posibilidad de revertir?
- ¿Podemos auditar el sistema o encargar una auditoría de un tercero?
Una respuesta perfectamente aceptable de un proveedor es "para este caso de uso trabajamos a nivel agregado, con estándar de exactitud de nivel A". Lo que no es aceptable es que no sepa responder a qué nivel trabaja.
Errores que vemos una y otra vez
- Confundir precisión con exactitud. Guardar más decimales, más campos y más histórico "para ser exactos" es, con frecuencia, incumplir minimización sin ganar nada.
- Auditar registros y no el conjunto. Se validan formatos y rangos campo a campo, y nadie mira si el dataset representa a quien va a sufrir las decisiones.
- Tratar las salidas como si no fueran datos personales. Es el fallo más extendido y el más fácil de convertir en incidente.
- Documentar después. La ficha de dataset escrita seis meses tarde es arqueología, no gobernanza: se escribe mientras se construye o no se escribe.
- Delegar todo en el DPO o todo en el equipo técnico. Los seis criterios exigen las dos manos: el nivel de exigencia lo fija la finalidad (negocio y legal), pero las métricas y el linaje los implementa ingeniería.
Cierre: el criterio regulatorio ha alcanzado al criterio de ingeniería
Lo interesante de esta nota técnica no es que añada burocracia, es que coincide con lo que ya sabíamos que había que hacer. Cualquiera que haya llevado un sistema de IA a producción sabe que la representatividad del dataset, el control de las salidas y la monitorización de la deriva son la diferencia entre un sistema que aguanta dos años y uno que se apaga en silencio a los seis meses. Ahora, además, hay un criterio regulatorio que lo respalda.
Eso cambia la conversación interna: ya no hay que justificar por qué se dedican dos semanas a la calidad del dato antes de tocar el modelo. Y para una pyme es buena noticia, porque el trabajo que exige —clasificar tratamientos, documentar datasets, guardar el contexto de las inferencias, monitorizar dos o tres señales— es asumible y no depende del tamaño del equipo. Nada de esto garantiza el cumplimiento por sí solo: la evaluación depende de la finalidad concreta y del contexto de cada tratamiento, y conviene revisarla con vuestro DPO o asesoría jurídica. Pero es la base sobre la que esa evaluación se sostiene.
Si estáis diseñando un sistema de IA que trata datos personales, o tenéis uno en producción del que nadie sabe decir cómo de exactas son sus salidas, en Lin-ia hacemos precisamente ese trabajo: revisar el dato antes que el modelo, dejarlo documentado y montar la monitorización que avisa cuando se degrada. Escríbenos y lo miramos sobre vuestro caso.
Lecturas relacionadas: validar un caso de uso de IA en 4 semanas, IA on-premise sin enviar datos fuera de la UE y checklist del AI Act europeo.
