Gating por confiança e escalonamento para um humano

A página anterior defendeu que o código deve ser dono do limiar. Esta página trata do que o limiar divide — as três faixas de cada lado.

Três faixas, não duas

Projetos reais raramente fazem “automático ou não”. Três faixas é a forma comum:

A terceira faixa é fácil de ignorar e é a mais barata das três. “Não olhado” e “uma pessoa dá uma olhada” diferem por um humano.

Uma implementação de triagem é típica: pagine apenas quando P(SEV1) + P(SEV2) ≥ 0.80; descarte abaixo de 0.20 apenas quando uma verificação de acionabilidade também discorda; mande a faixa do meio para um humano.

A faixa do meio é onde vivem os problemas de fato

Uma vez que as três faixas existem, toda pergunta difícil se move para a do meio:

É capacidade humana, não capacidade ociosa. Quanto mais larga a faixa, mais escalonamentos, mais uma pessoa trata. Uma taxa de escalonamento de 9% parece baixa — até a taxa base ser milhares por dia.

Ela precisa de um fail-safe, ou fica travada silenciosamente. Assim que você entrega uma decisão a um humano, nada acontece até um humano olhar. Num painel, isso se parece exatamente com “está tudo bem”. A resposta da ferramenta de triagem é direta: sem confirmação em 15 minutos, pagine de qualquer forma. Melhor acordar alguém do que deixar um P1 parado numa fila.

A própria condição de escalonamento pode falhar. Um gate de autonomia dentro de um agente continua apenas quando um Choice ultrapassa 0.6 e um Noul de segurança de autonomia ultrapassa 0.5, devolvendo o turno ao humano caso contrário. Os dois números precisam passar — porque “o que devo fazer” e “isso é seguro” são perguntas separadas, e uma confiança só não pode honestamente responder às duas.

Definir o limiar: meça primeiro

Escolher 0.8 do nada é a abordagem mais comum e a que mais provavelmente vira ruído três meses depois. A abordagem reproduzível é medir, sobre os seus próprios dados rotulados, o limiar necessário para atingir a precisão desejada.

Um exemplo público: com 0.7 como gate de baixa confiança, uma execução sobre n=130 pegou 3 de 3 classificações erradas a uma taxa de escalonamento de 9%. A amostra é pequena. Seu valor não é o 0.7 — é que é assim que um número desses deveria ser relatado: tamanho da amostra, taxa de escalonamento e o que foi pego.

Latência é o risco subestimado

Os números medidos da ferramenta de triagem merecem uma tabela própria:

O p95 é 3.5× o p50. Isso significa que a cauda importa mais do que a média — porque a política de timeout dispara na cauda, e quando ela dispara você está no ramo de fallback, não no ramo que você projetou. A chamada mais lenta chegou a 151 ms do timeout, ou seja, o determinismo do sistema dependia de uma moeda que por acaso não caiu mal.

Então os sistemas de gating geralmente falham não por “julgar errado”, mas por estourar o timeout e seguir o fallback. Teste o fallback independentemente do caminho principal.

Duas direções de fallback, ambas corretas

Quando algo dá erro, as implementações públicas se dividem em dois campos, e ambos estão certos:

• fail-closed: um juiz de permissões nega em timeout ou erro. Um gate de segurança tem que funcionar assim — um gate de segurança fail-open é um buraco silencioso.
• fail-open: um hook Stop do Claude Code permite em qualquer erro. Um gate de eficiência tem que funcionar assim — um gate de eficiência fail-closed trava todo o fluxo.

O critério não é “qual é mais seguro”, mas qual custo é maior: um bloqueio falso ou um bloqueio perdido. E isso tem que ser decidido quando você escreve o código, porque o que ele determina é o caminho de exceção, não o principal.

Em uma frase

Num desenho de três faixas, o trabalho está na faixa do meio: sua largura é um custo, seu fail-safe é uma propriedade de confiabilidade. Projete os dois explicitamente em vez de usar os padrões.