«Tenho stock para aceitar esta encomenda ou aquilo já está reservado?» Abres o ERP, exportas existências, pedes as reservas ao armazém e cruzas tudo no Excel. Entretanto, alguém expede uma encomenda. Quando acabas, os dois ficheiros já não descrevem o mesmo momento.
Um ChatGPT privado para empresas pode encurtar esse caminho. Mas, se consultar o stock primeiro e as reservas depois, pode entregar-te uma resposta rápida que nunca correspondeu à realidade. Antes de discutir que modelo responde melhor em português, precisas de perguntar: os números desta resposta pertencem ao mesmo estado dos dados?
Porque não basta perguntar a um chat público?
Copiar ficheiros para um serviço público envia informação para outro fornecedor. A localização do tratamento, a retenção e a utilização dependem do serviço e do contrato; não deves assumir residência na UE. Também não tens automaticamente os perfis de acesso e a auditoria do teu ERP. O modelo pode inventar uma explicação quando faltam dados, e o português europeu precisa de ser validado.
Há uma dificuldade menos visível: mesmo sem inventar nada, pode repetir números incompatíveis recebidos do conector.
O Barómetro HeraPrime de outubro de 2026 encontrou utilização de ERP em 77% das 57 empresas participantes, mas IA estruturada em apenas 14%. A amostra era voluntária e concentrada na região de Lisboa; não representa todas as PME. Ilustra, ainda assim, a pergunta útil: como tornar consultáveis os sistemas existentes sem perder rigor?
Como podem duas consultas certas produzir uma resposta errada?
Considera este exemplo inteiramente fictício, com uma única referência no armazém 2. Para simplificar, disponibilidade significa stock físico menos reservas, sem outros bloqueios.
Às 09:00:00, o ERP tem 100 unidades físicas e 40 reservadas. Estão disponíveis 60.
O assistente começa por ler o stock: recebe 100. Logo depois, o armazém confirma a expedição de 30 unidades reservadas. Neste exemplo, o ERP grava a redução do stock e das reservas na mesma transação: ficam 70 unidades físicas e 10 reservadas. Continuam disponíveis 60.
Só então o assistente consulta as reservas: recebe 10. Subtrai corretamente 100 menos 10 e responde: «Tens 90 disponíveis.»
A conta está certa. A resposta está errada. Misturou o stock anterior à expedição com as reservas posteriores. Nenhum dos dois estados tinha 90 unidades disponíveis. Não foi uma alucinação do modelo: foi uma falha na composição dos dados.
Perto do fecho de outubro, quando cruzas movimentos e saldos, esta diferença interessa mais do que uma resposta bem escrita.
O que significa consultar tudo no mesmo instante?
Não significa executar todas as consultas no mesmo milissegundo. Significa que as leituras usadas numa resposta observam uma versão coerente dos dados, mesmo que entretanto ocorram movimentos.
A documentação do PostgreSQL 16 distingue dois comportamentos. Em Read Committed, cada consulta vê um novo instantâneo dos dados confirmados. Colocar duas consultas dentro da mesma transação não basta. Em Repeatable Read, as leituras seguintes mantêm o instantâneo estabelecido pela primeira instrução relevante da transação.
Numa integração só de leitura, isso permite recolher stock e reservas sobre a mesma fotografia lógica. A implementação deve manter a transação curta, com limites de execução, para não prejudicar o sistema operacional.
Isto não é uma receita universal para qualquer ERP. Num PHC, por exemplo, é preciso validar a base de dados, a versão e a interface efetivamente disponíveis. O conector deve usar o mecanismo adequado ao sistema, não copiar comandos de PostgreSQL para outra tecnologia.
E uma fotografia coerente pode estar atrasada. Consistência e atualidade são coisas diferentes. Uma réplica atualizada há cinco minutos pode fornecer números coerentes entre si, mas inadequados para prometer uma entrega imediata.
O que deve existir à volta do modelo nacional?
Quem procura «AMALIA IA português» procura frequentemente uma experiência em português europeu com controlo sobre os dados. A arquitetura que propomos é agnóstica ao modelo: pode usar um modelo nacional ou outro alojado na UE, conforme os testes e os requisitos. Não pressupõe uma implementação Leiritech já em produção sobre o AMALIA.
O trabalho decisivo está à volta: conector só de leitura, interpretação da pergunta, consultas controladas e resposta com valores verificáveis. O ERP mantém-se; não é preciso substituí-lo para criar esta camada.
A fonte deve identificar o sistema, a referência, o armazém e o critério de leitura. O registo de auditoria deve associar utilizador, pergunta, consultas e mecanismo de consistência. Carimbar tudo com a hora de envio não prova que os dados foram lidos juntos.
A Caravela já anuncia processamento na UE e avaliação de integrações empresariais. A diferença a demonstrar não é «ter chat»: é mostrar como uma resposta composta preserva a coerência no teu ERP concreto.
Como seria perguntar ao ERP no WhatsApp?
Estas quatro interações são exemplos fictícios de funcionamento, não resultados de clientes. A coerência é exigida dentro de cada resposta; perguntas posteriores podem observar novos movimentos.
Tu: «Quanto temos da referência R-204 no armazém 2, descontando reservas?»
Assistente: «70 unidades físicas, 10 reservadas, 60 disponíveis. Fonte: existências e reservas do ERP, na mesma leitura coerente. Não foram incluídas entradas previstas.»
Tu: «Quanto vendemos hoje e quanto foi devolvido?»
Assistente: «8.400 € faturados e 400 € em notas de crédito: saldo de 8.000 €, sem IVA. Fonte: documentos contabilizados de hoje, lidos na mesma versão dos dados.»
Tu: «Quanto está vencido ao cliente C-118, descontando recebimentos?»
Assistente: «3.200 €. Fonte: documentos e recebimentos contabilizados, conciliados na mesma leitura. Transferências ainda não registadas não estão incluídas.»
Tu: «A ordem de produção OP-42 já terminou?»
Assistente: «Das 200 unidades previstas, estão registadas 150 concluídas e 50 por concluir. Fonte: ordem e movimentos de produção na mesma leitura. Isto não confirma capacidade para acabar hoje.»
O canal também conta. O WhatsApp envolve um fornecedor externo e não garante, por si, tratamento exclusivamente na UE. Se esse requisito não puder ser demonstrado para todo o percurso, usa a consola privada alojada na UE.
E se o stock e as reservas vierem de APIs diferentes?
Se uma API devolver stock e outra devolver reservas, lançar os pedidos em paralelo não cria uma fotografia comum. Horas próximas também não provam consistência.
É necessário um mecanismo suportado pelas fontes: uma versão comum de leitura, por exemplo. Sem isso, o assistente deve explicar a limitação e não apresentar a disponibilidade como garantida. Repetir os pedidos pode reduzir discrepâncias, mas não demonstra que deixaram de existir.
Também não escreve no ERP, não reserva material e não decide por ti. Mesmo uma resposta coerente pode ficar ultrapassada antes de confirmares a encomenda.
Como testar isto num piloto pequeno?
Começa pelo armazém e por 10 a 20 perguntas frequentes. Define referências, unidades, reservas e quem pode consultar cada informação. Dados desorganizados ou movimentos registados separadamente não ficam corretos por acrescentares IA.
Inclui um teste deliberado: confirma uma expedição entre as duas leituras do exemplo. Aceita uma resposta correspondente ao estado anterior ou posterior, nunca a mistura. Se a integração não garantir coerência, deve dizê-lo.
Mede o tempo para obter e confirmar cada resposta, antes e depois do piloto. Converte a diferença e a frequência real das perguntas em horas poupadas, sem esconder a revisão humana.
Exige acesso por perfil, auditoria com retenção definida e dados na UE nos componentes contratados. Só de leitura não impede divulgação indevida; alojamento europeu não equivale a conformidade automática. RGPD por desenho inclui minimização e controlo de acessos.
Na Leiritech, em Leiria, falas diretamente com quem escreve o código, sem gestores 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.
