Gobierno de datos federado: cómo llevar Data Mesh a la práctica real

Respuesta rápida:

El gobierno de datos federado es la forma de gobernar los datos cuando su propiedad está repartida entre departamentos o dominios, como propone Data Mesh. En lugar de un comité central que aprueba cada decisión, un consejo federado con representantes de cada dominio y del equipo de plataforma acuerda solo los estándares mínimos comunes: identificadores compartidos, clasificación de la información, privacidad, requisitos mínimos de calidad e interoperabilidad.

Esos estándares no se quedan en un documento: la plataforma de datos los aplica automáticamente como código (Governance-as-Code) cada vez que un dominio publica un dato. Todo lo demás lo decide cada dominio, que es quien mejor conoce sus datos.

El resultado es un gobierno más rápido y más fiable a la vez: los dominios no esperan aprobaciones y las reglas se cumplen sin depender de que alguien las recuerde.

Un comité no gobierna los datos. Gobiernan las reglas que se ejecutan cada vez que alguien publica un dato.

Muchas organizaciones han adoptado el vocabulario de Data Mesh: dominios, productos de datos, plataforma de autoservicio. Pero al llegar al gobierno, mantienen el modelo de siempre: un comité central que se reúne una vez al mes, revisa peticiones y publica políticas en un documento compartido. El resultado suele ser uno de dos extremos. O el comité se convierte en un cuello de botella y los dominios esperan semanas para publicar un dato, o los dominios se saltan el proceso y cada uno aplica sus propias reglas.

Ninguno de los dos extremos es Data Mesh. El primero recentraliza lo que se quería descentralizar. El segundo fragmenta la organización en islas de datos que no se entienden entre sí.

Descentralizar la propiedad del dato sin automatizar las reglas no es Data Mesh: es fragmentación con otro nombre.

Qué es el gobierno federado en Data Mesh

Data Mesh se apoya en cuatro principios: propiedad del dato por dominios, el dato como producto, una plataforma de datos de autoservicio y gobierno computacional federado. Los tres primeros reparten la responsabilidad; el cuarto evita que ese reparto acabe en caos.

La palabra clave es computacional. Las decisiones comunes se toman de forma federada, entre todos los dominios, pero se ejecutan de forma automática en la plataforma. El gobierno deja de ser un proceso de revisión humana y pasa a ser un conjunto de reglas que el propio sistema comprueba y aplica.

Por qué los comités tradicionales no funcionan con dominios descentralizados

• Latencia: un comité que se reúne cada mes no puede seguir el ritmo de decenas de equipos publicando datos cada semana.
• Distancia del contexto: quien aprueba no conoce el dato tan bien como el dominio que lo produce, así que sus decisiones son lentas o superficiales.
• Cumplimiento por documento: una política escrita en un wiki depende de que cada persona la lea, la entienda y la recuerde; en la práctica, se cumple de forma desigual.
• Sin retroalimentación: el comité no ve cuántas veces se incumple una regla hasta que llega una auditoría o un incidente.

El problema no es la existencia de un órgano común, sino su papel. En un modelo federado, ese órgano no aprueba datos uno a uno: define pocas reglas, bien elegidas, y se asegura de que la plataforma las haga cumplir.

Qué se decide en común y qué decide cada dominio

La primera decisión de un gobierno federado es trazar la frontera entre lo global y lo local. Cuanto más pequeño sea lo global, más rápido funcionará todo lo demás.

Lo que se decide en común, porque afecta a todos:

• Identificadores compartidos: cómo se identifica un cliente, un producto o un centro para que los datos de distintos dominios se puedan cruzar.
• Clasificación de la información: qué niveles de sensibilidad existen y qué etiquetas son obligatorias, como la de dato personal.
• Privacidad y acceso: qué tratamiento reciben los datos personales y quién puede ver cada nivel de sensibilidad.
• Requisitos mínimos de un producto de datos: dueño, descripción, contrato, pruebas de calidad y nivel de servicio.
• Interoperabilidad: formatos, nomenclatura y metadatos mínimos.

Lo que decide cada dominio, porque es quien mejor lo conoce: su modelo de datos interno, sus reglas de calidad de negocio, su hoja de ruta y quién accede a sus datos dentro de los límites comunes.

Governance-as-Code: cómo convertir políticas en reglas ejecutables

Governance-as-Code significa expresar las políticas de gobierno como código versionado que la plataforma ejecuta, en lugar de como texto que las personas interpretan. En la práctica se traduce en cuatro mecanismos:

• Clasificación que activa protección: al etiquetar una columna como dato personal, la plataforma le aplica automáticamente una política de enmascaramiento. Tanto Unity Catalog como Snowflake permiten vincular máscaras y filtros de filas a etiquetas.
• Requisitos comprobados antes de publicar: un producto de datos no llega a producción si le falta el dueño, la descripción, el contrato o las pruebas. La comprobación vive en el CI del dominio, con herramientas como Open Policy Agent o con reglas propias.
• Permisos como código: los accesos se declaran en repositorios versionados, por ejemplo con Terraform, de forma que cada cambio queda revisado y auditado.
• Catálogo y linaje automáticos: la plataforma registra cada producto de datos y su linaje de extremo a extremo sin que nadie tenga que documentarlo a mano.

Un descriptor de producto de datos puede ser tan sencillo como este:

# producto de datos: ventas.pedidos_diarios
dueno: equipo-datos-ventas
descripcion: Pedidos confirmados por día y canal
clasificacion: interna
columnas:
  - nombre: email_cliente
    etiquetas: [dato_personal]   # la plataforma aplica el enmascaramiento
calidad:
  frescura_maxima_horas: 24
contrato: v2

Si falta el dueño o una columna con datos personales no está etiquetada, el despliegue falla. Nadie tiene que acordarse de revisarlo.

Cómo implantarlo paso a paso con el Método Galde

Un gobierno federado no se implanta con un gran proyecto de diseño previo, sino demostrando que funciona en un dominio real y extendiéndolo después. Es el enfoque de nuestra metodología: un gobierno co-creado con los equipos, operativo desde el principio y con resultados visibles en las primeras semanas, con la dedicación de un sponsor técnico de dos horas semanales.

Semanas 1 y 2: un dominio con impacto y un consejo mínimo

Se elige un dominio cuyos datos alimenten una decisión de negocio visible y se forma el consejo federado con su responsable, el equipo de plataforma y quien vele por la privacidad y la seguridad. Nada más.

Semanas 3 y 4: tres o cuatro reglas globales, ya como código

El consejo acuerda solo las reglas imprescindibles, normalmente la clasificación, el tratamiento de los datos personales y los requisitos mínimos de un producto de datos, y la plataforma las implementa como comprobaciones automáticas desde el primer día.

Semanas 5 y 6: el primer producto de datos gobernado, en producción

El dominio publica su primer producto de datos cumpliendo las reglas comunes de forma automática, con dueño, contrato, pruebas y registro en el catálogo.

Semanas 7 y 8: medir y extender al siguiente dominio

Se mide lo que ha cambiado, como el tiempo de publicación, las incidencias o los accesos indebidos detectados, y se incorpora el segundo dominio reutilizando las mismas reglas y la misma plataforma.

Cómo saber si tu gobierno federado funciona

• Tiempo de publicación: cuánto tarda un dominio desde que quiere publicar un producto de datos hasta que está disponible.
• Cobertura: qué porcentaje de productos de datos cumple los requisitos mínimos, medido por la plataforma y no por una encuesta.
• Dónde se detectan los problemas: si las incidencias de acceso o de calidad las detecta la plataforma o las descubre una auditoría.
• Excepciones manuales: cuántas veces hay que saltarse una regla. Si son muchas, la regla está mal diseñada.

Cómo puede ayudar Galde a llevar el gobierno federado a la práctica

Desde gobernanza de datos, co-creamos con tus dominios el consejo federado, las reglas mínimas comunes y el reparto de responsabilidades, con el mismo enfoque operativo y ágil que aplicamos a cualquier gobierno del dato.

Desde data platforms, implementamos esas reglas como código: clasificación que activa el enmascaramiento, requisitos comprobados en CI, permisos declarados en repositorios y catálogo y linaje automáticos.

Y desde la IA generativa, extendemos el mismo gobierno a los datos que usan tus asistentes y agentes, para que la gobernanza de la IA generativa no sea un proceso aparte.

Conclusión

Data Mesh promete que los equipos que mejor conocen los datos sean sus dueños. Esa promesa solo se cumple si el gobierno deja de depender de comités y documentos y pasa a depender de pocas reglas comunes, ejecutadas por la plataforma. Empezar por un dominio, automatizar desde el primer día y medir resultados en semanas es la diferencia entre un Data Mesh real y una reorganización sobre el papel.