O humano apareceu. A decisão, não.
O agente prepara um reembolso e pede aprovação. A pessoa recebe uma tela com o nome do cliente, um resumo escrito pela própria IA e um botão verde.
Ela está no meio de outra tarefa. O texto parece razoável. Clica.
Depois aparece a pergunta que deveria ter vindo antes: qual cobrança foi reembolsada, qual regra permitia, qual valor estava confirmado e se o agente já tinha tentado executar a ação?
Aprovação humana só funciona quando o aprovador consegue reconstruir a decisão sem confiar no resumo do agente. Se a tela mostra apenas “reembolso recomendado”, o humano não controla a ação. Ele empresta o nome ao clique.
Resposta curta
Antes de aprovar uma ação de agente de IA, a pessoa precisa ver:
- ação: o que exatamente será feito;
- alvo: qual cliente, conta, pedido, agenda ou registro será afetado;
- estado atual: o que o sistema confirma agora;
- motivo: por que o agente propôs a ação;
- regra e fonte: qual política e qual dado sustentam a proposta;
- lacuna: o que ainda não foi confirmado;
- efeito: o que muda e se dá para desfazer;
- limite: valor, quantidade, prazo e escopo autorizados;
- validade: por quanto tempo e para qual tentativa a aprovação serve;
- prova posterior: como saber o que realmente foi executado.
O cartão de aprovação humana para agente de IA organiza isso numa página copiável. Para um piloto estreito, ele pode morar numa planilha, formulário ou ticket. Não é preciso comprar uma central de comando para descobrir que o aprovador precisa enxergar a cobrança antes de aceitar o reembolso.
Nem toda ação merece a mesma aprovação
Pedir confirmação para tudo cria fila e ensina a pessoa a clicar sem ler. Não pedir para nada deixa o agente decidir além da autoridade que deveria ter.
Separe as ações pelo efeito.
| Tipo de ação | Exemplo | Controle inicial |
|---|---|---|
| leitura | consultar status de pedido | acesso mínimo e registro da consulta |
| rascunho | preparar mensagem sem enviar | revisão por amostra ou antes do envio, conforme o risco |
| reversível e limitada | aplicar etiqueta, abrir tarefa | limite, auditoria e correção simples |
| externa | enviar mensagem, publicar, ligar | aprovação quando contexto, público ou consequência exigirem |
| financeira ou contratual | reembolsar, cobrar, cancelar, alterar contrato | aprovação explícita com regra, valor, autoridade e prova |
| acesso ou permissão | liberar usuário, compartilhar dado, mudar perfil | autorização no sistema de destino e revisão de escopo |
| difícil de desfazer | excluir registro, confirmar cirurgia, despachar item | humano com autoridade, informação original e trava técnica |
A aprovação deve acompanhar risco e reversibilidade. Uma etiqueta errada pode ser corrigida. Um reembolso duplicado continua duplicado mesmo quando o prompt estava bem-intencionado.
O resumo da IA não é a fonte
A OpenAI recomenda revisão humana especialmente em situações de maior risco e diz que o revisor deve ter acesso às informações necessárias para verificar a saída. Esse detalhe é o centro do problema.
Se o agente diz:
Cliente tem direito ao cancelamento. Aprovar?
mostre também:
- pedido e item afetados;
- data e estado atual;
- trecho da política aplicável;
- fonte ou sistema consultado;
- exceção encontrada;
- valor ou consequência;
- ferramenta que será chamada;
- tentativas anteriores;
- dado ainda desconhecido.
A tela pode continuar curta. O contexto verificável precisa estar a um clique, não escondido numa investigação de vinte minutos.
Quatro aprovações ruins
1. Aprovar só pelo texto final
O aprovador vê a mensagem que será enviada, mas não vê a regra nem o dado usado. O texto está elegante. A premissa pode estar errada.
2. Aprovar uma intenção aberta
“Autorizar o agente a resolver o caso” permite várias ações. Aprovação boa nomeia verbo, alvo, valor e limite: “autorizar reembolso de R$ 84,90 para o pedido 4821, uma vez”.
3. Reaproveitar aprovação antiga
A pessoa aprovou quando o valor era um, a regra era outra ou o destinatário ainda não tinha mudado. O agente reutiliza o clique depois que o contexto mudou.
4. Aprovar no prompt, liberar no sistema
A instrução diz que o agente precisa de humano. A credencial técnica, porém, permite executar direto. Se o fluxo de aprovação falhar, a ferramenta continua aberta.
A OWASP recomenda aprovação humana para ações de alto impacto e autorização no sistema de destino, em vez de depender do modelo para decidir se pode agir. Traduzindo: o botão não pode ser teatro. A ferramenta precisa recusar a execução sem uma autorização válida.
Fluxo para aprovar sem clicar no escuro
A aprovação precisa expirar
Uma aprovação não deveria virar permissão permanente por acidente.
Ela precisa estar ligada a pelo menos:
- uma ação;
- um alvo;
- um valor ou limite;
- uma versão da regra;
- uma versão do agente ou ferramenta;
- uma janela de tempo;
- uma pessoa com autoridade;
- um identificador único.
Peça nova aprovação quando mudar valor, destinatário, regra, dado relevante, versão, risco ou possibilidade de desfazer.
Exemplo:
Aprovação válida por 15 minutos para enviar uma única proposta ao contato 842, no valor de R$ 4.200, usando a versão 7 da política comercial. Mudança de valor, prazo ou destinatário exige nova decisão.
“Pode seguir” não carrega nenhum desses limites. É uma frase simpática com grande potencial administrativo.
O aprovador também precisa poder corrigir
A interface não pode oferecer apenas aprovar ou recusar. Muitas decisões reais são:
- aprovar valor menor;
- retirar um destinatário;
- pedir documento;
- trocar o canal;
- exigir humano na conversa;
- manter o cadastro sem alteração;
- encaminhar para alguém com outra autoridade.
Se toda correção obriga a pessoa a recusar, explicar em outro canal e esperar o agente refazer, o fluxo produz atalhos. Alguém acaba aprovando e corrigindo depois. O controle vira retrabalho com assinatura.
Quem aprova precisa ter autoridade, não só disponibilidade
A pessoa mais rápida nem sempre é a pessoa certa.
Defina autoridade por tipo de ação:
| Ação | Pergunta de autoridade |
|---|---|
| desconto | quem pode aprovar este valor e esta margem? |
| reembolso | quem confirma direito, valor e método? |
| cancelamento | quem pode encerrar sem criar obrigação indevida? |
| mudança de cadastro | quem pode validar identidade e dado sensível? |
| envio externo | quem responde por público, canal e mensagem? |
| acesso | quem pode conceder esta permissão a esta pessoa? |
| exceção de política | quem é dono da regra, não apenas da fila? |
Se o agente manda tudo para “qualquer supervisor”, ele não tem uma política de aprovação. Tem uma caixa de entrada com esperança.
Depois do clique, confira o estado real
Aprovar não prova que a ferramenta executou. E uma resposta de sucesso nem sempre prova que o estado final ficou correto.
Registre:
- identificador do pedido de aprovação;
- versão e regra usadas;
- identidade e função do aprovador;
- decisão, limite e horário;
- ferramenta chamada;
- parâmetros enviados;
- resposta recebida;
- estado confirmado no sistema responsável;
- mensagem enviada ao cliente;
- correção ou reversão posterior.
Se a chamada terminar em timeout, não peça outra aprovação para repetir sem antes reconciliar o estado. O problema pode não ser autorização; pode ser uma ação já executada com resposta perdida. O guia de falha de ferramenta trata esse caso.
Um teste manual para esta semana
Escolha uma ação de impacto: enviar proposta, remarcar, cancelar, reembolsar, alterar cadastro ou publicar.
Preencha o cartão de aprovação e rode seis testes:
- o pedido chega completo;
- falta a fonte;
- o valor muda depois da proposta;
- a aprovação expira;
- uma pessoa sem autoridade tenta aprovar;
- a ferramenta executa, mas a resposta se perde.
O resultado esperado não é “o humano percebe”. O sistema precisa bloquear contexto incompleto, aprovação vencida, autoridade errada e repetição incerta.
Quando uma fila simples basta
Uma planilha, formulário ou ticket funciona quando:
- existe um agente ou caso estreito;
- poucas ações pedem aprovação;
- uma pessoa tem autoridade clara no mesmo turno;
- o contexto cabe no cartão;
- cada pedido recebe identificador;
- a ferramenta não executa antes do clique;
- alguém confere o resultado no sistema responsável;
- erro pode ser localizado e corrigido rápido.
Nesse estágio, faça você mesmo. Revise a primeira amostra e resista à tentação de automatizar a aprovação antes de entender quais perguntas o humano faz.
Onde o caminho manual quebra
A fila começa a falhar quando:
- vários agentes disputam os mesmos aprovadores;
- voz, WhatsApp, CRM e ferramentas geram pedidos ao mesmo tempo;
- decisões expiram antes de alguém olhar;
- a autoridade muda por valor, produto, região ou risco;
- o mesmo clique pode ser reutilizado fora do contexto;
- ninguém liga pedido, decisão e execução;
- aprovações viram gargalo e recebem clique automático;
- QA não consegue localizar o que saiu do limite;
- ações incertas podem ser repetidas;
- pausa e reversão dependem de procurar mensagens antigas.
Aí aprovação deixa de ser um botão no fluxo. Vira parte da operação do agente: identidade, política, autoridade, estado, evidência, QA e caminho de volta.
É nesse cenário que uma camada de gestão de agentes em produção pode fazer sentido. Antes disso, use o cartão e descubra se o humano está decidindo ou apenas confirmando.
O teste mais honesto
Mostre ao aprovador um pedido com resumo convincente e fonte contraditória. Depois mude o valor entre a proposta e a execução.
Se o fluxo ainda aceita o clique, a operação não tem aprovação humana. Tem presença humana.
Vídeo
Eu não encontrei um vídeo em português que eu usaria como resposta principal para esta rotina. Há demonstrações de human in the loop e approval flow. Poucas mostram o que o aprovador vê, como a autorização expira e como pedido, clique e execução permanecem ligados.
Se bastante gente pedir, este assunto entra na fila de gravação. Não é promessa.