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.
