Usar IA para conversar com os dados do Power BI: os três caminhos e onde cada um trava

Reunião de resultado. Alguém pergunta por que a margem daquele cliente caiu. Ninguém tem o número ali — o painel mostra o consolidado, não o recorte. Anota-se o pedido, manda-se para o time de dados, e a resposta volta em três dias, quando a reunião já acabou e a decisão já foi tomada de outro jeito.

Do outro lado do mesmo pedido tem uma pessoa. É o analista que passa boa parte da semana em “extrai isso pra mim”, “adiciona aquela coluna”, “me ajuda aqui que é urgente” — e adia para depois a análise que ele gostaria de estar fazendo.

As duas dores são a mesma fila, vista das duas pontas. Quem espera nela reclama de decisão adiada. Quem a faz andar reclama do dia que foi embora em pedido pequeno. E as duas seguem valendo mesmo numa empresa com Power BI maduro, dashboard bonito e time bom — porque não é falta de dado nem falta de ferramenta.

O reflexo natural é construir mais uma visão. Se a pergunta não tinha resposta, cria-se o painel que responde.

Só que a próxima pergunta é outra. Dashboard é uma resposta pronta para uma pergunta que alguém previu — e o dia a dia produz perguntas que ninguém previu. Cada nova visão resolve um caso e cria mais um item para manter.

É por isso que empresas que investiram anos em BI continuam com a mesma queixa. Não faltou construção. Faltou o caminho para a pergunta que não estava no roteiro — e é nessa distância, entre a visão pronta e a pergunta do momento, que o valor do dado se perde.

Quando a empresa decide colocar IA sobre isso, existem três caminhos reais. Vale conhecer os três antes de escolher — inclusive porque dois deles não são nossos.

Caminho 1 — o que já vem na plataforma

O Copilot do Power BI e do Fabric já estão ali, inclusos na capacidade que a empresa paga. É o primeiro lugar onde qualquer time olha, e é a coisa certa a fazer: custo marginal zero para testar.

O que se costuma encontrar: ele responde melhor quando a pergunta é próxima do que o relatório já mostra, e depende bastante de como o modelo está descrito e nomeado. Em ambiente organizado ele entrega; em ambiente real, com anos de tabela herdada, o resultado varia de painel para painel. E o licenciamento e a capacidade mínima entram na conta antes do valor aparecer.

Quando é o caminho certo: ambiente já arrumado, escopo pequeno, time disposto a ajustar nomenclatura. Se resolver, resolveu — e economizou uma decisão.

Caminho 2 — construir por dentro

É o caminho mais tentador, e a intuição por trás dele está certa: hoje se conecta um LLM a um banco com pouco código, e a primeira demonstração vai funcionar. Quem constrói normalmente é bom, e a demo prova isso.

O problema não é a semana um. É o mês três, quando o piloto sai das três tabelas que a pessoa conhece de cor e encontra o ambiente de verdade.

Caminho 3 — uma camada sobre o modelo do BI

Uma camada que não fala com as tabelas cruas, e sim com o modelo que o time já publicou no Power BI: as medidas cadastradas, as regras aplicadas, as permissões configuradas. Em vez de descrever o significado dos dados de novo para a IA, ela usa a descrição que o time já escreveu e já valida todo dia. É onde o Data Hub atua.

E a coisa em que os três esbarram

Não é a qualidade do modelo de linguagem. É a ambiguidade.

Um ambiente de verdade tem centenas de tabelas, várias com a mesma informação e três versões da mesma métrica. Não existe uma resposta certa dentro da camada de dados: qual vale depende de uma regra de negócio que nunca foi escrita ali — o que conta como faturamento líquido, qual filtro se aplica, qual exceção existe para aquele cliente.

Quando a IA gera a consulta sozinha, ela escolhe. E escolhe bem em quase todas as perguntas, o que é exatamente o problema: o erro não vem em lote, vem pingado, misturado com acerto. Um número sai com cara de certo, entra na apresentação, e ninguém volta para conferir uma conta que não levantou suspeita.

É por isso que tanta prova de conceito encanta na demonstração e morre sem adoção — e o time raramente sabe dizer por quê.

Elas valem principalmente para quem vai construir por dentro, e é honesto colocá-las na mesa: nenhuma aparece na semana um. Todas aparecem quando o piloto sai das três tabelas que a pessoa conhece de cor e encontra o ambiente de verdade.

1. 01A IA escolhe uma das três versões e não avisa. É a ambiguidade descrita acima, encontrada na prática. Na demo ela não aparece, porque quem testa pergunta coisas cuja resposta já sabe.
2. 02O conserto mata a adoção. Descoberto o erro, o conserto óbvio é fazer a IA perguntar de volta: “você quer o faturamento com ou sem devolução?”, “pela data de emissão ou de competência?”. Tecnicamente é a coisa certa. Na prática é aqui que o projeto morre, e morre sem gerar bug — só silêncio. O diretor não quer desambiguar; em duas idas e voltas, ele não volta mais. Sobram dois caminhos e os dois são ruins: errar calado ou perguntar até cansar.
3. 03O catálogo semântico não fica pronto. A conclusão seguinte é descrever o significado dos dados para a IA: o que cada tabela é, o que cada coluna quer dizer, qual métrica vale. Funciona na teoria. Catálogo completo, atual e confiável ao mesmo tempo não é a realidade da maior parte das empresas brasileiras — ele nasce incompleto, envelhece na primeira mudança de modelo, e manter atualizado é trabalho contínuo que não tem dono. Vira um projeto dentro do projeto, que consome os meses seguintes e não entrega nada visível enquanto não converge.
4. 04A permissão não acompanha. O protótipo roda com uma conexão só e enxerga tudo, porque quem testa pode ver tudo. No mês três alguém pergunta o que acontece quando o gerente regional usar. Aí aparece o trabalho que ninguém tinha orçado: quem vê o quê, regra por regra — regras que já existem no BI e que a solução construída por fora não herda. Reconstruí-las significa manter uma segunda lista de acesso. Duas listas convivem bem no primeiro mês; no terceiro, alguém revoga um acesso numa delas e esquece a outra, e a pessoa continua vendo o que já não deveria. Não dá erro, então ninguém percebe. Isso não é bug de software, é achado de auditoria.

A quarta é a que dói mais, porque para o projeto depois de ele já estar funcionando.

Nada disso quer dizer que não dá para construir. Dá. O que a lista diz é onde a estrada passa — e que ela é mais longa do que parece do quilômetro zero.

E não é um lugar novo: é o modelo do seu próprio Power BI.

Ali o seu time passou anos decidindo o que conta como faturamento líquido, qual filtro vale, qual exceção existe para aquele cliente. Não foi uma reunião — foram dezenas, ao longo de anos, até chegar numa versão que a empresa aceita e usa para decidir todo dia. Essa é a curadoria mais cara que a empresa já pagou, e ela está pronta.

É por isso que o Data Hub começa por lá. Ele não gera consulta livre no banco: responde pelas medidas que já estão cadastradas e validadas no modelo. Não cria métrica nova e não inventa número — traduz a pergunta em português para o que já existe.

E tem uma coincidência que resolve dois problemas com uma decisão só: é a mesma camada que guarda a regra de acesso. Quem só enxergava a própria carteira no relatório continua enxergando só ela quando pergunta em português, sem recadastrar permissão em lugar nenhum. Uma lista de acesso, não duas.

A síntese, e é a mais honesta que a casa tem: o Hub é um tradutor entre o usuário e as métricas dele. O detalhe camada por camada está em Arquitetura; o que fica registrado e o que a IA alcança está em Governança.

São três atos, e o terceiro é o cliente:

Você pergunta — em português, do jeito que você falaria com o analista.

O Hub faz o trabalho difícil — entende a pergunta, aplica o contexto do negócio, consulta o Power BI respeitando a permissão de quem perguntou, devolve número, gráfico e leitura, e registra tudo.

Você decide — na mesma reunião, não na semana seguinte.

E o que muda depende de onde a pessoa senta:

E tem um ganho que só existe quando BI e IA estão juntos: você passa a saber o que as pessoas perguntam — inclusive o que elas procuram e não encontram. O BI comum mostra quem fez login. Aqui você vê o que a empresa quer saber, e isso vira uma lista de demanda de dados que se constrói sozinha, pelo uso. Não o que foi pedido em reunião de priorização: o que foi procurado na hora da decisão.

Essa é a restrição real de 2026, e ela é justa: quase ninguém tem verba nova para experimentar, nem margem política para um projeto que só mostra resultado no fim.

Três coisas do desenho respondem a isso.

Não há projeto de fundação antes do valor. O Hub entra sobre o que já está publicado. Sem migração, sem trocar plataforma, sem esperar o data lake ficar pronto. O que existe hoje continua existindo exatamente como está.

A entrada é pequena de propósito, e inclui treinamento gravado. A configuração inicial entrega a plataforma e um painel já funcionando com a IA em cima, mais duas sessões de treinamento — uma para quem vai usar e outra para quem vai administrar. A de administrador cobre justamente ligar o Hub num painel novo. A intenção é essa: você aprende a fazer os próximos sozinho. E como as sessões ficam gravadas, quem entrar no time daqui a seis meses aprende sem depender da gente — que é exatamente onde produto de dados costuma morrer no segundo ano.

Boa parte da conta já está sendo paga. Hoje a empresa paga licença individual por gente que só abre o relatório e olha. No Hub esse acesso passa pela capacidade do Fabric, não por licença por pessoa — e a economia dessa linha costuma financiar a IA. A conta inteira, com o mecanismo e onde mora a gordura, está em Economia de licença.

E se não der certo, nada fica preso. O Power BI continua como está. Não há migração para desfazer nem dado para resgatar de lugar nenhum, porque ele nunca saiu.