O primeiro instinto é aprovar tudo
É comum a primeira versão de um agente em produção pedir aprovação humana pra cada ação. Parece prudente: o agente sugere, uma pessoa confirma, nada sai do controle. Na prática, isso dura pouco. Em poucos dias a fila de aprovação vira uma lista de cliques automáticos, ninguém lê o que está aprovando de verdade, e o agente virou um formulário mais lento do que o processo manual que ele deveria substituir.
O dado que sustenta essa aflição não é anedota isolada. O relatório State of AI 2026 da AvePoint, divulgado em 29 de junho, entrevistou organizações que já rodam agentes de IA em produção: 88,4% delas sofreram ao menos uma violação de segurança ligada a um agente nos últimos 12 meses, e 95,5% tomaram alguma ação de mitigação depois do incidente. A mais comum, disparada, foi adicionar controle humano no fluxo. Ou seja: a maioria não decide o nível de supervisão antes. Decide depois que o agente já causou o problema.
A gente prefere decidir antes. E decidir antes significa responder uma pergunta que não tem resposta óbvia: até que ponto o agente pode agir sozinho?
Aprovar tudo mata o motivo de ter agente
O argumento contra aprovação total é simples de enunciar e difícil de aceitar quando o medo é grande. Se toda ação passa por uma pessoa, o tempo de resposta do processo vira o tempo de resposta da pessoa mais devagar da fila de aprovação, e a IA não acelerou nada. Pior: quando a fila de aprovação cresce, quem aprova para de ler com atenção. Aprova por hábito. E aí a supervisão que devia pegar o erro grave passa a validar tudo igual, inclusive o erro grave.
O argumento contra zero supervisão também é simples. Um agente que decide sozinho comete o mesmo tipo de erro em escala, porque repete a lógica que aprendeu sem cansar e sem duvidar de si mesmo. Um humano que erra, erra uma vez e sente o peso disso. Um agente que erra, erra a mesma coisa cem vezes antes de alguém notar o padrão.
Nenhuma das duas pontas funciona sozinha. A saída que a gente usa em projeto de implementação IA-first não é escolher um lado, é desenhar o limiar.
Como funciona o limiar
A lógica é separar as ações do agente em duas perguntas, não uma: qual é o impacto se der errado, e dá para desfazer depois? Uma ação de baixo impacto e reversível roda sozinha. Uma ação de alto impacto ou irreversível para na mesa de alguém antes de acontecer.
function decide(acao):
if acao.reversivel and acao.impacto <= LIMIAR:
executar(acao)
else:
enviar_para_aprovacao(acao)
O código é trivial. A parte difícil é calibrar LIMIAR e a lista do que conta como reversível, porque isso muda por processo e por cliente. Enviar uma mensagem errada para um lead é reversível: manda outra corrigindo. Aplicar um estorno indevido é reversível em teoria, mas mexe com o financeiro e com a confiança de quem recebeu. Excluir um registro de cadastro raramente é reversível de verdade, mesmo com backup, porque o efeito em cascata já aconteceu antes de alguém perceber.
| Abordagem | Velocidade | Onde quebra |
|---|---|---|
| Aprovar toda ação | Baixa | Fila cresce, aprovação vira reflexo |
| Zero aprovação | Alta | Erro se repete em escala antes de alguém ver |
| Limiar por impacto e reversibilidade | Alta nas ações de baixo risco | Exige calibrar o limiar caso a caso, não é genérico |
A terceira linha da tabela é a única que escala sem virar teatro de segurança. E ela custa mais para montar, porque exige conversar com quem conhece o processo sobre o que realmente é grave ali dentro. Isso não dá para terceirizar para um checklist genérico.
O limiar muda com o tempo, e isso é o ponto
Uma coisa que a gente aprendeu implementando esse padrão: o limiar do primeiro mês não é o limiar do sexto. No início, com o agente ainda não testado no processo real, faz sentido manter o limiar baixo, quase tudo passando por aprovação. Depois de um piloto rodando com métrica acompanhada, e um histórico de decisões revisadas sem erro grave, o limiar sobe. É a mesma lógica de dar mais autonomia para uma pessoa nova depois que ela mostra serviço, só que documentada em regra em vez de ficar no julgamento de quem gerencia.
O erro mais comum não é errar o limiar inicial. É esquecer de revisitar ele. Um agente que segue no limiar de cautela máxima seis meses depois de provar que funciona está custando tempo de aprovação que já não precisa mais existir. E um agente que ganhou autonomia demais cedo demais, sem ninguém checar o histórico de decisões, é exatamente o padrão que gerou os 88,4% de incidentes do relatório da AvePoint.
O que fazer na segunda de manhã
Pega o agente que já está rodando em produção hoje, se você tem um, e lista as ações que ele executa sem passar por ninguém. Para cada uma, responde duas perguntas: se der errado, dá para desfazer, e qual o tamanho do estrago até alguém perceber? Qualquer ação onde a resposta for não desfaz e demora a perceber precisa de um gate de aprovação essa semana, não no próximo sprint.
Se você está desenhando um piloto agora, define o limiar antes de escrever a primeira linha de código do agente, junto com a métrica de sucesso. É o mesmo momento em que a gente trata isso na implementação IA-first: guardrail não é o que se adiciona depois que algo deu errado, é parte do desenho desde o diagnóstico.
Fontes
- AvePoint Research Reveals AI Visibility Gaps Have Nearly Tripled as AI Agents Scale (GlobeNewswire, 2026)
