Uma equipe recebe pedidos de orçamento por mensagens, consulta o sistema, prepara os itens e pede ao responsável que confira as condições. Há trabalho repetitivo nesse percurso, mas também há decisões que não devem desaparecer dentro de uma automação. Se a inteligência artificial interpretar uma quantidade errada e o fluxo enviar o orçamento imediatamente, a velocidade apenas antecipará o problema.
Neste nono capítulo da série, vamos desenhar um fluxo com n8n que usa IA em uma etapa delimitada e conserva validação e aprovação antes da ação externa. O cenário é fictício e não foi executado em uma instalação do n8n ou conectado a um ERP real. A proposta é oferecer um roteiro verificável de arquitetura e teste, não um arquivo pronto para importar sem revisão.
Antes de escolher os componentes da automação, vale decidir onde a IA interpreta, quais ferramentas ficam disponíveis e como acompanhar o resultado. IA Além da Conversa aprofunda essa arquitetura de fluxos, ferramentas, avaliação e operação. Conheça a proposta e leia a degustação gratuita para avaliar como organizar uma solução além da tela de conversa. Para quem precisa definir responsabilidades e conduzir a adoção na equipe, Liderança Ampliada complementa o tema com preparação de decisões e governança, sem substituir o julgamento do gestor.
O conceito: um fluxo com IA não precisa ser um agente livre
O n8n permite construir fluxos de trabalho, chamados workflows, conectando componentes. Um nó, ou node, é um desses componentes: recebe, processa ou encaminha dados. As conexões organizam a passagem entre etapas, conforme a documentação de componentes de fluxo. Um gatilho é a entrada que inicia o processamento, como a chegada de uma solicitação em um canal definido.
O paradigma que proponho é uma automação estruturada com interpretação assistida. Automação estruturada significa definir antecipadamente as etapas, os critérios e os caminhos de falha. A IA pode ajudar a interpretar uma mensagem, mas não recebe autoridade para redesenhar o processo, escolher qualquer destinatário ou inventar uma operação do ERP. O fluxo conserva suas fronteiras mesmo quando a entrada vem em linguagem natural.
Um agente, neste contexto, é uma aplicação que utiliza o modelo para escolher ferramentas e encadear ações dentro de um ambiente. Essa abordagem pode ser útil quando a tarefa realmente exige escolhas variáveis. Para o exemplo de orçamento, minha preferência inicial é um caminho previsível: interpretar, validar, consultar, preparar, revisar e executar. Se esse desenho atender à necessidade, não há motivo para começar com autonomia ampla.
O ponto de conexão com o capítulo sobre MCP e capacidades delimitadas do ERP é a responsabilidade de cada operação. O n8n pode coordenar o percurso sem substituir as regras comerciais. MCP é uma possibilidade de conexão estudada anteriormente; neste artigo, o exemplo usa uma interface autorizada do sistema, sem exigir MCP como condição da automação.
Antes dos nós: definir o resultado e os limites
Minha proposta é automatizar a preparação de uma solicitação de orçamento, não aprovar condições comerciais nem enviar mensagens livremente. O resultado intermediário deve apresentar os itens reconhecidos, os dados consultados e as pendências. Essa delimitação permite saber se o fluxo terminou sua tarefa ou apenas encontrou uma parte da informação necessária.
Defina quem solicita, quem revisa e quem pode executar. A identidade do solicitante não deve ser inferida somente do texto da mensagem. Se alguém escrever “sou o diretor”, isso é conteúdo recebido, não autenticação. Proponho associar a entrada ao canal e à identidade verificados pela aplicação, e conferir as permissões no serviço responsável por cada operação.
Também é preciso combinar quais informações podem chegar ao modelo. Para interpretar uma lista de produtos, talvez não seja necessário enviar todo o cadastro do cliente, histórico financeiro ou dados de outros atendimentos. Minha recomendação é selecionar o mínimo necessário para a etapa e documentar a finalidade. Essa escolha deve abranger os registros do fluxo e os canais usados na revisão.
Antes de montar o piloto, escreva o que ele não fará. No cenário proposto, não altera preços, não aprova descontos, não efetiva pedidos e não resolve divergências silenciosamente. Esses limites tornam a discussão com o negócio mais concreta. Um fluxo visualmente pequeno ainda pode operar com uma credencial ampla; o desenho dos nós não demonstra, sozinho, o alcance real das permissões.
Da mensagem à proposta: onde a IA participa
Considere a entrada fictícia “preciso de cinco caixas do produto Alfa para a unidade Centro”. A etapa de interpretação tenta identificar produto, quantidade e unidade. Minha proposta é devolver campos estruturados, além de indicar o que não foi compreendido. Não há resposta produzida por modelo neste artigo; esse é o comportamento esperado para avaliar o piloto.
Campos estruturados são valores organizados em uma forma que o próximo componente consegue validar. O fluxo deve conferir se a quantidade tem o tipo e o intervalo permitidos e se os identificadores pertencem ao catálogo. “Caixa” pode ser uma unidade comercial específica: não se deve convertê-la em unidades individuais sem uma regra conhecida do ERP.
Quando a mensagem for ambígua, o caminho deve pedir esclarecimento. “Mande mais um lote” não informa necessariamente produto, tamanho ou destinatário. Proponho impedir que uma etapa posterior preencha essas lacunas por conveniência. A recusa de avançar pode ser o resultado correto, mesmo quando o modelo oferece uma interpretação plausível.
Depois da validação, a aplicação consulta a interface do ERP. API é uma interface pela qual programas solicitam operações ou dados a outros programas. O nó HTTP Request permite chamadas a serviços com API REST e configuração de autenticação. REST é um estilo de interface HTTP; o contrato concreto continua sendo o do sistema consultado.
No cenário proposto, a chamada deve usar destino e operação configurados pela equipe, não um endereço escolhido pelo modelo a partir da mensagem. O serviço verifica identidade, acesso à unidade e regras comerciais. Em seguida, prepara os dados da proposta. O modelo pode ajudar a redigir a explicação, mas a quantidade disponível e o preço autorizado devem vir da fonte responsável.
Aprovação de ferramenta e revisão de texto são controles diferentes
A documentação de revisão humana de ferramentas descreve uma pausa antes da execução de ferramentas específicas ligadas a um agente. O revisor recebe a ferramenta e os parâmetros propostos; pode aprovar ou negar. Se aprovar, a ferramenta executa com aquela entrada; se negar, a ação é cancelada. Esse recurso é diferente de revisar apenas a resposta final da conversa.
Na configuração documentada, a revisão é adicionada pelo painel de ferramentas do nó AI Agent, escolhendo o canal e conectando as ferramentas que exigem aprovação. A equipe deve conferir o recurso na versão instalada e suas credenciais. Não apresento capturas de interface ou um ensaio de configuração, pois este artigo não operou uma instalação do n8n.
Meu critério é posicionar o controle antes do efeito que exige autorização. Se o envio já aconteceu e só depois alguém revisa o texto, isso não é aprovação prévia. Em um fluxo estruturado sem agente escolhendo ferramentas, a mesma necessidade deve ser implementada como etapa explícita de revisão e decisão, com contrato próprio, e não presumida pela existência do recurso de agentes.
A solicitação de aprovação precisa apresentar cliente ou destinatário, produtos, quantidades, condições e ação prevista, segundo o caso. Proponho que esses dados venham do objeto validado que será executado. A síntese da IA pode facilitar a leitura, mas não deve ser a única representação do conteúdo: uma omissão na síntese não pode esconder uma alteração relevante.
Figura — Arquitetura proposta pelo autor. A aprovação antecede o efeito externo; nenhuma implementação n8n foi executada para este exemplo.
Depois da aprovação: executar apenas o que foi conferido
Minha recomendação é vincular a aprovação à versão exata da proposta, à identidade do revisor e ao prazo de validade definido pelo processo. Uma mudança de quantidade ou destinatário deve exigir nova revisão. A resposta “aprovado” dentro de uma mensagem recebida não comprova que a pessoa autorizada aprovou o objeto que será executado.
Também proponho verificar novamente as condições relevantes no momento da operação. Entre a preparação e a revisão, o estoque pode ter sido consumido ou a proposta pode ter expirado, conforme as regras do sistema. O ERP deve tratar esse conflito e devolver uma situação clara. A automação não deve aproveitar uma aprovação antiga para aceitar novas condições sem informar o responsável.
O resultado precisa distinguir proposta preparada, ação aprovada e ação concluída. São estados diferentes do processo, e a interface deve usar uma linguagem correspondente. Um orçamento preparado não foi necessariamente enviado. Um envio solicitado não está necessariamente confirmado. Essa clareza ajuda o usuário a decidir o próximo passo e facilita a investigação quando algo falha.
No trabalho diário, proponho manter um identificador para a solicitação e para a operação efetiva. Ele ajuda a relacionar entrada, aprovação e resultado. Não é preciso despejar todas as mensagens em um registro para obter rastreabilidade; o objetivo é preservar evidência suficiente sem criar uma nova exposição de dados sensíveis.
Falhas, repetição e o risco da duplicidade
Uma falha de comunicação não deve ser tratada como uma resposta comercial. Se a API de estoque estiver indisponível, a saída correta não é “não há produto”. O nó HTTP Request documenta retorno de status e cabeçalhos, além de limite de espera. Esses recursos ajudam a tratar a comunicação, mas a interpretação do resultado precisa seguir o contrato da API.
No fluxo proposto, estabeleça quais falhas interrompem o processo, quais pedem esclarecimento e quais podem ser repetidas com limites. Não recomendo habilitar uma opção que trate qualquer status como sucesso sem uma decisão explícita de tratamento. O recebimento de uma resposta HTTP e o sucesso da operação empresarial são verificações diferentes.
A documentação de tratamento de erros do n8n explica a associação de um fluxo de erro, iniciado por Error Trigger, para lidar com execuções que falham. Esse mecanismo pode apoiar alertas e investigação. Ele não demonstra que uma operação externa foi revertida nem resolve automaticamente os efeitos que ocorreram antes da falha.
Considere que o sistema registre a operação, mas a confirmação não chegue ao n8n. Repetir a chamada pode duplicar o resultado se não houver proteção. Minha proposta é uma operação idempotente, isto é, uma repetição da mesma solicitação não deve gerar um novo efeito indevido. O identificador e a regra de deduplicação precisam ser implementados no serviço; não basta pedir ao modelo que se lembre.
Quando o resultado for desconhecido, prefiro encaminhar para conferência ou consultar a situação pelo identificador antes de repetir. Também proponho uma saída humana para mensagens que a automação não consegue resolver. Encaminhamento é uma etapa prevista do serviço, não um fracasso que precisa ser escondido com uma resposta inventada.
Como avaliar utilidade e decidir se vale adotar
Comece em ambiente de testes, com dados fictícios e a execução externa desabilitada. Verifique a transformação da entrada em campos, a consulta e a proposta. Depois, examine a revisão e os caminhos de recusa. Só avance para um piloto limitado quando os responsáveis compreenderem onde ficam as credenciais, as regras e os registros.
Minha lista de casos inclui quantidade inválida, produto ambíguo, usuário sem acesso, serviço indisponível, rejeição do revisor, proposta alterada e solicitação repetida. Compare cada resultado com um comportamento esperado definido previamente. A metodologia continua a discussão do capítulo sobre testes com IA que realmente detectam defeitos: um caminho feliz não prova que os controles funcionam.
Avalie também o trabalho deslocado para o revisor. Uma automação que prepara dezenas de propostas incompletas pode aumentar a fila de conferência. Proponho medir erros de interpretação, retrabalho, tempo de revisão e resultados úteis, além do custo de modelos e operação. Não há ganhos quantitativos apresentados aqui, pois nenhum piloto foi medido.
A vantagem pretendida é organizar um percurso repetitivo e usar IA onde a linguagem livre acrescenta dificuldade. A contrapartida é manter mais componentes, credenciais e caminhos de falha. Se um formulário e uma integração convencional atenderem à necessidade, podem ser uma opção mais simples. A adoção deve decorrer do problema, não da vontade de colocar um agente em todo processo.
Conclusão
Automatizar tarefas de um ERP com n8n e IA exige preservar a distinção entre interpretar, propor, aprovar e executar. O fluxo pode coordenar essas etapas, mas as permissões e regras comerciais continuam pertencendo aos sistemas responsáveis. Aprovação humana útil precisa mostrar a ação real e acontecer antes do efeito externo.
O primeiro passo prático é escolher uma tarefa pequena, documentar sua saída e construir os caminhos de recusa e falha junto com o caminho esperado. Ao verificar esse comportamento com dados fictícios, a equipe terá condições melhores para decidir se o piloto deve avançar. O próximo capítulo tratará de uma ameaça que atravessa documentos e integrações: instruções maliciosas inseridas no conteúdo que a IA recebe.
Ao ampliar o fluxo, vale tratar recuperação de falhas, avaliação e custos como partes da solução, não como ajustes posteriores. IA Além da Conversa desenvolve essas decisões junto com automações, ferramentas e agentes. Consulte o sumário e a degustação gratuita para avaliar o aprofundamento arquitetural; a obra não dispensa testar o fluxo e suas permissões na instalação utilizada.
Referências
N8N. Handle errors gracefully. n8n Docs, [s. d.]. Disponível em: https://docs.n8n.io/build/flow-logic/handle-errors-gracefully. Acesso em: 2 out. 2026.
N8N. HTTP Request. n8n Docs, [s. d.]. Disponível em: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest. Acesso em: 2 out. 2026.
N8N. Human-in-the-loop for tools. n8n Docs, [s. d.]. Disponível em: https://docs.n8n.io/build/integrate-ai/ai-examples/human-in-the-loop-for-tools. Acesso em: 2 out. 2026.
N8N. Workflow components. n8n Docs, [s. d.]. Disponível em: https://docs.n8n.io/build/understand-workflows/workflow-components. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. Como gerar testes com IA e descobrir quando eles não provam nada. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/como-gerar-testes-com-ia-e-descobrir-quando-eles-nao-provam-nada/. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. IA Além da Conversa. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/ia-alem-da-conversa. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. Liderança Ampliada. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/lideranca-ampliada. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. MCP na prática: conectando a IA ao ERP sem dar acesso irrestrito. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/mcp-na-pratica-conectando-a-ia-ao-erp-sem-dar-acesso-irrestrito/. Acesso em: 2 out. 2026.
0 comentário(s)