Limiar de Decisão em Agentes de IA: Por Que Porcentagem É o Erro e Preço É a Solução

A maioria das configurações de agentes de IA tem uma linha parecida com esta: ESCALATION_THRESHOLD = 0.90. Acima disso, o agente age sozinho. Abaixo, um humano é acionado. É simples, é ajustável e dá a sensação de que a autonomia está sob controle. Mas não é a solução certa — e o problema não está no número, mas na pergunta que estamos fazendo.

Comece pela pergunta errada

A maioria das equipes faz uma pergunta de capacidade: o agente consegue escrever a SQL? Consegue emitir o reembolso? Se sim, deixa rodar. Mas conseguir fazer algo e decidir fazer sozinho são questões diferentes. A segunda é sobre a decisão em si: quanto custa um erro e quanto custa envolver um humano?

Se o agente age, você arrisca o custo de uma falha. Se escala, você paga pelo tempo de um especialista — independentemente de o agente estar certo ou não. A comparação é quase constrangedoramente simples quando você coloca números nela.

A regra: o agente deve agir sozinho quando:

(1 - p) * custo_do_erro  <  custo_de_escalar

Onde p é a probabilidade de o agente estar correto. Rearranjando, escale sempre que:

p  <  1 - (custo_de_escalar / custo_do_erro)

O valor à direita é o limiar real. Perceba do que ele depende: não do modelo, não de uma política definida em workshop. Apenas da razão entre dois custos. Se erros são baratos, o limiar é mais baixo e o agente pode agir mais. Se erros são caros, o limiar sobe — e até um agente confiante deve pedir ajuda.

Esta abordagem é baseada na regra de rejeição de Chow, de 1970, fundamento das pesquisas atuais de learning-to-defer. Ideias antigas envelhecem bem quando estão certas.

Dois tickets, mesma confiança, decisões opostas

O exemplo mais claro vem da triagem de tickets de suporte. Um agente lê tickets e decide resolver ou encaminhar para uma pessoa.

Caso 1 — reembolso de rotina: valor pequeno, política clara. Se o agente errar, o custo de limpeza é ~R$ 85 (crédito de boa vontade). Escalar queima três minutos de um especialista: ~R$ 23. O limiar: 1 − 23/85 ≈ 0,73. Com 90% de confiança, o agente deve claramente agir — escalar gastaria R$ 23 para evitar apenas R$ 8,50 de erro esperado.

Caso 2 — possível invasão de conta: um cliente relata troca de senha que não fez. Se o agente tratar como rotina, o prejuízo não é um crédito: é fraude, remediação, exposição regulatória. Coloque conservadores R$ 11.000 nisso. Escalar ainda custa R$ 23. O novo limiar: 1 − 23/11000 ≈ 0,998. Na prática, sempre escale. Com 90% de confiança, agir sozinho arrisca R$ 1.100 em custo esperado — é 50 vezes mais barato passar para um humano.

A pegadinha: calibração

Toda essa aritmética depende de uma premissa: quando o agente diz 90%, ele acerta ~90% das vezes. Isso é calibração, e não é a mesma coisa que confiança. Confiança é o número que o modelo emite. Calibração é se esse número significa alguma coisa.

Se a confiança declarada de 0,95 na verdade significa 0,70, seu custo de erro esperado é seis vezes maior do que a conta sugere. O limiar que você precificou com tanto cuidado é ficção.

Antes de qualquer limiar, verifique o número. Registre cada decisão com sua confiança declarada, agrupe por faixa de confiança e compare com a precisão real em cada faixa. Se o agente diz 90% e acerta 78%, você encontrou sua correção. Use regressão isotônica ou Platt scaling para mapear um valor no outro.

Dois detalhes mordem aqui: agentes são frequentemente pior calibrados na classe rara e de alto risco — exatamente a classe que carrega seu limiar extremo. E o mapa de calibração deriva conforme a distribuição dos tickets muda — meça-o regularmente.

A regra em código

Uma implementação didática, em poucas linhas:

def deve_agir_autonomamente(
    confianca_declarada: float,
    custo_do_erro: float,
    custo_de_escalar: float,
    calibrar
) -> bool:
    """
    Age sozinho ou escala, por custo esperado.
    'calibrar' mapeia confiança declarada para
    probabilidade real de acerto.
    """
    p_acerto = calibrar(confianca_declarada)

    custo_esperado_agir = (1 - p_acerto) * custo_do_erro
    custo_esperado_perguntar = custo_de_escalar

    return custo_esperado_agir < custo_esperado_perguntar

Não há nada sofisticado na função. O que realmente importa é como você escolhe os três parâmetros de entrada. É aí que seu esforço deve estar — não em debater se o número mágico é 0,85 ou 0,92.

Onde os números ficam complicados

Dois fatores tornam as entradas mais complexas na prática. Primeiro, o custo de escalar não é só minutos × salário: escalações se acumulam em filas, e filas congestionam. Pior: o excesso de escalação treina revisores a aprovar no automático. Um humano que aprova tudo não é um controle, é um ritual.

Segundo, lembre-se da premissa que deixamos de lado: o humano acerta. Frequentemente, não. Dê ao especialista uma taxa de erro h e a regra vira: aja quando (1−p) × custo_erro for menor que custo_escalar + h × custo_erro. Em tickets genuinamente ambíguos, isso inclina o limiar de volta para o agente — e surpreende as pessoas.

Aplicando no seu agente

O procedimento é curto:

1. Agrupe as decisões do agente em classes onde o custo de um erro é aproximadamente o mesmo (ex: reembolsos em uma classe, incidentes de segurança em outra).
2. Precifique cada classe. Converse com quem limpa a bagunça — finanças e operações de suporte conhecem esses números melhor que engenharia.
3. Estime o custo de escalação, incluindo efeitos de congestionamento e aprovação automática.
4. Calibre: use a probabilidade corrigida na regra, não o score bruto.
5. Derive o limiar por classe a partir da razão de custos e deixe-o se mover quando os custos mudarem.

No fim, seu agente terá vários limiares, não apenas um. Mais autonomia onde erros são baratos, muito menos onde erros são custosos. O modelo e a comparação permanecem os mesmos.

E esta é a resposta honesta para a pergunta com a qual todo mundo começa. “Quão confiante meu agente deve estar antes de agir sozinho?” não pode ser respondida — porque está mal especificada. “Quanto custa errar aqui e quanto custa perguntar?” pode. Defina o limiar como um preço. A porcentagem se resolve sozinha.