Datos de prueba sin personas reales: por qué lo seudonimizado sigue siendo personal y lo sintético no

Copiar producción es un tratamiento, no un atajo

El reflejo se entiende. Los datos reales tienen la forma que tienen los datos reales: nombres de todas las longitudes, direcciones que no caben en el formulario, pedidos con cuarenta líneas, la clienta cuyo apellido lleva un apóstrofo que lo rompió todo el pasado marzo. Un volcado de producción restaurado es el juego de pruebas de mayor fidelidad que existe, y cuesta un comando. El problema es que ese comando es un tratamiento en sentido jurídico, y el Reglamento tiene algo que decir al respecto.

Dos de los principios del artículo 5 le afectan de forma directa e independiente. La limitación de la finalidad, artículo 5, apartado 1, letra b), exige que los datos personales se recojan con fines determinados, explícitos y legítimos y no se traten ulteriormente de manera incompatible con dichos fines. La dirección se recogió para entregar un pedido. Reproducir un fallo de maquetación no es esa finalidad, y si es compatible con ella es una pregunta real con una respuesta real que alguien tiene que elaborar: el Reglamento da criterios para la evaluación de compatibilidad, no un sí o un no. La minimización, artículo 5, apartado 1, letra c), exige que los datos sean adecuados, pertinentes y limitados a lo necesario en relación con los fines. Una copia íntegra de todos los clientes, para probar una página de pago, es difícil de describir como limitada a lo necesario.

Hay una dimensión práctica que no tiene nada que ver con el derecho y todo que ver con lo que sale mal de verdad. Un entorno de pruebas no tiene los controles de acceso de producción, ni su supervisión, ni sus reglas de retención de copias. Está en un portátil, en un contenedor que alguien levantó, en una instantánea dentro de un bucket que nadie recuerda haber creado. El envío de correo suele seguir configurado, y así fue como una ejecución en preproducción escribió una vez a una lista de clientes reales. La obligación de proteger los datos no se debilita porque la máquina se llame preproducción, y la exposición práctica es mayor ahí que en producción. Los dos argumentos apuntan en la misma dirección.

Lo seudonimizado sigue siendo personal: aquí es donde la gente se equivoca

El artículo 4, apartado 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. Léelo una vez: las palabras decisivas son sin utilizar información adicional. Esa información adicional existe. Se conserva en algún sitio. El vínculo sigue ahí; se ha hecho más difícil de seguir, no se ha eliminado.

El considerando 26 saca la conclusión explícitamente: los datos personales seudonimizados que cabría atribuir a una persona física mediante el uso de información adicional deben considerarse información sobre una persona física identificable. Dicho de otro modo, los datos seudonimizados son datos personales, dentro del ámbito, con todas las obligaciones asociadas: derechos de acceso y supresión, deber de notificación de brechas, reglas de transferencia. Las Directrices 01/2025 del Comité Europeo de Protección de Datos, adoptadas el 16 de enero de 2025, formulan la misma conclusión en su resumen ejecutivo y añaden un punto que conviene retener: vale incluso si los datos seudonimizados y la información adicional no están en manos de la misma persona.

La anonimización es una afirmación distinta y mucho más exigente. El considerando 26 dice que los principios de protección de datos no deben aplicarse a la información anónima, es decir, información que no guarda relación con una persona física identificada o identificable, ni a los datos convertidos en anónimos de forma que el interesado no sea identificable, o deje de serlo. Pero el mismo considerando fija la prueba: para determinar si una persona es identificable deben tenerse en cuenta todos los medios que razonablemente sea probable que se utilicen, considerando factores objetivos como el coste y el tiempo necesarios. Un conjunto donde se han sustituido los nombres pero permanecen códigos postales, fechas de nacimiento e historiales de pedidos suele fallar esa prueba, porque la combinación reidentifica. Una anonimización que aguante el escrutinio suele implicar destruir la propia estructura que el entorno de pruebas debía reproducir.

Los datos sintéticos escapan de todo el razonamiento al no entrar nunca en él. Una fila ensamblada a partir de una lista fija de nombres, una lista fija de apellidos y una lista fija de ciudades no guarda relación con una persona física identificada o identificable, porque no hay ninguna persona detrás ni información adicional que llevara a una. El artículo 4, apartado 1, define los datos personales como toda información sobre una persona física identificada o identificable; si nada se refiere a nadie, la definición no se cumple, y el Reglamento sencillamente no alcanza al conjunto. Sin base jurídica, sin evaluación de compatibilidad, sin plazo de conservación, sin ninguna solicitud de supresión que pueda llegar jamás. Es una diferencia de categoría, y es la razón para generar.

Lo que este generador produce realmente, medido

La herramienta toma de seis conjuntos por país —Francia, Reino Unido, Alemania, España, Italia y Portugal—, cada uno con treinta y dos nombres, treinta y dos apellidos y doce ciudades. Son 192 nombres, 192 apellidos, 72 ciudades y 6144 nombres completos distintos en todo el espacio, y una fila se sostiene: una persona de Lisboa recibe un nombre portugués y una parte local de correo derivada de él, no un apellido alemán sobre un teléfono francés. Medido sobre cuatrocientas tiradas, cien filas dan 99,2 nombres distintos de media y mil filas dan 922,5. El primer nombre repetido aparece hacia la fila 100, que es la cota del cumpleaños sobre un espacio de 6144 y no un defecto.

Las direcciones de correo no colisionan nunca, porque no se dejan al azar. Cada ejecución guarda las partes locales ya repartidas y añade un contador a una repetición: la segunda Marie Martin recibe marie.martin2 como parte local. Diez mil filas dan diez mil direcciones distintas, y doscientas mil dan doscientas mil: medido sobre la función que construye las filas, ya que el formulario se detiene en mil filas por ejecución. El índice UNIQUE que rechazaba la importación a media faena, dejando una tabla a medio llenar, ya no tiene nada que cazar. Conviene conocer dos límites de esa garantía. El contador vive lo que dura una ejecución, así que dos exportaciones separadas todavía pueden repetirse: guarda un juego de datos en un solo archivo, o dale a cada lote su propio prefijo. Y el número de nombres distintos no es el de direcciones distintas: una consulta que cuente clientes por nombre en vez de por dirección llegará algo por debajo de tu número de filas, en torno a un ocho por ciento a mil filas.

Cada dirección termina en example.com, example.net o example.org, y en nada más. Los tres están reservados por la RFC 2606 para servir de ejemplo, y los tres publican un registro MX nulo —el 0 . de la RFC 7505, un dominio que declara en el DNS que no acepta correo alguno—, así que un remitente se detiene antes de abrir una conexión. El emparejamiento de las dos cosas es lo que cuenta, y es más estricto de lo que parece. Un dominio que simplemente no tiene servidor de correo no es seguro: la RFC 5321 hace que el remitente que no encuentra MX recaiga en el registro de dirección, de modo que un dominio con aire de documentación, con un A vivo y sin MX, sigue siendo un destino de entrega. Reservado más MX nulo es lo que cierra la puerta, y es la razón para no inventarse un dominio de ejemplo propio.

La columna de teléfono es el único sitio donde la herramienta responde a una pregunta dejando un campo vacío. Francia reserva números para la ficción: el plan nacional de numeración asigna las raíces 01 99 00, 02 61 91, 03 53 01, 04 65 71, 05 36 49 y 06 39 98 a las obras audiovisuales, y 06 39 98 es la única móvil, así que una fila francesa lleva +33 6 39 98 seguido de cuatro cifras al azar y nada más. Ofcom aparta 07700 900000 a 07700 900999 para la ficción de televisión y radio, de modo que una fila británica lleva +44 7700 900 y tres cifras. La Bundesnetzagentur publicó dos bloques móviles para producciones de medios, 0171 3920000 a 3920099 y 0176 04069000 a 04069099, y una fila alemana sale de uno de ellos. España, Italia y Portugal no publican nada equivalente, así que sus filas salen con el campo de teléfono vacío. Los países se sortean de forma uniforme, lo que significa que alrededor de la mitad de las filas tienen un hueco ahí —49,99 % sobre doscientas mil filas— y una nota bajo el formulario explica por qué, porque una columna vacía sin explicación parece una herramienta rota.

Una regla aplicable, y dónde se detiene

Genera, no copies, y haz que los datos generados sean obviamente falsos. Usa un dominio reservado para cada dirección en vez de una mezcla, pon en la parte local un prefijo que ninguna cuenta real llevaría, y elige una raíz telefónica que tu país reserve para la ficción si es que tiene alguna. Ese «si es que tiene alguna» merece respuesta, porque para la mitad de los mercados de este sitio la respuesta es no. Francia, el Reino Unido y Alemania publican cada uno un bloque; España, Italia y Portugal no publican ninguno. Lo que esos tres tienen en su lugar es espacio sin asignar por ahora, que es una promesa mucho más débil: un regulador que aún no ha repartido un tramo puede repartirlo el año que viene, y un juego de pruebas escrito hoy estaría llamando a alguien. Donde exista un tramo reservado, úsalo; donde no exista, la salida honesta es no poner número, que es lo que hace ahora esta herramienta. La cuestión no es legal —los datos sintéticos quedan fuera del ámbito tengan el aspecto que tengan—, es que una persona que eche un vistazo a un ticket de soporte o a una línea de registro pueda ver en un segundo que la fila no es un cliente. Un dato que parece real se trata como real, y así es como una dirección de prueba acaba en una lista de correo.

Donde la generación se detiene de verdad es en el fallo que solo puedes reproducir con un registro. A veces el defecto está en los datos de ese cliente y en ningún otro sitio, y ninguna fila sintética lo mostrará. Ese caso no se resuelve fingiendo, se resuelve estrechando. Extrae el registro único y no la tabla, coge solo los campos que toca el fallo, trabaja en una máquina con los mismos controles que producción, registra el acceso y bórralo al terminar. Eso es un tratamiento documentado, minimizado y acotado en el tiempo, con una finalidad que puedes escribir, algo completamente distinto de un volcado nocturno a un clúster de preproducción compartido, y es la forma que tu delegado de protección de datos reconocerá, porque es la que el Reglamento está hecho para acomodar.

Preguntas frecuentes

¿Los datos seudonimizados siguen siendo datos personales bajo el RGPD?

Sí. El artículo 4, apartado 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, y el considerando 26 declara que los datos seudonimizados que cabría atribuir a una persona física mediante el uso de esa información adicional deben considerarse información sobre una persona física identificable. El Comité Europeo de Protección de Datos lo reiteró en sus Directrices 01/2025 sobre seudonimización, adoptadas el 16 de enero de 2025, añadiendo que vale incluso cuando los datos seudonimizados y la información adicional no están en manos de la misma persona. La seudonimización es una garantía que el Reglamento fomenta, puede reducir el riesgo y apoyar una evaluación de compatibilidad, pero no saca un conjunto de datos del ámbito de aplicación.

¿Puedo copiar la base de datos de producción a preproducción si la borro después?

Borrarla después no hace lícita la copia; limita cuánto dura el tratamiento, que es otra cuestión. La copia es un tratamiento desde el momento en que ocurre, necesita una base jurídica y tiene que superar la prueba de limitación de la finalidad del artículo 5, apartado 1, letra b): el Reglamento pregunta si el nuevo fin es compatible con aquel para el que se recogieron los datos y da criterios para valorarlo. El artículo 5, apartado 1, letra c), se aplica de forma independiente: llevarse una tabla entera cuando bastarían tres campos no está limitado a lo necesario. Este es exactamente el juicio para el que existe un delegado de protección de datos, y la respuesta depende de tu sector, de tu información de privacidad y de qué estás probando de verdad. Pregunta antes de lanzar la restauración, no después.

¿Los datos sintéticos están realmente fuera del RGPD?

Cuando son genuinamente sintéticos, sí, pero la palabra está trabajando. Los datos ensamblados a partir de una lista fija de palabras, sin ninguna entrada de un registro real, no guardan relación con una persona física identificada o identificable, así que el artículo 4, apartado 1, no se cumple y el Reglamento no se aplica. El considerando 26 dice que los principios de protección de datos no deben aplicarse a la información que no guarda relación con una persona física identificada o identificable. La salvedad es que no todo lo que se llama sintético está construido así: un conjunto generado por un modelo entrenado con registros reales es otra cosa, porque el modelo ha visto los originales y la salida puede retener lo bastante como para aislar a alguien. Si tu generador lee de producción, el análisis empieza otra vez desde cero. Si lee una lista fija de ciento noventa y dos nombres que nunca fueron los de nadie en concreto, no.

¿Se puede entregar algo de verdad a las direcciones de correo generadas?

No, y la razón conviene copiarla en tus propios juegos de datos. Cada dirección usa example.com, example.net o example.org. La RFC 2606 reserva los tres como nombres de ejemplo, así que nadie puede registrar uno y ponerse a recibir correo en él, y los tres publican un registro MX nulo: la forma 0 . definida por la RFC 7505, es decir, un dominio que anuncia en el DNS que no acepta correo. Un remitente conforme lo lee y se detiene sin abrir conexión. El emparejamiento importa: un dominio sin MX no es equivalente, porque la RFC 5321 hace que el remitente recaiga en el registro de dirección, de modo que un dominio verosímil que resuelve pero no tiene servidor de correo sigue siendo un destino de entrega. Si escribes tu propio generador, coge los nombres reservados en lugar de inventarte uno que parezca reservado, y bloquea además el correo saliente a nivel de entorno, cosa que deberías estar haciendo igualmente.

¿Cuántas filas puedo generar antes de que se repitan los nombres?

Los nombres empiezan a repetirse hacia la fila 100; las direcciones de correo, nunca. Los conjuntos tienen treinta y dos nombres y treinta y dos apellidos para cada uno de los seis países, o sea 6144 nombres completos distintos, y la cota del cumpleaños sobre un espacio de ese tamaño sitúa la primera colisión en torno a cien extracciones, medida en 99,6 sobre tres mil ejecuciones. Con cien filas obtienes 99,2 nombres distintos de media; con mil filas, 922,5. Las direcciones son otra cosa: a un nombre repetido se le añade un contador en la parte local, así que diez mil filas dan diez mil direcciones distintas y un índice UNIQUE sobre la columna de correo no tiene nada que rechazar. Un límite a eso: el contador vale para una ejecución, y el formulario genera como mucho mil filas de una vez, así que si necesitas más, vuelve a lanzarlo con otra semilla y añade tu propio prefijo por lote en vez de dar por hecho que las dos exportaciones no pueden solaparse.