Ambiguidade é um problema de governança, não apenas de IA Generativa

O que realmente acontece quando alguém pergunta "quanto vendemos?"

Essa pergunta parece simples porque, na conversa entre pessoas, o contexto preenche o que falta. Quando o diretor comercial pergunta quanto a equipe vendeu no mês, o analista que trabalha com ele há três anos sabe, sem precisar perguntar, que a resposta esperada é receita líquida, sem impostos, considerando apenas pedidos faturados, excluindo devoluções, no regime de competência, para os canais próprios. Esse conhecimento não está em lugar nenhum. Está na cabeça do analista. Ele é reconstruído toda vez que a pergunta é feita, e é reconstruído de forma ligeiramente diferente por cada pessoa que a responde.

O que uma ferramenta de GenBI faz é remover o analista do meio do caminho. A pergunta chega direto ao modelo, que precisa transformá-la em consulta ao dado. E aí surge o ponto que quase ninguém trata como problema antes de doer: o modelo não tem os três anos de convivência. Ele tem o catálogo, os nomes das colunas, as descrições que alguém escreveu ou deixou de escrever, e a pergunta em linguagem natural. Se existem sete colunas que poderiam representar "venda", ele vai escolher uma. A escolha vai ser plausível, vai gerar SQL válido, vai retornar um número correto para aquela definição. E vai estar errado do ponto de vista do negócio, porque a empresa esperava outra.

Vale ser preciso sobre a natureza da falha. O modelo não alucinou um número. Ele respondeu com exatidão a uma pergunta ambígua, e uma pergunta ambígua admite várias respostas exatas. Chamar isso de "erro da IA" é confortável porque desloca o problema para o fornecedor da tecnologia. Mas o diagnóstico honesto é outro: a empresa nunca decidiu o que é uma venda, e conseguiu conviver com isso enquanto um humano com contexto absorvia a decisão silenciosamente, todo dia, sem registrar.

Um termo, várias respostas corretas

Vale abrir o exemplo, porque a ambiguidade raramente aparece como duas opções. Ela aparece como uma combinação de decisões independentes, cada uma delas legítima, que se multiplicam.

1. 01

   O que se mede

   Receita bruta, receita líquida de impostos, receita líquida de devoluções e descontos, quantidade de itens, quantidade de pedidos, ou valor de contrato assinado. Financeiro e comercial costumam responder isso de forma diferente, e ambos estão certos dentro da própria lógica.

2. 02

   Quando a venda acontece

   Na data do pedido, na aprovação do crédito, na emissão da nota, no faturamento, no embarque ou no recebimento. Uma empresa com ciclo longo pode ter três meses de distância entre a primeira e a última dessas datas.

3. 03

   O que entra na conta

   Pedidos cancelados depois do fechamento, devoluções lançadas em mês posterior, vendas entre empresas do mesmo grupo, amostras, bonificações, trocas em garantia, frete cobrado do cliente, vendas de teste feitas pela própria equipe.

4. 04

   A quem se atribui

   Ao vendedor que abriu a oportunidade, ao que fechou, à filial que faturou, à região do cliente, ao canal de origem. Em operações com venda assistida, essa única decisão já é capaz de gerar duas versões conflitantes do mesmo ranking de desempenho.

Vale fazer a conta, porque ela é mais dura do que a intuição sugere. Seis opções na primeira decisão, seis na segunda e cinco critérios de atribuição na quarta já produzem 180 combinações, e isso antes de considerar as exclusões da terceira, que se combinam entre si e multiplicam esse número por ordens de grandeza. O ponto não é o total exato, é a natureza combinatória: cada decisão que a empresa deixa em aberto multiplica as respostas defensáveis para "quanto vendemos no mês passado", em vez de somar. A ferramenta de IA vai escolher uma. A probabilidade de acertar exatamente a que estava na cabeça de quem perguntou é baixa, e o problema é que a resposta errada não parece errada. Ela vem formatada, com gráfico, num número da ordem de grandeza esperada.

O que os benchmarks mostram sobre o peso do contexto

Até aqui o argumento é raciocínio. Existe, porém, um dado público que permite medir uma parte dele.

O BIRD é um benchmark de conversão de linguagem natural para SQL construído sobre bancos reais, com registros financeiros, dados de toxicologia e bases governamentais, valores sujos e colunas cujo significado exige conhecimento de domínio. Nele, o GPT-4 alcançou 54,89% de acerto de execução no conjunto de teste quando recebeu junto da pergunta um conhecimento externo curado sobre o domínio. Sem esse conhecimento, o mesmo modelo, no mesmo banco, respondendo às mesmas perguntas, caiu para 34,88%.

É a tese deste artigo medida em condição controlada: parte relevante do que se atribui à capacidade do modelo é, na verdade, disponibilidade de definição.

Duas ressalvas importam. A primeira é que esse conhecimento externo do BIRD é escrito à mão, consulta por consulta, por anotadores com domínio do assunto, o que não corresponde a um cenário real de produção, onde o sistema precisa recuperar ou inferir o contexto sozinho. Isso não enfraquece o argumento; reforça, porque mostra que alguém tem de produzir esse contexto, e é exatamente esse trabalho que a maioria das empresas não fez. A segunda é que os números do benchmark não são estáveis: um estudo apresentado no CIDR 2026 encontrou taxas altas de erro de anotação em conjuntos de teste-para-SQL e, ao corrigir uma amostra do BIRD Dev, viu a acurácia de agentes variar de −7% a +31% em termos relativos, com mudanças expressivas de posição no ranking. Trate esses percentuais como ordem de grandeza, não como medida precisa.

O que continua de pé mesmo com essa ressalva é o mais importante: a diferença provocada pela presença de contexto de domínio é grande demais para ser ruído.

Por que isso é governança e não tecnologia

O impulso natural de quem opera a ferramenta é tratar isso como um problema de engenharia de prompt. Escrever instruções melhores, detalhar mais o pedido, criar regras de negócio no contexto do modelo. Essa camada ajuda e é necessária, mas ela não resolve, porque não é onde a decisão falta.

Convém dizer que nada disso é novidade conceitual. A necessidade de um significado único para cada termo de negócio é tratada há décadas: nas dimensões conformes de Ralph Kimball, na disciplina de gestão de metadados e definição de dados descrita no DAMA-DMBOK, e mais recentemente na discussão de camada semântica e camada de métricas nas arquiteturas modernas de dados. A contribuição da IA generativa aqui não é levantar um problema novo. É tornar caro continuar ignorando um problema velho.

O que falta é alguém dentro da empresa dizer, com autoridade para isso: venda é isto. Não "venda pode ser isto dependendo do caso", que é o que já existe. Uma definição única, com dono, com data, com registro de quando mudou e por quê, e com uma tradução técnica que corresponde exatamente ao texto de negócio. Isso é governança de dados no sentido mais literal do termo: alguém governa o significado.

O que muda com GenBI é o custo de não ter feito isso. No modelo tradicional de BI, a ambiguidade era absorvida por três amortecedores. O primeiro era o tempo: entre a pergunta e o relatório havia dias, e nesse intervalo alguém checava, discutia, ajustava. O segundo era o número limitado de pessoas com acesso: cinco analistas com prática compartilhada erram de forma parecida, o que faz a divergência aparecer pouco. O terceiro era o número limitado de perguntas: um dashboard responde as perguntas previstas quando foi construído, e essas perguntas já vinham com a definição embutida por quem o construiu.

GenBI remove os três de uma vez. A resposta vem em segundos, sem intervalo para checagem. O acesso vai para dezenas ou centenas de pessoas, cada uma com sua própria noção do termo. E a pergunta passa a ser livre, incluindo cortes e combinações que ninguém previu. A ambiguidade que sobrevivia contida em cinco cabeças passa a circular em reuniões, apresentações e decisões. Não é uma nova falha. É uma falha antiga sem os amortecedores que a mantinham invisível.

Aqui está o ponto que costuma ser incômodo de admitir: a divergência de números entre áreas já existia antes de qualquer IA. Toda empresa com mais de um sistema conhece a reunião em que comercial e financeiro apresentam faturamentos diferentes e ninguém consegue explicar a diferença em tempo real. GenBI não inventou esse problema. Ele apenas encurtou o caminho entre a pergunta e a contradição.

O ponto cego dos dois lados

Vale nomear como isso costuma travar na prática, porque raramente é falta de competência técnica.

Quem vem do BI conhece esse problema há muito tempo. Dicionário de dados, dimensão conforme, métrica com dono: nada disso é novidade. O ponto cego desse lado é achar que a solução é a mesma de sempre, ou seja, mais documentação e mais processo. Documentação que vive num arquivo separado do sistema que responde às perguntas não é camada semântica, é intenção. Se a definição não estiver executável, no caminho entre a pergunta e a consulta, ela não vai ser aplicada.

Quem vem da IA olha o problema como qualidade de contexto e tenta resolver com recuperação de informação, com mais exemplos, com uma janela maior. Isso melhora a taxa de acerto, mas esbarra num limite duro: não existe contexto capaz de recuperar uma decisão que a empresa nunca tomou. Quando quatro áreas definem "cliente ativo" de quatro maneiras, o modelo não tem como escolher a certa, porque não existe uma certa ainda.

Os dois lados estão descrevendo o mesmo problema com vocabulários diferentes. É por isso que ele aparece com tanta frequência em projeto real e com tão pouca frequência em apresentação de fornecedor.

Como isso se traduz em implementação

Existe uma consequência prática direta. Ao implantar uma solução de GenBI, o trabalho pesado não está na integração técnica, nem na escolha do modelo de linguagem, nem na geração de SQL. Está na camada semântica, o conjunto de definições que traduz o vocabulário do negócio para o vocabulário do dado.

Essa camada precisa carregar, para cada termo que aparece em pergunta de negócio, pelo menos: a definição em linguagem de negócio; a expressão técnica correspondente; o que fica de fora, explicitamente; a granularidade em que o número faz sentido; o dono da definição; a data da última revisão. Termos sem esses campos não deveriam estar disponíveis para consulta. É preferível que a ferramenta diga que não sabe responder a que responda com uma escolha arbitrária.

Duas escolhas de projeto seguem daí e são pouco discutidas. A primeira: quando a pergunta é ambígua, o comportamento correto da ferramenta é perguntar de volta, não escolher.

"Você quer receita bruta ou líquida?"

é uma resposta melhor que um número. Ferramentas otimizadas para parecer fluidas tendem a evitar essa pergunta, porque ela quebra a impressão de mágica. É exatamente essa impressão que produz o erro caro.

A segunda: toda resposta precisa mostrar a definição que usou, junto com o número. Não em documentação separada, não num tooltip escondido, e sim na resposta. Quem lê precisa poder discordar da definição antes de usar o número numa decisão. Sem isso, não existe correção possível: o erro só aparece semanas depois, numa reunião, quando dois números incompatíveis se encontram.

Limites desta tese

Duas ressalvas, porque a tese não explica tudo.

Nem toda falha de GenBI é semântica. Existem erros que são genuinamente do modelo: SQL mal construído, junção incorreta entre tabelas, interpretação errada de período mesmo com a definição clara, invenção de coluna inexistente. Esses casos existem e precisam de controles próprios, como validação de consulta, testes com resultado conhecido e revisão de amostra. Atribuir tudo à governança seria trocar um álibi por outro.

E definir bem os termos não garante decisão correta. Uma métrica bem definida, calculada sobre dado incompleto ou desatualizado, continua produzindo conclusão ruim. Definição semântica resolve a pergunta "estamos medindo a mesma coisa?", que é anterior e diferente de "o dado está certo?" e de "a conclusão que tiramos disso procede?". São três problemas distintos, e resolver o primeiro não dispensa os outros dois.

O que fazer com isso

Se você está avaliando ou implantando GenBI, o teste mais barato leva uma tarde. Pegue os dez termos que mais aparecem nas reuniões da sua diretoria: venda, cliente ativo, churn, margem, ticket médio, inadimplência, o que for o vocabulário da sua operação. Peça, separadamente e por escrito, a definição de cada um a três pessoas de áreas diferentes. Não discuta antes; compare depois.

Se as três definições coincidirem, a empresa está pronta para a camada semântica e o projeto pode avançar pela via técnica. Se divergirem, e na maioria das operações que já têm mais de um sistema elas divergem, essa divergência é o projeto. Nenhuma ferramenta vai resolvê-la, porque não é uma pergunta que a tecnologia tenha autoridade para responder. É uma decisão de negócio que alguém precisa tomar e assinar.

A implantação de GenBI, nesse sentido, tem um efeito secundário que raramente é vendido como benefício: ela obriga a empresa a decidir o que suas próprias palavras significam. Muitas organizações passaram vinte anos adiando essa conversa porque conseguiam operar sem ela. Com uma ferramenta que responde qualquer pergunta em segundos para qualquer pessoa, adiar deixa de ser uma opção barata.

Se você fez esse teste e encontrou divergência, esse é exatamente o tipo de dor que a GenBI Community BR existe para tratar. Traga o caso. Discutir uma ambiguidade concreta, com os termos reais de uma operação real, ensina mais do que qualquer explicação genérica sobre camada semântica, inclusive esta.