Desarrollo de Software Conforme al GDPR: Guía Práctica para Empresas del Reino Unido y la UE

Cada semana hablamos con empresas que desarrollaron su software sin considerar seriamente el GDPR, y ahora lo están pagando — a veces en honorarios legales, a veces en rearquitecturas de emergencia, y en ocasiones en multas de la ICO. La conversación suele comenzar con una frase que ya hemos aprendido a reconocer: "Sabemos que tenemos que resolver nuestro cumplimiento, solo que todavía no hemos tenido oportunidad."

Esa "oportunidad" raramente llega de manera natural. El cumplimiento no aparece como un elemento planificado en un sprint. Llega como una brecha de seguridad, una notificación regulatoria, un cuestionario de diligencia debida de un cliente empresarial que el equipo de ventas necesita responder en cuarenta y ocho horas, o un interesado amenazando con acciones legales por datos que no puede conseguir que se eliminen. Para cuando el GDPR se vuelve urgente, ya resulta costoso.

El motivo por el que adaptar el cumplimiento a posteriori es tan doloroso es que el GDPR no es un conjunto de políticas que se añaden sobre una aplicación en funcionamiento. Es una disciplina de diseño. Afecta al esquema de la base de datos, a la arquitectura de registro, a la elección de servicios de terceros, al diseño de la API, a los flujos orientados al usuario y a los procesos internos del equipo. Todo ello es más fácil de hacer bien al inicio de un proyecto que corregirlo después.

En Cyberbeak, integramos la privacidad en nuestros proyectos de software desde la primera semana del proceso de descubrimiento. Esta guía explica exactamente qué significa eso en la práctica — los conceptos legales traducidos en decisiones de ingeniería, los patrones que hacen sostenible el cumplimiento y los errores que vemos con más frecuencia en las bases de código que llegan a nuestra mesa para trabajos de corrección.

---

El GDPR en una Frase

El Reglamento General de Protección de Datos (UE 2016/679) es la ley de protección de datos que se aplica a cualquier organización que trate datos personales de personas en la UE o el Reino Unido, independientemente del lugar donde esté ubicada dicha organización. Si tiene usuarios en la UE o el Reino Unido, le aplica.

En términos prácticos, exige seis cosas:

• Base legal — todo acto de tratamiento de datos personales debe tener una justificación legal.
• Transparencia — las personas deben ser informadas claramente sobre qué datos se recopilan y por qué.
• Minimización de datos — solo se pueden recopilar los datos necesarios para el fin declarado.
• Derechos — los individuos tienen derecho a acceder, corregir, suprimir y exportar sus datos.
• Seguridad — debe proteger los datos personales con medidas técnicas y organizativas adecuadas.
• Responsabilidad proactiva — debe ser capaz de demostrar el cumplimiento, no solo afirmarlo.

La multa máxima por una infracción grave es de 20 millones de euros o el 4 % de la facturación global anual — la que sea mayor. La ICO (el regulador del Reino Unido) y las autoridades de supervisión de la UE han demostrado que están dispuestas a aplicar esas cifras. British Airways fue multada con 20 millones de libras. Amazon fue multada con 746 millones de euros. Estos no son casos extremos exclusivos de grandes multinacionales negligentes; las pequeñas y medianas empresas también se enfrentan a sanciones, y el daño reputacional derivado de una resolución sancionadora pública puede ser más perjudicial que la propia multa.

---

Privacidad por Diseño: Qué Significa en la Práctica

La privacidad por diseño está recogida directamente en el Artículo 25 del GDPR. No es una orientación opcional — es una obligación legal. El reglamento exige que la protección de datos se considere en el momento de diseñar los sistemas y procesos, no como una idea posterior.

Los siete principios fundacionales de la privacidad por diseño, traducidos en decisiones de ingeniería, se ven así:

1. Proactivo, No Reactivo

Diseñar para la privacidad antes de que surja un problema. En términos de software: llevar a cabo una Evaluación de Impacto en la Protección de Datos (EIPD) durante el descubrimiento, antes de escribir una sola línea de código, para cualquier funcionalidad que implique el tratamiento a gran escala de datos sensibles.

2. La Privacidad como Configuración Predeterminada

El comportamiento predeterminado del sistema debe ser la opción más protectora de la privacidad. Los usuarios no deberían tener que actuar para proteger su privacidad — deberían tener que actuar para reducirla. En términos de software: los correos electrónicos de marketing son opt-in, no opt-out; las cookies analíticas están desactivadas hasta ser aceptadas; las funciones de compartición en redes sociales no están habilitadas de antemano.

3. Privacidad Integrada en el Diseño

La privacidad no es una capa adicional sobre la arquitectura — es parte de ella. En términos de software: el modelo de datos separa la información de identificación personal de los datos transaccionales desde el principio; los microservicios están delimitados para que solo los que necesitan datos PII puedan acceder a ellos; la infraestructura de registro elimina o aplica hash a los identificadores antes de escribirlos en los almacenes de registros centralizados.

4. Funcionalidad Plena

La privacidad no debe tener un coste en funcionalidad. No debería ser necesario elegir entre un producto útil y uno conforme. En términos de software: la analítica anonimizada puede seguir ofreciendo información significativa sobre el producto; la personalización basada en consentimiento puede seguir proporcionando una buena experiencia de usuario.

5. Seguridad Extremo a Extremo

Protección durante todo el ciclo de vida del dato. En términos de software: cifrado en reposo, cifrado en tránsito, eliminación segura cuando los datos ya no son necesarios, y no solo en la capa de aplicación — también en la capa de base de datos y almacenamiento.

6. Visibilidad y Transparencia

Los usuarios deben poder ver qué datos se conservan sobre ellos y qué se hace con ellos. En términos de software: un portal de autoservicio para solicitudes de acceso de los interesados, una política de privacidad clara y precisa, y registros de auditoría que el equipo de cumplimiento pueda realmente leer.

7. Respeto por la Privacidad del Usuario

Situar los intereses del usuario en primer lugar. En términos de software: las políticas de retención de datos son aplicadas por la aplicación, no se dejan para una limpieza manual; la eliminación se propaga por todos los sistemas, incluidas las copias de seguridad y las cachés.

---

Base Legal para el Tratamiento de Datos

Esta es el área donde con más frecuencia observamos malentendidos fundamentales en proyectos de software — no porque los desarrolladores sean negligentes, sino porque los conceptos legales tienen consecuencias técnicas que son fáciles de pasar por alto.

El GDPR define seis bases legales para el tratamiento de datos personales. Las cuatro más relevantes para la mayoría de los productos de software son:

Base Legal	Cuándo Aplica	Implicación Técnica
Consentimiento	Marketing, analítica opcional, cookies no esenciales	Debe ser libre, específico, informado e inequívoco. Debe ser revocable. Requiere un registro de consentimiento con marca de tiempo.
Contrato	Tratamiento necesario para prestar un servicio al que el usuario se ha suscrito	No se requiere consentimiento separado, pero el tratamiento debe ser genuinamente necesario para el contrato.
Interés Legítimo	Analítica empresarial, prevención del fraude, seguridad de la red	Requiere una Evaluación de Interés Legítimo. Debe superar una prueba de equilibrio frente a los derechos individuales.
Obligación Legal	Registros fiscales, comprobaciones de blanqueo de capitales	Debe poder citar la ley específica. No puede utilizarse como comodín.

El motivo por el que elegir la base incorrecta es un problema técnico y no solo legal:

Si se basa en el consentimiento pero luego trata datos de formas para las que los usuarios no han consentido específicamente, necesitará obtener el consentimiento de nuevo — lo que implica volver a contactar con su base de usuarios y potencialmente perder una gran proporción de ellos. Si alega interés legítimo pero no ha realizado una Evaluación de Interés Legítimo, puede que necesite eliminar datos ya recopilados y rediseñar el flujo de datos que dependía de ellos.

La base legal también determina qué derechos son aplicables. Bajo el consentimiento, los usuarios tienen un derecho absoluto a la supresión. Bajo el contrato, el derecho a la supresión puede denegarse si los datos siguen siendo necesarios para cumplir el contrato. Esto afecta a si el flujo de "eliminar cuenta" debe propagarse por todas las tablas o puede conservar algunos registros.

Nuestra recomendación: Documente la base legal de cada actividad de tratamiento de datos en un Registro de Actividades de Tratamiento (RAT) antes de que se tomen las decisiones de arquitectura. Cambiará esas decisiones.

---

Implementación de la Gestión del Consentimiento

La gestión del consentimiento es el área más visible para los usuarios finales — y el área donde las implementaciones más frecuentemente no alcanzan el estándar legal.

Qué Requiere un Consentimiento Válido

Bajo el GDPR, el consentimiento debe ser:

• Libre — el consentimiento condicionado (debe aceptar las cookies para usar el sitio) no es consentimiento válido para cookies no esenciales.
• Específico — el consentimiento para analítica no cubre el consentimiento para segmentación publicitaria.
• Informado — los usuarios deben saber a qué están consintiendo antes de dar su consentimiento.
• Inequívoco — las casillas pre-marcadas no constituyen consentimiento. El silencio no constituye consentimiento.
• Revocable — retirar el consentimiento debe ser tan fácil como darlo.

Implementación del Consentimiento de Cookies

Un banner de cookies técnicamente conforme debe:

1. Bloquear la carga de todos los scripts no esenciales hasta que se dé el consentimiento — no solo establecer una cookie que indique la preferencia.
2. Registrar el consentimiento con una marca de tiempo, la versión de la política de privacidad mostrada y las categorías específicas aceptadas.
3. Permitir el consentimiento granular por categoría (necesarias, analítica, marketing, preferencias).
4. Ofrecer un mecanismo para retirar el consentimiento en cualquier momento.

Esto significa que la configuración de su gestor de etiquetas debe estar condicionada al estado del consentimiento. Si utiliza Google Tag Manager, los scripts de las categorías de analítica y publicidad solo deben activarse después de que se establezcan las señales de consentimiento correspondientes. Implementar esto incorrectamente — mostrando un banner pero cargando scripts independientemente — es una de las infracciones más comunes que observamos.

Plataformas de Gestión del Consentimiento

Para la mayoría de los proyectos, implementar la gestión del consentimiento desde cero no es la opción correcta. Las principales opciones son:

OneTrust — nivel empresarial, altamente configurable, se integra con la mayoría de las plataformas de gestión del consentimiento y catálogos de datos. Adecuado para organizaciones más grandes con necesidades de consentimiento complejas.

Cookiebot (ahora Usercentrics) — buena opción para el mercado medio, escanea automáticamente cookies y las categoriza, fácil integración mediante etiqueta de script o GTM.

Implementación personalizada — adecuada para aplicaciones que tienen flujos de consentimiento inusuales (por ejemplo, un SaaS B2B donde el empleador del usuario final es el responsable del tratamiento) o donde las plataformas existentes no se adaptan a los requisitos de UX. Requiere un diseño cuidadoso del esquema de registro del consentimiento.

Centro de Preferencias de Marketing

Más allá de las cookies, los productos que envían comunicaciones de marketing deben implementar un centro de preferencias — una interfaz orientada al usuario donde los individuos pueden gestionar sus preferencias de comunicación. Esto debe estar respaldado por una base de datos que almacene:

• Estado del consentimiento por canal (correo electrónico, SMS, notificaciones push)
• Marca de tiempo de cada cambio
• Origen del consentimiento (formulario de registro, proceso de compra, actualización del centro de preferencias)
• Las categorías de marketing específicas a las que el usuario ha dado su opt-in

Estos datos deben verificarse en el momento del envío, no solo en el momento de la captura — lo que significa que la lógica de envío de correos electrónicos debe consultar el estado de consentimiento actual, no basarse en un indicador establecido en el momento del registro.

---

La Minimización de Datos en la Práctica

La minimización de datos — Artículo 5(1)(c) — es el principio según el cual solo se deben recopilar los datos personales necesarios para el fin específico declarado. Suena sencillo. En la práctica, requiere una disciplina activa porque la tendencia natural de los equipos de software es capturar tantos datos como sea posible "por si resultan útiles más adelante".

Inventario de PII y Clasificación de Datos

El punto de partida es saber qué datos personales se están recopilando realmente. Un inventario de PII es un catálogo estructurado de cada dato que gestiona el sistema, etiquetado con:

• Qué es (nombre, correo electrónico, dirección IP, historial de compras, datos de salud)
• Por qué se recopila (necesario para el contrato, analítica, obligación legal)
• Dónde se almacena (qué base de datos, qué servicio de terceros)
• Cuánto tiempo se conserva
• Quién tiene acceso a él

Este ejercicio suele sorprender a los equipos. Direcciones IP en registros del servidor que nadie había considerado. Cadenas de user-agent escritas en una base de datos junto a registros de cuentas. Direcciones completas almacenadas para una función de entrega que fue discontinuada hace dieciocho meses.

Patrones Arquitectónicos para la Minimización

Más allá del inventario, la propia arquitectura debe hacer de la minimización el camino de menor resistencia:

• Separe los almacenes de PII de los almacenes transaccionales. Si su base de datos de analítica realiza joins directamente sobre direcciones de correo electrónico, es un problema de minimización de datos. Utilice identificadores seudónimos en los flujos de analítica y mantenga la tabla de correspondencia en un servicio restringido.
• Recopile en el momento de necesidad, no de forma especulativa. No solicite un número de teléfono en la creación de la cuenta si los números de teléfono solo se necesitan para la autenticación de dos factores — solicítelo cuando el usuario active la 2FA.
• Implemente la retención en código, no en documentos de política. Una política que dice que los datos se eliminan después de dos años no es cumplimiento. Un proceso programado que impone la eliminación después de dos años, con registros que lo demuestren, sí lo es.

---

Derechos de los Interesados

El GDPR otorga a los individuos ocho derechos. Los cuatro que requieren la implementación técnica más significativa son:

Derecho de Acceso (Solicitud de Acceso del Interesado)

Un individuo puede solicitar una copia de todos los datos personales que se conserven sobre él. Dispone de un mes natural para responder. La respuesta debe estar en un formato de uso habitual y legible por máquina.

Implementación técnica: Construya una capa de agregación de datos que pueda recopilar información sobre un usuario de cada servicio que la conserve — su base de datos de aplicación, su plataforma de analítica, su CRM, su sistema de tickets de soporte — y compilarla en una exportación estructurada. Para la mayoría de las aplicaciones, esta es una tarea de ingeniería no trivial, que es exactamente la razón por la que debe planificarse en la fase de arquitectura en lugar de gestionarse de manera improvisada cuando llega una solicitud.

Para aplicaciones de alto volumen, un portal de autoservicio para solicitudes de acceso que genere la exportación automáticamente es tanto una mejora de cumplimiento como operacional.

Derecho de Supresión (Derecho al Olvido)

Un individuo puede solicitar la eliminación de sus datos personales. El derecho no es absoluto — puede denegarse cuando los datos son necesarios para obligaciones legales, por interés público, o cuando el interés legítimo prevalece sobre los derechos individuales — pero para la mayoría de las aplicaciones de consumo, una solicitud de supresión válida debe ser atendida.

Implementación técnica: La eliminación debe propagarse a todos los lugares donde vivan los datos. Esto incluye:

• Base de datos de la aplicación (eliminación inmediata o seudonimización de los campos PII)
• Copias de seguridad (un proceso claro para excluir registros específicos de la restauración de copias de seguridad, o un calendario de retención para las copias de seguridad que limite cuánto tiempo persisten los datos eliminados)
• Cachés (invalidación de caché en el momento de la eliminación)
• Servicios de terceros (solicitudes de eliminación al CRM, plataforma de correo electrónico, herramienta de analítica, sistema de soporte)
• Datos derivados (conjuntos de datos de entrenamiento de ML, agregados de analítica que podrían contener datos a nivel individual)

Derecho a la Portabilidad

Un individuo puede solicitar sus datos en un formato estructurado, de uso habitual y legible por máquina — normalmente JSON o CSV — con el fin de transferirlos a otro servicio.

Implementación técnica: Diseñe el formato de exportación de datos de manera anticipada. Debe abarcar los datos que el usuario proporcionó activamente (información de cuenta, contenido que creó, preferencias que estableció) en lugar de datos inferidos o derivados. El endpoint de exportación debe estar autenticado, con límite de tasa y auditado.

Derecho de Rectificación

Un individuo puede solicitar la corrección de datos personales inexactos.

Implementación técnica: Cada campo PII del sistema necesita una ruta de edición — lo que parece obvio pero no siempre es así. Los registros de eventos inmutables que contienen datos personales presentan un desafío particular; el enfoque recomendado es la seudonimización en lugar de la corrección de registros históricos.

---

Residencia de Datos y Encargados del Tratamiento de Terceros

Una de las implicaciones técnicas más significativas e infravaloradas del GDPR es la restricción sobre la transferencia de datos personales fuera de la UE/EEE (y fuera del Reino Unido en virtud del UK GDPR).

El Panorama Post-Schrems II

La sentencia Schrems II del Tribunal de Justicia de la UE en 2020 invalidó el marco del Escudo de Privacidad UE-EE.UU., que había sido previamente el mecanismo legal que permitía transferir datos personales de la UE a procesadores con sede en EE.UU. El mecanismo de sustitución son las Cláusulas Contractuales Tipo (CCT) — cláusulas contractuales preaprobadas que ambas partes firman antes de que tenga lugar cualquier transferencia.

En la práctica, esto significa que si utiliza cualquier herramienta SaaS con sede en EE.UU. — una plataforma de analítica alojada en EE.UU., los centros de datos de un proveedor de nube estadounidense, un CRM con sede en EE.UU. — necesita:

1. Verificar si el proveedor tiene CCT disponibles (la mayoría de los grandes proveedores sí las tienen).
2. Ejecutar dichas CCT antes de transferir datos personales.
3. Realizar una Evaluación del Impacto de la Transferencia para verificar que las leyes del país receptor no socavan las protecciones de las CCT.

Auditoría de Sus Proveedores Cloud y Stack SaaS

Una auditoría de transferencia de datos debe documentar cada servicio de terceros al que su aplicación envía datos personales, y para cada uno capturar:

• Mecanismo legal de transferencia (CCT, decisión de adecuación, excepción)
• Ubicación(es) del centro de datos
• Subencargados utilizados por ese proveedor
• Enlace al Acuerdo de Tratamiento de Datos (ATD) ejecutado

Esta lista es más extensa de lo que la mayoría de los equipos espera. Considere: su proveedor de alojamiento, su CDN, su servicio de envío de correo electrónico, su herramienta de monitoreo de errores, su herramienta de monitoreo del rendimiento de la aplicación, su plataforma de soporte al cliente, su CRM, su herramienta de automatización de marketing, su widget de chat en vivo, su plataforma de analítica y cualquier script de terceros cargado en su frontend.

Acuerdos de Tratamiento de Datos

Cada tercero que trate datos personales en su nombre debe firmar un Acuerdo de Tratamiento de Datos (ATD). Este es un requisito contractual en virtud del Artículo 28 del GDPR, no una mitigación de riesgo opcional. La mayoría de los proveedores SaaS de confianza disponen de un ATD estándar en su centro de confianza o a solicitud. La ausencia de un ATD con un proveedor es en sí misma una infracción del cumplimiento, independientemente de si ha ocurrido algún incidente con los datos.

---

Requisitos de Seguridad Bajo el GDPR

El Artículo 32 exige a las organizaciones que implementen "medidas técnicas y organizativas apropiadas" para garantizar un nivel de seguridad adecuado al riesgo. El GDPR evita deliberadamente especificar estándares técnicos exactos — pero los siguientes se entienden ampliamente como requisitos de referencia para la mayoría de las aplicaciones.

Cifrado

• En reposo: Cifrado de la base de datos (AES-256 es el estándar de referencia), copias de seguridad cifradas, almacenamiento de archivos cifrado. Cifrado a nivel de aplicación para campos especialmente sensibles (datos de salud, datos financieros) para que los administradores de bases de datos no puedan leerlos en texto plano.
• En tránsito: TLS 1.2 como mínimo, TLS 1.3 preferido. Cabeceras HSTS. Sin contenido mixto. Monitoreo de certificados.

Seudonimización

Reemplazar la información directamente identificadora por identificadores seudónimos siempre que sea posible — especialmente en flujos de analítica, archivos de registro y bases de datos de informes. Esto no elimina las obligaciones del GDPR (los datos seudonimizados siguen siendo datos personales bajo el GDPR) pero reduce significativamente el impacto de una brecha.

Controles de Acceso

• Control de acceso basado en roles con principios de mínimo privilegio.
• Autenticación multifactor para todo acceso interno a sistemas de producción.
• Revisiones de acceso periódicas — especialmente cuando los miembros del equipo cambian de función o se van.
• Entornos de producción y desarrollo separados sin PII de producción en sistemas de desarrollo.

Registro de Auditoría

Un registro de auditoría completo recoge quién accedió o modificó datos personales, cuándo, desde dónde y por qué. Esto tiene dos propósitos: permite la detección de brechas y demuestra la responsabilidad proactiva ante los reguladores. El propio registro debe estar protegido contra manipulaciones.

Detección de Brechas y la Regla de las 72 Horas

El Artículo 33 exige la notificación a la autoridad supervisora (la ICO para las organizaciones del Reino Unido, la autoridad de la UE correspondiente para las organizaciones de la UE) dentro de las 72 horas de tener conocimiento de una brecha de datos personales, cuando la brecha sea probable que resulte en un riesgo para los individuos.

Esto significa que su monitoreo de seguridad debe ser capaz de detectar brechas con rapidez — una detección lenta y una escalada interna lenta consumirán ese plazo de 72 horas. Su proceso de respuesta a incidentes debe incluir una evaluación formal de si una brecha alcanza el umbral de notificación.

---

UK GDPR Post-Brexit

Tras el Brexit, el Reino Unido ya no está sujeto al GDPR de la UE. En cambio, el UK GDPR — que es el GDPR de la UE traspuesto al derecho del Reino Unido con algunas modificaciones — se aplica a las organizaciones que tratan datos personales de personas en el Reino Unido.

En la práctica, el UK GDPR y el GDPR de la UE son sustancialmente idénticos en la mayoría de los aspectos. Los mismos principios, los mismos derechos, las mismas bases legales y niveles de multa similares se aplican. Las principales diferencias prácticas son:

• La ICO (Oficina del Comisionado de Información) es la autoridad supervisora para el UK GDPR, no las autoridades supervisoras de la UE.
• La UE ha concedido al Reino Unido una decisión de adecuación, lo que significa que los datos personales de la UE pueden fluir al Reino Unido sin CCT (en el momento de escribir esto — las decisiones de adecuación pueden revocarse).
• Las organizaciones del Reino Unido que también traten datos de residentes de la UE deben cumplir tanto el UK GDPR como el GDPR de la UE, y puede que necesiten nombrar un representante en la UE.
• Las CCT del Reino Unido (denominadas Acuerdo Internacional de Transferencia de Datos o AITD) difieren en formato de las CCT de la UE, aunque las protecciones sustantivas están alineadas.

Para la mayoría de las empresas del Reino Unido, las obligaciones prácticas del día a día son casi idénticas a las que exige el GDPR de la UE. La complejidad surge para las empresas que operan en ambas jurisdicciones — especialmente aquellas con usuarios tanto del Reino Unido como de la UE, o las que utilizan procesadores con sede en la UE.

---

Errores Comunes del GDPR en Proyectos de Software

Estos son los patrones que vemos con más frecuencia cuando revisamos bases de código existentes en busca de brechas de cumplimiento:

Almacenar más datos de los que requiere el fin declarado. Formularios de registro que solicitan la fecha de nacimiento "para personalización" pero nunca la utilizan. Integraciones de CRM que sincronizan todos los campos del usuario aunque el CRM no los necesite todos. El hábito de recopilar datos de forma especulativa está profundamente arraigado en la cultura del producto y requiere una resistencia activa.

Sin políticas de retención de datos aplicadas en código. La política de privacidad dice que los datos se conservan durante tres años. La base de datos tiene registros que se remontan a ocho años sin ningún proceso de eliminación a la vista. Un documento de política que no es aplicado por la aplicación no es cumplimiento — es responsabilidad.

Scripts de terceros olvidados que transfieren datos a EE.UU. Un equipo de marketing añade un widget de chat en vivo. Un desarrollador añade una herramienta de mapa de calor. Otro desarrollador añade una fuente de terceros. Ninguno de estos aparece en el registro de ATD. Cada uno está transfiriendo direcciones IP de usuarios — y potencialmente más — a un servidor con sede en EE.UU. sin un mecanismo legal de transferencia y sin ser bloqueado por el sistema de gestión del consentimiento.

Ausencia de Acuerdos de Tratamiento de Datos con proveedores cloud. AWS, GCP y Azure tienen ATD disponibles y la mayoría de los clientes los ejecutan automáticamente al crear la cuenta. Pero los servicios complementarios — una herramienta de monitoreo especializada, un proveedor de correo electrónico específico, una pequeña plataforma de retroalimentación de clientes — frecuentemente quedan sin ATD ejecutados simplemente porque nadie se acordó de solicitarlo.

Confundir el consentimiento con cualquier interacción. Continuar enviando correos electrónicos de marketing porque un usuario "no se ha dado de baja" no es consentimiento. Tratar el registro en la cuenta como consentimiento para la analítica no es consentimiento. Estos patrones eran comunes antes del GDPR y siguen siendo comunes hoy.

Sin proceso para las solicitudes de acceso de los interesados. Cuando llega una solicitud de acceso, alguien debe ser capaz de extraer todos los datos conservados sobre un individuo en todos los sistemas en el plazo de un mes. Si no existe un proceso definido ni un mecanismo técnico para hacerlo, la primera solicitud será tanto incumplidora como operativamente caótica.

---

Cómo Construimos Software Conforme al GDPR en Cyberbeak

La privacidad por diseño está integrada en la manera en que gestionamos cada proyecto, no se trata como una auditoría de última hora.

Durante el descubrimiento, realizamos un ejercicio de mapeo del flujo de datos para cada producto — documentando qué datos personales se recopilarán, dónde se almacenarán, qué servicios de terceros los recibirán y cuál será la base legal de cada actividad de tratamiento. Esto suele poner de manifiesto decisiones que deben tomarse antes de que comience el trabajo de arquitectura: si utilizar una herramienta SaaS con sede en EE.UU. o una alternativa europea, cómo estructurar el modelo de consentimiento, si se requiere una EIPD.

Para proyectos que implican tratamiento de alto riesgo — datos de salud, datos financieros, elaboración de perfiles a gran escala, datos sobre menores — realizamos una Evaluación de Impacto en la Protección de Datos formal antes de que comience el desarrollo. La EIPD documenta los riesgos, las medidas de mitigación y el riesgo residual, y es revisada por quien ocupe el rol de DPO para el cliente (o podemos proporcionar esa función como servicio).

Durante la arquitectura, diseñamos la separación de PII, el registro de auditoría y la retención de datos en el modelo de datos desde el principio. Documentamos el Registro de Actividades de Tratamiento a medida que avanzamos, para que refleje lo que el sistema realmente hace en lugar de lo que alguien escribió en un documento de política.

Durante la construcción, los flujos de consentimiento se construyen según el estándar legal — no como una adición cosmética posterior. La funcionalidad de solicitud de acceso y supresión se delimita como una característica de primer nivel, no como un proceso manual. Las integraciones de terceros se evalúan para el cumplimiento de la transferencia de datos antes de ser añadidas a la base de código.

Durante la entrega, proporcionamos al cliente un RAT completo, un diagrama del flujo de datos y documentación de todos los encargados del tratamiento de terceros y su estado de ATD — no porque estemos obligados, sino porque un cliente que comprende su postura de cumplimiento tiene muchas menos probabilidades de introducir infracciones después de la entrega.

No somos abogados, y trabajamos junto a asesores legales para clientes que necesitan opiniones jurídicas formales. Pero la implementación técnica del cumplimiento del GDPR es plenamente una disciplina del desarrollo de software, y es una que tomamos en serio.

---

Preguntas Frecuentes

¿Necesita una pequeña startup preocuparse por el GDPR?

Sí — el GDPR se aplica a cualquier organización que trate datos personales de individuos de la UE o el Reino Unido, independientemente del tamaño o los ingresos de la organización. No existe exención para pequeñas empresas. Existen algunos requisitos más ligeros para organizaciones más pequeñas (aquellas con menos de 250 empleados pueden tener obligaciones reducidas del Registro de Actividades de Tratamiento en algunos casos), pero las obligaciones principales — base legal, transparencia, minimización de datos, seguridad y derechos — se aplican universalmente. La ICO ha publicado resoluciones sancionadoras contra pequeñas empresas y autónomos.

¿Cuáles son las multas por infracciones del GDPR?

Existen dos niveles. El nivel inferior se aplica a infracciones de obligaciones como registros de consentimiento, requisitos de encargados del tratamiento de datos y avisos de privacidad — multas de hasta 10 millones de euros o el 2 % de la facturación global anual. El nivel superior se aplica a infracciones de los principios fundamentales del GDPR — base legal, minimización de datos, derechos de los interesados y transferencias internacionales — multas de hasta 20 millones de euros o el 4 % de la facturación global anual. La ICO tiene su propia estructura de multas equivalente bajo el UK GDPR, limitada a 17,5 millones de libras o el 4 % de la facturación global.

¿Es conforme al GDPR utilizar AWS (o GCP o Azure)?

Los principales proveedores de nube han invertido significativamente en infraestructura de cumplimiento del GDPR y todos ofrecen Acuerdos de Tratamiento de Datos y la posibilidad de elegir regiones de centros de datos en la UE. Utilizar AWS en la región de Fráncfort con un ATD ejecutado y CCT para cualquier transferencia fuera del EEE es coherente con el GDPR. Utilizar AWS sin un ATD ejecutado, o tratar datos personales de la UE en una región de EE.UU. sin un mecanismo legal de transferencia, no lo es. El proveedor de nube es un encargado del tratamiento; usted es el responsable del tratamiento; ambos tienen obligaciones y ambos deben documentar correctamente la relación.

¿Necesitamos un Delegado de Protección de Datos?

Un DPO es obligatorio en virtud del Artículo 37 para las autoridades públicas, las organizaciones cuyas actividades principales implican la monitorización sistemática a gran escala de individuos, y las organizaciones cuyas actividades principales implican el tratamiento a gran escala de datos de categoría especial (datos sensibles). Para muchas empresas, estas condiciones no se aplican, y un DPO no es legalmente obligatorio — aunque a menudo sigue siendo una buena práctica designar a alguien con responsabilidad en materia de protección de datos. Si tiene dudas, la ICO ha publicado orientación sobre cuándo se requiere un DPO.

¿Qué significa el UK GDPR para nuestra empresa tras el Brexit?

Si solo tiene usuarios en el Reino Unido y trata datos personales únicamente dentro del Reino Unido, se aplica el UK GDPR y la ICO es su regulador. Si también tiene usuarios en la UE, se aplica adicionalmente el GDPR de la UE, y puede que necesite un representante en la UE. Las transferencias de datos del Reino Unido a la UE están permitidas bajo la decisión de adecuación de la UE para el Reino Unido (que debe monitorearse por posibles cambios). Las transferencias de la UE al Reino Unido están igualmente permitidas. Las organizaciones del Reino Unido que transfieran datos a terceros países fuera del Reino Unido deben utilizar los propios mecanismos de transferencia del Reino Unido — el AITD o el Addendum a las CCT de la UE — en lugar de las CCT de la UE directamente.

---

Si está construyendo un nuevo producto y desea hacer bien el GDPR desde el principio — o si tiene una aplicación existente que necesita una revisión de cumplimiento — podemos ayudarle. Nuestro proceso de descubrimiento incluye el mapeo del flujo de datos y una evaluación de privacidad por diseño como estándar, y hemos trabajado con empresas de fintech, healthtech, comercio electrónico y SaaS B2B para construir sistemas que son tanto genuinamente útiles como genuinamente conformes.

Póngase en contacto con nosotros para hablar sobre su proyecto.