Pedir aprovação para tudo também é um risco: quando o humano vira carimbador do Agente

Quando uma empresa começa a permitir que Agentes de IA executem ações reais, uma das primeiras preocupações costuma ser a mesma: onde colocar um humano para aprovar o que o Agente está fazendo?

A resposta mais conservadora parece simples: em todo lugar.

Se qualquer ação precisar de aprovação antes de acontecer, o Agente nunca estará completamente sozinho. Há sempre alguém conferindo. No diagrama, isso parece maximizar o controle.

Na operação, pode acontecer o contrário.

Depois de dezenas ou centenas de solicitações parecidas, a pessoa deixa de avaliar cada decisão e começa a reconhecer um padrão de tela: ler pouco, clicar em aprovar e seguir para a próxima. A etapa humana continua registrada, mas o julgamento que deveria funcionar como barreira de segurança perde qualidade.

A AWS descreve esse efeito como rubber-stamping em fluxos de aprovação. Encaminhar todas as ações para revisão humana, independentemente do risco, pode gerar fadiga e aprovações mecânicas. Não revisar nada cria o problema oposto: autonomia sem limites.

A saída está entre esses extremos. A supervisão humana em Agentes IA funciona melhor quando a atenção das pessoas é reservada para situações em que o julgamento humano realmente altera o risco da operação.

Mais aprovação não significa necessariamente mais controle

Existe uma diferença importante entre ter uma etapa de aprovação e ter uma decisão humana de qualidade.

Imagine um Agente comercial trabalhando dentro de um CRM. Ele consulta contatos, classifica leads, adiciona observações, cria tarefas, prepara mensagens e solicita condições comerciais quando necessário.

Se cada leitura de cadastro, atualização de tag e criação de tarefa precisar parar na tela de um funcionário, o funcionário pode receber dezenas de interrupções ao longo do dia.

As primeiras solicitações provavelmente serão analisadas com cuidado. Depois de algum tempo, forma-se um padrão:

"Atualizar CRM? Aprovar."

"Criar tarefa? Aprovar."

"Alterar status? Aprovar."

"Enviar informação? Aprovar."

O cérebro começa a reconhecer a interface em vez de avaliar a decisão.

O risco aparece quando, no meio dessas ações rotineiras, surge uma exceção: alterar dados sensíveis, oferecer um desconto fora da política, enviar uma comunicação para milhares de clientes ou executar uma ação difícil de desfazer.

O controle que deveria detectar a exceção treinou o operador a tratar tudo como rotina.

Por isso, a AWS trata gerenciamento de carga cognitiva como parte da segurança de sistemas com Agentes. A orientação inclui priorizar filas, acompanhar volume e limitar a quantidade de revisões atribuídas a uma pessoa para que a supervisão continue sendo uma decisão, não um ritual.

Onde realmente faz sentido exigir aprovação humana?

A pergunta mais útil deixa de ser "essa ação precisa de aprovação?" e passa a ser "o que existe nessa ação que justifica consumir atenção humana?".

O principal critério é o impacto potencial, combinado com reversibilidade, alcance, sensibilidade dos dados e possibilidade de recuperação.

| Nível de risco | Exemplo | Supervisão possível |

| --- | --- | --- |

| Baixo | Consultar dados autorizados, buscar conhecimento interno, gerar resumo | Execução autônoma com logs |

| Moderado | Atualizações delimitadas e reversíveis em sistemas internos | Execução com limites, auditoria e revisão por amostragem |

| Alto | Comunicação externa relevante, alteração sensível de cadastro, exceção comercial | Aprovação humana antes da execução |

| Crítico | Pagamentos, exclusões, privilégios administrativos, ações em grande escala | Aprovação reforçada, autenticação adicional ou múltiplos revisores |

Essa tabela não deve virar uma regra universal. A mesma ação pode ter riscos diferentes conforme o contexto.

Enviar uma mensagem é rotina para um Agente de atendimento respondendo individualmente dentro de políticas conhecidas. Enviar uma comunicação institucional para 50 mil clientes tem outro alcance.

Alterar um campo no CRM pode ser trivial quando se trata de uma tag operacional. Alterar dados bancários do cliente é outra categoria de decisão.

Preparar uma proposta comercial pode ser automático. Conceder um desconto acima da política pode exigir aprovação. Esse é o mesmo tipo de separação que aparece quando uma empresa define limites para orçamento automatizado com Agente IA.

O nome da ferramenta importa menos do que o efeito concreto da ação.

O próprio Agente não deveria decidir sozinho quando precisa de aprovação

Existe uma armadilha adicional: deixar o próprio modelo ser a autoridade final sobre o risco daquilo que pretende fazer.

Um Agente pode processar emails, documentos, páginas da web, mensagens de clientes e respostas de sistemas externos. Parte desse conteúdo é potencialmente não confiável.

Em um ataque de prompt injection, uma instrução maliciosa pode tentar influenciar não apenas a resposta do Agente, mas também sua avaliação sobre a segurança de uma operação. O problema fica ainda mais sério quando o modelo que lê o conteúdo não confiável é o mesmo que decide se a ação deve passar ou não por revisão humana.

A OWASP inclui Decision and Approval Manipulation entre os riscos de segurança de Agentes. Um invasor pode tentar influenciar pontuações de risco, níveis de confiança ou critérios de aprovação para contornar salvaguardas.

Esse cenário também se conecta ao risco de prompt injection no atendimento: conteúdo não confiável não deveria ter autoridade para alterar as próprias regras que limitam o que o Agente pode fazer.

Por isso, a AWS recomenda que a classificação responsável por exigir aprovação não dependa exclusivamente de um LLM exposto ao mesmo conteúdo que está sendo avaliado. O modelo pode fornecer sinais, mas a decisão final deve passar por regras determinísticas, mecanismos de autorização ou uma camada de políticas que o Agente não controla.

Considere um exemplo simples:

O Agente propõe aplicar desconto de 8%.

A política da aplicação permite até 5% sem aprovação.

O backend identifica que 8% ultrapassa o limite e interrompe a execução.

O Agente não precisa concordar com a regra. Também não consegue removê-la por meio de uma instrução textual.

Essa separação entre raciocínio e autorização é parte da lógica discutida em identidade, permissões e responsabilidade em Agentes IA. O modelo pode solicitar uma ação. Outra camada decide se aquela ação está autorizada.

Um pedido de aprovação precisa trazer contexto suficiente para existir uma decisão

Reduzir a quantidade de aprovações resolve apenas metade do problema.

Quando uma solicitação realmente chegar a uma pessoa, ela precisa ser avaliável.

Uma tela dizendo apenas:

"O Agente deseja executar esta ação. Aprovar?"

transfere responsabilidade para o humano sem fornecer os elementos necessários para que ele exerça essa responsabilidade.

Uma boa interface de aprovação deveria deixar claro:

• o que será feito;
• em qual recurso;
• com quais parâmetros;
• qual foi o motivo da proposta;
• qual é o alcance da ação;
• qual política foi ultrapassada;
• quais evidências sustentam a proposta;
• o que pode acontecer se a decisão estiver errada;
• se a ação pode ser revertida.

Compare duas solicitações.

"Aprovar alteração de preço?"

e:

"Aplicar desconto de 12% no contrato do cliente X, reduzindo o valor mensal de R$ 8.000 para R$ 7.040. A política comercial permite até 5% automaticamente. O Agente solicita uma exceção com base na negociação registrada no CRM."

Na segunda situação existe algo para revisar.

Na primeira existe apenas um botão.

A AWS aponta a falta de contexto como um antipadrão nos fluxos de aprovação. Quando o revisor recebe apenas a ação proposta, sem informações suficientes sobre fontes, consequências e contexto, a revisão tende a virar formalidade.

Algumas ações não deveriam depender de uma única pessoa

Supervisão baseada em risco também permite aumentar o controle quando ele realmente é necessário.

Não faz sentido exigir três aprovadores para atualizar uma tag no CRM. Pode fazer sentido exigir dois para liberar uma transferência de alto valor, alterar permissões administrativas, apagar um grande volume de dados ou executar uma operação crítica em produção.

No Agentic AI Lens sobre múltiplos revisores, a AWS recomenda revisão independente para operações de alto risco. Mostrar ao segundo aprovador a decisão do primeiro antes que ele avalie o caso pode introduzir viés de ancoragem.

Em fluxos críticos, os revisores podem decidir de forma independente. Se houver divergência, o caso segue para escalonamento em vez de ser convertido automaticamente em aprovação.

O objetivo não é adicionar burocracia por padrão. É concentrar defesa adicional nos pontos em que uma decisão errada tem maior impacto.

Supervisão baseada em risco significa redistribuir controles.

Menos atenção humana onde ela pouco acrescenta.

Mais atenção onde um erro pode custar caro.

Como saber se o humano virou apenas um carimbador?

Depois que o sistema entra em produção, ainda existe uma pergunta importante: os humanos continuam realmente revisando?

Isso pode ser observado por métricas.

A AWS recomenda acompanhar indicadores como tempo médio de revisão, taxa de aprovação, taxa de reversão, tamanho das filas e tempo até que uma solicitação receba decisão.

Alguns padrões merecem investigação:

• revisões muito rápidas para decisões complexas;
• taxas de aprovação próximas de 100% em períodos de alto volume;
• aumento de reversões depois da aprovação inicial;
• filas crescendo mais rápido do que a capacidade de revisão;
• diferenças grandes entre revisores para o mesmo tipo de decisão;
• itens de alto risco esperando atrás de solicitações rotineiras.

Nenhuma métrica isolada prova negligência. Um fluxo bem calibrado pode apresentar alta taxa de aprovação porque apenas casos muito previsíveis chegam à fila.

O valor está no conjunto.

Se 99% das solicitações de uma categoria são aprovadas quase instantaneamente, nunca são revertidas e possuem histórico consistente de baixo risco, talvez aquela classe de ação não precise mais interromper a operação a cada ocorrência.

Ela pode migrar para execução automática com limites, logs e auditoria.

Se outra categoria apresenta rejeições frequentes, correções posteriores ou divergências entre revisores, a intervenção humana provavelmente continua necessária. Também pode ser um sinal de que o próprio comportamento do Agente naquela atividade precisa ser melhorado.

Esse tipo de análise complementa as métricas para avaliar se um Agente IA está funcionando. Não basta medir velocidade e quantidade de tarefas concluídas. Também é necessário verificar se os mecanismos de controle continuam funcionando como foram desenhados.

Autorizações persistentes podem reduzir cliques sem abrir a porteira

Existe outro caminho para operações repetitivas: aprovar um padrão muito específico uma vez e permitir que futuras execuções equivalentes ocorram sem uma nova confirmação.

A AWS chama esse mecanismo de persistent trust grants dentro da orientação de aprovação humana por risco.

A ideia pode ser útil, mas exige limites estreitos.

Uma pessoa poderia autorizar, por exemplo, que determinado Agente atualize automaticamente um campo específico do CRM quando os parâmetros estiverem dentro de uma faixa conhecida.

Essa autorização deveria estar vinculada a elementos verificáveis, como comando, formato de parâmetros, recurso, prazo de validade ou limite de valor. Também precisa ser auditável e revogável.

O que não funciona é uma autorização genérica como:

"Aprovar todas as futuras operações comerciais desse Agente."

Nesse caso, a empresa não reduziu fadiga. Ela simplesmente removeu a supervisão de uma categoria inteira de ações.

Autorizações persistentes deslocam o julgamento humano do momento de cada execução para o momento em que a permissão é concedida. Por isso, quanto maior o risco, menor deve ser a possibilidade de reutilizar uma autorização sem nova confirmação.

Autonomia não precisa ser binária

É comum imaginar sistemas de IA em dois extremos.

Em um deles, o Agente apenas sugere e espera uma pessoa executar tudo.

No outro, executa qualquer ação sozinho.

Sistemas reais podem funcionar em muitos pontos entre esses extremos.

A própria AWS descreve supervisão em níveis conforme risco e reversibilidade. Uma operação pode ser autônoma, gerar apenas uma notificação ou exigir aprovação antes de continuar.

O NIST também reconhece que configurações humano-IA podem variar de totalmente manuais a totalmente autônomas. A necessidade de supervisão depende do contexto e do tipo de sistema.

No AI Risk Management Framework, a organização ainda orienta que o nível de atividade de gestão de risco seja definido conforme a tolerância de risco da organização e que papéis de supervisão nas configurações humano-IA sejam claramente definidos. O AI RMF Playbook transforma esse princípio em ações de governança, como definir responsabilidades, registrar riscos e relacionar configurações humano-IA à tolerância de risco da empresa.

Na prática, um Agente pode ter liberdade para:

• consultar informações autorizadas;
• executar rotinas conhecidas;
• realizar alterações reversíveis dentro de limites;
• registrar tudo o que fez;
• interromper somente quando algum parâmetro ultrapassa a política;
• chamar uma pessoa quando a consequência da decisão justifica atenção adicional.

Autonomia, nesse modelo, não significa ausência de controle.

Significa liberdade dentro de fronteiras verificáveis.

O humano deveria aparecer onde seu julgamento vale alguma coisa

Adicionar uma confirmação antes de cada ação é fácil.

Projetar boa supervisão é mais difícil.

Exige entender quais ações são reversíveis, quais possuem impacto financeiro, quais alcançam clientes, quais manipulam dados sensíveis, quais alteram privilégios, quais fogem do padrão e quais podem gerar consequências difíceis de corrigir.

Também exige aceitar uma conclusão aparentemente contraintuitiva:

remover algumas aprovações pode tornar o sistema mais seguro.

Não porque o Agente passe a merecer confiança ilimitada, mas porque atenção humana é um recurso finito.

Se ela for consumida por centenas de decisões irrelevantes, estará menos disponível quando surgir uma decisão que realmente importa.

O objetivo de human-in-the-loop não deveria ser provar que sempre existe uma pessoa no processo. Deveria ser garantir que, quando o Agente estiver prestes a atravessar uma fronteira relevante de risco, exista uma pessoa informada, atenta e com autoridade suficiente para interrompê-lo.

Um bom ponto de aprovação não é aquele que aparece mais vezes. É aquele em que a decisão humana realmente muda o risco da operação.