Categoría: Data Governance

Los bancos que aceleran la adopción de inteligencia artificial sin haber resuelto primero su arquitectura de gobierno del dato están construyendo sobre terreno inestable. La experiencia acumulada en el sector financiero global —y cada vez más en América Latina— muestra un patrón consistente: los proyectos de IA que fracasan o generan resultados sesgados tienen, en su raíz, problemas de calidad, ownership o trazabilidad de datos, no de algoritmos.

El dato como activo estratégico, no como subproducto

Durante años, las entidades financieras gestionaron sus datos como un subproducto de las operaciones: algo que existía, que se almacenaba y que se consultaba cuando era necesario. La irrupción de modelos de machine learning y, más recientemente, de large language models (LLMs) en procesos críticos —scoring crediticio, detección de fraude, atención al cliente, cumplimiento regulatorio— cambió radicalmente esa ecuación. Hoy, un modelo de IA es tan confiable como los datos con los que fue entrenado y con los que opera en producción. Si esos datos tienen problemas de linaje, duplicidades o definiciones inconsistentes entre sistemas, el modelo amplifica esos defectos a escala.

El marco DAMA-DMBOK, referencia obligada para cualquier programa de gobierno del dato, identifica once áreas de conocimiento que van desde la arquitectura de datos hasta la gestión de la calidad y la privacidad. Para un banco que quiere desplegar IA de forma responsable, las más críticas son precisamente las que más se descuidan: data quality management, data lineage y el establecimiento formal de data stewards —roles que asumen la responsabilidad operativa sobre dominios de datos específicos, como clientes, productos o transacciones.

Qué hace un CDO bancario con esto el lunes

El punto de partida no es un proyecto de transformación de dieciocho meses. Es un diagnóstico acotado. Un Chief Data Officer que quiera validar si su organización está en condiciones de escalar IA debería revisar al menos tres dimensiones antes de aprobar cualquier caso de uso nuevo:

• Data lineage documentado: ¿puede el equipo trazar, de punta a punta, el recorrido de las variables que alimentan cada modelo? Sin esto, cualquier auditoría interna o regulatoria se convierte en un ejercicio de arqueología de datos.
• Ownership formalizado: ¿existe un data steward designado para cada dominio crítico, con criterios de calidad definidos y medidos periódicamente? En bancos medianos de la región, este rol suele estar fragmentado entre TI y el área de negocio, sin responsabilidad clara.
• Catálogo activo: ¿el banco opera con un catálogo de datos que los equipos de datos y de negocio realmente usan, o es un documento que se actualizó por última vez durante una auditoría?

El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), ofrece una escala de madurez que varios bancos de primera línea en Brasil y Colombia ya están usando como referencia para sus programas internos. En particular, la capability 8 —que evalúa controles de acceso, clasificación y protección del dato en entornos cloud— resulta directamente aplicable a cualquier banco que opere modelos de IA sobre infraestructura híbrida.

El ángulo regulatorio que LATAM no puede ignorar

La presión no viene solo del mercado. Los reguladores financieros de la región están incorporando el gobierno del dato como un requisito implícito —y en algunos casos explícito— dentro de sus marcos de supervisión de riesgos tecnológicos. El Banco Central de Brasil ha avanzado en lineamientos sobre riesgo de modelos que exigen documentación del ciclo de vida del dato utilizado en sistemas de decisión automatizada. En Argentina, la Comunicación A 7724 del BCRA establece criterios de gestión de riesgo tecnológico que, interpretados en clave de IA, demandan exactamente lo que el gobierno del dato provee: trazabilidad, control y accountability. En Colombia, la Superintendencia Financiera ha señalado en circulares recientes que los sistemas de scoring basados en IA deben poder explicarse y auditarse, lo que es imposible sin data lineage sólido.

Esta convergencia entre exigencia regulatoria y necesidad operativa es, paradójicamente, la mejor noticia para los equipos de datos bancarios: el caso de negocio para invertir en gobierno del dato ya no necesita justificarse solo por eficiencia interna. Existe un mandato externo que empuja en la misma dirección.

Madurez antes que velocidad

La tentación de desplegar IA rápido para mostrar resultados es comprensible en un sector tan competitivo como el bancario. Pero los casos de modelos crediticios que reprodujeron sesgos históricos —o de chatbots que ofrecieron información incorrecta sobre productos financieros— tienen, casi siempre, un factor común: datos sin gobierno. Bob Seiner, referente en Non-Invasive Data Governance, sostiene que el gobierno del dato no es un proyecto separado de la operación, sino una capa de responsabilidad que debe integrarse en los procesos existentes sin crear fricción adicional. Esa filosofía es especialmente relevante para bancos latinoamericanos con estructuras más ágiles, donde la burocracia de un programa de DG clásico puede matar la iniciativa antes de dar frutos.

La pregunta ya no es si los bancos de la región necesitan gobierno del dato para escalar IA — la pregunta es cuántos incidentes evitables hacen falta antes de que ese programa pase al tope de la agenda del CDO.

La adopción masiva de inteligencia artificial en las organizaciones latinoamericanas ha disparado una pregunta que muchos equipos de datos no pueden responder con certeza: ¿dónde están realmente los datos que alimentan esos modelos? El problema no es nuevo, pero la IA lo volvió urgente. Sin un inventario preciso y un data lineage actualizado, cualquier iniciativa de IA corporativa construye sobre terreno inestable.

Durante años, la gobernanza de datos fue tratada como un proyecto de infraestructura de segundo orden: importante en el papel, postergado en la práctica. Los datos se acumularon en silos departamentales, data lakes sin catalogar y sistemas heredados que nadie se atrevía a tocar. Ese desorden era manejable cuando los datos se usaban para reportes o dashboards. Deja de serlo cuando un modelo de lenguaje o un sistema de ML los consume sin discriminar calidad, origen ni clasificación de sensibilidad.

El inventario como base de todo

El primer paso que propone el DAMA-DMBOK para cualquier programa de gobierno de datos es el establecimiento de un inventario de activos de datos —lo que en la industria se conoce como data catalog. No se trata de una herramienta tecnológica per se, sino de una decisión organizacional: alguien tiene que ser responsable de saber qué datos existen, dónde residen, quién los usa y con qué propósito. Ese rol es el data steward, y en la mayoría de las empresas latinoamericanas todavía no está formalizado ni tiene capacidad de decisión real.

El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), identifica la capacidad de localización y clasificación de datos como una de las capabilities fundacionales —equivalente al nivel 8 de su modelo de madurez— sin la cual ningún control de privacidad, seguridad o calidad puede implementarse de forma efectiva. Dicho de otro modo: si no sabés dónde están tus datos, no podés protegerlos, no podés auditarlos y no podés cumplir con ninguna obligación regulatoria.

La presión regulatoria que ya llegó

En América Latina, esta exigencia dejó de ser solo buena práctica para convertirse en obligación legal en varios frentes. En Brasil, la Lei Geral de Proteção de Dados (LGPD) requiere que las organizaciones puedan demostrar el propósito y la base legal de cada tratamiento de datos personales —algo imposible sin un registro de actividades de tratamiento actualizado. En Argentina, la Ley 25.326 y la reglamentación de la AAIP (Agencia de Acceso a la Información Pública) exigen que los responsables de bases de datos personales puedan informar a los titulares qué datos tienen y con qué fin. En México, la LFPDPPP impone obligaciones similares sobre el aviso de privacidad y los transfers de datos a terceros.

Lo que la IA agrega a este escenario es una capa adicional de complejidad: cuando los datos personales se usan para entrenar o alimentar un modelo, el ciclo de vida del dato se vuelve difuso. ¿En qué punto el dato deja de ser “tratado” y pasa a ser parte del modelo? ¿Quién es el data steward de un dataset de entrenamiento? Estas preguntas no tienen respuesta regulatoria definitiva en la región, pero las autoridades de protección de datos ya las están formulando.

Qué hace un CDO con esto el lunes

La pregunta operativa no es filosófica. Un Chief Data Officer que está evaluando o ya tiene iniciativas de IA en producción debería revisar esta semana al menos tres cosas concretas:

• Inventario de datasets en uso por modelos de IA: ¿están catalogados con clasificación de sensibilidad (dato personal, dato confidencial, dato público)? ¿Tienen data steward asignado?
• Data lineage de extremo a extremo: ¿puede trazarse el origen de cada dataset hasta la fuente primaria? ¿Hay transformaciones no documentadas en el camino?
• Revisión de acuerdos con proveedores de IA: ¿los contratos con vendors cloud o de modelos de terceros contemplan cláusulas sobre uso de datos para reentrenamiento? ¿Son consistentes con las bases legales declaradas en los registros de tratamiento?

El framework Non-Invasive Data Governance de Bob Seiner plantea que los controles de gobernanza más efectivos son los que se integran en los procesos existentes sin crear burocracia nueva. Aplicado al contexto de IA, eso significa que el CDO no necesita un proyecto de 18 meses para responder dónde están sus datos: necesita asignar ownership de datos en los pipelines actuales y establecer una política mínima de clasificación antes de que cualquier dataset entre a un flujo de entrenamiento o inferencia.

La ventana se está cerrando

En Chile, el nuevo reglamento de la Ley 21.719 —que entrará en vigencia en 2026— incorpora requisitos de accountability que obligarán a las organizaciones a demostrar, no solo declarar, que tienen control sobre sus datos personales. Colombia avanza en la misma dirección con la actualización de la Ley 1581 bajo supervisión de la SIC (Superintendencia de Industria y Comercio). El patrón regional es claro: la carga de la prueba se invierte, y ya no alcanza con tener una política de privacidad publicada en el sitio web.

Las organizaciones que lleguen a esa instancia sin un catálogo de datos operativo ni un modelo de ownership claro no tendrán un problema de compliance: tendrán un problema de negocio.

La gobernanza de datos geoespaciales se instaló como tema central en la São Paulo Climate Week, en un debate organizado por la Fundação Getulio Vargas (FGV). El evento puso de relieve una brecha estructural que pocas organizaciones de la región abordan formalmente: los datos de localización, cobertura terrestre y movilidad climática carecen, en la mayoría de los casos, de ownership definido, linaje documentado y políticas de calidad aplicables a su ciclo de vida completo.

El encuentro reunió a referentes del sector público, academia y organizaciones de la sociedad civil para discutir cómo los datos geoespaciales —imágenes satelitales, registros de sensores remotos, capas de información territorial— se producen en volúmenes crecientes pero se gestionan con marcos de gobernanza rudimentarios o directamente inexistentes. La paradoja es conocida en la industria: cuanto más sofisticada la fuente del dato, más informal suele ser su administración interna.

El problema de fondo: datos sin dueño

En el lenguaje del DAMA-DMBOK, los datos geoespaciales representan un dominio de alta complejidad técnica con bajo nivel de madurez en stewardship —es decir, en la figura del data steward responsable de definir estándares, validar calidad y gestionar el acceso. A diferencia de los datos transaccionales o de clientes, los datasets geoespaciales suelen ser producidos por equipos de ingeniería o ciencia de datos sin una cadena clara de accountability hacia el negocio o la política pública. El resultado es que el dato existe, pero nadie puede responder con certeza de dónde viene, qué transformaciones sufrió ni si es apto para tomar decisiones de política climática.

El modelo de madurez DCAM (Data Management Capability Assessment Model) del EDM Council ubica la gestión de datos geoespaciales en las capabilities asociadas a data quality y data lineage. En organizaciones que trabajan con este tipo de activos —agencias ambientales, ministerios de infraestructura, fondos de inversión con criterios ESG— la ausencia de linaje documentado es un riesgo operativo y reputacional concreto, no un problema abstracto de arquitectura.

El contexto regulatorio presiona desde varios frentes

Brasil no es el único país de la región donde este debate se vuelve urgente. La Lei Geral de Proteção de Dados (LGPD) ya planteó, desde 2020, que los datos de geolocalización pueden constituir datos personales cuando permiten identificar o inferir el comportamiento de individuos. Eso significa que un dataset de movilidad poblacional usado para modelado climático puede, simultáneamente, estar sujeto a controles de gobernanza corporativa y a obligaciones de privacidad ante la Autoridade Nacional de Proteção de Dados (ANPD). La intersección entre ambos marcos es territorio que pocas organizaciones brasileñas tienen mapeado formalmente.

En Argentina, la Ley 25.326 de Protección de Datos Personales y su autoridad de aplicación, la AAIP, también contemplan la geolocalización como dato sensible cuando se combina con perfiles de comportamiento. Mientras tanto, el Instituto Nacional de Estadística e Informática (INEI) de Perú y el DANE de Colombia gestionan enormes volúmenes de datos geoespaciales censales con marcos de gobernanza que, según referentes del sector, todavía operan por debajo de los estándares que exigiría una auditoría bajo ISO/IEC 38505 —el estándar internacional de gobernanza de datos para órganos directivos.

Qué puede hacer un CDO el lunes

Para un Chief Data Officer o Data Governance Manager cuya organización usa datos geoespaciales —aunque sea de forma periférica—, el debate de São Paulo ofrece una señal de acción concreta. El primer paso es inventariar qué datasets geoespaciales existen en la organización, quién los produjo, con qué frecuencia se actualizan y si tienen un data steward formalmente asignado. En la mayoría de los casos, ese inventario no existe o está desactualizado. Herramientas de data catalog con soporte para metadatos geoespaciales —como OpenMetadata o Collibra con conectores GIS— permiten iniciar ese relevamiento sin necesidad de un proyecto de transformación de largo plazo.

El segundo movimiento es evaluar si alguno de esos datasets cruza el umbral de dato personal bajo la regulación local aplicable. Si la organización opera en Brasil, la respuesta en muchos casos será afirmativa, lo que implica coordinar con el DPO (Data Protection Officer) para definir la base legal del tratamiento y documentar la evaluación de impacto correspondiente. No hacerlo es dejar un flanco abierto ante la ANPD en un contexto en que el regulador brasileño ha escalado su actividad de supervisión en los últimos doce meses.

Una ventana que no estará abierta siempre

El hecho de que la FGV lleve este debate a un evento de agenda climática internacional no es accidental. Los compromisos de descarbonización, reporte ESG y transparencia territorial que asumen gobiernos y empresas de la región dependen, en última instancia, de la calidad y trazabilidad de los datos geoespaciales que los sustentan. Si esos datos no tienen gobernanza, los compromisos tampoco la tienen.

La gobernanza de datos geoespaciales dejó de ser un nicho técnico: es la infraestructura invisible de la agenda climática en América Latina, y su ausencia tiene costos medibles.

Sin datos de calidad, un programa de data governance es una estructura vacía. La relación entre ambos conceptos no es complementaria sino constitutiva: la calidad del dato es la condición de posibilidad de cualquier decisión que el gobierno de datos pretenda respaldar. Para los equipos que lideran iniciativas de gobernanza en América Latina, entender esa relación en términos operativos marca la diferencia entre un framework decorativo y uno que genera valor real.

El error más frecuente que cometen las organizaciones al arrancar un programa de gobernanza es tratar la calidad de datos como un proyecto paralelo o posterior. Se definen políticas, se asignan data stewards, se instala un catálogo de datos, y recién entonces alguien pregunta: ¿pero estos datos son confiables? Para ese momento, las decisiones ya se tomaron sobre cimientos inestables. El DAMA-DMBOK 2 es explícito al respecto: la gestión de la calidad del dato (Data Quality Management) es uno de los once knowledge areas del framework, y su integración con Data Governance no es opcional sino estructural.

Qué significa “calidad” en un contexto de gobernanza

La calidad de datos no se reduce a que los registros estén completos o sin errores tipográficos. En un marco de gobernanza robusto, la calidad se evalúa contra dimensiones precisas: completitud, consistencia, precisión, oportunidad, unicidad y validez. Cada dimensión responde a una pregunta de negocio distinta. Un dato puede ser preciso pero inoportuno —llegar fuera del ciclo de decisión—, o consistente en un sistema pero contradictorio al cruzarse con otro. El modelo de John Ladley en “Data Governance: How to Design, Deploy, and Sustain an Effective Data Governance Program” subraya que las reglas de calidad deben derivarse de los casos de uso del negocio, no de criterios técnicos aislados.

Esto tiene una implicancia directa para el diseño del programa: los data stewards —los responsables funcionales del dato en cada dominio— son quienes deben definir qué significa “buena calidad” para su conjunto de datos, no el equipo de IT. Un steward de datos maestros de clientes en un banco tiene criterios de calidad distintos a los de un steward de datos de riesgo crediticio, aunque ambos trabajen con información del mismo cliente. Esta distinción es central en el enfoque de Non-Invasive Data Governance de Bob Seiner, que propone formalizar roles que ya existen en la organización en lugar de imponer estructuras nuevas.

El costo de ignorarlo: casos concretos en la región

En América Latina, la degradación de la calidad de datos tiene consecuencias regulatorias directas. Las entidades financieras en Brasil que reportan al Banco Central bajo el sistema SCR (Sistema de Informações de Crédito) enfrentan penalidades cuando los datos remitidos presentan inconsistencias. En Argentina, la Comunicación A 7724 del BCRA establece requisitos de integridad de la información para los reportes de gestión de riesgo, lo que obliga a los bancos a mantener controles de calidad que —aunque no se llamen así— son capabilities equivalentes a los que define el CDMC (Cloud Data Management Capabilities) del EDM Council. En México, la CNBV tiene requerimientos similares para la remisión de información regulatoria periódica.

Más allá del sector financiero, organizaciones con grandes volúmenes de datos personales enfrentan un riesgo adicional: datos de baja calidad pueden derivar en tratamientos incorrectos de información personal, lo que en jurisdicciones con leyes activas como la LGPD brasileña o la Ley 25.326 argentina puede traducirse en incumplimientos con consecuencias sancionatorias. Un registro duplicado mal gestionado puede implicar el envío de comunicaciones a personas que ya ejercieron su derecho de supresión.

Qué hace un CDO con esto el lunes

El punto de entrada más práctico es el data quality scorecard por dominio. Antes de expandir el catálogo de datos o incorporar nuevas fuentes al data lineage, un CDO debería poder responder tres preguntas por cada dominio crítico: ¿cuál es la tasa de completitud actual?, ¿existe un SLA de calidad definido y acordado con el negocio?, y ¿hay un data steward asignado con capacidad de escalar issues de calidad? Si alguna de las tres respuestas es “no sé”, ese dominio es el punto de partida.

• Mapear los dominios de datos críticos para el negocio y asignar un data steward con mandato explícito sobre calidad.
• Definir al menos tres dimensiones de calidad medibles por dominio, con umbrales acordados con stakeholders de negocio.
• Integrar los controles de calidad en el pipeline de datos, no como paso posterior sino como gate de ingesta.
• Establecer un proceso de escalamiento claro cuando un dataset no alcanza el umbral mínimo de calidad para ser usado en decisiones.
• Revisar si los controles de calidad actuales cubren los requisitos de reporte regulatorio aplicables en la jurisdicción.

Herramientas como Great Expectations, Monte Carlo o los módulos nativos de calidad en plataformas como Collibra o Alation permiten automatizar buena parte de este monitoreo, pero la automatización sin ownership humano reproduce el problema a mayor velocidad. La tecnología es el habilitador; el data steward es el responsable.

Gobernanza sin calidad es solo burocracia

Los programas de data governance que no resuelven el problema de calidad generan uno nuevo: una capa de procesos y documentación que le da a la organización la ilusión de control sin el control real. Los comités se reúnen, las políticas se aprueban, el catálogo crece, y las decisiones siguen tomándose sobre datos que nadie confía del todo. Esa desconexión entre la estructura de gobernanza y la realidad del dato es, según el Data Governance Institute, una de las causas principales de abandono de iniciativas de este tipo en los primeros dos años.

Un programa de gobernanza se mide, en última instancia, por si los datos que produce son usados con confianza. Todo lo demás es arquitectura.