Por qué los datos de producción no deben estar en sistemas de prueba
Los datos personales solo pueden tratarse para la finalidad para la que se obtuvieron o para una finalidad compatible con ella (art. 6 apdo. 3 LPD, art. 5 apdo. 1 letra b RGPD). Probar software a menudo no es compatible sin más con esa finalidad.
A ello se suma la seguridad: los entornos de prueba suelen estar menos protegidos, más personas tienen acceso y colaboran desarrolladores externos. La protección de datos desde el diseño (art. 7 LPD, art. 25 RGPD) exige reducir estos riesgos de antemano con medidas adecuadas.
¿Qué métodos existen?
| Método | Resultado | Indicado para |
|---|---|---|
| Enmascarar | Los datos se hacen irreconocibles. | Visualización de documentos, formación |
| Valores sustitutos con formato válido | Valores realistas; las validaciones y las interfaces siguen funcionando. | Sistemas de prueba, pruebas de integración |
| Seudonimizar | Es posible volver a la persona con la correspondencia. | Análisis con consulta posterior, búsqueda de errores |
| Datos sintéticos | Generados sin relación con personas reales. | Desarrollo temprano, pruebas de carga |
Lo que importa en los datos de prueba
- Formato válido: identificadores como el IBAN o el número AVS superan las validaciones de la aplicación.
- Coherencia: la misma persona recibe el mismo valor sustituto en los datos relacionados.
- No olvidar el texto libre: los nombres suelen aparecer en campos de observaciones y en documentos.
- Control posterior: comprobar si en el resultado quedan datos sin proteger.
- Prueba: dejar constancia de quién ha recibido qué datos de prueba y para qué.
Ceder datos vinculados a una finalidad
Lo que vale para los datos de prueba vale para cualquier cesión: a equipos de análisis, a proveedores de servicios o a una IA. El principio es ceder solo el vínculo con personas que exija la finalidad, y registrar para cada destinatario y finalidad qué se ha cedido.