"Quanto é que a Metalúrgica Silva nos deve, e desde quando?" É uma pergunta de trinta segundos. Hoje, na maioria das PME, demora meia hora: alguém abre o PHC, exporta o extrato de conta corrente, cola no Excel, filtra por vencimento, e manda um print por email. Se essa pessoa estiver de férias, a pergunta espera.
A promessa de um "ChatGPT privado para empresas" é acabar com essa meia hora. E a forma mais rápida de fazer uma demo disso é também a mais perigosa: dar ao modelo de linguagem acesso à base de dados do ERP e deixá-lo escrever o SQL que achar melhor. Funciona lindamente em palco. Em produção, é a decisão que vais lamentar.
Este artigo explica a alternativa que usamos: o modelo não escreve SQL. Escolhe uma consulta de um catálogo que tu aprovaste, preenche os parâmetros, e o sistema valida tudo antes de tocar no ERP.
O que corre mal quando a IA escreve SQL livre?
A técnica chama-se "text-to-SQL": a pergunta entra em português, o modelo devolve uma consulta, o sistema executa-a e mostra o resultado. Há três problemas, e nenhum é teórico.
Primeiro, o modelo erra sem avisar. A própria ficha do modelo do AMALIA, o modelo de linguagem português lançado este ano, diz-o com uma honestidade que se agradece: o modelo pode alucinar, os resultados devem ser verificados sempre que a exatidão importa, e não deve servir de autoridade de decisão em domínios onde os erros têm consequências sem uma pessoa qualificada pelo meio. Não é um defeito do AMALIA; vale para qualquer modelo, nacional ou americano. Mas repara no que acontece com SQL: uma consulta mal escrita não dá erro, dá um número. Um JOIN a mais e as faturas aparecem a dobrar. Um filtro de datas com < em vez de <= e perdes o último dia do trimestre. O resultado parece plausível, vem formatado, e ninguém desconfia.
Segundo, o esquema do teu ERP não é óbvio. Um ERP como o PHC tem centenas de tabelas, campos com nomes herdados de há vinte anos, documentos anulados que continuam na base de dados, notas de crédito que abatem faturas noutra tabela. O que a tua empresa chama "vendas" (líquido de devoluções? com ou sem IVA? só faturas, ou também vendas a dinheiro?) não está escrito em lado nenhum do esquema. Um modelo que não conhece estas regras inventa uma interpretação. E cada vez que a pergunta muda ligeiramente, pode inventar outra.
Terceiro, segurança. Mesmo com um utilizador de base de dados só de leitura, SQL livre deixa o modelo ler tudo o que esse utilizador vê: salários, dados pessoais de clientes, margens por comercial. Basta alguém pedir "mostra-me a tabela de funcionários" ou um PDF de fornecedor trazer instruções escondidas. Restringir isto depois de o modelo poder escrever qualquer consulta é tapar buracos um a um.
Como funciona um catálogo de consultas aprovadas?
A ideia é simples: tiramos ao modelo a parte em que ele é fraco (escrever código exato contra um esquema que não conhece) e deixamos-lhe a parte em que é bom (perceber o que a pessoa quer, em português).
Na prática, o projeto começa com uma lista. Sentamo-nos contigo e com quem faz as perguntas todos os dias, e recolhemos as perguntas reais. Numa PME típica, a maioria cabe numas poucas dezenas de consultas. Por exemplo, um catálogo de 30, que é a ordem de grandeza com que costumamos arrancar um piloto:
- saldo em dívida de um cliente, por antiguidade;
- faturação por cliente, por período, com ou sem notas de crédito;
- referências abaixo do stock mínimo, por armazém;
- encomendas de cliente em aberto há mais de N dias;
- produção concluída vs. planeada, por semana.
Cada consulta é escrita por nós, à mão, contra o teu ERP, e revista contigo. Tem um nome, uma descrição em português, parâmetros com tipo (um cliente que tem de existir, uma data, um armazém de uma lista fechada) e uma definição de negócio explícita: "faturação = faturas e vendas a dinheiro, menos notas de crédito, sem IVA, documentos anulados excluídos". Essa definição é discutida uma vez, assinada por ti, e passa a ser a mesma para toda a gente.
Quando alguém pergunta, o modelo faz só três coisas: escolhe a consulta do catálogo que corresponde à pergunta, extrai os parâmetros ("Metalúrgica Silva", "este trimestre") e, no fim, redige a resposta com os números que a consulta devolveu. Entre a escolha e a resposta, há código normal, determinístico, que:
- confirma que a consulta existe no catálogo e que o perfil de quem pergunta a pode usar (o armazém não vê margens; o comercial só vê os seus clientes);
- valida os parâmetros: o cliente existe? há dois clientes com nome parecido? Se sim, pergunta qual;
- executa a consulta com uma ligação só de leitura;
- regista tudo: quem perguntou, a pergunta original, a consulta escolhida, os parâmetros, os números devolvidos e a resposta final.
Se nenhuma consulta do catálogo serve, o assistente diz que não sabe responder a isso e regista a pergunta. Não improvisa.
Como fica uma conversa real no WhatsApp?
Um exemplo, com números ilustrativos:
Pergunta: Quanto nos deve a Metalúrgica Silva?
Resposta: A Metalúrgica Silva tem 18 420,50 € em aberto, em 7 faturas. 6 980 € estão vencidos há mais de 60 dias (FT 2026/1184 e FT 2026/1203). Fonte: consulta "Saldo de cliente por antiguidade", dados do ERP às 09:42.
Pergunta: E o que lhe faturámos este trimestre?
Resposta: Entre 1 de julho e 30 de setembro: 41 300 € sem IVA, já descontadas 2 notas de crédito (1 150 €). Fonte: "Faturação por cliente e período".
Pergunta: Que referências estão abaixo do mínimo no armazém 2?
Resposta: 4 referências: … (lista com quantidade atual e mínimo).
Pergunta: Qual foi a margem do Rui em setembro?
Resposta: Essa informação não está disponível para o teu perfil.
Repara na última: não é o modelo a decidir que não deve responder. É a regra de acesso, em código, que nem sequer lhe entrega a consulta.
Mas isso não é só um relatório com outro nome?
É a objeção mais justa, e a resposta é: em parte, sim. E ainda bem.
Os relatórios do ERP já têm as consultas certas. O que não têm é a porta de entrada. Para os usar, tens de saber que existem, em que menu estão, que filtros preencher e como ler o resultado. O assistente troca essa parte por uma pergunta em português, a partir do telemóvel, no armazém ou na estrada. Percebe "este trimestre", "o Silva" e "o que está para trás". Junta duas consultas numa resposta ("deve 18 mil, faturámos 41 mil este trimestre"). E escreve em português europeu, que é precisamente para o que modelos como o AMALIA foram pensados.
O ganho não está em a IA saber mais do que o teu ERP. Está em a pergunta deixar de depender de quem sabe mexer no ERP.
E o catálogo cresce. Cada pergunta a que o assistente não soube responder fica no registo. Ao fim de um mês, tens uma lista ordenada das perguntas que a tua equipa faz e que não estavam previstas. Escolhes as que valem a pena, nós escrevemos a consulta, tu aprovas a definição, e entra no catálogo. É um processo lento de propósito: cada número que sai do assistente tem uma consulta revista por trás.
E perde-se flexibilidade?
Perde-se, e é uma troca consciente. Um sistema com SQL livre responde a mais perguntas no primeiro dia. Um sistema com catálogo responde a menos, mas cada resposta é reproduzível: a mesma pergunta amanhã dá o mesmo número, e se o teu contabilista perguntar de onde veio, há uma consulta com nome e um registo com data e hora.
Para análise exploratória ("descobre-me padrões nas vendas") há ferramentas melhores, usadas por quem sabe ler o resultado. Para a pergunta operacional de todos os dias, feita por quem não tem tempo para verificar o SQL, a previsibilidade vale mais do que a amplitude.
Que modelo está por trás, e onde correm os dados?
A arquitetura é agnóstica ao modelo. Como o modelo só escolhe consultas e redige respostas, pode ser um modelo nacional como o AMALIA ou outro modelo alojado na UE, escolhido em função das tuas perguntas e do teu orçamento. Trocar de modelo não muda as consultas, as permissões nem o registo de auditoria. Essa é outra vantagem do catálogo: o conhecimento do teu negócio fica do teu lado, não no modelo.
Os dados do ERP são lidos por uma ligação só de leitura e processados na UE. O acesso é por perfil (RBAC). O RGPD entra no desenho: o catálogo define, consulta a consulta, que dados pessoais podem sair, e o que não está no catálogo não sai. No WhatsApp há um limite honesto a ter em conta: a mensagem passa pela infraestrutura da Meta, por isso as respostas devem levar só o necessário.
Não tens de arrancar nem migrar nada. O PHC, ou o ERP que tiveres, continua a ser a fonte de verdade.
Por onde começar?
Por um departamento e pelas 10 a 20 perguntas que esse departamento faz mais vezes. Escrevemos essas consultas, revemos as definições contigo, ligamos o assistente ao teu ERP só em leitura e medimos durante um mês: quantas perguntas foram respondidas, quantas ficaram sem resposta, quantas horas deixaram de ir para exportações e prints. Se os números não convencerem, ficas com um catálogo de definições de negócio revistas, o que já vale alguma coisa.
Somos uma equipa pequena em Leiria: falas diretamente com quem escreve as consultas, não com um gestor de conta.
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.
