Auditoría de datos y versionabilidad

1) Por qué es necesario

La auditoría y la versionalidad crean reproducibilidad: puede explicar cualquier figura, repetir el cálculo y desarrollar modelos/vitrinas de forma segura. En iGaming, esto es crítico para finanzas (GGR/NET), pagos, KYC/AML, Juego Responsable e informes regulatorios.

• Seguimiento: quién ha cambiado los datos/esquema/lógica y por qué.
• Reproducibilidad: qué versión de los datos/código/modelo generó el informe.
• Seguridad de lanzamientos: reversibilidad (rollback) y previsibilidad de cambios.
• Cumplimiento: registros probados para reguladores y auditorías internas.

2) Conceptos y niveles de versionalidad

1. Versión de esquema (Schema Version): evolución de campos/tipos/semántica (SEMVER).
2. Versión del conjunto de datos (Dataset Version): instantánea/corte en el momento; «verdad» para el informe/aprendizaje.
3. Versión del escaparate/modelo BI (versión de producto de datos): fórmulas, filtros, agregaciones.
4. La versión del fich/modelo ML: data/kod/giperparametry/fichi/dannye (end-to-end).
5. Versión de pipeline: código de transformación, confecciones, dependencias.
6. Versión del contrato de datos: requisitos para el productor/consumidor (esquema, SLA, calidad).

3) Auditoría: qué lógica

Quién: sujeto (usuario/servicio), rol/atributos (RBAC/ABAC).
Qué: tabla/escaparate/modelo/esquema/contrato.
Cuándo: tiempo exacto, tz, id de correlación.
Por qué: referencia a task/ticket/nota de lanzamiento, la razón.
Qué: versión de código/modelo, commit hash, imagen de contenedor.
Cómo ha cambiado: antes/después (diff), volumen de filas (rows affected), control de integridad (hash/firma).
Contexto: entorno (prod/stage), dominio, sensibilidad de datos (clase).

Los registros de auditoría son inmutables (append-only/WORM), están firmados y están disponibles en SIEM.

4) Política de versionalidad (recomendaciones)

SEMVER: `MAJOR. MINOR. PATCH`

MAJOR - Cambios de esquema/semántica incompatibles.
MINOR - adiciones reversiblemente compatibles (nuevos campos/columnas con nullable, nuevos escaparates vNext).
PARCHE - correcciones sin cambio de contrato (quality-fix, backfill).
Procedimiento de depreciación: ventana de obsolescencia, alertas en directorio/CI, fecha de desactivación.
Notas de lanzamiento: una página por lanzamiento: qué, por qué, riesgos, plan de reversión.

5) Técnicas de almacenamiento y flujo

Time-travel/Snapshots: almacenamiento de versiones de tablas; la capacidad de ejecutar la solicitud «como estaba en T-0».
SCD (Slowly Changing Dimensions): tipos de 1/2/3 para medidas (juegos, proveedores, jugadores).
CDC/CDF (Change Data/Capture & Feed): cambios incrementales en los hechos (tasas, pagos, KYC).
Registro de operaciones: tabla de hechos independiente con eventos de revisiones/adiciones/eliminaciones.
Control de integridad: hashes de lotes/archivos, firma de paquetes, compactación de agregados.

6) Evolución de esquemas y contratos de datos

Contrato como código: esquema, tipos, obligatoriedad de campos, valores válidos, frescura SLA, reglas DQ.
Compatibilidad: agregó el campo → MINOR; cambiaron el tipo/semántica → MAJOR con migración y dual-escritura.
CI-gate: el esquema de cambio de PR se bloquea si se rompe la compatibilidad o no de las Notas de Release.
Directorio/Registro: almacena versiones y propietarios activos/heredados.

7) Versionabilidad en BI y métricas

Vitrinas «doradas» certificadas: KPI semántica anclada (GGR, ARPPU, retención).
Dual-run: la nueva versión del escaparate se construye en paralelo (v2), comparando métricas (bandas de tolerance).
Confirmación de informes: cada exportación/dashboard hace referencia a 'dataset _ version' y 'definition _ version'.
Los cortes del calendario: «dei-kat», «mes-a-fecha» - se fijan en la versión de los datos.

8) Versionabilidad en ML/MLOps

Registro del modelo: modelo, fecha, métricas de calidad, datos de aprendizaje (dataset_version), versiones fich (feature_set_version).
Feature Store: grupos de fiech versionados; prohibición de campos «calientes» sin una versión explícita.
Repro set: código de entrenamiento (commit), entorno (Docker/conda lock), led.
Champion-Challenger: versiones paralelas en venta, informes de calidad, fairness y privacidad.
Rollback: retroceso rápido al modelo estable anterior y al conjunto de fichas.

9) Rollback, backfill y correcciones

Plan Rollback: para cada versión MAYOR/MENOR - pasos de retorno claros.
Backfill-playbook: fuente de la verdad, rango de fechas, orden de conversión, sumas de comprobación, etiquetas «recomputed = true».
Visibilidad de las ediciones: v2 sustituye a v1 sólo después de pasar la comparación; todos los informes «históricos» siguen haciendo referencia a sus versiones.

10) Seguridad y cumplimiento en auditoría

Firma de eventos/paquetes: el productor firma, el consumidor comprueba.
PII-saneamiento: auditoría almacena tokens no crudos PII.
Legal Hold: prohibición de eliminar versiones/registros durante el período de investigación.
DSAR: las versiones localizan y descargan las entradas del sujeto por token; se tienen en cuenta las imágenes históricas.

11) Métricas y SLO

Tasa Repro: proporción de informes reproducidos desde la versión de datos/código ≥ el umbral de destino.
Cobertura:% de las tablas con time-travel/registro de auditoría habilitado.
Schema Compatibility Pass: porcentaje de comprobaciones de compatibilidad exitosas en CI.
Dual-run Delta: discrepancia v1/v2 dentro de las tolerancias.
Rollback MTTR: tiempo medio de reversión de la versión.
Audit Integrity: proporción de eventos firmados y verificados.
Éxito de Backfill: proporción de recuentos completados correctamente.

12) Patrones para iGaming (casos)

Corrección GGR retroactiva: el proveedor ha recalculado RTP - hacer backfill de los hechos para el período, fijar 'recomputed _ at', publicar Notas de release, comparar v1/v2; no reescribimos los informes de los meses pasados, sino que marcamos «la versión corregida está disponible».
Reglas antifraude: cambiamos la semántica del fichi - modelos MAJOR, dual-run y vitrinas, rollback a champion en caso de retroceso.
KYC/AML: ha añadido nuevos estados de proveedor - MINOR con nullable; incluimos pruebas de compatibilidad en los contratos.
Señales RG: aclaró la lógica de las «series de pérdida» - MINOR + Notas de liberación y monitoreo de impacto.

13) Instrumentos y artefactos (categorías)

Catalog/Lineage/Registry: versiones de conjuntos/diagramas/escaparates, propietarios, comunicaciones, contratos.
Orchestrator & CI/CD: gates de compatibilidad, ejecución dual-run, publicación de notas de lanzamiento.
Almacenamiento con tiempo de viaje: almacenamiento de instantáneas/registros.
Signing & Checksums: firma de paquetes, sumas de comprobación de lotes.
Model/Feature Registry: versiones fich/modelos, informes champion-challenger.

14) Plantillas (listas para usar)

14. 1 Notas de release (esbozo)

Versión: 'payments _ gold v2. 1. 0`

Tipo: MINOR (nuevos campos 'psp _ country', 'method _ group')

Motivo: unificación de los informes PSP/países

Riesgos: impacto en las joyas con el escaparate 'risk _ signals'

Validación: dual-run 14 días, delta ≤ 0. 2% por GGR

Rollback: cambiar a 'v2. 0. 3 'a través de la bandera del orquestador

Fecha de deploy/propietario/ticket

14. 2 Pasaporte de la versión del kit

Dataset: `game_rounds_silver`

Versión: '2025-11-01T00: 00: 00Z' (snapshot id)

Diagrama: 'schema @ 1. 7. 0 '(referencia al contrato)

Fuente: Provider Fides A/B (commit...)

Control de integridad: checksum, manifiesto firmado

DQ: plenitud 99. 9%, frescura ≤ 15 min

Usos: 'games _ perf _ gold v3. x`, `rg_signals v1. x`

14. 3 Acto de auditoría del cambio

Evento: update schema 'kyc _ status' → 'kyc _ status, v2'

Quién: usuario/servicio, el papel de 'Data-Engineer'

Cuándo: '2025-11-01 09:32:10 + 02'

Por qué: ticket # 3421 (nuevos estados de proveedor)

Diff: + 'status _ reason' (nullable), enum ampliado

Verificaciones: CI semver pass, contrato MINOR

Firma: 'sim =...', hash diff: 'sha256 =...'

14. 4 Política de versionabilidad (fragmento)

MAYOR: rompe la compatibilidad; dual-write ≥ 30 días; un plan de rollback obligatorio.
MINOR: reversiblemente compatible; alertas en el directorio; A/B escaparate 7-14 días.
PATCH: ficciones de calidad/recalculaciones; Las notas de lanzamiento son obligatorias.
Archivado: almacenamos ≥ N meses de snapshot para la regulación; WORM para auditoría.

15) Procesos (fin a fin)

1. Iniciativa: ticket de cambio + evaluación de impacto por linaje.
2. Diseño: actualización del contrato/esquema + Notas de lanzamiento.
3. Validación: pruebas de compatibilidad CI, pruebas DQ, dual-run.
4. Deploy: por bandera, canario; publicar la versión en el directorio.
5. Monitoreo: delta v1/v2, KPI, quejas.
6. Retroceso/Backfill: por playbook en caso de retroceso.
7. Post-mortem: si el incidente, actualización de la política/pruebas.

16) RACI (ejemplo)

Políticas y normas: CDO (A), Consejo de Gobierno de Datos (R/A), DPO/Sec (C).
Contratos/esquemas: Domain Owners (A), Data Stewards (R), Platform/Eng (C).
Orquestación/bóveda: Plataforma/Eng (R), SRE (C).
BI/métricas: Analytics Lead (R), Product/Finance (C).
Versiones ML: ML Lead (A), DS (R), Platform (C).
Auditoría/registros: SecOps (R), Auditoría interna (C).

17) Hoja de ruta para la aplicación

0-30 días (MVP)

Habilitar el tiempo de viaje/instantáneas para tablas críticas (pagos, game_rounds, kyc).
Ejecutar registros de auditoría y firma de paquetes de ingestión sin cambios.
Aceptar la política SEMVER y la plantilla Notas de lanzamiento.
Catálogo: añadir 'owner', 'schema _ version', 'dataset _ version' a los principales escaparates.

30-90 días

Escriba dual-run para todos los MINOR/MAJOR; comparación automática v1/v2.
Vincular los contratos a las puertas CI de compatibilidad y DQ.
Reglamento backfill/rollback; entrenar a los equipos.
Model/Feature Registry con un conjunto completo de enlaces «dannyye→fichi→model→inferens».

3-6 meses

Cobertura completa de registros de auditoría, almacenamiento de información WORM, informes para reguladores.
Notas automatizadas Release desde diff + linj.
Informes Repro Rate/Schema Compatibility/Rollback MTTR en dashboards.
Revuelo trimestral de versiones de KPI y «congelación» de definiciones.

18) Anti-patrones

Cambiar la semántica de KPI sin una nueva versión/nota de lanzamiento.
Los recuentos son «silenciosos» sin el plan de backfill y las marcas 'recomputed'.
Almacenamiento de PII en bruto en los logs de auditoría.
Ausencia de dual-run y sustitución instantánea de escaparates.
Modelos/escaparates «eternos» sin especificar la versión y las fuentes.

19) Secciones relacionadas

Gestión de datos, Origen y ruta de datos, Control de acceso, Tokenización, Seguridad y cifrado, Supervisión de modelos, Ética y DSAR, Aprendizaje federado, ML confidencial.

Resultado

La auditoría y la verosimilitud convierten los datos y los modelos en un producto fiable: cada cambio es transparente, reproducible y reversible. Para iGaming, es la base de la confianza en los KPI, la estabilidad del cumplimiento y la velocidad de las versiones seguras.