Privacidad por Diseño: Principios de Diseño

1) Por qué es necesario (objetivo y área)

PbD garantiza que la privacidad está incorporada en el producto predeterminado en lugar de estar «pegada» en la parte superior. Para iGaming, esto reduce los riesgos regulatorios (GDPR/ePrivacy/leyes locales), protege a los usuarios vulnerables, aumenta la confianza y reduce el costo de los incidentes. Cobertura: web/mobile, KYC/AML/RG, pagos, marketing/CRM, análisis/DWH, logs/ARM, socios/vendedores.

2) Los siete principios (y cómo aterrizarlos en las operaciones)

1. Proactividad, no reactividad

Threat modeling (LINDDUN/STRIDE) en la etapa de discovery.
Criterios de aceptación de privacidad en las plantillas Jira/PR.

2. Privacidad predeterminada

Todos los tumblers de marketing/personalización - fuera de, hasta que no hay consentimiento.
Recopilar sólo los identificadores predeterminados «estrictamente necesarios».

3. Privacidad incorporada en el diseño

El PII se almacena en un circuito regional (residencia de datos), control plano - sin PII.
Tokenización/pseudonimización de claves en eventos de servicio.

4. Funcionalidad completa (ganar-ganar)

Modos de «análisis anónimo» y «personalización consentida».
Igual a UX sin discriminación de quienes rechazaron el seguimiento.

5. Seguridad a través del ciclo de vida

Encriptación en el paso/en el paso; BYOK/HYOK; segmentación de redes; Gestión secreta.
Registros WORM para pruebas y auditorías.

6. Transparencia

Políticas cortas y «caja de resumen» de condiciones clave; panel de privacidad en el perfil.
Informes: quién/qué/cuándo/por qué se accedió a los datos.

7. Orientación del usuario

Textos sencillos, sin patrones oscuros, disponibilidad de WCAG AA +.
Revocación fácil del consentimiento y canales convenientes DSAR.

3) Roles y RACI

DPO/Head of Compliance - PbD, DPIA/TRA, control de riesgos. (A)

Seguridad/Infra Lead - criptografía, accesos, registros, vendedores. (R)

Product/UX - requisitos de privacidad en fichas, sin patterns oscuros. (R)

Ingeniería/Arquitectura - tokenización, aislamiento de tenant/región, contratos API. (R)

Datos/Análisis - de-PII transportadores, PETs, agregación. (R)

Legal - fundamentos legales, textos y localies. (C)

Marketing/CRM - consentimiento/suppression, comunicaciones honestas. (R)

Auditoría interna - Muestras de artefactos, CAPA. (C)

4) Clasificación y taxonomía de los datos

PII básico: FIO, correo electrónico, teléfono, dirección, fecha de nacimiento, dispositivo IP/ID.
PII sensibles: biometría (selfie/vitalidad), documentos KYC, datos de pago, estados RG/SE.
Operativo: eventos de juego, logs/tracks (PII-free por defecto).
Marketing/análisis: identificadores de cookies/SDK (por consentimiento).

Reglas: minimización, almacenamiento separado, propósito explícito y vida útil.

5) Ciclo de vida de los datos (Data Lifecycle)

1. Recolección: sólo los campos necesarios; CMR/Consentimiento; comprobaciones de edad.
2. Transmisión - TLS 1. 2 +/mTLS, firma de webhooks, routing regional.
3. Almacenamiento - encriptación, tokenización, rotación de claves, aislamiento por mercados.
4. Uso - RBAC/ABAC, «need-to-know», PETs para análisis.
5. Intercambio - DPA/SCC, conjuntos mínimos, canales auditados.
6. Retiro/Eliminación - Plazo por categoría; delete jobs en cascada; eliminación cripto de archivos.
7. Informes/auditorías: registros de acceso y exportación, artefactos DPIA/DSAR.

6) DPIA/TRA (cómo hacer brevemente)

Desencadenantes: nuevas categorías PII, categorías especiales, nuevos vendedores, transmisiones transfronterizas, altos riesgos de RG/biometría.
Plantilla DPIA: objetivo → categoría de datos → base legal → flujo/tarjeta → riesgos → medidas (t/org) → riesgo residual → solución.
Artefactos: diagrama de flujo, lista de campos, tabla de riesgos, protocolo de negociación.

7) Patrones de arquitectura PbD

Tenant/Regional Isolation: segregación física/lógica de la DB, claves y secretos.
Control vs Data Plane: control global - sin PII; PII sólo localmente.
De-PII Pipeline: antes de exportar a DWH - hash/sal, truncamiento, k-anonimato/cohortado.
Tokenization Gateway: tokens en lugar de identificadores primarios en el bus de servicio.
Edge sin PII: CDN/edge caché - sólo contenido público.
Fail-Closed: el desconocido 'player _ region' → la prohibición de operaciones con PII.

8) Medidas y normas técnicas

Encriptación: AES-256/GCM at nat; TLS 1. 2+/1. 3; PFS.
Claves: KMS, BYOK/HYOK, rotación, acceso por roles HSM, registro de operaciones clave.
Acceso: RBAC/ABAC, accesos JIT, funciones de administración y auditoría separadas.
Registros: inmutable (WORM), cadenas hash, almacenamiento en la región.
DevSecOps: secretos en Vault, SAST/DAST, linter de campos PII, pruebas de privacidad en CI.
Datos de prueba: sintética predeterminada; si los datos re son de identificación y de breve retención.

9) PETs (Privacy-Enhancing Technologies)

Seudonimización: reemplaza el ID por tokens; la llave-mapa se almacena por separado.
Anonimización: agregados, k- anonimnost/ℓ -diversidad, bining/cohortes.
Privacidad diferencial: ruido en los informes, «budget de privacidad».
Analíticas federadas: modelos locales, exportando sólo escalas/agregados.
Enmascaramiento/revisión: eliminación de EXIF, eliminación de campos en documentos KYC.

10) UX sin patrones oscuros

Igual visibilidad «Rechazar todo «/« Aceptar todo «/« Configurar ».
Textos de propósito comprensibles y ejemplos de uso de datos.
Rechazar la personalización no empeora la experiencia básica.
Panel de privacidad en 1-2 clics de todas partes; Disponibilidad de AA +.

11) Vendedores y transferencia de datos

Registro de proveedores: jurisdicciones DC, sub-procesadores, certificación, regiones de almacenamiento, DPA/SCC/IDTA.
Política de «conjunto mínimo»: sólo los campos deseados, prohibición de exportación libre.
Notificación y revisión al cambiar de ubicación/sub-procesador.

12) Datos y eventos (modelo mínimo)

data_asset{id, category{KYC    PCI    RG    CRM    LOG    ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}

13) KPI/KRI y dashboard PbD

Índice de minimización PII (promedio de campos PII por fichu).
Residency Coverage (% de los registros en la región correcta).
Tasa de justificación de exportación (número de exportaciones con referencia a la base).
DSAR SLA (mediana de ejecución/precisión).
Tag Firing Violations (etiquetas sin consentimiento).
Auditability Score (% de los casos con un paquete completo de artefactos).
Incidents/Findings (observaciones recurrentes de auditoría/regulador).

14) Hojas de cheques

A. Antes del desarrollo de los fichas (Diseño)

• Se definen los objetivos y las bases jurídicas del tratamiento.
• Mapa de datos y lista de campos marcados con PII/sensibles.
• DPIA/TRA cumplidos; riesgos residuales asumidos.
• Se ha pensado en un «modo anónimo» o modo con un mínimo de datos.

B. Antes de su lanzamiento (Build/Release)

• Los secretos en el administrador, claves/cifrado están configurados.
• Registros sin PII; eventos y auditoría incluidos.
• La política regional de routing y retention está activa.
• Pruebas: consent-gates, deny-by-default para etiquetas, ruta erasure.

C. En operaciones

• Rugido trimestral de accesos y exportaciones.
• Seguimiento de las infracciones y solicitudes transfronterizas.
• Los DSAR/eliminaciones se ejecutan a tiempo; los artefactos se conservan.

15) Plantillas (inserciones rápidas)

A) Plantilla DPIA (corta)

B) Política de minimización de campos

C) Cláusula con vendedor (compromiso PbD)

D) Respuesta al DSAR (extracto)

16) Errores frecuentes y cómo evitarlos

Recolección «por si acaso». → Política de minimización + esquemas de rugido de código.
Registros en bruto con PII en APM → Enmascaramiento/revisión en el agente, almacenamiento local.
DWH global con PII → Sólo agregados/alias de de-PII.
No hay artefactos DPIA/consent. → repositorio WORM, imágenes automáticas de UI/textos.
Vendedores no registrados/SDK. → Registro trimestral, prohibición de conexiones «grises».

17) Plan de implementación de 30 días

Semana 1

1. Aprobar políticas PbD y plantillas DPIA/TRA.
2. Construir un mapa de datos/flujos por zonas clave (KYC/PCI/RG/CRM/Logs).
3. Destacar los perímetros regionales (EU/UK/...); definir el modelo de claves (BYOK/HYOK).

Semana 2

4) Habilite los transportadores de tokenización/de-PII y deny-by-default para las etiquetas.
5) Ajustar las WORM-revistas (доступы/экспорты/consent/удаления).
6) Actualizar los contratos con los vendedores (DPA/SCC, localizaciones, sub-procesadores).

Semana 3

7) Implementar pruebas de privacidad en CI (linter PII, screen-fijación CMP, erasure-E2E).
8) Lanzamiento del panel de privacidad en el perfil; mejorar los textos y las localies.
9) Capacitar a los equipos (Product/Eng/Data/CS/Legal).

Semana 4

10) Llevar a cabo DPIA rugido top fich, cerrar CAPA.
11) Ejecutar KPI/KRI dashboard (Residency, Exports, DSAR SLA).
12) Plan v1. 1: diff. privacidad para informes, pipelines federados.

18) Secciones interrelacionadas

GDPR: gestión del consentimiento del usuario/Política de cookies y CMP

Localización de datos por jurisdicciones

Comprobación de edad y filtros de edad

AML/KYC y almacenamiento de artefactos

Dashboard de cumplimiento y monitoreo/Informes regulatorios

Auditorías internas/externas y hojas de comprobación de cuentas

BCP/DRP/Encriptación en Tránsito y En