A régua de risco: guardrails que continuam funcionando mesmo quando o modelo falha

Este artigo é sobre como desenhar a camada que decide quando um agente pode agir sozinho e quando precisa parar e esperar um humano, sem transformar todo o sistema em uma fila de aprovação que ninguém aguenta manter.

Por que confiança do próprio modelo não é um guardrail confiável

O erro mais comum nesse desenho é usar um único limite de confiança como critério de escalonamento: se a confiança do modelo cair abaixo de um número, escala para um humano, senão segue sozinho. O problema é que a confiança declarada pelo próprio modelo não deve ser interpretada como uma probabilidade calibrada de acerto. Pesquisa recente em interpretabilidade mecanicista mostra que modelos de linguagem codificam calibração real e confiança verbalizada em direções praticamente ortogonais dentro da rede [1], o que significa que a informação correta sobre incerteza existe internamente, mas o texto que o modelo gera para expressar essa confiança frequentemente não reflete ela [2]. Na prática, isso aparece como resposta incorreta apresentada com linguagem tão confiante quanto uma resposta correta.

A defesa mais robusta contra isso não é ajustar o limite, é não depender de um único sinal. Um segundo modelo, menor e dedicado a checar o trabalho do primeiro, ajuda, mas não é validação independente garantida: dois modelos podem compartilhar o mesmo erro, especialmente quando vêm de dado de treinamento ou padrão de raciocínio parecido. O desenho que funciona combina sinais de natureza diferente, não só mais um modelo avaliando o primeiro: regra determinística, validação de schema, verificação de permissão, evidência recuperada de fonte confiável, teste de consistência entre execuções, o modelo avaliador como mais um desses sinais, e revisão humana reservada para o caso realmente crítico.

Como a ação decide o nível de controle

Nem toda ação merece o mesmo nível de controle. Uma consulta de leitura não tem o mesmo risco que uma escrita irreversível, cancelar um pedido, aprovar um pagamento, publicar conteúdo, ou mudar uma configuração de produção. Mapear toda ação que o agente pode executar, e classificar cada uma antes de decidir qual padrão de controle aplicar, é o primeiro passo que a maioria dos projetos pula, indo direto para "vamos colocar um humano revisando tudo" ou para o oposto, "o agente já erra pouco, deixa rodar sozinho".

Quatro padrões cobrem a maior parte dos casos reais. Auto-run para ações de baixo risco e reversíveis, sem intervenção nenhuma. Audit para ações de risco médio, o agente executa e a ação fica registrada para revisão posterior, não bloqueante. Validação condicionada para ações de risco alto, mas reversível e controlável, onde a liberação depende de uma composição de fatores, reversibilidade, impacto, qualidade da evidência recuperada, resultado de validações determinísticas e incerteza do modelo, não apenas um número de confiança isolado. Gate para ações de risco crítico ou irreversível, aprovação humana obrigatória antes de qualquer execução, sem exceção.

O ponto de verificação estruturado

Quando a ação exige aprovação, o formato do pedido de aprovação importa tanto quanto a decisão de pedir. O padrão que funciona em produção segue uma sequência fixa: o agente prepara a ação com trilha de auditoria completa, um humano revisa a justificativa objetiva e as evidências que a sustentam, o humano autoriza ou nega, e o agente executa com a atribuição daquela autorização registrada junto ao resultado. O humano não precisa, e não deveria precisar, ler uma cadeia interna de raciocínio do modelo para decidir. Ele precisa de evidência auditável: dado de entrada, regra acionada, ferramenta chamada, resultado de validação e origem da informação usada.

Isso é bem diferente de um pedido de aprovação genérico do tipo "posso continuar?". A aprovação estruturada expõe a intenção da ação, a origem do dado usado para decidir, a cadeia de permissão envolvida, o raio de impacto esperado, e o plano de reversão se algo der errado. Um aprovador que só vê "confirmar ação?" tende a aprovar por hábito depois da décima vez. Um aprovador que vê o contexto completo tem o que precisa para de fato julgar.

Autorização não é o fim da história. Mesmo depois de aprovada, uma ação deveria rodar sob privilégio mínimo: allowlist explícita de ferramentas e operações permitidas, escopo limitado pela identidade que autorizou, limite de valor e de volume por execução, idempotência para que reexecutar não duplique efeito, sandbox quando o domínio permitir, e credencial temporária ou escopada em vez de uma chave de acesso permanente e ampla. Separar o momento de preparar a ação do momento de executá-la é o que torna essa camada possível, porque só depois de separado é que existe um ponto claro onde aplicar todos esses limites antes do efeito colateral acontecer.

Detecção de loop e circuit breaker são dois guardrails diferentes

Um agente que tenta a mesma etapa repetidamente, sem convergir, quase sempre significa que o plano está errado, não que só falta mais uma tentativa. Isso não é apenas um problema de custo, é um problema de guardrail: um agente preso em loop pode começar a tentar variações cada vez mais agressivas da mesma ação até uma delas "funcionar", o que é exatamente o comportamento que você não quer perto de uma ação de risco.

Vale separar dois mecanismos que costumam aparecer misturados. O loop detector, ou orçamento de passos, controla o comportamento do próprio agente: repetição da mesma ferramenta, repetição do mesmo estado, ausência de progresso mensurável, número máximo de etapas, crescimento anormal do plano. O circuit breaker, por outro lado, protege a chamada entre componentes: falhas consecutivas acima de um limite, timeout de um serviço dependente, taxa de erro elevada, período de recuperação antes de novas tentativas. Um atua no nível da orquestração e da execução do agente, o outro no nível da infraestrutura da qual o agente depende. Os dois são guardrails, mas resolvem falhas de natureza diferente, e um sistema maduro precisa dos dois, não de um cobrindo o papel do outro.

Onde a maioria erra: excesso de porta de aprovação

O erro oposto ao guardrail fraco é o guardrail que trava tudo. Se toda ação passa por aprovação humana, o agente não economiza esforço nenhum, ele vira um assistente que exige mais supervisão do que o trabalho manual que substituiria. Fila de aprovação que demora horas para responder não é responsiva, e vira o motivo pelo qual ninguém confia no sistema para nada urgente.

A prática que evita os dois extremos é começar com portões conservadores, revisar a fila semanalmente procurando fadiga do aprovador e desvio de rota, e só afrouxar um portão específico depois de acumular um volume relevante de execuções limpas naquela ação. Ampliar autonomia é uma decisão baseada em evidência acumulada, não em confiança geral de que "o agente já está bom".

Um exemplo real de decisão

"

Caso real

Em um gateway de pagamentos que arquitetei, o AI Risk Agent nunca teve autoridade para bloquear ou aprovar uma transação sozinho, ele sempre devolvia uma recomendação para o motor determinístico avaliar. Isso por si só já era um guardrail: a fronteira entre análise e decisão estava desenhada no contrato de resposta, não em uma instrução de prompt.

A camada de resiliência incluía Shadow Mode, executando a recomendação da IA em paralelo ao fluxo real, sem influenciar o resultado, até acumular evidência operacional suficiente sobre concordância, estabilidade e taxa de erro em relação ao motor determinístico. Só depois desse período em sombra é que qualquer sinal da IA passou a pesar de fato no fluxo de decisão, e mesmo assim como insumo, não como decisão final.

Um circuit breaker completava essa camada, interrompendo chamadas para um componente que começava a falhar repetidamente, em vez de deixar a falha se propagar pelo resto do sistema. Guardrail, nesse desenho, não foi uma feature adicionada depois, foi parte do contrato entre os componentes desde o início.

O custo real da escolha

Latência do handoff. Toda vez que uma ação escala para aprovação humana, o tempo de resposta deixa de ser medido em segundos e passa a ser medido em minutos ou horas, dependendo da disponibilidade do aprovador. Isso precisa estar no desenho do produto, não ser uma surpresa descoberta depois que o primeiro cliente reclama de demora.

Fadiga do aprovador. Um humano que aprova a mesma categoria de ação repetidamente, sem quase nunca negar, tende a parar de ler o contexto e passar a aprovar por reflexo. Isso não é falha de caráter, é viés de automação bem documentado em pesquisa de fatores humanos e discutido também no debate jurídico sobre supervisão humana em sistemas de IA [3][4][5], o resultado esperado de colocar humano demais no caminho de coisas que raramente dão errado.

Falso senso de segurança. Um limite único de confiança, sem validação multissinal por trás dele, dá a sensação de estar protegido sem entregar a proteção de fato, porque o próprio sinal em que o limite se baseia é o sinal que mais falha exatamente nos casos que mais importam.

Fila sem SLA. Uma fila de aprovação sem prazo de resposta definido não é um guardrail, é um gargalo esperando para acontecer. Se a expectativa de resposta não está dimensionada conforme a disponibilidade real dos aprovadores, a fila cresce até alguém decidir ignorá-la.

A pergunta que quase ninguém faz

Antes de desenhar essa camada, eu respondo cinco perguntas sobre o sistema que estou construindo.

Toda ação que o agente pode executar está mapeada e classificada por nível de risco, ou só as óbvias receberam esse cuidado.

O critério de escalonamento depende de um único sinal de confiança do próprio modelo, ou existe validação multissinal por trás dele.

Existe um limite técnico de tentativas repetidas na mesma etapa antes do sistema parar e escalar, em vez de deixar o agente insistir indefinidamente.

O pedido de aprovação chega ao humano com contexto suficiente para julgar, ou é um "confirmar?" genérico que treina o aprovador a clicar sem ler.

Existe SLA definido para quanto tempo uma ação pode esperar na fila antes de virar um problema por si só.

Cada resposta fraca aqui é um guardrail que existe no papel, mas não em produção.

Como isso evolui na prática

Guardrail no prompt
"Seja cauteloso", sem enforcement real
    │
    ▼
Limite único de confiança
Melhor que nada, mas mal calibrado
    │
    ▼
Classificação de risco por ação
Auto-run, audit, validação condicionada, gate
    │
    ▼
Validação multissinal
Regras, schemas, permissões,
evidências e modelo avaliador
    │
    ▼
Produção madura
Loop detector e orçamento de passos
Circuit breaker para dependências
Fila de aprovação com SLA
Fronteira explícita entre recomendação e decisão

O salto mais arriscado dessa escada é pular do guardrail em prompt direto para produção sem passar pela classificação de risco por ação. É esse salto que produz tanto o sistema que trava em aprovação demais quanto o sistema que deixa passar uma ação irreversível sem revisão nenhuma.

Minha recomendação como arquiteto

Guardrail não é uma camada que se adiciona depois que o agente já está funcionando. É parte do contrato entre o agente e o resto do sistema desde a primeira ação que ele tem permissão de executar sozinho. Comece mapeando toda ação possível e classificando o risco de cada uma, antes de escrever qualquer lógica de escalonamento.

O critério mais simples que uso para saber se um guardrail é real: ele continua funcionando mesmo quando o modelo, por engano ou por design malicioso de um prompt externo, decide ignorar a própria instrução de cautela. Se a resposta for não, o que você tem é uma esperança bem escrita, não uma arquitetura.

Um agente rápido demais, aprovando tudo sozinho, e um agente lento demais, esperando aprovação para tudo, falham pelo mesmo motivo: ninguém desenhou a régua de risco entre os dois extremos.

Referências técnicas

[1] "Wired for Overconfidence: A Mechanistic Perspective on Inflated Verbalized Confidence in LLMs". arXiv, 2026. https://arxiv.org/pdf/2604.01457

[2] "Large Language Models Are Overconfident in Their Own Responses". arXiv, 2026. https://arxiv.org/pdf/2606.03437

[3] Center for Security and Emerging Technology, Georgetown University. "AI Safety and Automation Bias", issue brief. Novembro de 2024. https://cset.georgetown.edu/wp-content/uploads/CSET-AI-Safety-and-Automation-Bias.pdf

[4] "Check the box! How to deal with automation bias in AI-based personnel selection". Frontiers in Psychology, 2023. https://www.frontiersin.org/journals/psychology/articles/10.3389/fpsyg.2023.1118723/full

[5] "Automation Bias in the AI Act: On the Legal Implications of Attempting to De-Bias Human Oversight of AI". arXiv, 2025. https://arxiv.org/pdf/2502.10036