El EDPB pone orden en la anonimización: si tus datos aún permiten aislar, enlazar o inferir, siguen siendo datos personales

La anonimización acaba de perder una de sus coartadas favoritas: llamarse anonimización no convierte mágicamente unos datos en anónimos. El Comité Europeo de Protección de Datos (EDPB) adoptó el 7 de julio de 2026 su Guidelines 02/2026 on Anonymisation para consulta pública, y el mensaje de fondo es bastante menos amable que la prosa institucional: si tus datos todavía permiten aislar a una persona, enlazarla con otras fuentes o inferir suficiente información sobre ella, sigues dentro del perímetro del GDPR.

No es una precisión académica. Es un aviso operativo para bancos, aseguradoras, plataformas de datos, hospitales, anunciantes, data brokers y cualquiera que lleve años confundiendo seudonimización con anonimización porque resultaba conveniente en la presentación de PowerPoint. El documento llega en un momento en el que el uso secundario de datos, la IA generativa, los data clean rooms y los proyectos de monetización de datos han disparado una pregunta que el sector lleva tiempo respondiendo con optimismo creativo: cuándo deja un dato de ser personal de verdad.

La respuesta del EDPB no simplifica el trabajo, pero sí aclara por dónde hay que pasar. Y eso importa. Mucho.

Lo nuevo no es solo el qué, sino el cómo

La idea de que los datos anónimos quedan fuera del GDPR no tiene nada de revolucionaria. El propio Reglamento lo deja claro en su considerando 26: los principios de protección de datos no se aplican a la información anónima, es decir, a aquella que no se refiere a una persona física identificada o identificable, o que ha sido anonimizada de forma que el interesado no sea identificable. El problema siempre ha sido otro: casi todo el mundo dice querer datos anónimos, pero mucha menos gente sabe demostrar que realmente lo son.

Aquí el EDPB da un paso útil. Las guías no se limitan a repetir el considerando 26 ni a recitar obviedades sobre riesgo residual. Construyen un marco práctico de evaluación con dos enfoques y tres criterios técnicos concretos. Traducido a lenguaje no regulatorio: por fin hay una estructura razonablemente accionable para separar los casos sencillos de los autoengaños caros.

El documento se adopta al amparo del artículo 70.1.e del GDPR, que faculta al EDPB para emitir directrices, recomendaciones y buenas prácticas. No cambia el texto del Reglamento. Tampoco crea una categoría jurídica nueva. Pero sí tiene el potencial de reordenar cómo autoridades de control, delegados de protección de datos, equipos legales y áreas de analítica discuten una cuestión que, hasta ahora, se resolvía demasiadas veces con una mezcla de intuición, vaguedad técnica y fe en que nadie preguntara demasiado.

Hay un detalle que merece atención. El EDPB no analiza la anonimidad de manera abstracta, sino desde la perspectiva de la entidad relevante. Eso introduce una incomodidad muy real: un mismo conjunto de datos puede no plantear el mismo riesgo de reidentificación para todas las partes. Lo que para un destinatario externo podría ser anónimo, para quien conserva información auxiliar, claves, metadatos, historiales o acceso a otras bases puede seguir siendo claramente personal. Esa relatividad ya estaba implícita en el considerando 26, cuando habla de los medios razonablemente probables de ser utilizados. Las guías la convierten en método.

La gran corrección del EDPB: la anonimización se evalúa desde una perspectiva concreta, no en el vacío

Uno de los puntos más relevantes del texto está en la parte jurídica, cuando explica que la anonimidad debe evaluarse desde la perspectiva de cada entidad relevante, normalmente cualquier parte para la que los datos se pretendan anónimos. Parece sutil, pero no lo es. De hecho, dinamita un atajo muy extendido: asumir que si el receptor no tiene el nombre o el DNI, ya está todo resuelto.

Bajo el GDPR, una persona es identificable si puede ser distinguida de otras en un contexto dado mediante medios razonablemente probables de ser utilizados. Y el EDPB insiste en que “medios” debe interpretarse en sentido amplio, incluso si algunos de esos medios solo son accesibles a través de un tercero. Esa formulación importa porque obliga a mirar más allá del propio dataset y revisar el ecosistema de datos alrededor: información pública, bases comerciales, historiales de cliente, registros de dispositivos, datos de localización, archivos internos, proveedores analíticos y cualquier otra pieza que permita recomponer identidades.

El matiz práctico es este: la pregunta correcta no es “hemos borrado los identificadores directos?”, sino “quién podría volver a individualizar a alguien con lo que entregamos y con lo que ya tiene o puede obtener sin un esfuerzo desproporcionado?”. Son dos preguntas muy distintas, y durante años demasiados proyectos se han quedado cómodamente en la primera.

Las guías también recuerdan que la relación entre información y persona física puede venir por contenido, propósito o efecto. Esa tríada no es nueva —viene de la jurisprudencia y de la doctrina ya asentada en protección de datos—, pero aquí adquiere relevancia especial porque ataca otra zona gris muy frecuente: los datos que no “nombran” a nadie, pero se usan para tomar decisiones, segmentar, tratar de forma diferente o inferir características sobre personas. Si el efecto del tratamiento recae sobre individuos distinguibles, el argumento de “solo procesamos atributos técnicos” empieza a sonar como lo que a menudo es: semántica defensiva.

Dos enfoques para una misma pregunta, y uno de ellos es deliberadamente más severo

El EDPB propone dos formas de aplicar su marco de análisis: el enfoque contextual y el simplificado. No son equivalentes, y ahí está una de las aportaciones más inteligentes del documento.

El enfoque contextual intenta reflejar toda la complejidad del estándar jurídico. Evalúa si los datos son anónimos para cada entidad relevante según sus capacidades concretas. Eso obliga a considerar qué sabe cada actor, qué puede conseguir razonablemente, qué recursos tiene, qué incentivos existirían para reidentificar y qué barreras técnicas, contractuales u organizativas operan en la práctica.

El enfoque simplificado, en cambio, prescinde de esas diferencias de capacidad y adopta una visión más conservadora. En términos llanos: trata determinados datos como si no fueran anónimos aunque, para algunos destinatarios específicos, quizá sí podrían considerarse anónimos bajo un análisis jurídico fino. El propio EDPB reconoce que este enfoque puede ir más allá del estándar legal, pero ofrece dos ventajas que en la vida real pesan mucho: es más sencillo de aplicar y da mayor confianza a quien quiere minimizar riesgo regulatorio.

Esto tiene una consecuencia operativa inmediata. Si una organización busca reutilizar datos de forma amplia, compartirlos con múltiples terceros o alimentar modelos de IA con gobernanza razonable, el enfoque simplificado puede convertirse en un refugio pragmático. No porque el EDPB obligue a usarlo, sino porque reduce discusiones internas interminables y evita decisiones demasiado dependientes de hipótesis contextuales difíciles de defender ante una autoridad de control.

Ahora bien, tampoco conviene idealizarlo. El coste del enfoque simplificado es evidente: puede llevar a tratar como personales conjuntos de datos que, en ciertos contextos cerrados, quizá ya no lo sean. Para quienes persiguen máxima utilidad de datos, esa sobrerrestricción no es trivial. Aquí entra el dilema clásico entre seguridad jurídica y valor analítico. El EDPB no lo resuelve; simplemente deja claro que la comodidad metodológica tiene precio.

La prueba de fuego: No Record Isolation, No Linkage y No Inference

Si hay una parte del documento que merece quedarse pegada en la pared del equipo de datos, es esta. El marco técnico pivota sobre tres criterios: No Record Isolation, No Linkage y No Inference. No son eslóganes. Son las tres preguntas que deberían arruinar muchas etiquetas de “anonymous dataset” antes de que lleguen al comité de dirección.

No Record Isolation: si puedes singularizar un registro, no has terminado

El primer criterio examina si un individuo puede ser aislado o distinguido dentro del conjunto. No hace falta conocer su nombre. Basta con poder individualizarlo de forma suficientemente precisa y fiable para tratarlo de manera distinta. Y esto golpea directamente a los datos de alta dimensionalidad y alta resolución, dos características que el propio EDPB identifica como especialmente problemáticas.

Piénsalo en términos sencillos. Un dataset de movilidad con coordenadas muy precisas y marcas temporales finas, un historial transaccional granular, o un conjunto de eventos de navegación con combinaciones raras de atributos pueden permitir singularizar personas aunque se hayan eliminado los identificadores directos. El dato curioso —y bastante incómodo— es que cuanto más útil suele ser un dataset para analítica avanzada, más probable es que también sea singularizante.

La vieja receta de “quitar nombre, correo y número de cliente” no aguanta aquí ni un café. Si la combinación de variables sigue siendo única o casi única, el riesgo no desaparece. Solo cambia de disfraz.

No Linkage: si se puede enlazar con otras fuentes, la supuesta anonimidad se deshace

El segundo criterio pregunta si los registros pueden vincularse con información adicional. Aquí entra todo el universo de ataques de enlace, correlaciones y cruces con fuentes externas o internas. El EDPB deja claro que el análisis debe incluir medios accesibles a través de terceros cuando sean razonablemente probables de ser utilizados.

Para sectores altamente dataficados —finanzas, salud, telecomunicaciones, publicidad digital, movilidad— este es probablemente el criterio más letal. ¿Por qué? Porque pocas organizaciones operan con un solo dataset aislado. El verdadero riesgo está en los acoplamientos: CRM más web analytics; datos de pagos más geolocalización; historiales de siniestros más open data; eventos del dispositivo más datos de autenticación. La anonimización falla muchas veces no por lo que contiene una tabla, sino por lo bien que encaja con las demás.

Hay una implicación contractual que no debería pasar desapercibida. Si compartes datos supuestamente anónimos con un proveedor, socio o cliente, tu evaluación no puede fingir que ese tercero vive en una cueva sin acceso a otras fuentes. El artículo 5.2 del GDPR, el principio de responsabilidad proactiva, vuelve por la puerta de atrás: tendrás que poder demostrar por qué consideraste que el enlace no era razonablemente probable o por qué las salvaguardas aplicadas lo neutralizan suficientemente.

No Inference: aunque no identifiques a Juan, si puedes deducir algo fiable sobre Juan, el problema sigue ahí

El tercer criterio es, en cierto modo, el más sofisticado y el más contemporáneo. No se trata solo de identificar o enlazar, sino de inferir información sobre una persona con precisión suficiente para distinguirla y tratarla de forma diferente. En plena economía de modelos, perfiles y predicciones, este punto es cualquier cosa menos accesorio.

La relevancia práctica es enorme. Un conjunto de datos puede no permitir “reconocer” de forma inmediata a una persona, pero sí facilitar inferencias robustas sobre salud, solvencia, hábitos, ubicación, vulnerabilidades o comportamiento futuro. Si esas inferencias son lo bastante precisas y fiables, la frontera entre dato aparentemente inofensivo y dato personal vuelve a moverse hacia dentro del GDPR.

Aquí el EDPB acierta al centrar la evaluación en la exactitud del resultado. No basta con decir que una técnica de reidentificación o inferencia produce mucha incertidumbre. La pregunta es si el resultado final tiene precisión y fiabilidad suficientes para permitir distinguir y tratar de manera diferente al interesado. Esa vara es mucho más útil que las afirmaciones genéricas sobre “bajo riesgo”.

La guía no convierte la seudonimización en anonimización por insistencia semántica

Conviene decirlo sin rodeos porque sigue siendo uno de los errores más caros del mercado: seudonimizar no es anonimizar. El GDPR ya distingue claramente ambas figuras en el artículo 4.5, al definir la seudonimización como el tratamiento de datos personales de manera que ya no puedan atribuirse a un interesado sin utilizar información adicional, siempre que esa información adicional se conserve separada y protegida. Datos personales, no otra cosa.

Las guías del EDPB refuerzan esa separación de manera muy práctica. Si existe una información adicional que permite revertir la desvinculación, o si la estructura del dataset mantiene capacidad suficiente de aislamiento, enlace o inferencia, seguimos en territorio GDPR. Y eso arrastra consigo base jurídica, transparencia, limitación de finalidad, minimización, seguridad, posible evaluación de impacto del artículo 35 y, en determinados contextos, obligaciones de contratos con encargados y transferencias internacionales.

La ironía regulatoria es conocida: muchas organizaciones han vendido internamente la seudonimización como una especie de salida elegante del Reglamento, cuando en realidad el propio GDPR la trata como una medida de seguridad y gobernanza dentro del Reglamento. Es valiosa, sí. Reduce riesgos, también. Puede ayudar con el artículo 32 sobre seguridad del tratamiento y con la proporcionalidad de ciertas operaciones. Pero no te expulsa del campo de juego.

Esta diferencia importa especialmente en proyectos de analítica avanzada, entrenamiento de modelos y compartición de datos con filiales o terceros. Si el business case depende de afirmar que el dataset ya no es personal, las nuevas guías obligan a documentar mucho mejor esa conclusión. Y si no puedes sostenerla, tocará rediseñar el caso de uso o asumir las obligaciones correspondientes. No hay tercer camino místico.

Lo que cambia para IA, analítica y monetización de datos

Estas directrices llegan en 2026, no en 2019, y eso importa. El gran telón de fondo no es solo la protección de datos clásica, sino la industrialización de la inferencia. Cuanto mejores son los modelos para reconstruir, correlacionar, predecir y clasificar, más difícil resulta sostener afirmaciones flojas sobre anonimización.

Las guías no mencionan la IA como excusa universal, pero su lógica encaja de lleno con el problema. Un dataset que hace pocos años podía parecer “suficientemente desidentificado” puede dejar de serlo si los medios razonablemente probables para enlazar o inferir han cambiado. Y han cambiado. Más capacidad computacional, más fuentes accesibles, más datos comerciales, más herramientas de correlación y más incentivos económicos para extraer valor de perfiles finos. El estándar legal no se mueve, pero el contexto técnico sí, y eso afecta a la conclusión jurídica.

Para quienes trabajan con modelos, la consecuencia es incómoda pero clara. No basta con revisar solo el conjunto de entrenamiento. Hay que mirar también:

• la granularidad de los atributos,
• la posibilidad de vincular registros con otras fuentes disponibles,
• la existencia de memorization o extracción de información a través del modelo,
• los outputs agregados o sintéticos que podrían seguir permitiendo inferencias individualizadas,
• y los destinatarios concretos de los datos o resultados.

El documento del EDPB no entra a fondo en todos esos escenarios de IA, pero deja la base para que las autoridades lo hagan después. Y aquí está el quid: si una empresa confía en la etiqueta “anonymous” para entrenar, compartir o comercializar datos, la carga de la prueba técnica sube de nivel. Harán falta test más serios, documentación mejor atada y una conversación mucho menos ingenua entre legal, privacidad, seguridad y ciencia de datos.

En otras palabras: el tiempo del “lo anonimiza el proveedor” se ha terminado. O debería.

La mezcla de datos anónimos y personales: uno de los puntos más subestimados

El índice de las guías reserva un apartado específico a datasets que contienen una mezcla de datos anónimos y datos personales. Es un acierto, porque la práctica empresarial está llena de híbridos. No todo conjunto encaja limpiamente en una caja u otra. Hay tablas con campos verdaderamente agregados junto a variables que permiten singularización; hay entornos donde unos usuarios ven una versión limitada y otros conservan acceso a llaves de correlación; hay productos donde los resultados estadísticos conviven con datos subyacentes reutilizables.

Ese escenario híbrido tiene dos consecuencias. La primera: no puedes etiquetar todo el conjunto como anónimo porque una parte lo sea. La segunda: la gobernanza debe operar por capas, no por slogans. Clasificación granular, controles de acceso distintos, políticas de retención diferenciadas y documentación específica de qué elementos han salido realmente del ámbito del GDPR y cuáles no.

Esto parece administrativo, pero no lo es. En una investigación de la autoridad, la diferencia entre tener esa arquitectura documental o no tenerla puede decidir si el debate gira sobre matices técnicos o sobre un incumplimiento frontal del principio de responsabilidad proactiva del artículo 5.2.

Cómo encaja esto con el deber de demostrar cumplimiento

Las guías del EDPB no crean una obligación nueva de documentación, pero vuelven mucho más difícil improvisar. Si concluyes que un conjunto de datos es anónimo, tendrás que poder explicar cómo llegaste ahí. No con adjetivos. Con análisis.

Eso conecta con varios artículos del GDPR. El artículo 24 exige al responsable aplicar medidas apropiadas y poder demostrar que el tratamiento es conforme con el Reglamento. El artículo 25 obliga a protección de datos desde el diseño y por defecto. El artículo 32 exige medidas técnicas y organizativas apropiadas para la seguridad. Y si el tratamiento presenta alto riesgo, el artículo 35 puede obligar a una evaluación de impacto. Las guías no convierten cada proyecto de anonimización en una DPIA automática, pero sí elevan el umbral de seriedad que debería aplicarse antes de declarar “esto ya está fuera del GDPR”.

En la práctica, una evaluación defendible debería cubrir al menos cinco piezas. Primera, la descripción del dataset y sus atributos con atención a dimensionalidad y resolución. Segunda, la identificación de las entidades relevantes y sus capacidades. Tercera, el análisis de aislamiento, enlace e inferencia con técnicas plausibles de reidentificación. Cuarta, las medidas técnicas, organizativas y contractuales aplicadas. Quinta, la conclusión motivada sobre por qué, para cada destinatario pertinente, los datos pueden o no considerarse anónimos.

Si tu organización no tiene hoy esa mecánica, no estás sola. Tampoco estás cómoda.

Implicaciones para entidades financieras españolas

En banca, seguros, pagos y fintech, estas guías tienen más impacto del que parece a primera vista. No porque introduzcan obligaciones sectoriales nuevas, sino porque el sector financiero europeo vive de explotar datos ricos, longitudinales y enlazables: transacciones, fraude, solvencia, comportamiento digital, biometría, reclamaciones, siniestros, autenticación, geolocalización y señales de dispositivo. Justo el tipo de materiales que hacen sonreír a un equipo de analítica y fruncir el ceño a un regulador de privacidad.

Para entidades españolas, además, la cuestión no vive en un silo. Se cruza con DORA, que desde el 17 de enero de 2025 es aplicable y ha obligado a reforzar gobernanza, gestión de terceros TIC e inteligencia sobre dependencias. ¿Por qué importa aquí? Porque muchos procesos de anonimización, compartición analítica y explotación de datos descansan en proveedores cloud, plataformas de datos, herramientas de observabilidad y servicios externos. Si el proveedor participa en la transformación o acceso a los datos, la entidad no puede disociar el análisis GDPR del mapa de terceros que exige DORA, en particular sus artículos 28 y siguientes sobre gestión de riesgo de terceros TIC. Separar privacidad de resiliencia operativa es una forma elegante de comprar problemas por duplicado.

También hay una derivada de prevención de fraude y AML. Las entidades suelen intentar equilibrar minimización y utilidad, sobre todo cuando reutilizan datos para detección de anomalías, entrenamiento de modelos o pruebas en entornos no productivos. Las guías del EDPB no prohíben esos usos, pero sí endurecen el examen sobre si los datos “desidentificados” de verdad han salido del GDPR. Para muchos bancos, la conclusión práctica será menos romanticismo con la palabra anonimización y más segmentación de casos: seudonimización robusta donde el tratamiento siga siendo personal; anonimización solo donde pueda sostenerse con pruebas.

Hay otra implicación que no conviene pasar por alto. En proyectos de open banking, datos agregados de clientes, benchmarking comercial o compartición con socios del ecosistema, el criterio de No Linkage puede volverse especialmente severo. Los actores financieros suelen disponer de bases históricas, identificadores técnicos y capacidad analítica suficiente como para que los medios de enlace sean, precisamente, razonablemente probables. El EDPB no menciona a la banca con el dedo levantado, pero el zapato encaja sospechosamente bien.

La consulta pública abre una oportunidad, pero no para pedir indulgencia

Las guías 02/2026 están adoptadas para consulta pública desde el 7 de julio de 2026. Eso significa que el texto aún puede ajustarse antes de su versión final. Habrá comentarios de industria, asesores, academia, sociedad civil y autoridades nacionales. Y es previsible que una parte del mercado intente empujar en una dirección conocida: pedir más flexibilidad, más reconocimiento de medidas contractuales y organizativas, y quizá menos severidad implícita en algunos escenarios de reidentificación teórica.

Es un debate legítimo. No toda posibilidad abstracta de reidentificación debería bloquear la circulación útil de datos. El considerando 26 del GDPR ya habla de medios razonablemente probables, no de fantasías omniscientes. Y el propio EDPB intenta reflejarlo con el enfoque contextual. Pero sería un error interpretar la consulta como una invitación a rebajar el estándar hasta volverlo decorativo.

La pregunta que merece la pena plantear al regulador no es “cómo hacemos para llamar anónimo a casi todo?”, sino “qué grado de evidencia espera exactamente para aceptar que un conjunto concreto ha dejado de ser personal?”. Esa es la conversación madura. El resto es nostalgia por tiempos en los que bastaba un hash y un contrato para sentirse invulnerable.

Qué deberían hacer ahora los equipos de privacidad, legal, datos y seguridad

No hace falta esperar a la versión final para empezar a corregir inercias. De hecho, esperar sería una mala idea. El documento ya muestra con suficiente claridad hacia dónde apunta la interpretación europea.

Primer movimiento: revisar el inventario de datasets que la organización etiqueta hoy como “anónimos”, “anonimizados”, “deidentified”, “sanitized” o cualquier otro sinónimo corporativo de “no queremos discutir esto”. Hay que separar los casos de anonimización real de los de seudonimización, minimización o simple retirada de identificadores directos.

Segundo: mapear quiénes son las entidades relevantes para cada flujo. Responsable original, filiales, encargados, socios, clientes corporativos, laboratorios de analítica, investigadores, proveedores cloud. Si cambia el destinatario, puede cambiar la conclusión sobre identificabilidad.

Tercero: someter los conjuntos más sensibles a pruebas específicas de aislamiento, enlace e inferencia. No vale una declaración genérica del proveedor ni un memo jurídico sin contraste técnico. La evaluación debe tener participación real de perfiles de privacidad, ingeniería de datos y seguridad. Cuando haga falta, también de expertos externos. Sí, cuesta. Más caro resulta defender ante una autoridad que el análisis nunca se hizo.

Cuarto: revisar contratos, políticas de acceso y segregación de entornos. En algunos casos, el control contractual y organizativo no bastará para convertir datos personales en anónimos, pero sí será crucial para reducir qué medios son razonablemente probables de ser utilizados por determinadas partes. Ese matiz puede inclinar el análisis contextual.

Quinto: ajustar el lenguaje interno. Parece menor, pero no lo es. Si el comité llama “anónimo” a todo lo que no lleva nombre, el error conceptual se contagia a decisiones de producto, de riesgo y de cumplimiento. Las palabras importan porque luego acaban en procedimientos, contratos y respuestas al regulador.

La verdadera noticia: el EDPB no endurece el GDPR, endurece las excusas

Sería fácil presentar estas guías como otro ejercicio europeo de complicar lo que ya era complicado. Sería también perezoso. Lo que hace el EDPB, en realidad, es poner estructura donde abundaba la ambigüedad interesada. No inventa un test imposible. No exige anonimización perfecta, porque eso rara vez existe en sentido absoluto. Lo que hace es algo más incómodo: obligar a demostrar, con relación a actores concretos y técnicas plausibles, por qué un conjunto de datos ya no permite identificar, enlazar ni inferir de forma suficiente sobre personas físicas.

Ese estándar molestará a quienes han construido valor sobre una noción muy laxa de anonimización. A otros les vendrá bien. Una guía exigente pero razonablemente operativa reduce el margen para la competencia desleal regulatoria, esa en la que unos invierten en gobernanza seria y otros resuelven la cuestión con un nombre optimista en el repositorio.

La lección de fondo para 2026 es bastante simple. La anonimización ya no puede tratarse como un trámite de higiene previo a explotar datos, sino como una decisión técnica y jurídica de alto impacto. Si pasa el test del EDPB, excelente: has ganado libertad de uso. Si no lo pasa, la salida no es mirar hacia otro lado, sino tratar esos datos como lo que probablemente siguen siendo: datos personales.

Puede que a algunos les parezca una noticia incómoda. Lo es. También era hora.