Quem pode ver o quê: controle de acesso no Power BI sem travar o time

Open Mind IA · 4 de setembro de 2026 · 11 min de leitura

Chega o dia em que o dashboard fica pronto. Os números batem com o sistema, os gráficos carregam rápido, a diretoria aprova. Aí alguém faz a pergunta que trava a reunião: "posso liberar isso para a equipe comercial inteira?" O silêncio que vem em seguida costuma durar alguns segundos. É que no mesmo relatório em que o vendedor veria a própria carteira, ele veria também a margem de cada produto, o desempenho dos colegas e o resultado consolidado da empresa.

Esse impasse não é técnico, é de governança. A empresa quer que as pessoas usem os dados, mas não sabe como entregar o número certo para a pessoa certa. Na dúvida, escolhe o caminho mais fácil: restringe tudo. O BI termina com três usuários — o dono, o controller e o analista que construiu o modelo — enquanto o resto da equipe continua pedindo relatório por e-mail. O investimento em dados vira um painel bonito que quase ninguém abre.

A boa notícia é que esse problema já tem solução madura e bem conhecida. Plataformas como o Power BI permitem controlar não apenas quem entra no relatório, mas quais linhas da base cada pessoa enxerga dentro do mesmo painel. É o que se chama de segurança em nível de linha, ou RLS (row-level security, na sigla em inglês, escrita aqui só para você reconhecer o termo quando ouvir). Este artigo explica como isso funciona na prática, quais erros custam caro e como montar um mapa de acesso simples antes de sair distribuindo link.

O que significa controle de acesso num BI

Vale começar pela analogia mais direta. Pense num prédio comercial. Existe a portaria, que confere se você é mesmo quem diz ser e libera a entrada. Existe o crachá, que abre umas portas e outras não — você entra no seu andar, mas não na sala do servidor. E existe, dentro da sua sala, o armário com as pastas: mesmo tendo entrado, você só mexe nos documentos da sua área. Um BI bem configurado funciona exatamente assim, em três camadas independentes.

A confusão começa quando a empresa trata as três camadas como se fossem uma só. "Dar acesso ao BI" vira uma decisão de tudo ou nada: ou a pessoa vê o painel inteiro, ou não vê nada. Quando se separa o que é entrada, o que é permissão de relatório e o que é recorte de dados, a conversa muda de tom. Deixa de ser "posso confiar nessa pessoa com o resultado da empresa?" e passa a ser "qual pedaço da informação ajuda essa pessoa a fazer o trabalho dela melhor?". A segunda pergunta é muito mais fácil de responder — e é a que realmente importa.

Os três níveis que você precisa separar

1. Quem entra

É a identificação. Cada pessoa acessa com a conta corporativa nominal dela, com senha própria e, idealmente, verificação em duas etapas. Parece óbvio, mas é justamente aqui que mora o hábito mais perigoso das empresas pequenas e médias: a conta compartilhada. Um login "gerência" que meia dúzia de pessoas usa, com a senha anotada num grupo de WhatsApp. Enquanto isso existir, nenhuma das camadas seguintes funciona, porque o sistema não tem como saber quem é quem — e você perde também o registro de quem acessou o quê e quando.

Contas nominais custam mais em licença, e esse costuma ser o argumento contra. Mas a comparação correta não é "licença a mais x licença a menos": é "licença a mais x não conseguir liberar dado nenhum com segurança". Quando cada pessoa tem a própria identidade, todo o resto do controle passa a ser possível, inclusive desligar o acesso de alguém que saiu da empresa em trinta segundos, sem trocar senha de mais ninguém.

2. O que a pessoa abre

É a permissão de conteúdo: quais relatórios e painéis aparecem para cada usuário. No Power BI, isso se organiza por áreas de trabalho e por perfis — quem só consome, quem edita, quem publica. Um erro frequente é dar perfil de edição para gente que só precisa olhar, geralmente por pressa. O resultado aparece semanas depois, quando alguém "arrumou" uma medida e os números do relatório oficial mudaram sem ninguém saber por quê.

A regra prática é simples: por padrão, todo mundo entra como leitor. Editar é exceção, concedida a nome e sobrenome, para quem tem responsabilidade formal sobre aquele modelo. Isso não é desconfiança, é a mesma lógica de não dar permissão de alterar o plano de contas para quem apenas lança nota fiscal.

3. Quais linhas a pessoa enxerga

É a camada que quase ninguém configura e que resolve a maior parte dos impasses. Aqui você define que o vendedor abre o relatório comercial e enxerga somente os clientes da carteira dele; que o gerente da filial de Erechim vê os números daquela filial; que o supervisor regional vê todas as filiais da região dele, somadas, mas não as outras. Mesmo relatório, mesmos gráficos, mesmas medidas — recortes diferentes de base, conforme quem está logado.

RLS na prática: um relatório, vários recortes

Tecnicamente, a segurança em nível de linha é configurada dentro do modelo de dados, e não em cada visual do relatório. Você cria funções (por exemplo, "Vendedor", "Gerente de Filial", "Diretoria") e associa a cada função um filtro que se aplica a uma tabela de dimensão — a tabela de vendedores, a de filiais, a de centros de custo. Quando a pessoa abre o painel, a plataforma identifica quem ela é, descobre a que função ela pertence e aplica aquele filtro antes de qualquer cálculo acontecer.

Esse detalhe do "antes de qualquer cálculo" é o que torna o mecanismo confiável. Não se trata de esconder visualmente um gráfico ou de bloquear um botão de filtro, coisa que qualquer usuário curioso contorna. Os dados que a pessoa não pode ver simplesmente não chegam até a tela dela: o total geral que ela enxerga já é o total do recorte dela. Se o vendedor exportar o resultado para Excel, exporta apenas a própria carteira.

Um bom projeto ainda prevê o caso da hierarquia. Um gerente que responde por cinco vendedores precisa ver os cinco, e cada vendedor precisa ver só a si mesmo. Isso se resolve com uma tabela que relaciona pessoa e escopo de visão, mantida como qualquer outro cadastro. E a configuração é testável: antes de publicar, dá para visualizar o relatório "como se fosse" cada função, conferindo com os próprios olhos o que aquela pessoa vai encontrar quando abrir o link.

Por que criar uma versão para cada área é o pior caminho

Sem RLS, a saída improvisada é multiplicar arquivos: um painel para o comercial, outro para a diretoria, um terceiro filtrado para cada filial. No começo parece controle. Seis meses depois, é um problema de manutenção. Cada ajuste de regra de negócio — uma mudança na forma de calcular a margem, um novo imposto, uma correção no cadastro de produtos — precisa ser replicado em todos os arquivos. Basta esquecer um para que duas áreas cheguem à reunião com números diferentes para a mesma pergunta.

E é aí que o custo aparece de verdade, porque o prejuízo não é o retrabalho do analista: é a perda de confiança. Depois da segunda reunião em que os números não bateram, a diretoria volta a decidir pelo feeling e o painel vira decoração. Já escrevemos sobre esse efeito ao tratar do dicionário de indicadores: uma fonte única de verdade só se sustenta se houver, de fato, uma fonte só. Recortar por permissão preserva essa unidade; recortar por cópia de arquivo destrói.

Os erros que aparecem quase sempre

Em projetos de diagnóstico, alguns padrões se repetem com uma frequência impressionante, independentemente do porte da empresa. Vale conferir se algum destes está na sua casa:

• Login compartilhado por equipe — impede qualquer recorte por pessoa e apaga o rastro de quem acessou o quê.
• Acesso concedido e nunca revisado — gente que mudou de área ou saiu da empresa e continua com o link ativo, às vezes por anos.
• Tudo liberado para "não travar o trabalho" — decisão tomada na correria de uma implantação e que nunca mais é revisitada.
• Regra de acesso na cabeça de uma pessoa só — quando quem configurou sai de férias, ninguém sabe conceder nem revogar nada.
• Confundir esconder com proteger — remover um visual do relatório não impede que o dado esteja no modelo e apareça numa exportação.
• Dado sensível junto do operacional — folha de pagamento, custo de aquisição e margem por cliente convivendo no mesmo modelo aberto a todos.

Nenhum desses erros nasce de má intenção. Todos nascem de pressa, e todos ficam mais caros de corrigir quanto mais tempo passa, porque as pessoas se acostumam com o acesso que têm. Reduzir permissão depois de concedida sempre gera atrito — motivo pelo qual vale desenhar isso antes da primeira publicação, e não depois do primeiro susto.

Acesso bem desenhado aumenta o uso, não atrapalha

Há uma inversão importante aqui. Controle de acesso costuma ser tratado como assunto de segurança, algo que restringe. Na prática, é o que permite abrir. Quando existe RLS configurada, o diretor comercial não precisa mais escolher entre esconder o painel de todo mundo ou expor a margem para a equipe inteira: ele libera o relatório para os quarenta vendedores sabendo exatamente o que cada um vai ver. O BI sai da sala da diretoria e chega em quem executa.

Existe ainda o lado formal. A LGPD, em vigor desde 2020, trabalha com o princípio da necessidade — tratar apenas os dados necessários para a finalidade pretendida. Um modelo em que qualquer usuário alcança dados de pessoas, salários ou informações de clientes que não fazem parte do trabalho dele é difícil de justificar numa auditoria. Definir escopos de visão não é burocracia: é a tradução prática desse princípio dentro da ferramenta que a empresa usa todo dia.

Como começar: o mapa de acesso de uma página

Não é preciso um projeto de governança inteiro para dar o primeiro passo. Um documento simples, de uma página, resolve a maior parte das dúvidas e leva menos de uma tarde para ser feito com as pessoas certas na sala:

• Liste os públicos, não as pessoas — diretoria, gerência de filial, vendedores, financeiro, operação. Cinco ou seis grupos costumam cobrir tudo.
• Para cada público, escreva a pergunta que ele precisa responder — "quanto vendi este mês e quanto falta para a meta" é diferente de "qual produto sustenta a margem da empresa".
• Marque o que é sensível — margem, custo, comissão, folha, dados pessoais de clientes. Deixe explícito quem pode ver cada um.
• Defina o recorte de linha de cada público — a própria carteira, a própria filial, a região, tudo.
• Escolha o dono de cada acesso — quem aprova a entrada de alguém novo e quem revisa a lista, com uma data no calendário. Trimestral já resolve.
• Teste antes de publicar — abra o relatório na visão de cada função e confira com os próprios olhos.

Com esse mapa em mãos, a configuração técnica no Power BI é a parte rápida do trabalho. O que consome tempo — e o que evita retrabalho lá na frente — é a conversa que produz o mapa. Se a estrutura dos seus dados ainda não separa bem filial, vendedor ou centro de custo, esse é o sinal de que o problema é anterior ao acesso e está no modelo. Vale tratá-lo primeiro, como discutimos ao falar de diagnóstico de dados.

Abrir os dados sem perder o controle

Um BI só gera retorno quando é usado por quem toma decisão no dia a dia — e isso inclui o vendedor na rua, o gerente da filial e o comprador que precisa decidir o pedido da semana. Segurar tudo na diretoria por medo de expor informação é uma escolha compreensível, mas cara: o dado fica guardado justamente longe de quem poderia agir sobre ele. Configurar acesso por camadas é o que resolve esse dilema sem exigir concessão de nenhum lado.

Na Open Mind IA, essa etapa faz parte da construção de qualquer painel: junto com o modelo de dados, desenhamos os perfis de acesso, aplicamos a segurança em nível de linha e testamos função por função antes de o relatório ir para o ar. É o que permite que um mesmo painel atenda a diretoria e a equipe de campo sem duas versões, duas manutenções e duas verdades. Você pode ver exemplos de projetos assim na nossa página de cases ou conhecer como estruturamos ambientes corporativos em Plataforma Power BI e BI Sob Medida.

Se hoje o seu relatório está parado porque ninguém sabe até onde liberar, provavelmente falta apenas uma tarde de conversa e um ajuste no modelo. É bem menos trabalho do que continuar respondendo pedidos de relatório por e-mail.