Blog

Declararse “AI ready” se convirtió en un ritual corporativo que rara vez sobrevive al primer audit de datos. La promesa de estar preparado para la inteligencia artificial se derrumba sistemáticamente en tres frentes concretos: calidad del dato, gobernanza operativa y confianza institucional en los sistemas de información.

El término “AI ready” proliferó en presentaciones de directorio y comunicados de prensa durante los últimos dos años, pero en la práctica funciona más como señal de aspiración que como diagnóstico técnico. Cuando los equipos de datos intentan construir un pipeline de machine learning o desplegar un modelo de lenguaje sobre datos corporativos, el primer obstáculo no es el algoritmo: es el estado real del dato subyacente. Duplicados, registros incompletos, esquemas inconsistentes entre sistemas heredados y ausencia de un data owner identificable son los bloqueos más frecuentes que reportan los equipos de ingeniería en organizaciones que se autoproclaman preparadas.

Calidad de datos: el prerequisito que nadie quiere medir

La calidad del dato no es un atributo binario. El marco DAMA-DMBOK v2 distingue al menos seis dimensiones relevantes: completitud, consistencia, exactitud, oportunidad, unicidad y validez. Un modelo de IA entrenado o inferido sobre datos que fallan en dos o más de esas dimensiones produce outputs que amplifican los errores de origen, no los corrigen. El problema operativo para un CDO es que la mayoría de las organizaciones no tienen una línea de base medida para ninguna de esas dimensiones. Sin medición, la autoevaluación de “AI readiness” es subjetiva por definición.

El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), sitúa la gestión de calidad en las capabilities 5 y 6 de su modelo de madurez. Organizaciones que no han formalizado esas capabilities difícilmente pueden sostener que sus datos son aptos para alimentar sistemas de IA de manera confiable. La certificación CDMC no es un requisito universal, pero sus categorías sirven como checklist diagnóstico independiente del proveedor de nube o de plataforma.

Gobernanza sin data stewards activos es decorativa

El segundo vector de falla es la gobernanza. Muchas organizaciones tienen políticas documentadas, un comité de datos en papel y un catálogo de datos parcialmente poblado. Pero si no existe un data steward con responsabilidad operativa sobre cada dominio crítico —y con tiempo real asignado para esa función, no como tarea residual—, la gobernanza no escala cuando la IA la exige. Bob Seiner, referente en Non-Invasive Data Governance, señala que la gobernanza efectiva requiere asignar responsabilidad sobre el dato a quien ya toma decisiones sobre él, no crear una capa burocrática paralela. En contextos de IA, esa asignación se vuelve urgente porque los modelos consumen datos de múltiples dominios simultáneamente y el data lineage —la trazabilidad del dato desde su origen hasta el output del modelo— debe ser reconstruible para auditar resultados.

En América Latina, este déficit tiene consecuencias regulatorias concretas. Los bancos colombianos sujetos a las circulares de la Superintendencia Financiera sobre gestión de riesgo operativo, y las entidades financieras brasileñas bajo la Resolução CMN 4.557, están obligadas a documentar los datos que alimentan modelos de decisión crediticia. Si el data lineage no existe o está incompleto, el cumplimiento regulatorio es formal pero no sustantivo. El Banco Central de Brasil ya incorporó en su agenda supervisora el uso de modelos algorítmicos, y la CNBV en México avanza en lineamientos similares para fintech. Declararse “AI ready” sin linaje documentado en esos contextos es un riesgo regulatorio concreto, no solo un problema de madurez interna.

Confianza institucional: cuándo aplica y cuándo no

El tercer componente —confianza— es el menos tangible pero el que más frecuentemente determina si un proyecto de IA llega a producción o muere en piloto. La confianza en este contexto tiene dos dimensiones: confianza técnica (¿el equipo de negocio cree que el dato es correcto?) y confianza institucional (¿los usuarios del sistema aceptarán las recomendaciones del modelo?). Ambas se construyen con transparencia sobre las limitaciones del dato, no con afirmaciones de exactitud que luego se contradicen en el uso diario.

La confianza técnica se gana mostrando métricas de calidad accesibles para usuarios no técnicos —dashboards de completitud por dominio, tasas de error en validaciones, antigüedad promedio del dato—. La confianza institucional requiere que los data stewards y los responsables de negocio participen activamente en la validación de los datos de entrenamiento antes del despliegue del modelo, no después del primer incidente.

Cuándo aplica “AI ready” y cuándo no

El concepto tiene sentido como objetivo de roadmap, no como estado presente. Una organización puede afirmar que trabaja hacia la preparación para IA si tiene: (a) una línea de base medida de calidad del dato en al menos sus dominios críticos, (b) data stewards asignados con mandato formal sobre esos dominios, y (c) un catálogo de datos activo con linaje documentado para los procesos que serán automatizados. Sin esos tres elementos simultáneos, “AI ready” describe una intención, no una capacidad.

No aplica —y el término resulta contraproducente— cuando se usa para justificar inversiones en infraestructura de IA antes de resolver los problemas de datos subyacentes. Comprar una plataforma de MLOps o un contrato empresarial con un proveedor de modelos fundacionales no resuelve la calidad del dato de origen. La secuencia importa: primero gobernanza, después arquitectura, después modelos.

Tres verificaciones concretas antes del próximo comité de datos

Para un CDO que necesita evaluar el estado real de su organización, tres preguntas operativas son más útiles que cualquier encuesta de madurez:

• ¿Podés identificar, en menos de 48 horas, el data steward responsable de cada dominio de datos que alimentaría el primer caso de uso de IA priorizado?
• ¿Tenés una métrica de completitud y exactitud medida en los últimos 90 días para esos dominios, con un benchmark definido como umbral de aceptación?
• ¿El linaje de datos desde el sistema fuente hasta el punto de consumo del modelo está documentado y es auditable por un tercero —regulador, auditor externo o equipo de riesgo interno?

Si alguna de las tres respuestas es “no” o “parcialmente”, el roadmap de IA necesita un paso previo de gobernanza, no un paso adicional de tecnología. El DAMA-DMBOK y el CDMC del EDM Council ofrecen marcos de referencia públicos para estructurar ese diagnóstico sin depender de consultoras externas.

Para profundizar en los estándares de referencia: el DAMA-DMBOK v2 está disponible en dama.org y el marco CDMC del EDM Council puede consultarse en edmcouncil.org; ambos son el punto de partida obligado para cualquier diagnóstico serio de preparación para la IA.

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.

Los modelos de inteligencia artificial no fallan solo por arquitecturas deficientes: fallan porque los datos que los alimentan son inconsistentes, incompletos o simplemente incorrectos. La calidad del dato ha dejado de ser un problema de backoffice para convertirse en un requisito de ingeniería de IA tan crítico como la capacidad de cómputo.

Durante años, la calidad de datos fue un ítem postergado en la agenda corporativa: algo que “había que mejorar” pero que rara vez bloqueaba proyectos. La irrupción de sistemas de IA en producción cambió esa dinámica de forma abrupta. Un modelo de lenguaje entrenado con registros duplicados, un sistema de recomendación alimentado con atributos mal clasificados, o un motor de detección de fraude que consume datos sin linaje verificable producen resultados que no solo son incorrectos, sino que pueden ser jurídicamente problemáticos en contextos regulados.

Qué significa “calidad de datos” en un pipeline de IA

En el marco del DAMA-DMBOK, la calidad de datos se descompone en al menos seis dimensiones: completitud, consistencia, exactitud, oportunidad, unicidad y validez. Para un pipeline de IA, cada una de esas dimensiones tiene consecuencias directas sobre el comportamiento del modelo. Un dataset con baja completitud introduce sesgos sistemáticos hacia los segmentos mejor representados. La falta de consistencia entre fuentes provoca que el modelo aprenda contradicciones como si fueran patrones reales. La ausencia de unicidad —registros duplicados— infla artificialmente la frecuencia de ciertos eventos y distorsiona las distribuciones de entrenamiento. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), clasifica la gestión de calidad como una capability de nivel 2, es decir, prerequisito para cualquier uso avanzado de datos, incluida la IA.

Data lineage: sin trazabilidad, no hay auditabilidad del modelo

El data lineage —la capacidad de rastrear el origen, las transformaciones y el destino de cada dato a lo largo de su ciclo de vida— es el componente de gobernanza que más directamente habilita la auditabilidad de sistemas de IA. Sin lineaje documentado, es imposible responder preguntas regulatorias básicas: ¿con qué datos fue entrenado este modelo?, ¿esos datos eran representativos de la población objetivo?, ¿existía algún sesgo de selección en la fuente? En jurisdicciones donde los sistemas de IA de alto riesgo deben poder explicar sus decisiones —como establece el AI Act de la Unión Europea en su artículo 13— el lineaje deja de ser una buena práctica y se convierte en evidencia jurídica.

En América Latina, el vínculo entre lineaje y cumplimiento normativo es menos explícito en los textos legales, pero ya está siendo requerido de forma implícita. El Banco Central de Brasil, por ejemplo, exige a las instituciones financieras supervisadas que demuestren la idoneidad de los modelos de riesgo crediticio que usan en sus decisiones automatizadas, lo que en la práctica demanda tener el linaje de los datos de entrenamiento disponible para inspección. En Argentina, la Comunicación A 8073 del BCRA sobre gestión de riesgo operacional establece controles sobre los modelos utilizados en procesos críticos, con implicancias directas sobre la documentación de los datos que los alimentan.

Cuándo aplica gobernanza de datos para IA — y cuándo no

La gobernanza de datos orientada a IA aplica con urgencia cuando una organización está entrenando o ajustando (fine-tuning) modelos propios, cuando consume APIs de modelos externos con datos internos sensibles, o cuando los outputs de IA alimentan decisiones automatizadas sobre personas (crédito, salud, contratación, seguridad). No aplica —o aplica con menor criticidad— cuando el uso de IA es puramente exploratorio, sin datos de producción, y sin impacto en procesos de negocio ni en derechos de terceros. El error frecuente es tratar ambos escenarios con el mismo nivel de exigencia, lo que genera fatiga de compliance sin reducir riesgo real.

El rol del data steward en proyectos de IA

Bob Seiner, referente en Non-Invasive Data Governance, sostiene que el data steward —el responsable de un dominio de datos dentro de la organización— es la figura que debe certificar la aptitud de un dataset para un caso de uso específico antes de que ese dataset ingrese a un pipeline de entrenamiento. Este rol, que en muchas organizaciones latinoamericanas todavía se ejerce de forma informal o no existe formalmente, se vuelve crítico cuando los modelos de IA empiezan a escalar. Sin un steward que valide la calidad, la relevancia y los permisos de uso de los datos, el equipo de datos o de ingeniería termina tomando decisiones de gobernanza para las que no tiene mandato ni contexto de negocio.

La adopción de este rol en la región es desigual. Empresas de servicios financieros en México, Colombia y Brasil con exposición a reguladores internacionales (BIS, FSB) ya tienen estructuras de stewardship activas. En sectores como retail, salud privada y gobierno, el rol existe en el organigrama pero raramente tiene atribuciones formales sobre los datasets que alimentan sistemas de IA.

Tres controles mínimos antes de poner datos en un modelo

Las organizaciones que empiezan a formalizar su gobernanza de datos para IA no necesitan implementar un framework completo desde el día uno. Tres controles concretos reducen el riesgo de forma inmediata:

• Perfil de calidad documentado: completitud, duplicados y distribución de valores nulos por campo, generado antes de cada ciclo de entrenamiento o actualización del modelo.
• Registro de origen: para cada dataset en producción, un registro legible por humanos que indique fuente primaria, fecha de extracción, transformaciones aplicadas y responsable de aprobación.
• Control de acceso por sensibilidad: clasificación del dataset según si contiene datos personales, datos financieros regulados o datos de categoría especial, con acceso restringido al equipo de IA según esa clasificación.

Estos tres controles se alinean con las capabilities de nivel básico del CDMC del EDM Council y son auditables por cualquier regulador que solicite evidencia de diligencia debida en el uso de datos para IA.

Para profundizar en los estándares aplicables, el DAMA-DMBOK (segunda edición) y el marco CDMC del EDM Council son los documentos de referencia más completos disponibles para equipos de gobernanza que trabajan en contextos de IA. Ambos están disponibles en sus respectivos sitios oficiales.