Etiqueta: Normativa

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.

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.