El gobierno de datos acumula años de promesas y frameworks bien documentados, pero en la mayoría de las organizaciones sigue siendo un ejercicio de diseño más que de ejecución. La brecha no está en el conocimiento teórico — está en la distancia entre la política aprobada por el comité y la decisión que toma un analista a las 9 de la mañana del lunes. Cerrar esa brecha es el verdadero desafío operativo para los equipos de datos en 2025 y 2026.
El problema de fondo: governance como artefacto
Durante años, muchas organizaciones construyeron su programa de gobierno de datos alrededor de entregables: un glosario de negocio, un mapa de data lineage —la trazabilidad que permite saber de dónde viene un dato y cómo se transforma a lo largo de su ciclo de vida—, un catálogo de activos, políticas de clasificación. El problema no es que esos artefactos estén mal; el problema es que se actualizan trimestralmente, viven en herramientas que pocos consultan y no están conectados a los flujos de trabajo diarios. En la práctica, el dato se procesa igual con o sin ellos. El DAMA-DMBOK, en su segunda edición, ya advertía sobre esta trampa: un programa de governance que no se integra en los procesos operativos es, a efectos prácticos, decorativo.
Bob Seiner, referente de la corriente Non-Invasive Data Governance, lleva más de dos décadas argumentando que el gobierno de datos debería operar sobre las responsabilidades que ya existen — no crear burocracia nueva — sino formalizar quién ya toma decisiones sobre los datos y hacer eso visible, medible y repetible. La operacionalización no implica agregar pasos; implica incrustar controles donde el trabajo ya ocurre.
Qué significa “operativo” en la práctica
Hablar de gobierno de datos operativo tiene al menos tres dimensiones concretas que vale distinguir. La primera es la integración en pipelines: las reglas de calidad, clasificación y ownership no se definen fuera del pipeline — se ejecutan dentro de él. La segunda es la asignación de data stewards —responsables de dominio de datos con mandato formal— que participan en las decisiones técnicas, no solo en las revisiones de política. La tercera es la medición continua: dashboards de calidad de datos vinculados a KPIs de negocio, no reportes mensuales en PDF.
- Reglas de calidad y clasificación embebidas en los pipelines de ingesta y transformación.
- Data stewards con capacidad de bloquear o escalar issues en tiempo real, no solo en reuniones de comité.
- Métricas de governance como parte del scorecard del CDO, no en un reporte separado de compliance.
- Catálogo de datos activo, vinculado al entorno de desarrollo, no a un portal que nadie visita.
El contexto regulatorio empuja la urgencia en LATAM
En América Latina, la presión externa para operacionalizar el gobierno de datos ya no es solo una buena práctica — empieza a ser una exigencia implícita en marcos regulatorios sectoriales. En Brasil, la ANPD ha orientado sus primeras resoluciones hacia la demostración de controles efectivos sobre datos personales, no solo sobre la existencia de políticas escritas: las empresas que no puedan mostrar evidencia operativa de su programa corren riesgo en cualquier proceso de fiscalización bajo la LGPD. En Argentina, la Comunicación A 8073 del BCRA exige a las entidades financieras capacidades de gestión del ciclo de vida del dato que, en el marco del EDM Council (CDMC), corresponden a niveles de madurez 7 y 8 — aunque la mayoría de los bancos locales aún no ha formalizado esa equivalencia ni la certifica. En México, el INAI ha intensificado la expectativa de que los responsables de tratamiento puedan demostrar, con evidencia, los controles aplicados sobre datos personales sensibles.
“La governance que no se puede demostrar en producción no existe desde el punto de vista regulatorio. Una política aprobada en un comité no es un control.”
— Principio operativo, EDM Council CDMC Framework
Qué hace un CDO con esto el lunes
La pregunta concreta para cualquier Chief Data Officer o Data Governance Manager es cómo avanzar sin necesidad de un proyecto de transformación de 18 meses. Una ruta práctica parte de identificar los tres o cuatro dominios de datos con mayor impacto regulatorio o de negocio — clientes, productos, proveedores, transacciones — y mapear quién toma decisiones sobre esos datos hoy, aunque no tenga título formal de data steward. Formalizar ese ownership es el primer paso hacia un control operativo real. El segundo es revisar si las reglas de calidad definidas en el glosario o en el catálogo están efectivamente implementadas en algún punto del pipeline, o solo existen en un documento Word. Si la respuesta es “solo en el documento”, ese es el gap prioritario. El tercer paso es conectar al menos una métrica de calidad de datos a un indicador de negocio que el área usuaria ya monitoree — eso cambia la conversación de compliance a valor.
El ISO/IEC 38505, marco de governance de datos para órganos de dirección, refuerza este enfoque: la responsabilidad final sobre los datos no recae en el equipo de TI ni en el equipo de datos, sino en quienes toman decisiones de negocio. Operacionalizar governance es, en último término, hacer esa responsabilidad visible y exigible en el día a día.
Un programa de gobierno de datos que no se puede demostrar en producción no es un programa — es una presentación de PowerPoint con fecha de vencimiento.
Deja un comentario