Silencio. El administrador de Power BI traga saliva. Sabe que hay cientos de reportes. Miles de usuarios con acceso. Decenas de modelos conectados a bases de datos con información sensible. Pero no tiene un inventario claro. No sabe quién accede a qué. No puede responder.
Esa pregunta sin respuesta puede acabar en una multa millonaria. O en un despido.
Esto no es un escenario ficticio. Es lo que pasa en la mayoría de empresas que usan Power BI a escala.
Hace unas semanas tuvimos en NamasData una clase magistral con Francisco Gutierrez Gonzalez, administrador de Power BI y Microsoft Fabric que gestiona 6.000 reportes en producción. Lo que contó durante 3 horas cambió la forma de entender la administración para muchos de los asistentes.
Voy a resumir las ideas que más impacto me causaron.
El acceso manual es una bomba de relojería
La mayoría de equipos dan acceso a los workspaces usuario a usuario. Sin proceso. Sin trazabilidad. Si alguien se va de la empresa, nadie revoca su acceso. Si alguien nuevo entra, hay que añadirlo en 5, 10, 20 sitios distintos.
La alternativa que Francisco defiende es rotunda: grupos de seguridad siempre. Un cambio en el grupo propaga el acceso a todos los workspaces. Si alguien se va, se elimina del grupo y pierde todo. Si alguien entra, un solo paso.
«Si hay usuarios fuera de un grupo de seguridad, no han seguido ningún proceso. Hay que eliminarlos.»
Pero va más allá. En Azure AD puedes crear grupos dinámicos que se llenan solos según las propiedades del usuario. Si el Job Title contiene «Manager», acceso automático. Si el departamento es «Finanzas», acceso automático. No hay que abrir un ticket. No hay que esperar a nadie.
Un consejo suyo que parece menor pero es oro: prefijar todos los grupos con «PBI_» y añadir «_auto» a los dinámicos. Cuando tienes cientos de grupos en Azure, esa convención te salva horas.
¿Dónde están tus datos confidenciales?
Esta es la pregunta más difícil que puede hacer un CDO. Y Francisco presentó una estrategia que no había visto antes.
La idea: crear dos conectores separados en la Gateway. Uno con acceso a datos sensibles (PII), otro sin. Si fuerzas que todas las actualizaciones pasen por la Gateway, sabes exactamente qué reporte usa qué conector. Si un reporte usa el conector PII, tiene datos confidenciales. Sin excepciones.
Es elegante porque no depende de herramientas caras. Solo de arquitectura bien pensada.
Las configuraciones del tenant que casi todo el mundo tiene mal
Francisco repasó las opciones del inquilino que recomienda revisar de inmediato. Algunas duelen:
- «Publicar en la web» habilitado. Cualquiera puede crear un enlace público a un reporte. Si no lo has bloqueado, hazlo ahora.
- Exportación a CSV activada. Los CSV no soportan etiquetas de confidencialidad. Un usuario descarga los datos en CSV y las protecciones desaparecen. Permite solo Excel.
- Prueba de 60 días activa. Esto incentiva que los usuarios creen workspaces personales. Esos workspaces van a la región por defecto del tenant. En empresas multirregión, eso puede significar que datos europeos acaban en servidores de otra región. Violación del RGPD.
Y una que me dejó pensando: las etiquetas de confidencialidad no protegen. Solo clasifican. Si no las combinas con Microsoft Defender para bloquear descargas y fugas, no sirven de nada.
El cálculo de capacidad que nadie te explica
¿Sabes cuánta capacidad Premium/Fabric estás consumiendo realmente? Francisco lo desmontó con una calculadora en vivo.
En una F128/P2: 128 CU por segundo × 30 segundos = 3.840 CU por ventana. Las operaciones interactivas se suavizan en 5 minutos (10 ventanas). Las de background se suavizan en 24 horas (2.880 ventanas).
Esto significa que una sola operación grande de background penaliza tu capacidad durante un día entero. Y si lanzas varias, puedes agotar la capacidad del día sin que ningún usuario haya tocado un reporte.
Contó una anécdota real: un desarrollador lanzó varios refreshes de 5 horas un fin de semana. Le llegaron 12 notificaciones seguidas de capacidad al 100%. Tuvo que entrar de urgencia a bloquear el modelo. Por suerte era fin de semana.
Semantic Link: la herramienta que lo cambió todo
Francisco lo describió como «la herramienta más importante para administradores de Power BI en los últimos 5 años». Y después de ver lo que hace, es difícil no estar de acuerdo.
Desde un notebook en Fabric puedes:
- Listar todos los modelos, tablas, columnas y medidas del tenant.
- Ejecutar las reglas BPA (Best Practice Analyzer) contra todos los modelos de golpe.
- Detectar qué modelos no usan Incremental Refresh.
- Consultar cuántas filas tiene cada tabla y de dónde viene la conexión.
Pero la demo que más me impactó fue la última. Francisco ejecutó un script que elimina automáticamente todos los accesos manuales de todos los workspaces del tenant. En vivo. Añadió usuarios a mano a dos workspaces, ejecutó el código, y los usuarios desaparecieron. Solo quedaron los grupos de seguridad.
Lo que a un administrador le llevaría horas (o días) haciendo clic en cada workspace… resuelto con un script que puedes programar para que se ejecute solo cada madrugada.
La reflexión que me quedo
Nadie nos enseñó a administrar Power BI. Nos enseñaron a hacer reportes. A escribir DAX. A modelar datos. Pero nadie nos explicó cómo gobernar un entorno con miles de usuarios, cientos de modelos y datos confidenciales repartidos por todas partes.
Un pequeño fallo de permisos puede costar más que el presupuesto anual de todo el equipo de datos.
La administración no es burocracia. Es la diferencia entre dormir tranquilo y recibir una llamada del regulador.
*Esta clase magistral está disponible en NamasData.com con la grabación completa (3 horas).
Deja un comentario