"Quanto faturámos?" tem quatro respostas certas. Qual delas queres?

Segunda de manhã, reunião com o banco à tarde. Pegas no telemóvel e escreves ao assistente: "Quanto faturámos em setembro?". Hoje, sem assistente, isto é um pedido à contabilidade, uma exportação do ERP para Excel, uma tabela dinâmica e, com sorte, um número ao fim de meia hora. Com um assistente mal feito é pior: recebes um número em três segundos, com ar de certeza, e não sabes o que ele contou.

Porque "quanto faturámos" não é uma pergunta. São pelo menos quatro.

Quais são as quatro respostas certas?

Imagina uma metalomecânica com faturação mensal na casa dos 400 mil euros. Para setembro, o ERP tem tudo o que é preciso para responder, e consegue responder de quatro maneiras diferentes, todas corretas. Os números abaixo são ilustrativos:

1. Faturado bruto, sem IVA: soma das faturas e faturas-recibo emitidas em setembro. 412.300 €.
2. Faturado líquido, sem IVA: o mesmo, menos as notas de crédito emitidas no mês (uma devolução de peças fora de tolerância, um desconto comercial). 396.800 €.
3. O mesmo, com IVA: é o valor que vês nos documentos e o que interessa a quem olha para tesouraria. 488.064 €.
4. Recebido em setembro: o que entrou efetivamente na conta, que inclui faturas de julho e agosto e exclui metade das de setembro, que vencem a 60 dias. 351.200 €.

Entre a resposta mais alta e a mais baixa há quase 137 mil euros. Nenhuma está errada. Mas se levas a 3 para uma reunião onde se fala de volume de negócios, ou a 1 quando o banco quer saber de margem, tens um problema que nenhum modelo de linguagem resolve sozinho.

E isto ainda é a versão simples. Há a data do documento versus a data de vencimento, os adiantamentos, as vendas de uma loja que fecha caixa ao dia seguinte, a empresa do grupo que fatura à outra. Cada PME tem as suas.

Porque é que um ChatGPT público não resolve isto?

O problema do ChatGPT público numa PME costuma ser apresentado como um problema de privacidade, e é: os dados saem da empresa, muitas vezes saem da UE, e ninguém regista quem perguntou o quê. Mas mesmo que resolvas isso, sobra o problema de fundo. Um modelo genérico não sabe que na tua empresa "faturação" quer dizer líquido de notas de crédito e sem IVA, porque foi assim que a tua contabilista sempre fez o mapa mensal.

Quando não sabe, escolhe. E escolhe em silêncio.

Há números públicos sobre isto do lado técnico. Os sistemas que transformam texto em consultas SQL rondam os 75% de acerto de execução num benchmark académico conhecido (BIRD), e em bases de dados com estrutura empresarial real o acerto já foi medido a cair para cerca de 10% (Spider 2.0). O pormenor que interessa: quando falham, a consulta normalmente corre. Devolve uma tabela, devolve um total, não dá erro. Simplesmente responde a outra pergunta.

Num ChatGPT privado para empresas, esse silêncio é o defeito a eliminar. Não o modelo "inventar uma fatura", que é raro quando a resposta vem do ERP, mas o modelo responder com confiança a uma leitura da pergunta que tu não fizeste.

O que deve fazer um assistente sério quando a pergunta é ambígua?

Duas coisas, e só duas: perguntar de volta ou dizer qual leitura usou. Nunca a terceira, que é escolher sem avisar.

Perguntar de volta faz sentido quando a diferença entre as leituras é grande e quem pergunta tem várias necessidades. Ao gestor que vai ao banco, o assistente responde: "Queres o faturado (sem IVA, líquido de notas de crédito) ou o recebido em setembro?". Um toque e está.

Declarar o pressuposto faz sentido quando a empresa já decidiu o que a palavra quer dizer. Aí a resposta vem com a etiqueta colada: "396.800 € — faturado líquido de notas de crédito, sem IVA, por data do documento, 1 a 30 de setembro. Fonte: 214 documentos de venda e 6 notas de crédito." O número vem com a definição e com a origem, e qualquer pessoa da contabilidade o consegue confirmar no ERP em dois minutos.

"Não quero um assistente que me faz perguntas. Quero a resposta."

É a objeção certa, e é por isso que a clarificação não pode ser a regra. Um assistente que pergunta "com ou sem IVA?" a cada mensagem é abandonado na segunda semana.

A solução é decidir as definições uma vez, com quem conhece os números, e não deixá-las ao critério do modelo em cada pergunta. Na prática, faz-se assim:

• Um glossário da empresa. "Faturação" = líquido, sem IVA, por data do documento. "Recebimentos" = movimentos de conta corrente liquidados. "Em atraso" = vencido há mais de 30 dias. É uma tarde de trabalho com a pessoa das finanças.
• Consultas aprovadas, não SQL livre. O modelo não escreve a consulta de raiz. Escolhe entre consultas que foram escritas, testadas e validadas contra os mapas que a empresa já usa, e preenche os parâmetros (cliente, período, armazém). Se a pergunta não encaixa em nenhuma, diz que não sabe.
• Predefinições por perfil. A direção comercial vê faturação; a tesouraria vê recebimentos; o assistente só pergunta de volta quando a pessoa tem acesso às duas e a pergunta não diz qual.

Assim, a pergunta de volta fica reservada para os casos em que vale mesmo a pena, e no resto respondes à primeira, com a definição à vista.

Como funciona por cima do ERP que já tens?

Sem jargão, são quatro peças:

1. Um conector só de leitura ao ERP (PHC ou outro). O utilizador de base de dados não tem permissão de escrita. Não é uma regra no prompt, é uma permissão que a base de dados recusa.
2. Uma camada que traduz a pergunta para uma das consultas aprovadas, aplicando o glossário e o perfil de quem pergunta (RBAC: o armazém não vê margens, o comercial só vê os seus clientes).
3. A resposta com números verificáveis: valor, definição usada, período, e quantos documentos entraram na conta.
4. Um registo de auditoria de cada pergunta, da leitura escolhida, da consulta executada e da resposta dada.

A arquitetura é agnóstica ao modelo: pode usar um modelo pensado para o português europeu, como o AMALIA, ou outro modelo alojado na UE, conforme o caso e o tipo de perguntas. O que não muda é o resto: dados na UE, RGPD por desenho (minimização, acesso por perfil, retenção definida), e nada é arrancado nem migrado. O ERP continua a ser a fonte de verdade.

Como fica isto no WhatsApp?

Um exemplo de uma manhã normal numa distribuidora. Números ilustrativos.

Tu: quanto faturámos em setembro?
Assistente: Faturação de setembro (líquida de notas de crédito, sem IVA): 396.800 €. 214 faturas, 6 notas de crédito. Queres ver o recebido no mesmo mês?

Tu: sim
Assistente: Recebido entre 1 e 30 de setembro: 351.200 €, dos quais 148.900 € são faturas de julho e agosto.

Tu: e o cliente Ferragens Lis?
Assistente: Ferragens Lis em setembro: faturado 18.450 € (sem IVA), recebido 9.200 €. Em aberto: 22.690 € com IVA, dos quais 7.380 € vencidos há mais de 30 dias (2 faturas).

Tu: quantas peças do 40-112 temos?
Assistente: "Peças" pode ser stock físico ou disponível (físico menos reservado em encomendas). Físico no armazém 1: 1.240. Disponível: 860. Abaixo do mínimo definido (1.000).

Repara no padrão: quando há definição da empresa, ela vem escrita na resposta. Quando a ambiguidade importa, o assistente diz as duas leituras em vez de escolher uma.

O que é que isto não faz?

Não escreve no ERP. Não lança faturas, não altera stocks, não fecha encomendas. Não decide por ti se cobras o cliente amanhã. E não corrige dados desarrumados: se metade das notas de crédito está lançada como faturas negativas e a outra metade como documento próprio, o assistente vai refletir essa confusão, e o primeiro mérito do piloto costuma ser mostrá-la.

Também precisa de duas coisas que só tu podes dar: alguém das finanças que passe uma tarde a fechar o glossário, e uma decisão clara sobre quem vê o quê.

Por onde começar?

Um piloto pequeno. Um departamento, normalmente finanças ou comercial. Juntas as 10 a 20 perguntas que hoje chegam por email ou telefone à contabilidade ("quanto faturámos ao cliente X", "o que está por receber", "quais as faturas vencidas"), defines o que cada palavra quer dizer, e medes em horas poupadas por semana ao fim de um mês. Se os números não baterem com os mapas da contabilidade, não passa do piloto.

Somos uma equipa pequena em Leiria: falas diretamente com quem escreve o conector e as consultas, sem gestores de conta pelo meio.

Queres perguntar ao teu ERP em português, sem os dados saírem da UE? Fala connosco: hello@leiritech.com · +351 914 572 595, ou vê o nosso trabalho em leiritech.pt.