Anonimización, tokenización y cifrado en IA: qué técnica usar según el RGPD
Anonimización, tokenización y cifrado no son lo mismo. Esta guía explica cada técnica, en qué se diferencian, cuándo usar cada una y qué dice el RGPD sobre ellas para proteger datos personales en aplicaciones de IA.
- Anonimización, tokenización y cifrado son tres técnicas distintas con implicaciones legales diferentes bajo el RGPD. Confundirlas puede costarte una sanción
- La anonimización es irreversible: si está bien hecha, el resultado no es dato personal y el RGPD deja de aplicar. Pero es difícil de hacer bien y destruye información útil para la IA
- La tokenización es reversible pero con control: los tokens solo pueden revertirse con una clave que permanece separada. El RGPD la reconoce como seudonimización (Art. 4.5)
- El cifrado protege en tránsito o en reposo pero el dato se desencripta para usarlo. Es necesario pero no suficiente para cumplir con la minimización de datos
- Para aplicaciones de IA, la tokenización antes del envío al proveedor es la técnica que mejor equilibra protección, cumplimiento normativo y utilidad del dato
Si trabajas con datos personales y los envías a un proveedor de IA, has oído estos tres términos en reuniones de compliance: anonimización, tokenización, cifrado. Y probablemente los has visto usados como si fueran sinónimos. No lo son. Y confundirlos tiene consecuencias legales.
Esta guía explica qué hace cada técnica, en qué se diferencian, qué dice el RGPD sobre cada una, y —lo más importante— cuál deberías usar según tu caso de uso con IA.
Si necesitas el marco legal completo sobre IA y RGPD, empieza por aquí: RGPD e Inteligencia Artificial: guía completa 2026. Y si lo que buscas es una checklist práctica de cumplimiento, tenemos esta: Checklist de cumplimiento normativo IA para DPOs.
Aviso: esta guía explica conceptos técnicos y su relación con el RGPD. No es asesoramiento jurídico. La decisión sobre qué técnica es adecuada para tu caso concreto debe ser validada por tu DPO o asesoría legal.
Las tres técnicas, en una tabla
| Anonimización | Tokenización | Cifrado | |
|---|---|---|---|
| ¿Qué hace? | Elimina permanentemente los identificadores | Reemplaza identificadores por tokens con una tabla de correspondencia separada | Convierte datos en texto ilegible mediante un algoritmo y una clave |
| ¿Es reversible? | No, por definición. Si se puede revertir, no es anonimización | Sí, con acceso a la tabla de correspondencia | Sí, con la clave de descifrado |
| ¿El resultado es dato personal? | No (si está bien hecha) | No para quien no tiene la tabla. Sí para quien la tiene | Sí. El dato original se recupera al descifrar |
| ¿El RGPD aplica al resultado? | No | Solo para quien custodia la tabla de correspondencia | Sí, plenamente |
| ¿La IA puede trabajar con ello? | Pierde información útil (nombres, fechas, referencias) | Sí, el modelo razona sobre tokens sin perder estructura | Sí, pero el proveedor ve el dato real |
| ¿Protege contra el proveedor de IA? | Sí, pero destruye utilidad | Sí, el proveedor solo ve tokens | No, el proveedor descifra y ve el dato original |
| Complejidad de implementación | Alta (requiere verificación de irreversibilidad) | Baja (una línea de código con proxy) | Media (gestión de claves) |
| Uso típico | Datasets públicos, estadísticas agregadas | Envío de prompts a proveedores de IA, procesamiento de pagos | Datos en tránsito (TLS), datos en reposo (discos, backups) |
Anonimización: el ideal que casi nunca se alcanza
La anonimización es el santo grial de la protección de datos: si consigues que los datos sean verdaderamente anónimos, el RGPD deja de aplicar. No hay dato personal, no hay obligación. Fácil, ¿no?
No. La anonimización bien hecha es sorprendentemente difícil.
Lo que dice el RGPD
El Considerando 26 establece que los principios de protección de datos no se aplican a la información anónima, es decir, información que no guarda relación con una persona física identificada o identificable. Pero añade una precisión crucial: para determinar si una persona es identificable, deben tenerse en cuenta «todos los medios que razonablemente pueda utilizar el responsable del tratamiento o cualquier otra persona para identificar directa o indirectamente a la persona física».
Traducción: no basta con quitar el nombre. Si alguien con acceso a otros datos puede reconstruir la identidad, no es anonimización.
El problema con la IA
Imagina que quieres enviar este prompt a OpenAI para que analice un caso clínico:
«Paciente varón, 62 años, diagnosticado con diabetes tipo 2 en 2019. Residente en Soria. Tratamiento actual: metformina 850mg/12h. Última HbA1c: 7.2%.»
Has quitado el nombre. Has quitado el número de historia clínica. ¿Está anonimizado?
No necesariamente. «Varón, 62 años, diabetes tipo 2, Soria» es suficiente para que alguien con acceso al censo de Soria, a los registros de la clínica local o incluso a otras fuentes públicas pueda reidentificar a esa persona. La combinación de atributos (edad, sexo, localidad pequeña, condición médica) crea un cuasi-identificador.
Este es el problema de la anonimización en la práctica: el riesgo de reidentificación nunca es cero, y demostrar que es suficientemente bajo requiere un análisis estadístico que la mayoría de las empresas no tienen capacidad de hacer.
Para la IA, además, la anonimización destruye información que el modelo necesita. «Paciente [ANONIMIZADO] de [ANONIMIZADO] años, residente en [ANONIMIZADO]» no le sirve al modelo para razonar sobre patrones clínicos reales.
Tokenización: el equilibrio que el RGPD reconoce
La tokenización (o seudonimización en la terminología del RGPD) ocupa el punto dulce: protege los datos sin destruir su utilidad, y el RGPD la reconoce explícitamente como medida técnica válida.
Lo que dice el RGPD
El Artículo 4(5) define la seudonimización 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 destinadas a garantizar que los datos personales no se atribuyan a una persona física identificada o identificable.»
Cada palabra de esta definición importa:
- «sin utilizar información adicional»: los tokens por sí solos no revelan la identidad
- «figure por separado»: la tabla de correspondencia no viaja con los datos
- «medidas técnicas y organizativas»: la tabla debe estar protegida
- «no se atribuyan»: el objetivo es que quien recibe los tokens no pueda atribuirlos a una persona
Cómo funciona en la práctica
Antes de tokenizar:
«El paciente Juan García (DNI 12345678A, tfno. 666111222)
presenta niveles elevados de glucosa.»
Después de tokenizar:
«El paciente [PERSONA_1] (DNI [DNI_1], tfno. [TEL_1])
presenta niveles elevados de glucosa.»El proveedor de IA recibe [PERSONA_1]. Puede razonar sobre el contexto clínico, generar una respuesta, y devolverla con los tokens intactos. Tu infraestructura restaura los valores originales antes de mostrar la respuesta al usuario.
La diferencia clave con la anonimización
La tokenización no pretende que los datos sean anónimos para siempre. Pretende que no sean identificables para quien los recibe. El RGPD no exige que los datos sean anónimos; exige que solo puedan ser identificados por quien tiene legitimidad para hacerlo y bajo las salvaguardas adecuadas.
Y aquí está el matiz legal más potente: si quien recibe los datos (el proveedor de IA) no tiene acceso a la tabla de correspondencia y no puede reidentificar a los interesados por otros medios, los tokens que recibe no son datos personales para ese receptor. No porque estén anonimizados, sino porque el receptor no puede atribuirlos a una persona física concreta.
Esto cambia completamente la ecuación de compliance: las restricciones de transferencia internacional (Capítulo V del RGPD) aplican a datos personales. Si lo que cruza la frontera no es dato personal para quien lo recibe, el Capítulo V no se activa.
Cifrado: necesario pero no suficiente
El cifrado convierte datos legibles en texto ilegible mediante un algoritmo y una clave. Es la técnica más ubicua: TLS cifra tus datos en tránsito, el cifrado de disco protege el reposo. Sin cifrado, nada de lo demás importa.
Pero el cifrado tiene una limitación fundamental para el caso de uso de IA: para procesar el dato, hay que descifrarlo. Cuando tu aplicación envía un prompt a OpenAI por HTTPS, los datos viajan cifrados (TLS 1.3). Pero llegan a los servidores de OpenAI, se descifran, se procesan en texto plano, y el proveedor ve el dato original.
El cifrado protege contra un atacante en la red (nadie puede interceptar el prompt en tránsito). No protege contra el proveedor que recibe el dato. Y el proveedor es precisamente el riesgo que el RGPD te pide gestionar.
Dónde encaja el cifrado
| Capa | Técnica recomendada |
|---|---|
| Datos en tránsito hacia el proveedor | TLS 1.3 (obligatorio) |
| Tabla de correspondencia de tokenización | Cifrado en reposo + control de acceso |
| Logs de auditoría | Cifrado en reposo + retención limitada |
| Canal de gestión (API de configuración) | TLS 1.3 + autenticación por API key |
El cifrado es la base. Pero no sustituye a la tokenización, igual que el cinturón de seguridad no sustituye al airbag: son capas complementarias.
Cuándo usar cada técnica
| Caso de uso | Técnica recomendada | Por qué |
|---|---|---|
| Enviar prompts con datos personales a OpenAI, Claude o Gemini | Tokenización antes del envío | El proveedor no recibe datos identificables. El modelo mantiene la capacidad de razonar |
| Datos de categoría A (secreto profesional, propiedad intelectual) | No enviar. Modelo local en el edge | La tokenización no basta: el contenido es confidencial por categoría, no por identificabilidad |
| Datasets para entrenamiento de modelos internos | Anonimización verificada | Los datos no deben permitir reidentificación por ningún medio razonable |
| Almacenamiento de logs y auditoría | Cifrado en reposo + tokenización de PII en logs | Minimiza exposición incluso en caso de brecha |
| Tráfico de red entre tu infraestructura y el proveedor | Cifrado (TLS 1.3) | Protección mínima exigible contra interceptación |
Cómo implementar tokenización sin montar tu propia infraestructura
La tokenización suena compleja: necesitas un detector de PII, un generador de tokens, una tabla de correspondencia segura, y un proxy que intercepte las llamadas a la API. Y sí, construir eso desde cero es un proyecto de semanas.
Privedge empaqueta todo eso en un proxy que se despliega en minutos:
// Sin Privedge: el proveedor recibe datos personales reales
const openai = new OpenAI({ apiKey: process.env.OPENAI_KEY })
// Con Privedge: el proveedor recibe tokens
const openai = new OpenAI({
apiKey: process.env.OPENAI_KEY,
baseURL: 'https://api.privedge.io/v1',
defaultHeaders: { 'X-Privedge-Key': process.env.PRIVEDGE_KEY },
})La detección de PII se ejecuta en el edge de Cloudflare, la tabla de correspondencia se almacena en el nodo más cercano a tu infraestructura, y el proveedor de IA nunca ve los datos originales. Tokenización, cifrado y minimización en una línea de código.
Si quieres entender el marco legal completo antes de decidir qué técnica implementar, aquí tienes la guía: ¿Es legal usar ChatGPT en tu empresa? Lo que dice la AEPD sobre privacidad y RGPD. Y si ya lo tienes claro y necesitas una checklist de compliance, usa esta: Cumplimiento normativo IA: checklist para DPOs.
¿Necesitas usar IA en tu empresa?
Hazlo con el RGPD cubierto y respetando el anonimato de tus clientes.
Guía completa
IA conforme con el RGPD