Blog

Desplegar inteligencia artificial sobre datos sin gobierno es repetir, a mayor escala y velocidad, el mismo error que organizaciones latinoamericanas han cometido con cada ola tecnológica anterior: integrar primero, ordenar después. El resultado predecible es un sistema que amplifica el caos en lugar de reducirlo.

Cuando una organización conecta un modelo de lenguaje o un sistema de analítica predictiva a sus repositorios internos sin haber definido quién es responsable de cada dato, qué calidad tiene y bajo qué reglas circula, no está adoptando inteligencia artificial — está construyendo un conducto de alta velocidad hacia sus problemas de datos más viejos. La IA no genera orden: consume el que existe. Si el orden no existe, el modelo lo hace visible de la peor manera posible: en producción, frente al cliente, o frente al regulador.

Por qué la IA expone brechas de gobernanza que los sistemas legacy ocultaban

Los sistemas transaccionales tradicionales toleran datos duplicados, inconsistentes o sin propietario definido porque operan con reglas fijas y flujos predecibles. Un ERP con mala calidad de datos sigue funcionando dentro de sus parámetros. Un modelo de IA entrenado o alimentado con esos mismos datos, en cambio, generaliza las inconsistencias: las aprende, las replica y las escala a toda decisión que toque. Lo que antes era un problema de datos silenciado por la rigidez del sistema, ahora se convierte en un comportamiento del modelo difícil de depurar y más difícil aún de explicar ante una auditoría.

El marco DAMA-DMBOK identifica diez áreas de conocimiento en gobernanza de datos. Las más frecuentemente ausentes en proyectos de IA corporativa en la región son precisamente las más críticas para su funcionamiento: calidad de datos (Data Quality), gestión de metadatos (Metadata Management) y lineaje (Data Lineage). Sin saber de dónde viene un dato, qué transformaciones sufrió y quién lo validó, es imposible auditar por qué un modelo tomó una decisión determinada — requisito que ya no es opcional en ninguna jurisdicción con regulación de IA o de datos personales activa.

El rol del data steward antes del primer prompt

En organizaciones con gobernanza madura, el data steward — responsable operativo de un dominio de datos específico — es quien certifica que un conjunto de datos es apto para un uso determinado antes de que ese uso ocurra. En proyectos de IA, esa certificación debería preceder al entrenamiento o a la conexión del modelo a fuentes internas. Sin embargo, según el EDM Council, menos del 30% de las organizaciones globales que han iniciado proyectos de IA generativa en entornos productivos contaban con ownership formal de datos en los dominios involucrados al momento del despliegue, según se informó en su evaluación CDMC de 2024.

El patrón es conocido en la región: el equipo de datos construye el pipeline, el equipo de negocio aprueba el caso de uso, y la función de gobernanza — cuando existe — es informada después. Bob Seiner, referente de la metodología Non-Invasive Data Governance, describe este modelo como “gobernanza reactiva”: se activa cuando algo sale mal, no cuando se define qué puede salir mal. En proyectos de IA, el costo de esa reactividad es estructuralmente más alto porque los errores se propagan a velocidades que los procesos manuales de remediación no pueden seguir.

México y el costo regulatorio de no gobernar antes de desplegar

México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y su autoridad de control, el INAI, ha emitido lineamientos sobre el uso de datos personales en sistemas automatizados. Si un modelo de IA toma decisiones que afectan a personas físicas — scoring crediticio, selección de candidatos, segmentación de pacientes — y fue alimentado con datos personales sin el consentimiento adecuado o sin una base legal documentada, la organización enfrenta responsabilidad bajo la ley vigente, independientemente de si el modelo “funciona bien” en términos técnicos. La ausencia de linaje documental hace imposible demostrar cumplimiento en una auditoría del INAI.

El escenario no es exclusivo de México. En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige base legal para cada tratamiento de datos personales, incluidos los automatizados, y la ANPD ha señalado explícitamente el uso de IA como área de supervisión prioritaria para 2025-2026. En Argentina, la Ley 25.326 y la AAIP enfrentan un escenario similar con menor capacidad sancionatoria formal, pero con presión creciente desde la esfera judicial. En todos estos casos, un catálogo de datos con clasificación de sensibilidad y linaje documentado es la primera línea de defensa — no el cifrado, no el pentesting, sino saber qué datos tiene la organización y quién responde por ellos.

Cuándo aplica la gobernanza previa — y cuándo ya es tarde

La gobernanza de datos como prerrequisito de IA aplica en cualquier proyecto que involucre datos internos de la organización, datos de clientes, o datos sujetos a regulación sectorial — es decir, prácticamente todos los casos de uso empresarial relevantes. No aplica, o aplica en menor medida, a modelos completamente aislados que operan sobre datos sintéticos o sobre conjuntos públicos sin datos personales, que representan una fracción marginal de los proyectos reales. La pregunta que un CDO debe hacer antes de aprobar el presupuesto de cualquier iniciativa de IA no es “¿tenemos los datos?” sino “¿sabemos qué son esos datos, quién los posee y bajo qué condiciones pueden usarse?”. Si la respuesta a alguna de esas tres preguntas es incierta, el proyecto tiene un problema de gobernanza disfrazado de problema de ingeniería.

Un CDO que enfrenta esta situación en su organización puede tomar tres pasos concretos antes de que el siguiente proyecto de IA entre a producción: primero, mapear los dominios de datos que alimentarán el sistema e identificar si tienen un data steward asignado con accountability formal; segundo, ejecutar un perfil de calidad de datos sobre esas fuentes con métricas de completitud, consistencia y unicidad — herramientas como Great Expectations, Monte Carlo o incluso dbt tests permiten hacerlo sin infraestructura adicional; tercero, documentar el linaje desde la fuente hasta el modelo en el catálogo de datos corporativo, de modo que cualquier auditor interno o externo pueda reconstruir el recorrido del dato sin depender de quien lo construyó. Estos tres pasos no garantizan un modelo perfecto, pero sí una organización que puede defender sus decisiones.

La gobernanza de datos no es el freno de la adopción de IA: es la condición para que esa adopción sea sostenible. Las organizaciones que lo descubran después del primer incidente regulatorio habrán pagado un precio innecesario por una lección que ya estaba disponible.

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.