La privacidad de los datos de dirección se trata a menudo como un asunto secundario frente a otros datos más delicados, y es un error de apreciación. Una dirección completa identifica a una persona o, como mínimo, a un domicilio concreto, y esa capacidad de identificar es exactamente lo que convierte un dato en personal. A partir de ahí se aplican principios que no dependen del tamaño del sistema: recoger lo necesario, conservarlo el tiempo justo y no exponerlo donde no hace falta.
Por qué una dirección es un dato personal
Un nombre suelto es ambiguo; una dirección asociada a un nombre es única en la práctica. La combinación de calle, número, unidad, ciudad y código postal reduce el conjunto de personas posibles a un número muy pequeño, y en muchos casos a una sola. Eso basta para que la dirección esté sujeta a las mismas obligaciones que cualquier otro dato que permita identificar a alguien.
Hay una segunda consideración que se pasa por alto: la dirección revela información indirecta. Un domicilio puede sugerir una situación económica, una zona de residencia o la presencia de una familia. No hace falta deducir nada de eso para que el dato esté protegido, pero conviene tenerlo presente a la hora de decidir quién puede verlo y con qué finalidad.
¿Cuánto tiempo se debe conservar una dirección?
El principio general es que se conserva mientras exista una finalidad que lo justifique y se elimina cuando esa finalidad desaparece. En la práctica, la dirección suele estar vinculada a un pedido, a una factura o a un contrato, y la obligación de conservar esos documentos marca el plazo. Lo que no está justificado es mantener copias de la dirección en sitios que no tienen ninguna obligación de conservarla.
Ahí es donde aparecen los problemas reales. La dirección acaba copiada en un registro de aplicación, en un fichero de depuración, en una copia de seguridad de pruebas y en un cuaderno de seguimiento que alguien usó una vez para investigar una incidencia. Cada una de esas copias es un tratamiento distinto, con su propia finalidad y, a menudo, sin ninguna necesidad.
Conviene por tanto hacer un inventario de dónde vive la dirección y eliminar las copias que no responden a una finalidad concreta. Es más eficaz que cualquier política escrita que nadie aplica.
¿Se pueden usar direcciones reales para probar?
No, y es una de las decisiones con más consecuencias prácticas de todo este artículo. Usar la dirección de un cliente real en un entorno de pruebas significa sacar un dato personal de su contexto, ampliar el número de personas con acceso a él y, en muchos casos, dejarlo en un sistema que no tiene los mismos controles que producción.
La costumbre de copiar registros reales suele justificarse por la necesidad de que los datos «parezcan reales». Es una necesidad legítima que se resuelve generando datos que tengan la misma forma sin pertenecer a nadie. El generador de direcciones falsas produce direcciones completas por país con ese propósito, y son solo para pruebas de software: no corresponden a ninguna vivienda ni destinatario real y no deben emplearse para enviar nada.
Cuando ya existe un entorno con datos reales, la corrección consiste en sustituirlos por datos generados y borrar los originales. Y conviene revisar de paso las capturas de pantalla, los ejemplos de la documentación y los comentarios del código: son lugares donde las direcciones reales aparecen con mucha frecuencia y donde nadie las busca.
El enmascarado en pantalla y en los registros
Mostrar la dirección completa en cada pantalla no es necesario. En la mayoría de los casos basta con una parte: el nombre de la vía o solo la ciudad y el país, según lo que la persona necesite para reconocer el registro. Un pedido destinado a Estados Unidos puede reconocerse perfectamente por la ciudad y la división, sin necesidad de exponer el número de la casa. Cuanto menos se muestre, menos se filtra a quien mira por encima del hombro o captura una pantalla.
Lo mismo vale para los registros técnicos. Una dirección escrita en el registro de una aplicación queda almacenada sin control, se copia a los sistemas de recogida y a menudo se conserva mucho más tiempo que el dato original. Lo razonable es enmascarar la parte que identifica el domicilio y conservar solo lo que hace falta para diagnosticar: el país, si acaso, o un identificador interno del registro.
| Contexto | Qué mostrar | Qué evitar |
|---|---|---|
| Listado de pedidos | Ciudad y país | Calle y número completos |
| Confirmación al cliente | Dirección completa de su propio pedido | Direcciones de otros |
| Registro técnico | País o identificador interno | Línea de calle |
| Documentación y ejemplos | Datos generados | Copias de datos reales |
| Entorno de pruebas | Datos generados | Volcados de producción |
Cómo tratar la dirección en la interfaz de administración
Los paneles internos son el punto más descuidado. Suelen mostrar la dirección completa a cualquier persona con acceso, sin distinguir entre quien necesita verla para atender un pedido y quien solo consulta métricas. Y suelen permitir exportaciones completas a formatos de hoja de cálculo que después circulan por correo.
Limitar el acceso por función es más efectivo que añadir una advertencia en la interfaz. Si el equipo de atención necesita la dirección para resolver una incidencia y el resto no, basta con restringir el campo. Y si se exporta, conviene que la exportación incluya solo los campos necesarios y sea un acto deliberado, no un botón que cualquiera pulsa sin pensar.
Notas para quien programa
- Recoge solo los campos que usas. Un campo de dirección que nunca se lee es un riesgo sin ningún beneficio.
- No dupliques el dato. Cada copia en registros, ficheros de depuración o herramientas internas es un tratamiento añadido.
- Genera los datos de prueba. No copies producción para que las pruebas parezcan realistas; los datos generados cumplen la misma función.
- Enmascara por defecto. Que ver la dirección completa sea la excepción y no la norma simplifica mucho el cumplimiento.
- Cuida los registros. Un dato personal en un fichero de registro sobrevive a cualquier borrado que se haga en la base de datos.
- Revisa los ejemplos. Documentación, pruebas automatizadas y capturas contienen direcciones reales más a menudo de lo que se cree.
Siguientes pasos
Haz una lista de los sitios donde aparece una dirección en tu sistema —base de datos, registros, exportaciones, documentación y entornos de prueba— y marca en cuáles no hay una finalidad que la justifique. Empezar por eliminar esos casos suele ser más útil que redactar una política nueva. Y cuando necesites llenar un entorno con datos verosímiles, el generador devuelve direcciones completas que no pertenecen a nadie y que están pensadas únicamente para pruebas.