O teu ERP já traz IA. A Sage meteu-a nos fluxos financeiros, o Business Central tem-na dentro da ficha, o Odoo integrou-a de raiz na versão 19 e o Holded vende-a no painel. Se pagas qualquer um dos quatro, a pergunta que estás a fazer é justa: já tenho IA incluída, para quê contratar alguma coisa por fora?
A tese numa frase: o copiloto do fabricante resolve muito bem o que acontece dentro de um ecrã — resumir, sugerir, preencher, explicar um registo que tens à frente — e não resolve nada do que atravessa sistemas, que é precisamente onde está o trabalho caro. E o ponto não é que ainda não o faça: não está construído para isso. É uma fronteira de arquitetura, não uma linha pendente no roadmap deles.
IA nativa do ERP vs agente externo: a fronteira não é de funções, é de arquitetura
Olha para o que os copilotos nativos fazem mesmo e vais ver que têm todos a mesma forma. No Odoo 19 a IA deixou de ser um módulo à parte: a documentação oficial descreve agentes construídos a partir de tópicos — as instruções que dizem ao agente o que fazer — e ferramentas associadas a esses tópicos. No Business Central, a função mais citada pelas equipas financeiras é a reconciliação bancária assistida: propõe correspondências entre as linhas do extrato importado e os lançamentos do razão, e sugere a conta para as que não batem. Na Sage, o copiloto vive dentro dos fluxos financeiros e o seu agente de importação corta a preparação manual de dados em migrações e importações recorrentes.
É bom produto. Repara no que têm em comum: os três trabalham sobre dados já dentro do sistema, no ecrã onde o utilizador já está, com as permissões desse utilizador, enquanto esse utilizador está a olhar. O ERP não é onde o copiloto vive: é todo o mundo dele. É essa a fronteira, e explica ao mesmo tempo o que faz bem e o que nunca vai fazer.
As três coisas que o copiloto nativo te dá e que devias estar a usar
- Explicar-te um registo que já tens aberto. Resumir o histórico de um cliente, dizer-te porque é que esta fatura está assim, traduzir um lançamento para linguagem humana. Contexto imediato sobre dados que o sistema já tem e a que já tens direito.
- Propor dentro de um formulário, com as regras do próprio sistema. Reconciliação bancária, conta sugerida, descrição de produto, texto de uma proposta. O fabricante joga em casa: ninguém conhece melhor o seu modelo de dados, e as sugestões respeitam as suas próprias validações.
- Perguntar aos teus dados sem construir um relatório. O que antes era pedir uma listagem a alguém e esperar dois dias agora é uma frase. Não é pouco: é a diferença entre decidir com dados e decidir de cor.
Isto vem incluído no que já pagas, por isso ativá-lo e formar as pessoas é das decisões mais baratas que vais tomar este ano. Quem te disser o contrário está a vender-te alguma coisa. Nós também: por isso dizemo-lo primeiro.
As três que nunca te vai dar, e porque é arquitetura e não roadmap
Agora o outro lado. Há três tipos de trabalho que o copiloto do fabricante não faz, e nenhum dos três se resolve à espera da versão seguinte.
- O trabalho que atravessa sistemas. A fatura chega por email, a guia de remessa é um PDF do fornecedor, a encomenda vive no ERP e a reclamação resolveu-se por WhatsApp. Fazer bater estas quatro coisas é o trabalho que custa dinheiro, e três das quatro estão fora do ERP. Um copiloto que só vê uma delas não o consegue fechar, por muito bom que seja.
- O trabalho que espera por alguém de fora. Um orçamento à espera do sim do cliente, um fornecedor que não responde, uma aprovação parada há quatro dias. Aí o estrangulamento não é perceber o dado: é andar atrás de uma pessoa que não tem o teu ERP aberto nem o vai abrir.
- O trabalho que acontece quando ninguém está a olhar. Os processos que correm de madrugada, encontram uma exceção e têm de decidir se escalam. O copiloto precisa de um utilizador à frente que lhe peça alguma coisa; a sua unidade de trabalho é a sessão, não o processo.
A razão de fundo é a mesma nos três casos. O copiloto nativo herda três limites do sistema que o aloja: o limite do dado (só vê o que está lá dentro), o limite das permissões (age como o utilizador que o invoca, nem mais nem menos) e o limite do relógio (começa quando alguém escreve e acaba quando essa pessoa fecha o ecrã). Um agente que atravessa processos precisa exatamente do contrário: identidade própria, permissões próprias limitadas à sua tarefa, e um relógio só dele. Isso não é uma função que a Sage ou a Microsoft possam acrescentar na release da primavera: é outro objeto.
A partir de onde compensa o que está por fora
A pergunta não é «de quanta IA preciso», que não tem resposta. É uma bem mais aborrecida e essa sim mensurável: quantas vezes por dia é que alguém tem de sair do teu ERP para terminar um trabalho? É esse número que decide, e podes contá-lo esta semana sem comprar nada.
- Conta os saltos. Pega em três processos que doem e anota cada vez que alguém sai do ERP para os completar: abrir o email, procurar o PDF, escrever por WhatsApp, entrar no portal do fornecedor. Cada salto é trabalho que o copiloto nativo não vê.
- Mede a espera, não a digitação. O custo real quase nunca é o minuto a escrever: é o tempo em que o trabalho está parado à espera de alguém. Um orçamento que espera quatro dias não custa quatro minutos de administrativo, custa quatro dias de tesouraria.
- Põe preço no erro tardio. Os erros descobertos dentro do ecrã são baratos; os descobertos três semanas depois, no fecho ou na fatura ao cliente, não são. Conta quantos dos últimos dez foram descobertos tarde.
Se os três números saírem baixos, ainda bem: ativa o copiloto, forma a equipa e não gastes mais. Se saírem altos — e na maioria das PME com vários sistemas saem altos — identificaste, com nome e apelido, exatamente onde é preciso algo que o fabricante não vende.
| Dimensão | Copiloto nativo do ERP | Agente que atravessa sistemas |
|---|---|---|
| Unidade de trabalho | O ecrã / a sessão | O processo de ponta a ponta |
| Que dados vê | Os que estão dentro do ERP | ERP + email + documentos + mensagens |
| Com que permissões age | As do utilizador que o invoca | Identidade própria, limitada à sua tarefa |
| Quando arranca | Quando alguém lho pede | Quando o evento acontece, com ou sem plateia |
| Quem responde se falha | O fabricante, dentro do produto dele | Tu: turno, rasto e procedimento |
O erro caro: pagar duas vezes pela mesma coisa
Há uma forma de errar em cada direção. Uma é a que abre este artigo: dar por garantido que o copiloto incluído cobre tudo, e passar mais um ano com três pessoas a fazer bater documentos à mão. A outra vai ao contrário e vê-se menos: montar por fora o que o fabricante já te dá por dentro, acabando a pagar duas vezes uma reconciliação bancária e a manter uma integração frágil que o ERP fazia sozinho.
A ordem certa é a aborrecida: primeiro ativas e espremes o que já vem incluído; depois medes o que continua a sair pela porta; e só então constróis por fora, e só aí. Quando esse momento chegar, a decisão técnica não é «que IA compro» mas como se lança a ponte para os sistemas que já tens — API, camada de orquestração ou MCP —, que é o tema do guia sobre integrar a IA com os teus sistemas sem refazer nada. E a segunda decisão, a que afunda mais projetos por chegar tarde, é em que superfície vive esse agente: dentro do próprio ERP, no Teams, no email ou no WhatsApp, conforme onde já está a pessoa que o vai usar. Essa comparação está em em que canal pôr um agente de IA.
O que fazemos nós, sem enfeite
Não vendemos outro ERP nem te pedimos que mudes o que tens. Montamos por cima o pedaço de processo que o teu ERP não consegue cobrir porque está fora dele: o documento que chega por email, a aprovação que alguém tem de dar do telemóvel, a exceção que aparece às três da manhã. Com nome concreto conforme onde vives: IA sobre Sage, sobre Business Central, sobre Odoo ou sobre Holded. E quando o trabalho atravessa vários sistemas ao mesmo tempo, isso é automatização de operações no sentido literal: o processo inteiro, não o ecrã.
O resumo cabe numa linha e convém tê-la clara antes da próxima reunião com o teu parceiro: o copiloto é uma função do teu ERP; o agente é um processo que atravessa o teu ERP. Confundi-los sai caro nas duas direções — ou pagas duas vezes, ou esperas dois anos por uma versão que não vai chegar, porque o que precisas não cabe dentro do produto.