Data governance: de obligacion legal a ventaja competitiva

El problema no es cumplir la ley. El problema es que tus datos mienten.

La mayoria de las organizaciones descubren que necesitan data governance de la peor forma posible: un informe al consejo con numeros que no cuadran, un regulador que pide un linaje de datos que nadie puede reconstruir, o un modelo de ML que produce predicciones absurdas porque se alimento de basura bien formateada.

El reflejo habitual es tratarlo como un problema de compliance. Se contrata un DPO, se redactan politicas, se implementa un banner de cookies y se declara victoria. Pero el GDPR es solo la capa superficial. El problema real es que la organizacion no sabe que datos tiene, donde estan, quien los toco por ultima vez, ni si son correctos.

Hemos trabajado con empresas de logistica que tenian 47 definiciones distintas de “envio completado” repartidas en 12 sistemas. Con bufetes de abogados que descubrieron datos de clientes en entornos de test tres anos despues de que el caso se cerrase. Con retailers cuyo stock “en tiempo real” tenia un desfase de 6 horas porque nadie sabia que un proceso ETL fallaba silenciosamente cada noche.

Esos no son problemas de GDPR. Son problemas de gobierno del dato. Y cuestan dinero real.

Que es data governance (y que no es)

Data governance es el conjunto de politicas, procesos, roles y herramientas que aseguran que los datos de una organizacion son precisos, consistentes, seguros y utilizables. No es una herramienta que se compra. No es un proyecto con fecha de fin. Es una disciplina operativa, como la contabilidad o el control de calidad.

Lo que no es:

• No es solo GDPR/LOPD. Compliance es un subconjunto de governance, no al reves. Puedes cumplir perfectamente con la normativa y tener datos inutilizables.
• No es un proyecto de IT. Si vive exclusivamente en tecnologia, fracasara. Governance requiere involucrar negocio, legal, operaciones y datos.
• No es un catalogo de datos bonito. Un catalogo sin procesos de actualizacion es un documento muerto en seis meses.
• No es un freno a la innovacion. Bien implementado, governance acelera el acceso a datos fiables y reduce el tiempo que los equipos dedican a limpiar, reconciliar y discutir numeros.

Los cuatro pilares

Un programa de data governance maduro se sostiene sobre cuatro pilares:

1. Catalogo de datos. El inventario de todos los activos de datos de la organizacion: tablas, ficheros, APIs, dashboards, modelos. Cada activo tiene un propietario, una descripcion, un esquema, un nivel de clasificacion (publico, interno, confidencial, restringido) y un indicador de calidad. Sin catalogo, nadie sabe que datos existen ni donde buscarlos.

2. Calidad de datos. Reglas medibles que definen cuando un dato es “bueno”. Completitud (no hay nulls donde no deberia haberlos), unicidad (no hay duplicados), consistencia (el mismo concepto tiene el mismo formato en todos los sistemas), precision (el dato refleja la realidad) y frescura (el dato esta actualizado). Estas reglas se automatizan y se ejecutan continuamente.

3. Linaje de datos. La capacidad de rastrear un dato desde su origen hasta su consumo. Cuando un KPI en un dashboard muestra un numero incorrecto, el linaje te permite seguir el hilo: de que tabla sale, que transformaciones sufrio, que proceso lo alimento, de que sistema fuente proviene. Sin linaje, depurar un error en un informe ejecutivo se convierte en arqueologia.

4. Modelo organizativo. Quien es responsable de que. Data owners (definen las reglas de negocio), data stewards (implementan y mantienen la calidad), data engineers (construyen los pipelines), y data consumers (usan los datos para tomar decisiones). Sin roles claros, todo el mundo asume que la responsabilidad es de otro.

Catalogo de datos: de inventario a sistema nervioso

Un catalogo de datos no es un Excel con una lista de tablas. Es un sistema vivo que conecta datos con contexto: quien los creo, para que sirven, con que frecuencia se actualizan, como de fiables son y quien los usa.

Herramientas

El mercado ha madurado significativamente en los ultimos tres anos:

DataHub (LinkedIn, open source) es probablemente la opcion mas equilibrada para organizaciones de tamano medio. Soporta ingestion automatica de metadatos desde bases de datos, data warehouses, pipelines de Airflow y dashboards de Looker o Tableau. Su API GraphQL permite integracion programatica.

OpenMetadata es una alternativa open source mas reciente, con una interfaz mas pulida y un enfoque fuerte en data quality nativo. Buena opcion si estas empezando desde cero.

Amundsen (Lyft, open source) fue pionero pero ha perdido traccion frente a DataHub y OpenMetadata.

En el lado comercial, Alation y Collibra dominan el segmento enterprise. Son potentes, caros y requieren implementaciones de meses. Tienen sentido para organizaciones con cientos de fuentes de datos y requisitos regulatorios complejos.

Nuestra recomendacion: empieza con DataHub u OpenMetadata. Invierte en el proceso de catalogacion, no en la herramienta. La herramienta se puede cambiar; los procesos tardan anos en madurar.

Que catalogar primero

El error comun es intentar catalogar todo de golpe. Fracaso garantizado. Empieza por los activos criticos:

1. Tablas que alimentan reportes financieros. Si un numero llega al consejo, el dato subyacente debe estar catalogado.
2. Datos que alimentan modelos de ML en produccion. Un modelo se vuelve inexplicable si no puedes rastrear sus inputs.
3. Datos que cruzan fronteras regulatorias. Datos personales, datos financieros, datos de salud.
4. Fuentes de verdad compartidas. El CRM, el ERP, el sistema de pedidos. Los sistemas que multiples equipos consultan.

En la practica, las primeras 20-30 tablas criticas cubren el 80% del valor. Catalogarlas lleva semanas, no meses.

Calidad de datos: medir antes de mejorar

La calidad de datos es donde mas organizaciones fallan, y donde mas ROI se obtiene. Un estudio de Gartner estima que la mala calidad de datos cuesta a las organizaciones una media de 12.9 millones de dolares al ano. Incluso si esa cifra te parece exagerada, divide por 10 y sigue siendo un problema serio.

Las cinco dimensiones

Definimos calidad de datos con cinco dimensiones medibles:

Completitud. Porcentaje de campos no nulos donde se espera un valor. Un registro de cliente sin email puede ser aceptable; un registro de envio sin direccion de destino no lo es. La clave es definir que campos son obligatorios para cada tipo de registro y medir sistematicamente.

Unicidad. Ausencia de duplicados. Parece trivial hasta que descubres que tu CRM tiene 3 registros para el mismo cliente con variaciones en el nombre (Logistics Express S.L., Logistics Express, LOGISTICS EXPRESS SL). La deduplicacion es uno de los problemas mas infravalorados en gestion de datos.

Consistencia. El mismo concepto tiene el mismo formato y significado en todos los sistemas. Si “fecha de envio” significa “fecha en que sale del almacen” en el WMS y “fecha en que se entrega al transportista” en el TMS, tienes un problema de consistencia que ningun pipeline va a resolver automaticamente.

Precision. El dato refleja la realidad. Un stock de 150 unidades en el sistema cuando en el almacen hay 147 es un error de precision del 2%. Aceptable o no dependera de tu contexto, pero primero necesitas medirlo.

Frescura. El dato esta actualizado segun las expectativas del consumidor. Un dashboard de ventas “en tiempo real” que se actualiza cada 4 horas tiene un problema de frescura. No porque 4 horas sea malo en absoluto, sino porque la expectativa es diferente.

Automatizacion de controles

Las comprobaciones de calidad deben ser automaticas, continuas y visibles. Las herramientas principales:

Great Expectations (open source, Python) es el estandar de facto para data quality en pipelines de datos. Defines “expectations” (reglas) sobre tus datasets y se ejecutan automaticamente en cada ejecucion del pipeline. Si una expectation falla, el pipeline se detiene antes de contaminar sistemas downstream.

dbt tests son la opcion natural si ya usas dbt para transformaciones. Puedes definir tests de unicidad, no nulidad, relaciones entre tablas y expresiones SQL personalizadas directamente en tu proyecto de dbt.

Soda es una alternativa mas reciente con un lenguaje de definicion de checks mas accesible que Great Expectations, y buena integracion con Airflow y dbt.

El patron que recomendamos:

1. Define checks de calidad para las 20 tablas criticas.
2. Ejecuta los checks como parte del pipeline de datos (no como proceso separado).
3. Si un check falla, el pipeline se detiene y se notifica al data steward.
4. Publica metricas de calidad en un dashboard accesible a negocio.
5. Revisa las metricas semanalmente con data owners y stewards.

El dashboard de calidad no es para IT. Es para el CFO que quiere saber si puede confiar en las cifras del cierre mensual.

Linaje de datos: seguir el hilo

El linaje responde a la pregunta mas importante en data governance: “De donde viene este numero?”

Cuando el director financiero pregunta por que los ingresos del Q2 en el dashboard no coinciden con los del ERP, necesitas poder recorrer el camino completo: el dashboard lee de una vista materializada, que se alimenta de una tabla en el data warehouse, que se carga mediante un job de dbt, que lee de una replica de la base de datos de produccion del ERP. En algun punto de esa cadena, algo se rompio o se transformo incorrectamente.

Linaje automatico vs manual

Linaje automatico se extrae directamente de los sistemas: dbt genera linaje de sus modelos SQL, Airflow registra las dependencias entre tareas, Spark trackea los DataFrames. Las herramientas de catalogo (DataHub, OpenMetadata) pueden ingerir este linaje automaticamente y mostrarlo como un grafo visual.

Linaje manual es necesario para los tramos que las herramientas no cubren: integraciones via FTP, hojas de calculo que alguien descarga y sube modificadas, datos que se introducen manualmente. Estos “eslabones oscuros” son donde mas errores se producen y donde mas dificil es rastrear problemas.

El objetivo realista no es tener linaje automatico de todo (utopia) sino tener linaje completo de los activos criticos y reducir progresivamente los eslabones oscuros.

Impacto practico

Con linaje funcional:

• Root cause analysis de un error en un informe pasa de dias a minutos.
• Analisis de impacto antes de cambiar un esquema de base de datos: sabes exactamente que dashboards, modelos y procesos se ven afectados.
• Compliance regulatorio: puedes demostrar a un auditor que un dato personal se maneja correctamente en toda la cadena.
• Confianza del negocio: cuando alguien pregunta “de donde sale este numero?”, hay una respuesta trazable.

Modelo organizativo: el factor humano

La razon numero uno por la que los programas de data governance fracasan no es la tecnologia. Es la falta de un modelo organizativo claro. Las herramientas se compran en semanas; los cambios organizativos tardan trimestres.

Roles

Data Owner es un rol de negocio, no de IT. El data owner de “datos de cliente” es el director comercial, no el DBA. El data owner define que significa un dato, quien puede acceder a el, y cual es el nivel de calidad aceptable. Si no tiene autoridad para tomar estas decisiones, el rol no funciona.

Data Steward es el responsable operativo de la calidad. Monitoriza las metricas, investiga anomalias, coordina con los equipos tecnicos para resolver problemas. Puede ser un rol dedicado o una responsabilidad asignada dentro de un equipo existente. Lo que no puede ser es una responsabilidad difusa que no es de nadie.

Data Engineer construye y mantiene los pipelines que mueven, transforman y sirven los datos. Implementa las reglas de calidad definidas por los stewards, mantiene el catalogo tecnico y asegura que el linaje automatico funciona.

Data Consumer (analistas, data scientists, equipos de negocio) usa los datos. Su responsabilidad es reportar problemas de calidad cuando los detectan y respetar las politicas de acceso.

Modelos de organizacion

Centralizado. Un equipo de data governance define las politicas para toda la organizacion. Funciona bien en empresas pequenas y medianas (hasta 200 personas). Permite consistencia pero puede convertirse en cuello de botella.

Federado. Cada dominio de negocio (ventas, operaciones, finanzas) gestiona sus datos con politicas alineadas a un marco comun. Es el modelo natural para organizaciones grandes. Requiere un equipo central que defina el marco y arbitre conflictos, pero la ejecucion es local. Es, en esencia, la aplicacion de data mesh al gobierno del dato.

Hibrido. Lo que funciona en la practica para la mayoria. El equipo central define politicas, herramientas y metricas. Los dominios ejecutan. Los datos criticos (financieros, regulatorios) tienen governance centralizada estricta. Los datos operativos de cada equipo tienen governance federada con estandares minimos.

Como empezar si no tienes nada

Si partimos de cero, que es la situacion de la mayoria de las pymes y medianas empresas que asesoramos:

1. Nombra un responsable. No necesitas un Chief Data Officer. Necesitas una persona con autoridad y tiempo dedicado. Puede ser el CTO, el CFO o un responsable de datos a tiempo parcial, pero tiene que ser alguien concreto.
2. Identifica los 5 problemas de datos que mas duelen. Habla con negocio, no con IT. Pregunta: “Que dato no te fias?” y “Donde pierdes tiempo reconciliando numeros?”
3. Empieza por un dominio. No intentes gobernar todos los datos a la vez. Elige el dominio con mas dolor (normalmente finanzas o ventas) y construye el catalogo, las reglas de calidad y los roles para ese dominio.
4. Automatiza algo rapido. Implementa 10 checks de calidad automaticos sobre las tablas criticas del dominio elegido. Publica los resultados. El simple hecho de medir y hacer visible la calidad cambia el comportamiento de los equipos.
5. Itera trimestralmente. Anade un dominio por trimestre. En un ano tienes los 4-5 dominios principales cubiertos.

De compliance a ventaja competitiva

Hasta aqui hemos hablado de evitar problemas: datos incorrectos, incumplimiento regulatorio, reconciliaciones manuales. Pero data governance bien ejecutado no es solo prevencion. Es aceleracion.

Acceso a datos fiables, mas rapido

Sin governance, un analista pasa el 40-60% de su tiempo buscando, limpiando y validando datos antes de poder analizarlos. Con un catalogo funcional, reglas de calidad automatizadas y datos documentados, ese porcentaje baja al 10-15%. El analista produce insight en vez de producir confianza.

Modelos de ML mas fiables

Los modelos de machine learning son tan buenos como sus datos de entrenamiento. Data governance proporciona la infraestructura que permite construir modelos sobre datos cuya calidad, linaje y representatividad estan documentados y monitorizados. Un modelo que entrenas con datos gobernados se puede explicar, auditar y mejorar. Un modelo entrenado con “lo que habia en el data lake” es una caja negra construida sobre arenas movedizas.

Decisiones mas rapidas

Cuando no hay una fuente de verdad acordada, las reuniones de direccion se convierten en debates sobre que numero es el correcto. Cada departamento trae su version. Nadie cede. Se pierde una hora reconciliando antes de poder tomar una decision. Con governance, hay una unica version de la verdad, documentada, con linaje trazable. La discusion pasa de “cual es el numero” a “que hacemos con el numero”.

M&A e integraciones

Las fusiones y adquisiciones exponen brutalmente la falta de governance. Integrar los datos de dos empresas sin catalogo, sin definiciones comunes y sin reglas de calidad es un proyecto de meses que se convierte en un proyecto de anos. Las empresas con governance maduro reducen el tiempo de integracion de datos en un 50-70%.

Monetizacion de datos

En sectores como logistica, retail y fintech, los datos operativos tienen valor mas alla de la operacion interna. Datos agregados y anonimizados sobre patrones de envio, tendencias de consumo o comportamiento financiero son activos comercializables. Pero solo si estan gobernados: calidad garantizada, linaje documentado, privacidad asegurada. Sin governance, no hay producto de datos viable.

Errores que hemos visto (y cometido)

Tres anos implementando programas de governance nos han ensenado que evitar:

Comprar la herramienta antes de definir el proceso. Hemos visto implementaciones de Collibra de seis cifras que se usan como un Excel glorificado porque nadie definio los procesos de catalogacion ni los roles de stewardship. La herramienta potencia un buen proceso. No sustituye su ausencia.

Intentar gobernar todo desde el dia uno. La ambicion es el enemigo del progreso en governance. Un programa que intenta catalogar 500 tablas en el primer trimestre no cataloga ninguna. Empieza con 20 y hazlo bien.

Governance sin data ownership. Si los datos no tienen dueno de negocio, las reglas de calidad las define IT segun su criterio tecnico, no segun las necesidades del negocio. Resultado: controles que pasan pero datos que no sirven.

Metricas de vanidad. “Tenemos 500 tablas catalogadas” no significa nada si 400 tienen descripciones vacias y datos de calidad desconocidos. Mide profundidad (calidad del catalogo) no anchura (numero de activos).

Olvidar la gestion del cambio. Data governance cambia como la gente trabaja. El analista que antes se descargaba un CSV y lo manipulaba a su antojo ahora tiene que usar el dato certificado del catalogo. Si no explicas el por que y no formas en el como, habra resistencia.

El business case: como presentarlo a direccion

Si necesitas convencer a tu CEO o CFO de que inviertan en governance, estos son los argumentos que funcionan (porque estan basados en dinero, no en mejores practicas abstractas):

Reduccion de tiempo de reconciliacion. Calcula cuantas horas al mes dedican tus equipos a reconciliar numeros entre sistemas. Multiplica por coste hora. Hemos visto empresas donde este numero supera los 50.000 EUR anuales.

Reduccion de errores en reporting. Cuantas veces al ano se ha tenido que corregir un informe al consejo o a un regulador? Cada correccion tiene un coste reputacional y, en algunos casos, regulatorio.

Aceleracion de time-to-insight. Si un proyecto de analytics tarda 3 meses de los cuales 2 son preparacion de datos, governance puede reducir ese ciclo a la mitad.

Reduccion de riesgo regulatorio. Con la Digital Operational Resilience Act (DORA) en servicios financieros y las actualizaciones continuas del GDPR, la capacidad de demostrar que sabes donde estan tus datos y como se manejan no es opcional.

Habilitacion de IA. Toda iniciativa de IA seria necesita datos gobernados. Sin governance, los proyectos de IA se frenan en la fase de datos, que es exactamente donde el 80% de los proyectos de ML fracasan.

Roadmap pragmatico

Un programa de data governance realista para una empresa de 100-500 personas:

Trimestre 1: Fundamentos. Nombrar responsable. Elegir herramienta de catalogo (DataHub u OpenMetadata). Catalogar las 20 tablas criticas del dominio financiero. Implementar 10 checks de calidad automaticos siguiendo el enfoque descrito en nuestra guia de calidad de datos. Publicar el primer dashboard de calidad de datos.

Trimestre 2: Expansion. Anadir el dominio comercial/CRM. Definir data owners y stewards para ambos dominios. Implementar linaje automatico para los pipelines de dbt/Airflow. Formalizar el proceso de catalogacion para nuevos activos.

Trimestre 3: Madurez. Anadir el dominio operativo. Integrar calidad de datos en los pipelines de CI/CD. Empezar a usar el catalogo como punto de entrada para nuevos proyectos de analytics. Medir y reportar metricas de governance trimestralmente a direccion.

Trimestre 4: Escala. Cubrir todos los dominios criticos. Automatizar el linaje end-to-end. Establecer procesos de revision periodica de calidad con cada data owner. Evaluar si el modelo organizativo necesita evolucionar de centralizado a federado.

Al final del primer ano, la organizacion no tendra data governance perfecto. Tendra data governance funcional sobre sus datos criticos, con procesos probados que se pueden escalar. Y eso es infinitamente mas valioso que un proyecto de 18 meses que aspira a la perfeccion y no entrega nada.

Porque data governance no es un destino. Es un habito. Y como todo habito, empieza pequeno, se refuerza con resultados, y se sostiene con disciplina.