Power BI Embedded: como pôr o painel no portal do cliente sem expor os dados

O pedido chega de várias formas: “queria que o cliente visse o painel dele na área logada do site”, “o franqueado precisa acompanhar as vendas sem pedir planilha”, “o parceiro quer o relatório dentro do nosso portal”. Em todas, o painel já existe no Power BI e falta só um jeito de mostrá-lo a gente de fora da empresa.

O caminho que aparece primeiro no menu é o Publicar na Web, que gera um código de inserção em dois cliques. É também o caminho errado para esse caso. Este artigo separa as três formas de levar um painel para fora do serviço do Power BI, explica como o Power BI Embedded funciona por dentro, quem precisa de licença em cada cenário e como a capacidade é cobrada, sempre pela documentação da Microsoft.

O que é o Power BI Embedded?

É a oferta do Azure que fornece a capacidade para inserir conteúdo do Power BI em aplicativos próprios. A Microsoft descreve o produto como voltado a ISVs e desenvolvedores que querem inserir visuais em seus aplicativos, e ele é vendido em SKUs da família A.

Na prática, o Power BI continua sendo onde o relatório é criado e onde o modelo de dados mora. O que muda é a porta de entrada: em vez de abrir o app.powerbi.com, o usuário vê o relatório dentro do seu site, do seu portal ou do seu sistema, com o seu login e a sua identidade visual.

Vale separar dois nomes que se confundem. Análise integrada do Power BI é o conjunto de técnicas de inserção, que também funciona com capacidades Premium e Fabric. Power BI Embedded é o produto específico do Azure, com SKU A, que a Microsoft associa à solução de inserir para clientes.

Quais são os jeitos de colocar um painel do Power BI num site?

São três caminhos, e eles respondem a perguntas diferentes: quem vai ver, como essa pessoa prova quem é e se ela precisa de licença.

Microsoft Learn: Capacidade e SKUs na análise integrada do Power BI, Visão geral da análise integrada e Publicar na Web (consultados em 12/11/2026).

Existe ainda a inserção segura, a opção sem código do serviço do Power BI para colocar o relatório num portal interno por URL ou iFrame. Ela pede que cada visualizador tenha a licença adequada, então resolve intranet e SharePoint, não portal de cliente.

Por que o Publicar na Web não serve para portal de cliente?

Porque ele foi feito para o contrário: publicar dado que pode ser público, como um indicador num blog ou uma pesquisa aberta. O aviso da Microsoft é direto.

Esconder o código de inserção atrás da área logada do seu site não muda isso. O link continua público: quem tiver o endereço, porque copiou do código-fonte da página ou recebeu de alguém, abre o relatório sem passar pelo seu login. E a falta de suporte à segurança em nível de linha impede o único mecanismo que faria cada cliente ver só os dados dele.

A mesma página lista outras limitações que pesam num portal: não há suporte para relatórios com DirectQuery nem com conexão dinâmica ao Analysis Services, os dados ficam em cache por uma hora a partir da consulta e a Microsoft não recomenda o recurso para dados que precisam ser atualizados com frequência. Só é possível criar um código de inserção por relatório.

O controle fica com o administrador do Power BI, na configuração de locatário Publicar na Web, que pode liberar o recurso para toda a organização ou só para grupos de segurança. Já discutimos o lado das licenças desse atalho no artigo sobre quem paga licença Pro só para ver o painel, e o problema equivalente em outra ferramenta no texto sobre o perfil público do Tableau.

Como funciona o Power BI Embedded por dentro?

No cenário de inserir para clientes, o usuário final nunca conversa com o Power BI diretamente. Quem conversa é o seu aplicativo, e isso muda toda a arquitetura de segurança.

1. O cliente entra no seu portal com o login que você já usa. Ele não precisa de conta Microsoft nem de licença do Power BI.
2. O back-end do aplicativo se autentica no Power BI de forma não interativa, com uma entidade de serviço (o registro do aplicativo no Microsoft Entra ID) ou com um usuário mestre.
3. O aplicativo pede um token de inserção para aquele relatório e, quando o modelo tem segurança em nível de linha, informa no token a identidade do cliente.
4. O navegador abre o relatório com o token, pelo SDK JavaScript do Power BI, já filtrado para aquele cliente.

Dois pontos da documentação de segurança merecem atenção. Primeiro, atribuir usuários a funções dentro do serviço do Power BI não afeta a segurança em nível de linha quando se usa token de inserção no cenário do aplicativo: o que vale é a identidade enviada no token. Segundo, quando o aplicativo fornece uma identidade, as permissões dessa identidade são aplicadas aos dados, mesmo que a conta do aplicativo seja administradora do workspace.

Para separar clientes, a Microsoft descreve três padrões. Base pequena pode usar um único modelo com RLS dinâmico. Clientes grandes, com departamentos, combinam RLS estático e dinâmico, às vezes com segurança em nível de objeto, que esconde tabelas e colunas. E operações com milhares de clientes podem dar a cada um seu próprio workspace e modelo, com perfis de entidade de serviço.

Quem precisa de licença para ver o painel inserido?

Depende do cenário e do tamanho da capacidade, e é aqui que muito projeto nasce com custo errado.

A consequência prática: comprar uma SKU A e montar um portal em que cada cliente entra com conta Microsoft é pagar duas vezes, pela capacidade e por uma licença Pro ou PPU para cada leitor. Se o público é externo, o desenho certo é o do aplicativo que possui os dados.

Do outro lado, quem publica sempre precisa de licença. A Microsoft exige Pro ou PPU para publicar conteúdo num workspace, com uma exceção: a entidade de serviço pode publicar pela API REST de importação sem licença Pro ou PPU.

Qual a diferença entre SKUs A, EM e F do Power BI?

As três famílias compram capacidade, mas vêm de ofertas diferentes, são cobradas de jeitos diferentes e abrem cenários diferentes. A tabela de equivalência da Microsoft ajuda a comparar o tamanho.

Microsoft Learn, Capacidade e SKUs na análise integrada do Power BI, tabela de capacidade de computação (consultado em 12/11/2026). A tabela original segue até F8192.

• SKU A (Power BI Embedded): oferta do Azure, cobrança por hora, sem compromisso, com escala e pausa. Atende inserir para clientes, para a organização e aplicativos do Microsoft 365, mas não a inserção segura por URL.
• SKU EM (Power BI Premium): oferta do Office, cobrança mensal com compromisso anual, para inserir em aplicativos da Microsoft e de terceiros.
• SKU F (Microsoft Fabric): oferta do Azure que reúne Power BI e outras cargas de dados. A partir da F64, libera o consumo por usuários gratuitos no cenário da organização. Já explicamos o que acontece no fim da avaliação em o que some quando o teste do Fabric acaba.

A escolha, portanto, começa pelo público. Portal só para clientes externos aponta para SKU A ou F pequena. Se a mesma capacidade também vai servir milhares de leitores internos sem licença, a conversa passa a ser F64 ou superior.

Quanto custa o Power BI Embedded?

O preço por hora de cada SKU está na página de preços do Azure e muda por região e moeda, por isso não vale copiar número de terceiros. O que a documentação deixa claro é o modelo de cobrança, e ele é o que mais pesa no orçamento.

Cobrança por hora com pausa abre uma economia que a assinatura mensal não tem. Um portal B2B usado em horário comercial pode ter a capacidade pausada à noite e no fim de semana, por automação. O cuidado é que, pausada, a capacidade não atende ninguém: o cliente que abrir o portal às 22h verá erro.

Na conta total entram ainda: a licença Pro ou PPU de quem publica, o desenvolvimento do back-end que gera tokens, a modelagem da segurança em nível de linha e o tempo de alguém para monitorar o uso da capacidade. O orçamento que considera só a SKU costuma ser o que estoura.

Como implantar o Power BI Embedded na prática?

1. Feche o inventário de quem vê o quê

Liste os públicos (clientes, franqueados, parceiros), o que cada um pode ver e qual campo do modelo identifica cada um. Essa lista vira a regra de segurança em nível de linha.

2. Modele a segurança antes do visual

Crie as funções de RLS no modelo e teste com a opção de exibir como função no Power BI Desktop. Painel bonito com segurança improvisada é o que vaza dado de um cliente para outro.

3. Registre o aplicativo e crie a entidade de serviço

No Microsoft Entra ID, registre o aplicativo e dê a ele acesso aos workspaces de produção. A entidade de serviço é preferível ao usuário mestre porque não depende da senha de uma pessoa.

4. Desenvolva com token de avaliação

Os tokens gratuitos com licença Pro servem para construir e testar. Eles não servem para produção, e a barra de versão de avaliação no topo do relatório lembra disso.

5. Contrate a capacidade e atribua o workspace

Escolha a SKU pelo volume de uso esperado, atribua o workspace à capacidade e confira em Configurações do workspace, Informações de licença, qual capacidade está ativa.

6. Desligue o atalho público

Revise os códigos de Publicar na Web existentes, exclua os que expõem dado de cliente e peça ao administrador para restringir a configuração de locatário a um grupo de segurança.

Quais os erros mais comuns com Power BI Embedded?

• Usar Publicar na Web atrás de login achando que a área restrita do site protege o relatório.
• Comprar SKU A e autenticar o cliente com conta Microsoft, o que exige licença Pro ou PPU por leitor.
• Deixar a segurança em nível de linha para depois e descobrir o vazamento quando o primeiro cliente vê o número do outro.
• Confiar nas funções atribuídas no serviço, que não afetam a RLS quando o acesso é por token no cenário do aplicativo.
• Entrar em produção com token de avaliação, com a barra “Versão de avaliação gratuita” na tela do cliente.
• Pausar a capacidade sem avisar quem usa o portal fora do horário.
• Depender do usuário mestre e perder o portal quando a senha da pessoa muda ou ela sai da empresa.

Como medir se o portal com Power BI Embedded valeu a pena?

1. Uso: quantos clientes abrem o painel por semana e quanto tempo ficam nele.
2. Demanda evitada: quantos pedidos de relatório por e-mail ou planilha deixaram de chegar ao time.
3. Custo por cliente ativo: capacidade, licenças de quem publica e manutenção, divididos pelos clientes que usam.
4. Uso da capacidade: picos e ociosidade, para decidir entre escalar, reduzir ou pausar em horários sem uso.
5. Incidentes de acesso: zero é a meta; qualquer caso de cliente vendo dado alheio volta para a etapa da RLS.

Defina esses números antes do lançamento. Sem a contagem de pedidos manuais do mês anterior, não há como mostrar que o portal tirou trabalho do time.

Por onde começar hoje?

O primeiro passo custa zero: revise os códigos de Publicar na Web e exclua os que mostram dado de cliente. O segundo é escrever em uma página quem precisa ver o quê, porque é essa lista que decide o cenário, a SKU e a regra de segurança.

Se o portal faz parte de uma estratégia maior de dados, vale olhar também o que está antes do painel: fontes, métricas e quem decide com elas. O diagnóstico de marketing gratuito da Alliance leva cerca de 30 minutos e avalia a maturidade em dados e mensuração. E, para desenhar o modelo, a segurança e a inserção do painel no seu portal, a equipe de BI e dashboards da Alliance faz o projeto de ponta a ponta.