GDPR y datos de identidad de prueba es una combinación que muchos equipos resuelven tarde, cuando alguien pregunta de dónde salieron los nombres que aparecen en la base de datos de desarrollo. La respuesta habitual es que se copiaron de producción hace años y que nadie los ha tocado desde entonces. Esta guía explica por qué esa copia es un problema, qué diferencia hay entre las técnicas que prometen resolverlo y qué se puede hacer en su lugar.
Qué cuenta como dato personal en un registro de identidad
Un registro de identidad está formado casi por completo por datos personales. El nombre, el número de documento, la fecha de nacimiento, la dirección postal, el teléfono y el correo electrónico identifican a una persona, y lo hacen por separado o en conjunto. No hace falta que vayan acompañados de un número de expediente para serlo.
Incluso los campos que parecen inocuos pueden serlo. Una dirección con su código postal, combinada con una fecha de nacimiento y una profesión, reduce muchísimo el conjunto de personas a las que puede referirse el registro. La protección no depende de que el nombre esté presente, sino de que el conjunto permita llegar hasta alguien.
¿Por qué los entornos de prueba no deberían guardar datos reales?
Porque multiplican los lugares donde vive el dato. Un entorno de desarrollo suele estar peor protegido que el de producción: menos controles de acceso, más personas con permiso, copias en equipos portátiles y volcados que se comparten para reproducir una incidencia. Cada uno de esos movimientos amplía la superficie expuesta sin que nadie haya decidido exponerla.
A eso se añade el paso del tiempo. La copia se hizo para un problema concreto que ya se resolvió, pero el entorno sigue ahí y el dato también. Los principios habituales de protección de datos hablan de limitar la finalidad, recoger lo mínimo, mantener la exactitud y no conservar más de lo necesario; una copia de producción que nadie recuerda haber hecho incumple esos principios sin que medie mala intención. Los detalles sobre el tratamiento de direcciones y teléfonos están en la guía sobre privacidad de los datos de dirección.
¿Qué diferencia hay entre pseudonimizar y anonimizar?
Pseudonimizar consiste en sustituir los identificadores directos por otros, pero conservando la posibilidad de volver al original. Los datos siguen siendo personales: basta con tener la tabla que relaciona ambos valores. Enmascarar es una variante de lo mismo, porque los valores ocultos pueden recuperarse si el enmascaramiento es reversible.
Anonimizar consiste en romper el vínculo de forma que no se pueda reconstruir por ningún medio razonable. Es un listón alto. Cambiar los nombres por otros inventados no basta si se conservan la fecha de nacimiento exacta, el código postal y la profesión, porque esa combinación puede señalar a una sola persona. Por eso conviene desconfiar de cualquier procedimiento que se anuncie como anonimización y consista únicamente en borrar el nombre. La comparación completa está en la guía sobre datos sintéticos y datos anonimizados.
Minimizar y no conservar más de lo necesario
Si el entorno de pruebas necesita una identidad para funcionar, casi nunca necesita la identidad completa. La pregunta útil no es qué campos se pueden ocultar, sino cuáles hacen falta de verdad para la prueba que se va a ejecutar. Un formulario que valida longitudes no necesita nombres auténticos, solo cadenas de la longitud adecuada.
La segunda pregunta es cuánto tiempo hace falta conservarlo. Un conjunto de datos que se regenera cuando se necesita no acumula registros antiguos ni crece con cada copia. Ese planteamiento encaja además con el funcionamiento normal del desarrollo, donde los entornos se reconstruyen con frecuencia.
Cómo llenar un entorno de pruebas sin datos personales
La solución más limpia es no partir de personas reales. En el generador de datos de identidad de este sitio se construyen registros completos a partir de un país y una división administrativa, con nombre, dirección, documento, teléfono y perfil en línea que no pertenecen a nadie. Como el material no deriva de ningún dato existente, desaparece la discusión sobre qué se hizo con el original.
Para equipos que prefieren fijar las muestras en lugar de generarlas, la guía sobre identidades en ficheros de prueba explica cómo organizarlas y cómo evitar que envejezcan mal.
Notas para quien programa
- Separa los entornos de verdad, no solo de nombre. Si la base de datos de desarrollo se restaura desde producción, todo lo anterior se pierde. La separación tiene que incluir el procedimiento de carga, no solo la dirección del servidor.
- No copies datos de producción para reproducir una incidencia. Casi siempre basta con reproducir la forma del registro, no su contenido. Si de verdad hace falta el dato original, tiene que haber una justificación escrita y un plazo.
- Revisa los registros de actividad y las capturas. El nombre y el documento aparecen en trazas, volcados de error y capturas que se adjuntan a incidencias. Los datos personales se filtran por ahí tanto como por la base de datos.
- No confundas enmascarar con anonimizar. Un campo oculto que se puede recuperar sigue siendo un dato personal. Tratarlo como anónimo relaja la protección sin reducir el riesgo.
- Documenta de dónde sale cada conjunto de datos. El registro de origen es lo que permite responder en una revisión interna y lo que evita que en dos años nadie sepa si esos nombres son reales o inventados.
Siguientes pasos
Comprueba hoy si el entorno de desarrollo de tu equipo contiene algún registro procedente de producción. Si lo contiene, sustitúyelo por material generado y anota la decisión: es una tarea corta con un efecto duradero.
Para generar los registros que ocupen ese hueco, el generador de datos de identidad devuelve identidades completas y reproducibles. Ese material es solo para pruebas de software, no corresponde a ninguna persona real y no sirve para hacerse pasar por otra ni para acreditar una identidad ante un tercero.