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.
