Copiar la base de clientes parece una forma rápida de probar un sistema. También crea otro lugar donde quedan nombres, contactos, transacciones y observaciones que quizá nadie necesitaba para esa prueba. Los datos de prueba deben permitir comprobar el comportamiento del software con la menor exposición posible. La decisión comienza por definir qué necesita demostrar el equipo, antes de autorizar una extracción desde producción.
Para quien dirige un proyecto tecnológico, la pregunta útil es concreta: ¿necesitamos conocer a las personas o solamente reproducir formatos, relaciones y situaciones? Esa diferencia puede evitar que una validación rutinaria termine dejando información de clientes en computadores de desarrollo, tickets o ambientes de un proveedor.
Datos de prueba según lo que se quiere comprobar
Validar un campo obligatorio, una fecha inválida o una compra sin productos normalmente requiere escenarios definidos, no identidades reales. Probar una integración puede exigir que los registros conserven relaciones entre clientes, pedidos y pagos. Evaluar rendimiento requiere un volumen representativo. Son necesidades distintas y no se resuelven necesariamente con la misma base.
NIST SP 800-188 distingue datos de prueba que respetan estructuras y rangos de aquellos creados para conservar características estadísticas. Los primeros pueden incluir valores extremos útiles para encontrar fallas, sin servir para sacar conclusiones sobre clientes reales. El criterio es elegir información adecuada al objetivo, no asumir que una copia completa siempre entrega una prueba mejor.
Información ficticia no equivale automáticamente a información anónima
Crear registros ficticios desde reglas conocidas puede evitar el uso de antecedentes personales. Por ejemplo, un equipo puede preparar pedidos de distintos tamaños, descuentos y estados sin extraer compras de clientes. Conviene identificarlos claramente como pruebas y evitar que activen correos, cobros o despachos reales.
Otra situación es generar datos sintéticos mediante un modelo construido con información real. NIST advierte que esos modelos y sus resultados pueden revelar información potencialmente reidentificable. La palabra «sintético» no reemplaza la evaluación del método, sus entradas y sus resultados.
Cambiar nombres por códigos tampoco demuestra anonimato. El ICO explica que la identificación depende de más factores que el nombre y del contexto de acceso. Una combinación singular de fechas, ubicaciones y características puede seguir señalando a una persona. Estas referencias aportan criterios técnicos; no se presentan como obligaciones legales chilenas.
Una excepción necesita una necesidad demostrable
Puede existir una falla que el equipo no consiga reproducir con información ficticia. Antes de entregar datos reales, el responsable del proceso debería pedir una explicación del problema, qué campos son indispensables y por qué las alternativas disponibles no bastan. No es necesario convertir cada prueba en un trámite extenso: sí dejar una decisión comprensible y un responsable.
Una autorización acotada debería precisar destinatarios, ambiente, duración y restricciones de uso. Los campos libres, adjuntos y registros de errores merecen atención: pueden conservar detalles personales aunque las columnas principales hayan sido transformadas. El mapa de datos personales ayuda a ubicar esas copias y sus recorridos.
El proveedor y el ambiente también cuentan
Entregar una muestra a un desarrollador externo cambia quién puede verla y dónde permanece. Como criterio de gestión, conviene acordar accesos, almacenamiento autorizado, uso de subcontratistas y destino al terminar. Una carpeta compartida indefinidamente o una copia en un equipo personal puede sobrevivir al proyecto que la justificó.
Los ambientes de prueba deberían tener accesos y credenciales separados de producción. También conviene revisar integraciones salientes y funciones automáticas: una prueba de facturación puede producir consecuencias reales si conserva conexiones operativas. La seguridad por diseño en proyectos tecnológicos permite incorporar estas condiciones antes de aceptar la solución.
Comprobar utilidad y cerrar las copias
Supongamos una empresa chilena que cambia su sistema de pedidos. Negocio define casos como devoluciones parciales, descuentos incompatibles y direcciones incompletas; el equipo prepara registros ficticios para probarlos. Si aparece un error excepcional, se evalúa una muestra mínima y controlada. Es un ejemplo de decisión, no un caso de cliente de AllDefense.
Al cerrar la validación, importa conservar la evidencia del resultado y retirar las copias que ya no se necesitan. La retención de datos personales desarrolla ese criterio. Si la empresa no puede explicar qué información utiliza fuera de producción, el servicio de protección de datos personales de AllDefense ofrece un punto de partida para revisar procesos, riesgos y medidas pertinentes.
Fuentes consultadas
- NIST SP 800-188: técnicas y gobierno de la desidentificación, secciones 4.4.2–4.4.4.
- ICO: evaluación de la efectividad de la anonimización.
