¡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 en carne propia 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 el Embedding Analytics, cómo funciona, cuáles son los modelos de licencia disponibles, las capacidades dedicadas involucradas, los conceptos técnicos de smoothing, bursting y throttling de Fabric, los riesgos de soluciones que se salen 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 los 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, a menudo, 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, muchas veces, resistencia por parte del departamento de TI.

Es justamente para resolver estos problemas que Microsoft creó el recurso 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 un recurso oficial de Microsoft que permite incorporar informes, dashboards 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.

¡No confundas Embedding Analytics con Power Embedded!

Embedding Analytics es el nombre de la tecnología y funcionalidad de Microsoft. Power Embedded es el nombre de una plataforma específica, de la empresa Power Tuning, que implementa y facilita el uso de esta tecnología. El Embedding Analytics es el recurso; el Power Embedded es una de las herramientas que utiliza este recurso.

En la práctica, el Embedding Analytics permite que construyas (o contrates) un portal web propio, donde los informes de Power BI aparecen embebidos, como si formaran parte de tu aplicación. El usuario final accede a tu portal, inicia sesión con las credenciales que definas (correo 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 embeber informes en sitios web, SharePoint, correo electrónico, Teams y otros canales, son muy diferentes en seguridad, costo y control. Mira la comparativa:

1. Publicar en la Web

Es la forma más sencilla, pero también la más peligrosa. El informe queda totalmente público, sin ningún control de acceso. Cualquier persona que tenga el enlace puede visualizar 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.

Aunque intentes bloquear el acceso con una contraseña en el portal que aloja el iframe, este tipo de protección se puede eludir fácilmente en pocos segundos usando las Developer Tools del navegador. La persona tendrá acceso irrestricto a los datos publicados en el informe.

2. Insertar Informe (vía 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 vía capacidad dedicada)

Es el recurso más completo. 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 vía 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. La licencia se realiza mediante capacidad dedicada (Fabric o Power BI Embedded), no por usuario. Es la única opción que entrega todos estos beneficios al mismo tiempo.

Los dos modelos de inserción de informes

Dentro del 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 licencia:

User Owns Data: Insertar para la Organización

Este es el modelo más sencillo y directo. Cada usuario final se autentica en Power BI con su propia cuenta corporativa, vía 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 workspace 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 licencia 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 lo que hace posible la gran reducción de costos.

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

Las características de este modelo:

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

La documentación oficial de Microsoft confirma: "Para el Embedding para tus clientes (la aplicación posee los datos), no hay requisitos de licencia para los usuarios finales." Además, Microsoft documenta que la alteración y creación de informes a través de un portal que utilice la licencia de Power BI Embedded no requiere licencia Pro o PPU, lo que hace que esta operación sea totalmente legal y soportada.

¿Puedo usar licencia Pro o PPU para embeber 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 embed con una cuenta Pro o PPU (llamada "Master Account"), pero la propia Microsoft es explícita en la documentación oficial:

"Los tokens incorporados con licencia Pro o Premium por usuario (PPU) están destinados a pruebas de desarrollo, por lo tanto, una cuenta maestra o Service Principal de Power BI solo puede generar un número limitado de tokens. Adquiere una capacidad para la incorporación en un entorno de producción. No hay límite para cuántos tokens incorporados puedes generar al comprar una capacidad."

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

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

Usar licencia Pro para esto en producción:

  • Viola los términos de uso de Power BI y los Microsoft Product Terms.
  • Puede resultar en multas, sanciones y auditorías de cumplimiento por parte de Microsoft.
  • Tiene un límite de tokens que, cuando se alcanza, hace que los informes dejen de cargarse.
  • Crea riesgos serios de seguridad, ya que el uso de Pro/PPU + embedding externo puede ser explotado como 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 tenant.
  • El uso de Master Account exige almacenar inicio de sesión y contraseña, lo que crea riesgo de filtración de credenciales.

Si has contratado (o estás evaluando) una plataforma de embedding que utiliza una cuenta Pro o Master Account para generar los tokens de inserción sin capacidad dedicada, tu empresa probablemente está violando los términos de uso de Power BI y está expuesta a multas, sanciones y riesgos de seguridad graves.

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 embed 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, este límite se alcanza y Power BI no permite más insertar informes.

Por estos motivos, 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 Fabric son la generación más nueva y completa. Además de soportar Embedding Analytics, habilitan todos los demás workloads de Microsoft Fabric: Data Engineering, Data Science, Data Warehouse, Real-Time Analytics y mucho más. Son la opción recomendada para nuevos proyectos.

Ventajas de los F SKUs:

  • Cobrados por hora de ejecución (granularidad por segundo).
  • Pueden pausarse en cualquier momento, interrumpiendo el cobro.
  • Más nuevos, más flexibles y con más recursos integrados al ecosistema Microsoft.
  • Comienzan a partir de F2 (menor y más barato), reduciendo el costo de entrada.
  • Periodo de evaluación gratuita de 60 días disponible por Microsoft (F64), permitiendo ejecutar una PoC completa sin costo de capacidad.
  • Cualquier tamaño de F SKU soporta Embedding Analytics, según lo documentado por Microsoft en la página "Entender 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 pay-as-you-go

Disponibles desde 2017, las capacidades A SKUs (A1 a A6) se aprovisionan directamente en Azure y se cobran 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 los F SKUs (Fabric) para determinados perfiles de uso.

Características:

  • Cobrados por hora de ejecución. Pausar la capacidad suspende completamente el cobro.
  • Más predecibles para uso continuo, pues no tienen la complejidad del smoothing de Fabric.
  • El cálculo de ahorro es sencillo: cantidad de horas encendida × costo por hora de la capacidad.
  • Ampliamente soportadas por 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 (~US$ 5.800/mes) (tier P1), lo que las hacía inviables para la mayoría de las empresas. Los P SKUs fueron sustituidos por los F SKUs de Fabric.

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

Premium por Capacidad (EM SKUs): para Aplicaciones Internas y SharePoint

Los EM SKUs son una modalidad de capacidad de Power BI Premium creada específicamente para el escenario de inserción para la organización (User Owns Data): aplicaciones internas corporativas, intranet, SharePoint Online, Teams y PowerPoint. A diferencia de los A SKUs (adquiridos a través del portal de Azure, cobrados por hora, pausables), los EM SKUs se adquieren vía contrato de licenciamiento por volumen de Microsoft (Enterprise Agreement o CSP), con compromiso anual y cobro mensual fijo.

La principal ventaja del EM en relación con simplemente comprar licencias Pro para cada colaborador es permitir que usuarios con cuenta gratuita de Power BI visualicen informes incorporados en SharePoint Online, sin necesidad de asignar una licencia Pro a cada uno.

Características de los EM SKUs:

  • No se pueden pausar: El cobro es mensual fijo, independientemente del tiempo de uso real. No existe la opción de pausar para reducir costos en horarios de bajo uso.
  • Contratación vía licenciamiento corporativo: Adquiridos a través de contratos de licenciamiento por volumen de Microsoft (Enterprise Agreement o CSP), no directamente por el portal de Azure como los F y A SKUs. Los niveles EM1 y EM2 no están disponibles para compra individual.
  • Compatibles con la Web Part de Power BI para SharePoint Online: Permiten que usuarios con cuenta gratuita de Power BI visualicen informes incorporados en SharePoint, sin necesidad de licencia Pro.

Equivalencias de capacidad computacional y valores estimados de referencia (los EM SKUs se adquieren exclusivamente vía contrato de volumen y no poseen tabla de precios oficial divulgada públicamente; los valores a continuación son estimaciones basadas en información de mercado y pueden variar según el tipo de cambio, canal de contratación y negociación):

  • EM1 (1 v-core): equivalente al F8 y al A1. ~R$ 4.070/mes (~US$ 740/mes).
  • EM2 (2 v-cores): equivalente al F16 y al A2. ~R$ 8.131/mes (~US$ 1.480/mes).
  • EM3 (4 v-cores): equivalente al F32 y al A3. ~R$ 16.283/mes (~US$ 2.960/mes).

Al no poder pausarse, los EM SKUs suelen tener un costo efectivo mayor que los A SKUs del mismo tamaño para empresas que no necesitan la capacidad encendida las 24 horas del día. Para la mayoría de los escenarios de embedding, los F SKUs o A SKUs ofrecen más flexibilidad y un costo total menor. El EM tiene más sentido para grandes empresas con contratos de licenciamiento corporativo (Enterprise Agreement) ya activos y una necesidad exclusiva de uso interno en SharePoint. Para más detalles sobre este tipo de licencia, consulte el artículo Power BI Premium por Capacidad: SKU EM.

Todas las capacidades se contratan directamente con Microsoft (o a través de un partner de Microsoft) mediante el portal de Azure. La contratación la realiza su propia empresa, lo que garantiza total transparencia en el cobro, trazabilidad y gobernanza sobre los recursos provisionados. Usted puede incluso contratar la capacidad con cualquier partner de Azure, o directamente a través de Microsoft.

Embedding en SharePoint Online: la Web Part Nativa de Power BI

Para empresas que utilizan Microsoft 365 y SharePoint Online como intranet corporativa, existe una forma nativa de incorporar informes directamente en páginas de SharePoint: la Web Part de Power BI para SharePoint Online. Este recurso permite que los colaboradores visualicen informes interactivos sin salir del entorno de SharePoint, integrando análisis directamente en las páginas y portales del día a día corporativo.

Es importante comprender las diferencias entre este enfoque y el Embedding Analytics completo descrito en las secciones anteriores, ya que cada uno tiene características, requisitos de licencia y casos de uso distintos.

Web Part de SharePoint vs. Embedding Analytics Completo: principales diferencias

La Web Part nativa de SharePoint utiliza el modelo User Owns Data. Esto significa que cada usuario se autentica con su propia cuenta de Microsoft y Power BI aplica los controles de seguridad basados en esa identidad.

Web Part de Power BI para SharePoint Online (User Owns Data):

  • Cada usuario se autentica con su propia cuenta de Microsoft organizacional.
  • La seguridad y el RLS se aplican automáticamente según la identidad del usuario conectado.
  • No requiere desarrollo: configuración sencilla vía interfaz de SharePoint, en pocos minutos.
  • No ofrece control programático: no es posible aplicar filtros vía código, cambiar temas o páginas dinámicamente.
  • Acepta solo cuentas de Microsoft organizacionales del tenant. No acepta Gmail ni correos electrónicos externos.
  • Requiere licencia Power BI Pro, PPU, o que el workspace esté en una capacidad EM o P SKU.

Embedding Analytics completo (App Owns Data), con portal dedicado:

  • La aplicación se autentica en Power BI vía Service Principal, no el usuario final.
  • Los usuarios finales no necesitan cuenta de Microsoft ni licencia de Power BI.
  • Requiere desarrollo de un portal propio o la contratación de una solución lista.
  • Ofrece control total vía SDK: filtros dinámicos, temas, exportaciones programáticas y mucho más.
  • Cualquier F SKU o A SKU es suficiente, sin necesidad de EM o P.
  • Adecuado para portales externos, clientes, partners y escenarios SaaS.

Licenciamiento para Visualización en SharePoint: la Diferencia del EM SKU

Para que un usuario visualice un informe insertado vía Web Part de SharePoint, debe cumplirse una de las siguientes condiciones:

  • El usuario tiene licencia Power BI Pro o PPU (Premium por Usuario); o
  • El workspace que contiene el informe está asociado a una capacidad EM SKU o P SKU.

Los F SKUs menores que F64 no son suficientes para la Web Part de SharePoint. En el Embedding Analytics completo (App Owns Data), cualquier F SKU, desde F2 hasta F128, permite eliminar licencias por usuario. En la Web Part nativa de SharePoint (User Owns Data), este beneficio solo se aplica a partir del F64. Si su empresa usa F2, F4, F8, F16 o F32 y desea permitir la visualización en SharePoint sin licencia Pro, la solución es usar una capacidad EM SKU, migrar a F64+ o adoptar el modelo App Owns Data con un portal dedicado.

Es precisamente para este escenario que se crearon los EM SKUs: permitir que colaboradores sin licencia Pro accedan a informes incorporados en la intranet o en SharePoint, sin necesidad del P SKU (que comienza en ~R$ 32.000/mes) ni del F64 (cuya capacidad computacional equivale al P1).

Cómo Incorporar un Informe en SharePoint Online

El proceso no requiere desarrollo y puede completarse en pocos minutos:

  1. Abra el informe en el servicio de Power BI (app.powerbi.com).
  2. Haga clic en Archivo, seleccione Insertar informe y luego SharePoint Online.
  3. Copie la URL que aparece en el cuadro de diálogo.
  4. Acceda a la página de SharePoint Online deseada y haga clic en Editar.
  5. Añada una nueva Web Part, localice la sección Análisis de Datos y seleccione Power BI.
  6. Haga clic en Agregar informe y pegue la URL copiada. El informe se cargará automáticamente en la Web Part.
  7. Haga clic en Publicar para hacer la página visible para los demás usuarios.

El recurso funciona solo en Páginas Modernas de SharePoint Online. El SharePoint Server clásico (on-premises) y las páginas con diseño clásico no son compatibles con esta Web Part. Es necesario tener habilitada la creación de páginas modernas en el tenant de SharePoint antes de usar el recurso.

Tras la inserción, la Web Part ofrece las siguientes configuraciones:

  • Página predeterminada: define qué página del informe se muestra al cargar la Web Part.
  • Visualización: ajusta cómo el informe se adapta al ancho de la página de SharePoint.
  • Panel de Navegación: muestra u oculta el panel de navegación entre páginas del informe.
  • Panel de Filtro: muestra u oculta el panel lateral de filtros.

Limitaciones y Restricciones de la Web Part de SharePoint

  • Sin soporte para usuarios invitados B2B: Los usuarios externos añadidos vía Azure B2B no pueden visualizar informes en la Web Part de SharePoint.
  • Sin filtros vía URL: No es posible pasar filtros por parámetros de URL a la Web Part de Power BI en SharePoint.
  • Solo Páginas Modernas: El SharePoint clásico (on-premises) no es compatible.
  • Sin control programático: No es posible aplicar filtros vía código, exportar por API o personalizar la experiencia dinámicamente como en el SDK de Power BI Embedded.
  • El acceso a Aplicaciones requiere preinstalación: Para mostrar contenido de una Aplicación de Power BI en SharePoint, el usuario debe instalar la aplicación en el servicio de Power BI antes de poder visualizarla en la página.
  • MFA puede causar errores de autenticación: Si el entorno exige MFA y el usuario no se autenticó con MFA al entrar en SharePoint, puede aparecer un error de token. La solución es cerrar sesión y volver a entrar con el dispositivo de MFA configurado.
  • Copilot disponible con capacidad Premium: Es posible habilitar Copilot marcando la opción al generar el enlace de inserción (Archivo > Insertar informe > SharePoint Online). Requiere que Copilot esté habilitado en el tenant y que el workspace esté en una capacidad Premium o Fabric de pago.

¿Necesito F64 para Usar Embedding Analytics sin Licencia Pro?

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

Es cierto que los usuarios pueden acceder a informes directamente a través del portal de Power BI (app.powerbi.com) sin licencia Pro, siempre que el workspace 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 vía portal de Embedding sin necesidad de 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 "Entender las licencias de Microsoft Fabric": para el escenario "la aplicación posee datos" (App Owns Data), se puede utilizar cualquier SKU F y los usuarios finales no necesitan licencia.
  • La página "Capacidad y SKUs 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 insertado de Power BI."

Es decir, usted no necesita F64 para eliminar la necesidad de licencias Pro para sus usuarios. Usted necesita cualquier capacidad dedicada, combinada con un portal de visualización que utilice el modelo App owns data. La diferencia del 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 sencilla: en lugar de que cada usuario acceda al portal de Power BI (que exige licencia individual), acceden al portal de Embedding, que no requiere cuenta de Microsoft ni licencia Pro. La capacidad contratada sirve a todos, independientemente de cuántos usuarios existan. El costo de la capacidad no escala con el número de usuarios.

Vamos a 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 (~US$ 3.450/mes)

Escenario con Embedding Analytics:

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

Esto representa un ahorro de entre el 75% y el 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 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.

Además de la reducción de costos en licencias, al utilizar una capacidad dedicada todos los workspaces asociados pasan a ser Premium, liberando recursos que no están disponibles con licencias Pro: hasta 48 actualizaciones de datos por día, datasets superiores a 1 GB, XMLA Endpoint, tablas híbridas, actualización incremental, pipelines de implementación, versionado con Git y mucho más.

¿Pausar la Capacidad Reduce el Costo?

Una duda 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 (A SKUs): Pausar siempre reduce el costo, ya que no hay smoothing. El cobro es estrictamente por hora de uso. El cálculo de ahorro es sencillo y predecible: cantidad de horas encendida × costo por hora. Tiene sentido pausar siempre que no haya informes en uso.

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

Smoothing, Bursting y Throttling: entienda qué son

Smoothing (Suavizado):

El suavizado permite que las cargas de trabajo utilicen recursos más allá del límite aprovisionado durante 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 utilizar la capacidad basada en el uso promedio, no en el pico.

En la práctica:

  • Cuando ejecuta tareas de fondo, como 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 smoothing se complete, el sistema entiende que usted interrumpió la "ventana de pago" y cobrará por separado 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 smoothing.

Ejemplo práctico de smoothing: Si en el informe Fabric Capacity Metrics se muestra que el procesamiento de fondo está al 50%, esto significa que el 50% de la capacidad ya está comprometido para las próximas 24 horas. Si PAUSA el recurso de Fabric en ese momento, ese tiempo futuro que fue suavizado se COBRARÁ por separado y ese costo aparecerá en el informe de costos del portal de Azure.

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. Delay 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 de Fondo: después de 24 horas de sobrecarga acumulada, las operaciones de fondo son rechazadas.

Cuándo tiene sentido pausar Microsoft Fabric:

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

Cuándo 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 smoothing 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 accediendo 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

El cobro de Power BI Embedded y Fabric se calcula por las horas en que la capacidad estuvo encendida. Como ambos 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 (de 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 (de 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 iniciar automáticamente cuando un usuario intenta acceder a un informe fuera del horario definido, y pausar 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 actualizar modelos o visualizar 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.
  • Preagregar datos antes de importarlos a Power BI.
  • Optimizar el código M (Power Query) asegurando que el Query Folding esté ocurriendo.
  • Utilizar 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 cargas de trabajo en múltiples capacidades.

Riesgos de soluciones que violan la licencia

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 licencia de Microsoft y puede resultar en penalizaciones contractuales, auditorías, suspensión de servicios y riesgos legales.

2. Multi-tenant SaaS 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 dueño 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 (vía logs, navegador, proxy o DevTools), cualquier persona tiene acceso a todos los informes de todos los clientes en ese tenant. Si alguien deja 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 dueño 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 vía Entra ID y la segregación multi-tenant arquitectónica como mejores prácticas para escenarios corporativos.

Riesgos de cumplimiento y LGPD/GDPR:

  • El cliente deja de ser el Data Controller y el Tenant Owner, 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.
  • Inviabiliza certificaciones como SOC 2, ISO 27001, auditorías de licencia Microsoft y controles de RBAC, Purview y Microsoft Defender.

Riesgos de licencia:

  • Violación de los Microsoft Product Terms y del contrato de licencia.
  • 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.

Si el proveedor del portal de Embedding que utiliza no es transparente sobre la arquitectura de aislamiento, pregunte: ¿cada cliente tiene su propio tenant de Microsoft, su propio Service Principal y su propia capacidad dedicada? Si la respuesta es "no", evalúe cuidadosamente los riesgos antes de continuar utilizando la solución. La arquitectura correcta es App Owns Data con Service Principal por tenant de cliente.

Errores comunes al implementar el modelo App Owns Data

Además de las prácticas prohibidas anteriormente, 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 licencia, 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 embed tokens.
  • 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 de la licencia.

Riesgos adicionales de seguridad: necesidad de almacenar usuario y contraseña (con riesgo de filtración), 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 embed. 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 para usar. Necesita desarrollar su propia aplicación web 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 vía 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 gratuitamente, 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 requiere:

  • 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 requiere 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, vía 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 ni 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 sobre el cumplimiento de 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 parte del portal. Todos los datos permanecen almacenados 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 viajan a través del 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 dificultades serias para demostrar el cumplimiento de la LGPD en una eventual auditoría.

¿Crear un portal propio o contratar una solución lista para usar?

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 embed 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 aplicaciones, 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-idioma, 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 se autentica utilizando el client_id + secret del Service Principal del cliente, genera el token de embed con alcance mínimo y aplica seguridad y RLS según las configuraciones del cliente.
  • No hay alojamiento de los informes en el tenant de Power Tuning; el acceso y el embed ocurren utilizando el Service Principal del tenant del propio cliente.

Esto cumple al 100% con el modelo "App owns data" documentado por Microsoft, y garantiza que, aunque sea un portal multi-cliente, cada tenant tiene su propia instancia de embed 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 en 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 mediante certificados SSL (HTTPS).
  • Claves de acceso a Power BI almacenadas cifradas con RSA-OAEP, con claves individuales por cliente en Azure Key Vault.

Algunos de los recursos disponibles en la plataforma:

  • Reducción de hasta un 90% en los costos de licenciamiento de Power BI.
  • Los usuarios acceden con cualquier correo electrónico (corporativo, Gmail, etc.), sin cuenta de Microsoft, sin instalar aplicaciones.
  • Todos los workspaces pasan a ser Premium, liberando hasta 48 actualizaciones por día, datasets de más de 1 GB, XMLA Endpoint, tablas híbridas, pipelines de implementación y control de versiones con Git.
  • White-label completo: identidad visual de su empresa o de cada cliente, incluyendo URL personalizada.
  • Multi-idioma (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 pasan 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 a 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 tras 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 proporcionados por Microsoft).

Power Embedded está disponible en el Azure Marketplace, lo que indica que Microsoft ha validado y aprobado la solución. El producto es desarrollado por Power Tuning, empresa Microsoft Solutions Partner desde 2018, una de las líderes en ventas de Azure en Brasil.

No es obligatorio utilizar 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

El 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 un recurso de Microsoft; no es el nombre de una plataforma específica.
  • El modelo correcto para eliminar licencias por usuario es el 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 F SKU o A SKU 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 riesgos serios de seguridad, cumplimiento y licenciamiento.
  • Microsoft no proporciona un portal de visualización listo para usar. Usted necesita desarrollarlo o contratar uno.
  • En Fabric, pausar la capacidad no siempre genera ahorros. 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). Durante este período, puede 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 encuentran los enlaces principales para consulta y profundización:

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

¡Un gran saludo y hasta la próxima!