Porque é que o vosso agente de IA não é fiável para escalar
Construíram um agente em n8n ou em cima do ChatGPT. Na demo funcionou. Duas semanas depois, alguém da equipa pergunta "podemos confiar nisto para os clientes todos?" — e a resposta honesta é não. Este artigo explica porquê, e o que separa um protótipo que impressiona de um agente que aguenta uma operação.
Porque é que o agente funciona na demo e falha em produção?
Porque a demo testa o caminho feliz e a produção testa tudo o resto. Na demo, o input é limpo, a API responde, e quem está a ver quer que funcione. Em produção, o agente recebe um PDF digitalizado de lado, a API do CRM devolve um timeout, e ninguém está a olhar.
Os protótipos falham nos mesmos cinco pontos, quase sempre por esta ordem:
- Inputs reais. Emails com seis threads coladas, anexos errados, clientes que escrevem "amanhã" sem dizer de que dia estão a falar. O protótipo assume estrutura; a realidade não tem.
- Falhas silenciosas. O passo 7 do workflow falha, o n8n marca o run a vermelho, e ninguém recebe aviso. O lead perdeu-se e só se descobre na sexta.
- Sem critério de "não sei". Um agente fiável precisa de saber quando NÃO deve agir e passar o caso a uma pessoa. A maioria dos protótipos responde sempre — com confiança, mesmo quando está errado.
- Custos sem teto. Um loop mal desenhado ou um documento gigante e a fatura da API decuplica num dia. Sem limite de custo por execução, o agente é um risco financeiro.
- Ninguém mede nada. Se não há registo do que o agente decidiu e porquê, não há como saber se está a melhorar ou a piorar. "Parece que funciona" não é uma métrica.
O que é que um agente de produção tem que o protótipo não tem?
Quatro coisas, e nenhuma delas é um modelo melhor:
| Componente | O que faz | Sem isto |
|---|---|---|
| Evals | Conjunto de casos de teste reais corridos a cada alteração | Cada "melhoria" pode partir o que já funcionava |
| Audit log | Registo de cada decisão: input, output, fundamentação | Impossível investigar erros ou provar compliance |
| Escalação humana | Regras explícitas de quando parar e entregar a uma pessoa | O agente erra com confiança em casos ambíguos |
| Teto de custo por execução | Limite duro de tokens/chamadas por run | Faturas imprevisíveis; loops infinitos pagos a peso de ouro |
Nada disto aparece numa demo — e é exatamente por isso que as demos enganam. O modelo é talvez 20% do trabalho; a infraestrutura de fiabilidade à volta é o resto.
O n8n é o problema?
Não — usamo-lo em produção em clientes reais, e escrevemos um guia para começar com agentes em n8n. O n8n é uma excelente ferramenta de orquestração. O problema é tratar a ferramenta como se fosse a solução completa.
Um workflow n8n torna-se um agente de produção quando alguém desenha o tratamento de erros, escreve os evals, define a escalação e monitoriza os KPIs. Isso é trabalho de engenharia, não de configuração. A ferramenta não o faz sozinha — nem o n8n, nem o Zapier, nem o GPT mais recente.
Quando é que vale a pena investir em fiabilidade?
Quando o custo do erro deixa de ser teórico. Um agente que qualifica leads e perde 5% deles em silêncio custa pipeline real todos os meses. Um agente que responde a clientes e alucina preços custa reputação. A conta é simples: multiplicar a taxa de erro pelo custo de cada erro e comparar com o custo de fazer bem.
Para a maioria das PMEs, a sequência sensata é a que descrevemos nos 7 agentes de IA para transformar a empresa: começar com um workflow de alto impacto, pô-lo fiável a sério, medir o ROI — e só depois escalar para o segundo. O contrário (dez protótipos, zero em produção) é o padrão que mais vemos quando uma empresa nos chega já frustrada com IA.
Como saber em que estado está o vosso agente?
Cinco perguntas, respostas honestas:
- Se o agente falhar às 3 da manhã, alguém fica a saber antes do cliente?
- Conseguem dizer quantos erros cometeu na última semana — com números?
- Há casos em que ele para e entrega a uma pessoa, ou responde sempre?
- Sabem quanto custa cada execução, e existe um máximo?
- Quando mudam o prompt, conseguem provar que não pioraram nada?
Três ou mais "não": têm um protótipo, não um agente. É um bom ponto de partida — a maior parte do nosso trabalho em agentes de IA começa exatamente aí: pegar num protótipo que mostrou potencial e construir-lhe a fiabilidade que falta, com evals, audit log e teto de custos desde o primeiro dia.