La seudonimización conserva la utilidad del dato: integridad referencial entre tablas, comportamiento equivalente al de producción, capacidad de realizar joins y análisis. La anonimización elimina esa trazabilidad de forma irreversible.
La elección entre una y otra depende del caso de uso. Cuando se requiere que un entorno de QA o staging se comporte de forma equivalente a producción sin exponer datos reales, la seudonimización es la opción técnicamente adecuada. Cuando el dataset va a publicarse o transferirse sin restricciones de acceso, la anonimización completa es el estándar aplicable.
Qué técnicas de seudonimización existen
La técnica adecuada depende del tipo de dato, del nivel de consistencia requerido y del perfil de riesgo de reidentificación que se quiere mitigar.
Cifrado determinista
Un mismo valor de entrada produce siempre el mismo seudónimo. Si el DNI 12345678A se transforma en X9F3K2, ese mismo DNI generará X9F3K2 en cualquier tabla y en cualquier ejecución posterior.
Es la técnica más adecuada para bases de datos relacionales: el ID de cliente en la tabla de pedidos sigue correspondiendo al mismo registro en la tabla de clientes, aunque ninguna de las dos contenga datos reales. Garantiza la integridad referencial sin exponer identidades.
Tokenización
El dato original se sustituye por un token —un identificador sin valor propio— y la correspondencia se almacena en un repositorio separado y controlado. El sistema que procesa los datos opera únicamente con el token; el dato real permanece en un entorno con acceso diferenciado.
Es el método habitual para números de tarjeta en el sector financiero, pero su aplicación se extiende a cualquier identificador personal.
Hashing con salt
El dato pasa por una función hash que genera un valor de longitud fija. El salt —un valor aleatorio incorporado antes de aplicar la función— evita que dos registros con el mismo dato original generen el mismo hash, bloqueando ataques por diccionario o tablas arcoíris.
A diferencia del cifrado determinista, el hashing no tiene reversión directa. Se combina con otras técnicas cuando se requiere la posibilidad de reconstruir la identidad original bajo condiciones controladas.
Generalización y supresión
Una fecha de nacimiento exacta se convierte en un rango de edad. Un código postal se trunca a los primeros dígitos. Un identificador nominal se elimina y se sustituye por un ID numérico.
Estas técnicas reducen la precisión del dato sin sustituirlo por un equivalente funcional. Son adecuadas para análisis estadísticos donde el análisis opera sobre distribuciones agregadas, no sobre registros individuales.
Entornos de prueba y exposición de datos personales
Los entornos no productivos —desarrollo, QA, staging— concentran un riesgo de exposición que con frecuencia no recibe el mismo tratamiento que los sistemas de producción. Estos entornos suelen contener réplicas de datos reales, con accesos más amplios que facilitan la depuración, controles de auditoría menos exhaustivos y, en muchos casos, conexiones a herramientas o proveedores externos.
El RGPD no establece distinción entre tipos de entorno: si un entorno de QA contiene datos personales reales, aplican las mismas obligaciones que en producción, incluidas la base legal de tratamiento, la minimización y las medidas de seguridad técnica del artículo 32.
Los estándares técnicos complementarios de DORA van en la misma dirección: los entornos no productivos deben contener únicamente datos anonimizados, seudonimizados o aleatorizados. El uso de datos de producción sin transformar se contempla como excepción acotada, sujeta a gobernanza explícita, aprobación documentada y plazo definido.
Aplicar seudonimización antes de poblar estos entornos elimina la exposición desde el origen. Los equipos de desarrollo y QA trabajan con datos que se comportan de forma equivalente a los reales, sin que ningún dato personal salga del entorno productivo sin transformación previa.
Qué requisitos técnicos debe cumplir una implementación de seudonimización
Una seudonimización incorrectamente implementada genera una exposición residual que puede no ser evidente hasta que ocurre un incidente. Tres requisitos condicionan su efectividad:
Separación de la clave de reversibilidad. El mapa entre datos originales y seudónimos no puede residir en el mismo sistema que los datos transformados. Si un atacante accede simultáneamente a ambos, la protección queda anulada. La clave debe almacenarse en un repositorio independiente, con acceso basado en roles y registro de auditoría de cada consulta.
Trazabilidad auditable. Cada operación —seudonimización, reversión, entrega a un entorno— debe quedar registrada: qué se ejecutó, quién lo autorizó, cuándo y bajo qué justificación. Sin este registro no es posible demostrar control ante una auditoría interna ni ante la AEPD en caso de inspección.
Consistencia determinística. El mismo campo debe producir siempre el mismo seudónimo en todos los sistemas y ejecuciones. Si el ID de cliente CL-001 genera X9F3 en la base de datos principal y A2B7 en el sistema de facturación, los entornos de prueba presentarán comportamientos divergentes respecto a producción, lo que invalida la utilidad de los tests.
Seudonimización y RGPD: artículos aplicables
Tres artículos del RGPD son directamente relevantes para la aplicación de seudonimización en entornos empresariales:
Artículo 25 (privacidad desde el diseño): la seudonimización se cita como ejemplo de medida técnica para aplicar protección de datos por defecto desde las fases iniciales del ciclo de desarrollo.
Artículo 32 (seguridad del tratamiento): incluye la seudonimización entre las medidas técnicas adecuadas para garantizar un nivel de seguridad proporcional al riesgo del tratamiento.
Artículo 34 (notificación a los interesados): cuando los datos afectados por una brecha estaban seudonimizados con claves inaccesibles para el atacante, puede no ser exigible la notificación individual a los afectados. Esto limita de forma significativa el impacto reputacional y operativo de un incidente de seguridad.
El dato seudonimizado sigue siendo un dato personal bajo el RGPD mientras exista la clave de reversibilidad. Únicamente cuando esa clave se destruye de forma irreversible el dato deja de estar sujeto al ámbito de aplicación del reglamento.
Preguntas frecuentes sobre seudonimización
¿La seudonimización es suficiente para cumplir el RGPD?
No de forma autónoma. Es una medida técnica reconocida y recomendada por el RGPD, pero requiere complementarse con control de acceso a la clave de reversibilidad, trazabilidad de operaciones y separación física entre el repositorio de reversión y los datos transformados.
¿Los datos seudonimizados son datos personales?
Sí, mientras exista la clave de reversibilidad. Es lo que los distingue de los datos anonimizados. El RGPD les aplica con la misma intensidad que a los datos no transformados.
¿Qué es la seudonimización según el RGPD?
El RGPD define la seudonimización en el artículo 4(5) como el tratamiento de datos personales de manera 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.
¿Qué diferencia hay entre seudonimización estática y dinámica?
La seudonimización estática transforma el dato antes de almacenarlo o entregarlo —es la modalidad habitual en entornos de prueba y staging. La dinámica aplica la transformación en el momento de la consulta, sin modificar el dato en origen; se utiliza principalmente para controlar accesos en producción sin alterar la base de datos subyacente.
¿Es posible usar datos seudonimizados para entrenar modelos de inteligencia artificial?
Depende del nivel de riesgo de reidentificación y de la finalidad del tratamiento. El RGPD exige una base legal compatible con la finalidad original de recogida. En tratamientos internos de análisis y entrenamiento, la seudonimización es habitualmente suficiente; cuando el dataset se publica o se transfiere de forma amplia, la anonimización es el estándar aplicable.
