Embedding Analytics en Power BI: Reduzca Costos y Personalice la Experiencia del Cliente

¡Hola a todos!

Si trabajas con Power BI y alguna vez has necesitado compartir informes con decenas o cientos de usuarios, especialmente externos a tu organización, ya debes haber sentido el peso de las licencias individuales. Power BI Pro, Premium por Usuario (PPU)... la cuenta crece rápido. Pero existe una alternativa oficial de Microsoft, totalmente legal y mucho más económica: el Embedding Analytics.

En este artículo, cubriré todo el tema desde cero: qué es Embedding Analytics, cómo funciona, cuáles son los modelos de licenciamiento disponibles, las capacidades dedicadas involucradas, los conceptos técnicos de smoothing, bursting y throttling de Fabric, los riesgos de soluciones que se desvían del modelo oficial, las preguntas frecuentes y cómo puedes implementar todo esto de forma segura y eficiente en tu empresa.

El Desafío de Distribuir Informes de Power BI

En el modelo estándar de Power BI, cualquier persona que quiera visualizar un informe publicado en el servicio (app.powerbi.com) necesita una cuenta de Microsoft y, en la gran mayoría de los escenarios, una licencia Power BI Pro o Premium por Usuario (PPU). Esto crea una barrera real en tres frentes:

• Costo elevado: Cada usuario que necesita acceder a informes tiene un costo mensual de licencia. Para equipos internos pequeños, está bien. Pero cuando necesitas compartir con clientes, socios, revendedores o franquiciados, el costo escala linealmente y rápido.
• Experiencia genérica: El portal de Power BI fue creado para el equipo de BI de la empresa, no para el cliente final. La identidad visual es de Microsoft, la navegación es técnica y muchas veces el usuario no tiene el contexto necesario para manejarse solo.
• Limitaciones de acceso externo: Los usuarios externos a tu organización deben ser agregados como invitados en Azure AD, lo que conlleva complejidad de gestión y, a menudo, resistencia por parte del departamento de TI.

Es precisamente para resolver estos problemas que Microsoft creó la función de Análisis Integrado de Power BI, más conocido como Embedding Analytics.

¿Qué es Embedding Analytics en Power BI?

El Embedding Analytics (o Análisis Integrado) es una función oficial de Microsoft que permite incorporar informes, paneles y otros artefactos de Power BI directamente en aplicaciones web y portales personalizados, de forma segura, controlada y sin exigir que los usuarios finales tengan licencias individuales de Power BI.

En la práctica, Embedding Analytics te permite construir (o contratar) un portal web propio, donde los informes de Power BI aparecen incrustados, como si formaran parte de tu aplicación. El usuario final accede a tu portal, inicia sesión con las credenciales que definas (correo electrónico corporativo, Gmail o cualquier otro método) y visualiza los informes, sin siquiera saber que Power BI está detrás de todo.

Embedded, "Publicar en la Web" e "Insertar Informe": ¿cuáles son las diferencias?

Aunque las tres opciones permiten incrustar informes en sitios web, SharePoint, correo electrónico, Teams y otros canales, son muy diferentes en seguridad, costo y control. Vea la comparación:

1. Publicar en la Web

Es la forma más sencilla, pero también la más peligrosa. El informe es totalmente público, sin ningún control de acceso. Cualquier persona que tenga el enlace puede ver los datos, incluido Google, que indexa estos informes en búsquedas simples, incluso si el enlace nunca se ha publicado en ningún lugar. No hay autenticación, no hay RLS, no hay OLS, no hay auditoría de quién accedió. Úsalo solo para datos realmente públicos, como resultados de elecciones o índices económicos abiertos.

Incluso si intentas bloquear el acceso con una contraseña en el portal que aloja el iframe, este tipo de protección se sortea fácilmente en pocos segundos usando las Herramientas de Desarrollo del navegador. La persona tendrá acceso irrestricto a los datos publicados en el informe.

2. Insertar Informe (mediante código HTML/iFrame)

Esta opción permite incorporar el informe en sitios web, SharePoint, Teams, etc., manteniendo todos los controles de seguridad de Power BI: permisos, RLS, OLS y auditorías de acceso. Pero el problema es claro: todos los usuarios que vayan a acceder al informe insertado de esta forma aún necesitan una licencia Pro o PPU activa. Además, no puedes controlar los elementos del informe mediante lenguaje de programación, como crear o editar visuales dinámicamente, cambiar temas, crear o eliminar páginas, etc.

3. Embedding Analytics (Análisis Integrado mediante capacidad dedicada)

Es la función más completa. Permite visualizar informes de forma segura, con RLS, OLS, control de permisos, bloqueos por IP, auditoría de accesos y control programático total (filtros mediante código, cambio de tema, navegación de páginas, creación y edición de visuales), sin que los usuarios necesiten una licencia de Power BI. El licenciamiento se realiza mediante capacidad dedicada (Fabric o Power BI Embedded), no por usuario. Es la única opción que ofrece todos estos beneficios al mismo tiempo.

Los Dos Modelos de Inserción de Informes

Dentro de Embedding Analytics, Microsoft define dos modelos de inserción. Elegir el incorrecto puede significar tanto una mala experiencia como una violación del contrato de licenciamiento:

User Owns Data: Insertar para la Organización

Este es el modelo más simple y directo. Cada usuario final se autentica en Power BI con su propia cuenta corporativa, a través de Entra ID (Azure AD).

La aplicación actúa como un puente, pero la experiencia es personalizada por usuario y cada persona necesita una licencia Power BI Pro (o acceso a un espacio de trabajo en capacidad Premium).

Escenarios correctos para este modelo:

• Aplicaciones internas para colaboradores de una empresa.
• Soluciones corporativas que siguen políticas internas de seguridad e identidad.
• Usuarios internos autenticados en Entra ID con licenciamiento Pro o P SKU.

Este modelo no es adecuado para clientes externos o para escenarios donde el objetivo es eliminar el costo de licencias por usuario. No intentes usar User Owns Data con usuarios externos o compartir credenciales y tokens manualmente.

App Owns Data: Insertar para tus Clientes

Este es el modelo ideal para ISVs (Independent Software Vendors) y soluciones SaaS, y es el que posibilita la gran reducción de costos.

Aquí, quien se autentica en Power BI no es el usuario final, sino la propia aplicación, utilizando un Service Principal (una identidad técnica en Azure AD). La aplicación genera un token de incrustación con un alcance mínimo para cada sesión y entrega el informe renderizado al usuario, quien nunca necesita tener una cuenta de Microsoft o una licencia Pro.

Las características de este modelo:

• Los usuarios finales no necesitan una licencia de Power BI Pro o PPU.
• Los usuarios finales no necesitan una cuenta de Microsoft (pueden usar Gmail, su propio correo electrónico corporativo, inicio de sesión con contraseña, SSO corporativo, etc.).
• El control de permisos, RLS y visibilidad se realiza dentro de la aplicación, a través del token de incrustación.
• Requiere obligatoriamente una capacidad dedicada (Fabric o Power BI Embedded) en producción.
• El contenido de los informes debe estar en un espacio de trabajo no personal, asociado a la capacidad.
• Los usuarios pueden incluso crear y editar informes desde el portal sin necesidad de una licencia Pro, según lo documentado por Microsoft.

¿Puedo usar una licencia Pro o PPU para incrustar en producción?

Esta es una de las dudas más frecuentes, y la respuesta debe ser directa: no. Técnicamente es posible generar tokens de incrustación con una cuenta Pro o PPU (llamada "Master Account"), pero la propia Microsoft es explícita en la documentación oficial:

"Los tokens incrustados con licencia Pro o Premium por usuario (PPU) están destinados a pruebas de desarrollo, por lo que una cuenta maestra o Service Principal de Power BI solo puede generar un número limitado de tokens. Adquiera una capacidad para incrustar en un entorno de producción. No hay límite en la cantidad de tokens incrustados que puede generar al adquirir una capacidad."

Fuente: Documentación oficial de Microsoft: "Mover la aplicación incrustada a producción"

En otras palabras, usar Pro/PPU para incrustar solo está permitido en entornos de desarrollo y pruebas. En producción, con usuarios reales accediendo, Microsoft exige una capacidad dedicada.

Usar una licencia Pro para esto en producción:

• Viola los términos de uso de Power BI y los Términos de Producto de Microsoft.
• Puede resultar en multas, sanciones y auditorías de cumplimiento por parte de Microsoft.
• Tiene un límite de tokens que, al alcanzarse, hace que los informes dejen de cargarse.
• Crea serios riesgos de seguridad, ya que el uso de Pro/PPU + incrustación externa puede ser explotado como un vector de exfiltración de datos. Si un token se filtra, cualquier persona puede acceder a todos los informes de todos los clientes que están en ese inquilino.
• El uso de una Cuenta Maestra exige almacenar el inicio de sesión y la contraseña, lo que crea un riesgo de fuga de credenciales.

Capacidades Dedicadas: ¿Qué son y cuáles son las opciones?

Las capacidades dedicadas son recursos computacionales exclusivos, aprovisionados en Azure, que licencian el uso de Embedding Analytics y permiten generar tokens de incrustación de forma ilimitada.

Sin una capacidad contratada, usando solo una cuenta Pro o PPU, tienes una cantidad limitada de tokens. Después de un tiempo, se alcanza ese límite y Power BI ya no permite insertar informes.

Por estas razones, tener una capacidad es obligatorio para cualquier uso en producción.

Existen tres tipos de capacidades:

Microsoft Fabric (F SKUs): la opción más moderna

Las capacidades de Fabric son la generación más nueva y completa. Además de admitir Embedding Analytics, habilitan todas las demás cargas de trabajo de Microsoft Fabric: Ingeniería de Datos, Ciencia de Datos, Almacén de Datos, Análisis en Tiempo Real y mucho más. Son la opción recomendada para nuevos proyectos.

Ventajas de los F SKUs:

• Se cobran por hora de ejecución (granularidad por segundo).
• Pueden pausarse en cualquier momento, interrumpiendo la facturación.
• Más nuevas, más flexibles y con más recursos integrados en el ecosistema de Microsoft.
• Comienzan a partir de F2 (más pequeño y más barato), reduciendo el costo de entrada.
• Período de evaluación gratuita de 60 días disponible por Microsoft (F64), lo que permite ejecutar una PoC completa sin costo de capacidad.
• Cualquier tamaño de F SKU admite Embedding Analytics, según lo documentado por Microsoft en la página "Comprender las licencias de Microsoft Fabric".

Atención: Fabric utiliza los conceptos de smoothing, bursting y throttling, que alteran la lógica simple de "pausar = ahorrar". Esto se explicará en detalle más adelante en este artículo.

Power BI Embedded (A SKUs): opción de pago por uso

Disponibles desde 2017, las capacidades A SKUs (A1 a A6) se aprovisionan directamente en Azure y se facturan por hora de uso. Son la opción más tradicional, más estable y confiable para escenarios de Embedding.

Dependiendo de la región y el tamaño, pueden ser mucho más baratas que las F SKUs (Fabric) para determinados perfiles de uso.

Características:

• Se cobran por hora de ejecución. Pausar la capacidad suspende completamente la facturación.
• Más predecibles para uso continuo, ya que no tienen la complejidad del smoothing de Fabric.
• El cálculo de ahorro es simple: cantidad de horas encendida × costo por hora de la capacidad.
• Ampliamente compatibles con todas las herramientas y portales de Embedding del mercado.

Premium por Capacidad (P SKUs): descontinuado

Las capacidades P SKUs eran la versión premium de Power BI antes de Fabric. Fueron descontinuadas por Microsoft y ya no están disponibles para nuevas contrataciones. El costo inicial era de aproximadamente R$ 32.000/mes (nivel P1), lo que las hacía inviables para la mayoría de las empresas. Las P SKUs fueron reemplazadas por las F SKUs de Fabric.

Si ya tienes una capacidad Premium contratada (nivel P), esta incluye las funcionalidades de Embedded desde el nivel P1, y puede usarse con portales de Embedding normalmente.

¿Necesito F64 para usar Embedding Analytics sin licencia Pro?

Esta es una de las mayores confusiones en el mercado, así que vamos a aclararla de una vez por todas.

Es cierto que los usuarios pueden acceder a los informes directamente a través del portal de Power BI (app.powerbi.com) sin una licencia Pro, siempre que el espacio de trabajo esté asociado a una capacidad F64 o superior (equivalente al antiguo P1). Este es un beneficio específico y restringido al acceso directo a través del portal de Microsoft.

Pero cuando hablamos de Embedding Analytics, las reglas son completamente diferentes:

• Cualquier tamaño de F SKU (F2, F4, F8, F16...) permite visualizar informes a través del portal de Embedding sin necesidad de una licencia Pro por usuario.
• Cualquier SKU de Power BI Embedded (A1 a A6) también funciona para este escenario.
• Microsoft documenta explícitamente en la página "Comprender las licencias de Microsoft Fabric": para el escenario "la aplicación posee los datos" (App Owns Data), cualquier SKU F puede utilizarse y los usuarios finales no necesitan licencia.
• La página "Capacidad y SKU en el análisis integrado de Power BI" confirma: "El análisis integrado de Power BI requiere una capacidad (A, EM, P o F SKU) para publicar contenido incrustado de Power BI."

Es decir, no necesitas F64 para eliminar la necesidad de licencias Pro para tus usuarios. Necesitas cualquier capacidad dedicada, combinada con un portal de visualización que utilice el modelo App owns data. La diferencia de F64 es exclusiva para el escenario de acceso directo a app.powerbi.com sin licencia individual.

¿Cómo funciona la reducción de costos en la práctica?

La mecánica de la reducción de costos es simple: en lugar de que cada usuario acceda al portal de Power BI (que requiere una licencia individual), acceden al portal de Embedding, que no requiere una cuenta de Microsoft ni una licencia Pro. La capacidad contratada sirve a todos, independientemente de cuántos usuarios haya. El costo de la capacidad no escala con el número de usuarios.

Veamos un ejemplo concreto. Imagine una empresa con 200 usuarios que necesitan acceder a informes de Power BI:

Escenario actual, con Pro por usuario: 200 licencias × ~R$ 95/mes = R$ 19.000/mes

Escenario con Embedding Analytics:

• Capacidad F8 (suficiente para muchos escenarios de tamaño mediano): ~R$ 2.000 a R$ 3.000/mes
• Portal de visualización (como Power Embedded): ~R$ 5/usuario/mes = R$ 1.000/mes para 200 usuarios
• Licencias Pro solo para quienes publican informes (ej.: 5 desarrolladores): ~R$ 475/mes
• Total estimado: R$ 3.475 a R$ 4.475/mes

Esto representa un ahorro entre 75% y 80%. Y cuanto mayor sea el número de usuarios, mayor será el ahorro porcentual, ya que el costo de la capacidad es fijo y no crece con el número de usuarios.

¿A partir de cuántos usuarios vale la pena?

Para licencias Power BI Pro, en empresas donde los informes no necesitan estar disponibles las 24 horas del día, a partir de aproximadamente 15 usuarios ya es posible ahorrar alrededor del 50% en relación con el costo de las licencias Pro. Si utiliza una licencia Premium por Usuario (PPU), el ahorro puede llegar al 76% con solo 15 usuarios.

En escenarios donde los informes necesitan estar disponibles las 24 horas del día (capacidad encendida todo el tiempo, sin pausas), a partir de aproximadamente 30 usuarios, Embedding Analytics se vuelve más ventajoso financieramente.

¿Pausar la capacidad reduce el costo?

Una pregunta muy común: si pauso la capacidad fuera del horario comercial, ¿ahorro?

La respuesta depende del tipo de capacidad utilizada, y en el caso de Fabric, también de su patrón de uso:

Para Power BI Embedded (SKUs A): Pausar siempre reduce el costo, ya que no hay suavizado. La facturación es estrictamente por hora de uso. El cálculo de ahorro es simple y predecible: cantidad de horas encendidas × costo por hora. Tiene sentido pausar siempre que no haya informes en uso.

Para Microsoft Fabric (SKUs F): La situación es más compleja. El ahorro al pausar no siempre ocurre, debido a los conceptos de suavizado, bursting y throttling.

Suavizado, Bursting y Throttling en Fabric: entienda qué son

Suavizado (Smoothing):

El suavizado permite que las cargas de trabajo utilicen recursos más allá del límite aprovisionado durante los picos de demanda, distribuyendo el consumo de recursos a lo largo del tiempo. Para ello, Fabric utiliza el concepto de "preasignación proporcional de uso futuro". Esto permite usar la capacidad basada en el uso promedio, no en el pico.

En la práctica:

• Cuando ejecuta tareas en segundo plano, como la actualización de datasets, notebooks o pipelines, el sistema amortiza y distribuye el costo a lo largo de las próximas 24 horas.
• Para actividades interactivas (navegación en informes), hay un suavizado mínimo de solo 5 minutos.
• Si pausa la capacidad antes de que el suavizado se complete, el sistema entiende que interrumpió la "ventana de pago" y cobrará aparte las horas que ya estaban preasignadas. Esto puede, en algunos escenarios, incluso duplicar el costo estimado si considera solo las horas encendidas sin considerar el suavizado.

Bursting (Capacidad Elástica):

Permite que las cargas de trabajo utilicen temporalmente más recursos que el SKU base, mejorando el rendimiento en picos. Cada SKU tiene un factor de burst diferente (por ejemplo, F2 puede tener un burst de hasta 32x, F8 puede tener hasta 12x). Esto es útil para absorber picos sin necesidad de aprovisionar permanentemente una capacidad mayor.

Throttling (Limitación):

Ocurre cuando el uso promedio de CUs (Capacity Units) supera los límites suavizados del SKU. Las operaciones en curso no se interrumpen; la limitación se aplica solo a las próximas operaciones. El throttling ocurre en etapas progresivas:

1. Retraso Interactivo: después de 10 minutos de sobrecarga acumulada, las operaciones interactivas comienzan a sufrir retrasos.
2. Rechazo Interactivo: después de 60 minutos de sobrecarga acumulada, las operaciones interactivas son rechazadas.
3. Rechazo en Segundo Plano: después de 24 horas de sobrecarga acumulada, las operaciones en segundo plano son rechazadas.

Cuando tiene sentido pausar Microsoft Fabric:

• Fuera de los horarios fijos de ejecución de pipelines y actualizaciones de datos (por ejemplo, de medianoche a 6 a.m., cuando no hay actualizaciones programadas).
• Cuando el uso de la capacidad se compone principalmente de acciones interactivas (visualización y navegación en los informes), con poco o ningún procesamiento en segundo plano.
• Cuando el porcentaje de segundo plano en el informe Fabric Capacity Metrics es bajo antes de pausar.
• Siempre analice y monitoree el consumo de la capacidad en la pantalla de Administración de Costos de Azure. A partir del segundo día después de los cambios en la programación de las pausas, ya es posible analizar el costo diario para verificar si realmente se está produciendo un ahorro.

Cuando puede tener más sentido dejarlo encendido 24x7:

En muchos escenarios, especialmente cuando hay actualizaciones de datos frecuentes y uso continuo, puede tener más sentido contratar una reserva de instancia de Microsoft (descuento por compromiso de uso anual) y dejar la capacidad encendida todo el tiempo, en lugar de pausar y potencialmente generar cargos de suavizado inesperados.

Qué sucede cuando la capacidad está pausada:

Mientras la capacidad esté pausada, nadie puede acceder a los informes, ni siquiera los usuarios con licencia Pro que acceden directamente a través del portal de Power BI (app.powerbi.com). Los datasets tampoco se actualizan. Este es un punto crítico de planificación.

Modelos de Disponibilidad: 24x7, 14x6 y 12x5

La facturación de Power BI Embedded y Fabric se calcula por las horas en que la capacidad estuvo encendida. Como ambas permiten pausar la capacidad, existen diferentes estrategias de disponibilidad. Las más comunes son:

• 24x7: capacidad disponible 24 horas al día, 7 días a la semana. Sin ninguna pausa. Escenario para operaciones que necesitan informes disponibles en cualquier momento.
• 14x6: capacidad disponible 14 horas al día, 6 días a la semana (lunes a sábado). Representa un ahorro del 53% en relación con el 24x7. Atiende a la mayoría de los clientes corporativos.
• 12x5: capacidad disponible 12 horas al día, 5 días a la semana (lunes a viernes). Representa un ahorro del 67% en relación con el 24x7. Adecuado para empresas con uso estrictamente en horario comercial.

Estos son solo ejemplos. Los horarios reales se definen según el perfil de uso de cada empresa. Herramientas como Power Embedded ofrecen gestión automática de pausa e inicio de la capacidad, pudiendo también iniciarse automáticamente cuando un usuario intenta acceder a un informe fuera del horario definido, y pausarse nuevamente después de un período de inactividad configurable por el administrador.

Capacidad por encima del límite: ¿qué hacer?

Si el entorno comienza a presentar sobrecargas constantes (mensajes de error, impedimentos para la actualización de modelos o la visualización de informes), algunas medidas pueden ayudar antes de aumentar el SKU:

• Optimizar medidas DAX con alto consumo de capacidad.
• Evitar columnas calculadas y tablas calculadas en el modelo, cuando sea posible.
• Reducir el número de visuales por página (lo recomendado es no más de 10).
• Optimizar el modelado de los datasets: evitar relaciones N:N y filtrado bidireccional.
• Identificar y eliminar columnas y tablas no utilizadas en el modelo.
• Pre-agregar datos antes de importarlos a Power BI.
• Optimizar el código M (Power Query) asegurando que se esté produciendo el Query Folding.
• Utilizar la carga incremental de datos en lugar de actualizaciones completas.
• Evaluar el uso de DirectQuery o DirectLake para volúmenes de datos muy grandes.
• Separar datasets grandes en capacidades diferentes, distribuyendo la carga.
• Evaluar si es necesario aumentar el SKU o dividir las cargas de trabajo en múltiples capacidades.

Riesgos de soluciones que violan el licenciamiento

En el mercado existen soluciones de Embedding que intentan reducir costos de formas no soportadas por Microsoft. Las dos prácticas más comunes y peligrosas son:

1. Uso de licencias Pro o PPU en producción (App Owns Data)

Como ya se explicó, Pro y PPU son estrictamente para desarrollo y pruebas. En producción, viola los términos de licenciamiento de Microsoft y puede resultar en penalizaciones contractuales, auditorías, suspensión de servicios y riesgos legales.

2. SaaS multi-tenant con un único tenant y Service Principal compartido entre todos los clientes

Otra práctica común para la reducción de costos es consolidar múltiples clientes en un único tenant controlado por el proveedor, con un único Service Principal y una capacidad compartida. En este modelo, el cliente tiene solo un usuario para acceder y publicar informes, en lugar de ser el propietario de la información con todos los controles de auditoría y seguridad de su propio entorno.

Aunque técnicamente posible, esta práctica crea riesgos críticos:

Riesgos de seguridad y aislamiento:

• Aislamiento inexistente: Un único Service Principal técnico para todos los clientes significa: sin segregación de identidad, sin RBAC real por cliente, sin control de acceso granular por organización y sin Conditional Access por empresa. Cualquier error de configuración de RLS puede exponer datos de un cliente a otro.
• Compromiso en cascada: Si el token o la credencial se filtra (a través de logs, navegador, proxy o DevTools), cualquier persona tiene acceso a todos los informes de todos los clientes en ese tenant. Si alguien abandona la empresa del proveedor con acceso al Service Principal, todos los clientes se ven comprometidos simultáneamente.
• Sin auditoría para el cliente: Cuando el cliente no es propietario del tenant, no ve los logs de acceso, no controla Purview, no controla Microsoft Defender for Cloud Apps y no puede probar el cumplimiento en auditorías de LGPD/GDPR.
• Zero Trust violado: Microsoft recomienda el aislamiento por tenant o capacidad, el control de identidad a través de Entra ID y la segregación arquitectónica multi-tenant como mejores prácticas para escenarios corporativos.

Riesgos de cumplimiento y LGPD/GDPR:

• El cliente deja de ser el Controlador de Datos y el Propietario del Tenant, transfiriendo la responsabilidad legal al proveedor sin los controles adecuados.
• En GDPR/LGPD, esto puede caracterizar el procesamiento sin control del controlador, aumentando la responsabilidad legal de la empresa contratante.
• Inhabilita certificaciones como SOC 2, ISO 27001, auditorías de licenciamiento de Microsoft y controles de RBAC, Purview y Microsoft Defender.

Riesgos de licenciamiento:

• Violación de los Términos de Producto de Microsoft y del contrato de licenciamiento.
• Auditorías de cumplimiento y multas contractuales por parte de Microsoft.
• Suspensión del servicio o del tenant, impactando toda la operación de la empresa.
• Riesgo legal y reputacional para la organización contratante.

Errores comunes al implementar el modelo App Owns Data

Además de las prácticas prohibidas anteriores, existen dos patrones comunes de implementación incorrecta que vale la pena destacar:

Error 1: Portal que aloja informes de clientes en el tenant del ISV

• Un único workspace por cliente dentro del tenant del proveedor.
• Una capacidad compartida entre todos los clientes.
• Service Principal controlado por el proveedor, no por el cliente.
• Acceso segmentado solo por RLS o filtros de token.
• El cliente no tiene ningún control real sobre sus informes.

Riesgos: violación de las reglas de licenciamiento, posible infracción contractual con Microsoft, riesgo de suspensión de la cuenta y datos de múltiples clientes bajo el control de un único tenant (riesgo de seguridad y privacidad).

Error 2: Uso de Master Account con licencia Pro para todos los informes

• La aplicación utiliza una cuenta genérica con licencia Pro para generar tokens de inserción.
• No utiliza Service Principal (práctica obsoleta y no recomendada por Microsoft).
• No hay uso de capacidad Premium dedicada.
• Los usuarios finales acceden sin licencia, en violación del licenciamiento.

Riesgos adicionales de seguridad: necesidad de almacenar nombre de usuario y contraseña (con riesgo de fuga), tokens generados con permisos de un usuario humano (sin autenticación granular o alcance controlado), y si los tokens son interceptados, cualquier persona puede acceder al contenido incrustado.

¿Qué necesita para usar Embedding Analytics?

Para implementar Embedding Analytics en el modelo correcto (App owns data), necesita los siguientes requisitos previos:

• Una capacidad dedicada: Fabric F SKU o Power BI Embedded A SKU, contratada a través del portal de Azure directamente con Microsoft o a través de un socio de Microsoft.
• Un workspace de Power BI no personal: Los informes que se incrustarán deben estar en un workspace asociado a la capacidad. Los workspaces personales no son compatibles con Embedding.
• Un Service Principal: Una identidad técnica creada en Azure AD (Entra ID) con permisos para acceder a los workspaces y generar tokens de inserción. El Service Principal debe tener acceso solo a los workspaces necesarios, con permisos mínimos.
• Un portal de visualización: Microsoft proporciona las APIs, pero no ofrece un portal listo. Debe desarrollar una aplicación web propia o contratar una solución SaaS ya lista.
• Licencia Pro para los desarrolladores: Los usuarios que publican informes en el servicio de Power BI aún necesitan una licencia Pro o PPU. Solo los usuarios que visualizan a través del portal de Embedding no la necesitan. Una alternativa para eliminar también esta dependencia es usar Azure DevOps para la publicación automática a través de CI/CD.
• Cuenta de Azure: Para crear la capacidad, necesita una cuenta en Azure con permisos para crear recursos. Si su empresa no tiene una cuenta de Azure, puede crearla de forma gratuita, incluso con crédito inicial de Microsoft.

Desde el punto de vista de las configuraciones técnicas en Azure/Entra ID para la instalación, típicamente se necesitan:

• Cuenta de usuario con permiso para crear la capacidad Fabric o Embedded en Azure.
• Cuenta de usuario con permiso para crear grupos y Service Principals en Entra ID.
• Cuenta de usuario que posea el rol "Fabric Administrator" para acceder al portal de administración de Power BI y configurar los permisos del Service Principal.

¿Cómo funciona el proceso de publicación de informes?

El flujo de publicación y disponibilidad de informes en Embedding Analytics es prácticamente el mismo que ya existe en el servicio tradicional de Power BI. No se necesita ningún cambio significativo en el proceso de creación de informes:

1. El analista de BI abre Power BI Desktop y crea o edita el informe normalmente.
2. El analista publica el informe en el workspace deseado en el servicio de Power BI (app.powerbi.com), utilizando su licencia Pro o PPU.
3. El administrador del portal de Embedding importa el informe del workspace de Power BI al sistema.
4. El administrador asigna los permisos de acceso al informe, a través de grupos o usuarios individuales.
5. El administrador configura las reglas de RLS del conjunto de datos, si es necesario.
6. Los usuarios acceden al informe a través del portal de visualización, con sus credenciales configuradas en la plataforma.

Los usuarios finales no necesitan instalar Power BI Desktop, crear una cuenta en Microsoft o tener ningún conocimiento de Power BI. Para ellos, los informes aparecen dentro del portal de la empresa, como parte de la aplicación.

LGPD y Privacidad en Embedding Analytics

Un punto frecuentemente cuestionado es la conformidad con la LGPD (Ley General de Protección de Datos) y el GDPR europeo en el uso de portales de Embedding. La respuesta positiva depende de la arquitectura utilizada.

En el modelo correcto (App owns data, con los informes en el tenant del propio cliente):

• El proceso de incrustar informes no requiere la carga o lectura de ningún dato de la empresa por el portal. Todos los datos se almacenan en los servidores de Power BI, en el tenant de la propia empresa.
• El portal solo realiza una llamada HTTP a la API de Power BI, que lee los metadatos de los informes y modelos semánticos en el tenant del cliente y los muestra en pantalla. Los datos nunca transitan por el servidor del portal.
• Los únicos datos almacenados por el portal son los nombres y correos electrónicos de los usuarios registrados, para la gestión de accesos.
• Toda la comunicación está cifrada de extremo a extremo vía SSL/HTTPS.
• La empresa sigue siendo la Data Controller de sus propios datos, manteniendo todos los controles de auditoría, Purview, Defender y cumplimiento.

En el modelo incorrecto (tenant del proveedor, Service Principal compartido), la empresa pierde el control sobre sus datos y puede tener serias dificultades para demostrar el cumplimiento de la LGPD en una eventual auditoría.

¿Crear un Portal Propio o Contratar una Solución Lista?

Esta es una decisión importante. Microsoft pone a disposición las APIs de Power BI Embedded para que cualquier empresa desarrolle su propio portal, pero la complejidad real de hacerlo correctamente es mucho mayor de lo que parece en la documentación:

• Implementación de autenticación con Azure AD (Entra ID) y generación de tokens de incrustación con Service Principal.
• Gestión de usuarios, grupos, permisos y RLS programático.
• Interfaz de usuario responsiva, accesible y compatible con múltiples navegadores y dispositivos móviles.
• Gestión de servidor de aplicación, base de datos e infraestructura en la nube.
• Mantenimiento continuo para seguir los cambios en las APIs de Microsoft (que son frecuentes).
• Soporte técnico para usuarios finales y para desarrolladores de informes.
• Gestión de pausa e inicio de la capacidad.
• Seguridad de la aplicación (pentest, gestión de secretos, Azure Key Vault, etc.).

Para una empresa con 100 usuarios, un portal básico (solo inicio de sesión, permisos simples y visualización) demanda fácilmente 100 o más horas de un desarrollador experimentado, sin contar la infraestructura, el mantenimiento y la evolución continua. Funcionalidades avanzadas como IA generativa, multi-idiomas, modo TV, suscripción de informes por correo electrónico, SSO, sincronización con Entra ID, APIs externas y auditoría detallada multiplican este esfuerzo significativamente.

La alternativa es contratar una solución SaaS ya construida, con todo esto disponible inmediatamente, mantenida y evolucionada de forma continua por el proveedor, con SLA de disponibilidad y soporte especializado.

Power Embedded: una Plataforma Recomendada

Una opción que recomiendo y conozco de cerca es Power Embedded. Tuve la oportunidad de seguir su desarrollo desde el principio, durante mi período en Power Tuning, y puedo decir con propiedad que es una plataforma seria, técnicamente sólida y con una arquitectura correcta desde el punto de vista de licenciamiento y seguridad de Microsoft.

Desde el punto de vista arquitectónico, Power Embedded opera en el modelo App owns data con aislamiento completo por cliente:

• Cada cliente tiene su propio tenant de Microsoft Entra ID.
• Cada cliente tiene su propia capacidad Premium (Power BI Embedded o Fabric).
• Cada cliente tiene sus propios workspaces con informes, asociados a su propia capacidad.
• Se crea un Service Principal directamente dentro del tenant del cliente (con su consentimiento), con permisos solo en los workspaces utilizados en el portal.
• Power Embedded autentica usando el client_id + secret del Service Principal del cliente, genera el token de incrustación con alcance mínimo y aplica seguridad y RLS basándose en las configuraciones del cliente.
• No hay alojamiento de los informes en el tenant de Power Tuning; el acceso y la incrustación ocurren usando el Service Principal del tenant del propio cliente.

Esto está 100% en conformidad con el modelo "App owns data" documentado por Microsoft, y garantiza que, incluso siendo un portal multi-cliente, cada tenant tiene su propia instancia de incrustación aislada.

Desde el punto de vista de infraestructura y seguridad interna:

• Arquitectura basada en recursos SaaS autogestionados en Azure, con alta disponibilidad del 99,99%, failover automático y copias de seguridad automáticas.
• Pentests periódicos, tanto automatizados como manuales por especialistas en seguridad contratados.
• Todo el entorno de la nube protegido por Microsoft Defender for Cloud.
• Acceso a los recursos de Azure bloqueado para internet, accesible solo vía VPN.
• Comunicación cifrada vía certificados SSL (HTTPS).
• Claves de acceso a Power BI almacenadas cifradas con RSA-OAEP, con claves individuales por cliente en Azure Key Vault.

Algunas de las características disponibles en la plataforma:

• Reducción de hasta el 90% en los costos de licenciamiento de Power BI.
• Los usuarios acceden con cualquier correo electrónico (corporativo, Gmail, etc.), sin cuenta Microsoft, sin instalar aplicaciones.
• Todos los workspaces pasan a ser Premium, liberando hasta 48 actualizaciones por día, datasets superiores a 1 GB, XMLA Endpoint, tablas híbridas, pipelines de implementación y versionamiento con Git.
• White-label completo: identidad visual de su empresa o de cada cliente, incluyendo URL personalizada.
• Multi-idiomas (6 idiomas soportados).
• Sincronización automática de usuarios y grupos vía Entra ID (SSO).
• IA generativa (Power Pilot): preguntas en lenguaje natural directamente sobre los datos, con generación de tablas y gráficos dinámicos.
• RLS, OLS y auditorías detalladas de inicio de sesión y acceso.
• Modo TV para informes que se muestran automáticamente en paneles de monitoreo.
• Gestión automática de la capacidad: se enciende cuando hay acceso, se apaga por inactividad configurable.
• Exportación en CSV, Excel, PDF, imagen y PowerPoint.
• APIs para automatización e integración con sistemas externos.
• Informes responsivos: soporte nativo para diseño móvil, sin necesidad de instalar aplicaciones.
• Implementación en hasta 16 horas hábiles después de la aprobación comercial, instalación de 20 a 60 minutos.
• 30 días de evaluación gratuita (además de los 60 días gratuitos de capacidad F64 disponibles por Microsoft).

No es obligatorio usar Power Embedded específicamente. Lo importante es que cualquier solución que utilice respete la arquitectura correcta: App owns data, Service Principal por tenant de cliente, capacidad dedicada por cliente y aislamiento total entre clientes. Pero si desea una opción lista, probada en producción, con soporte especializado y actualizada constantemente, Power Embedded es mi recomendación.

Consideraciones Finales

Embedding Analytics es una de las funcionalidades más potentes y subutilizadas del ecosistema Power BI. Resuelve tres problemas al mismo tiempo: reduce los costos de licenciamiento, mejora la experiencia del usuario final y aumenta el control de seguridad sobre quién accede a qué.

Los puntos más importantes para recordar:

• Embedding Analytics es una característica de Microsoft; no es el nombre de una plataforma específica.
• El modelo correcto para eliminar licencias por usuario es App owns data, con capacidad dedicada.
• Pro y PPU son para desarrollo y pruebas; en producción, Microsoft exige capacidad dedicada.
• Usted no necesita F64 para usar Embedding Analytics sin licencia por usuario. Cualquier SKU F o SKU A funciona.
• Los desarrolladores que publican informes aún necesitan licencia Pro. Los usuarios que visualizan a través del portal de Embedding, no.
• Las soluciones que comparten un único tenant y Service Principal entre varios clientes crean serios riesgos de seguridad, cumplimiento y licenciamiento.
• Microsoft no proporciona un portal de visualización listo. Usted necesita desarrollarlo o contratar uno.
• En Fabric, pausar la capacidad no siempre genera ahorro. Entienda el smoothing antes de definir la estrategia de pausa.
• Con modelos de disponibilidad como 14x6 o 12x5, es posible ahorrar del 53% al 67% sobre el costo de una capacidad 24x7.
• A partir de solo 15 usuarios Pro, Embedding Analytics ya puede ser más económico.

Si está evaluando implementar esta estrategia en su empresa, recomiendo comenzar por el período de evaluación gratuita de 60 días de Microsoft Fabric (F64). En ese período, podrá ejecutar toda la prueba de concepto y medir el consumo real de capacidad de su entorno antes de definir qué SKU contratar en producción.

Referencias Oficiales

Todo el contenido técnico de este artículo se basa en la documentación oficial de Microsoft. A continuación se presentan los principales enlaces para consulta y profundización:

• Análisis integrado de Power BI — Microsoft Learn — Descripción general oficial de Embedding Analytics, modelos de inserción y requisitos de licenciamiento.
• Insertar para sus clientes (App Owns Data) — Microsoft Learn — Detalle del modelo App Owns Data con Service Principal.
• Insertar para la organización (User Owns Data) — Microsoft Learn — Detalle del modelo User Owns Data con autenticación por usuario.
• Mover a producción (Power BI Embedded) — Microsoft Learn — Documentación oficial que confirma que los tokens con Pro/PPU son exclusivos para desarrollo y que una capacidad es obligatoria en producción.
• Capacidad y SKUs en el análisis integrado de Power BI — Microsoft Learn — Tabla comparativa de SKUs, requisitos de licenciamiento por escenario de incrustación y confirmación de que App Owns Data no exige licencia de los usuarios finales.
• Preguntas frecuentes sobre Power BI Embedded — Microsoft Learn — FAQ técnico oficial, incluyendo límites de tokens por tipo de licencia.
• Incorporar contenido de Power BI con entidad de servicio — Microsoft Learn — Cómo configurar y usar Service Principal en el modelo App Owns Data.
• Escenarios de uso: insertar para clientes — Microsoft Learn — Guía de planificación de implementación con requisitos de licenciamiento para el modelo de inserción para clientes.
• Entender las licencias de Microsoft Fabric — Microsoft Learn — Detalle completo de los SKUs F, escenarios de incrustación por tipo de SKU y requisitos de licenciamiento por usuario.
• Suavizado y limitación de la capacidad de cómputo en Microsoft Fabric — Microsoft Learn — Documentación técnica sobre suavizado, ráfagas y limitación en capacidades Fabric.

Bueno, espero que este artículo haya ayudado a aclarar el Embedding Analytics en Power BI de forma completa y práctica.

¡Un fuerte abrazo y hasta pronto!