Anonimización y NER por IA: la guía que desentraña anonimización, seudonimización y RGPD (2026)

Q: ¿Cuál es la diferencia concreta entre anonimización y seudonimización según el RGPD?

La anonimización es irreversible: resulta imposible reidentificar a la persona, incluso cruzando con otras fuentes, incluso con una clave. El dato sale del ámbito del RGPD y de la LOPDGDD (Considerando 26). La seudonimización, definida en el art. 4.5 RGPD, es reversible: un identificador seudónimo sustituye a los identificadores directos, pero existe una clave de reidentificación en otra ubicación bajo acceso restringido. El dato sigue siendo personal en el sentido del RGPD. Consecuencia práctica: la mayoría de los proyectos llamados 'anonimización IA' producen en realidad seudonimización. Las obligaciones del RGPD siguen aplicándose (registro de actividades, base de licitud, EIPD si procede), aunque el riesgo se haya reducido.

Q: ¿Es suficiente el NER (reconocimiento de entidades nombradas) para anonimizar un texto?

No, casi nunca. El NER detecta las entidades nombradas explícitas: nombres, apellidos, números de teléfono, direcciones, IBAN, DNI, número de Seguridad Social, fechas. Falla sistemáticamente con los datos indirectamente identificativos: descripciones precisas ('el director comercial que abandonó ACME S.A. en marzo de 2025'), combinaciones singulares (edad + ciudad + profesión), referencias internas (número de expediente correlacionado con un cliente), formulaciones contextuales. Una anonimización rigurosa exige NER + análisis contextual + revisión humana sobre los casos críticos + pruebas de robustez frente a la reidentificación — exactamente lo que la AEPD espera en su guía sobre técnicas de anonimización.

Q: ¿Qué precisión cabe esperar de un NER IA en 2026 sobre español?

En español estándar, un LLM moderno (Mistral Large, GPT-4o, Claude, MarIA del BSC) detecta entre el 95 y el 98 % de las entidades nombradas explícitas con un prompt bien construido. Los modelos dedicados (spaCy es_core_news_lg, BETO-NER, MarIA del Barcelona Supercomputing Center, GLiNER multilingüe) alcanzan entre el 92 y el 99 % de F1 según el dominio. El rendimiento cae fuertemente en: nombres extranjeros o raros, lenguas mixtas (catalán, gallego, vasco mezclado con español), abreviaturas sectoriales, referencias implícitas dentro del texto. Ningún modelo alcanza el 100 % — por eso la revisión humana sobre muestra sigue siendo indispensable al inicio.

Q: ¿LLM genérico o modelo NER dedicado?

Para la mayoría de casos en 2026, un LLM genérico bien promptado (Mistral, GPT-4o, Claude) basta con una precisión superior al 95 %. El modelo NER dedicado (spaCy es_core_news_lg, BETO-NER, MarIA, modelo afinado) se vuelve pertinente cuando el volumen es muy elevado (millones de documentos al mes), cuando la latencia es crítica (triaje en tiempo real en SNS-O o entidades financieras supervisadas por el Banco de España) o cuando el contexto es ultra-especializado (terminología clínica, jurídica). Regla simple: empezar con LLM genérico para el prototipo, pasar a dedicado si el coste de inferencia o el rendimiento lo justifican.

Q: ¿Un dato seudonimizado por NER sigue sometido al RGPD?

Sí. El RGPD considera que un dato sigue siendo personal mientras la reidentificación sea posible — directamente, indirectamente, por cruce con otras fuentes o vía la clave de seudonimización. La seudonimización reduce el riesgo pero no saca el dato del ámbito RGPD. Para alcanzar una verdadera anonimización en el sentido del RGPD, hay que destruir la clave, eliminar los datos indirectamente identificativos y resistir ataques por cruce. Es técnicamente muy difícil — la AEPD lo recuerda explícitamente en su guía 'K-anonimato como medida de privacidad'.

Q: ¿Qué casos de uso se sostienen realmente en empresas españolas?

Seis casos robustos: (1) preparar un corpus para fine-tuning de un modelo interno sin riesgo de fuga; (2) compartir un dataset con un consultor o socio académico bajo contrato de encargado de tratamiento; (3) responder a una solicitud de acceso (art. 15 RGPD) sin exponer datos de terceros; (4) analizar corpus internos (correos, actas) con fines de gestión sin cruzar la línea de la vigilancia individual ilegal según el Estatuto de los Trabajadores y la LOPDGDD art. 87-91 (derechos digitales en el ámbito laboral); (5) cumplimiento sectorial (SNS-O, MUFACE, secreto profesional médico según Ley 41/2002, banca según Banco de España); (6) preparación de documentos antes de llamar a un LLM SaaS para reducir la exposición.

Q: ¿Qué herramientas permiten anonimización IA soberana en 2026?

LLMs genéricos soberanos: Mistral Large vía La Plataforme (Francia), Mistral on-premise vía vLLM, alojamiento en proveedores españoles (Stackscale-Aire Networks, Acens, Pue Data Center). Modelos dedicados open-source: spaCy es_core_news_lg (excelente relación rendimiento/coste para español), BETO-NER (BERT español pre-entrenado por DCC Universidad de Chile), MarIA del Barcelona Supercomputing Center (modelo en español del proyecto IA Lenguaje 2025), GLiNER multilingüe. Microsoft Presidio es un excelente framework open-source pero la inferencia por defecto pasa por OpenAI — a redirigir hacia proveedor soberano o local. Para máxima soberanía: Mistral on-prem o Llama 3 auto-alojado + spaCy interno, cero salida de datos.

Q: ¿Hace falta una EIPD para un proyecto de anonimización IA?

Recomendada en la mayoría de casos, obligatoria en varios: volúmenes elevados, datos sensibles (salud, opiniones, biometría según art. 9 RGPD), tratamiento a gran escala, vigilancia sistemática de empleados, cruce de fuentes. La lógica: la anonimización IA es en sí misma un tratamiento automatizado de datos personales, por lo que está sometida al RGPD. La EIPD documenta el riesgo residual tras la seudonimización, justifica las elecciones técnicas y formaliza el control de acceso a la clave de reidentificación. La AEPD publica la lista indicativa de tratamientos que requieren EIPD en aepd.es.

Quick Answer: ¿qué es la anonimización por IA y el NER?

La anonimización y la seudonimización por IA se apoyan en la técnica del NER (Named Entity Recognition, «reconocimiento de entidades nombradas»: la capacidad de una IA para detectar automáticamente nombres, direcciones, números, fechas y organizaciones en un texto). La IA identifica estos datos personales y los sustituye por marcadores o seudónimos.

Distinción RGPD crítica:

Anonimización: transformación irreversible. El dato sale del ámbito del RGPD (Considerando 26). Muy difícil de alcanzar técnicamente — hay que asegurar que la persona no podrá ser reidentificada nunca, ni siquiera cruzando con otras fuentes, ni aunque alguien recupere la clave.
Seudonimización (art. 4.5 RGPD): sustitución reversible bajo acceso restringido. El dato sigue siendo personal en el sentido del RGPD, pero el riesgo se reduce.

La mayoría de los proyectos llamados «anonimización IA» producen en realidad seudonimización. Es lo primero que hay que aclarar: todo lo demás — base de licitud, EIPD, plazo de conservación, transferencias fuera de la UE — se deriva de ello.

Herramientas 2026:

Grandes modelos de lenguaje (Mistral Large, GPT-4o, Claude): precisión 95-98 % en español estándar, sencillos de implementar mediante un prompt, pero coste de inferencia y dependencia del proveedor.
Modelos NER dedicados (spaCy es_core_news_lg, BETO-NER, MarIA del BSC, GLiNER, Microsoft Presidio): más rápidos, más económicos en volumen, pero taxonomía rígida.
Para soberanía: Mistral instalado on-premise o Llama 3 auto-alojado + spaCy interno, cero salida de datos hacia Estados Unidos — relevante para SNS-O, MUFACE, despachos jurídicos y banca supervisada.

Casos de uso que se sostienen: preparación de corpus para fine-tuning interno, compartir con socios académicos bajo contrato, respuesta a solicitud RGPD art. 15 sin exponer datos de terceros, análisis de gestión de corpus internos respetando la LOPDGDD art. 87-91, cumplimiento sectorial (SNS-O, secreto médico Ley 41/2002, banca), preparación de documentos antes de llamar a un LLM SaaS.

Por qué este tema, por qué ahora

Muchas organizaciones españolas tienen en mente: «enviar nuestros documentos a un LLM, pero sin los datos personales dentro». La idea es sana. La promesa rara vez se cumple.

Tres cosas han cambiado en 2026. Una, los LLMs modernos saben hacer NER en español de verdad — no era cierto en 2022. Dos, los modelos dedicados open-source (spaCy, GLiNER, BETO-NER, MarIA) están al alcance de un despliegue soberano — no hace falta enviar una sola palabra a OpenAI para anonimizar una sola palabra. Tres, la doctrina regulatoria se ha endurecido sobre lo que cuenta verdaderamente como «anonimización»: la AEPD y el EDPB recuerdan regularmente que seudonimizar no es anonimizar (Dictamen EDPB 28/2024).

La trampa: creer que un detector de nombres basta para «salir del RGPD». No basta. Este artículo desentraña qué funciona, qué no, y dónde poner la frontera entre la IA, la organización, el DPD y la máquina humana de validación.

Anonimización vs seudonimización: la distinción que lo cambia todo

Es la base. Todo lo demás — base de licitud, EIPD, contratos con encargados, plazo de conservación — depende de esta distinción.

Anonimización en el sentido del RGPD

Para que un dato esté verdaderamente anonimizado, deben cumplirse tres condiciones simultáneamente, según la guía de la AEPD «Orientaciones y garantías en los procedimientos de anonimización de datos personales»:

Sin reidentificación directa — nombres, identificadores, DNI, números de Seguridad Social, IBAN se eliminan o transforman.
Sin reidentificación indirecta — ninguna combinación de atributos permite aislar a una persona. Esto incluye los contextos singulares («el único director comercial que abandonó ACME S.A. en marzo de 2025»).
Sin reidentificación por cruce — incluso combinando con el Registro Mercantil, el censo electoral, una exportación de LinkedIn o una base abierta, la persona permanece indistinguible.

Si se cumplen las tres condiciones, el dato sale del ámbito de aplicación del RGPD. Es la promesa máxima.

Alcanzar las tres condiciones es técnicamente muy difícil, especialmente en textos libres (correos, actas, contratos). Existen técnicas formales — k-anonimato, l-diversidad, t-cercanía — pero se aplican sobre todo a bases tabulares, no a texto libre.

Seudonimización en el sentido del RGPD

El art. 4.5 del RGPD la define como «el tratamiento de datos personales de manera tal que ya no puedan atribuirse a un interesado sin utilizar información adicional, siempre que dicha información adicional figure por separado y esté sujeta a medidas técnicas y organizativas».

En claro: se sustituye María García por Persona_001 y se conserva una tabla Persona_001 → María García en otro sitio, bajo acceso muy restringido. La seudonimización reduce fuertemente el riesgo, pero el dato sigue siendo personal en el sentido del RGPD. Todas las obligaciones se aplican: registro de actividades, base de licitud, plazo de conservación, derechos de los interesados, EIPD si procede, contratos con encargados.

Tabla rápida de decisión

Criterio	Anonimización	Seudonimización
Vínculo con la persona	Destruido irremediablemente	Conservado vía clave separada
¿Sometida al RGPD?	No	Sí
Factibilidad sobre texto libre	Muy difícil	Factible con NER + política
Caso de uso típico	Publicación de dataset abierto	Tratamiento interno, intercambio enmarcado
Riesgo residual	Casi nulo (si se hace bien)	Bajo pero no nulo
Esfuerzo de implementación	Elevado	Moderado

Veredicto práctico: la mayoría de los proyectos llamados «anonimización IA» son en realidad seudonimización. No es una debilidad, es un marco claro. La trampa consiste en prometer anonimización y entregar seudonimización: el cumplimiento se desploma y el DPD descubre el problema seis meses después — típicamente durante una inspección de la AEPD.

El NER: lo que hace, lo que no hace

La mecánica

El NER (Named Entity Recognition) identifica en un texto las entidades nombradas pertenecientes a categorías predefinidas. Una taxonomía clásica adaptada al contexto español:

Categoría	Ejemplo	Sensibilidad RGPD
PER — persona	María García, D. Martín	Identificador directo
ORG — organización	ACME S.A., Hospital Clínic	Indirecto (combinado con PER)
LOC — lugar	Madrid, Calle Mayor 24	Indirecto, a veces directo (dirección precisa)
DATE	15 de marzo de 2026	Indirecto (fechas de eventos personales)
EMAIL / PHONE / IBAN / DNI / NUSS	maria@acme.es, 91 234 56 78	Identificadores directos
MISC — diversos	Número de expediente, referencia interna	Variable

Para la seudonimización en empresas españolas, esta taxonomía se enriquece con categorías de negocio: número de paciente (HCE), identificador de cliente, número de expediente, importes sensibles, identificadores de contratos, código postal (combinado con edad y género es altamente identificativo — el resultado de Sweeney sobre códigos ZIP estadounidenses se transpone a códigos postales españoles). Es este trabajo de tipado de negocio lo que marca la diferencia entre un NER genérico y una seudonimización utilizable.

Esquema simplificado del pipeline

[Texto fuente]
      │
      ▼
[NER] → lista de entidades detectadas (tipo, valor, posición)
      │
      ▼
[Política de sustitución] → qué eliminar, qué seudonimizar, qué conservar
      │
      ▼
[Generación de seudónimos] → tabla «original → seudónimo»
      │                              │
      │                              ▼
      │                       [Bóveda segura]
      ▼                       (clave de reidentificación,
[Texto seudonimizado]          acceso muy restringido)

La bóveda es la pieza crítica. Si cualquiera puede acceder a la tabla de correspondencia, la seudonimización se desploma. Es un punto arquitectónico, no un detalle de implementación — la AEPD examinará exactamente este control durante una inspección.

Lo que el NER no ve

El NER, incluso excelente, falla con tres familias de datos identificativos:

1. Datos indirectamente identificativos por contexto. «El director comercial que abandonó ACME S.A. en marzo de 2025 hacia un competidor» — ningún nombre propio en la frase, pero solo una persona en el mundo encaja. El NER detecta «director comercial», «ACME S.A.», «marzo de 2025». No comprende que la combinación es singular.

2. Combinaciones raras. «Mujer, 47 años, ingeniera agrónoma, residente en Albacete, madre de gemelos» — ningún elemento es identificativo de forma aislada, el conjunto sí lo es fuertemente. Ningún NER detecta «combinación rara».

3. Referencias implícitas internas. «Como acordamos ayer por teléfono, aquí va el borrador de carta para el cliente del que hablábamos» — el NER no ve ninguna entidad identificable y, sin embargo, un humano que conoce el contexto sabe exactamente de quién se trata.

Por eso la revisión humana sobre muestra sigue siendo obligatoria: 5 a 10 % del corpus al inicio, reducible al 1-2 % una vez estabilizados los patrones. Y por eso combinamos sistemáticamente el NER con una política de reescritura contextual sobre los casos de alto impacto: no solo sustituimos los nombres, también neutralizamos los contextos singulares.

Los tres enfoques técnicos (en lenguaje llano)

Enfoque 1 — LLM genérico con instrucción

Se le da al LLM una instrucción del tipo: «identifica en este texto todas las entidades nombradas y devuélvelas en forma estructurada, con su tipo y posición». Los modelos modernos (Mistral Large, GPT-4o, Claude) lo hacen muy bien sobre español estándar.

Ventajas	Límites
Precisión elevada (95-98 % en español estándar)	Coste de inferencia no trivial en volumen
Gestiona el contexto (útil para casos ambiguos)	Latencia (unos segundos por documento)
Flexible: taxonomía adaptada vía prompt	Dependencia del proveedor LLM
Sin curva de aprendizaje técnica	Posible salida hacia proveedor extranjero si SaaS

Cuándo es la elección correcta: prototipos, volúmenes bajos a medios (hasta unas decenas de miles de documentos al mes), taxonomía evolutiva, equipo sin experiencia en NLP.

Enfoque 2 — Modelo NER dedicado (open-source)

Modelo pre-entrenado especializado: spaCy es_core_news_lg, BETO-NER, MarIA del BSC, GLiNER, Microsoft Presidio. Funciona en local, muy rápido, bajo coste.

Ventajas	Límites
Muy rápido (milisegundos por documento)	Taxonomía rígida por defecto
Económico en volumen	Rendimiento variable según dominio
Desplegable on-premise, cero salida de datos	Setup más técnico (Python, empaquetado de modelos)
Maduro (spaCy en producción desde 2015)	Comprensión débil del contexto

Cuándo es la elección correcta: volúmenes elevados (SNS-O, banca), latencia crítica, exigencia de soberanía máxima, presupuesto de inferencia controlado.

Enfoque 3 — Híbrido

Modelo dedicado para la detección rápida en el grueso del flujo + LLM genérico para casos complejos o ambiguos + revisión humana sobre casos críticos.

Ventajas	Límites
Óptimo coste / precisión en grandes volúmenes	Arquitectura más compleja
Robusto sobre casos atípicos	Exige un orquestador (LangChain, código a medida)
Compatible con soberanía	Requiere seguimiento de métricas (tasa de fallback al LLM)

Cuándo es la elección correcta: producción estabilizada, grandes volúmenes, exigencia de calidad alta, equipo capaz de operar un pipeline.

Árbol de decisión rápido

¿Volumen mensual?
│
├── < 10.000 documentos
│   └── ¿Latencia crítica (tiempo real)?
│       ├── Sí → NER dedicado (spaCy)
│       └── No → LLM genérico
│
├── 10.000 – 1 millón
│   └── ¿Sensibilidad máxima (SNS-O, despacho)?
│       ├── Sí → Híbrido sobre stack soberana
│       └── No → LLM genérico soberano (Mistral)
│
└── > 1 millón
    └── Híbrido obligatorio (economía de inferencia + calidad)

Casos de uso que se sostienen

Sin catálogo exhaustivo. Seis casos robustos, con lo que hay que saber antes de empezar.

Caso 1 — Preparar un corpus para fine-tuning interno

Contexto: una organización española quiere adaptar un LLM open-source (Llama, Mistral) a su negocio. Dispone de un corpus de actas internas, intercambios de correo, documentación. Sin seudonimización, estos datos arriesgan terminar en los pesos del modelo final y reaparecer mediante un ataque llamado membership inference («¿estaba este documento en el corpus de entrenamiento?»).

Volumen tipo: 10.000 a 500.000 documentos.

Lo que puede fallar: seudonimización incompleta sobre referencias internas (números de expediente, códigos de proyecto) — estas referencias no las ve el NER pero permiten cruce interno.

Métrica de éxito: tasa de reidentificación < 1 % sobre muestra manual post-seudonimización.

Caso 2 — Compartir con un socio académico o consultor

Contexto: un despacho jurídico español quiere compartir un corpus de contratos con un laboratorio universitario para análisis estadístico. Un actor sanitario quiere compartir actas de casos clínicos con un consultor de datos para una auditoría de calidad.

Volumen tipo: unos miles de documentos.

Lo que puede fallar: subestimación de los datos indirectamente identificativos. Un contrato anonimizado sobre los nombres de las partes puede seguir siendo identificable por el número de procedimiento, el juzgado competente, la fecha de registro.

Salvaguarda: contrato de encargado de tratamiento (art. 28 RGPD) con el socio, plazo de conservación limitado, destrucción demostrable, auditoría posible. La seudonimización por sí sola no sustituye al contrato — y para datos del SNS-O, los acuerdos de cesión deben respetar la Ley 41/2002 sobre autonomía del paciente.

Caso 3 — Responder a una solicitud RGPD art. 15

Contexto: una persona solicita acceso a sus datos personales. Tiene derecho a recibirlos — pero no a obtener de paso los datos de otras personas presentes en los mismos documentos (correos, actas). NER + tachado de terceros hace la respuesta conforme. La AEPD ha sancionado en varios procedimientos la mala gestión de solicitudes de acceso (multas de 10.000 a 100.000 € en sectores variados desde 2023).

Volumen tipo: variable, a veces unos pocos documentos, a veces varios cientos.

Lo que puede fallar: sobre-seudonimización que vuelve el documento ininteligible e impide al solicitante comprender sus propios datos.

Salvaguarda: política clara sobre lo que se tacha y lo que se conserva, validación por el DPD o servicio jurídico antes del envío.

Caso 4 — Analizar un corpus interno sin caer en vigilancia individual ilegal

Contexto: una dirección quiere comprender los temas recurrentes en los intercambios internos (correos, soporte al cliente) sin cruzar la línea de la vigilancia individual ilegal según el Estatuto de los Trabajadores y la LOPDGDD art. 87-91 (derechos digitales en el ámbito laboral). La seudonimización de remitentes y destinatarios permite un análisis agregado.

Volumen tipo: 10.000 a 1 millón de mensajes al mes.

Lo que puede fallar: la seudonimización no basta si el análisis revela indirectamente el comportamiento individual (volumen de envío atípico, patrones horarios únicos). Hay que agregar antes del análisis.

Salvaguarda: información previa a la representación legal de los trabajadores (comité de empresa), EIPD documentada, finalidad limitada, acceso restringido a los resultados.

Contexto: un actor sanitario quiere usar un LLM externo para analizar informes clínicos. Si el identificador de paciente no es necesario para el análisis, la seudonimización aguas arriba permite enviar el contenido a un LLM menos restringido (Mistral Le Chat Enterprise) en lugar de imponer una infraestructura completa conforme al ENS de alta categoría. La Ley 41/2002 (autonomía del paciente) y el secreto médico siguen aplicándose — la seudonimización no exime a la organización de documentar finalidad, necesidad y minimización. Véase nuestra guía IA conforme al RGPD.

Salvaguarda: contrato de encargado con el proveedor LLM, EIPD obligatoria, trazabilidad de cada envío, conservación de la versión original en entorno ENS-Alto.

Caso 6 — Preparación contable y flujos financieros

Contexto: facturas sensibles (facturas de proveedores con datos salariales, facturas sanitarias en pólizas de salud), notas de gastos detalladas. Seudonimización de datos de pacientes o empleados antes del tratamiento por un LLM SaaS para extracción estructurada. Véase nuestra guía automatización de facturas con IA.

Volumen tipo: 10.000 a 500.000 documentos al mes según el tamaño de la organización.

Arquitectura de referencia: lo que montamos en concreto

Un pipeline de anonimización IA en producción se descompone en siete etapas. Cada una tiene sus trampas.

Etapa 1 — Ingesta. El documento llega en formato bruto: PDF, Word, correo, exportación de base de datos, imagen escaneada. Para documentos no textuales, OCR previo (Tesseract, AWS Textract en región Madrid, Doctly). En esta etapa se conserva el original cifrado para auditoría.

Etapa 2 — Detección NER. LLM o modelo dedicado identifica las entidades. Salida: lista estructurada {tipo, valor, offset_inicio, offset_fin}. Para documentos largos se trocea en bloques de unos miles de caracteres con solapamiento (chunking); de lo contrario los modelos pierden entidades en los bordes.

Etapa 3 — Política de sustitución. Decisión de negocio, no técnica:

Categorías a eliminar (eliminación limpia, p. ej. números de tarjeta en correos)
Categorías a seudonimizar (sustitución por identificador seudónimo estable, p. ej. nombres de personas)
Categorías a conservar (útiles para uso posterior, p. ej. fechas si sirven al análisis temporal)

Etapa 4 — Generación de seudónimos. María García → Persona_001. El seudónimo debe ser estable (la misma persona recibe el mismo seudónimo en todos los documentos) y no correlacionado con el valor original (sin hash del valor — un hash es atacable por diccionario si el dominio es pequeño). La tabla de correspondencia se almacena en bóveda separada.

Etapa 5 — Aplicación al texto. Sustitución efectiva. Atención a fronteras de palabra, mayúsculas/minúsculas, acentos, variaciones ortográficas. Una María García puede aparecer más adelante como Sra. García, Dña. García, M. García — el NER debe enlazar estas formas (resolución de correferencia).

Etapa 6 — Validación. Revisión humana sobre muestra (5 a 10 % al inicio, reducible al 1-2 % tras estabilización). Medimos:

Tasa de entidades omitidas (recall)
Tasa de detecciones falsas (precisión)
Presencia de datos indirectamente identificativos residuales

Etapa 7 — Auditoría y logs. Conservación separada:

Documento original cifrado (en caso de litigio, solicitud RGPD art. 15, auditoría)
Documento seudonimizado (para uso posterior)
Tabla de correspondencia (bóveda, acceso muy restringido)
Logs de acceso (quién vio qué, cuándo)

Esquema de producción simplificado

[Fuente]              [Tratamiento]             [Destinos]
   │                       │                       │
   ▼                       ▼                       ▼
PDF / correo ──► OCR ──► NER ──► Política ──► Seudo. ──► LLM SaaS / fine-tune / compartir
                          │           │
                          └─► Auditoría ──┘
                                │
                                ▼
                          Bóveda de clave (acceso estricto)
                          Original cifrado (ENS-Alto si sanidad)

La trampa de la reidentificación

Es la prueba definitiva. Una seudonimización que no resiste a los ataques por cruce no es seudonimización utilizable — y la AEPD lo dirá durante una inspección.

Tres ataques clásicos

Ataque 1 — Cruce con fuente abierta. El atacante dispone del Registro Mercantil, el censo electoral, una exportación de LinkedIn. Cruza los atributos restantes en el documento seudonimizado (edad, ciudad, profesión, empleador) con estas fuentes. Si una combinación es única, la reidentificación tiene éxito. El famoso estudio de Sweeney (1997) mostró que el 87 % de los individuos estadounidenses son únicamente identificables por código ZIP + fecha de nacimiento + género — los códigos postales españoles dan resultados similares.

Ataque 2 — Inferencia por contexto. El atacante conoce el dominio. Sabe que solo un director comercial abandonó ACME S.A. en marzo de 2025. Deduce la identidad.

Ataque 3 — Membership inference (sobre LLM afinado). Un atacante interroga un modelo afinado sobre un corpus seudonimizado para adivinar si tal o cual individuo estaba en el corpus. Si el modelo se ha sobreajustado, revela información. El trabajo de Carlini et al. (2023) sobre ataques de extracción contra GPT-2 ha situado el tema en los consejos de administración.

Tres defensas

Defensa 1 — k-anonimato (para bases tabulares). Cada combinación de atributos aparece al menos k veces en el dataset. Si k = 5, cada perfil es indistinguible de al menos otros 4. Sobre texto libre, transposición parcial vía generalización: «47 años» → «40-50 años», «ingeniera agrónoma en Albacete» → «cuadro en Castilla-La Mancha».

Defensa 2 — l-diversidad y t-cercanía. Extensiones del k-anonimato que también restringen la diversidad de los valores sensibles en cada grupo. Útil cuando los datos sensibles (salud, opinión) son el núcleo del dataset.

Defensa 3 — Pruebas de reidentificación. Más pragmático: intentar activamente reidentificar sobre una muestra. Si se logra demasiado fácilmente, la seudonimización es insuficiente. Esta práctica la espera la AEPD para proyectos sensibles según su guía sobre técnicas de anonimización.

Ninguna de las tres protege totalmente. Regla práctica: probar explícitamente la robustez antes de la puesta en producción y documentar las pruebas.

Cumplimiento RGPD: lo que se espera realmente

La anonimización/seudonimización por IA es en sí misma un tratamiento automatizado de datos personales. Por tanto sometida al RGPD. Esto es lo que se inscribe y lo que hay que poder producir en caso de inspección.

En el registro de actividades de tratamiento (art. 30 RGPD)

Una ficha dedicada: «seudonimización automatizada por NER para [finalidad precisa]». Se consigna:

Finalidad (p. ej. preparar corpus para fine-tuning, compartir con socio X, analizar correos internos)
Categorías de datos tratados (texto libre, tipos de entidades detectadas)
Personas afectadas (clientes, empleados, pacientes según el caso)
Plazo de conservación (del original, de la versión seudonimizada, de la tabla de correspondencia — cada uno justificado)
Encargados de tratamiento (proveedor del LLM, alojamiento)
Medidas técnicas y organizativas

Base de licitud

Según el contexto:

Interés legítimo (art. 6.1.f RGPD): caso más frecuente para tratamientos internos, a condición de documentar el test de ponderación (interés perseguido vs derechos de las personas).
Ejecución de un contrato: si el tratamiento se deriva directamente de la ejecución de un contrato con la persona.
Obligación legal: rara, pero posible (respuesta a solicitud RGPD art. 15, por ejemplo).
Consentimiento: excepcionalmente, y a evitar si otra base es movilizable — el consentimiento puede retirarse.

EIPD (evaluación de impacto)

Recomendada en la mayoría de casos, obligatoria en varios escenarios listados por la AEPD:

Volúmenes elevados
Datos sensibles (salud, opiniones políticas, biométricos, judiciales)
Tratamiento a gran escala
Vigilancia sistemática de empleados
Cruce de fuentes

La EIPD documenta el riesgo residual tras la seudonimización, justifica las elecciones técnicas y formaliza el control de acceso a la clave. Se mantiene a disposición de la AEPD en caso de inspección. Véase nuestra guía EIPD para proyecto IA.

Contrato de encargado con el proveedor LLM

Si usa un LLM SaaS, el contrato de encargado de tratamiento debe prever:

Localización del tratamiento (idealmente UE — Mistral, Scaleway, Stackscale)
Prohibición de usar los datos para entrenar el modelo
Plazo de conservación de prompts y completados
Subencargados (alojamiento, copias de seguridad)
Modalidades de notificación de incidente

Con un proveedor soberano europeo, el contrato es netamente más simple. Con un proveedor estadounidense, se convierte en un expediente técnico aparte (cláusulas contractuales tipo, transfer impact assessment según Schrems II, a veces inutilizable según la naturaleza de los datos — particularmente para datos del SNS-O o banca supervisada por el Banco de España).

Localización del tratamiento

Para datos sensibles (salud SNS-O, secreto médico, datos bancarios bajo supervisión del Banco de España, datos salariales), la localización es un tema en sí mismo. Tres niveles:

Nube soberana (Scaleway, OVHcloud, Stackscale-Aire Networks, Acens, Pue Data Center) — los datos permanecen en la UE, bajo derecho europeo, sin riesgo de incautación bajo el Cloud Act estadounidense.
On-premise — la IA funciona sobre los servidores de la organización, cero salida de datos. Véase nuestra guía LLM local en empresa.
Nube extranjera con marco contractual — posible pero con carga documental considerable y riesgo residual no nulo. El EU-US Data Privacy Framework ayuda para algunos flujos pero no cubre todos los casos.

Para la mayoría de casos sensibles en España, se mantiene o un proveedor soberano (Mistral La Plataforme), o on-premise. Es el enfoque que adopta DPLIANCE para sus clientes, en el marco de soluciones IA a medida.

Lo que rehusamos prometer

Tres antipatrones que vemos regularmente en proyectos y que evitamos en DPLIANCE.

«Vamos a anonimizar, así que salimos del RGPD.» No, salvo caso muy excepcional. La seudonimización permanece bajo RGPD. Si la promesa de salir del RGPD es necesaria para el proyecto, hay que rediseñar el proyecto — no torcer el sentido de las palabras. La guía de la AEPD sobre técnicas de anonimización es explícita sobre esto.

«El NER lo detecta todo, no necesitamos revisión humana.» Ningún NER detecta los contextos singulares, las combinaciones raras, las referencias implícitas. La revisión humana sobre muestra es no negociable al inicio y sigue siendo recomendada en régimen estable.

«Conservamos la clave de reidentificación, pero la cerramos bien.» Si la clave permanece accesible para varias personas, la seudonimización se vuelve teórica. La práctica RGPD espera un acceso muy restringido, registrado, con un proceso de recuperación excepcional y trazado.

FAQ

¿Cuál es la diferencia concreta entre anonimización y seudonimización según el RGPD?

La anonimización es irreversible: resulta imposible reidentificar a la persona, incluso cruzando con otras fuentes, incluso con una clave. El dato sale del ámbito del RGPD y de la LOPDGDD (Considerando 26). La seudonimización, definida en el art. 4.5 RGPD, es reversible: un identificador seudónimo sustituye a los identificadores directos, pero existe una clave de reidentificación en otra ubicación bajo acceso restringido. El dato sigue siendo personal en el sentido del RGPD. Consecuencia práctica: la mayoría de los proyectos llamados «anonimización IA» producen en realidad seudonimización. Las obligaciones del RGPD siguen aplicándose (registro de actividades, base de licitud, EIPD si procede), aunque el riesgo se haya reducido.

¿Es suficiente el NER (reconocimiento de entidades nombradas) para anonimizar un texto?

No, casi nunca. El NER detecta las entidades nombradas explícitas: nombres, apellidos, números de teléfono, direcciones, IBAN, DNI, número de Seguridad Social, fechas. Falla sistemáticamente con los datos indirectamente identificativos: descripciones precisas («el director comercial que abandonó ACME S.A. en marzo de 2025»), combinaciones singulares (edad + ciudad + profesión), referencias internas (número de expediente correlacionado con un cliente), formulaciones contextuales. Una anonimización rigurosa exige NER + análisis contextual + revisión humana sobre los casos críticos + pruebas de robustez frente a la reidentificación — exactamente lo que la AEPD espera en su guía sobre técnicas de anonimización.

¿Qué precisión cabe esperar de un NER IA en 2026 sobre español?

En español estándar, un LLM moderno (Mistral Large, GPT-4o, Claude, MarIA del BSC) detecta entre el 95 y el 98 % de las entidades nombradas explícitas con un prompt bien construido. Los modelos dedicados (spaCy es_core_news_lg, BETO-NER, MarIA del Barcelona Supercomputing Center, GLiNER multilingüe) alcanzan entre el 92 y el 99 % de F1 según el dominio. El rendimiento cae fuertemente en: nombres extranjeros o raros, lenguas mixtas (catalán, gallego, vasco mezclado con español), abreviaturas sectoriales, referencias implícitas dentro del texto. Ningún modelo alcanza el 100 % — por eso la revisión humana sobre muestra sigue siendo indispensable al inicio.

¿LLM genérico o modelo NER dedicado?

Para la mayoría de casos en 2026, un LLM genérico bien promptado (Mistral, GPT-4o, Claude) basta con una precisión superior al 95 %. El modelo NER dedicado (spaCy es_core_news_lg, BETO-NER, MarIA, modelo afinado) se vuelve pertinente cuando el volumen es muy elevado (millones de documentos al mes), cuando la latencia es crítica (triaje en tiempo real en SNS-O o entidades financieras supervisadas por el Banco de España) o cuando el contexto es ultra-especializado (terminología clínica, jurídica). Regla simple: empezar con LLM genérico para el prototipo, pasar a dedicado si el coste de inferencia o el rendimiento lo justifican.

¿Un dato seudonimizado por NER sigue sometido al RGPD?

Sí. El RGPD considera que un dato sigue siendo personal mientras la reidentificación sea posible — directamente, indirectamente, por cruce con otras fuentes o vía la clave de seudonimización. La seudonimización reduce el riesgo pero no saca el dato del ámbito RGPD. Para alcanzar una verdadera anonimización en el sentido del RGPD, hay que destruir la clave, eliminar los datos indirectamente identificativos y resistir ataques por cruce. Es técnicamente muy difícil — la AEPD lo recuerda explícitamente en su guía «K-anonimato como medida de privacidad».

¿Qué casos de uso se sostienen realmente en empresas españolas?

Seis casos robustos: (1) preparar un corpus para fine-tuning de un modelo interno sin riesgo de fuga; (2) compartir un dataset con un consultor o socio académico bajo contrato de encargado de tratamiento; (3) responder a una solicitud de acceso (art. 15 RGPD) sin exponer datos de terceros; (4) analizar corpus internos (correos, actas) con fines de gestión sin cruzar la línea de la vigilancia individual ilegal según el Estatuto de los Trabajadores y la LOPDGDD art. 87-91 (derechos digitales en el ámbito laboral); (5) cumplimiento sectorial (SNS-O, MUFACE, secreto profesional médico según Ley 41/2002, banca según Banco de España); (6) preparación de documentos antes de llamar a un LLM SaaS para reducir la exposición.

¿Qué herramientas permiten anonimización IA soberana en 2026?

LLMs genéricos soberanos: Mistral Large vía La Plataforme (Francia), Mistral on-premise vía vLLM, alojamiento en proveedores españoles (Stackscale-Aire Networks, Acens, Pue Data Center). Modelos dedicados open-source: spaCy es_core_news_lg (excelente relación rendimiento/coste para español), BETO-NER (BERT español pre-entrenado por DCC Universidad de Chile), MarIA del Barcelona Supercomputing Center (modelo en español del proyecto IA Lenguaje 2025), GLiNER multilingüe. Microsoft Presidio es un excelente framework open-source pero la inferencia por defecto pasa por OpenAI — a redirigir hacia proveedor soberano o local. Para máxima soberanía: Mistral on-prem o Llama 3 auto-alojado + spaCy interno, cero salida de datos.

¿Hace falta una EIPD para un proyecto de anonimización IA?

Recomendada en la mayoría de casos, obligatoria en varios: volúmenes elevados, datos sensibles (salud, opiniones, biometría según art. 9 RGPD), tratamiento a gran escala, vigilancia sistemática de empleados, cruce de fuentes. La lógica: la anonimización IA es en sí misma un tratamiento automatizado de datos personales, por lo que está sometida al RGPD. La EIPD documenta el riesgo residual tras la seudonimización, justifica las elecciones técnicas y formaliza el control de acceso a la clave de reidentificación. La AEPD publica la lista indicativa de tratamientos que requieren EIPD en aepd.es.

Fuentes: Reglamento (UE) 2016/679 (RGPD), especialmente arts. 4.5 y Considerando 26; LOPDGDD (Ley Orgánica 3/2018), arts. 5, 87-91; Ley 41/2002 de autonomía del paciente; AEPD, «Orientaciones y garantías en los procedimientos de anonimización de datos personales» y «K-anonimato como medida de privacidad»; Dictamen EDPB 28/2024 sobre aspectos de protección de datos en modelos de IA; documentación oficial de spaCy, Microsoft Presidio, GLiNER, BETO-NER, MarIA (Barcelona Supercomputing Center); documentación Mistral AI La Plataforme.

Para enmarcar un proyecto de anonimización por IA en su organización — elección de herramienta, metodología, pipeline, cumplimiento — véase nuestra guía IA conforme al RGPD, nuestra guía EIPD para proyecto IA, nuestra guía LLM local en empresa, o contáctenos vía nuestras soluciones IA a medida.