Privacidad desde el diseño y el RGPD (GDPR)

La privacidad es una propiedad del diseño

La seguridad y la privacidad se solapan, pero no son lo mismo. La seguridad se pregunta si los datos están protegidos frente a quienes no deberían tenerlos. La privacidad se pregunta además si la propia organización debería recopilar esos datos en absoluto, qué puede hacer con ellos, durante cuánto tiempo y qué control conserva la persona a la que describen. Un sistema puede no sufrir ninguna brecha y aun así invadir la privacidad, por ejemplo si conserva para siempre el rastro de ubicaciones de cada repartidor o si reutiliza discretamente los historiales de pedidos para entrenar un modelo de precios.

La plataforma de reparto de comida es un buen ejemplo de por qué la privacidad es arquitectónica. Guarda nombres, números de teléfono y domicilios; historiales de pedidos que pueden revelar la religión o la salud a través de las preferencias alimentarias; referencias de pago; y un flujo continuo de ubicaciones de los repartidores. Estos datos circulan desde las apps a través de decenas de servicios, eventos, cachés, logs, almacenes de analítica y copias de seguridad, y llegan a encargados del tratamiento como el proveedor de pagos, la pasarela de SMS y el SaaS de soporte. Las decisiones sobre dónde se almacenan los datos personales, con qué clave se identifican y cómo pueden encontrarse y eliminarse son costosas de cambiar más adelante, que es exactamente la prueba para saber si algo es arquitectónicamente significativo.

La ley en breve: el RGPD y el UK GDPR

El Reglamento General de Protección de Datos, Reglamento (UE) 2016/679, se aplica desde el 25 de mayo de 2018. Protege los datos personales, que el artículo 4(1) define como toda información sobre una persona física identificada o identificable, directa o indirectamente, por ejemplo mediante un nombre, un número de identificación, datos de localización o un identificador en línea. El responsable del tratamiento decide por qué y cómo se tratan los datos y tiene la responsabilidad principal; un encargado del tratamiento trata los datos por cuenta del responsable en virtud de un contrato (artículo 28), como hace la pasarela de SMS de la plataforma. El RGPD se aplica a las organizaciones establecidas en la UE y, según el artículo 3, a otras que ofrecen bienes o servicios a personas en la UE o controlan su comportamiento.

En el Reino Unido, el RGPD se mantuvo tras el Brexit como UK GDPR, que funciona junto con la Data Protection Act 2018. La Data (Use and Access) Act 2025 modificó ambos; la mayoría de sus cambios en materia de protección de datos entraron en vigor el 5 de febrero de 2026, incluidos cambios en las bases jurídicas, las decisiones automatizadas y las transferencias internacionales, y a partir del 19 de junio de 2026 se suma la obligación de que los responsables gestionen las reclamaciones sobre protección de datos. La Comisión Europea renovó sus decisiones de adecuación para el Reino Unido en diciembre de 2025, de modo que los datos personales pueden seguir fluyendo de la UE al Reino Unido sin garantías adicionales. Para los arquitectos, los dos regímenes comparten los mismos principios, derechos y obligaciones de diseño; las diferencias son cuestiones de detalle para los abogados.

Las multas máximas por las infracciones más graves son de 20 millones de EUR o el 4% del volumen de negocio anual mundial según el RGPD (17.5 millones de GBP o el 4% según el UK GDPR), la cifra que sea mayor, aunque las consecuencias más habituales son órdenes de detener el tratamiento, daños a la reputación y el costo de rediseñar los sistemas. En noviembre de 2025, la Comisión Europea propuso modificaciones del RGPD como parte de un paquete Digital Omnibus; en el momento de redactar esto, siguen en tramitación legislativa y todavía no cambian nada.

Las bases jurídicas, brevemente

El artículo 6 solo permite el tratamiento sobre una de seis bases jurídicas: el consentimiento, la ejecución de un contrato con la persona, una obligación legal, intereses vitales, una misión realizada en interés público, o intereses legítimos que no prevalezcan sobre los intereses y derechos de la persona. Las categorías especiales de datos, como la salud o las creencias religiosas, necesitan una condición adicional según el artículo 9. La base se elige por finalidad, no por sistema, y cambia lo que debe hacer la arquitectura. En la plataforma de reparto de comida, la dirección de entrega se trata para ejecutar el contrato; las facturas se conservan para cumplir una obligación legal derivada de la normativa fiscal; la detección de fraude suele basarse en intereses legítimos; y los correos electrónicos de marketing normalmente necesitan consentimiento, que también regulan las normas sobre marketing electrónico.

El consentimiento tiene la mecánica más estricta. Según el artículo 7, el responsable debe poder demostrar que se dio el consentimiento, este debe ser específico para una finalidad, y retirarlo debe ser tan fácil como darlo. Eso significa que el consentimiento no puede ser una sola columna booleana: el sistema necesita un registro de solo anexión (append-only) de qué aceptó la persona, cuándo, por qué canal y en respuesta a qué texto, y todos los consumidores deben respetar una retirada con prontitud.

{
  "event": "ConsentGiven",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "noticeVersion": "privacy-notice-2026-09",
  "wording": "Send me offers from restaurants near me",
  "channel": "ios-app 7.3.0",
  "method": "unticked checkbox, user ticked",
  "at": "2026-10-03T18:22:41Z"
}
{
  "event": "ConsentWithdrawn",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "channel": "email unsubscribe link",
  "at": "2026-10-19T07:05:12Z"
}

Protección de datos desde el diseño y por defecto

El artículo 25 convierte la privacidad desde el diseño en una obligación legal. El artículo 25(1), la protección de datos desde el diseño, exige al responsable, tanto en el momento de decidir cómo tratar los datos como durante el propio tratamiento, aplicar medidas técnicas y organizativas apropiadas, como la seudonimización, que hagan efectivos los principios, teniendo en cuenta el estado de la técnica, el costo, la naturaleza y los fines del tratamiento y los riesgos. El artículo 25(2), por defecto, exige que por defecto solo se traten los datos necesarios para cada fin específico, lo que abarca la cantidad recopilada, la extensión del tratamiento, el plazo de conservación y la accesibilidad; en particular, los datos no deben ser accesibles a un número indeterminado de personas sin la intervención de la persona afectada. Las Directrices 4/2019 sobre el artículo 25 del Comité Europeo de Protección de Datos (EDPB) ofrecen ejemplos prácticos.

La ley tomó la idea de Ann Cavoukian, comisionada de Información y Privacidad de Ontario, que desarrolló la privacidad desde el diseño en la década de 1990 y publicó sus siete principios fundamentales en 2009; la conferencia internacional de comisionados de protección de datos los respaldó en 2010. Siguen siendo una lista de comprobación útil para revisar diseños.

Derechos que la arquitectura debe soportar

Los derechos de los interesados son el punto en el que la legislación de privacidad se convierte más directamente en requisitos del sistema. Un responsable debe responder normalmente en el plazo de un mes desde la solicitud, prorrogable hasta otros dos meses en el caso de solicitudes complejas o numerosas (artículo 12(3)), y debe poder encontrar los datos de la persona dondequiera que estén. En un sistema de veinte servicios, cinco encargados del tratamiento SaaS y un almacén de datos, eso es imposible sin un mapa de datos mantenido: el registro de actividades de tratamiento que el artículo 30 ya exige, mantenido lo bastante cerca del código como para ser exacto. Con las modificaciones del Reino Unido de 2025, un responsable que atiende una solicitud de acceso solo está obligado a realizar búsquedas razonables y proporcionadas, algo que un buen mapa de datos agiliza.

Evaluaciones de impacto relativas a la protección de datos

El artículo 35 exige una evaluación de impacto relativa a la protección de datos (EIPD) antes de un tratamiento que probablemente entrañe un alto riesgo para los derechos y libertades de las personas, en particular la elaboración de perfiles sistemática y exhaustiva con efectos significativos, el tratamiento a gran escala de categorías especiales de datos o de datos relativos a infracciones penales, y la observación sistemática a gran escala de una zona de acceso público. Las autoridades de control publican listas de otros casos; el seguimiento continuo de la ubicación de los repartidores y la gestión algorítmica de su trabajo son candidatos típicos. Una EIPD describe el tratamiento y sus fines, evalúa su necesidad y proporcionalidad, evalúa los riesgos para las personas y registra las medidas que los abordan; si persiste un alto riesgo, el responsable debe consultar a la autoridad de control antes de empezar (artículo 36).

Los arquitectos deberían tratar una EIPD como la contrapartida de privacidad del modelo de amenazas de la Sección 8.2, hecha al mismo tiempo y sobre el mismo diagrama de flujo de datos. El marco LINDDUN, desarrollado en la KU Leuven, hace con las amenazas a la privacidad lo que STRIDE hace con las amenazas a la seguridad, con categorías como la vinculación, la identificación, la detección, la divulgación de datos y el desconocimiento. Las conclusiones de la EIPD se convierten en requisitos arquitectónicos, como los rastros de ubicación se eliminan 30 días después de la entrega, que pueden probarse.

Transferencias internacionales y residencia de datos

El capítulo V del RGPD restringe las transferencias de datos personales a países fuera del Espacio Económico Europeo. Una transferencia es lícita si la Comisión ha declarado adecuado el país (artículo 45), si existen garantías adecuadas como las cláusulas contractuales tipo de la Comisión (artículo 46), o al amparo de excepciones limitadas (artículo 49). Después de que el Tribunal de Justicia anulara el Escudo de la Privacidad UE-EE. UU. (Privacy Shield) en la sentencia Schrems II de julio de 2020, las transferencias basadas en cláusulas contractuales necesitan una evaluación de la legislación del país de destino; el Marco de Privacidad de Datos UE-EE. UU. (Data Privacy Framework), declarado adecuado en julio de 2023, cubre las transferencias a empresas estadounidenses que se certifiquen en él, y superó una primera impugnación ante el Tribunal General de la UE en septiembre de 2025 (Latombe/Comisión), aunque nuevos litigios, incluido un posible recurso de casación ante el Tribunal de Justicia, todavía podrían cambiar la situación.

De ello se derivan dos cuestiones arquitectónicas. Primera: una transferencia no es solo una base de datos en otra región; el acceso remoto de un equipo de soporte en el extranjero, los subencargados de un encargado SaaS y un servicio de logging alojado en otro lugar también cuentan, así que el mapa de datos debe registrar dónde se almacenan los datos y desde dónde se accede a ellos. Segunda: los requisitos de residencia de datos, ya sean legales, contractuales o elegidos, se cumplen más fácilmente con células de despliegue regionales: cada región guarda los datos personales y las claves de sus clientes, los servicios globales solo ven referencias seudónimas y la replicación entre regiones es explícita y revisada. Incorporar la residencia a posteriori en una única base de datos global es uno de los cambios más costosos a los que puede enfrentarse una plataforma, y por eso pertenece a las restricciones que se recogen desde el principio.

Minimización, seudonimización y anonimización

Los datos personales más baratos de proteger son los que nunca recopilas. La minimización se nota en decisiones pequeñas: un indicador de mayor de 18 años en lugar de una fecha de nacimiento, un distrito postal en lugar de una dirección completa para la analítica, un número de teléfono enmascarado que la plataforma retransmite en lugar de revelar al repartidor el número del cliente, y un muestreo de la ubicación solo mientras hay una entrega en curso.

La seudonimización (artículo 4(5)) trata los datos de manera que ya no puedan atribuirse a una persona sin información adicional, como una clave, que se guarda por separado y protegida. Un hash con clave (HMAC) del ID de cliente, cuya clave guarda el equipo de cuentas, permite al equipo de analítica contar los pedidos por cliente sin ver quiénes son los clientes. Es una salvaguarda valiosa que el artículo 25 menciona expresamente, pero el considerando 26 deja claro que los datos seudonimizados que podrían atribuirse a una persona mediante información adicional siguen siendo datos personales. En SEPD/JUR (asunto C-413/23 P, 4 de septiembre de 2025), el Tribunal de Justicia añadió un matiz: si los datos son personales se evalúa desde la perspectiva de quien los tiene, de modo que los datos seudonimizados pueden no ser datos personales para un destinatario que no tenga medios razonables de reidentificar a nadie, aunque siguen siendo datos personales para el responsable que guarda la clave, y el responsable debe seguir informando a las personas sobre esos destinatarios. Las Directrices 01/2025 del EDPB sobre seudonimización describen cómo hacerla bien.

La anonimización va más allá: los datos ya no se refieren a una persona identificable, teniendo en cuenta todos los medios que razonablemente puedan utilizarse para identificar a alguien, y entonces el RGPD deja de aplicarse. La anonimización real es difícil. Eliminar los nombres no basta cuando la combinación de código postal, fecha de nacimiento y sexo identifica a la mayoría de las personas, o cuando el rastro de ubicaciones de un solo repartidor revela dónde vive. La agregación con supresión de los recuentos pequeños, la generalización y, para las estadísticas, la privacidad diferencial son las técnicas habituales, y el resultado debería probarse frente a intentos realistas de reidentificación.

Conservación y supresión en todas las copias

La limitación del plazo de conservación necesita un calendario de conservación: para cada categoría de datos, cuánto tiempo se conservan, por qué y qué ocurre al final (eliminación, anonimización o archivo). Los calendarios solo funcionan cuando los sistemas los aplican automáticamente: TTL en las entradas de caché y de almacenes clave-valor, tablas particionadas por tiempo cuyas particiones antiguas se eliminan, reglas de ciclo de vida del almacenamiento de objetos, ajustes de conservación de logs y tareas programadas cuyo éxito se monitoriza.

La supresión es más difícil en los lugares por los que se filtran los datos personales. Las cachés y los índices de búsqueda necesitan desalojo y reindexación explícitos, con TTL como red de seguridad. Los almacenes de analítica deberían guardar referencias seudónimas para que las filas puedan encontrarse y eliminarse, o bien los datos deberían anonimizarse al entrar. Los logs de eventos y los almacenes con event sourcing son inmutables por diseño; la técnica habitual es el crypto-shredding, que cifra los campos de cada persona con una clave propia de esa persona y destruye la clave, como se describe en la Sección 7.5, o bien mantener los datos personales fuera de los eventos y almacenar solo referencias. Los logs de aplicación no deberían contener datos personales innecesarios, algo sobre lo que vuelve la Sección 8.8. Las copias de seguridad normalmente no pueden editarse; la Information Commissioner's Office (ICO) del Reino Unido acepta que los datos permanezcan en las copias de seguridad hasta que se sobrescriban según un calendario establecido, siempre que entretanto queden fuera de uso y se informe claramente a la persona de lo que ocurrirá, y si alguna vez se restaura una copia de seguridad, las supresiones deben volver a aplicarse, lo que exige conservar la lista de los ID suprimidos. Por último, hay que dar instrucciones de eliminación a los encargados del tratamiento, ya que solo actúan siguiendo las instrucciones del responsable (artículo 28), y hay que informar a los demás destinatarios (artículo 19), así que la supresión debe llegar a la pasarela de SMS, al servicio de soporte y a la plataforma de marketing a través de sus API.