Quando confiar num agente de IA e quando verificar na mão

Publicado em 27 de setembro de 2026 · Por Brian Reis, corretor de imóveis CRECI/SC 52.398

"Quando você confia num agente de IA e quando verifica na mão?" é a pergunta que mais recebo de quem tenta entender como estruturar isso na própria operação. Tenho um critério simples, que uso todo dia, e que não depende de humor ou de quanto tempo sobra — depende só da natureza da tarefa.

Critério 1: tarefa mecânica e reversível — confio, com checagem por amostragem

Calcular mediana sobre um acervo de 1.600 registros, formatar tabela, gerar rascunho de texto a partir de dado real — são tarefas mecânicas, fáceis de conferir depois, e onde um erro custa pouco para corrigir. Aqui confio no agente e checo por amostragem, não linha por linha, porque o custo de um erro isolado é baixo e reversível.

Critério 2: ação pública ou irreversível — nunca confio sem verificação humana

Publicar uma matéria, fazer deploy, tocar em qualquer arquivo que envolva dado de cliente — aqui a regra é diferente: verificação humana sempre, mais uma barreira automática que não depende de eu lembrar de olhar. Foi exatamente essa barreira que travou sozinha quando um script meu de correção de favicon alterou, sem eu perceber, dois documentos legais assinados. Sem essa camada, o erro teria ido ao ar antes de qualquer verificação humana acontecer.

Critério 3: diagnóstico ambíguo — investigo antes de aceitar

Quando algo "parece" bug, esse "parece" não é motivo suficiente para corrigir. Numa sessão recente, uma suspeita de dado vazado entre cidades virou investigação — e a investigação provou que o sistema estava certo (era uma deduplicação aplicada de propósito em julho), não que havia erro algum. As outras quatro suspeitas da mesma sessão eram reais e foram corrigidas depois de confirmadas. O critério não é desconfiar de tudo — é não agir sobre uma suspeita sem confirmar a causa primeiro, por mais óbvio que o erro pareça à primeira vista.

Critério 4: escala — meça antes de multiplicar

Quando uma correção pode ser aplicada em massa, primeiro valido num piloto. Encontrei recentemente 203 casos da mesma inconsistência num portal e corrigi apenas 1 antes de decidir se valia escalar para os outros 202. Multiplicar um erro é sempre mais caro do que multiplicar devagar, mesmo que devagar pareça, na hora, uma perda de tempo.

Os quatro critérios não são independentes entre si — na prática, a maioria das decisões do dia a dia envolve mais de um ao mesmo tempo. Uma correção em massa (critério 4) sobre um dado publicado (critério 2) que começou como uma suspeita ambígua (critério 3) passa pelos três antes de eu decidir agir. Quanto mais desses critérios uma tarefa acumula, mais devagar e mais verificada ela precisa ser — e é raro uma tarefa realmente importante acionar só um deles isoladamente.

O critério resumido em uma frase

Quanto mais barato for reverter um erro, mais confio no agente sozinho; quanto mais público, irreversível ou sensível for o resultado, mais camada de verificação humana e barreira automática eu exijo antes de deixar ir ao ar. É um critério simples de enunciar, mas que só funciona se for aplicado sempre — inclusive nos dias em que o prazo empurra na direção de pular a checagem.

Como esse critério nasceu de erro, não de teoria

Não cheguei a esses quatro critérios lendo um manual — cheguei porque cada um deles corresponde a um momento em que a falta dele custou caro, ou quase custou. O critério de barreira automática nasceu do incidente do favicon. O critério de investigar antes de aceitar nasceu da sessão em que uma suspeita de bug provou que o sistema estava certo. O critério de medir antes de escalar nasceu dos 203 casos que decidi tratar como piloto em vez de correção em massa. Nenhum veio antes do problema; todos vieram depois, como resposta a ele.

Como aplicar isso desde o primeiro dia, sem esperar o próprio incidente

Quem está começando não precisa esperar cometer o mesmo erro para adotar o critério — pode simplesmente perguntar, antes de automatizar qualquer tarefa: quanto custa reverter se isso sair errado, e quem vai perceber se sair? A resposta a essas duas perguntas já indica, de forma bastante confiável, quanta supervisão aquela tarefa específica exige, sem precisar aprender isso da forma mais cara.

Um detalhe que vale reforçar: nenhum desses quatro critérios é estático para sempre. Uma tarefa que hoje é mecânica e reversível pode deixar de ser se o contexto mudar — por exemplo, se ela passar a alimentar diretamente uma decisão de cliente em vez de só um cálculo interno. Reavaliar periodicamente em que categoria cada tarefa automatizada se encaixa é parte do próprio critério, não um passo à parte dele.

Fecho com o que considero o teste mais simples de todos, para quem só vai lembrar uma coisa deste texto: imagine explicar, depois do fato, exatamente o que aconteceu e por que você deixou a IA decidir aquilo sozinha. Se essa explicação soa confortável e razoável, a confiança estava bem calibrada. Se soa como uma desculpa, é sinal de que aquela tarefa devia ter tido mais verificação humana antes de ir ao ar — e da próxima vez, antes de agir, vale fazer esse teste mentalmente primeiro, não só depois que algo já deu errado.

Esse critério não é sofisticado, e é justamente por isso que funciona no dia a dia, sob pressão de prazo, sem exigir uma reunião de comitê antes de cada decisão pequena. Regra simples que se aplica sempre bate regra sofisticada que só se lembra de aplicar quando dá tempo. Depois de meses operando assim, é essa simplicidade — não a sofisticação do sistema por trás — que sustenta a confiança de que nada crítico vai passar despercebido.

Vale reforçar que este critério não nasceu pronto — ele é a versão atual de algo que venho ajustando desde que comecei a usar IA de forma mais intensa na operação. Cada incidente ou quase-incidente que mencionei ao longo deste texto empurrou um dos quatro critérios para uma forma mais clara do que era antes. Espero, honestamente, continuar ajustando — o dia em que eu achar que este critério está definitivo demais para revisar é o dia em que ele provavelmente já ficou desatualizado.

Prefiro terminar este texto com essa admissão de que o critério ainda está em construção do que fingir que cheguei a uma fórmula final e imutável — porque, na prática, nenhum processo que sobrevive a este ritmo de trabalho fica parado por muito tempo.

E é essa disposição para revisar, mais do que qualquer regra específica, que recomendo, acima de tudo, a quem for adaptar este critério para a própria operação.