Power BI Embedded: cómo entregar tus reportes en un portal con tu marca

Muchas empresas ya tienen buenos reportes de Power BI, pero la entrega sigue improvisada: enlaces sueltos por correo, personas sin licencia pidiendo capturas, clientes externos que no logran acceder y workspaces que nadie sabe quién puede abrir. El reporte es bueno. Lo que falla es el camino hasta quien lo necesita.

Power BI Embedded resuelve esa parte. Con él, los reportes aparecen dentro de tu propio portal o sistema, con tu marca, tu login y tus reglas de acceso, sin que cada usuario tenga que entrar a Power BI. En este artículo explicamos cómo funciona, cuándo vale la pena, cómo el licenciamiento cambia la cuenta y cómo armar un portal de reportes de la forma correcta.

¿Qué es Power BI Embedded?

Power BI Embedded es la forma de mostrar reportes y paneles de Power BI dentro de otra aplicación: un portal web, un sistema interno, un área del cliente o una app. El reporte se sigue creando en Power BI Desktop y se publica en el servicio de Microsoft. Lo que cambia es dónde aparece y quién controla el acceso.

En la práctica, tu aplicación le pide a Power BI un token de incorporación (embed token), una clave temporal que autoriza mostrar un reporte específico a ese usuario. El reporte se carga en la página con la biblioteca JavaScript de Power BI, con filtros, navegación entre páginas e interacción, igual que en el servicio original.

Los dos escenarios de incorporación

• Incorporar para tu organización: cada persona entra con su propia cuenta Microsoft y necesita acceso al contenido en Power BI. Sirve para portales internos de colaboradores.
• Incorporar para tus clientes: la aplicación se autentica en Power BI con una identidad de servicio, y quien usa el portal entra con el login del propio portal. Sirve para clientes, socios, franquiciados y equipos internos sin cuenta en Power BI.

El segundo escenario es el más usado en portales de reportes con la marca de la empresa, porque separa al usuario final del licenciamiento por persona y deja todo el control de acceso en tu aplicación.

¿Cuándo vale la pena crear un portal de reportes?

No toda empresa necesita un portal. Si los reportes los usan pocas personas, todas con licencia y acostumbradas a Power BI, el propio servicio basta. El portal empieza a tener sentido cuando la distribución se vuelve el problema.

• Necesitas mostrar reportes a clientes, proveedores, franquiciados o socios que no forman parte de tu entorno Microsoft.
• Muchas personas solo consultan los números, y pagar una licencia por usuario para todas pesa en el presupuesto.
• Cada público necesita ver un recorte distinto de los mismos datos: región, cartera, unidad o cliente.
• Los reportes están repartidos en varios workspaces y nadie encuentra lo que necesita.
• La empresa quiere que la experiencia tenga su propia marca, y no la cara de una herramienta de terceros.
• Además de paneles en Power BI, hay reportes en HTML, hojas de cálculo o enlaces externos que deberían estar en el mismo lugar.

En finanzas, por ejemplo, un portal reúne el estado de resultados, el flujo de caja y los gastos por centro de costo, y cada gestor ve solo su área. En ventas, el director ve toda la empresa, el gerente ve su región y el vendedor ve su propia cartera. En contact center, el cliente de la operación accede a los indicadores de su contrato sin entrar al entorno de la empresa.

¿Cómo funciona el licenciamiento de Power BI Embedded?

Esta es la parte que más dudas genera, y las reglas de Microsoft cambian con cierta frecuencia. Por eso conviene confirmar en la documentación oficial antes de cerrar la arquitectura. El principio general es estable: cuando el reporte se incorpora para clientes, la empresa paga por capacidad, no por usuario.

• Capacidad: una reserva de procesamiento en Azure o en Microsoft Fabric donde corren los reportes. Los SKU A, de Power BI Embedded en Azure, se pueden pausar y escalar; los SKU F, de Fabric, también sirven para incorporar.
• Quién publica: los desarrolladores que crean y publican los reportes siguen necesitando licencia Power BI Pro o equivalente.
• Quién consume: al incorporar para clientes, el usuario final del portal no necesita licencia de Power BI.
• Escenario interno: al incorporar para tu organización, cada usuario normalmente necesita licencia, salvo que el contenido esté en una capacidad lo bastante grande como para permitir lectores sin licencia paga.

El tamaño de la capacidad depende del volumen de datos, de la complejidad del modelo, de la frecuencia de actualización y de cuántas personas abren reportes al mismo tiempo. Un buen proyecto empieza pequeño, mide el uso real y solo después ajusta.

¿Cómo funciona el control de acceso en un portal?

En un portal de reportes, la pregunta no es solo quién entra, sino qué ve cada persona después de entrar. Son tres capas que trabajan juntas.

1. Login: el usuario entra al portal con Microsoft, Google o el login de la propia aplicación, y el portal sabe quién es la persona.
2. Catálogo: el portal decide qué reportes aparecen en el menú de cada perfil. El gerente comercial no ve el reporte de nómina, por ejemplo.
3. Filas: dentro del reporte, la seguridad a nivel de fila (RLS) filtra los datos. El portal le informa a Power BI la identidad del usuario al generar el token, y el modelo muestra solo las filas permitidas.

La tercera capa es la más sensible. Debe hacerse en el modelo, con una tabla de permisos, y no con filtros ocultos en la página, que se pueden quitar. Explicamos el paso a paso en el artículo sobre RLS en Power BI.

Un portal bien hecho también registra auditoría: quién accedió, qué reporte abrió, cuándo y qué exportó. Eso ayuda en la gobernanza y en las leyes de protección de datos, como la LGPD de Brasil, porque muestra que el acceso a datos personales es controlado y rastreable.

Cómo armar un portal de reportes paso a paso

1. Enumera los públicos y lo que cada uno necesita ver: perfiles, recortes de datos y qué reportes entran en el menú de cada uno.
2. Organiza los reportes: un modelo de datos confiable por tema, publicado en workspaces separados para desarrollo y producción.
3. Define la RLS en el modelo, con una tabla de permisos alimentada por el registro de usuarios del portal.
4. Crea la identidad de servicio (service principal) en Microsoft Entra ID y dale acceso a los workspaces de producción.
5. Aprovisiona la capacidad en Azure o en Fabric y asígnale los workspaces de producción.
6. Desarrolla el portal: login, menú por perfil, generación del embed token en el servidor y visualización con la biblioteca JavaScript de Power BI.
7. Aplica la identidad visual: colores, logo, dominio propio y, si tiene sentido, modo claro y oscuro y más de un idioma.
8. Prueba con usuarios reales de cada perfil, revisa lo que ve cada uno y solo entonces abre el acceso a todos.

Una regla práctica: el token de incorporación debe generarse siempre en el servidor, nunca en el navegador. Las credenciales de la identidad de servicio no pueden aparecer en el código que llega al usuario.

¿Qué errores evitar?

• Usar la opción Publicar en la web para clientes. Genera un enlace público, sin login, que cualquiera puede abrir y compartir.
• Duplicar un reporte para cada cliente en vez de usar RLS. El mantenimiento crece con cada cliente nuevo.
• Hacer la seguridad solo en el portal, ocultando menús, y dejar el modelo sin RLS.
• Dimensionar la capacidad por un pico imaginado, sin medir el uso real.
• Olvidar la actualización de los datos. El portal más bonito pierde confianza si los números están atrasados.
• Mantener el registro de usuarios manual y sin revisión. Quien dejó la empresa o el contrato tiene que perder el acceso.

¿Power BI Embedded o dashboard en HTML?

No todo reporte de un portal tiene que ser Power BI. Power BI es excelente para análisis, filtros y exploración. Los paneles en HTML y CSS tienen más sentido cuando la experiencia debe ser muy específica, liviana en el celular o integrada a las pantallas de un sistema. Comparamos los dos caminos en dashboard en HTML o Power BI.

El punto es que el portal puede recibir los dos. El usuario encuentra en el mismo menú los reportes en Power BI, los paneles en HTML e incluso enlaces a reportes externos, con el mismo login y las mismas reglas de acceso.

Cómo ayuda Wolkee

Wolkee entrega paneles en Power BI o en HTML/CSS dentro de un portal con la marca del cliente: login con Microsoft o Google, menú por perfil, RLS en el modelo, auditoría de accesos e integración con los sistemas de donde vienen los datos. Puedes explorar un portal de ejemplo, con datos ilustrativos, en la página de dashboards y Power BI.

Si la distribución de tus reportes se volvió un problema, empieza con un diagnóstico gratuito de 30 minutos. Entendemos quién necesita ver qué, revisamos el licenciamiento actual y te indicamos el camino más simple para tu escenario.

Preguntas frecuentes

¿Cuánto cuesta Power BI Embedded?

Depende de la capacidad contratada, no de la cantidad de usuarios del portal. El precio varía según el tamaño del SKU, la región de Azure y el tiempo que la capacidad queda encendida, ya que los SKU A se pueden pausar. Se suman las licencias Pro de quienes publican los reportes. Usa la calculadora de precios de Azure y confirma los valores vigentes con Microsoft.

¿El usuario del portal necesita licencia de Power BI?

No, en el escenario de incorporación para clientes. En él, la aplicación se autentica en Power BI con una identidad de servicio y el consumo lo cubre la capacidad. Quien accede entra con el login del portal. En la incorporación para la organización, donde cada persona usa su propia cuenta Microsoft, normalmente se necesita licencia por usuario, salvo en capacidades más grandes.

¿Se puede usar Power BI Embedded con Microsoft Fabric?

Sí. Las capacidades F de Microsoft Fabric también permiten incorporar reportes de Power BI en aplicaciones propias. Es útil cuando la empresa ya usa Fabric para ingeniería de datos, porque el lakehouse, los modelos semánticos y los reportes quedan en la misma plataforma. La elección entre SKU A y SKU F depende del resto de la arquitectura y del volumen de uso.

¿Power BI Embedded es seguro para datos de clientes?

Sí, siempre que la implementación siga las buenas prácticas. El token de incorporación es temporal y se genera en el servidor, la RLS en el modelo garantiza que cada cliente vea solo sus datos y el portal registra quién accedió a qué. El riesgo aparece en los atajos, como usar Publicar en la web o filtrar datos solo en pantalla.