Tu empresa necesita seguridad por roles cuando distintas personas deben ver distintos subconjuntos de los mismos datos y hoy lo resuelven con copias de informes, filtros manuales o confianza. La seguridad por filas (RLS) y por objetos (OLS) en el modelo semántico, junto con la seguridad de OneLake en Microsoft Fabric, permiten que cada identidad vea solo lo que le corresponde por cualquier ruta de consumo: informes, Excel, SQL o agentes de IA.
Muchas empresas descubren que necesitan seguridad por roles de la peor manera: un vendedor ve las comisiones de todo el equipo, un gerente regional accede a los márgenes de otra región, o alguien exporta a Excel una tabla que en el informe estaba filtrada. Ninguno de esos casos es un ataque. Son consecuencias de un diseño de acceso que nunca se pensó como sistema.
En este artículo repasamos las señales concretas de que llegó el momento de diseñar la seguridad por roles, y por qué el enfoque correcto es pensar por rutas de acceso, no solo por informe.
¿Qué es la seguridad por roles en datos?
La seguridad por roles define qué puede ver y hacer cada persona según su función, no según el informe que abre. En el ecosistema Microsoft se implementa en varias capas que se complementan:
- Roles de workspace: definen capacidades de colaboración (quién administra, quién edita, quién ve). Por sí solos no alcanzan para todos los escenarios.
- Permisos por elemento: controlan el acceso a informes, modelos semánticos y otros artefactos concretos.
- Seguridad de OneLake: en Microsoft Fabric, permite aplicar seguridad granular en tablas, filas y columnas a través de los distintos motores.
- RLS y OLS en el modelo semántico: la seguridad por filas (Row Level Security) y por objetos (Object Level Security) protegen dentro del modelo, y son especialmente útiles cuando todo el consumo se canaliza por el modelo semántico.
La idea central es simple: el modelo semántico es el punto donde el negocio acuerda sus métricas. Si la seguridad vive en ese punto, todas las experiencias que lo consumen la heredan.
Señal 1: mantienes copias del mismo informe para distintas audiencias
Es la señal más común. Existe un "Informe de ventas - Norte", un "Informe de ventas - Sur" y un "Informe de ventas - Dirección". Cada copia filtra los datos de forma distinta, y cada cambio de lógica hay que repetirlo tres veces.
El costo no es solo el mantenimiento. Tarde o temprano una copia queda desactualizada, dos versiones muestran números distintos y la reunión se dedica a discutir cifras en lugar de decidir. Con RLS bien diseñada, un único informe sobre un único modelo muestra a cada persona solo sus filas. Una sola verdad, una sola lógica que mantener.
Señal 2: el filtro del informe es tu única barrera
Un informe puede tener un filtro que oculta datos sensibles. Pero un filtro de informe no es seguridad: es una preferencia visual. Si el usuario tiene acceso al modelo subyacente, puede llegar a los datos por otras rutas.
En Fabric, un usuario puede interactuar con los datos a través de informes, modelos semánticos, lakehouses, endpoints SQL, Excel, APIs o agentes de IA. Por eso el control debe pensarse por identidad, rol, elemento, dato y experiencia, no por pantalla, tal como explicamos al detallar cómo gobernar quién ve qué dato en la empresa. La regla práctica que aplicamos en cada proyecto: probar los permisos antes de publicar, sin asumir que una restricción en el informe protege todos los caminos por los que pueden consultarse los datos.
Señal 3: "Analizar en Excel" te pone nervioso
Una prueba rápida de madurez: ¿qué pasa si un usuario conecta Excel directamente al modelo semántico? Si la respuesta es "vería cosas que no debería", la seguridad está en el lugar equivocado.
Cuando la seguridad vive en el modelo (RLS y OLS), la conexión desde Excel respeta exactamente las mismas restricciones que el informe. El usuario puede explorar con libertad dentro de su perímetro. Eso convierte al autoservicio en una ventaja en lugar de un riesgo.
Señal 4: los agentes de IA y Copilot entran en escena
La llegada de Copilot y de los agentes de datos cambia la urgencia. Un agente que responde preguntas sobre el negocio consulta el modelo o el lakehouse con la identidad de quien pregunta. Si los permisos no están diseñados por identidad y dato, la IA no arregla el problema: lo amplifica, porque hace más fácil y más rápido llegar a datos que antes requerían saber dónde buscar.
Antes de habilitar experiencias de IA sobre los datos de la empresa, la seguridad por roles deja de ser opcional. Es un prerrequisito.
Señal 5: no puedes responder quién ve qué
Si un auditor, un cliente o el propio directorio pregunta "¿quién puede ver los salarios?" y la respuesta requiere revisar informe por informe, no hay gobierno: hay costumbre. Un diseño por roles permite responder con una tabla simple: rol, datos visibles, rutas habilitadas.
A esto se suman dos permisos que suelen pasar inadvertidos:
- Permiso de compilación (Build): quien puede crear contenido sobre un modelo también puede ver sus metadatos. Ese permiso debe gobernarse igual que el acceso a los datos.
- Identidad efectiva en Direct Lake: si el acceso usa inicio de sesión único o una identidad fija cambia cómo se valida cada consulta. Conviene entender qué identidad viaja en cada ruta.
¿Qué capa de seguridad conviene en cada caso?
No hay una única herramienta correcta. Cada capa protege una ruta distinta:
| Capa | Qué protege | Cuándo usarla |
|---|---|---|
| Roles de workspace | Colaboración y administración | Siempre, como base organizativa |
| Permisos por elemento | Informes y artefactos concretos | Para separar audiencias por contenido |
| RLS y OLS en el modelo | Filas y objetos dentro del modelo semántico | Cuando el consumo pasa por el modelo (informes, Excel, Copilot) |
| Seguridad de OneLake | Tablas, filas y columnas en el lake | Cuando hay acceso directo por SQL, Spark u otros motores |
La combinación depende de las rutas reales de consumo en tu empresa. Por eso el diseño empieza con un mapa: quién consume, por dónde y con qué identidad.
Cómo empezar sin rehacer todo
Un camino razonable en cuatro pasos:
- Inventaria las rutas de acceso reales: informes, conexiones de Excel, endpoints SQL, exportaciones, agentes.
- Define los roles de negocio: no por persona, sino por función (dirección, gerencia regional, ventas, finanzas).
- Implementa la seguridad en la capa más cercana al dato que cubra esas rutas: el modelo semántico si todo pasa por él, OneLake si hay acceso directo a los datos.
- Prueba cada rol por cada ruta antes de publicar: la validación con usuarios reales o identidades de prueba es parte del despliegue, no un extra, y ayuda a esquivar los errores comunes al trabajar con la seguridad por roles en datos.
Este trabajo suele destapar además problemas de nombres, linaje y calidad. Es normal: la seguridad es una pieza del gobierno de datos, y madurar una obliga a madurar el resto.
El siguiente paso
Si reconociste dos o más señales, el problema no se resuelve con un filtro más. Se resuelve con un diseño de acceso por roles sobre un modelo semántico que funcione como contrato común de las métricas.
Si quieres ver cómo se ve ese diseño aplicado a un caso real, con roles, rutas de acceso y validación antes de publicar, mira la demo gratuita y evalúa con tu equipo cuál es el mejor punto de partida.
Preguntas relacionadas
¿Qué diferencia hay entre RLS y los permisos de workspace?
Los roles de workspace definen capacidades de colaboración (administrar, editar, ver) sobre el espacio de trabajo, pero no filtran datos. RLS (seguridad por filas) actúa dentro del modelo semántico y determina qué filas ve cada identidad. Se complementan: el workspace organiza quién colabora, RLS controla qué datos ve cada rol.
¿Un filtro en el informe de Power BI protege los datos?
No. Un filtro de informe es una preferencia visual. Si el usuario tiene acceso al modelo, puede consultar los datos por otras rutas: Analizar en Excel, endpoints SQL o agentes de IA. La protección real debe vivir en el modelo semántico (RLS y OLS) o en la seguridad de OneLake.
¿La seguridad por roles aplica también a Copilot y los agentes de IA?
Sí, y es donde más importa. Un agente consulta los datos con la identidad de quien pregunta. Si RLS y los permisos están bien diseñados, el agente solo responde con datos que esa persona puede ver. Si no lo están, la IA amplifica el problema de acceso existente.
¿Cuándo conviene usar la seguridad de OneLake en lugar de RLS del modelo?
RLS y OLS protegen cuando el consumo se canaliza por el modelo semántico. La seguridad de OneLake aplica reglas granulares en tablas, filas y columnas a través de los distintos motores de Fabric, y conviene cuando hay acceso directo a los datos por SQL, Spark u otras rutas que no pasan por el modelo.
¿Cómo se valida que la seguridad por roles funciona antes de publicar?
Probando cada rol por cada ruta de consumo: abrir el informe con una identidad de prueba, conectar Excel al modelo, consultar el endpoint SQL. La regla práctica es no asumir que una restricción en el informe protege todos los caminos por los que pueden consultarse los datos.