Embedding Analytics no Power BI: Reduza Custos e Personalize a Experiência do Cliente

Fala pessoal!

Se você trabalha com Power BI e já precisou compartilhar relatórios com dezenas ou centenas de usuários, especialmente externos à sua organização, já deve ter sentido na pele o peso das licenças individuais. Power BI Pro, Premium por Usuário (PPU)... a conta cresce rápido. Mas existe uma alternativa oficial da Microsoft, totalmente legal e muito mais econômica: o Embedding Analytics.

Neste artigo, vou cobrir todo o assunto do zero: o que é o Embedding Analytics, como ele funciona, quais são os modelos de licenciamento disponíveis, as capacidades dedicadas envolvidas, os conceitos técnicos de smoothing, bursting e throttling do Fabric, os riscos de soluções que fogem do modelo oficial, as perguntas frequentes e como você pode implementar tudo isso de forma segura e eficiente na sua empresa.

O Desafio de Distribuir Relatórios Power BI

No modelo padrão do Power BI, qualquer pessoa que queira visualizar um relatório publicado no serviço (app.powerbi.com) precisa de uma conta Microsoft e, na grande maioria dos cenários, de uma licença Power BI Pro ou Premium por Usuário (PPU). Isso cria uma barreira real em três frentes:

• Custo elevado: Cada usuário que precisa acessar relatórios tem um custo mensal de licença. Para equipes internas pequenas, tudo bem. Mas quando você precisa compartilhar com clientes, parceiros, revendedores ou franqueados, o custo escala linearmente, e rápido.
• Experiência genérica: O portal do Power BI foi criado para o time de BI da empresa, não para o cliente final. A identidade visual é da Microsoft, a navegação é técnica e muitas vezes o usuário não tem o contexto necessário para se virar sozinho.
• Limitações de acesso externo: Usuários externos à sua organização precisam ser adicionados como convidados no Azure AD, o que traz complexidade de gestão e, muitas vezes, resistência por parte do departamento de TI.

É justamente para resolver esses problemas que a Microsoft criou o recurso de Análise Integrada do Power BI, mais conhecido como Embedding Analytics.

O que é Embedding Analytics no Power BI?

O Embedding Analytics (ou Análise Integrada) é um recurso oficial da Microsoft que permite incorporar relatórios, dashboards e outros artefatos do Power BI diretamente em aplicações web e portais customizados, de forma segura, controlada e sem exigir que os usuários finais tenham licenças individuais do Power BI.

Na prática, o Embedding Analytics permite que você construa (ou contrate) um portal web próprio, onde os relatórios do Power BI aparecem embutidos, como se fizessem parte da sua aplicação. O usuário final acessa o seu portal, faz login com as credenciais que você definir (email corporativo, Gmail, ou qualquer outro método) e visualiza os relatórios, sem nem saber que o Power BI está por trás de tudo.

Embedded, "Publicar na Web" e "Inserir Relatório": quais as diferenças?

Embora as três opções permitam embeddar relatórios em websites, SharePoint, e-mail, Teams e outros canais, elas são muito diferentes em segurança, custo e controle. Veja o comparativo:

1. Publicar na Web

É a forma mais simples, mas também a mais perigosa. O relatório fica totalmente público, sem qualquer controle de acesso. Qualquer pessoa que tenha o link pode visualizar os dados, inclusive o Google, que indexa esses relatórios em buscas simples, mesmo que o link nunca tenha sido publicado em lugar algum. Não há autenticação, não há RLS, não há OLS, não há auditoria de quem acessou. Use apenas para dados realmente públicos, como resultados de eleições ou índices econômicos abertos.

Mesmo que você tente bloquear o acesso com uma senha no portal que hospeda o iframe, esse tipo de proteção é facilmente contornado em poucos segundos usando o Developer Tools do navegador. A pessoa terá acesso irrestrito aos dados publicados no relatório.

2. Inserir Relatório (via código HTML/iFrame)

Essa opção permite incorporar o relatório em sites, SharePoint, Teams, etc., mantendo todos os controles de segurança do Power BI: permissões, RLS, OLS e auditorias de acesso. Mas o problema é claro: todos os usuários que forem acessar o relatório inserido dessa forma ainda precisam de licença Pro ou PPU ativa. Além disso, você não consegue controlar os elementos do relatório via linguagem de programação, como criar ou editar visuais dinamicamente, trocar temas, criar ou excluir páginas, etc.

3. Embedding Analytics (Análise Integrada via capacidade dedicada)

É o recurso mais completo. Permite visualizar relatórios de forma segura, com RLS, OLS, controle de permissões, bloqueios por IP, auditoria de acessos e controle programático total (filtros via código, troca de tema, navegação de páginas, criação e edição de visuais), sem que os usuários precisem de licença do Power BI. O licenciamento ocorre via capacidade dedicada (Fabric ou Power BI Embedded), não por usuário. É a única opção que entrega todos esses benefícios ao mesmo tempo.

Os Dois Modelos de Inserção de Relatórios

Dentro do Embedding Analytics, a Microsoft define dois modelos de inserção. Escolher o errado pode significar tanto uma experiência ruim quanto uma violação do contrato de licenciamento:

User Owns Data: Inserir para a Organização

Este é o modelo mais simples e direto. Cada usuário final se autentica no Power BI com sua própria conta corporativa, via Entra ID (Azure AD).

O aplicativo age como uma ponte, mas a experiência é personalizada por usuário e cada pessoa precisa de uma licença Power BI Pro (ou acesso a um workspace em capacidade Premium).

Cenários corretos para este modelo:

• Aplicativos internos para colaboradores de uma empresa.
• Soluções corporativas que seguem políticas internas de segurança e identidade.
• Usuários internos autenticados no Entra ID com licenciamento Pro ou P SKU.

Este modelo não é adequado para clientes externos ou para cenários onde o objetivo é eliminar o custo de licenças por usuário. Não tente usar User Owns Data com usuários externos ou compartilhar credenciais e tokens manualmente.

App Owns Data: Inserir para seus Clientes

Este é o modelo ideal para ISVs (Independent Software Vendors) e soluções SaaS, e é o que viabiliza a grande redução de custos.

Aqui, quem se autentica no Power BI não é o usuário final, mas sim a própria aplicação, usando um Service Principal (uma identidade técnica no Azure AD). A aplicação gera um token de embed com escopo mínimo para cada sessão e entrega o relatório renderizado ao usuário, que nunca precisa ter conta Microsoft ou licença Pro.

As características deste modelo:

• Os usuários finais não precisam de licença Power BI Pro ou PPU.
• Os usuários finais não precisam de conta Microsoft (podem usar Gmail, email corporativo próprio, login com senha, SSO corporativo, etc.).
• O controle de permissões, RLS e visibilidade é feito dentro da aplicação, via token de incorporação.
• Requer obrigatoriamente uma capacidade dedicada (Fabric ou Power BI Embedded) em produção.
• O conteúdo dos relatórios precisa estar em um workspace não-pessoal, associado à capacidade.
• Usuários podem até criar e editar relatórios pelo portal sem precisar de licença Pro, conforme documentado pela Microsoft.

Posso Usar Licença Pro ou PPU para Embeddar em Produção?

Esta é uma das dúvidas mais frequentes, e a resposta precisa ser direta: não. Tecnicamente é possível gerar tokens de embed com uma conta Pro ou PPU (chamada de "Master Account"), mas a própria Microsoft é explícita na documentação oficial:

"Os tokens incorporados com licença Pro ou Premium por usuário (PPU) destinam-se a testes de desenvolvimento, portanto, uma conta mestra ou Service Principal do Power BI só pode gerar um número limitado de tokens. Adquira uma capacidade para incorporação em um ambiente de produção. Não há limite para quantos tokens incorporados você pode gerar ao comprar uma capacidade."

Fonte: Documentação oficial Microsoft: "Mover a aplicação incorporada para produção"

Em outras palavras, usar Pro/PPU para embeddar é permitido apenas em ambiente de desenvolvimento e testes. Em produção, com usuários reais acessando, a Microsoft exige uma capacidade dedicada.

Usar licença Pro para isso em produção:

• Viola os termos de uso do Power BI e os Microsoft Product Terms.
• Pode resultar em multas, sanções e auditorias de compliance pela Microsoft.
• Tem um limite de tokens que, quando atingido, faz os relatórios pararem de carregar.
• Cria riscos sérios de segurança, pois o uso de Pro/PPU + embedding externo pode ser explorado como vetor de exfiltração de dados. Se um token vazar, qualquer pessoa pode acessar todos os relatórios de todos os clientes que estão naquele tenant.
• O uso de Master Account exige armazenar login e senha, o que cria risco de vazamento de credenciais.

Capacidades Dedicadas: o que São e quais as Opções?

As capacidades dedicadas são recursos computacionais exclusivos, provisionados no Azure, que licenciam o uso do Embedding Analytics e permitem gerar tokens de embed de forma ilimitada.

Sem uma capacidade contratada, usando apenas uma conta Pro ou PPU, você tem uma quantidade limitada de tokens. Após um tempo, esse limite é atingido e o Power BI não permite mais inserir relatórios.

Por estes motivos, ter uma capacidade é obrigatório para qualquer uso em produção.

Existem três tipos de capacidades:

Microsoft Fabric (F SKUs): a opção mais moderna

As capacidades Fabric são a geração mais nova e completa. Além de suportar o Embedding Analytics, elas habilitam todos os outros workloads do Microsoft Fabric: Data Engineering, Data Science, Data Warehouse, Real-Time Analytics e muito mais. São a opção recomendada para novos projetos.

Vantagens dos F SKUs:

• Cobradas por hora de execução (granularidade por segundo).
• Podem ser pausadas a qualquer momento, interrompendo a cobrança.
• Mais novas, mais flexíveis e com mais recursos integrados ao ecossistema Microsoft.
• Começam a partir de F2 (menor e mais barato), reduzindo o custo de entrada.
• Período de avaliação gratuita de 60 dias disponível pela Microsoft (F64), permitindo rodar uma PoC completa sem custo de capacidade.
• Qualquer tamanho de F SKU suporta Embedding Analytics, conforme documentado pela Microsoft na página "Entender as licenças do Microsoft Fabric".

Atenção: o Fabric usa os conceitos de smoothing, bursting e throttling, que alteram a lógica simples de "pausar = economizar". Isso será explicado em detalhes mais adiante neste artigo.

Power BI Embedded (A SKUs): opção pay-as-you-go

Disponíveis desde 2017, as capacidades A SKUs (A1 a A6) são provisionadas diretamente no Azure e cobradas por hora de uso. São a opção mais tradicional, mais estável e confiável para cenários de Embedding.

Dependendo da região e do tamanho, podem ser bem mais baratas que os F SKUs (Fabric) para determinados perfis de uso.

Características:

• Cobradas por hora de execução. Pausar a capacidade suspende completamente a cobrança.
• Mais previsíveis para uso contínuo, pois não têm a complexidade do smoothing do Fabric.
• O cálculo de economia é simples: quantidade de horas ligada × custo por hora da capacidade.
• Amplamente suportadas por todas as ferramentas e portais de Embedding do mercado.

Premium por Capacidade (P SKUs): descontinuado

As capacidades P SKUs eram a versão premium do Power BI antes do Fabric. Foram descontinuadas pela Microsoft e não estão mais disponíveis para novas contratações. O custo inicial era de aproximadamente R$ 32.000/mês (tier P1), o que as tornava inviáveis para a maioria das empresas. Os P SKUs foram substituídos pelos F SKUs do Fabric.

Se você já tem uma capacidade Premium contratada (tier P), ela inclui as funcionalidades de Embedded desde o tier P1, e pode ser usada com portais de Embedding normalmente.

Preciso de F64 para Usar o Embedding Analytics sem Licença Pro?

Esta é uma das maiores confusões no mercado, então vamos esclarecer de uma vez por todas.

É verdade que usuários podem acessar relatórios diretamente pelo portal do Power BI (app.powerbi.com) sem licença Pro, desde que o workspace esteja associado a uma capacidade F64 ou superior (equivalente ao antigo P1). Esse é um benefício específico e restrito ao acesso direto pelo portal da Microsoft.

Mas quando falamos de Embedding Analytics, as regras são completamente diferentes:

• Qualquer tamanho de F SKU (F2, F4, F8, F16...) permite visualizar relatórios via portal de Embedding sem precisar de licença Pro por usuário.
• Qualquer SKU de Power BI Embedded (A1 a A6) também funciona para esse cenário.
• A Microsoft documenta explicitamente na página "Entender as licenças do Microsoft Fabric": para o cenário "o aplicativo possui dados" (App Owns Data), qualquer SKU F pode ser utilizado e os usuários finais não precisam de licença.
• A página "Capacidade e SKUs na análise integrada do Power BI" confirma: "A análise integrada do Power BI requer uma capacidade (A, EM, P ou F SKU) para publicar conteúdo inserido do Power BI."

Ou seja, você não precisa de F64 para eliminar a necessidade de licenças Pro dos seus usuários. Você precisa de qualquer capacidade dedicada, combinada com um portal de visualização que use o modelo App owns data. A diferença do F64 é exclusiva para o cenário de acesso direto ao app.powerbi.com sem licença individual.

Como Funciona a Redução de Custos na Prática?

A mecânica da redução de custos é simples: ao invés de cada usuário acessar o portal do Power BI (que exige licença individual), eles acessam o portal de Embedding, que não requer conta Microsoft nem licença Pro. A capacidade contratada serve a todos, independentemente de quantos usuários existam. O custo da capacidade não escala com o número de usuários.

Vamos a um exemplo concreto. Imagine uma empresa com 200 usuários que precisam acessar relatórios do Power BI:

Cenário atual, com Pro por usuário: 200 licenças × ~R$ 95/mês = R$ 19.000/mês

Cenário com Embedding Analytics:

• Capacidade F8 (suficiente para muitos cenários de médio porte): ~R$ 2.000 a R$ 3.000/mês
• Portal de visualização (como o Power Embedded): ~R$ 5/usuário/mês = R$ 1.000/mês para 200 usuários
• Licenças Pro apenas para quem publica relatórios (ex.: 5 desenvolvedores): ~R$ 475/mês
• Total estimado: R$ 3.475 a R$ 4.475/mês

Isso representa uma economia entre 75% e 80%. E quanto maior o número de usuários, maior a economia percentual, já que o custo da capacidade é fixo e não cresce com o número de usuários.

A partir de quantos usuários vale a pena?

Para licenças Power BI Pro, em empresas onde os relatórios não precisam ficar disponíveis 24h por dia, a partir de aproximadamente 15 usuários já é possível economizar em torno de 50% em relação ao custo das licenças Pro. Se você usa licença Premium por Usuário (PPU), a economia pode chegar a 76% com apenas 15 usuários.

Em cenários onde os relatórios precisam estar disponíveis 24h por dia (capacidade ligada o tempo todo, sem pausas), a partir de aproximadamente 30 usuários o Embedding Analytics se torna mais vantajoso financeiramente.

Pausar a Capacidade Reduz o Custo?

Uma dúvida muito comum: se eu pausar a capacidade fora do horário comercial, economizo?

A resposta depende do tipo de capacidade utilizada, e no caso do Fabric, também do seu padrão de uso:

Para Power BI Embedded (A SKUs): Pausar sempre reduz o custo, pois não há smoothing. A cobrança é estritamente por hora de uso. O cálculo de economia é simples e previsível: quantidade de horas ligada × custo por hora. Faz sentido pausar sempre que não houver relatórios em uso.

Para Microsoft Fabric (F SKUs): A situação é mais complexa. A economia ao pausar nem sempre acontece, por causa dos conceitos de smoothing, bursting e throttling.

Smoothing, Bursting e Throttling: entenda o que são

Smoothing (Suavização):

A suavização permite que cargas de trabalho usem recursos além do limite provisionado durante picos de demanda, distribuindo o consumo de recursos ao longo do tempo. Para isso, o Fabric utiliza o conceito de "pré-alocação proporcional de uso futuro". Isso permite usar a capacidade baseada em uso médio, não no pico.

Na prática:

• Quando você executa tarefas de background, como atualização de datasets, notebooks ou pipelines, o sistema amortiza e distribui o custo ao longo das próximas 24 horas.
• Para atividades interativas (navegação em relatórios), há suavização mínima de apenas 5 minutos.
• Se você pausar a capacidade antes do smoothing completar, o sistema entende que você interrompeu a "janela de pagamento" e cobrará à parte as horas que já estavam pré-alocadas. Isso pode, em alguns cenários, até dobrar o custo estimado se você considerar apenas as horas ligadas sem considerar o smoothing.

Bursting (Capacidade Elástica):

Permite que workloads usem temporariamente mais recursos do que o SKU base, melhorando o desempenho em picos. Cada SKU tem um fator de burst diferente (por exemplo, F2 pode ter burst de até 32x, F8 pode ter até 12x). Isso é útil para absorver picos sem precisar provisionar permanentemente uma capacidade maior.

Throttling (Limitação):

Ocorre quando o uso médio de CUs (Capacity Units) ultrapassa os limites suavizados do SKU. As operações em andamento não são interrompidas; a limitação se aplica apenas às próximas operações. O throttling acontece em etapas progressivas:

1. Delay Interativo: após 10 minutos de sobrecarga acumulada, as operações interativas começam a sofrer atraso.
2. Rejeição Interativa: após 60 minutos de sobrecarga acumulada, operações interativas são rejeitadas.
3. Rejeição Background: após 24 horas de sobrecarga acumulada, operações de background são rejeitadas.

Quando faz sentido pausar o Microsoft Fabric:

• Fora dos horários fixos de execução de pipelines e atualizações de dados (por exemplo, de meia-noite às 6h da manhã, quando não há atualizações agendadas).
• Quando o uso da capacidade é majoritariamente composto de ações interativas (visualização e navegação nos relatórios), com pouco ou nenhum processamento de background.
• Quando o percentual de background no relatório Fabric Capacity Metrics está baixo antes de pausar.
• Sempre analise e acompanhe o consumo da capacidade na tela de Gerenciamento de Custos do Azure. A partir do segundo dia após alterações no agendamento das pausas já é possível analisar o custo diário para verificar se realmente está ocorrendo economia.

Quando pode fazer mais sentido deixar ligado 24x7:

Em muitos cenários, especialmente quando há atualizações de dados frequentes e uso contínuo, pode fazer mais sentido contratar uma reserva de instância da Microsoft (desconto por compromisso de uso anual) e deixar a capacidade ligada o tempo todo, do que ficar pausando e potencialmente gerando cobranças de smoothing inesperadas.

O que acontece quando a capacidade está pausada:

Enquanto a capacidade estiver pausada, ninguém consegue acessar os relatórios, nem mesmo usuários com licença Pro acessando diretamente pelo portal do Power BI (app.powerbi.com). Os datasets também não são atualizados. Isso é um ponto crítico de planejamento.

Modelos de Disponibilidade: 24x7, 14x6 e 12x5

A cobrança do Power BI Embedded e do Fabric é calculada pelas horas em que a capacidade ficou ligada. Como ambas permitem pausar a capacidade, existem diferentes estratégias de disponibilidade. As mais comuns são:

• 24x7: capacidade disponível 24 horas por dia, 7 dias na semana. Sem nenhuma pausa. Cenário para operações que precisam de relatórios disponíveis a qualquer momento.
• 14x6: capacidade disponível 14 horas por dia, 6 dias na semana (segunda a sábado). Representa uma economia de 53% em relação ao 24x7. Atende a maioria dos clientes corporativos.
• 12x5: capacidade disponível 12 horas por dia, 5 dias na semana (segunda a sexta). Representa uma economia de 67% em relação ao 24x7. Adequado para empresas com uso estritamente em horário comercial.

Esses são apenas exemplos. Os horários reais são definidos conforme o perfil de uso de cada empresa. Ferramentas como o Power Embedded oferecem gerenciamento automático de pausa e inicialização da capacidade, podendo também iniciar automaticamente quando um usuário tenta acessar um relatório fora do horário definido, e pausar novamente após um período de inatividade configurável pelo administrador.

Capacidade Acima do Limite: o que Fazer?

Se o ambiente começa a apresentar sobrecargas constantes (mensagens de erro, impedimentos a atualização de modelos ou visualização de relatórios), algumas medidas podem ajudar antes de aumentar o SKU:

• Otimizar medidas DAX com alto consumo de capacidade.
• Evitar colunas calculadas e tabelas calculadas no modelo, quando possível.
• Reduzir o número de visuais por página (o recomendado é não mais que 10).
• Otimizar a modelagem dos datasets: evitar relacionamentos N:N e filtragem bidirecional.
• Identificar e remover colunas e tabelas não utilizadas no modelo.
• Pré-agregar dados antes de importá-los para o Power BI.
• Otimizar o código M (Power Query) garantindo que o Query Folding está ocorrendo.
• Utilizar carregamento incremental dos dados no lugar de atualizações completas.
• Avaliar o uso de DirectQuery ou DirectLake para volumes de dados muito grandes.
• Separar datasets grandes em capacidades diferentes, distribuindo a carga.
• Avaliar se é necessário aumentar o SKU ou dividir workloads em múltiplas capacidades.

Riscos de Soluções que Violam o Licenciamento

No mercado existem soluções de Embedding que tentam reduzir custos de formas não suportadas pela Microsoft. As duas práticas mais comuns e perigosas são:

1. Uso de licenças Pro ou PPU em produção (App Owns Data)

Conforme já explicado, Pro e PPU são estritamente para desenvolvimento e testes. Em produção, viola os termos de licenciamento da Microsoft e pode resultar em penalidades contratuais, auditorias, suspensão de serviços e riscos legais.

2. Multi-tenant SaaS com um único tenant e Service Principal compartilhado entre todos os clientes

Outra prática comum para redução de custos é consolidar múltiplos clientes em um único tenant controlado pelo fornecedor, com um único Service Principal e uma capacidade compartilhada. Nesse modelo, o cliente tem apenas um usuário para acessar e publicar relatórios, ao invés de ser o dono das informações com todos os controles de auditoria e segurança do seu próprio ambiente.

Embora tecnicamente possível, essa prática cria riscos críticos:

Riscos de segurança e isolamento:

• Isolamento inexistente: Um único Service Principal técnico para todos os clientes significa: sem segregação de identidade, sem RBAC real por cliente, sem controle de acesso granular por organização e sem Conditional Access por empresa. Qualquer erro de configuração de RLS pode expor dados de um cliente para outro.
• Comprometimento em cascata: Se o token ou a credencial vazar (via logs, browser, proxy ou DevTools), qualquer pessoa tem acesso a todos os relatórios de todos os clientes naquele tenant. Se alguém sair da empresa do fornecedor com acesso ao Service Principal, todos os clientes são comprometidos simultaneamente.
• Sem auditoria para o cliente: Quando o cliente não é dono do tenant, ele não vê os logs de acesso, não controla o Purview, não controla o Microsoft Defender for Cloud Apps e não pode provar conformidade em auditorias de LGPD/GDPR.
• Zero Trust violado: A Microsoft recomenda isolamento por tenant ou capacidade, controle de identidade via Entra ID e segregação multi-tenant arquitetural como melhores práticas para cenários corporativos.

Riscos de compliance e LGPD/GDPR:

• O cliente deixa de ser o Data Controller e o Tenant Owner, transferindo responsabilidade legal para o fornecedor sem controles adequados.
• Em GDPR/LGPD, isso pode caracterizar processamento sem controle do controlador, aumentando a responsabilidade legal da empresa contratante.
• Inviabiliza certificações como SOC 2, ISO 27001, auditorias de licenciamento Microsoft e controles de RBAC, Purview e Microsoft Defender.

Riscos de licenciamento:

• Violação dos Microsoft Product Terms e do contrato de licenciamento.
• Auditorias de compliance e multas contratuais pela Microsoft.
• Suspensão do serviço ou do tenant, impactando toda a operação da empresa.
• Risco legal e reputacional para a organização contratante.

Erros Comuns ao Implementar o Modelo App Owns Data

Além das práticas proibidas acima, existem dois padrões comuns de implementação errada que valem ser destacados:

Erro 1: Portal hospedando relatórios de clientes no tenant da ISV

• Um único workspace por cliente dentro do tenant do fornecedor.
• Uma capacidade compartilhada entre todos os clientes.
• Service Principal controlado pelo fornecedor, não pelo cliente.
• Acesso segmentado apenas por RLS ou filtros de token.
• O cliente não tem nenhum controle real sobre seus relatórios.

Riscos: violação das regras de licenciamento, possível infração contratual com a Microsoft, risco de suspensão da conta, e dados de múltiplos clientes sob controle de um único tenant (risco de segurança e privacidade).

Erro 2: Uso de Master Account com licença Pro para todos os relatórios

• A aplicação usa uma conta genérica com licença Pro para gerar embed tokens.
• Não utiliza Service Principal (prática obsoleta e não recomendada pela Microsoft).
• Não há uso de capacidade Premium dedicada.
• Usuários finais acessam sem licença, em violação do licenciamento.

Riscos adicionais de segurança: necessidade de armazenar login e senha (com risco de vazamento), tokens gerados com permissões de um usuário humano (sem autenticação granular ou escopo controlado), e se os tokens forem interceptados, qualquer pessoa pode acessar o conteúdo embutido.

O que Você Precisa para Usar o Embedding Analytics?

Para implementar o Embedding Analytics no modelo correto (App owns data), você precisa dos seguintes pré-requisitos:

• Uma capacidade dedicada: Fabric F SKU ou Power BI Embedded A SKU, contratada pelo portal do Azure diretamente com a Microsoft ou através de um parceiro Microsoft.
• Um workspace Power BI não-pessoal: Os relatórios que serão incorporados precisam estar em um workspace associado à capacidade. Workspaces pessoais não são suportados para Embedding.
• Um Service Principal: Uma identidade técnica criada no Azure AD (Entra ID) com permissões para acessar os workspaces e gerar tokens de embed. O Service Principal deve ter acesso apenas aos workspaces necessários, com permissões mínimas.
• Um portal de visualização: A Microsoft disponibiliza as APIs, mas não oferece um portal pronto. Você precisa desenvolver uma aplicação web própria ou contratar uma solução SaaS já pronta.
• Licença Pro para os desenvolvedores: Os usuários que publicam relatórios no Power BI serviço ainda precisam de licença Pro ou PPU. Apenas os usuários que visualizam pelo portal de Embedding não precisam. Uma alternativa para eliminar também essa dependência é usar o Azure DevOps para publicação automática via CI/CD.
• Conta do Azure: Para criar a capacidade, você precisa de uma conta no Azure com permissões para criar recursos. Se sua empresa não tem conta Azure, pode criá-la gratuitamente, inclusive com crédito inicial da Microsoft.

Do ponto de vista de configurações técnicas no Azure/Entra ID para instalação, tipicamente são necessários:

• Conta de usuário com permissão para criar a capacidade Fabric ou Embedded no Azure.
• Conta de usuário com permissão para criar grupos e Service Principals no Entra ID.
• Conta de usuário que possua a role "Fabric Administrator" para acessar o portal de administração do Power BI e configurar as permissões do Service Principal.

Como Funciona o Processo de Publicação dos Relatórios?

O fluxo de publicação e disponibilização de relatórios no Embedding Analytics é praticamente o mesmo que já existe no Power BI serviço tradicional. Nenhuma mudança significativa no processo de criação de relatórios é necessária:

1. O analista de BI abre o Power BI Desktop e cria ou edita o relatório normalmente.
2. O analista publica o relatório no workspace desejado no Power BI serviço (app.powerbi.com), usando sua licença Pro ou PPU.
3. O administrador do portal de Embedding importa o relatório do workspace do Power BI para o sistema.
4. O administrador atribui as permissões de acesso ao relatório, via grupos ou usuários individuais.
5. O administrador configura as regras de RLS do conjunto de dados, se necessário.
6. Os usuários acessam o relatório pelo portal de visualização, com suas credenciais configuradas na plataforma.

Os usuários finais não precisam instalar o Power BI Desktop, criar conta na Microsoft ou ter qualquer conhecimento de Power BI. Para eles, os relatórios aparecem dentro do portal da empresa, como parte da aplicação.

LGPD e Privacidade no Embedding Analytics

Um ponto frequentemente questionado é sobre a conformidade com a LGPD (Lei Geral de Proteção de Dados) e o GDPR europeu no uso de portais de Embedding. A resposta positiva depende da arquitetura utilizada.

No modelo correto (App owns data, com os relatórios no tenant do próprio cliente):

• O processo de embeddar relatórios não requer o carregamento ou leitura de nenhum dado da empresa pelo portal. Todos os dados ficam armazenados nos servidores do Power BI, no tenant da própria empresa.
• O portal apenas faz uma chamada HTTP à API do Power BI, que lê os metadados dos relatórios e modelos semânticos no tenant do cliente e exibe na tela. Os dados nunca trafegam pelo servidor do portal.
• Os únicos dados armazenados pelo portal são os nomes e e-mails dos usuários cadastrados, para gerenciamento dos acessos.
• Toda a comunicação é criptografada ponta a ponta via SSL/HTTPS.
• A empresa continua sendo a Data Controller de seus próprios dados, mantendo todos os controles de auditoria, Purview, Defender e compliance.

No modelo incorreto (tenant do fornecedor, Service Principal compartilhado), a empresa perde o controle sobre seus dados e pode ter dificuldades sérias para demonstrar conformidade com a LGPD em uma eventual auditoria.

Criar Portal Próprio ou Contratar uma Solução Pronta?

Esta é uma decisão importante. A Microsoft disponibiliza as APIs do Power BI Embedded para que qualquer empresa desenvolva seu próprio portal, mas a complexidade real de fazer isso corretamente é muito maior do que parece na documentação:

• Implementação de autenticação com Azure AD (Entra ID) e geração de tokens de embed com Service Principal.
• Gerenciamento de usuários, grupos, permissões e RLS programático.
• Interface de usuário responsiva, acessível e compatível com múltiplos navegadores e dispositivos móveis.
• Gerenciamento de servidor de aplicação, banco de dados e infraestrutura de nuvem.
• Manutenção contínua para acompanhar mudanças nas APIs da Microsoft (que são frequentes).
• Suporte técnico para usuários finais e para desenvolvedores de relatórios.
• Gerenciamento de pausa e inicialização da capacidade.
• Segurança da aplicação (pentest, gerenciamento de secrets, Azure Key Vault, etc.).

Para uma empresa com 100 usuários, um portal básico (apenas login, permissões simples e visualização) demanda facilmente 100 ou mais horas de um desenvolvedor experiente, sem contar a infraestrutura, a manutenção e a evolução contínua. Funcionalidades avançadas como IA generativa, multi-idiomas, modo TV, assinatura de relatórios por e-mail, SSO, sincronização com Entra ID, APIs externas e auditoria detalhada multiplicam esse esforço significativamente.

A alternativa é contratar uma solução SaaS já construída, com tudo isso disponível imediatamente, mantida e evoluída de forma contínua pelo fornecedor, com SLA de disponibilidade e suporte especializado.

Power Embedded: uma Plataforma Recomendada

Uma opção que eu recomendo e conheço de perto é o Power Embedded. Tive a oportunidade de acompanhar seu desenvolvimento desde o início, durante meu período na Power Tuning, e posso dizer com propriedade que é uma plataforma séria, tecnicamente sólida e com arquitetura correta do ponto de vista de licenciamento e segurança da Microsoft.

Do ponto de vista arquitetural, o Power Embedded opera no modelo App owns data com isolamento completo por cliente:

• Cada cliente tem seu próprio tenant Microsoft Entra ID.
• Cada cliente tem sua própria capacidade Premium (Power BI Embedded ou Fabric).
• Cada cliente tem seus próprios workspaces com relatórios, associados à sua própria capacidade.
• Um Service Principal é criado diretamente dentro do tenant do cliente (com consentimento deles), com permissões apenas nos workspaces usados no portal.
• O Power Embedded autentica usando o client_id + secret do Service Principal do cliente, gera o token de embed com escopo mínimo e aplica segurança e RLS com base nas configurações do cliente.
• Não há hospedagem dos relatórios no tenant da Power Tuning; o acesso e o embed ocorrem usando o Service Principal do tenant do próprio cliente.

Isso está 100% em conformidade com o modelo "App owns data" documentado pela Microsoft, e garante que mesmo sendo um portal multi-cliente, cada tenant tem sua própria instância de embed isolada.

Do ponto de vista de infraestrutura e segurança interna:

• Arquitetura baseada em recursos SaaS auto-gerenciados no Azure, com alta disponibilidade de 99,99%, failover automático e backups automáticos.
• Pentests periódicos, tanto automatizados quanto manuais por especialistas de segurança contratados.
• Todo o ambiente de nuvem protegido pelo Microsoft Defender for Cloud.
• Acesso aos recursos do Azure bloqueado para internet, acessível apenas via VPN.
• Comunicação criptografada via certificados SSL (HTTPS).
• Chaves de acesso ao Power BI armazenadas criptografadas com RSA-OAEP, com chaves individuais por cliente em Azure Key Vault.

Alguns dos recursos disponíveis na plataforma:

• Redução de até 90% nos custos de licenciamento Power BI.
• Usuários acessam com qualquer email (corporativo, Gmail, etc.), sem conta Microsoft, sem instalar aplicativos.
• Todos os workspaces passam a ser Premium, liberando até 48 atualizações por dia, datasets acima de 1 GB, XMLA Endpoint, tabelas híbridas, pipelines de implantação e versionamento com Git.
• White-label completo: identidade visual da sua empresa ou de cada cliente, incluindo URL personalizada.
• Multi-idiomas (6 idiomas suportados).
• Sincronização automática de usuários e grupos via Entra ID (SSO).
• IA generativa (Power Pilot): perguntas em linguagem natural diretamente sobre os dados, com geração de tabelas e gráficos dinâmicos.
• RLS, OLS e auditorias detalhadas de login e acesso.
• Modo TV para relatórios passando automaticamente em painéis de monitoramento.
• Gerenciamento automático da capacidade: liga quando há acesso, desliga por inatividade configurável.
• Exportação em CSV, Excel, PDF, imagem e PowerPoint.
• APIs para automação e integração com sistemas externos.
• Relatórios responsivos: suporte nativo a layout mobile, sem necessidade de instalar aplicativos.
• Implantação em até 16 horas úteis após aprovação comercial, instalação de 20 a 60 minutos.
• 30 dias de avaliação gratuita (além dos 60 dias gratuitos de capacidade F64 disponibilizados pela Microsoft).

Não é obrigatório usar o Power Embedded especificamente. O importante é que qualquer solução que você use respeite a arquitetura correta: App owns data, Service Principal por tenant de cliente, capacidade dedicada por cliente e isolamento total entre clientes. Mas se você quer uma opção pronta, testada em produção, com suporte especializado e atualizada constantemente, o Power Embedded é a minha recomendação.

Considerações Finais

O Embedding Analytics é uma das funcionalidades mais poderosas e subutilizadas do ecossistema Power BI. Ele resolve três problemas ao mesmo tempo: reduz custos de licenciamento, melhora a experiência do usuário final e aumenta o controle de segurança sobre quem acessa o quê.

Os pontos mais importantes para lembrar:

• Embedding Analytics é um recurso da Microsoft; não é o nome de uma plataforma específica.
• O modelo correto para eliminar licenças por usuário é o App owns data, com capacidade dedicada.
• Pro e PPU são para desenvolvimento e testes; em produção, a Microsoft exige capacidade dedicada.
• Você não precisa de F64 para usar Embedding Analytics sem licença por usuário. Qualquer F SKU ou A SKU funciona.
• Os desenvolvedores que publicam relatórios ainda precisam de licença Pro. Os usuários que visualizam pelo portal de Embedding, não.
• Soluções que compartilham um único tenant e Service Principal entre vários clientes criam riscos sérios de segurança, compliance e licenciamento.
• A Microsoft não fornece um portal de visualização pronto. Você precisa desenvolver ou contratar um.
• No Fabric, pausar a capacidade nem sempre gera economia. Entenda o smoothing antes de definir a estratégia de pausa.
• Com modelos de disponibilidade como 14x6 ou 12x5, é possível economizar de 53% a 67% sobre o custo de uma capacidade 24x7.
• A partir de apenas 15 usuários Pro, o Embedding Analytics já pode ser mais econômico.

Se você está avaliando implementar essa estratégia na sua empresa, recomendo começar pelo período de avaliação gratuita de 60 dias do Microsoft Fabric (F64). Nesse período, você consegue rodar toda a prova de conceito e medir o consumo real de capacidade do seu ambiente antes de definir qual SKU contratar em produção.

Referências Oficiais

Todo o conteúdo técnico deste artigo é embasado na documentação oficial da Microsoft. Abaixo estão os principais links para consulta e aprofundamento:

• Análise integrada do Power BI — Microsoft Learn — Visão geral oficial do Embedding Analytics, modelos de inserção e requisitos de licenciamento.
• Inserir para seus clientes (App Owns Data) — Microsoft Learn — Detalhamento do modelo App Owns Data com Service Principal.
• Inserir para a organização (User Owns Data) — Microsoft Learn — Detalhamento do modelo User Owns Data com autenticação por usuário.
• Mover para produção (Power BI Embedded) — Microsoft Learn — Documentação oficial que confirma que tokens com Pro/PPU são exclusivos para desenvolvimento e que uma capacidade é obrigatória em produção.
• Capacidade e SKUs na análise integrada do Power BI — Microsoft Learn — Tabela comparativa de SKUs, requisitos de licenciamento por cenário de embedding e confirmação de que o App Owns Data não exige licença dos usuários finais.
• Perguntas frequentes sobre o Power BI Embedded — Microsoft Learn — FAQ técnico oficial, incluindo limites de tokens por tipo de licença.
• Incorporar conteúdo do Power BI com entidade de serviço — Microsoft Learn — Como configurar e usar Service Principal no modelo App Owns Data.
• Cenários de uso: inserir para clientes — Microsoft Learn — Guia de planejamento de implementação com requisitos de licenciamento para o modelo de inserção para clientes.
• Entender as licenças do Microsoft Fabric — Microsoft Learn — Detalhamento completo dos SKUs F, cenários de embedding por tipo de SKU e requisitos de licenciamento por usuário.
• Compute capacity smoothing and throttling in Microsoft Fabric — Microsoft Learn — Documentação técnica sobre smoothing, bursting e throttling em capacidades Fabric.

Bom pessoal, espero que este artigo tenha ajudado a esclarecer o Embedding Analytics no Power BI de forma completa e prática.

Um grande abraço e até mais!