Data governance: de obligación legal a ventaja competitiva

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

La mayoría de las organizaciones descubren que necesitan data governance de la peor forma posible: un informe al consejo con números 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 alimentó de basura bien formateada.

El reflejo habitual es tratarlo como un problema de compliance. Se contrata un DPO, se redactan políticas, se implementa un banner de cookies y se declara victoria. Pero el GDPR es solo la capa superficial. El problema real es que la organización no sabe qué datos tiene, dónde están, quién los tocó por última vez, ni si son correctos.

Hemos trabajado con empresas de logística que tenían 47 definiciones distintas de “envío completado” repartidas en 12 sistemas. Con bufetes de abogados que descubrieron datos de clientes en entornos de test tres años después de que el caso se cerrase. Con retailers cuyo stock “en tiempo real” tenía un desfase de 6 horas porque nadie sabía que un proceso ETL fallaba silenciosamente cada noche.

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

Qué es data governance (y qué no es)

Data governance es el conjunto de políticas, procesos, roles y herramientas que aseguran que los datos de una organización 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 revés. Puedes cumplir perfectamente con la normativa y tener datos inutilizables.
• No es un proyecto de IT. Si vive exclusivamente en tecnología, fracasará. Governance requiere involucrar negocio, legal, operaciones y datos.
• No es un catálogo de datos bonito. Un catálogo sin procesos de actualización es un documento muerto en seis meses.
• No es un freno a la innovación. Bien implementado, governance acelera el acceso a datos fiables y reduce el tiempo que los equipos dedican a limpiar, reconciliar y discutir números.

Los cuatro pilares

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

1. Catálogo de datos. El inventario de todos los activos de datos de la organización: tablas, ficheros, APIs, dashboards, modelos. Cada activo tiene un propietario, una descripción, un esquema, un nivel de clasificación (público, interno, confidencial, restringido) y un indicador de calidad. Sin catálogo, nadie sabe qué datos existen ni dónde buscarlos.

2. Calidad de datos. Reglas medibles que definen cuando un dato es “bueno”. Completitud (no hay nulls donde no debería haberlos), unicidad (no hay duplicados), consistencia (el mismo concepto tiene el mismo formato en todos los sistemas), precisión (el dato refleja la realidad) y frescura (el dato está 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 número incorrecto, el linaje te permite seguir el hilo: de qué tabla sale, qué transformaciones sufrió, qué proceso lo alimentó, de qué sistema fuente proviene. Sin linaje, depurar un error en un informe ejecutivo se convierte en arqueología.

4. Modelo organizativo. Quién es responsable de qué. 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.

Catálogo de datos: de inventario a sistema nervioso

Un catálogo de datos no es un Excel con una lista de tablas. Es un sistema vivo que conecta datos con contexto: quién los creó, para qué sirven, con qué frecuencia se actualizan, cómo de fiables son y quién los usa.

Herramientas

El mercado ha madurado significativamente en los últimos tres años:

DataHub (LinkedIn, open source) es probablemente la opción más equilibrada para organizaciones de tamaño medio. Soporta ingestión automática de metadatos desde bases de datos, data warehouses, pipelines de Airflow y dashboards de Looker o Tableau. Su API GraphQL permite integración programática.

OpenMetadata es una alternativa open source más reciente, con una interfaz más pulida y un enfoque fuerte en data quality nativo. Buena opción si estás empezando desde cero.

Amundsen (Lyft, open source) fue pionero pero ha perdido tracción 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 recomendación: empieza con DataHub u OpenMetadata. Invierte en el proceso de catalogación, no en la herramienta. La herramienta se puede cambiar; los procesos tardan años en madurar.

Qué catalogar primero

El error común es intentar catalogar todo de golpe. Fracaso garantizado. Empieza por los activos críticos:

1. Tablas que alimentan reportes financieros. Si un número llega al consejo, el dato subyacente debe estar catalogado.
2. Datos que alimentan modelos de ML en producción. 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 múltiples equipos consultan.

En la práctica, las primeras 20-30 tablas críticas cubren el 80% del valor. Catalogarlas lleva semanas, no meses.

Calidad de datos: medir antes de mejorar

La calidad de datos es donde más organizaciones fallan, y donde más 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 dólares al año. 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 envío sin dirección de destino no lo es. La clave es definir qué campos son obligatorios para cada tipo de registro y medir sistemáticamente.

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 deduplicación es uno de los problemas más infravalorados en gestión de datos.

Consistencia. El mismo concepto tiene el mismo formato y significado en todos los sistemas. Si “fecha de envío” significa “fecha en que sale del almacén” en el WMS y “fecha en que se entrega al transportista” en el TMS, tienes un problema de consistencia que ningún pipeline va a resolver automáticamente.

Precisión. El dato refleja la realidad. Un stock de 150 unidades en el sistema cuando en el almacén hay 147 es un error de precisión del 2%. Aceptable o no dependerá de tu contexto, pero primero necesitas medirlo.

Frescura. El dato está actualizado según 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.

Automatización de controles

Las comprobaciones de calidad deben ser automáticas, continuas y visibles. Las herramientas principales:

Great Expectations (open source, Python) es el estándar de facto para data quality en pipelines de datos. Defines “expectations” (reglas) sobre tus datasets y se ejecutan automáticamente en cada ejecución del pipeline. Si una expectation falla, el pipeline se detiene antes de contaminar sistemas downstream.

dbt tests son la opción 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 más reciente con un lenguaje de definición de checks más accesible que Great Expectations, y buena integración con Airflow y dbt.

El patrón que recomendamos:

1. Define checks de calidad para las 20 tablas críticas.
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 métricas de calidad en un dashboard accesible a negocio.
5. Revisa las métricas 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 más importante en data governance: “De dónde viene este número?”

Cuando el director financiero pregunta por qué 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 réplica de la base de datos de producción del ERP. En algún punto de esa cadena, algo se rompió o se transformó incorrectamente.

Linaje automático vs manual

Linaje automático 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 catálogo (DataHub, OpenMetadata) pueden ingerir este linaje automáticamente y mostrarlo como un grafo visual.

Linaje manual es necesario para los tramos que las herramientas no cubren: integraciones vía FTP, hojas de cálculo que alguien descarga y sube modificadas, datos que se introducen manualmente. Estos “eslabones oscuros” son donde más errores se producen y donde más difícil es rastrear problemas.

El objetivo realista no es tener linaje automático de todo (utopía) sino tener linaje completo de los activos críticos y reducir progresivamente los eslabones oscuros.

Impacto práctico

Con linaje funcional:

• Root cause analysis de un error en un informe pasa de días a minutos.
• Análisis de impacto antes de cambiar un esquema de base de datos: sabes exactamente qué 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 dónde sale este número?”, hay una respuesta trazable.

Modelo organizativo: el factor humano

La razón número uno por la que los programas de data governance fracasan no es la tecnología. 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 qué significa un dato, quién puede acceder a él, y cuál 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 métricas, investiga anomalías, coordina con los equipos técnicos 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 catálogo técnico y asegura que el linaje automático 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 políticas de acceso.

Modelos de organización

Centralizado. Un equipo de data governance define las políticas para toda la organización. Funciona bien en empresas pequeñas 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 políticas alineadas a un marco común. Es el modelo natural para organizaciones grandes. Requiere un equipo central que defina el marco y arbitre conflictos, pero la ejecución es local. Es, en esencia, la aplicación de data mesh al gobierno del dato.

Híbrido. Lo que funciona en la práctica para la mayoría. El equipo central define políticas, herramientas y métricas. Los dominios ejecutan. Los datos críticos (financieros, regulatorios) tienen governance centralizada estricta. Los datos operativos de cada equipo tienen governance federada con estándares mínimos.

Cómo empezar si no tienes nada

Si partimos de cero, que es la situación de la mayoría 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 más duelen. Habla con negocio, no con IT. Pregunta: “Qué dato no te fías?” y “Dónde pierdes tiempo reconciliando números?”
3. Empieza por un dominio. No intentes gobernar todos los datos a la vez. Elige el dominio con más dolor (normalmente finanzas o ventas) y construye el catálogo, las reglas de calidad y los roles para ese dominio.
4. Automatiza algo rápido. Implementa 10 checks de calidad automáticos sobre las tablas críticas 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. Añade un dominio por trimestre. En un año tienes los 4-5 dominios principales cubiertos.

De compliance a ventaja competitiva

Hasta aquí hemos hablado de evitar problemas: datos incorrectos, incumplimiento regulatorio, reconciliaciones manuales. Pero data governance bien ejecutado no es solo prevención. Es aceleración.

Acceso a datos fiables, más rápido

Sin governance, un analista pasa el 40-60% de su tiempo buscando, limpiando y validando datos antes de poder analizarlos. Con un catálogo 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 más 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 están documentados y monitorizados. Un modelo que entrenas con datos gobernados se puede explicar, auditar y mejorar. Un modelo entrenado con “lo que había en el data lake” es una caja negra construida sobre arenas movedizas.

Decisiones más rápidas

Cuando no hay una fuente de verdad acordada, las reuniones de dirección se convierten en debates sobre qué número es el correcto. Cada departamento trae su versión. Nadie cede. Se pierde una hora reconciliando antes de poder tomar una decisión. Con governance, hay una única versión de la verdad, documentada, con linaje trazable. La discusión pasa de “cuál es el número” a “qué hacemos con el número”.

M&A e integraciones

Las fusiones y adquisiciones exponen brutalmente la falta de governance. Integrar los datos de dos empresas sin catálogo, sin definiciones comunes y sin reglas de calidad es un proyecto de meses que se convierte en un proyecto de años. Las empresas con governance maduro reducen el tiempo de integración de datos en un 50-70%.

Monetización de datos

En sectores como logística, retail y fintech, los datos operativos tienen valor más allá de la operación interna. Datos agregados y anonimizados sobre patrones de envío, tendencias de consumo o comportamiento financiero son activos comercializables. Pero solo si están gobernados: calidad garantizada, linaje documentado, privacidad asegurada. Sin governance, no hay producto de datos viable.

Errores que hemos visto (y cometido)

Tres años implementando programas de governance nos han ensenado qué 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 definió los procesos de catalogación ni los roles de stewardship. La herramienta potencia un buen proceso. No sustituye su ausencia.

Intentar gobernar todo desde el día uno. La ambición 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 dueño de negocio, las reglas de calidad las define IT según su criterio técnico, no según las necesidades del negocio. Resultado: controles que pasan pero datos que no sirven.

Métricas de vanidad. “Tenemos 500 tablas catalogadas” no significa nada si 400 tienen descripciones vacías y datos de calidad desconocidos. Mide profundidad (calidad del catálogo) no anchura (número de activos).

Olvidar la gestión del cambio. Data governance cambia cómo 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 catálogo. Si no explicas el por qué y no formas en el cómo, habrá resistencia.

El business case: cómo presentarlo a dirección

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

Reducción de tiempo de reconciliación. Calcula cuántas horas al mes dedican tus equipos a reconciliar números entre sistemas. Multiplica por coste hora. Hemos visto empresas donde este número supera los 50.000 EUR anuales.

Reducción de errores en reporting. Cuántas veces al año se ha tenido que corregir un informe al consejo o a un regulador? Cada corrección tiene un coste reputacional y, en algunos casos, regulatorio.

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

Reducción 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 dónde están tus datos y cómo se manejan no es opcional.

Habilitación 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 pragmático

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

Trimestre 1: Fundamentos. Nombrar responsable. Elegir herramienta de catálogo (DataHub u OpenMetadata). Catalogar las 20 tablas críticas del dominio financiero. Implementar 10 checks de calidad automáticos siguiendo el enfoque descrito en nuestra guía de calidad de datos. Publicar el primer dashboard de calidad de datos.

Trimestre 2: Expansión. Añadir el dominio comercial/CRM. Definir data owners y stewards para ambos dominios. Implementar linaje automático para los pipelines de dbt/Airflow. Formalizar el proceso de catalogación para nuevos activos.

Trimestre 3: Madurez. Añadir el dominio operativo. Integrar calidad de datos en los pipelines de CI/CD. Empezar a usar el catálogo como punto de entrada para nuevos proyectos de analytics. Medir y reportar métricas de governance trimestralmente a dirección.

Trimestre 4: Escala. Cubrir todos los dominios críticos. Automatizar el linaje end-to-end. Establecer procesos de revisión periódica de calidad con cada data owner. Evaluar si el modelo organizativo necesita evolucionar de centralizado a federado.

Al final del primer año, la organización no tendrá data governance perfecto. Tendrá data governance funcional sobre sus datos críticos, con procesos probados que se pueden escalar. Y eso es infinitamente más valioso que un proyecto de 18 meses que aspira a la perfección y no entrega nada.

Porque data governance no es un destino. Es un hábito. Y como todo hábito, empieza pequeño, se refuerza con resultados, y se sostiene con disciplina.