| Qué protege | Qué NO protege | |
|---|---|---|
| HTTPS | Que nadie lea el tráfico por el camino | Lo que hay dentro del JSON, ni dónde acaba almacenado |
| Anonimización | El contenido: nombres, correos, teléfonos | La ubicación del servidor ni quién puede consultarlo |
| Autoalojamiento | Dónde vive el dato y quién lo custodia | Lo que registras: si mandas el DNI, se guarda igual |
"Usamos HTTPS" no es una respuesta a "¿dónde acaban los datos de mis pacientes?", y "está en nuestro servidor" no es una respuesta a "¿por qué hay un correo electrónico en esa traza?".
Una vez el dato ha salido de la memoria de tu proceso, "borrarlo" es un trámite con un tercero, con su ventana temporal, sus copias de seguridad y su registro. Límpialo antes de que salga.
Es el mismo patrón que el CallbackHandler: algo que hay que acordarse
de hacer en cada punto de llamada. Aquí el precio de olvidarlo no
es una traza que falta, es un dato personal publicado. Así que no lo dejes como una
llamada suelta que cada quien recuerda: que sea un único punto de estrangulamiento
— una función envoltorio por la que pase todo, o el mecanismo de enmascarado
del propio SDK si lo tiene — para que no se pueda olvidar.
re.sub(r'[\w\.-]+@[\w\.-]+', '[EMAIL_REDACTED]', texto)
re.sub(r'\b\d{9}\b', '[PHONE_REDACTED]', texto)
La segunda solo caza nueve dígitos seguidos. No caza
666 77 78 88, ni +34 666777888, ni 666-777-888,
pese a que el comentario del código dice "formatos variados". La primera funciona,
pero se lleva por delante el punto final de la frase si el correo va justo antes.
Y lo que ninguna regex caza: nombres propios, direcciones postales, números de historia clínica, fechas de nacimiento en texto libre. Por eso la propia guía remite a librerías especializadas de detección de PII para producción. Ese consejo no es opcional.
La validación está escrita para pasar. La cadena de prueba
del ejemplo es "Contacta a Juan en juan@empresa.com o al 666777888.". El
teléfono tiene exactamente nueve dígitos seguidos, que es justo lo
único que la regex detecta, y la validación consiste en comprobar que el
correo se sustituye. Un caso de prueba construido a la medida de la solución no
prueba nada: mide si la regex hace lo que ya sabemos que hace, no si protege al
usuario. Escribe tú los casos que deberían romperla.
metadata={"compliance": "GDPR_OK"}. La traza "segura" del
ejemplo se etiqueta a sí misma como conforme al RGPD. Nadie ha verificado nada:
es una cadena de texto que el propio código se autoconcede. Y no es inocuo —
una etiqueta así en producción es exactamente lo que aparece en una
auditoría, y afirma algo que la regex de al lado no sostiene. Si vas a etiquetar
el tratamiento de un dato, que la etiqueta describa lo que hiciste —
qué se enmascaró y con qué —, no una conclusión legal
que no te corresponde firmar.
Coge las dos expresiones regulares tal cual y pásales esta lista:
666 77 78 88
+34 666777888
666-777-888
Mi correo es ana@empresa.com.
Paciente: María López, nacida el 3 de mayo de 1978Cuenta cuántas de las cinco líneas dejan escapar un dato personal. Ese número, escrito al lado de la frase "hemos anonimizado los datos", es la diferencia entre una medida de protección y una casilla marcada.