Quando um agente de IA deve pedir aprovação humana?

Um agente pode consultar um pedido sem ajuda. O problema começa quando a mesma execução também pode enviar um e-mail, apagar um registro, publicar uma mudança ou alterar uma permissão. Se tudo pede confirmação, o time passa a clicar sem ler. Se nada pede, uma chamada mal interpretada pode produzir um efeito difícil de desfazer.

A resposta prática é classificar a ação, não o agente inteiro. Leituras e mudanças reversíveis podem seguir de forma autônoma. Ações de impacto alto ou difíceis de reverter devem parar antes do efeito externo. A execução durável para agentes de IA complementa este desenho quando a aprovação demora e o processo precisa retomar depois.

Resposta curta

• Peça aprovação para uma ação específica quando o custo de errar for alto, a reversão for difícil ou outra pessoa precisar responder por ela.
• Faça a decisão no runtime, depois da validação da tool e antes do efeito externo. Não deixe o modelo autorizar a própria chamada.
• Mostre o payload exato, persista o estado pendente e invalide a aprovação se os argumentos ou o alvo mudarem.

Por que um agente não deve pedir aprovação para toda tool?

Em 2026, a documentação da AWS sobre supervisão de agentes separa ações em níveis autônomo, notificação e aprovação conforme impacto e reversibilidade (AWS, “Establish tiered human oversight and approval workflows”, 2026). A separação evita dois erros opostos: bloquear trabalho simples e deixar uma ação grave passar sem revisão.

Uma consulta de status costuma ser reversível porque não muda o sistema. Um rascunho pode exigir apenas registro. Já apagar dados, enviar uma comunicação externa, alterar permissões ou confirmar uma transação muda o mundo fora do loop. A categoria da tool ajuda, mas o contexto também importa: alvo, valor, identidade, frequência e capacidade de desfazer a ação.

O modelo não deve decidir sozinho em qual categoria a chamada entra. Um prompt pode pedir que ele seja cuidadoso, mas não cria uma fronteira de autorização. Trate a saída do modelo como uma proposta. O código de política deve decidir se a proposta passa, gera uma notificação ou vira uma pendência.

Como classificar ações por risco e reversibilidade?

Comece com três níveis simples. A documentação da AWS recomenda que ações autônomas sejam de baixo risco e reversíveis, que ações de notificação avancem com visibilidade do operador e que ações de aprovação sejam de alto risco ou irreversíveis (AWS, “Establish tiered human oversight and approval workflows”, 2026). A tabela é um ponto de partida, não uma política universal.

Não use o número de chamadas como medida de risco. Uma única escrita pode ser mais perigosa que cem leituras. Pergunte o que muda, quem será afetado, se a ação pode ser desfeita e quem tem autoridade para aceitá-la. Se a resposta for incerta, prefira uma pendência ou uma recusa segura até que o contrato fique claro.

O que a pessoa precisa ver antes de aprovar?

Em 2026, a orientação da AWS para decisões críticas pede contexto suficiente para que o revisor entenda a operação, o impacto e as consequências, além de registrar identidade, horários, decisão e escalonamentos (AWS, “Human-in-the-loop for critical decisions”, 2026). Um botão com “aprovar ação do agente” não é uma revisão útil.

O pedido de aprovação deve representar a chamada que será executada. Inclua, no mínimo:

• nome da tool e versão do contrato;
• argumentos normalizados e o alvo que será alterado;
• motivo operacional e resultado esperado;
• dados relevantes usados para montar a chamada;
• risco, reversibilidade e caminho de compensação;
• versão da política, identidade do agente e prazo de validade;
• identificador único que ligue proposta, decisão e resultado.

Não peça para o modelo resumir a ação e mostre apenas esse resumo. A interface deve permitir inspecionar os argumentos reais. Se o runtime buscar novos dados depois da aprovação e reconstruir o payload, a nova chamada precisa passar por outra avaliação. O revisor aprovou uma operação concreta, não uma intenção aberta.

Onde o gate de aprovação deve ficar?

O gate deve ficar entre a validação determinística da chamada e a execução do efeito externo. A orientação da AWS coloca a revisão de ações mutáveis no caminho de execução, e não apenas no prompt (AWS, “Implement tool authorization”, 2026). Assim, uma instrução hostil ou uma decisão errada do modelo não consegue alcançar diretamente o endpoint de autorização.

O fluxo mínimo é este:

1. O modelo propõe uma tool e argumentos.
2. O runtime valida formato, identidade, escopo e pré-condições.
3. Uma política determinística classifica o risco.
4. O runtime executa, notifica ou cria uma pendência.
5. O executor confere que a decisão pertence à mesma chamada.
6. A tool produz o efeito e grava o resultado ligado ao identificador da decisão.

O código abaixo é ilustrativo. policy, savePending e execute são adaptadores que precisam de regras e armazenamento próprios no seu sistema.

type Decision = "autonomous" | "notify" | "approve";

async function runTool(call: unknown) {
  const parsed = ToolCall.safeParse(call);
  if (!parsed.success) return { status: "rejected", reason: "invalid_input" };

  const decision: Decision = policy.evaluate(parsed.data);

  if (decision === "approve") {
    const pending = await savePending({
      tool: parsed.data.tool,
      arguments: normalize(parsed.data.arguments),
      policyVersion: policy.version,
    });
    return { status: "pending", approvalId: pending.id };
  }

  return execute(parsed.data, { notify: decision === "notify" });
}

O executor não deve receber um “sim” solto. Ele precisa buscar a pendência, comparar tool, argumentos normalizados, alvo e versão da política, e recusar se qualquer parte mudou. A validação de tool calls em TypeScript explica a fronteira anterior, onde input e output precisam ser tratados como dados não confiáveis.

Como pausar e retomar um agente depois da decisão?

O SDK de Agents da OpenAI modela a aprovação como uma interrupção: a execução pausa, o estado pode ser convertido para RunState, a pessoa aprova ou rejeita a chamada e o runtime retoma o processo com esse estado (OpenAI Agents SDK, “Human-in-the-loop”, 2026). O ponto importante é a persistência. Uma aprovação que só existe na memória do processo desaparece quando o worker reinicia.

Esse estado explícito se conecta ao desenho de máquinas de estados para agentes de IA: a aprovação é uma transição observável, não um detalhe escondido no prompt.

Guarde a pendência em armazenamento durável com o identificador da execução, tool, argumentos, política, prazo e estado. O processo pode ser retomado em outro worker, mas a decisão deve continuar ligada à mesma chamada. Se a aprovação ficar aberta por muito tempo, inclua uma versão do agente ou do contrato para evitar que uma definição nova execute uma pendência antiga.

Timeout também é uma decisão. Quando o revisor não responde, o sistema pode recusar, encaminhar para outra pessoa ou manter a pendência bloqueada. O que ele não deve fazer é liberar a ação por silêncio. A AWS recomenda definir timeout, escalonamento e fallback seguro para que o workflow não fique parado sem dono (AWS, “Human-in-the-loop for critical decisions”, 2026).

Em um fluxo que atravessa várias horas ou reinícios, eu uso RemoteCode para manter contexto e evidências em sessões longas de agentes. É uma ferramenta minha. A menção cabe aqui porque a aprovação precisa sobreviver ao intervalo entre a proposta e a retomada, sem depender da memória do processo.

Quais falhas tornam a aprovação uma formalidade?

Uma aprovação pode existir no banco e ainda não proteger nada. O primeiro problema é aprovar um resumo enquanto o executor usa argumentos diferentes. O segundo é manter o endpoint de aprovação acessível ao próprio agente. O terceiro é pedir revisão para toda chamada até que a equipe pare de ler.

O caso GhostApproval mostra uma variação importante: a pessoa pode aprovar um caminho aparente enquanto o runtime escreve no alvo resolvido. O princípio é o mesmo para tools. O revisor precisa ver o recurso real que será afetado, e o executor precisa aplicar a mesma fronteira depois do clique.

Também há a janela entre efeito e confirmação. Uma API externa pode concluir a operação e a aplicação cair antes de salvar o recibo. Um retry ingênuo pode enviar a mensagem ou criar o registro pela segunda vez. Para cada ação aprovada, defina chave idempotente, consulta de estado ou caminho de compensação antes de permitir a repetição.

Como verificar que o gate realmente protege a tool?

Faça os testes no executor, sem depender de o modelo escolher o caminho certo. O teste deve provar o comportamento da fronteira e deixar claro o que acontece quando a execução para no meio.

• uma leitura válida segue sem aprovação;
• uma escrita de baixo impacto segue no nível definido e produz uma notificação;
• uma escrita de alto impacto cria uma pendência antes de chamar o serviço;
• argumentos alterados depois do clique exigem nova aprovação;
• uma política nova não executa uma pendência criada sob uma versão incompatível;
• rejeição e timeout não chamam a tool;
• repetir a retomada não cria dois efeitos externos;
• o log liga agente, tool, argumentos, decisão, revisor, horários e resultado.

O critério não é “apareceu um botão”. É conseguir demonstrar que a chamada que a pessoa viu é a chamada que o executor aceitou. A observabilidade de agentes de código ajuda a tornar essa trilha pesquisável. Se essa igualdade não pode ser verificada, a aprovação é só uma camada de interface.

Perguntas frequentes

Toda tool que escreve em um banco precisa de aprovação?

Não. Uma escrita pequena, reversível e limitada pode entrar no nível autônomo ou de notificação se a política, o escopo e a compensação forem claros. A aprovação deve seguir o impacto e a capacidade de desfazer a mudança. Alterar permissões, apagar dados ou atravessar uma fronteira de confiança merece uma exigência mais forte que atualizar um rascunho interno.

O modelo pode decidir quando pedir aprovação?

Ele pode fornecer sinais, mas não deve ser a autoridade final. O runtime precisa aplicar regras independentes sobre tool, alvo, identidade, valor, contexto e reversibilidade. Se a classificação depender somente do texto do agente, uma instrução maliciosa pode tentar rebaixar uma ação perigosa para o caminho autônomo.

Aprovação humana elimina o risco de prompt injection?

Não. Ela reduz a autonomia de algumas ações, mas não corrige validação fraca, permissões amplas, payload mutável ou uma interface que esconde o alvo real. Mantenha a autorização fora do alcance do agente, mostre os argumentos concretos e teste entradas hostis junto com o caminho normal.

Conclusão

Um agente deve pedir aprovação humana quando está prestes a produzir um efeito de alto impacto, difícil de desfazer ou que exige responsabilidade explícita. O bloqueio precisa estar no runtime, depois da validação e antes da tool, com a decisão ligada ao payload exato.

Comece com três níveis: autônomo, notificar e aprovar. Persista as pendências, defina timeout, invalide chamadas que mudaram e teste replay como você testaria qualquer outra operação com efeito externo. Assim, a pessoa revisa as decisões que realmente importam, enquanto o agente continua útil no trabalho repetível.

Fontes consultadas

• OpenAI Agents SDK, “Human-in-the-loop”, consultado em 2026-08-20, https://openai.github.io/openai-agents-python/human_in_the_loop/
• AWS, “Establish tiered human oversight and approval workflows”, consultado em 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentrel02-bp05.html
• AWS, “Human-in-the-loop for critical decisions”, consultado em 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentsec04-bp02.html
• AWS, “Implement tool authorization”, consultado em 2026-08-20, https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentsec02-bp01.html
• Reddit, “Approval is not review if the human cannot inspect the action”, consultado em 2026-08-20, https://www.reddit.com/r/AI_Agents/comments/1t7d3cb/approval_is_not_review_if_the_human_cannot/
• Reddit, “Human in the loop is meaningless unless we define what was approved”, consultado em 2026-08-20, https://www.reddit.com/r/AI_Agents/comments/1vhvqp0/human_in_the_loop_is_meaningless_unless_we_define/
• Reddit, “Human approval on agent writes is mostly theater”, consultado em 2026-08-20, https://www.reddit.com/r/mcp/comments/1uzsx6h/human_approval_on_agent_writes_is_mostly_theater/