Políticas de retención de datos

1) Por qué se necesitan políticas de retención

Las políticas de retención determinan cuánto tiempo y por qué almacena cada tipo de datos, dónde está alojado, quién responde y cómo se eliminan o anonimizan los datos. Sin ellos, es imposible cumplir con la privacidad, minimización y reproducibilidad de los informes, especialmente en iGaming con PII/finanzas sensibles, regulaciones e investigaciones.

• Cumplimiento de leyes/licencias y contratos con proveedores/PSP.
• Minimizar los riesgos de fugas y multas.
• Previsibilidad de los costos de almacenamiento y rendimiento de la plataforma.
• Soporte para procesos DSAR, Legal Hold, auditoría y versionabilidad.

2) Principios básicos

1. Almacenamiento de destino (purpose limitation): la fecha límite está vinculada a un objetivo de procesamiento específico.
2. Minimización: no almacenar «por si acaso»; al final del objetivo - eliminar/anonimizar.
3. Transparencia y probabilidad: cada registro debe tener el propietario, la clase, el término y la base.
4. Separación de entornos: prod/stage/sandbox con diferentes plazos y conjuntos de campos.
5. Policy-as-Code: política como configuración en el repositorio + CI-validación.
6. Defense in Depth: almacenamiento + backups + registros de auditoría + Legal Hold se negocian entre sí.

3) Clasificación y bases jurídicas

Clases: Public/Internal/Confidential/Restricted (PII/Finance) con las etiquetas: 'pii', 'financial', 'tokenized', 'backup', 'legal _ hold',' wip ',' dsar _ subject ''.

• Obligación legal/licencias (por ejemplo, informes y AML).
• Ejecución del contrato (transacciones/pagos).
• Interés legítimo (seguridad, antifraude) - con evaluación de equilibrio.
• Consentimiento (marketing/personalización) - con plazos y revocación separados.

4) Matriz de vida útil (referencia para iGaming)

5) Legal Hold y congelación

Legal Hold cancela temporalmente las eliminaciones/TTL para los kits relacionados con la investigación/disputa.
La fuente de la verdad es el registro Legal Hold: propietario, fecha, base, rango de datos, fecha de retiro.
Retirada - por el proceso aprobado; todos los retiros retrasados se desencadenan como frijoles depositados.

6) DSAR y «derecho de supresión»

Almacenar tokens de sujetos (no PII) para buscar en el gráfico.
Mantenga la distinción entre eliminación, alias y anonimización.
No elimine los registros que están obligados a almacenar por ley - marque la restricción de procesamiento; explique al sujeto.
En backups: elimina en futuras rotaciones + la marca «subject erased» en la capa activa.

7) Backups, archivos y WORM

3-2-1: tres copias, dos tipos de medios/nubes, uno es offline/air-gapped.
Cifrado con claves KMS/HSM independientes del proveedor.
WORM para informes de auditoría/regulación.
Política de rotación de backups: la vida útil de los backups no debe exceder la duración de los datos activos a menos que haya excepciones obligatorias.
Prueba de recuperación programada.

8) Transfronteroriedad y geolocalización

Geo-scoping: los datos y las claves de cifrado están enlazados a una región/licencia.
Las replicaciones respetan los tiempos de retención locales y las restricciones de transmisión.
Los contratos con proveedores/PSP/KYC están obligados a reflejar los lugares de almacenamiento y los plazos.

9) Arquitectura de almacenamiento y automatización

• Raw/Bronze (plazo mínimo, sin PII si es posible).
• Silver (hechos depurados con TTL y enmascaramiento).
• Oro (unidades/vitrinas de larga duración).
• Feature Store/Model Registry (versioning y time-travel sin PII).

• Políticas Lifecycle/TTL en objetos/tablas/temas.
• Política como código: YAML/JSON con 'purpose', 'retention _ period', 'post _ expiry _ action', 'legal _ hold _ override'.
• CI-linter: bloquea PR si un nuevo conjunto sin 'retention _ policy'.
• Scheduler: un control diario «que vence mañana/en la semana».
• Deletion jobs: eliminación suave → comprobación de dependencias → eliminación/encriptación sólida.

10) Eliminación, anonimización, seudonimización

Borrado duro: eliminación física (tenga en cuenta las cascadas y el linaje).
Soft delete es la etiqueta 'deleted _ at', ocultación, plan de borrado duro posterior.
Crypto-erase: elimina las claves para que los datos no estén disponibles.
La anonimización es una transformación irreversible; se permite el almacenamiento de unidades.
Seudonimización - Sustitución por tokens; es obligatoria la política de claves/pepper y la prohibición de reversibilidad fuera de la «zona limpia».

11) Métricas y SLO

Cobertura de Retención:% de conjuntos con directiva aprobada.
Eliminación en tiempo real: proporción de eliminaciones realizadas a tiempo.
Zero-PII en Logs: recubrimiento de registros mediante enmascaramiento.
Accuracy Legal Hold: coincidencia del registro con las heladas reales.
Backup Restore-Rate: recuperación de pruebas exitosa.
DSAR SLA: tiempo medio de ejecución de las solicitudes (por tipo).
Costo vs Retention: ahorros de agregación/TTL.

12) RACI (ejemplo)

Políticas y normas: CDO/DPO (A), Consejo de Gobierno (R/A), Legal (C), Seguridad (C).
Catálogo y etiquetas: Data Stewards (R), Domain Owners (A), Platform (C).
Automatización/TTL: Plataforma/SRE (R), Sec (C).
Legal Hold/DSAR: DPO/Legal (A/R), Dominios (C).
Auditoría y respaldo: SecOps/SRE (R), Auditoría interna (C).

13) Plantillas (listas para usar)

13. 1 Política de retención (esbozo)

Ámbito: enumerar dominios y excepciones.
Fundamentos: obligación legal/contrato/consentimiento/interés legítimo.
Plazos: tabla 'dataset → period → action'.
Legal Hold: proceso de inclusión/retirada.
DSAR: orden de búsqueda/eliminación/restricción.
Backups/WORM: plazos, claves, prueba de recuperación.
Control: métricas, rugir anualmente, dueño de la póliza.

13. 2 Tarjeta de marcación con retention

Dataset: `payments. transactions`

Clase: Restringido (finanzas)

Fundamento: obligación legal/contabilidad

Plazo: N años a partir de la fecha de la operación

Acción posterior a la fecha límite: anonimización de unidades, borrado duro de piezas

Legal Hold override: да

Responsables: Owner/Steward, DPO

Etiquetas/contratos: 'pii', 'tokenized', 'retention: N', referencia al contrato

13. 3 políticas YAML (policy-as-code, fragmento)

yaml dataset: payments. transactions purpose: accounting_and_aml class: restricted retention_period: P{N}Y    # ISO 8601 duration post_expiry_action: anonymize_then_delete legal_hold_override: true geo_scope: EU backups:
retention_period: P{N}Y worm: true audit:
enabled: true destination: worm://audit/payments

13. 4 Lista de comprobación de inicio

• Cada dataset tiene una tarjeta y una política YAML
• Reglas TTL/lifecycle incluidas en los repositorios
• El directorio muestra los plazos/bases/propietarios
• Alertas de caducidad personalizadas y informe de eliminación en tiempo real
• El registro de Legal Hold está sincronizado con las banderas de almacenamiento
• Secuencia de comandos «table-top» de DSAR/eliminación en backups

14) Hoja de ruta para la aplicación

0-30 días (MVP)

1. Inventario de conjuntos y clasificación; asignar propietarios.
2. Agregar el campo 'retention' al contrato/directorio; traer las tarjetas de los mejores conjuntos.
3. Habilitar TTL/lifecycle para logs y capas raw; Prohibición de PII en los logs.
4. Registro Legal Hold y procesos; Informes básicos de Coverage/On-Time Deletion.

30-90 días

1. Enrollar policy-as-code (YAML) y CI-linter; unidad PR sin 'retention'.
2. Implementar la anonimización/seudonimización post-término; automatizar la eliminación de jobs.
3. Ajustar los backups a los plazos; habilitar WORM para auditoría.
4. Asociar DSAR con retoque y tokenización; Informes de SLA.

3-6 meses

1. Geo-localización de conjuntos y claves; políticas transfronterizas.
2. Análisis avanzado del costo de almacenamiento y el efecto TTL.
3. Revoluciones trimestrales de los plazos con Legal/Dominios; auditoría externa.
4. Escalar en socios/proveedores (requisitos contractuales de Retench).

15) Anti-patrones

«Guardamos todo para siempre» - sin base y sin plan de eliminación.
Incoherencia: el activo se elimina, y en los backups, para siempre.
Ausencia de Legal Hold: borrar las pruebas.
Plazos uniformes para todos los dominios «por simplicidad».
DSAR sin eliminación real en escaparates/fichas derivadas.
Sandbox con copias prod-PII y duración infinita.

16) Secciones relacionadas

Gestión de Datos, Control de Acceso, Tokenización de Datos, Seguridad y Cifrado, Origen y Ruta de Datos, Auditoría y Versionabilidad, Legal Hold y DSAR, ML Confidencial.

Las políticas de retención convierten un «almacén caótico» en un archivo administrado: cada campo conoce su término, base y destino. Para iGaming es la base del cumplimiento, el ahorro y la confianza en los datos: almacena suficiente, pero no innecesariamente, sabe cómo eliminar y probar rápidamente, y al mismo tiempo no rompe los informes, ML y procesos operativos.