El gobierno de datos en la era de la IA: cuando los datos se mueven solos, el control no puede ser opcional. Fabric y Purview para dar respuesta al cómo.

Llevo más de 10 años desplegando procesos y tecnología como soporte al análisis de datos de la dirección, entender el negocio para tomar decisiones informadas y no basadas en intuiciones. Cuando hablaba con un cliente de gobierno de datos, el escenario era estático: las personas consultaban informes, los analistas movían tablas, y el gobierno consistía en saber quién veía qué y garantizar una única fuente de verdad.

Pero el desbocado avance de la IA y su “adopción” por las personas y organizaciones (tanto monta monta tanto) hace que este gobierno cobre aun más importantica. Hoy ya no acceden solo las personas. También lo hacen copilots, asistentes y agentes de IA capaces de leer datos, generar respuestas, llamar a APIs y ejecutar operaciones autenticadas sobre las plataformas, los datos se mueven solos. Los datos no se mueven solos en sentido literal, pero cada vez más decisiones sobre qué consultar, combinar, resumir o devolver se delegan en agentes y automatizaciones.

Por este motivo, el control no puede seguir siendo un proyecto paralelo que arrancamos cuando hay tiempo. No basta con tener informes bien publicados. Hay que saber qué datos consume cada agente, con qué identidad accede, qué información devuelve y qué ocurre cuando toca datos sensibles. No basta con tener informes bien publicados. Hay que saber qué datos consume cada agente, con qué identidad accede, qué información devuelve y qué ocurre cuando toca datos sensibles:

Lo que ha publicado Microsoft como respuesta

Escribo este post ya que, en las últimas semanas, Microsoft ha publicado dos piezas en preview que me parecen el ejemplo más claro de hacia dónde va esto: DLP extendido a los datos estructurados de OneLake y DSPM para IA en Fabric. No es casualidad que las dos salgan ahora, justo cuando el MCP Remoto y los Fabric Data Agents pasan a ser realidad.

Vamos a profundizar un poco en gobierno de datos, miramos por separado cada nueva funcionalidad y luego vemos cómo encajan.

Por qué la IA convierte el gobierno en algo urgente

Durante años, el gobierno de datos se vendió como un asunto de cumplimiento: auditorías, RGPD, casillas que marcar. Funcionaba como un seguro, y como todo seguro, daba pereza pagarlo hasta que pasaba algo.

La IA ha cambiado esa ecuación. Un cuadro de mando con datos regulares todavía deja margen a que una persona mire el número y diga «esto no puede ser». Un modelo que se entrena o se alimenta con datos malos no tiene ese filtro: amplifica el error y lo sirve con una seguridad que asusta. Si el dato de origen está sesgado, incompleto o mal definido, la IA no lo corrige; lo escala.

La consecuencia práctica es sencilla: la fiabilidad de cualquier iniciativa de IA está limitada por la fiabilidad del dato que tiene debajo. Por eso el gobierno de datos deja de ser un tema del equipo de cumplimiento y pasa a ser el habilitador número uno de la analítica avanzada y de la toma de decisiones automatizada.

Qué es realmente el gobierno de datos

El gobierno de datos (data governance) es el conjunto de procesos, roles y herramientas que aseguran que los datos de una organización sean confiables, seguros y disponibles. Dicho de otra forma: que cuando alguien usa un dato, sepa qué significa, de dónde viene, si puede fiarse de él y si tiene permiso para verlo:

• Confiables: integridad, consolidación, versionado, calidad son algunas de las etiquetas que tenemos que tener en cuenta. ¿Qué pasa cuando nuestro ChatBot de soporte a cliente está utilizando versiones antiguas del manual técnico de producto?
• Seguros: los puntos de fuga ahora son mayores. Los riesgos crecen y si los riegos crecen el gobierno debe ser más robusto. ¿Qué pasa si para realizar un PowerPoint de presentación a la dirección paseamos el plan estratégico de la compañía por todo el escaparate de servicios IA que nos ofrece el mercado para hacer una presentación chula?
• Disponibles. Listos y preparados para quien los necesita y en el momento que lo necesita. ¿De qué me sirve “predecir” que va a llover ayer?

No es un proyecto que se termina; es una disciplina que se mantiene. No es una competencia de IT, es responsabilidad de toda la organización. Y se apoya en unos pocos pilares que conviene tener claros (a mi me gusta destacar los siguientes, sabiendo que hay algunos procesos más):

Los cinco pilares del gobierno de datos

• • • Propiedad (ownership): que cada dominio de datos tenga un responsable claro, no una nube difusa de «esto es de todos y de nadie».
    • Catálogo: un inventario de los activos de datos para que la gente encuentre lo que necesita sin preguntar por Teams a cinco personas.
    • Linaje (lineage): el mapa del recorrido del dato desde su origen hasta el informe final, para responder a la pregunta de siempre: «¿por qué este número no cuadra?».
    • Calidad: medir si el dato está en condiciones de usarse, con dimensiones como exactitud, completitud, conformidad, consistencia, actualidad y unicidad.
    • Seguridad y privacidad: clasificar la información sensible y controlar quién accede a qué.

Esto permite definir el qué y el para qué. IT gestiona, realiza el cómo y aquí es donde entran las herramientas en general y el ecosistema Microsoft en concreto.

Qué ha publicado Microsoft (y qué cubre cada cosa)

Para no marear, lo divido en dos novedades concretas, ambas en versión preliminar y descritas tal cual en la documentación de Fabric:

1. DLP que restringe el acceso a los datos estructurados de OneLake

La capacidad de Data Loss Prevention (DLP) en Fabric se amplía para cubrir todos los datos estructurados de OneLake: bases de datos SQL, bases de datos KQL y warehouses. Es decir, las reglas DLP que hasta ahora se aplicaban a unos cuantos elementos pueden, en preview, restringir el acceso a información sensible de estructuras que son el corazón analítico de la plataforma.

Esto importa porque hasta ahora muchos equipos tenían un agujero conceptual: aplicaban DLP a Power BI y a SharePoint, pero un usuario con acceso a la base SQL o al warehouse podía consumir cualquier dato sensible que hubiese aterrizado ahí. La extensión a los datos estructurados de OneLake cierra esa puerta.

2. DSPM para IA en Fabric

Data Security Posture Management (DSPM) para IA en Fabric, también en preview, hace algo distinto y nuevo: supervisa las interacciones con los agentes de datos (artefacto que nos permite conversar con los datos en vez de analizarlos, ver el post Fabric data agent) para detectar información confidencial en las prompts y en las respuestas, investiga comportamiento de IA arriesgado y aplica gobernanza apoyándose en Purview Audit y eDiscovery. Traducido, cuando la auditoría está habilitada y la funcionalidad está correctamente configurada, las interacciones pueden quedar registradas y ser analizadas desde Microsoft Purview.

A estas dos, le sumo una tercera pieza que ya viene rodando: la gobernanza centralizada de datos en el catálogo de OneLake, en preview, donde los propietarios ven información agregada de sus elementos, reciben recomendaciones de mejora y acceden a las herramientas relevantes desde un único sitio. No es nueva, pero encaja con el resto.

Por qué esto cambia el verbo del gobierno de datos

El gobierno tradicional era un verbo en presente continuo: “estamos clasificando”, “estamos definiendo políticas”, “estamos catalogando”. Lentos por dentro, mirando hacia adentro.

Con DLP extendido y DSPM para IA, el verbo cambia a operar: el gobierno deja de ser un proyecto y pasa a ser una capacidad que se ejecuta en tiempo de uso. Cuando un agente intenta acceder a un dato estructurado de OneLake, DLP responde. Cuando un usuario hace una pregunta a un Data Agent, DSPM observa. No hay un “te aviso la semana que viene”. Hay una respuesta ahora mismo.

Esto cambia tres cosas en el día a día de quien gestiona la plataforma:

• • 1. El gobierno se vuelve preventivo, no forense. Antes mirábamos auditorías para entender qué había pasado. Ahora podemos impedir que pase, o al menos detectarlo en el mismo momento.
    2. El alcance se ensancha hasta donde los datos viven. DLP en Power BI ya no es suficiente: el agujero estaba en el almacén, en la base KQL, en el warehouse. Cerrarlo en OneLake cierra el flanco que más crecía.
    3. Las conversaciones con IA entran en el perímetro. Hasta ahora “lo que el usuario pregunta al chatbot” era una zona gris. Con DSPM para IA, esas interacciones son objeto de gobierno, igual que un correo o un documento.

Lo que vemos en proyecto: tres patrones que se repiten

Cuando entramos a ayudar a un cliente a poner orden, los problemas reales casi siempre son los mismos tres. Los enumero porque, si te suenan, ya sabes por dónde tirar:

• • • Permisos heredados de la era pre-Fabric. Workspaces creados sobre la marcha hace dos años, gente que ya no está, grupos de Entra ID que nadie revisa. Antes de habilitar DLP nuevo o DSPM, hay que limpiar esto. No por estética: por seguridad real.
    • Datos sensibles en tablas “intermedias” sin etiquetar. Los datos llegan etiquetados al lakehouse, los analistas hacen una vista materializada, una tabla en el warehouse, y ahí la etiqueta se pierde. DLP solo protege lo que está clasificado. Si la clasificación no se propaga, no hay protección.
    • Agentes con permisos demasiado amplios. Es el patrón que más nos vamos a encontrar en los próximos meses. Un Data Agent o un agente vía MCP Remoto se monta con un service principal al que se le dan permisos de lectura amplios “para que funcione”. Eso, sin DSPM y sin auditoría afilada, es una vía de fuga. Hay que pensar en la identidad del agente como una identidad de usuario sensible. El punto crítico no es solo que el agente responda preguntas, es que el agente se convierte en una nueva superficie de acceso a los datos.

Qué conviene hacer esta semana si gestionas la plataforma Fabric

No hace falta un plan grande para empezar a moverse. Tres pasos concretos que cualquier equipo de plataforma puede dar antes del viernes:

• • 1. Inventaría dónde aterrizan los datos sensibles dentro de Fabric. No solo en Power BI: pregúntate qué bases SQL, qué bases KQL y qué warehouses contienen información personal, financiera o regulada. Si no lo sabes, ese es el primer trabajo.
    2. Decide quién accede hoy a esos contenedores y, sobre todo, qué identidades no humanas (service principals, agentes, conectores) tienen permisos. Documenta y haz limpieza.
    3. Prepara el terreno para DLP extendido y DSPM para IA. Aunque ambas están en preview y no las vas a meter en producción crítica, sí puedes empezar a probarlas en un workspace de validación. Lo importante es entender cómo encajan en tu modelo de gobierno antes de que la presión venga del negocio.

Dónde estamos: el gobierno de datos deja de ser opcional

Lo que estamos viendo no es una novedad más del mes, es un cambio de fondo: con la expansión agentic de Fabric (MCP Remoto, Data Agents, integración con Copilot Studio y Microsoft Foundry), el gobierno deja de ser “lo que hace el equipo de cumplimiento en una pestaña aparte”. Pasa a ser una capacidad operativa crítica, al mismo nivel que la disponibilidad o el rendimiento de la plataforma.

Microsoft está poniendo las piezas para que esa capacidad sea ejecutable: DLP donde antes no llegaba, DSPM donde antes ni existía, catálogo centralizado para que los propietarios vean su parcela. Lo que no nos van a dar es el modelo de gobierno propio: ese lo tenemos que pensar nosotros, con la cabeza puesta en que dentro de muy poco no vamos a estar gobernando solo a los usuarios. Vamos a estar gobernando también a los agentes.

Y, sinceramente, ese es el cambio. Si tu modelo de gobierno actual no contempla qué pueden hacer los agentes y con qué identidad, es el momento de revisarlo. Antes de que el primer agente entre en producción.

Fuentes consultadas:

_

• • Microsoft Learn — Novedades de Microsoft Fabric: https://learn.microsoft.com/es-es/fabric/fundamentals/whats-new
  • Microsoft Purview — DSPM for AI in Fabric: https://learn.microsoft.com/es-es/purview/ai-copilot-fabric
  • Microsoft Fabric Blog — New data protection capabilities in Microsoft Fabric: https://blog.fabric.microsoft.com/blog/new-data-protection-capabilities-in-microsoft-fabric-native-security-for-the-modern-data-estate

_