Microsoft Fabric y Gobierno de Datos: ¿realmente cambia las reglas del juego?
- César Oviedo

- Feb 22
- 5 min read
Updated: May 11

Pero hay una verdad que muchas organizaciones descubren tarde: cuando la plataforma se vuelve más fácil de usar, el riesgo de desorden también crece. Más usuarios pueden crear activos, más equipos pueden publicar información y más dominios pueden consumir datos sin pasar por procesos tradicionales. Eso es poderoso, pero también exige un modelo de gobierno mucho más operativo.
La pregunta no es si Fabric reemplaza el gobierno de datos. La pregunta correcta es cómo debe evolucionar el gobierno para funcionar en un entorno donde el autoservicio, OneLake, los dominios, la seguridad granular y Microsoft Purview forman parte de la misma conversación.

Figura 1. Qué cambia con Microsoft Fabric
2. Qué cambia realmente con Fabric
Fabric no es solamente una nueva herramienta. Es una plataforma unificada que reduce fricción entre creación, almacenamiento, procesamiento y consumo de datos. Esto cambia tres cosas importantes para gobierno de datos.
Primero, cambia la velocidad. Lo que antes requería varias herramientas, integraciones y equipos, ahora puede resolverse dentro de una experiencia más integrada. Eso acelera la entrega de soluciones, pero también acelera la creación de activos sin estándares si no existe control.
Segundo, cambia el punto de control. En arquitecturas tradicionales, el gobierno podía apoyarse en barreras técnicas: diferentes plataformas, accesos separados, procesos de publicación más rígidos. En Fabric, el control debe estar más integrado al diseño de workspaces, dominios, permisos, catálogo, linaje y políticas de seguridad.
Tercero, cambia el rol del negocio. Fabric facilita que los dominios participen más activamente en la creación y consumo de datos. Por eso, el gobierno ya no puede ser un ejercicio centralizado y lejano. Tiene que combinar autonomía por dominio con reglas comunes.

Figura 2. Modelo de gobierno en Fabric
3. Lo que no cambia: ownership, calidad y confianza
Aunque la tecnología cambie, los principios fundamentales siguen siendo los mismos. Un indicador sigue necesitando una definición clara. Un dato sensible sigue necesitando protección. Un producto de datos sigue necesitando un dueño. Un reporte ejecutivo sigue necesitando trazabilidad. Y una iniciativa de AI sigue dependiendo de datos confiables.
La gran trampa es pensar que una plataforma más integrada resuelve automáticamente problemas de gobierno. Fabric puede ayudar a organizar, exponer y operar mejor los datos, pero no decide por sí solo quién es responsable, qué dato es crítico, qué reglas de calidad aplican o qué nivel de riesgo acepta la organización.
Por eso, Fabric debe verse como un acelerador del modelo de gobierno, no como su sustituto. Si la organización no define ownership, dominios, estándares de publicación, controles de acceso y métricas de uso, la plataforma puede terminar amplificando el desorden existente.
4. Los controles que deberían acompañar una adopción seria de Fabric
Un modelo de gobierno efectivo en Fabric debería empezar por los dominios. Los dominios permiten organizar la responsabilidad de los datos alrededor de áreas de negocio o capacidades funcionales. Esto ayuda a que el gobierno no sea una carga genérica, sino una práctica contextualizada.
Luego está el diseño de workspaces. Un workspace no debería crearse solo por conveniencia. Debe responder a un propósito: desarrollo, pruebas, producción, dominio, producto o área de consumo. Si los workspaces se crean sin estructura, tarde o temprano aparecen duplicidades, accesos inconsistentes y dificultad para auditar.
El siguiente elemento es el concepto de data product. En Fabric, no basta con publicar tablas o modelos. La organización debería promover activos listos para consumo, con dueño, descripción, sensibilidad, reglas de calidad, linaje y contexto de uso.
También es clave la seguridad. OneLake introduce un modelo donde el acceso al dato puede gestionarse de forma más granular, separando control plane y data plane. Esto permite pensar la seguridad no solo como permisos sobre objetos, sino como una capacidad transversal para proteger datos en diferentes experiencias.
Finalmente, Purview y OneLake Catalog deben conectarse con la operación diaria. El catálogo, el linaje, la clasificación y las recomendaciones de gobierno no deben verse como documentación adicional, sino como parte del flujo normal de publicar, consumir y monitorear activos de datos.

Figura 3. Controles clave para gobernar Fabric
5. El patrón de falla más común
El error más común es adoptar Fabric como una plataforma de productividad sin definir un modelo operativo de gobierno. La organización habilita capacidades, permite la creación de workspaces, conecta fuentes, publica reportes y celebra la velocidad inicial. Pero después aparecen las preguntas difíciles: ¿cuál es el dataset oficial?, ¿quién aprueba este indicador?, ¿por qué dos áreas tienen números distintos?, ¿quién tiene acceso a datos sensibles?, ¿qué reporte depende de esta tabla?
Cuando esas preguntas no tienen respuesta clara, Fabric no falló. Falló el modelo de adopción. La plataforma hizo más visible una deuda de gobierno que ya existía.
El patrón de éxito es diferente. Empieza pequeño, con dominios prioritarios y casos de negocio reales. Define estándares mínimos. Establece roles y responsabilidades. Usa Purview y OneLake Catalog para mejorar visibilidad. Aplica seguridad desde el diseño. Y mide adopción, calidad, reutilización y reducción de riesgo.

Figura 4. Patrón de falla vs patrón de éxito
6. Fabric y Purview: una combinación necesaria
Microsoft Fabric y Microsoft Purview se complementan. Fabric permite almacenar, procesar, modelar y consumir datos con mayor integración. Purview ayuda a gobernar, proteger y administrar el patrimonio de datos, incluyendo capacidades de catálogo, linaje, clasificación, protección y cumplimiento.
Esta combinación es especialmente importante porque la trazabilidad y la confianza no se logran solo dentro de una capa técnica. Se logran conectando metadatos técnicos, definiciones de negocio, sensibilidad, linaje, propietarios y evidencia de cumplimiento.
Un buen uso de Purview en Fabric debería responder preguntas prácticas: qué activos existen, quién los posee, qué datos son sensibles, cómo fluye la información, qué reportes dependen de un activo, qué tan gobernado está el dominio y qué acciones deben priorizarse.
7. Roadmap de 90 días para gobernar Fabric
No es necesario gobernarlo todo desde el día uno. De hecho, intentar gobernarlo todo suele ser una receta para la parálisis. Una ruta más efectiva es construir un gobierno mínimo viable sobre casos reales de negocio.
Durante los primeros 15 días, la organización debería alinear la visión de gobierno, seleccionar dominios prioritarios e identificar datos críticos o sensibles. Entre los días 16 y 40, debería estandarizar workspaces, roles, naming conventions, criterios de publicación y definición de data products.
De los días 41 al 70, el foco debería estar en habilitar capacidades: catálogo, linaje, clasificación, plantillas de calidad, seguridad y guías para equipos de dominio. Finalmente, entre los días 71 y 90, se deberían medir adopción, reutilización, reducción de duplicidad, exposición de datos sensibles y cumplimiento de estándares.

Figura 5. Roadmap de 90 días para gobierno en Fabric
8. Conclusión
Microsoft Fabric sí cambia las reglas del juego, pero no porque elimine la necesidad de gobierno. Las cambia porque obliga a que el gobierno sea más cercano a la operación, más federado, más automatizado y más conectado con la creación de valor.
La organización que use Fabric solo como una plataforma técnica probablemente ganará velocidad al inicio y complejidad después. La organización que lo combine con dominios, ownership, seguridad, catálogo, linaje y métricas de adopción puede convertirlo en una base real para escalar analítica, AI y productos de datos con confianza.
El mensaje central es simple: Fabric permite moverse más rápido. El gobierno permite moverse más rápido sin perder control.



Comments