Como usar IA para escrever DAX no Power BI sem quebrar o modelo

Dá para usar IA para escrever DAX no Power BI sem quebrar o modelo, desde que ela trabalhe dentro de um fluxo com conferência. O fluxo tem cinco partes: passar à IA o contexto real do modelo, declarar a regra de negócio por escrito, validar o resultado contra números que você já conhece, testar numa cópia versionada em formato PBIP e revisar o contexto de filtro antes de publicar. A sintaxe raramente é o problema. Os modelos de linguagem acertam a escrita do DAX com facilidade; o que eles erram é o significado, porque não sabem qual é a granularidade da sua tabela fato, quais relacionamentos estão ativos ou o que a diretoria chama de margem.

Por que a IA erra uma medida que parece correta?

Porque a fórmula pode estar certa para um modelo que não é o seu. Sem ver as tabelas, a IA supõe nomes de colunas, supõe que existe uma tabela de calendário marcada como tabela de datas e supõe que cada linha da fato é um pedido, quando muitas vezes é um item de pedido. A medida gerada roda, devolve um número plausível e passa na primeira olhada. O erro só aparece quando alguém compara com o relatório do ERP, ou quando o total da matriz deixa de bater com a soma das linhas.

Há também o erro mais simples de pegar: funções que não existem ou parâmetros na ordem errada. Esse o próprio Power BI acusa ao salvar a medida. O perigoso é o outro tipo, a medida que funciona e calcula a coisa errada.

Qual é o fluxo seguro, passo a passo?

1. 1.Passe o contexto do modelo: tabelas, colunas usadas, relacionamentos, granularidade de cada fato e as medidas que já existem. Sem isso, a IA inventa nomes e estrutura.
2. 2.Declare a regra de negócio: escreva em uma ou duas frases o que a medida precisa calcular, incluindo o que entra e o que fica de fora (devoluções, notas canceladas, frete, impostos).
3. 3.Valide contra números conhecidos: escolha um período fechado em que o resultado correto já é sabido, como a margem de agosto conferida pela controladoria, e compare.
4. 4.Teste em cópia versionada: salve o projeto como PBIP, trabalhe numa branch ou cópia e só leve a medida para o modelo publicado depois de revisar a diferença.
5. 5.Revise o contexto de filtro: confira a medida no total, em cada nível da hierarquia e com as segmentações que o usuário de fato usa, não só na linha de detalhe.

Que contexto passar para a IA?

Quanto mais a IA enxerga do modelo, menos ela adivinha. A forma mais completa é conectá-la diretamente ao modelo aberto pelo servidor MCP de modelagem da Microsoft, que descrevemos em o que é MCP e como conectá-lo ao Power BI Desktop: ela passa a ler as tabelas, as colunas e as medidas reais, em vez de trabalhar sobre uma descrição. Sem essa conexão, um bom pedido deixa explícitos alguns pontos:

• Granularidade da fato: se cada linha é uma nota, um item de nota ou um movimento de estoque. Isso decide se uma soma está certa ou duplicada.
• Nomes exatos de tabelas e colunas: copiados do modelo, com as tabelas de dimensão que filtram a fato e a direção dos relacionamentos.
• Tabela de calendário: qual é, se está marcada como tabela de datas e qual coluna de data da fato está ligada a ela por relacionamento ativo.
• Medidas que já existem: para que a nova medida reaproveite [Receita] e [Margem] em vez de recriar a regra com outra lógica.
• O resultado esperado: um ou dois números conferidos que a medida precisa reproduzir.

Antes de colar qualquer coisa num chat, vale lembrar que nomes de clientes, valores e amostras de dados também são informação da empresa. Na maior parte dos casos, a estrutura do modelo basta; os dados em si não precisam sair do Power BI.

Quais são os erros mais comuns da IA em DAX?

• Contexto de filtro removido demais: para um percentual sobre o total, a IA costuma usar ALL na tabela inteira, o que ignora também as segmentações escolhidas pelo usuário. Muitas vezes a regra pedia ALLSELECTED ou REMOVEFILTERS só em uma coluna.
• Iterador onde não cabe: AVERAGEX ou SUMX aplicados linha a linha sobre uma razão, como margem dividida por receita, calculam a média dos percentuais, e não o percentual do total.
• Totais que não fecham: medidas com IF ou com lógica por item mostram linhas certas e um total sem sentido, porque no total o contexto tem todos os itens ao mesmo tempo.
• Relacionamento errado: quando a fato tem duas datas, como emissão e entrega, só um relacionamento fica ativo. A IA raramente sabe qual, e quase nunca usa USERELATIONSHIP sem ser avisada.
• Inteligência de tempo sem calendário adequado: funções como SAMEPERIODLASTYEAR e DATESYTD dependem de uma tabela de datas contínua. Aplicadas direto na coluna de data da fato, devolvem resultados incompletos ou incorretos.

Como um desses erros aparece nos números?

Um caso inventado para este texto, sem relação com nenhum cliente, mostra o tamanho do estrago. Uma distribuidora pede à IA uma medida de margem percentual. A tabela de vendas tem, no recorte analisado, duas linhas: um pedido de R$ 1.000.000 com R$ 300.000 de margem (30%) e um pedido de R$ 10.000 com R$ 6.000 de margem (60%). A IA devolve uma medida que calcula o percentual de cada linha e tira a média: 45%. A margem real do período é R$ 306.000 sobre R$ 1.010.000, ou 30,3%. O pedido pequeno pesou o mesmo que o grande.

// Média dos percentuais: o pedido pequeno pesa igual ao grande
Margem % (errada) =
AVERAGEX ( fVendas, DIVIDE ( fVendas[Margem], fVendas[Receita] ) )

// Razão dos totais: a margem do período
Margem % =
DIVIDE ( SUM ( fVendas[Margem] ), SUM ( fVendas[Receita] ) )

Com milhares de linhas, a distorção some na primeira olhada: o número fica numa faixa plausível e ninguém desconfia. Só a comparação com um valor conferido mostra que ele não corresponde à margem que a controladoria apura.

Como validar a medida antes de colocar no modelo?

A visualização de consulta DAX do Power BI Desktop permite testar uma medida sem gravá-la no modelo: ela é definida dentro da consulta e avaliada ao lado dos totais que você já conhece. Os nomes de tabela e coluna abaixo são de um modelo de exemplo:

DEFINE
    MEASURE fVendas[Margem % Teste] =
        DIVIDE ( SUM ( fVendas[Margem] ), SUM ( fVendas[Receita] ) )
EVALUATE
SUMMARIZECOLUMNS (
    dCalendario[AnoMes],
    "Receita", SUM ( fVendas[Receita] ),
    "Margem %", [Margem % Teste]
)

O resultado mês a mês vai lado a lado com o relatório de margem do ERP para os períodos já fechados. Se algum mês divergir, a causa costuma ser uma das que listamos em por que os números do Power BI não batem com o ERP: filtro, critério de data, cadastro ou regra de cálculo. Só depois que os números batem a medida entra no modelo, com uma descrição que registre a regra usada.

Por que testar em PBIP versionado?

Salvo como projeto do Power BI (PBIP), o modelo semântico vira um conjunto de arquivos de texto em TMDL, que podem ir para o Git. Cada medida criada ou alterada pela IA aparece como uma diferença legível, que outra pessoa revisa antes da publicação. Se algo der errado, voltar à versão anterior é questão de minutos. No arquivo PBIX único, uma alteração em massa feita por IA fica difícil de auditar e de desfazer, porque não há como ver exatamente o que mudou.

O mesmo raciocínio vale para quem usa o Copilot dentro do Power BI ou qualquer outro assistente: a ferramenta acelera a escrita, mas a responsabilidade pelo número continua com o time que publica o relatório. Uma regra simples ajuda: nenhuma medida gerada por IA vai para o modelo de produção sem um número conferido e sem revisão de outra pessoa.

Se o seu time já usa IA para escrever DAX e ninguém sabe dizer quais medidas foram geradas assim, quem revisou cada uma e contra qual número, o risco já está no relatório da diretoria. No diagnóstico gratuito de modelo semântico e governança da Insight Pro, parte do serviço de Business Intelligence, avaliamos a estrutura do seu modelo, conferimos as medidas principais contra os números do ERP e propomos um fluxo de versionamento e revisão para o uso de IA no Power BI, sem compromisso de contratação.