Privacidad desde el diseño y por defecto.

Dos obligaciones, no una

La privacidad desde el diseño (privacy by design) y la privacidad por defecto (privacy by default) están redactadas como una única obligación del RGPD, pero exigen dos cosas distintas, y los profesionales se meten en problemas cuando las funden en una sola. Desde el diseño significa que los controles de privacidad se incorporan a un sistema desde la fase de requisitos, antes de que se escriba una línea de código o se elija un proveedor, en lugar de añadirse una vez que empiezan a llegar las solicitudes de acceso de los interesados.

Por defecto significa que cuando un usuario no hace nada, el sistema ya se encuentra en su configuración más protectora: la recogida de datos más restringida, la conservación más breve, la compartición más estricta. Una se refiere a cómo construyes; la otra a lo que el sistema hace el primer día sin configuración alguna.

La distinción importa porque un equipo puede cumplir una y fallar la otra. Puedes realizar una revisión de diseño exhaustiva, documentar una EIPD y aun así lanzar un producto cuyos ajustes por defecto estén todos configurados para la máxima compartición porque eso es lo que pidió el equipo de crecimiento. Ese producto es privacidad desde el diseño pero no por defecto, y no es conforme. También ocurre lo contrario: un ajuste por defecto conservador añadido a un sistema que nunca se evaluó deja al responsable del tratamiento incapaz de demostrar cómo se tomó la decisión.

Qué cambia esto realmente en la práctica

El cambio práctico consiste en mover la privacidad aguas arriba. En lugar de que el área jurídica revise una funcionalidad terminada, los requisitos de privacidad se convierten en restricciones de diseño que ingeniería y producto asumen desde el primer sprint. La minimización de datos deja de ser un eslogan y se convierte en una pregunta planteada a cada campo de cada formulario: ¿necesitamos esto para prestar el servicio? Y si no, ¿por qué está aquí? La limitación de la finalidad se convierte en una restricción sobre los fines para los que un conjunto de datos podrá reutilizarse después. La conservación se convierte en un calendario por defecto que el sistema aplica, no en una limpieza manual que nadie se acuerda de ejecutar.

• Recoge el mínimo de campos que el servicio realmente necesita, y justifica cada uno.
• Establece los plazos de conservación como ajustes por defecto aplicados, con supresión o anonimización automática cuando expiren.
• Configura los ajustes por defecto de compartición, visibilidad y elaboración de perfiles en la opción menos permisiva, dejando que el usuario opte por autorizar más.
• Aplica la seudonimización y el cifrado como opciones arquitectónicas estándar y no como excepciones.
• Acota el acceso a los datos personales por finalidad, de modo que un sistema solo exponga lo que una función concreta requiere.

Cómo se sitúa frente a conceptos vecinos

La privacidad desde el diseño se entiende más fácilmente por contraste con aquello con lo que la gente la confunde. No es lo mismo que una EIPD, que es una pieza de prueba de que la obligación más amplia se cumplió para una actividad de tratamiento concreta y de mayor riesgo. No es la seguridad desde el diseño, que protege los datos frente a los atacantes con independencia de si esos datos debieron recogerse siquiera; la privacidad desde el diseño empieza un paso antes, cuestionando la propia recogida. Y no es una verificación única. Como los sistemas evolucionan, la obligación es continua: cada nueva funcionalidad, integración o flujo de datos reabre las mismas preguntas sobre minimización, finalidad y ajustes por defecto.

En un programa maduro, la privacidad desde el diseño se convierte en un hábito integrado en el ciclo de vida del desarrollo, y no en un punto de control en manos del área jurídica. Producto e ingeniería plantean las preguntas por sí mismos, la EIPD se activa automáticamente cuando el tratamiento cruza un umbral de riesgo, y la configuración por defecto se revisa como parte del lanzamiento en lugar de descubrirse en producción. Esa es la diferencia entre una organización que puede demostrar el principio y otra que simplemente lo afirma.