Los datos son lo que hace funcionar a cualquier organización moderna y, en banca, además, constituyen uno de los activos más sensibles de gestionar. Los modelos diseñados para detectar fraude, evaluar riesgo o mejorar el servicio al cliente suelen depender de información sobre personas reales y dinero real. Los datos sintéticos ofrecen una vía para reducir la tensión entre hacer que los datos sean útiles y mantenerlos protegidos. En Santander, los equipos están explorando dónde puede aportar más valor este enfoque.
Los datos sintéticos ya se están aplicando a casos de uso internos, creando registros realistas sin incluir datos reales de clientes en los conjuntos de datos resultantes. Una iniciativa interna va un paso más allá: un generador diseñado para reproducir no solo una tabla, sino una base de datos relacional completa, incluidas múltiples tablas enlazadas y las series temporales integradas en ellas, como las transacciones, saldos y eventos de un cliente a lo largo de varios meses.
Generar una versión realista de una sola tabla es relativamente fácil, pero mantener relaciones entre múltiples tablas y, al mismo tiempo, conservar la coherencia interna del historial de cada cliente es mucho más difícil y sigue estando fuera de lo que muchas herramientas estándar están diseñadas para hacer.
La característica distintiva está en cómo aprende el generador. Se ajusta únicamente con estadísticas agregadas extraídas de la fuente (distribuciones, correlaciones y patrones estacionales y secuenciales) y reconstruye una copia realista a partir de ellas. Como ningún modelo ve nunca un registro real, esencialmente no hay nada que permita rastrearlo hasta una persona concreta. De esta forma, la privacidad está incorporada desde el inicio, no añadida después. El mismo enfoque está también pensado para funcionar con bases de datos desconocidas sin necesidad de un ajuste manual intensivo.
Para los equipos de Data & AI Science, esto puede facilitar mucho la experimentación. Los modelos pueden entrenarse y evaluarse sin dar a los equipos de desarrollo acceso directo a las bases de datos originales, reduciendo parte de las revisiones de confidencialidad, legales y de gobernanza que suelen surgir antes de poder empezar un primer experimento. Obtener acceso a datos de producción puede llevar meses, a veces más de un año. Una copia sintética utilizable puede estar lista en semanas.
Aun así, los conjuntos de datos sintéticos deben cumplir un umbral de calidad definido antes de poder utilizarse. Cada copia se evalúa en campos, relaciones y patrones temporales para determinar hasta qué punto se ha preservado la estructura de los datos de origen. También pueden realizarse pruebas adicionales para comprobar si un clasificador es capaz de distinguir los registros sintéticos de los reales, lo que aporta otra señal tanto sobre realismo como sobre privacidad. Un conjunto sintético solo se utiliza cuando esas métricas alcanzan los umbrales definidos de antemano.
La idea no es solo evitar usar datos reales, sino que nunca tengamos que tocarlos. Si reconstruimos una base de datos entera únicamente a partir de sus estadísticas, un equipo puede empezar a trabajar desde el primer día, con la cuestión de la privacidad prácticamente resuelta antes de que nadie la plantee.
Beneficios de los datos sintéticos
Los datos sintéticos no son ni datos reales anonimizados ni información inventada al azar. Un modelo generativo aprende la estructura estadística de un conjunto de datos real: la distribución de los campos individuales y, más importante todavía, las relaciones entre ellos. A continuación, crea nuevos registros que reproducen esos patrones sin copiar directamente observaciones individuales. Para los datos predominantemente tabulares que se encuentran en banca, los enfoques más habituales incluyen CTGAN y TVAE, Gaussian Copulas para los casos más sencillos, y generadores más recientes basados en difusión como TabDiff.
Con una biblioteca estándar, la receta es breve, pero conviene destacar que el modelo se entrena directamente sobre las filas reales:
```python
from sdv.single_table import CTGANSynthesizer
synth = CTGANSynthesizer(metadata)
synth.fit(real_transactions) # the model reads the real rows to learn their structure
synthetic = synth.sample(1_000_000) # brand-new records, no real customer inside
```
El enfoque interno separa esa primera etapa en dos pasos. Se accede a los datos de origen una sola vez, dentro del entorno seguro donde ya residen, exclusivamente para calcular estadísticas agregadas. Después, el generador trabaja a partir de esas agregaciones y no de las filas subyacentes.
```python
# Step 1 — runs once, in the secure zone; only aggregates ever leave it
stats = extract_statistics(real_database) # distributions, correlations, seasonality — not rows
# Step 2 — runs anywhere, with no access to the originals
synth = StatsGenerator(stats)
synthetic = synth.sample(1_000_000)
```
Los datos reales siguen teniendo que procesarse para calcular esas estadísticas, pero ese acceso ocurre una sola vez, dentro del entorno controlado en el que ya se encuentran los datos, y únicamente con el objetivo de extraer agregados no identificativos. A partir de ese momento, las filas individuales no necesitan moverse, y el modelo generativo no puede memorizar registros que nunca formaron parte de su entrada de entrenamiento. Esa distinción es importante: el objetivo no es solo reducir la exposición innecesaria, sino rediseñar el proceso para que el acceso directo a datos sensibles sea necesario en el menor número posible de etapas.
Los datos sintéticos no son automáticamente seguros. Existe una tensión muy conocida entre fidelidad y privacidad: cuanto más fielmente reproduce un conjunto sintético la estructura estadística de su fuente, más útil puede resultar, pero mayor es también el riesgo de que pueda inferirse información sobre los datos originales de entrenamiento. Los ataques de inferencia de pertenencia ilustran ese problema. Su objetivo es determinar si un registro concreto estuvo incluido en los datos de entrenamiento de un modelo, y los generadores muy fieles pueden ser más vulnerables a este tipo de ataque.
Por tanto, el realismo por sí solo no basta. Un conjunto de datos sintéticos debe evaluarse al mismo tiempo en tres dimensiones: fidelidad, utilidad y privacidad:
- Fidelidad: ¿preserva las propiedades estadísticas importantes de los datos de origen?
- Utilidad: ¿pueden los modelos entrenados con datos sintéticos rendir eficazmente cuando se aplican a datos reales?
- Privacidad: ¿cuánta información sobre registros individuales puede llegar a inferirse?
La privacidad diferencial puede acotar esta última dimensión, añadiendo ruido calibrado para que ningún registro individual altere mucho el resultado, aunque a costa de la fidelidad. Elegir deliberadamente ese equilibrio es la verdadera tarea de ingeniería.
Impacto en la banca
Los datos sintéticos también eliminan fricción en otros ámbitos. Los patrones raros pero críticos, como el fraude, pueden amplificarse para entrenamiento sin exponer a un solo cliente.
Ese caso de uso ya se refleja en gen-fraud-graph, un generador de código abierto para redes sintéticas de cuentas, transacciones y patrones de blanqueo de capitales. Permite entrenar y comparar modelos basados en grafos para detección de fraude y prevención del blanqueo con estructuras realistas, sin depender de registros financieros reales. Publicado bajo Apache-2.0, el proyecto también ofrece una base común sobre la que otros investigadores y desarrolladores pueden construir, probar y comparar enfoques.
La dirección regulatoria más amplia refuerza la importancia de este trabajo: los principios de gobernanza de datos en marcos como el RGPD y la Ley de IA de la UE ponen un fuerte énfasis en la gestión adecuada de los datos y en minimizar el uso innecesario de información personal. Los procesos de datos sintéticos bien diseñados pueden apoyar esos objetivos.
