Cómo preparar datos de prueba sin copiar información real a desarrollo
La opción más prudente para probar una aplicación suele ser generar datos sintéticos desde cero. Cuando no reproducen la variedad necesaria, puede transformarse un conjunto controlado y evaluar el riesgo de identificación. Copiar producción completa a desarrollo amplía accesos, duplica datos sensibles y hace difícil saber dónde quedan copias.
Lo esencial, antes de empezar
- Los datos de prueba deben parecerse al negocio en estructura y comportamiento, no en identidades.
- Sintético, anónimo, seudónimo y enmascarado describen resultados y riesgos diferentes.
- Transformar datos reales sigue requiriendo un entorno controlado y una evaluación del riesgo residual.
- Utilidad de prueba e identificación se validan por separado y se revisan cuando cambia el contexto.
Distingue sintético, anónimo, seudónimo y enmascarado
La Comisión Europea recuerda que los datos seudonimizados siguen siendo personales cuando pueden atribuirse de nuevo mediante información adicional. La FAQ de la AEPD sobre datos anonimizados explica que los datos anónimos quedan fuera del RGPD cuando la persona deja de ser identificable y que debe descartarse una probabilidad razonable de identificación en el conjunto.
| Tipo | Origen | Punto de control |
|---|---|---|
| Sintético | Generado sin copiar registros reales | Que no coincida con personas y cubra escenarios |
| Anonimizado | Datos reales transformados | Identificación no razonablemente posible en el contexto |
| Seudonimizado | Identificadores sustituidos con posible revinculación | Sigue siendo dato personal y exige protección |
| Enmascarado | Parte oculta para una vista o uso | No llamarlo anónimo sin evaluar el conjunto |
Usa las guías con su autoría y contexto correctos
La Guía básica de anonimización publicada en español por la AEPD es una traducción autorizada de la guía elaborada por la Personal Data Protection Commission de Singapur (PDPC), como explica el prólogo de la propia AEPD. La versión original actualizada de PDPC propone conocer los datos, desidentificar, aplicar técnicas, calcular riesgos y gestionarlos.
PDPC incluye un caso de datos ficticios para desarrollo y pruebas en el que los registros finales no coinciden con personas del origen. También aclara que otro enfoque es generar un conjunto sintético desde cero. Se usa aquí como guía técnica de riesgo y utilidad, no como norma española ni como acreditación de cumplimiento.
Empieza por el catálogo de escenarios
Pregunta qué debe comprobar el equipo antes de transformar una base. Facturación puede necesitar tipos impositivos, redondeos, series y abonos; reservas, solapamientos, zonas horarias y cancelaciones. Miles de clientes reales no aportan valor si ninguno representa el caso que rompe una regla.
| Escenario | Datos necesarios | Resultado esperado |
|---|---|---|
| Cliente nuevo | Identificador ficticio, dominio reservado, país | Alta única |
| Clave repetida | Dos registros sintéticos con la misma clave | Rechazo o fusión según regla |
| Texto diverso | Acentos, guion y longitud límite | Conservación correcta |
| Pedido sin stock | Producto ficticio y cantidad superior | Estado de excepción |
| Proveedor lento | Respuesta simulada con demora | Reintento o aviso sin duplicar |
Versiona este catálogo junto a las pruebas. La guía para definir un MVP con criterios de aceptación ayuda a convertir cada escenario en entrada, acción y resultado esperado.
Si transformas datos reales, inventaría antes de mover
- Identificadores directos: nombre, email, teléfono y documento.
- Identificadores indirectos: fecha exacta, código postal, puesto y combinaciones raras.
- Información sensible o confidencial.
- Claves técnicas necesarias para mantener relaciones.
- Texto libre, imágenes, adjuntos y metadatos.
- Copias, temporales, destinatarios y fecha de eliminación.
Eliminar el nombre no basta si una combinación permite reconocer a alguien. Asigna identificadores nuevos y conserva relaciones entre cliente, pedido y líneas. Si existe un mapa que permite volver al origen, mantenlo separado y protegido; el conjunto es seudonimizado mientras la revinculación siga siendo posible.
Genera emails en dominios reservados como example.com y datos claramente ficticios. Evita que el azar cree una combinación real. Para una integración, conserva formatos, claves y sumas necesarias, no identidades.
Aísla la transformación y valida dos resultados
La transformación inicial todavía trata datos reales. Ejecútala en un entorno controlado con acceso limitado, registro de ejecuciones y borrado de temporales. No envíes una copia sin transformar a un proveedor para que la anonimice en un entorno no acordado.
- 01
Utilidad
Comprueba relaciones, formatos, distribuciones necesarias y casos límite.
- 02
Identificación
Evalúa si alguien con el conjunto y fuentes razonablemente disponibles puede identificar personas.
- 03
Acceso
Define destinatarios, entorno, exportación y controles adicionales.
- 04
Vigencia
Repite la evaluación al cambiar fuentes, técnicas, destinatarios o contexto.
El ICO recomienda evaluar eficacia en función de destinatario, información adicional y medios razonablemente disponibles en su guía sobre cómo comprobar la anonimización. Esa orientación técnica no sustituye el marco aplicable en España.
Entrega un conjunto reproducible, no una copia de producción
- Escenarios y campos necesarios definidos.
- Datos sintéticos preferidos cuando son suficientes.
- Identificadores directos, indirectos y texto libre revisados.
- Relaciones y sumas de negocio coherentes.
- Sin secretos, tokens ni credenciales reales.
- Transformación controlada y temporales eliminados.
- Conjunto sintético comprobado frente a coincidencias reales.
- Propietario, versión, accesos y fecha de eliminación documentados.
- Clasificación como anónimo o seudónimo revisada.
NAS Solutions puede incorporar generadores, escenarios, validaciones y entornos separados al desarrollo de una app a medida. Si los datos cruzan sistemas, documenta qué fuente manda y revisa la guía para integrar CRM y ERP con una fuente de verdad. El resultado útil permite encontrar errores sin exponer información innecesaria.
Para aceptar la entrega, ejecuta el mismo generador dos veces con una semilla controlada y comprueba que el equipo puede reproducir un fallo. Después prueba la eliminación del conjunto y sus temporales. Registra versión del esquema, versión del generador y catálogo cubierto para distinguir un defecto de aplicación de un cambio accidental en los datos de prueba.
Fuentes y referencias
Documentación oficial y referencias de mercado consultadas para verificar los puntos que cambian con el tiempo.
- Guía básica de anonimización, traducción al español de la guía de PDPC — AEPD (traducción y publicación); PDPC Singapur (autoría original)
- A Guide to Basic Anonymisation — Personal Data Protection Commission Singapore
- ¿Los datos anonimizados son datos personales? — AEPD
- How do we ensure anonymisation is effective? — Information Commissioner's Office
