Databricks anunció CustomerLake, una solución diseñada para que los bancos centralicen y gobiernen los datos de sus clientes dentro de su propio entorno de datos, sin ceder el control a plataformas de CRM externas. La propuesta reactiva un debate que el sector financiero nunca cerró del todo: quién es el dueño real del dato del cliente y quién responde cuando ese dato falla.
CustomerLake parte de una premisa operativa concreta: los bancos acumulan décadas de datos transaccionales, de comportamiento y de contacto dispersos en silos —core bancario, CRM, canales digitales, call center— sin un modelo de gobernanza que los unifique bajo un data owner identificable. La propuesta de Databricks es construir esa capa de unificación sobre el lakehouse propio de la institución, manteniendo los datos bajo la jurisdicción y el control de la entidad financiera, no del proveedor de CX.
Qué hace CustomerLake y por qué importa en banca
La arquitectura de CustomerLake, según se informó, combina capacidades de ingesta unificada, resolución de identidad de clientes (identity resolution) y perfilado en tiempo real, todo dentro del entorno de datos del banco. El punto de diferenciación frente a soluciones de Customer Data Platform (CDP) tradicionales es que el dato nunca abandona el lakehouse de la institución: no hay sincronización hacia un SaaS de terceros que almacene una copia del perfil del cliente. Para los equipos de gobernanza de datos, eso cambia el mapa de riesgo de forma sustancial: el data lineage —la trazabilidad del dato desde su origen hasta su uso en una campaña o en una decisión crediticia— queda bajo control interno, auditable con las herramientas que ya tiene el banco.
Desde la perspectiva del DAMA-DMBOK, esta arquitectura aborda directamente dos capability areas críticas: Data Integration & Interoperability y Data Security. La resolución de identidad centralizada elimina duplicados y perfiles fragmentados, que son una de las causas raíz más frecuentes de problemas de calidad en datos de clientes bancarios. Un perfil duplicado no es solo un problema de marketing; en banca es un riesgo de cumplimiento: puede implicar KYC incompleto, alertas de prevención de lavado mal asignadas, o comunicaciones regulatorias enviadas a la dirección equivocada.
Cuándo aplica CustomerLake y cuándo no
CustomerLake aplica cuando el banco ya opera sobre Databricks o está en proceso de consolidar su arquitectura de datos en un lakehouse. No es una solución autónoma: presupone que existe —o se está construyendo— un Data Governance Council con capacidad de definir data domains, asignar data stewards por dominio (clientes, productos, riesgo) y mantener un catálogo activo. Si la institución no tiene ese andamiaje de gobernanza, CustomerLake entrega infraestructura técnica sin el modelo operativo que la hace funcionar. La herramienta resuelve el “dónde vive el dato”; no resuelve el “quién responde por él”.
Tampoco es la respuesta correcta para bancos medianos o cooperativas de crédito que no tienen equipo de ingeniería de datos propio. En esos casos, el costo operativo de mantener un lakehouse gobernado supera los beneficios de tener el dato in-house frente a una CDP SaaS con controles contractuales sólidos.
El flanco regulatorio en Argentina, Brasil y México
Para la banca latinoamericana, la propuesta de CustomerLake no es solo una decisión de arquitectura: es una decisión regulatoria. En Argentina, las entidades financieras supervisadas por el BCRA deben cumplir la Comunicación A 7724 y sus actualizaciones sobre gestión de riesgo tecnológico, que exigen trazabilidad sobre los sistemas que procesan datos de clientes. Transferir datos de clientes a un SaaS offshore implica, en muchos casos, informar a la autoridad de control y cumplir con los requisitos de localización o de acuerdo de transferencia que establece la Ley 25.326 y su decreto reglamentario. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige que el controlador —el banco— pueda demostrar una base legal para cada tratamiento y responder ante la ANPD en caso de incidente; si el dato está en manos de un procesador externo sin contrato de procesamiento adecuado, esa demostración se complica. En México, la LFPDPPP y la regulación sectorial de la CNBV imponen obligaciones similares sobre el responsable del tratamiento. Mantener el dato dentro del entorno propio simplifica esa cadena de accountability, aunque no la elimina: el banco sigue siendo responsable de lo que hace con el dato, independientemente de dónde lo almacene.
Lo que un CDO bancario necesita definir antes de implementar
Antes de evaluar CustomerLake como solución, un Chief Data Officer del sector financiero debería tener respuestas operativas a tres preguntas: primero, ¿existe un data domain “cliente” formalmente definido, con un data steward asignado y métricas de calidad activas? Segundo, ¿el catálogo de datos corporativo registra hoy qué sistemas son fuente de verdad (system of record) para cada atributo del perfil del cliente —nombre, dirección, score de riesgo, historial de contacto? Tercero, ¿el equipo legal tiene mapeados los flujos de datos de clientes hacia terceros, con los contratos de procesamiento de datos actualizados según la regulación local? Si alguna de esas tres respuestas es “no” o “parcialmente”, la prioridad no es la herramienta: es el modelo de gobernanza que la herramienta va a ejecutar. CustomerLake puede acelerar la implementación técnica, pero el diseño del data ownership es una decisión institucional que ningún proveedor puede tomar por el banco.
La especificación técnica de CustomerLake está disponible en la documentación oficial de Databricks; los marcos de referencia para el diseño del modelo de gobernanza pueden consultarse en el DAMA-DMBOK (segunda edición) y en el CDMC del EDM Council, que incluye controles específicos para datos de clientes en industrias reguladas.
