Seu agente pede aprovação. O humano ainda revisa ou só clica?

Às 17h47, o gestor recebe a décima oitava solicitação do dia: “aprovar atualização de condição comercial”. A tela mostra um resumo convincente, um botão verde e quase nenhum contexto. Ele aprova. No dia seguinte, descobre que o agente aplicou a condição certa ao cliente errado.

Havia um humano no fluxo, mas não havia revisão efetiva. A aprovação funcionou como transferência de responsabilidade, não como barreira de controle. Quando todo passo pede consentimento, a fila cresce, a atenção cai e o botão vira hábito.

Este artigo apresenta o método PAUSA, um protocolo para decidir o que deve executar sozinho, o que pode ser auditado em lote, o que exige aprovação e o que precisa ficar bloqueado para um especialista. O objetivo não é retirar pessoas da operação. É reservar julgamento humano para o ponto em que ele realmente muda o resultado.

Aprovar não é o mesmo que supervisionar

Um estudo longitudinal de junho de 2026 analisou 11.429 revisões feitas por 400 revisores recorrentes em contribuições de agentes de programação. Entre os períodos iniciais e finais de cada revisor, a taxa de aprovação subiu de 30,1% para 36,8%, o tempo em fila aumentou 3,5 vezes e o volume de comentários caiu 22%. Os autores interpretam o conjunto como indício de habituação sob carga, mas alertam que o desenho observacional não prova causalidade e que código corporativo pode se comportar de outra forma.

O valor do achado para uma PME não está em extrapolar código para qualquer processo. Está na pergunta que ele provoca: se o volume de solicitações aumenta, a capacidade real de revisão acompanha? Aprovação humana só é controle quando o revisor consegue entender a mudança, verificar a evidência, avaliar a consequência, recusar e interromper o fluxo.

Outro experimento, com 2.784 participantes extraindo dados de emissões de relatórios corporativos, observou que as pessoas corrigiam menos a sugestão da IA quando a correção exigia esforço adicional. Atitudes favoráveis à IA foram mais preditivas do desempenho do que fatores demográficos, e incentivos usuais não eliminaram o problema. Isso reforça que “colocar alguém no loop” não neutraliza automaticamente viés, esforço ou pressa.

Quatro destinos possíveis para cada ação

1. Executar automaticamente: ação de baixo impacto, reversível, dentro de regra testável e com confirmação posterior.
2. Executar e auditar em lote: grande volume de ações homogêneas, recuperáveis e amostradas por risco, sem interromper cada unidade.
3. Pausar para aprovação: decisão com consequência relevante em que o humano recebe evidência suficiente e tem autoridade para aceitar, alterar ou rejeitar.
4. Bloquear e encaminhar: ação proibida, fora de política, sem dados mínimos ou dependente de julgamento técnico, financeiro, jurídico ou assistencial específico.

A classificação não pode depender apenas da “confiança” declarada pelo modelo. Considere impacto, reversibilidade, valor, sensibilidade dos dados, destinatário, novidade da situação, qualidade da evidência e facilidade de confirmar o efeito no sistema oficial.

Método PAUSA: cinco controles para uma aprovação que vale

P — Perímetro e consequência

Defina quais ações entram na alçada do agente e quais consequências exigem intervenção. “Enviar mensagem” é uma categoria ampla demais: responder um pedido de horário, conceder desconto, comunicar informação clínica e assumir prazo contratual têm riscos diferentes.

Para cada tipo de ação, registre limite de valor, sistema, destinatário, dado sensível, horário, reversibilidade e regra de bloqueio. Se a proposta sair do perímetro, ela não deve aparecer como mais uma aprovação rotineira. Deve ser encaminhada como exceção, com prioridade e responsável próprios.

A — Artefato comparável e evidência

O revisor precisa ver o que mudará, não uma defesa eloquente escrita pelo agente. Mostre lado a lado estado anterior e proposto, regra aplicada, fonte, trechos relevantes, valor, destinatário e efeitos esperados. Em mensagem externa, exiba o texto e os anexos finais. Em cadastro, mostre o diff dos campos. Em compra, apresente itens, quantidade, preço, fornecedor e orçamento consumido.

O NIST está desenvolvendo sondas de avaliação integradas ao fluxo para comparar afirmações com documentos de referência e acumular trilhas de auditoria legíveis por máquina. O princípio é diretamente útil: a interface de decisão deve ligar cada afirmação importante à evidência que a sustenta, em vez de pedir confiança no resumo.

U — Urgência, fila e orçamento de atenção

Supervisão tem capacidade. Defina quantas decisões cada papel consegue revisar com qualidade por período, quanto tempo uma solicitação pode esperar e o que acontece quando a capacidade se esgota. A regra segura pode ser reduzir a autonomia, reatribuir a fila ou interromper novas execuções — nunca pressionar o humano a aprovar mais rápido.

Agrupe casos repetitivos, elimine alertas redundantes e ordene por consequência e prazo real. Uma pesquisa de 2026 modelou a supervisão como alocação de atenção finita e mostrou, em ambiente experimental, por que escalar tudo pode produzir resultado pior: solicitações benignas consomem a atenção que o caso perigoso precisaria. O artigo é um preprint e não deve ser tratado como parâmetro universal; serve como alerta para medir a carga da sua própria operação.

S — Supervisor competente, independente e capaz de negar

Escolha o revisor pela autoridade e pelo conhecimento da decisão, não apenas por disponibilidade. Quem aprova condição comercial precisa entender margem e alçada. Quem aceita medição de obra precisa conhecer critério e evidência. Quem revisa comunicação de clínica precisa distinguir rotina administrativa de orientação assistencial.

O supervisor precisa ter quatro saídas reais: aprovar, aprovar com alteração, rejeitar e pedir informação. A rejeição deve encerrar ou redirecionar a ação; não autorizar o agente a repetir a mesma proposta com palavras diferentes. Em ações críticas, separe solicitante, revisor e executor quando a operação permitir.

A — Aprendizado, amostragem e ajuste de política

Cada decisão gera dado operacional. Motivos recorrentes de aprovação podem virar regras testáveis para reduzir interrupções. Motivos recorrentes de rejeição devem corrigir fonte, prompt, integração ou mandato antes de aumentar autonomia.

Não use aprovação histórica como verdade automática: parte dela pode ter sido superficial. Mantenha amostragem pós-execução, compare aprovações entre revisores, revise escapes e simule casos raros. A política deve aprender com decisões fundamentadas e resultados confirmados, não apenas com cliques.

Pacote mínimo de decisão

Cada solicitação que chega ao humano deve caber em um cartão com:

1. objetivo do processo e identificador único;
2. ação exata que será executada;
3. estado anterior e estado proposto;
4. pessoa, cliente, obra, pedido ou registro afetado;
5. regra e alçada aplicáveis;
6. fontes, validade e evidências verificáveis;
7. valor, prazo, dado sensível e consequência;
8. testes automáticos já executados;
9. incertezas, conflitos e exceções;
10. possibilidade e procedimento de reversão;
11. prazo real para decidir e efeito da expiração;
12. nome, decisão e justificativa do revisor.

Se a decisão exige abrir quatro sistemas, reconstruir o histórico no WhatsApp e adivinhar a regra usada, a automação transferiu o trabalho para a aprovação. O pacote deve reduzir a busca sem esconder a evidência original.

Matriz consequência × verificabilidade

• Baixa consequência e fácil verificação: automatize com log e amostragem.
• Alta consequência e fácil verificação: use regra automática, pacote curto e aprovação por alçada; bloqueie se o teste objetivo falhar.
• Baixa consequência e difícil verificação: mantenha em proposta ou lote pequeno até criar critério de aceite.
• Alta consequência e difícil verificação: não delegue a decisão final. O agente reúne dados e opções; o especialista decide e registra o fundamento.

Essa matriz evita dois erros comuns: exigir clique para tudo, destruindo produtividade, ou liberar tudo que parece reversível, ignorando que uma comunicação enviada ou uma decisão registrada pode produzir efeitos difíceis de desfazer.

Exemplos nas verticais da V7

• v7 Obras: alertas e consolidações podem rodar automaticamente. Alteração de medição exige comparação com etapa, contrato e evidência; aceite técnico continua com o responsável competente.
• v7 Carteira: priorização de clientes pode ser auditada em lote. Desconto, limite e negociação recebem diff da condição, margem, histórico e alçada antes do envio.
• v7 Agro: lembretes de janela comercial podem ser automáticos. Preço, recomendação técnica ou compromisso de entrega saem da fila genérica e seguem fonte, validade e responsável específicos.
• v7 Imob: triagem e agendamento de visita podem seguir regras. Proposta, disponibilidade, preço e cláusula precisam ser confirmados no cadastro oficial e aprovados por quem tem mandato.
• v7 Clínicas Retorno: confirmação administrativa pode ser automatizada com consentimento e regras de contato. Situação clínica, urgência ou orientação não deve ser convertida em simples botão de aprovação.
• v7 Custom: atualizações internas reversíveis podem executar com auditoria. Pagamentos, exclusões, publicação externa e mudança de acesso recebem pacote de decisão, dupla checagem ou bloqueio.

Placar da supervisão

• carga por revisor: solicitações recebidas, tempo efetivo de análise e distribuição ao longo do dia;
• idade da fila: mediana, percentil alto e casos expirados;
• taxa de intervenção: aprovações com alteração, rejeições e pedidos de informação;
• falso escalonamento: casos que poderiam ter sido resolvidos por regra confiável;
• escape aprovado: erros descobertos depois de uma aprovação humana;
• reversão: ações desfeitas, custo e tempo de recuperação;
• divergência entre revisores: decisões diferentes sobre casos equivalentes;
• resultado confirmado: ações corretas no sistema oficial e efeito de negócio observado.

Taxa de aprovação alta não é sinal de qualidade. Pode indicar propostas excelentes, regra mal calibrada ou carimbo automático. Leia o indicador junto com intervenção, tempo efetivo, escapes e resultado confirmado.

Checklist de prontidão em 15 perguntas

1. Quais consequências realmente exigem decisão humana?
2. Quais ações podem executar e ser auditadas em lote?
3. Quem tem conhecimento e alçada para cada tipo de decisão?
4. O revisor pode rejeitar sem sofrer pressão operacional indevida?
5. A rejeição interrompe a ação ou o agente tenta novamente?
6. A tela mostra o diff ou apenas um resumo convincente?
7. Fontes e regras podem ser abertas em um clique?
8. Destinatário, valor e dado sensível aparecem com destaque?
9. Os testes automáticos reduzem o que precisa ser lido?
10. Existe limite de fila e caminho para sobrecarga?
11. Solicitações expiram quando dados ou autorizações vencem?
12. Decisões críticas têm independência ou dupla checagem?
13. O sistema registra motivo, não só “sim” ou “não”?
14. Há amostragem de ações aprovadas e automáticas?
15. Escapes alteram a política, o teste ou a fonte do agente?

Se as respostas 1, 3, 6, 10 e 14 forem “não”, adicionar mais botões de aprovação não resolve o risco. Primeiro redesenhe a supervisão.

Piloto assistido de 20 dias

1. Dias 1 a 4: escolha um fluxo, liste ações, consequências, volumes, filas atuais e responsáveis.
2. Dias 5 a 8: opere em modo proposta e registre tempo de análise, alterações, rejeições e informação faltante.
3. Dias 9 a 12: crie o pacote de decisão e a matriz consequência × verificabilidade; bloqueie ações sem evidência mínima.
4. Dias 13 a 16: automatize apenas casos baixos e testáveis; mantenha amostragem e compare o resultado no sistema oficial.
5. Dias 17 a 20: ajuste regras com base em escapes, falso escalonamento e capacidade. Amplie por tipo de ação validado, não por processo inteiro.

Sinais de alerta

• toda ação, inclusive rotineira e reversível, exige o mesmo clique;
• a fila é ordenada por chegada, sem risco ou prazo real;
• o resumo omite estado anterior, fonte, destinatário ou efeito;
• o revisor aprova no celular sem acesso aos documentos necessários;
• aprovações em massa não registram análise nem justificativa;
• o gestor que pediu velocidade também revisa sozinho todas as exceções;
• ninguém mede ações corrigidas depois de aprovadas;
• a solução chama presença humana de governança, mas não define capacidade, competência e veto;
• a automação cresce enquanto a fila e o retrabalho humano ficam fora do ROI.

O ponto de vista da V7 Agents

O humano no loop não pode ser decoração de segurança. IA só gera ROI quando existe processo, dados, responsável, rotina de revisão e implantação operacional. Isso inclui dimensionar a atenção humana como recurso finito e desenhar a aprovação como uma decisão verificável.

O V7 IA Ready mapeia ações, consequências, alçadas, evidências e capacidade antes da automação. Os Agentes Verticais aplicam regras do setor. A Operação Contínua mede fila, intervenção, escapes e resultado para ajustar a autonomia sem transformar gestores em operadores de botão.

Fontes consultadas

• Yu et al. — Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code, junho de 2026.
• Harvard Data Science Review — Bias in the Loop: How Humans Evaluate AI-Generated Suggestions, abril de 2026.
• Dhanorkar, Passi e Vorvoreanu — Human oversight of agentic systems in practice, junho de 2026.
• Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human, junho de 2026.
• NIST — Building Evaluation Probes into Agentic AI, maio de 2026.
• AI and Ethics — Designing meaningful human oversight in AI, maio de 2026.