La privacidad no es un complemento que se añade cuando un producto ya está desarrollado: es un requisito que debe estar presente desde el primer boceto de cualquier sistema de información. Eso es exactamente lo que exige el artículo 25 del Reglamento (UE) 2016/679 (RGPD), un precepto que sigue siendo uno de los menos conocidos en las pymes y medianas empresas, pese a que su incumplimiento puede derivar en sanciones en el marco del artículo 83 del RGPD.
En este artículo analizamos qué obliga exactamente el artículo 25 del RGPD, cuáles son las medidas técnicas y organizativas más relevantes para cumplirlo, qué papel tiene la seudonimización y cómo la división de Sistemas de Summum Consultoría acompaña a las organizaciones en la integración de estos principios desde la fase de diseño.
Qué establece el artículo 25 del RGPD
El artículo 25 del RGPD regula dos principios diferenciados pero íntimamente ligados:
- Privacidad desde el diseño (privacy by design): obliga al responsable del tratamiento a aplicar, tanto al determinar los medios del tratamiento como durante el propio tratamiento, medidas técnicas y organizativas apropiadas —como la seudonimización— con el fin de aplicar de forma efectiva los principios de protección de datos e integrar las garantías necesarias en el tratamiento (artículo 25.1 RGPD).
- Privacidad por defecto (privacy by default): obliga al responsable a garantizar que, por defecto, solo se traten los datos personales necesarios para cada fin específico del tratamiento. Esta obligación afecta a la cantidad de datos recogidos, la extensión de su tratamiento, su plazo de conservación y su accesibilidad (artículo 25.2 RGPD).
El artículo 25.3 añade que la adhesión a un mecanismo de certificación conforme al artículo 42 del RGPD puede utilizarse como elemento para demostrar el cumplimiento de los dos apartados anteriores.
El legislador europeo emplea dos umbrales temporales para la privacidad desde el diseño: «en el momento de determinar los medios de tratamiento» y «en el momento del propio tratamiento». Esto significa que la obligación arranca antes de que el sistema se ponga en marcha, no cuando ya está operativo. Una empresa que empieza a construir un CRM, un portal de clientes o un sistema de gestión de recursos humanos ya está sujeta al artículo 25 en la fase de especificación funcional.
Contexto normativo: de dónde viene la privacidad desde el diseño
El concepto de privacy by design tiene raíces en el trabajo de la comisionada de privacidad de Ontario (Canadá), Ann Cavoukian. El concepto, surgido en los años noventa, se concretó después en siete principios fundacionales: proactividad en lugar de reactividad; privacidad como configuración predeterminada; privacidad integrada en el diseño; funcionalidad plena sin compromisos; seguridad de extremo a extremo durante todo el ciclo de vida del dato; visibilidad y transparencia; y respeto activo por la privacidad del usuario. El RGPD absorbió esta filosofía y la convirtió en obligación jurídica directamente aplicable en los veintisiete Estados miembros de la Unión Europea.
En España, la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD) no desarrolla específicamente el artículo 25 del RGPD, pero complementa el marco europeo en aspectos procedimentales y sectoriales. La LOPDGDD derogó la antigua LO 15/1999 y es, junto con el RGPD, la referencia normativa vigente para las organizaciones que operan en territorio español.
El Comité Europeo de Protección de Datos (CEPD) ha publicado directrices específicas sobre la privacy by design y la privacy by default que orientan la aplicación práctica del artículo 25, especialmente en lo relativo a los criterios de evaluación de las medidas técnicas y organizativas.
Medidas técnicas y organizativas: qué exige la norma
El artículo 25.1 del RGPD aclara que las medidas deben tener en cuenta «el estado de la técnica, los costes de aplicación, la naturaleza, el ámbito, el contexto y los fines del tratamiento, así como los riesgos de diversa probabilidad y gravedad que entraña el tratamiento para los derechos y libertades de las personas físicas». No existe, por tanto, una lista tasada de medidas obligatorias: la norma exige proporcionalidad y adecuación al riesgo real de cada organización y de cada tratamiento concreto.
Las medidas técnicas más habituales que contribuyen a cumplir el artículo 25 incluyen:
- Seudonimización y cifrado de bases de datos, ficheros y comunicaciones.
- Control de acceso basado en roles (RBAC): solo el personal que necesita los datos para su función específica puede acceder a ellos.
- Minimización en formularios y APIs: recabar únicamente los campos estrictamente necesarios para el fin declarado, sin solicitar información adicional «por si acaso».
- Disociación de identificadores directos en entornos de desarrollo y pruebas, de modo que los desarrolladores no trabajen con datos reales de clientes o empleados.
- Registros de auditoría de acceso a datos personales: trazabilidad de quién accedió a qué dato y cuándo.
- Borrado automático de datos una vez transcurrido el plazo de conservación establecido para cada categoría.
- Separación de entornos (producción, desarrollo, preproducción) para evitar el uso de datos reales fuera del entorno operativo necesario.
Las medidas organizativas complementarias incluyen:
- Revisión de privacidad (privacy review) como requisito previo obligatorio al lanzamiento de cualquier nuevo tratamiento o funcionalidad.
- Cláusulas de protección de datos en contratos con proveedores y encargados del tratamiento que detallen las instrucciones técnicas y organizativas exigibles.
- Procedimientos internos de gestión del ciclo de vida del dato, desde la recogida hasta la supresión.
- Formación periódica del personal en principios de minimización, confidencialidad y gestión de incidentes.
- Evaluaciones de impacto relativas a la protección de datos (EIPD) para tratamientos de alto riesgo, de conformidad con el artículo 35 del RGPD.
La seudonimización: una herramienta clave, no una solución total
El RGPD define la seudonimización en su artículo 4.5 como «el tratamiento de datos personales de manera tal que ya no puedan atribuirse a un interesado específico sin utilizar información adicional, siempre que dicha información adicional figure por separado y esté sujeta a medidas técnicas y organizativas destinadas a garantizar que los datos personales no se atribuyan a una persona física identificada o identificable».
La seudonimización es una herramienta poderosa para reducir el riesgo en el tratamiento, pero no equivale a la anonimización. Los datos seudonimizados siguen siendo datos personales a efectos del RGPD, porque la reidentificación es posible si se accede a la información adicional (la clave o tabla de correspondencia). Lo que sí permite la seudonimización es reducir significativamente el riesgo de exposición en caso de brecha de seguridad y facilitar determinados tratamientos secundarios compatibles con el fin original.
Los casos de uso más relevantes en el contexto empresarial son:
- Entornos de desarrollo y pruebas: trabajar con datos de estructura real sin exponer datos reales de clientes o empleados.
- Analytics internos: medir el comportamiento de usuarios o elaborar estadísticas sin identificar individualmente a cada persona.
- Compartición de datos con terceros: enviar conjuntos de datos a proveedores o socios para análisis sin revelar la identidad de los interesados.
- Investigación y estadística: reutilización de datos con fines secundarios con menor impacto sobre los derechos del interesado, al amparo del artículo 89 del RGPD.
Privacidad por defecto: la minimización como obligación operativa
El principio de privacidad por defecto obliga a que la configuración inicial de cualquier sistema, aplicación o servicio sea la más restrictiva en materia de tratamiento de datos personales. Si un sistema tiene opciones de privacidad configurables, la opción por defecto debe ser siempre la que implica menor tratamiento de datos, no la más permisiva.
Esto tiene implicaciones directas y concretas para el diseño de productos digitales y para los procedimientos internos de las organizaciones:
- Un formulario de alta en un servicio no debe recoger el número de teléfono si este no es estrictamente necesario para la prestación de dicho servicio.
- Una aplicación de recursos humanos no debe vincular el historial médico del empleado con su ficha de nómina si ambos datos no necesitan estar integrados para ningún fin legítimo del tratamiento.
- Un panel de analítica web no debe almacenar la dirección IP completa si basta con los tres primeros octetos para el análisis geográfico que se pretende realizar.
- Un sistema de videovigilancia no debe conservar las grabaciones más allá del plazo máximo de un mes previsto en el artículo 22.3 de la LOPDGDD, salvo que exista una causa legal específicamente justificada.
- Una plataforma de comercio electrónico no debe marcar por defecto las casillas de suscripción a comunicaciones comerciales: el usuario debe optar activamente por recibirlas.
Comparativa: privacidad desde el diseño frente a privacidad por defecto
| Criterio | Privacidad desde el diseño (art. 25.1) | Privacidad por defecto (art. 25.2) |
|---|---|---|
| Momento de aplicación | Desde la concepción y diseño del sistema | En cada configuración y puesta en marcha del tratamiento |
| Destinatario principal | Equipos de desarrollo, arquitectura de sistemas, DPO | Producto, experiencia de usuario, administración de sistemas |
| Medidas técnicas típicas | Seudonimización, cifrado, RBAC, separación de entornos | Campos opcionales desactivados, retención mínima, acceso restringido por defecto |
| Principio RGPD vinculado | Minimización, integridad y confidencialidad (art. 5.1.c y 5.1.f) | Minimización, limitación de finalidad, limitación del plazo de conservación |
| Evidencia documental | Registros de diseño, EIPD previa, actas de revisión de privacidad | Configuraciones documentadas, políticas de retención, registros de acceso |
| Régimen sancionador | Art. 83.4 RGPD: hasta 10 M€ o 2 % facturación mundial anual | Art. 83.4 RGPD: hasta 10 M€ o 2 % facturación mundial anual |
El cruce con la división de Sistemas: integración desde la arquitectura
Cumplir el artículo 25 del RGPD no es solo una tarea del departamento jurídico o del delegado de protección de datos: requiere que los equipos técnicos —arquitectos de sistemas, desarrolladores, administradores de bases de datos, responsables de infraestructura— interioricen los principios de privacy by design como parte integral de su metodología habitual de trabajo.
La división de Sistemas de Summum Consultoría trabaja precisamente en este cruce: acompañamos a los equipos técnicos de las organizaciones para integrar los requisitos del artículo 25 en sus flujos de desarrollo, sus arquitecturas de datos y sus procedimientos de despliegue. No se trata de añadir una capa de cumplimiento al final del proceso, sino de incorporar las medidas técnicas y organizativas desde las primeras decisiones de arquitectura, cuando el coste de hacerlo correctamente es mínimo comparado con el coste de rectificar una vez el sistema está en producción.
Las actuaciones más habituales en este ámbito incluyen:
- Revisión de esquemas de bases de datos para identificar campos que recogen más información de la estrictamente necesaria para el fin del tratamiento.
- Implantación de políticas de retención automatizadas en sistemas de almacenamiento, con alertas y procesos de borrado programado.
- Definición y documentación de perfiles de acceso por roles en aplicaciones de gestión interna.
- Auditorías de configuración de herramientas SaaS y plataformas en la nube para verificar que la configuración por defecto aplicada por el proveedor es la más restrictiva disponible en materia de privacidad.
- Asesoramiento en el diseño de APIs para minimizar la exposición de datos personales en las respuestas, evitando devolver campos innecesarios para el caso de uso solicitante.
- Revisión de entornos de desarrollo y pruebas para garantizar que no se trabaja con datos reales de producción sin seudonimización previa.
Si tu organización está desarrollando un nuevo sistema de información o revisando la arquitectura de uno existente, nuestro equipo de adecuación al RGPD puede acompañarte en la integración de los principios del artículo 25 desde la fase de diseño, antes de que el sistema entre en producción y los costes de corrección se multipliquen.
Cómo documentar el cumplimiento del artículo 25
El principio de responsabilidad proactiva (accountability) del artículo 5.2 del RGPD obliga a los responsables del tratamiento no solo a cumplir los principios de protección de datos, sino a ser capaces de demostrarlo activamente ante las autoridades de control. En el caso del artículo 25, esto se traduce en mantener evidencias documentales de que las medidas de privacidad desde el diseño y por defecto han sido efectivamente aplicadas.
Los documentos más relevantes para acreditar el cumplimiento del artículo 25 son:
- Registro de actividades de tratamiento (art. 30 RGPD): debe reflejar, entre otros extremos, las medidas de seguridad técnicas y organizativas aplicadas a cada tratamiento.
- Evaluación de impacto relativa a la protección de datos (EIPD, art. 35 RGPD): obligatoria para tratamientos de alto riesgo, documenta el análisis de privacidad realizado antes del inicio del tratamiento.
- Actas de revisión de privacidad interna: registros que acrediten que cada nuevo desarrollo o funcionalidad fue evaluado desde la perspectiva de la protección de datos antes de su lanzamiento.
- Política de retención de datos: documento que establece los plazos de conservación de cada categoría de dato y los mecanismos de borrado automatizado asociados.
- Contratos con encargados del tratamiento (art. 28 RGPD): deben incluir las instrucciones específicas sobre las medidas técnicas y organizativas que el encargado está obligado a aplicar.
- Logs de configuración y auditoría: registros técnicos que acrediten que las configuraciones de privacidad por defecto están activas en los sistemas en producción.
La Agencia Española de Protección de Datos (AEPD) ha publicado guías y herramientas orientativas que facilitan la aplicación práctica del artículo 25, entre ellas el esquema de análisis de riesgo y las directrices sobre evaluación de impacto. Aunque estas guías no tienen carácter vinculante, la adhesión a ellas constituye un indicador relevante de diligencia ante una eventual investigación de la AEPD.
El equipo de protección de datos de Summum Consultoría trabaja con organizaciones de Castilla y León y Canarias —con oficinas en Valladolid, Burgos, Palencia, León y Las Palmas— para desarrollar esta documentación de cumplimiento de forma rigurosa y proporcionada al tamaño, sector y actividad de cada empresa. Desde 2007 y con más de dos mil proyectos de digitalización y adecuación normativa en cartera, nuestro enfoque combina el conocimiento jurídico con la capacidad técnica de la división de Sistemas.
Preguntas frecuentes
¿El artículo 25 del RGPD solo aplica a empresas tecnológicas o a cualquier responsable del tratamiento?
El artículo 25 del RGPD aplica a cualquier responsable del tratamiento, con independencia de su tamaño o sector. Una clínica dental, una asesoría fiscal, una empresa de logística o una pyme industrial que trate datos de clientes, empleados o proveedores está sujeta a sus obligaciones. La norma introduce proporcionalidad al exigir que las medidas sean adecuadas al estado de la técnica, los costes y el nivel de riesgo del tratamiento concreto, pero no exime de la obligación a ningún tipo de organización. La diferencia entre una gran corporación y una pequeña empresa no radica en si deben cumplirlo, sino en la complejidad y el coste de las medidas exigibles.
¿Qué diferencia hay entre la privacidad desde el diseño y una evaluación de impacto (EIPD)?
Son instrumentos distintos aunque complementarios. La privacidad desde el diseño es un principio general que obliga a integrar la protección de datos en cualquier sistema desde su concepción, aplicable a todos los tratamientos. La evaluación de impacto relativa a la protección de datos (EIPD, regulada en el artículo 35 RGPD) es un proceso formal y documentado, obligatorio únicamente para tratamientos que entrañen alto riesgo para los derechos y libertades de los interesados, que analiza sistemáticamente los riesgos y las medidas para mitigarlos antes de iniciar el tratamiento. La EIPD es, en cierto modo, la plasmación documentada de la privacidad desde el diseño aplicada a un tratamiento específico de alto riesgo.
¿Qué sanciones puede imponer la AEPD por incumplir el artículo 25 del RGPD?
El incumplimiento del artículo 25 del RGPD puede derivar en sanciones encuadradas en el artículo 83.4 del RGPD: multas administrativas de hasta 10.000.000 EUR o, en el caso de una empresa, hasta el 2 % de su volumen de negocio anual mundial total del ejercicio financiero anterior, optando por la cuantía más elevada. La LOPDGDD (LO 3/2018) complementa este régimen en el ordenamiento español con criterios adicionales de graduación. Además de la sanción económica, la AEPD puede imponer medidas correctoras como la suspensión temporal del tratamiento, la exigencia de adoptar medidas técnicas específicas en un plazo determinado, o la orden de adecuar el sistema al artículo 25 antes de reanudarlo.
¿La privacidad por defecto impide ofrecer al usuario configuraciones más permisivas?
No necesariamente. La privacidad por defecto exige que la configuración inicial sea la más restrictiva en cuanto a tratamiento de datos, pero no impide que el interesado, de forma libre, informada e inequívoca, opte por una configuración que implique mayor tratamiento de sus datos personales. El ejemplo más habitual son los paneles de preferencias de privacidad o los centros de gestión del consentimiento: la opción por defecto debe estar en el mínimo necesario, pero el usuario puede ampliar su consentimiento de forma activa a tratamientos opcionales. Lo que prohíbe el artículo 25.2 del RGPD es que la configuración por defecto sea la más permisiva y que el usuario tenga que esforzarse activamente para proteger su privacidad.