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.
Deja un comentario