RGPD para equipos técnicos:

lo que de verdad cambia en tu código y tu infraestructura

Gobernanza y normativa  |  unfantasmaenelsistema.com

El Reglamento General de Protección de Datos se ha explicado mil veces para juristas y para responsables de negocio, y casi nunca para quien diseña el esquema de la base de datos, escribe el endpoint que exporta un perfil o decide cuánto tiempo se guardan los logs de acceso. El resultado es un patrón conocido: la organización tiene un registro de actividades impecable en un PDF, y al mismo tiempo un microservicio que escribe el DNI del cliente en texto claro en un fichero de log que se retiene tres años «por si acaso».

Este artículo traduce el RGPD al lenguaje de quien mantiene los sistemas: qué obligaciones se convierten en decisiones de arquitectura, de modelo de datos y de operación, y cómo implementarlas sin romper la integridad referencial ni las copias de seguridad. No es asesoramiento jurídico: la calificación de un tratamiento, la base de licitud aplicable o la obligación de designar un delegado de protección de datos se deciden con el DPO y con soporte legal, no en una revisión de código.

1. El RGPD es también un problema de ingeniería

El reglamento no impone tecnologías concretas, pero sí resultados que solo se consiguen con decisiones técnicas. Dos principios del artículo 5 marcan el diseño desde el primer día. La minimización obliga a tratar solo los datos adecuados, pertinentes y limitados a lo necesario: cada columna de una tabla debería poder justificarse contra una finalidad. La limitación del plazo de conservación obliga a borrar o anonimizar cuando esa finalidad se cumple: un dato sin fecha de caducidad definida es un incumplimiento en potencia.

El artículo 25, protección de datos desde el diseño y por defecto, lo hace explícito: las medidas se integran en el desarrollo, y la configuración por defecto es siempre la más protectora. Si al dar de alta a un usuario todas las casillas de compartición vienen marcadas, el producto nace incumpliendo.

2. Base de licitud y minimización en el modelo de datos

Todo tratamiento necesita una de las seis bases del artículo 6, y esa base condiciona lo que el sistema puede y no puede hacer con el dato.

En la práctica: antes de añadir un campo, identifica su finalidad y su base. Las categorías especiales del artículo 9 (salud, biometría, ideología, orientación sexual, afiliación sindical) requieren una condición adicional del artículo 9.2 y casi siempre cifrado reforzado y control de acceso estricto. Evita recogerlos si no es imprescindible.

3. Seudonimización y cifrado: el artículo 32

El artículo 32 pide medidas técnicas y organizativas apropiadas al riesgo, y menciona expresamente cuatro: seudonimización, cifrado, garantía continuada de confidencialidad-integridad-disponibilidad-resiliencia, y un proceso de verificación y evaluación regular de su eficacia.

Un patrón habitual y efectivo es separar en dos tablas los datos identificativos (nombre, correo, documento) de los datos de comportamiento, unidas solo por un identificador interno sin significado. El grueso de las consultas analíticas trabaja contra la tabla seudonimizada, y el acceso a la tabla de identidades queda auditado y restringido.

-- Datos de identidad: acceso restringido, cifrado a nivel de campo, auditado
CREATE TABLE persona_identidad (
    persona_id     BIGINT PRIMARY KEY,
    nombre_cifrado  BYTEA NOT NULL,
    email_cifrado   BYTEA NOT NULL,
    creado_en       TIMESTAMPTZ NOT NULL DEFAULT now()
);
 
-- Datos de actividad: solo el token interno, sin PII directa
CREATE TABLE evento_uso (
    evento_id    BIGINT PRIMARY KEY,
    persona_id   BIGINT NOT NULL REFERENCES persona_identidad,
    accion       TEXT NOT NULL,
    ocurrido_en  TIMESTAMPTZ NOT NULL,
    borrar_tras  DATE NOT NULL   -- fecha de caducidad explicita por fila
);

4. Registro de actividades del tratamiento (artículo 30)

El artículo 30 obliga a mantener un inventario de los tratamientos: finalidad, categorías de interesados y de datos, destinatarios, transferencias internacionales, plazos de supresión previstos y descripción general de las medidas de seguridad. Es un documento de la organización, pero se nutre de información que solo el equipo técnico conoce con precisión.

• Qué sistemas y bases de datos participan en cada tratamiento y qué campos personales contienen
• A qué encargados se envían datos: proveedores de correo, analítica, alojamiento, pasarela de pago, soporte — cada uno necesita un contrato de encargo del artículo 28
• Dónde se alojan físicamente los datos y sus copias (país y proveedor)
• Qué plazo de conservación aplica cada tabla y cómo se ejecuta el borrado

Mantener este mapa actualizado es más fácil si vive cerca del código: un fichero versionado que describe cada tabla con datos personales, su finalidad, su base y su retención, revisado en cada cambio de esquema, evita que el registro formal quede obsoleto al mes siguiente.

5. Logs con datos personales

Los registros de acceso, las trazas de aplicación y la telemetría contienen casi siempre datos personales: direcciones IP, identificadores de usuario, correos en mensajes de error, a veces el cuerpo entero de una petición. Son un tratamiento más y necesitan su base de licitud —normalmente interés legítimo en la seguridad— y su plazo de conservación.

6. Derechos ARSOPL sin romper el sistema

El capítulo III da al interesado derecho de Acceso, Rectificación, Supresión, Oposición, Portabilidad y Limitación del tratamiento, más el derecho a no ser objeto de decisiones únicamente automatizadas. La organización tiene un mes para responder. Cada derecho es una funcionalidad, no un proceso manual sostenible a escala.

6.1 Supresión y backups

No se puede reescribir una copia de seguridad para eliminar a una persona, y el RGPD no lo exige. El enfoque aceptado: documenta que las copias son inmutables y tienen una rotación definida (por ejemplo 35 días); ejecuta la supresión en los sistemas vivos de inmediato; y mantén una lista de supresiones pendientes que se vuelva a aplicar si alguna vez hay que restaurar un backup. Así el dato borrado no reaparece por la puerta de atrás de una restauración.

6.2 Borrado como proceso, no como evento

La forma sostenible de cumplir la limitación de plazo es un proceso periódico que recorre las tablas con datos personales y actúa sobre las filas caducadas —anonimizando cuando hay claves foráneas o una obligación de conservar el registro contable, borrando cuando se puede—. La columna borrar_tras del ejemplo anterior convierte ese barrido en una consulta trivial.

7. Brechas de seguridad: el reloj de 72 horas

Ante una violación de seguridad que afecte a datos personales, el artículo 33 obliga a notificar a la autoridad de control —en España, la AEPD— sin dilación indebida y, cuando sea factible, en un plazo máximo de 72 horas desde que se tiene constancia, salvo que sea improbable que suponga un riesgo para los derechos de las personas. Si el riesgo es alto, el artículo 34 obliga además a comunicarlo a los propios afectados.

Para el equipo técnico esto significa tener antes del incidente: un procedimiento de respuesta con roles claros, capacidad de determinar rápido qué datos y cuántos registros se han visto afectados (aquí ayudan los logs bien hechos), y un registro interno de todas las brechas —también las que no se notifican— que el artículo 33.5 exige conservar.

8. Transferencias internacionales y EIPD

Sacar datos personales fuera del Espacio Económico Europeo —o usar un proveedor que lo haga— exige una garantía del capítulo V: una decisión de adecuación de la Comisión Europea para ese país, o cláusulas contractuales tipo acompañadas de un análisis de impacto de la transferencia que valore la legislación del país de destino, o normas corporativas vinculantes. En términos prácticos, revisa dónde alojan los datos tu proveedor cloud, tu herramienta de analítica, tu CRM y tu servicio de correo, y qué región tienes configurada.

La evaluación de impacto relativa a la protección de datos (EIPD, o DPIA) es obligatoria cuando un tratamiento pueda entrañar un alto riesgo: tratamiento a gran escala de categorías especiales, observación sistemática de zonas de acceso público, elaboración de perfiles con efectos significativos, uso de tecnologías novedosas. La AEPD publica una lista de tipos de tratamiento que la requieren. Conviene hacerla en fase de diseño, porque su resultado puede cambiar la arquitectura.

9. Privacidad desde el diseño: ejemplos concretos

• Formularios: cada campo tiene una finalidad; los opcionales se marcan como tales y no se almacenan si van vacíos
• Valores por defecto: visibilidad de perfil en «privado», compartición de datos con terceros desactivada, retención en el mínimo razonable
• Analítica: truncar la IP, desactivar identificadores persistentes salvo consentimiento, preferir métricas agregadas
• Entornos de preproducción: nunca con la base de datos de producción; usar datos sintéticos o un volcado anonimizado
• Exportaciones y informes: seudonimizados por defecto; la reidentificación es una acción separada y auditada
• Terceros: cada integración nueva pasa por revisión de qué datos recibe, con qué base y bajo qué contrato de encargo

Conclusión

El RGPD deja de parecer un texto ajeno cuando se traduce a las decisiones que el equipo técnico ya toma cada semana: qué columnas añadir, dónde poner el límite de retención, cómo separar identidad y actividad, qué escribe cada log y durante cuánto tiempo, y cómo se ejecuta un borrado sin romper nada. Casi todo se reduce a minimizar lo que se guarda, ponerle fecha de caducidad y saber en todo momento dónde está.

Hacerlo desde el diseño cuesta poco; añadirlo después, cuando el esquema ya está lleno de datos sin finalidad clara y los logs llevan años acumulando DNIs, cuesta mucho y casi siempre coincide con el peor momento posible: el de responder a una brecha o a una inspección.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)