La privacidad desde el diseño consiste en incorporar la protección de datos al decidir cómo funcionará un tratamiento y mantenerla durante su utilización. La protección por defecto exige que, sin una intervención adicional de la persona, solo se traten los datos necesarios para cada finalidad específica. No son etiquetas comerciales ni un requisito que se resuelva añadiendo una política de privacidad al final del proyecto.
El artículo 25 del RGPD obliga al responsable a aplicar medidas técnicas y organizativas apropiadas. No impone el mismo catálogo de tecnologías a todos los sistemas. El trabajo útil consiste en convertir finalidades, riesgos y derechos en decisiones comprobables: qué información se recoge, quién puede verla, cuánto tiempo se utiliza y qué sucede cuando cambia el servicio. Esta guía propone un expediente de diseño que puede adaptarse a un proyecto nuevo o a un sistema existente.
Qué exige el art. 25 RGPD
El artículo 25.1 del RGPD exige integrar garantías al determinar los medios y durante el tratamiento. Deben considerarse el estado de la técnica, el coste de aplicación, la naturaleza, el ámbito, el contexto y los fines, junto con la probabilidad y gravedad de los riesgos para las personas. La medida elegida debe servir realmente para aplicar los principios y proteger los derechos.
El apartado 2 concreta la protección por defecto en la cantidad de datos, la extensión del tratamiento, el plazo de conservación y la accesibilidad. También exige que, sin intervención de la persona, sus datos no sean accesibles a un número indeterminado de personas. No significa bloquear cualquier uso legítimo, sino evitar que el funcionamiento ordinario exceda lo necesario para cada fin específico.
La fórmula «configuración más protectora» puede resultar engañosa si se interpreta como una orden de elegir siempre el máximo aislamiento técnicamente imaginable. Una plataforma de colaboración necesita ciertos intercambios para prestar su función legítima. La decisión consiste en delimitar esos intercambios y evitar accesos o usos innecesarios. El producto debe funcionar con garantías adecuadas, sin trasladar al usuario toda la carga de restringirlo después.
Diseño frente a por defecto
Diseñar una separación entre datos identificativos y datos de análisis puede ser una medida del artículo 25.1. Configurar un informe para mostrar solo la información necesaria a su destinatario es una decisión de funcionamiento por defecto. Ambas pueden complementarse, pero no son intercambiables: una arquitectura prudente puede quedar debilitada por permisos iniciales demasiado amplios.
Tampoco se limita la protección por defecto a la primera pantalla que ve una persona. Hay valores predeterminados en una importación, una exportación, la duración de un enlace o la activación de registros de actividad. Revise esas decisiones en todos los canales. Un formulario público reducido sirve de poco si una integración interna incorpora automáticamente información adicional sin necesidad.
La minimización de datos ofrece criterios para decidir el contenido necesario. La limitación de la finalidad determina para qué puede utilizarse. El diseño debe hacer operativas ambas decisiones, por ejemplo separando una gestión contractual de una función opcional que persiga otra finalidad, en lugar de mezclar sus datos y permisos desde el inicio.
Empezar por el tratamiento, no por una tecnología
Defina el resultado que pretende conseguir la organización y las operaciones necesarias. Un proyecto descrito únicamente como «implantar inteligencia artificial» todavía no explica qué datos se usarán, para qué decisión ni sobre qué personas. Antes de seleccionar una herramienta, identifique la finalidad, los participantes, los orígenes de información y los efectos previsibles de un resultado incorrecto.
Determine la base jurídica y las condiciones específicas que correspondan. Un contrato con un proveedor no equivale a una base contractual para cualquier tratamiento de datos de usuarios. La necesidad del artículo 6.1.b debe vincularse a un contrato con la persona o a medidas precontractuales solicitadas por ella. Si se utilizan categorías especiales, el artículo 9 añade requisitos propios que ninguna técnica de seguridad sustituye.
El registro de actividades de tratamiento puede servir para enlazar el proyecto con la documentación general de la organización. No debe confundirse con el expediente técnico completo. Una descripción de alto nivel ayuda a ubicar la actividad, mientras que las decisiones de diseño necesitan explicar flujos, permisos, alternativas y cambios que no caben necesariamente en el registro.
Reúna a quienes conocen esas partes: negocio, sistemas, seguridad, cumplimiento y las personas que ejecutarán el proceso. Cuando exista un delegado de protección de datos, debe participar de forma adecuada y oportuna en las cuestiones correspondientes a su función. Su asesoramiento no convierte al delegado en responsable exclusivo del proyecto ni elimina la decisión y responsabilidad de la organización.
La guía de la AEPD y las estrategias de Hoepman
La Guía de Privacidad desde el Diseño de la AEPD presenta ocho estrategias de diseño. Cuatro se orientan a los datos: minimizar, ocultar, separar y abstraer. Las otras cuatro se orientan a los procesos: informar, controlar, cumplir y demostrar. Son recursos metodológicos para pensar soluciones; no equivalen a ocho tecnologías obligatorias que deban comprarse para cada proyecto.
Puede utilizar estas categorías en una reunión de diseño. Ante un panel de análisis, pregunte si necesita identificar personas, si puede reducir detalle y si debe separar la información de otras finalidades. Después examine cómo se informa, quién controla el uso y qué evidencia demuestra la decisión. El método ayuda a formular preguntas, mientras que la respuesta debe basarse en el tratamiento concreto.
Las Directrices 4/2019 del CEPD, versión final de 2020 desarrollan la aplicación del artículo 25. La referencia a una guía no certifica un producto ni convierte su cuestionario en prueba suficiente. La organización debe poder explicar por qué las medidas seleccionadas son apropiadas y cómo se ha comprobado su eficacia en el uso previsto.
Medidas concretas por fase del proyecto
En la fase de requisitos, convierta cada necesidad en una regla observable. Si un empleado solo necesita conocer que una solicitud está validada, quizá no deba acceder al justificante completo. Defina qué ve, en qué momento y con qué finalidad. Esa precisión permite diseñar permisos útiles y evita resolver todas las dudas concediendo acceso general a una carpeta compartida.
Durante el desarrollo o la configuración, examine dónde se crean copias adicionales. Los entornos de prueba, los registros de errores y las herramientas de soporte pueden recibir información que no aparece en el diagrama principal. Utilizar datos ficticios o debidamente preparados puede ser una alternativa apropiada cuando permita cumplir la finalidad de prueba. La elección debe atender al caso, no a una prohibición técnica universal.
Antes del despliegue, revise los valores predeterminados con una cuenta nueva y con distintos roles. Compruebe qué información se muestra sin cambiar ajustes, qué funciones opcionales están activas y qué exportaciones puede realizar cada perfil. Esta revisión práctica puede descubrir diferencias entre lo aprobado por el equipo y lo que realmente recibe el usuario al comenzar.
Durante la explotación, gestione los cambios con el mismo criterio. Una actualización puede activar una nueva recogida de datos o ampliar permisos. No hace falta repetir todo el expediente por cada cambio menor, pero sí identificar los cambios relevantes para las finalidades, los riesgos o las garantías. Asigne a alguien la revisión de esos efectos antes de incorporarlos al funcionamiento ordinario.
Ejemplo: un sistema de reserva de citas
Imagine una organización que permite reservar una cita informativa sin necesitar conocer datos de salud. El formulario podría requerir un medio de contacto y una franja horaria, mientras que un campo libre ilimitado podría recibir información sensible innecesaria. El diseño debe preguntarse si ese campo tiene una finalidad clara, si conviene sustituirlo y cómo evitar que las instrucciones animen a aportar detalles excesivos.
En la agenda interna, diferentes empleados pueden necesitar distinta información. Quien gestiona la disponibilidad no siempre necesita el contenido de una conversación posterior. La separación de vistas y los permisos son posibles medidas para aplicar esa distinción. El ejemplo no impone una arquitectura única: el objetivo comprobable es impedir accesos que no sean necesarios para el trabajo asignado.
Los recordatorios deben revisarse también. Un asunto de correo o una notificación visible en la pantalla bloqueada pueden revelar información a terceros. Decida qué contenido basta para recordar la cita y qué debe quedar detrás de una autenticación apropiada. La decisión debe tener en cuenta el contexto y las expectativas, evitando convertir un recordatorio útil en una divulgación innecesaria.
Por último, establezca qué sucede con una cita cancelada o antigua. No basta configurar el calendario si las exportaciones y los mensajes permanecen indefinidamente en otros sistemas. Vincule las reglas a la limitación del plazo de conservación y defina las situaciones en que exista una conservación legal o un bloqueo aplicable. La finalidad de cada copia debe poder explicarse.
Elegir medidas sin convertir ejemplos en mandatos
El cifrado puede proteger la confidencialidad, pero no corrige una finalidad ilícita ni reduce por sí mismo una recogida excesiva. La seudonimización puede limitar la vinculación directa con una persona, pero los datos siguen siendo personales cuando pueden atribuirse con información adicional. La selección de medidas debe responder al riesgo y al principio que se quiere hacer efectivo.
Un control de acceso puede ser adecuado y fallar por una mala gestión de altas y bajas. Una política de retención puede estar correctamente descrita y no ejecutarse porque nadie conoce el repositorio secundario. Por eso el análisis incluye medidas organizativas, responsabilidades y formación, además de funciones técnicas. La existencia de una opción en el producto no demuestra que esté bien configurada ni mantenida.
No todas las organizaciones necesitan la misma solución, pero el tamaño no elimina la obligación. Una entidad pequeña que trate información especialmente sensible puede necesitar controles rigurosos. El coste es uno de los factores legales de valoración, no una excusa general para omitir garantías necesarias. Compare alternativas capaces de alcanzar el resultado requerido y documente la elección de forma proporcionada.
Cuándo hace falta una evaluación de impacto
La protección desde el diseño se aplica con carácter general a los tratamientos sujetos a esa obligación. La evaluación de impacto en protección de datos se exige en los casos del artículo 35 y las reglas aplicables, especialmente cuando sea probable un alto riesgo. No todo proyecto necesita una EIPD, y no todo expediente de diseño debe denominarse así.
Cuando la EIPD sea necesaria, puede organizar el análisis de necesidad, proporcionalidad, riesgos y medidas. Debe realizarse antes del tratamiento y revisarse cuando corresponda. Si permanece un alto riesgo que no se ha mitigado, examine la consulta previa del artículo 36. Completar una plantilla no equivale a haber reducido el riesgo ni autoriza a iniciar una actividad sin resolver las condiciones aplicables.
Si no procede una EIPD, conserve una explicación suficiente de la evaluación y las decisiones. La ausencia de esa obligación específica no convierte el proyecto en irrelevante para la privacidad. Puede bastar un expediente más sencillo, siempre que permita comprender los hechos, las medidas adoptadas y las responsabilidades. La proporcionalidad también afecta a la manera de documentar, no solo al control elegido.
Comprar un servicio sin perder el control del diseño
El responsable mantiene sus obligaciones aunque utilice un producto estándar. Antes de contratar, compruebe si permite limitar datos, accesos y conservación de acuerdo con sus necesidades. No dé por hecho que una etiqueta de cumplimiento resuelve esos aspectos. Pida una demostración de los ajustes relevantes y una descripción de las limitaciones que no podrán cambiarse durante el uso.
También importan los usos del propio proveedor y las integraciones activadas. Un servicio destinado a gestionar citas podría incorporar analítica, soporte remoto u otras funciones. Determine quién decide sus fines y qué datos recibe cada participante. La configuración de la interfaz visible al usuario es solo una parte del diseño; las comunicaciones internas y externas deben entrar en la misma revisión.
Defina la salida antes del inicio. La organización debe saber cómo recuperar información, cerrar accesos y gestionar la finalización del servicio según las obligaciones aplicables. Esto no significa exigir una eliminación técnica instantánea de cualquier copia sin analizar su función y condiciones. Significa evitar una dependencia que impida ejecutar decisiones justificadas sobre los datos cuando cambie la relación.
Cómo acreditar el cumplimiento (accountability)
Un expediente útil conecta una decisión con su motivo, su ejecución y su evidencia. Para una exportación restringida, por ejemplo, conserve la regla de acceso aprobada y el resultado de la comprobación con un usuario autorizado y otro que no debería obtenerla. Una captura aislada sin contexto no demuestra necesariamente qué versión o configuración estaba en uso.
La metodología de auditoría RGPD ayuda a organizar revisiones posteriores. No es necesario guardar todos los detalles técnicos para siempre. Seleccione evidencias suficientes para demostrar las decisiones y su mantenimiento, con una conservación proporcionada. La documentación de cumplimiento también puede contener datos personales y necesita sus propias restricciones de acceso y uso.
Incluya la capacidad de responder a una brecha de seguridad como parte de la operativa, sin reducir el diseño exclusivamente a incidentes. Deben poder identificarse sistemas, responsables y datos afectados. Una arquitectura que evita copias innecesarias puede facilitar la respuesta, pero no ofrece una garantía de ausencia de incidentes ni sustituye las decisiones exigibles cuando ocurra uno.
Antes del cierre del proyecto, contraste los resultados con el checklist de cumplimiento RGPD en España. Utilícelo como recordatorio, no como certificación. Si una cuestión sigue abierta, indique su responsable y si impide iniciar el tratamiento. La aceptación del proyecto debe reflejar la situación real, no convertir una tarea pendiente en una medida supuestamente implantada.
Sistemas existentes y revisión de cambios
Un sistema antiguo también requiere medidas durante su utilización. Si no se diseñó correctamente, la obligación actual no desaparece ni la única respuesta es descartarlo por completo. Identifique sus carencias, valore alternativas y adopte las medidas necesarias. Un plan de mejora no justifica mantener indefinidamente un tratamiento que incumpla sus condiciones esenciales.
Revise especialmente cambios de finalidad, nuevas categorías de datos, destinatarios adicionales y ampliaciones de acceso. Un ajuste aparentemente pequeño puede modificar el contexto del tratamiento. La persona que propone el cambio debe aportar información suficiente para evaluarlo, y quien lo aprueba debe entender sus efectos. Deje vinculada esa decisión a la versión que finalmente entra en funcionamiento.
FAQ
¿Hay que cifrar y seudonimizar todos los datos por mandato del artículo 25?
El artículo exige medidas apropiadas y menciona la seudonimización como ejemplo. La necesidad de controles concretos se valora según el tratamiento, el estado de la técnica y los riesgos, junto con otras normas aplicables. No debe sustituirse ese análisis por un catálogo universal, ni usarse su ausencia para prescindir de medidas que sí resulten necesarias en el caso.
¿La privacidad por defecto solo afecta a las cuentas nuevas?
No. Abarca decisiones predeterminadas sobre cantidad, extensión, conservación y accesibilidad de los datos. Puede afectar a importaciones, informes, funciones opcionales y permisos, además de la configuración inicial de una cuenta. Debe revisarse cuando cambie el tratamiento y mantenerse durante su funcionamiento, sin exigir que cada persona corrija después un diseño excesivo.
¿La guía de la AEPD o una certificación sustituyen el análisis del proyecto?
No. Las guías ayudan a aplicar las obligaciones y un mecanismo de certificación aprobado puede ser un elemento de demostración en los términos del RGPD. Ninguno sustituye la comprobación del tratamiento real, la finalidad, los riesgos y la eficacia de las medidas. La evidencia debe corresponder al servicio y a la configuración efectivamente utilizados.