Para gobernar quién ve cada dato necesitas diseñar la seguridad por rutas de acceso, no solo por informe. Eso implica combinar cinco capas: identidad del usuario, roles de workspace, permisos por elemento, seguridad a nivel de dato (filas y columnas) y la experiencia por la que se consume (informe, Excel, SQL, API o agente de IA). Ninguna capa alcanza sola, y toda restricción debe probarse antes de publicar.
Cuando una empresa consolida sus datos en una única verdad, aparece una pregunta inevitable: si ahora todos consultan el mismo lugar, ¿cómo evito que todos vean todo? La respuesta no es un checkbox. Es un diseño de gobierno de acceso que acompaña la arquitectura desde el inicio. En este artículo vemos qué piezas necesitas y en qué orden pensarlas, con el ecosistema Microsoft (Power BI, Microsoft Fabric, Excel) como referencia.
¿Por qué no alcanza con restringir el informe?
El error más común es asumir que ocultar una página o restringir el acceso a un informe protege los datos. No es así. En Microsoft Fabric, un mismo usuario puede llegar al dato por muchos caminos: un informe de Power BI, el modelo semántico conectado desde Excel, un lakehouse, un endpoint SQL, una API o un agente de IA que consulta el modelo.
Si solo controlas el informe, dejaste abiertas todas las demás puertas. Por eso la regla central es esta: la seguridad se diseña por rutas de acceso. Cada camino por el que alguien puede consultar un dato es una ruta que debe estar gobernada y probada.
Esto se piensa en cinco dimensiones:
- Identidad: quién es la persona (o el proceso) que consulta.
- Rol: qué puede hacer dentro del espacio de trabajo.
- Elemento: a qué informes, modelos o artefactos concretos accede.
- Dato: qué tablas, filas y columnas puede ver dentro de esos elementos.
- Experiencia: por qué medio consume (informe, Excel, SQL, API, agente).
Las capas de control que necesitas conocer
El ecosistema Microsoft ofrece varias capas de seguridad que se complementan. Conviene entender qué resuelve cada una y qué no.
| Capa | Qué controla | Cuándo alcanza y cuándo no |
|---|---|---|
| Roles de workspace | Capacidades de colaboración (admin, miembro, colaborador, visor) | Necesarios, pero no suficientes por sí solos para todos los escenarios |
| Permisos por elemento | Acceso a informes, modelos y artefactos concretos | Útiles para compartir puntual, no protegen el dato en otras rutas |
| Seguridad de OneLake | Acceso granular a tablas, filas y columnas a través de motores | Clave cuando el dato se consulta desde varios motores, no solo desde el modelo |
| RLS y OLS en el modelo semántico | Filas y columnas dentro del modelo | Muy efectivas cuando todo el consumo se canaliza por el modelo semántico |
| Permiso de Build | Quién puede crear contenido sobre un modelo | Quien lo tiene también ve los metadatos del modelo, hay que gobernarlo |
La lectura correcta de esta tabla no es "elige una capa", sino "combina las capas según las rutas reales de tu empresa". Si tus usuarios solo consumen informes publicados, el RLS en el modelo semántico hace la mayor parte del trabajo. Si además hay analistas conectando Excel, consultas SQL directas o agentes de IA, necesitas que la seguridad viva también en la capa de datos, con la seguridad de OneLake.
¿Qué papel juega la identidad?
Toda ruta de acceso empieza por saber quién consulta. Y aquí hay un matiz técnico importante: la identidad con la que se valida el acceso puede ser la del usuario final (SSO) o una identidad fija configurada en la conexión. En escenarios con Direct Lake, ese detalle cambia cómo se valida el acceso al dato subyacente.
La consecuencia práctica: antes de decidir reglas de seguridad, define con qué identidad efectiva llegará cada tipo de usuario al dato. Un RLS perfecto puede quedar anulado si la conexión usa una identidad fija con permisos amplios. Este tipo de integración entre el modelo y el almacenamiento está documentado por Microsoft en la seguridad de Direct Lake.
El permiso que casi nadie gobierna: Build
Hay un permiso silencioso que merece atención: el permiso de Build sobre un modelo semántico. Quien lo tiene puede crear su propio contenido sobre el modelo, por ejemplo conectarse desde Excel o construir informes nuevos. Y quien puede construir sobre un modelo también puede ver sus metadatos: tablas, columnas, medidas.
Esto no es malo en sí mismo. De hecho, habilitar a analistas de negocio a explorar el modelo es parte del valor de centralizar los datos en un solo modelo confiable. Pero debe ser una decisión consciente: definir quiénes tienen Build, sobre qué modelos y con qué reglas de fila y columna activas. Otorgarlo por comodidad, sin RLS ni OLS detrás, es uno de los errores comunes al trabajar con la seguridad por roles: equivale a repartir llaves maestras.
¿Cómo se ve un gobierno de acceso bien montado?
Más allá de las capas técnicas, gobernar quién ve cada dato requiere prácticas de operación. Cuatro piezas sostienen el sistema en el tiempo:
- Convenciones de nombres: workspaces, lakehouses, modelos, informes y medidas con nombres consistentes. Sin esto, nadie sabe qué está protegiendo.
- Linaje: saber qué fuente alimenta cada tabla, modelo e informe. Sin linaje, cada cambio de permisos representa un riesgo, porque no ves qué más depende de ese dato.
- Controles de calidad: duplicados, nulos, rangos y reconciliación. Un dato mal gobernado en calidad termina generando copias paralelas fuera del sistema, que son el peor agujero de seguridad.
- Proceso de cambio: quién pide un acceso, quién lo valida, cómo se prueba y cómo se publica la modificación.
El punto 4 incluye la regla práctica más importante de todas: probar los permisos antes de publicar. No asumas que una restricción en el informe protege todos los caminos por los que pueden consultarse los datos. Simula el acceso con un usuario de cada perfil y verifica qué ve por cada ruta: informe, Excel, SQL.
¿Y cuando entran los agentes de IA?
Este diseño por rutas se vuelve todavía más importante con la IA. Un agente que consulta tus datos es una ruta de acceso más, con su propia identidad efectiva y sus propios permisos. Si la seguridad vive solo en el informe, el agente la ignora por completo. Si vive en el modelo semántico y en la capa de datos, el agente hereda las mismas reglas que cualquier usuario.
Aquí conviene tener presente una idea simple: la IA hereda las debilidades del sistema sobre el que opera. Un gobierno de acceso débil, amplificado por agentes que responden preguntas a cualquiera, es un problema serio. Un gobierno bien diseñado convierte a esos mismos agentes en consumidores seguros de ese repositorio central de datos.
Por dónde empezar en tu empresa
Si tuvieras que arrancar mañana, el orden razonable es este:
- Inventaria las rutas de acceso reales: quién consume qué y por dónde.
- Define la matriz de identidades y perfiles: qué debería ver cada rol del negocio.
- Decide en qué capa vive cada regla: modelo semántico para consumo canalizado, capa de datos para consumo multi motor.
- Gobierna Build y los permisos por elemento de forma explícita.
- Prueba cada perfil por cada ruta antes de publicar, y documenta el proceso de cambio.
Este trabajo es tanto de criterio como de herramienta. Primero se ordenan las métricas, los perfiles y las decisiones; después se configuran los permisos. Puede recorrerse con formación del equipo, con consultoría o con una combinación de ambas, según el punto de partida de cada empresa. Si quieres ver cómo abordamos este diseño de gobierno de acceso en la práctica, mira la demo gratuita.
Preguntas relacionadas
¿Alcanza con restringir el acceso a un informe de Power BI para proteger los datos?
No. Un usuario puede llegar al mismo dato por otras rutas: conectarse al modelo desde Excel, consultar un endpoint SQL, una API o un agente de IA. La protección debe diseñarse por rutas de acceso y probarse en cada una antes de publicar.
¿Qué diferencia hay entre RLS en el modelo semántico y la seguridad de OneLake?
El RLS y el OLS protegen filas y columnas dentro del modelo semántico, y funcionan bien cuando todo el consumo pasa por ese modelo. La seguridad de OneLake aplica reglas granulares sobre tablas, filas y columnas a través de distintos motores, y cubre rutas que no pasan por el modelo.
¿Por qué importa el permiso de Build?
Porque quien puede crear contenido sobre un modelo semántico también puede ver sus metadatos, como tablas, columnas y medidas, y conectarse desde herramientas como Excel. Es un permiso valioso para analistas, pero debe otorgarse de forma consciente y con RLS u OLS activos detrás.
¿Cómo afecta la identidad a la seguridad en Direct Lake?
La identidad efectiva con la que se ejecuta la consulta cambia cómo se valida el acceso al dato subyacente. Si la conexión usa SSO, aplican los permisos del usuario final; si usa una identidad fija con permisos amplios, puede anular en la práctica reglas definidas para usuarios individuales.
¿Los agentes de IA respetan los permisos de datos?
Un agente es una ruta de acceso más, con su identidad y permisos. Si la seguridad vive en el modelo semántico y en la capa de datos, el agente hereda esas reglas. Si vive solo en el informe, el agente no la ve, por eso el gobierno debe diseñarse por rutas y no por informe.