Aprovação humana no n8n: como revisar ações de agentes

Para exigir aprovação humana no n8n, conecte as ferramentas que executam ações ao passo de Human review do AI Agent e configure o canal de revisão. Antes de liberar esse fluxo, confira se a pessoa recebe a proposta completa, se pode recusá-la e se a ação executada corresponde ao que aprovou. Um pedido genérico de “posso continuar?” não resolve uma alteração de CRM ou o envio de uma mensagem ao cliente.

Aprovar uma proposta concreta: o revisor deve conseguir identificar o destinatário, o registro afetado, os valores anteriores e novos e o efeito esperado. Se precisar reconstruir tudo em outra tela, a mensagem de revisão está incompleta.

Onde colocar a aprovação no fluxo

A documentação de Human-in-the-loop descreve uma pausa antes de executar ferramentas selecionadas. Aprovar libera a chamada com os parâmetros propostos; negar cancela essa ação e informa o agente. Isso permite revisar apenas as ferramentas que precisam desse controle.

Na prática, separe consulta, preparação e execução. Consultar um catálogo ou preparar um resumo pode ser parte do caminho que produz a proposta. Enviar uma oferta, alterar o responsável de um negócio ou remover um registro tem outro efeito. Liste as ações que sua equipe quer revisar e identifique o nó ou serviço que realmente as realiza. O controle deve cobrir esse caminho inteiro, inclusive chamadas que o agente possa acionar indiretamente.

Evite uma segunda ferramenta capaz de realizar a mesma alteração sem passar pelo revisor. Se o agente pode escolher entre “enviar mensagem” e “chamar API”, proteger apenas a primeira opção deixa um caminho alternativo. Essa verificação é de arquitetura: nomes amigáveis de ferramentas e frases no prompt não demonstram que todos os caminhos de execução passam pela aprovação.

Como escolher o ponto de revisão no processo
Situação	Proposta que deve aparecer	Decisão da equipe
Enviar mensagem	Canal, destinatário e texto final	Conferir conteúdo e público antes de enviar
Atualizar CRM	ID, campo, valor anterior e novo	Conferir registro e significado da mudança
Excluir dado	Objeto exato e consequência da remoção	Avaliar se a exclusão é necessária e recuperável
Consultar informação	Escopo e acesso necessário	Definir se a consulta pode ocorrer sem nova revisão

Configuração nativa: do AI Agent ao canal de revisão

No AI Agent, abra o conector Tools. No painel, localize Human review, selecione um canal e configure suas credenciais. Conecte ao passo de revisão as ferramentas que precisam de aprovação e configure seus parâmetros. Esse é o procedimento apresentado pelo n8n; confirme os rótulos na sua instalação antes de reproduzir a sequência.

Escolha o canal pela rotina de quem decide. Uma equipe que trabalha no Slack pode preferir uma conversa restrita aos responsáveis. Outra pode usar Telegram, e-mail ou um canal de chat. Configure quem deve receber a solicitação e como acompanhar pendências. Ter uma integração disponível não comprova que qualquer participante do canal deva aprovar qualquer ação.

Levante também os requisitos fora do agente: conta do serviço, credenciais, permissões, conectividade e custos aplicáveis ao canal. Não considere uma assinatura de aplicativo como autorização automática para usar sua API. Este guia não estabelece preço, plano mínimo ou versão mínima universal, porque esses requisitos precisam ser conferidos para a combinação que você vai instalar.

Como mostrar os parâmetros que serão aprovados

O passo de revisão oferece $tool.name e $tool.parameters para compor a solicitação. Eles ajudam a mostrar a ferramenta e a entrada proposta. O nome é o do nó no canvas; os parâmetros incluem campos definidos com expressões $fromAI().

Ferramenta: {{ $tool.name }}
Entrada proposta:
{{ JSON.stringify($tool.parameters, null, 2) }}

Use esse exemplo como ponto de partida, acrescentando contexto que a equipe consiga interpretar. Um JSON com stage_id pode ser tecnicamente completo e ainda deixar o gestor sem entender para qual etapa o cliente será movido. Mostre o nome da etapa junto ao identificador, preservando o vínculo entre a apresentação e a entrada que será executada.

A função $fromAI() permite ao modelo preencher parâmetros de ferramentas conectadas ao agente; ela não funciona em qualquer campo do workflow e tem exceções documentadas, como a ferramenta Code. Uma descrição do parâmetro orienta o modelo, mas não substitui validações do valor produzido.

No desenho que recomendamos, dados estáveis ficam sob controle do fluxo: projeto, conta, lista permitida de destinos e operação disponível. A IA propõe o conteúdo que realmente precisa elaborar. Para atualizar um negócio, por exemplo, o identificador pode vir de uma consulta anterior e a proposta de observação pode vir do agente. Depois, a implementação confere se ambos pertencem à mesma solicitação.

Exemplo: proposta de atualização no CRM

Imagine um agente que resume uma conversa comercial e sugere mover o negócio para “proposta solicitada”. A mensagem ao gestor apresenta o negócio, o cliente, a etapa atual, a etapa proposta e a evidência da conversa. O responsável pode avaliar a alteração sem confiar somente na frase “o cliente está interessado”. Esse é um exemplo de desenho, não uma integração pronta com um CRM específico.

A consulta encontra o negócio e seu estado atual.
O agente prepara uma proposta com a alteração e a justificativa.
O fluxo confere os campos obrigatórios e o destino permitido.
A revisão humana apresenta o efeito concreto da proposta.
Com aprovação válida, a execução aplica essa proposta.
O retorno do CRM informa sucesso, falha ou necessidade de conferência.

Para uma implementação própria, uma proposta poderia carregar os campos abaixo. Eles são um modelo editorial de registro; não são uma resposta padrão do nó de Human review.

{
  "proposta_id": "crm-demo-001",
  "registro_id": "negocio-demo",
  "campo": "etapa",
  "valor_anterior": "qualificacao",
  "valor_proposto": "proposta_solicitada",
  "decisao": "aguardando"
}

Se o negócio mudar enquanto alguém revisa, a proposta pode ficar desatualizada. A recomendação editorial é conferir novamente o estado relevante antes de executar. Se houver divergência, apresente a mudança ao responsável e peça uma decisão sobre a proposta atual. Aprovar uma alteração sobre dados antigos não é necessariamente aprovar a alteração sobre o registro que existe agora.

Para mensagens, aplique o mesmo cuidado ao texto e ao destinatário. Se a IA reformular o conteúdo depois da aprovação, o responsável precisa revisar a nova versão. Não trate uma aprovação como permissão aberta para variar canal, público, anexo ou condição comercial. Defina esses elementos no pedido concreto que será liberado.

Recusa, ausência de resposta e falha são estados diferentes

O prompt deve explicar quais ferramentas dependem de aprovação e como responder à recusa. Oriente o agente a informar o resultado recebido, pedir esclarecimento quando necessário e respeitar a decisão. Se o retorno apenas disser que a proposta foi negada, ele não deve inventar o motivo. Também não deve tentar a mesma ação por outra ferramenta para contornar a revisão.

Um prompt operacional pode dizer: “Quando uma proposta for negada, não execute essa ação. Informe a recusa sem inventar justificativa. Use o comentário do revisor quando existir. Prepare outra proposta apenas quando houver informação ou solicitação que justifique a mudança, submetendo-a à revisão.” Essa é uma recomendação de texto para adaptar ao seu processo, não um mecanismo técnico de autorização.

Ausência de resposta também precisa de tratamento. No nó Wait, opções de prazo podem retomar a execução automaticamente. Retomar não equivale a receber aprovação. Se você desenhar a revisão com espera e webhook, valide explicitamente a decisão antes de chegar à ação e use a autenticação disponível para a retomada.

Como política editorial de implementação, propostas vencidas devem ter um destino definido: permanecer pendentes, expirar ou voltar ao responsável. Evite deixar o ramo de continuação executar uma alteração apenas porque terminou o tempo de espera. Registre a diferença entre “ninguém respondeu” e “alguém aprovou” para que a equipe consiga recuperar o trabalho sem repetir ações por engano.

Depois da aprovação, a API de destino ainda pode falhar. O n8n oferece error workflows e consulta de execuções para tratar erros. No seu processo, separe aprovação de confirmação da ação. Uma resposta incerta exige consulta ao destino antes de repetir um envio ou uma atualização que possa ter ocorrido.

Chat e histórico: confira o alcance de cada opção

O nó Chat tem Send and Wait for Response e respostas de aprovação. Ele exige Chat Trigger com Using Response Nodes, e a documentação registra limitações para Embedded, sub-workflows e determinados usos com subagentes. Não transfira uma configuração de chat para toda arquitetura sem conferir essas condições.

O histórico de uma conversa pode ajudar a investigar uma decisão, mas não demonstra sozinho identidade autorizada, vínculo com a proposta, retenção ou integridade do registro. Para uma trilha operacional, recomendamos guardar proposta, decisão recebida, identidade disponibilizada pelo canal, momento da resposta e resultado no destino. Confira quais dados o canal realmente retorna antes de prometer uma auditoria completa.

Defina também quem pode ver a proposta. O revisor pode precisar do conteúdo comercial sem precisar receber tokens, senhas ou dados pessoais que não ajudam na decisão. A mensagem de aprovação deve ser suficiente para avaliar o efeito, com acesso adequado ao processo. Esse desenho depende do contexto da empresa; a presença de botões de aprovação não certifica conformidade jurídica.

Checklist de validação antes de liberar

Conferir se todas as ferramentas que executam a ação passam pela revisão.
Apresentar proposta completa e identificadores compreensíveis.
Testar aprovação e comparar o efeito com os valores apresentados.
Testar recusa e confirmar que a ação não ocorreu.
Testar silêncio ou expiração sem liberar a ação automaticamente.
Testar proposta alterada ou registro modificado durante a espera.
Testar erro no destino e uma resposta cujo resultado seja incerto.
Conferir responsáveis, acesso, registro e recuperação de pendências.

Faça esses testes com destino controlado, dados fictícios e ações que não afetem clientes. Guarde o que aconteceu em cada cenário, incluindo a versão do workflow e os parâmetros usados. Uma demonstração em que todos clicam “aprovar” não verifica o comportamento quando a proposta é recusada, vencida ou executada com erro.

Perguntas frequentes

Preciso aprovar toda consulta do agente?

Defina a política por efeito e contexto. Consultar uma informação autorizada pode ter um tratamento diferente de enviar ou alterar algo. O essencial é identificar os caminhos que executam a ação e revisar aqueles que sua operação exige.

Um aviso no System Prompt é suficiente?

O prompt orienta o agente. O controle de execução precisa estar no fluxo e nas ferramentas disponíveis. Revise também caminhos alternativos, permissões do destino e os dados que serão liberados pela decisão.

Negar significa que o fluxo inteiro foi encerrado?

A recusa cancela a ação revisada. Confira o que seu fluxo faz a seguir: informar o usuário, registrar a decisão ou preparar outra proposta são comportamentos diferentes. Não prometa encerramento total sem validar o desenho completo.

A aprovação garante que o CRM foi atualizado?

Não. Ela autoriza uma proposta; a execução ainda precisa receber confirmação do destino. Mantenha resultado e aprovação separados para tratar falhas, respostas incertas e recuperação sem duplicar ações.

Próximo passo: revisar uma ação concreta

Comece com uma operação que a equipe consiga reconhecer e verificar, como atualizar um campo específico do CRM. Documente proposta, decisão e retorno, teste os caminhos de recusa e erro e só então amplie o escopo. A aprovação humana funciona melhor quando o responsável entende o que está liberando e a implementação preserva esse vínculo até a execução.