Gobierno de datos en la era de la IA: por qué el OneLake Catalog es tu primer paso

Llevo tiempo teniendo la misma conversación con clientes que están desplegando Copilot, agentes de Fabric y modelos de IA dentro de sus procesos: todos quieren ir rápido y casi ninguno tiene claro quién es el dueño de cada lakehouse, qué modelos semánticos están certificados o si los datos sensibles llevan una etiqueta. Y cuando la IA empieza a leer, resumir y decidir sobre esos datos, esa falta de gobierno deja de ser un riesgo teórico y se convierte en un problema real.

En este post quiero contar cómo afrontamos en TSBi una primera capa de gobierno en proyectos de Fabric apoyándonos en el OneLake Catalog, qué hace exactamente y por qué creemos que es el primer paso —no el último— para gobernar datos en la era de la IA.

Por qué el gobierno deja de ser opcional cuando entra la IA

Hasta hace poco, el gobierno del dato era una conversación que «se podía aplazar» (no pero…). Si un informe estaba mal etiquetado, lo veía un responsable y lo corregía. Si existen hechos duplicados en modelos analíticos duplicados, alguien acababa preguntando «¿por qué hay dos versiones de esto?» y se zanjaba, y muchas veces se dejaba de usar por pérdida de confianza.

Con agentes de IA leyendo OneLake en tiempo real para responder preguntas, generar resúmenes o lanzar acciones (el mayor impacto), ese margen desaparece. El agente no pregunta. Coge lo que encuentra y actúa.

Lo que llevo viendo en proyectos reales es que el problema no es la IA, es lo que hay debajo: workspaces sin dueño definido, modelos semánticos sin aprobación, datos sensibles sin sensitivity label, dominios mal mapeados. La IA solo ha hecho visible lo que ya estaba mal. Esto lo hacíamos en Power BI, descubrir lo que estaba mal, pero el impacto era radicalmente inferior. Ahora, en mi flujo de Quién -> Qué -> Cómo -> Dónde, el Dónde vuelve a coger un papel principal y clave

Qué es el OneLake Catalog y por qué es nuestro punto de partida

El OneLake Catalog es la pieza dentro de Microsoft Fabric desde donde se descubren, gobiernan y aseguran todos los items de OneLake. Es el sitio donde un analista, un data owner o un admin entran a buscar qué hay y en qué estado está. Lo bueno, y la razón por la que en TSBi lo usamos como primer paso, es que está embebido en Fabric desde el panel de navegación y también lo encuentras en Teams, Excel y Copilot Studio. No hace falta montar un producto adicional para empezar.

El catálogo tiene tres pestañas y conviene entender qué hace cada una:

• Explorar. Es el explorador de items. Lista lakehouses, warehouses, semantic models, KQL databases y demás, con filtros por dominio, workspace, tipo, endorsement y sensitivity. Es la versión «qué datos tengo» del catálogo.
• Administrar. Aquí es donde vive la parte que más nos interesa cuando entramos a un cliente. Muestra el estado de gobierno del data estate: cobertura de sensitivity labels, items endorsados, DLP, frescura del dato, descripciones rellenas o vacías. Y, crítico, lanza acciones recomendadas con guía concreta para arreglar lo que está flojo.
• Seguro. Centraliza permisos y roles de seguridad de OneLake en un único punto, para que el admin no tenga que ir workspace a workspace.

Para el admin de Fabric, el Govern tab muestra el estado del tenant completo. Para un data owner, el mismo tab pero filtrado a sus items. Esto importa porque permite delegar la responsabilidad sin perder visión central: el admin ve el mapa, el data owner ve su casa.

Lo que vemos al abrir el catálogo en un cliente

En la primera visita a un cliente que arranca con Fabric, abrimos el OneLake Catalog → Govern y casi siempre encontramos lo mismo:

Un porcentaje alto de items sin sensitivity label aplicado. Items duplicados con nombres parecidos. Workspaces sin dominio asignado, lo que rompe la posibilidad de aplicar filtros y políticas por área de negocio. Pocos items endorsed (ni promoted ni certified), con lo cual los analistas tiran del primero que encuentran en lugar de usar el bueno. Modelos semánticos sin descripción, lo que hace que Copilot y los Data Agents tengan menos contexto para responder bien.

Ninguna de estas cosas es un drama por sí sola. Todas juntas son la razón por la que un proyecto de IA tarda el doble de lo previsto: porque el dato no está listo para ser consumido por algo que no pregunta.

Cómo lo abordamos en TSBi: tres pasos cortos antes de hablar de IA

No vendemos consultoría de gobierno como un programa de seis meses. Lo planteamos como tres pasos cortos que se hacen sobre el propio OneLake Catalog y que dejan al cliente en una situación donde la conversación de IA empieza a ser sensata.

• 1. Mapa de dominios. Antes de tocar nada, definimos los dominios y subdominios de Fabric alineados con la estructura real del negocio (finanzas, operaciones, comercial, etc.) y mapeamos los workspaces existentes a esos dominios. Sin este paso, el resto de capacidades del catálogo —filtrado, insights, scoping de políticas— pierden gran parte de su valor.
• 2. Endorsement y descripciones. Identificamos los items que de verdad son fuente de verdad y los marcamos como Promoted o Certified. A la vez, rellenamos las descripciones de los items clave, porque eso es lo que después permite que un Data Agent responda con contexto y que los analistas encuentren lo bueno sin tener que preguntar en Teams «¿cuál es el modelo semántico bueno de ventas?».
• 3. Sensitivity y acciones recomendadas. Atacamos las recomendaciones que muestra el propio Govern tab, empezando por sensitivity labels en items con datos personales o financieros. Aquí el catálogo trabaja a favor: cada acción recomendada viene acompañada de la insight que la justifica y los pasos para resolverla.

Tres pasos. Ninguno espectacular. Los tres dejan al data estate en una situación donde Copilot, los Data Agents y los Operations Agents pueden funcionar sin que el primer agente que pase coja un modelo semántico duplicado y sin etiquetar.

Dónde encaja Purview

Si ya tienes Microsoft Purview desplegado, no tienes que tirarlo a la basura: parte de lo que antes vivía en el Purview Hub se ha trasladado al Govern tab del OneLake Catalog. Donde Purview sigue aportando es en políticas de acceso, auditoría completa, Insider Risk Management y gobierno de los Copilots y agentes de Fabric. La regla práctica: usa el OneLake Catalog como la consola operativa del día a día del data owner; usa Purview cuando necesites políticas transversales, auditoría profunda o cobertura más allá de Fabric.

El primer paso, no el último

No vamos a decir que el OneLake Catalog «soluciona el gobierno de datos». No lo hace. Hay capas posteriores —políticas formales, comité de datos, calidad continua, lineage detallado, Purview, IRM— que siguen siendo necesarias en organizaciones medianas y grandes. Lo que sí hace el catálogo es bajar la barrera de entrada: permite empezar a gobernar el día uno, sin proyecto adicional, sin licencia separada en muchos casos, y sin esperar a que el comité de datos se constituya.

Y en la era de los agentes de IA, empezar el día uno deja de ser una buena práctica y pasa a ser la diferencia entre un proyecto que avanza y otro que se atasca en la primera demo.

Si estás pensando en desplegar Copilot o agentes de Fabric dentro de tu organización y notas que la conversación de «¿pero esto qué dato lee exactamente?» se repite, abre el OneLake Catalog → Govern, mira el estado real de tu tenant y decide a partir de ahí. Suele ser el espejo más honesto que vas a encontrar. O mejor aun, lláma a TSBi y permite acompañarte en tu viaje, será un auténtico placer.

Fuentes: -OneLake catalog overview; -Govern Fabric data; -Governance overview and guidance; -Use Microsoft Purview to govern Microsoft Fabric; – What is OneLake?