Humano no loop em agentes de IA: aprovar tudo é não aprovar nada

Humano no loop virou a resposta padrão para qualquer dúvida sobre agentes de IA. O agente pode errar? Coloca um humano aprovando. O jurídico ficou desconfortável? Humano aprovando. O problema é que essa resposta costuma ser desenhada como um botão de "aprovar" em cada ação, e um botão apertado 200 vezes por dia deixa de ser controle. Vira ritual. A pessoa aprova porque o agente quase sempre acerta, e no dia em que ele erra, ela aprova também.

O mercado está descobrindo isso na prática. Uma pesquisa da VentureBeat Intelligence publicada em outubro de 2026, com 140 respondentes, mostrou que a fatia de empresas com agentes em produção que esperam manter revisão humana no futuro previsível subiu de 20% em julho para 42% em agosto. Na mesma amostra, 61% de quem usa avaliação pré-produção relatou ao menos uma falha visível ao cliente depois de o agente passar nos testes internos. As empresas querem mais humano no loop. A questão é se esse humano vai decidir alguma coisa.

Por que aprovação em toda ação vira carimbo

Aprovar tudo parece o desenho mais seguro, e é o que mais falha. Três mecanismos explicam.

Fadiga de aprovação. Quando 98% das solicitações estão certas, o revisor aprende que aprovar é o comportamento correto. Depois de algumas semanas, ele lê o título, não o conteúdo. A revisão continua registrada no log, mas a atenção saiu dela. É o mesmo fenômeno de alarme de hospital que toca demais: ninguém mais corre.

Viés de automação. Pessoas tendem a aceitar o que um sistema automatizado propõe, sobretudo quando ele soa confiante e bem formatado. Um agente que escreve a justificativa com tom seguro torna a rejeição socialmente mais cara para quem revisa. A matéria da TechTarget de junho de 2026 sobre o tema resume o diagnóstico de analistas ouvidos: revisar grande volume de saída de IA não engaja cognitivamente ninguém.

Revisor sem contexto. Muitas telas de aprovação mostram a ação ("enviar e-mail ao cliente X", "aplicar desconto de 12%") sem mostrar o porquê: que dados o agente usou, que política ele invocou, o que acontece se a ação estiver errada. Sem isso, o humano não tem como discordar com fundamento. Ele só pode confiar ou travar tudo.

Uma aprovação que nunca é recusada não é controle; é um atraso com assinatura.

Onde o humano precisa entrar no loop de um agente

A pergunta útil não é "o agente precisa de humano?", e sim "quais ações precisam?". Dois eixos resolvem a maior parte dos casos: reversibilidade (dá para desfazer em minutos e sem custo?) e impacto (quanto custa o erro em dinheiro, cliente ou compliance?).

Cruzando os dois, saem quatro faixas de tratamento:

1. Reversível e baixo impacto: agente age sozinho. Classificar ticket, rascunhar resposta interna, atualizar campo de status. O controle aqui é observabilidade e amostragem posterior, não aprovação prévia.
2. Reversível e alto impacto: agente age, humano revisa depois. Reagendar entrega, alterar prioridade de caso. O agente executa, a ação entra numa fila de revisão com prazo, e o humano corrige se precisar. Isso é o que alguns chamam de human on the loop.
3. Irreversível e baixo impacto: agente age dentro de limite fixo. Enviar uma mensagem padrão, emitir um cupom de valor pequeno. O controle é um teto codificado (valor, quantidade, frequência), não um humano.
4. Irreversível e alto impacto: humano aprova antes. Estorno acima de um valor, alteração contratual, exclusão de dados, comunicação fora do template. Só aqui a aprovação prévia faz sentido, e justamente por ser rara ela tende a ser lida.

É a mesma lógica que usamos ao discutir quando o Agentforce Commerce pode vender sem humano no loop: ticket baixo e SKU padrão toleram autonomia; exceção de preço e contrato pedem aval. O critério muda de domínio, mas a matriz se repete.

Um ponto que costuma passar batido: o limite da faixa 3 só existe de verdade se o agente não tiver permissão técnica para ultrapassá-lo. Teto escrito no prompt é sugestão. Teto aplicado na credencial e no escopo da ferramenta é controle, como detalhamos ao tratar de identidade própria para agente de IA em vez de login emprestado.

Como desenhar uma aprovação que alguém de fato lê

Depois de decidir onde a aprovação entra, o desenho da própria aprovação define se ela funciona. A sequência que aplicamos em projetos:

1. Mostre a decisão, não só a ação. A tela de aprovação traz o que o agente quer fazer, os dados que usou, a regra ou política em que se baseou e o efeito se estiver errado. Se o revisor precisa abrir três sistemas para entender, ele vai aprovar sem abrir.
2. Torne a recusa barata. Recusar precisa ser tão rápido quanto aprovar, com motivo de um clique ("dado desatualizado", "fora da política", "cliente sensível"). Recusa cara vira aprovação por cansaço.
3. Limite o volume por revisor. Se um analista recebe mais aprovações por dia do que consegue ler com atenção, o desenho falhou. Uma referência prática nossa (estimativa, não benchmark de mercado): acima de 30 a 50 aprovações por pessoa por dia, a qualidade da revisão cai visivelmente.
4. Nomeie quem aprova o quê. Aprovação de estorno é do financeiro; de comunicação ao cliente, do dono do processo. Fila genérica "para o time" não tem dono e acumula.
5. Defina o que acontece no silêncio. Se ninguém aprova em X horas, a ação expira, escala ou segue? Para ações da faixa 4, silêncio nunca deve significar "aprovado".
6. Insira casos de teste. De tempos em tempos, coloque na fila uma ação propositalmente errada e veja se ela é recusada. É a forma mais direta de saber se o revisor está lendo.

Taxa de rejeição: a métrica que mostra se a revisão é real

Todo fluxo com humano no loop deveria publicar um número: a taxa de rejeição ou edição das ações submetidas. Ela diz mais sobre a saúde do controle do que qualquer política escrita.

Taxa perto de zero por semanas seguidas tem duas leituras possíveis. Ou o agente está tão bom naquela ação que a aprovação prévia virou desperdício e ela deve descer de faixa, ou o revisor parou de olhar. Os casos de teste do passo 6 separam uma leitura da outra. Taxa alta e estável indica o oposto: o agente não está pronto para aquela ação, e o humano está fazendo o trabalho que o agente deveria fazer.

O movimento saudável é a ação descer de faixa com o tempo, com evidência. Começa na faixa 4, acumula semanas de histórico com taxa de rejeição baixa e casos de teste capturados, passa para a faixa 2 com revisão posterior por amostragem. Esse histórico é o argumento para dar mais autonomia ao agente, e ele só existe se a revisão foi medida desde o começo. É o mesmo princípio de reservar o humano para os casos de fronteira quando um LLM avalia outro: atenção humana é recurso escasso, e deve ir para onde a máquina hesita ou o erro custa caro.

Autonomia de agente se ganha ação por ação, com histórico de revisão medido, nunca por decreto.

O que muda na governança do agente

Tratar humano no loop como desenho, e não como botão, tem consequência organizacional. Alguém precisa ser dono da matriz de faixas, revisá-la quando o agente ganha ferramentas novas e responder pela taxa de rejeição como responde por qualquer indicador operacional. Sem isso, a matriz congela no dia do go-live e o agente ganha permissões sem que nenhuma ação mude de faixa.

O ganho é duplo. O risco cai nas ações que importam, porque a atenção humana deixa de ser diluída em centenas de aprovações triviais. E o agente entrega mais valor, porque as ações de baixo risco param de esperar numa fila que ninguém lê com atenção. O humano no loop bem desenhado decide menos vezes e decide de verdade.

Perguntas que sempre voltam

Dúvidas comuns de quem está colocando agentes de IA em produção com aprovação humana.

O que é humano no loop em agentes de IA?

Humano no loop (human-in-the-loop) é o ponto do fluxo em que o agente de IA para e espera uma pessoa aprovar, corrigir ou recusar uma ação antes de executá-la. Ele é diferente de humano on the loop, em que o agente age e a pessoa revisa depois, com poder de corrigir. Os dois são controles válidos, para faixas de risco diferentes.

Toda ação de um agente precisa de aprovação humana?

Não, e exigir aprovação em tudo costuma reduzir a segurança em vez de aumentá-la. A aprovação prévia faz sentido para ações irreversíveis e de alto impacto; ações reversíveis ou de baixo impacto ficam melhor com limites técnicos, revisão posterior por amostragem e observabilidade. Concentrar a aprovação no que importa é o que mantém o revisor atento.

Como saber se a aprovação humana virou carimbo?

Acompanhe a taxa de rejeição ou edição das ações submetidas e insira periodicamente casos propositalmente errados na fila. Se a taxa fica perto de zero e os casos de teste passam aprovados, a revisão virou carimbo. Se os casos de teste são recusados e a taxa segue baixa, a ação pode descer de faixa e ganhar autonomia.