Privacy by Design

Privacy by Design (GDPR)

1) De qué se trata y por qué

Privacy by Design (PbD) es el principio según el cual la privacidad se establece en el producto desde el principio: en los requisitos de negocio, arquitectura, código, procesos y operación. En términos de GDPR, esto se manifiesta en «privacy by design and by default» (minimizar las tarifas, la configuración predeterminada - lo más privado posible, transparencia y rendición de cuentas).

• Minimizar la recopilación y el procesamiento de datos personales (PDn).
• Garantizar legalidad, transparencia, corrección, limitación de objetivos y plazos.
• Reducir los riesgos (técnicos y jurídicos), simplificar la auditoría y demostrar la conformidad.

2) Roles, bases jurídicas y principios del RGPD

2. 1 Roles

Controlador (Controller): define los objetivos/medios de tratamiento.
Procesador (Processor): procesa el PDn en nombre del controlador del contrato DPA.
Sujeto de datos (Data Subject): el físico al que pertenecen los PDs.
DPO (Oficial de Protección de Datos): bajo demanda - control y asesoramiento independientes.

2. 2 Fundamentos jurídicos (seleccionamos y documentamos)

Consentimiento, contrato, interés legítimo, obligación legal, intereses vitales, tarea pública. Para cada uno - propósito, datos, retención, capacidad de revocación (para consentimiento).

2. 3 Principios de tratamiento (art. 5)

Legalidad, justicia, transparencia

Limitación del objetivo

Minimizar datos

Precisión

Restricción del almacenamiento

Integridad y privacidad

Rendición de cuentas (accountability): capacidad para probar el cumplimiento.

3) Proceso PbD en SDLC (referencia marco)

1. Iniciación: formulación de objetivos de procesamiento y bases legales, asignación de datos owner y punto DPO.
2. Kartirovanie de los datos (Data Mapping): las fuentes → los campos → el modelo confidencial → donde corren → quien lee → donde están → el plazo.
3. Evaluación de riesgos/DPIA: Modelo LINDDUN de amenazas a la privacidad, evaluación de impacto, medidas de reducción.
4. Soluciones arquitectónicas: selección de esquemas de minimización, pseudonimización, encriptación, delimitación.
5. Requisitos de UX/consentimiento/notificación: texto comprensible, consent granular, configuración predeterminada.
6. Implementación: impagos privados, telemetría segura, lógica sin secretos/PII.
7. Verificación: pruebas de privacidad, análisis estático, pruebas de unidad privada, protocolos DPIA.
8. Operación: procesos DSAR, retenciones y eliminación, monitoreo de incidentes, rugido de proveedores.
9. Revisión periódica: re-DPIA cuando los objetivos/tecnologías cambian.

4) Patrones de ingeniería PbD

4. 1 Minimización y descomposición

Recopilar sólo los campos necesarios; aplicar el perfil progresivo.
Separe el ID y el contenido: mantenga la clave de comunicación por separado (token/reference).

4. 2 Pseudonimización y anonimización

Seudonimización: mantenga el ID real por separado; la capa de trabajo ve el token.
Anonimato: use k-anonimato, l-diversity, t-closeness; para el análisis - privacidad diferencial (ε -budget).

4. 3 Control de acceso y separación de funciones

PoLP, ABAC/RBAC, segregación de duties, contornos separados para administradores y analistas.
Esos. medidas: mTLS, SSO/OIDC, tokens scoped, cuentas temporales para acceder a PDn.

4. 4 Encriptación y aislamiento

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Llaves separadas por arrendatario/dataset; crypto-eliminación para el «derecho al olvido».

4. 5 Retiro y eliminación

Políticas explícitas de TTL por campo/objetivo; auto-purge en paipelines; eliminación «bifásica» (lógica → física).
Para los backups - llaves separadas y ventanas cortas de almacenamiento de los snapshots personales.

4. 6 Telemetría privada y lógica

De forma predeterminada, sin PII; utilizar tokens/hashing con sal.
Enmascarar/tokenizar campos sensibles en el productor.

4. 7 UX privacidad y consentimiento

Consent granular por categoría (analítica, marketing, personalización).
«Impagos privados»: todo no es crítico - apagado hasta que esté de acuerdo.
La opción clara «Revocar consentimiento» y las notificaciones just-in-time en el nuevo uso.

5) DPIA y LINDDUN (corto)

DPIA (Evaluación de Impacto de Protección de Datos): se requiere con alto riesgo (monitoreo a gran escala, evaluación, nueva tecnología). Consiste en una descripción del tratamiento, necesidad/proporcionalidad, evaluación de riesgos, medidas de mitigación.
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Para cada amenaza, contramedidas (minimización, seudonimización, DP, transparencia, gestión de consentimiento, auditoría).

6) Transferencias transfronterizas

Averiguar las ubicaciones de almacenamiento/acceso de proveedores.
Utilizar SCC (cláusulas contractuales estándar) y realizar la Evaluación de impacto de transferencia.
Techmers: end-to-end cifrado, criptografía de cliente para datos especialmente sensibles, restricción de acceso remoto.

7) Proveedores y procesadores (Vendor Management)

Procesadores DPA/anidados, medidas técnicas y organizativas, subprocesadores - bajo control.
Ruidos y auditorías regulares; El derecho de inspección; Un plan de salida/migración (exportación de datos).

8) Derechos de los interesados (DSAR)

Acceso, rectificación, eliminación, restricción, portabilidad, objeción, no ser objeto de AADM (perfilado/automatización).
SLA y automatización: seguimiento de solicitudes, prueba de identificación, registro de respuestas.
Hooks técnicos en el producto: búsqueda rápida y exportación por ID; eliminación en cascada por retenciones.

9) Soluciones y perfiles automatizados (art. 22)

Si las decisiones con «impacto significativo» se toman por autómata - garantizar el derecho a la intervención humana, la explicabilidad, la transparencia de los signos.
Ruta de registro y versionamiento de modelos; Mecanismo de apelación.

10) Seguridad del tratamiento (art. 32) e incidentes (art. 33/34)

Medidas orientadas al riesgo: cifrado, integridad, sostenibilidad, planes de recuperación (RTO/RPO).
Incidentes de DP: proceso de detección → triaje → evaluación del riesgo → notificación al regulador ≤ 72 horas (cuando se requiere) y sujetos (si el riesgo es alto).
Playbook separado, lista de contacto DPO/abogados, plantillas de notificación.

11) Privacidad y ML/Análisis

Data Governance kits: fecha-línea, licencias/bases, consentimiento.
Técnicas: privacidad diferencial, aprendizaje federado, aggregación segura, minimización de fichas.
Protección contra ataques: inversión de membership/model - evaluaciones regulares de fugas, configuración de ε, ruido/clip.
Datos sintéticos - sólo con la comprobación de la falta de recuperación de las personas.

12) Esquemas arquitectónicos (patrones)

12. 1 Arquitectura de ID «de dos circuitos»

Esquema A (PDS - Personal Data Store): datos de identificación real (RID), acceso - estrictamente restringido, claves/cifrado/auditoría.
Bucle B (Operativo): datos de negocio con tokens; comunicaciones a través de un corredor de tokens con límites y auditoría.

12. 2 Bus de consentimiento (Consent Service)

Servicio centralizado que almacena versiones de consentimiento e historial.
SDK: 'can _ use (categoría, purpose)' - decide sobre la marcha; todo es lógico.

12. 3 Políticas de retención como código

Configuración YAML: la entidad del campo → → TTL → la acción en el momento de la expiración (anonimización/eliminación/torsión).
El planificador ejecuta job's, el informe está disponible por DPO.

13) Mini recetas

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) Documentación y rendición de cuentas

ROPA (Records of Processing Activities) - Registro de operaciones: propósito, base legal, categorías de datos/sujetos, transferencias, plazos de retención, medidas.
Políticas: privacidad, cookies, notificaciones informativas en el producto (en un lenguaje comprensible).
Formación del personal y rugidos anuales.

15) Errores frecuentes

Recaudación «por si acaso» y almacenamiento «para siempre».
El consentimiento es la única razón, aunque el contrato/interés legítimo es apropiado.
Pancartas de cookies «vacías» sin interruptores reales.
Falta de mapeo de datos y falta de preparación para DSAR.
Registros con PII, backups sin protección, mezcla de RID y datos operativos.
No hay control de proveedores y transferencias transfronterizas.

16) Hojas de cheques

• Se definen la finalidad del tratamiento y la base jurídica; ROPA actualizado.
• Mapeo de datos y DPIA (si es necesario).
• Minimización, pseudonimización, encriptación (en tránsito/en reposo) implementadas.
• Consentimiento - granular, con UX comprensible; Los impagos son privados.
• Políticas de retención configuradas como código; eliminación/anonimización verificada.
• Registros/telemetría - sin PII; enmascaramiento habilitado.
• DSAR-hooks preparados y exportación.
• Capacitación del equipo y aprobación de DPO.

• Revisión trimestral de las retenciones y fundamentos legales.
• Auditoría periódica de procesadores/subprocesadores.
• Vigilancia de incidentes y preparación para la notificación ≤ 72 horas
• Revisión de DPIA en cambios de procesos/tecnologías.
• Almacenamiento de artefactos de conformidad (DPIA, ROPA, informes de pruebas).

17) FAQ

P: ¿Es posible «huir» completamente de los consentimientos?
R: A veces sí (contrato/obligación legal/interés legítimo), pero sólo si es estrictamente necesario y con una evaluación del equilibrio de intereses. Marketing y análisis no crítico - la mayoría de las veces requieren consentimiento.

P: ¿La seudonimización es suficiente?
R: No, todavía son datos personales. Para salir de la esfera GDPR, se necesita una anonimización confiable (verificable ante la imposibilidad de volver a identificarse).

P: ¿Cómo estar con ML y personalización?
R: Minimice los fichajes, use enfoques DP/federados, lógica las soluciones, asegure el derecho a la intervención humana y evite el perfilado.

P: ¿Qué hacer en un conflicto entre negocios y privacidad?
R: Rediseñar la colección (perfil progresivo), cambiar a agregados/sintéticos, reevaluar la base legal, ofrecer una opción sin seguimiento.

• «Gestión de secretos»
• «Encriptación de At Nat»
• «Encriptación In Transit»
• «Auditoría y registros inmutables»
• «Firma y verificación de solicitudes»
• «Administración de claves y rotación»