Categoría: Data Governance

La gobernanza de datos dejó de ser un proyecto de TI para convertirse en una capacidad organizacional crítica. En un contexto donde los marcos regulatorios de América Latina se consolidan y la presión sobre los datos corporativos aumenta, los equipos liderados por Chief Data Officers enfrentan una brecha persistente: saben qué es gobernanza de datos, pero pocas organizaciones logran operacionalizarla de manera sostenible.

Durante años, la conversación en torno a la gobernanza de datos giró alrededor de definiciones, políticas y organigramas. El resultado fue previsible: documentos bien redactados que nadie consulta, comités de gobierno que se reúnen trimestralmente sin poder de decisión real, y data stewards —responsables temáticos del dato dentro de un dominio de negocio— que desconocen qué activos tienen a su cargo. El problema no es conceptual. Es de diseño institucional y de priorización ejecutiva.

El dato como activo que se gestiona, no que se almacena

El DAMA-DMBOK (Data Management Body of Knowledge), referencia estándar de la industria, organiza la gestión de datos en once áreas de conocimiento que van desde la arquitectura hasta la calidad y la seguridad. Sin embargo, la mayoría de las organizaciones latinoamericanas que dicen “tener gobernanza” operan únicamente en dos o tres de esas áreas, típicamente calidad de datos y alguna forma de catálogo. Lo que queda fuera —data lineage, ownership formal, clasificación por criticidad, ciclo de vida del dato— es precisamente lo que diferencia una función de gobernanza madura de una iniciativa de limpieza de datos con otro nombre.

El EDM Council, con su marco CDMC (Cloud Data Management Capabilities), ofrece una perspectiva complementaria orientada a entornos cloud y regulados. Sus doce capabilities permiten medir la madurez de forma granular. Lo relevante para la región es que varios bancos brasileños que reportan al Banco Central bajo las resoluciones del CMN ya operan con prácticas equivalentes a los niveles intermedios del CDMC —especialmente en clasificación de datos y controles de acceso— aunque sin la certificación formal ni la trazabilidad documentada que exige un programa de gobernanza robusto.

El marco regulatorio regional como palanca, no como amenaza

En América Latina, la presión regulatoria está empujando la agenda de gobernanza desde afuera hacia adentro. La LGPD brasileña (Lei Geral de Proteção de Dados) obliga a las organizaciones a mapear sus datos personales, definir bases legales de tratamiento y designar un Encarregado —rol que en la práctica recae sobre el DPO o se superpone con funciones de governance. En Argentina, la Ley 25.326 está en proceso de reforma con un proyecto que incorpora estándares más cercanos al GDPR europeo, incluyendo la figura del delegado de protección de datos y evaluaciones de impacto. En México, la LFPDPPP y sus lineamientos del INAI ya exigen documentación de flujos de datos personales que es, en esencia, data lineage aplicado a un subconjunto crítico del inventario corporativo.

Este contexto crea una oportunidad concreta: usar el cumplimiento regulatorio como caso de negocio para financiar el programa de gobernanza más amplio. Un CDO que logra articular “necesitamos catálogo de datos y data lineage para responder a los requerimientos de la ANPD o la AAIP” tiene un argumento presupuestario mucho más sólido que uno que habla de “madurez de datos” en abstracto.

Qué hace un CDO con esto el lunes a la mañana

El punto de partida no es un framework completo. Es una decisión de scope. Bob Seiner, referente del modelo Non-Invasive Data Governance, sostiene que la gobernanza efectiva parte de reconocer y formalizar lo que la organización ya hace informalmente —quién responde preguntas sobre un dato, quién aprueba cambios en una definición de negocio— antes de imponer estructuras nuevas. Aplicado a la realidad latinoamericana, esto significa identificar los tres o cinco dominios de datos más críticos para el negocio (clientes, productos, finanzas, por ejemplo), asignar data stewards con nombre y apellido en cada uno, y establecer un mecanismo mínimo de resolución de conflictos sobre definiciones y calidad.

• Auditar qué áreas del DAMA-DMBOK están cubiertas formalmente y cuáles operan de manera ad hoc o directamente no existen.
• Mapear los dominios de datos que tienen impacto regulatorio directo (datos personales bajo LGPD/Ley 25.326/LFPDPPP) y usarlos como piloto del programa de gobernanza.
• Identificar los data stewards informales actuales —las personas que hoy de facto responden preguntas sobre el dato— y formalizarlos antes de crear roles nuevos.
• Establecer una métrica de calidad de datos por dominio y reportarla al Comité de Dirección junto con el riesgo regulatorio asociado.

La trampa del perfeccionismo y el costo de la espera

Uno de los patrones más comunes en organizaciones que llevan años “implementando gobernanza” sin resultados visibles es la búsqueda del modelo perfecto antes de ejecutar. Se diseña el catálogo ideal, se debaten taxonomías durante meses, se espera la herramienta correcta. Mientras tanto, los datos críticos siguen sin owner formal, los pipelines se multiplican sin documentación y los auditores —ya sean internos o de la autoridad regulatoria— encuentran los mismos gaps año tras año. John Ladley, en su obra sobre data governance, es explícito al respecto: la gobernanza de datos es un programa de gestión del cambio con componentes técnicos, no un proyecto tecnológico con componentes de gestión del cambio. Invertir esa relación es la causa más frecuente de fracaso.

En un entorno donde las regulaciones latinoamericanas están madurando más rápido que los programas internos de gobernanza, la pregunta ya no es si implementar un marco —sino cuánto cuesta cada mes de demora.

Benín se posicionó como referente regional en protección de datos personales al compartir su experiencia en el Foro Africano de Gobernanza de Datos Personales, un espacio que busca articular estándares comunes para el continente. La iniciativa pone en evidencia una dinámica que América Latina conoce bien: la tensión entre marcos legales nacionales fragmentados y la necesidad de interoperabilidad regional. Para los equipos de gobierno de datos en LATAM, el movimiento africano ofrece un espejo incómodo pero útil.

Un foro, muchos marcos: el desafío de la armonización

El encuentro reunió a representantes de autoridades de protección de datos y organismos gubernamentales de distintos países africanos con el objetivo de construir criterios compartidos sobre gestión de datos personales. Benín, que cuenta con una autoridad de protección de datos activa y legislación específica en la materia, expuso según se informó su modelo de implementación como caso de referencia. El eje no fue técnico sino institucional: cómo una autoridad nacional puede operar con recursos limitados y aun así generar capacidades de enforcement creíbles.

El paralelo con América Latina es directo. La región cuenta con al menos ocho marcos legales de datos personales activos —entre ellos la LGPD brasileña, la Ley 25.326 argentina, la LFPDPPP mexicana, la Ley 1581 colombiana y la Ley 19.628 chilena en proceso de reforma— pero la coordinación entre autoridades sigue siendo incipiente. La Red Iberoamericana de Protección de Datos (RIPD) cumple un rol de articulación, aunque sin poder vinculante sobre las decisiones de cada autoridad nacional.

El ownership del dato como problema de gobernanza, no de tecnología

Lo que el foro africano pone sobre la mesa —y que resuena en la agenda de cualquier CDO de la región— es que los desafíos de gobernanza de datos personales raramente son técnicos en su origen. Son problemas de ownership: quién decide qué se recolecta, quién es responsable cuando el dato se comparte entre entidades, y qué controles de acceso existen a lo largo del ciclo de vida del dato. En términos del DAMA-DMBOK, esto corresponde al dominio de Data Security y Data Governance en su intersección: definir roles de data steward con responsabilidad explícita sobre datos sensibles y garantizar que esa responsabilidad esté documentada en el catálogo de datos.

El marco CDMC (Cloud Data Management Capabilities) del EDM Council establece en su capability 9 los controles de privacidad como componente integrado de la arquitectura de datos, no como capa adicional. Organizaciones en Brasil que operan bajo LGPD con obligación de reportar incidentes a la ANPD en 72 horas ya están, en la práctica, obligadas a tener ese nivel de madurez. El problema es que muchas lo implementan de forma reactiva, como respuesta a una auditoría, y no como parte del modelo operativo de gobierno.

Qué hace un CDO con esto el lunes

El movimiento africano hacia estándares regionales debería funcionar como señal de alerta temprana para equipos de DG en LATAM. Cuando una región emergente comienza a armonizar marcos de gobernanza de datos personales, los socios comerciales y reguladores globales elevan sus expectativas de interoperabilidad. Esto tiene consecuencias prácticas: un CDO que hoy no tiene mapeado el flujo transfronterizo de datos personales de su organización —especialmente en operaciones que cruzan Brasil, Argentina y México— está operando con un riesgo regulatorio no cuantificado.

Los pasos concretos para esta semana son tres. Primero, revisar si el data catalog corporativo tiene campos de clasificación de sensibilidad activos y si están siendo completados por los data stewards asignados, no por el equipo de IT de forma genérica. Segundo, verificar si existen acuerdos de transferencia de datos documentados para cada flujo transfronterizo, especialmente hacia proveedores cloud con infraestructura fuera de la región. Tercero, contrastar el inventario de tratamientos de datos personales con los requisitos de notificación de la autoridad local: en Argentina, la AAIP exige inscripción de bases de datos; en Colombia, el Registro Nacional de Bases de Datos (RNBD) ante la SIC cumple una función equivalente.

La gobernanza como ventaja competitiva regional

Más allá del cumplimiento, la experiencia africana sugiere que los países y organizaciones que invierten en construir capacidades de gobernanza de datos personales antes de que la presión regulatoria sea máxima terminan en mejor posición para atraer inversión y operar en mercados exigentes. En LATAM, el sector financiero es el que más avanzó en esta dirección: los bancos chilenos bajo supervisión de la CMF y las entidades financieras argentinas que reportan al BCRA bajo la Comunicación A 8073 ya operan con controles de calidad y linaje de datos que se superponen con los requerimientos de privacidad, aunque sin certificación formal bajo un marco como CDMC.

La pregunta que deja el foro africano no es si LATAM necesita mayor armonización regulatoria —eso ya está en la agenda— sino si las organizaciones de la región van a esperar que esa armonización llegue desde arriba o van a construir la madurez de gobernanza que les permita operar en cualquier escenario regulatorio que venga.

El data lineage —la capacidad de rastrear el origen, las transformaciones y el destino de cada dato en una organización— se ha convertido en un requisito no negociable para el gobierno corporativo de datos. Sin embargo, la mayoría de las implementaciones tienen un punto ciego crítico: los sistemas mainframe y legados que, en industrias como banca, seguros y retail, siguen concentrando los registros más sensibles y de mayor volumen.

En la práctica, cuando un CDO pide un mapa completo del flujo de datos desde el origen hasta el consumo, suele recibir una cadena con eslabones faltantes. Las plataformas modernas de data catalog documentan con precisión lo que ocurre en capas cloud o en pipelines construidos sobre tecnologías abiertas, pero el momento en que un dato nació en un sistema COBOL o en un archivo VSAM queda fuera del grafo. Eso no es lineage de extremo a extremo: es lineage a partir del segundo paso.

El problema de la brecha de origen

La integración entre Ataccama y Rocket Software apunta exactamente a cerrar esa brecha. Rocket Software aporta capacidad de extracción de metadatos técnicos desde entornos IBM z/OS —incluyendo programas COBOL, JCL, DB2 y estructuras de datos VSAM— mientras que Ataccama ONE los absorbe y los vincula al grafo de lineage que conecta con el resto del ecosistema de datos moderno. El resultado es un linaje continuo que no se interrumpe cuando el dato proviene de un mainframe.

Según se informó, la integración permite mapear automáticamente las transformaciones que ocurren dentro del código COBOL sin intervención manual, un cuello de botella histórico que obligaba a los equipos de data stewardship a documentar esas capas a mano o simplemente ignorarlas. Para organizaciones con decenas de miles de programas batch activos, la documentación manual no es una opción realista.

Por qué el lineage incompleto es un riesgo de governance

Desde la perspectiva del DAMA-DMBOK, el data lineage es un componente central del área de conocimiento de Metadata Management y un prerequisito operativo para la gestión efectiva de calidad de datos y de ciclo de vida. Sin lineage completo, el impact analysis —saber qué reportes, modelos o decisiones se ven afectados si cambia una tabla fuente— es parcial en el mejor caso y engañoso en el peor. En entornos regulados, eso tiene consecuencias directas.

El problema se amplifica cuando los datos de origen mainframe alimentan modelos de inteligencia artificial o agentes automatizados de decisión. Si el sistema no puede trazar la procedencia del dato que entrenó un modelo o que ingesta un agente en tiempo real, la organización queda expuesta a riesgos de explicabilidad que ya están siendo objeto de escrutinio regulatorio en varias jurisdicciones.

El ángulo regulatorio en América Latina

En la región, la presión por tener lineage auditable no es solo una aspiración de madurez técnica: es una exigencia emergente. En Brasil, la ANPD ha enfatizado en sus guías de adecuación a la LGPD que las organizaciones deben poder demostrar el flujo completo de datos personales, desde la recolección hasta el descarte. En Argentina, la Comunicación A 7724 del BCRA —que regula la gestión de riesgos tecnológicos en entidades financieras— requiere trazabilidad sobre los procesos que afectan datos críticos. Los bancos argentinos que todavía operan núcleos bancarios sobre mainframe IBM están, en muchos casos, en deuda con ese requisito porque su lineage se interrumpe precisamente en esa capa.

En Colombia, la Superintendencia Financiera ha impulsado estándares de gobierno de datos que incluyen mapeo de flujos de información como condición para la aprobación de modelos internos de riesgo. Las entidades que no pueden demostrar el origen de los datos que alimentan esos modelos enfrentan observaciones formales en los procesos de supervisión. La brecha de lineage en mainframe, lejos de ser un problema técnico interno, tiene implicancias regulatorias concretas.

Qué hace un CDO con esto el lunes

El primer paso accionable es un inventario de opacidad: identificar cuántos de los pipelines catalogados en la plataforma actual tienen como origen un sistema mainframe o legado sin cobertura de lineage. Ese número —que en bancos medianos de la región suele superar el 40% de los flujos críticos, según estimaciones de consultoras especializadas— define la urgencia del caso de negocio. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), clasifica el lineage end-to-end como una capability de nivel 2 dentro del dominio de Data Quality and Controls; organizaciones que no pueden acreditar esa cobertura difícilmente alcanzan niveles de certificación relevantes.

El segundo paso es evaluar si la arquitectura actual de metadata management tiene un conector hacia los entornos z/OS o si depende de documentación manual gestionada fuera del catalog. Si la respuesta es la segunda, el riesgo de desactualización es permanente: cada cambio en un programa COBOL que no se refleja en el grafo de lineage es un punto ciego nuevo. La integración entre herramientas especializadas en extracción de metadatos mainframe y plataformas de gobierno modernas es, hoy, la solución técnica más viable para organizaciones que no pueden —ni quieren— migrar esos sistemas en el corto plazo.

La apuesta por la continuidad, no por la migración

El enfoque de integración entre capas —en lugar de exigir la migración del sistema de origen como condición para tener lineage— reconoce una realidad que muchos fabricantes de plataformas modernas evitan admitir: los mainframes no van a desaparecer en los próximos cinco años en la banca latinoamericana. Según se informó en distintos foros del sector, más del 70% de las transacciones financieras en la región siguen procesándose sobre arquitecturas z/OS o equivalentes. Diseñar una estrategia de governance que ignore esa capa es diseñar una estrategia incompleta.

El lineage que no llega hasta el origen no es lineage: es una historia que empieza a la mitad.