LLMs de Decisão: Quando um Modelo Deve Decidir — e Quando Não

Pergunte a praticantes o que quebra em sistemas de agentes e a resposta raramente é a capacidade. A falha é mais silenciosa: o modelo decide, e ninguém consegue distinguir o correto do apenas fluente.

A saída de um modelo é uma amostra. Uma decisão tem propriedades que uma amostra não possui — determinismo para uma entrada fixa, invariantes que ela deve satisfazer e um rastro de auditoria que explica por que foi escolhida esta opção e não a alternativa. Quando essas propriedades estão ausentes, a “decisão” é apenas uma suposição de alta confiança vestida com as roupas de uma decisão real.

Este artigo oferece um tratamento mecânico para essa lacuna: uma taxonomia de cinco papéis de decisão, uma regra para rotear cada decisão para o menor modelo competente para ela e a maquinaria de verificação que transforma “o agente decidiu X” em algo que você pode provar posteriormente ter sido correto. Ele se encerra com uma rubrica que você pode executar contra qualquer ação no seu próprio sistema.

“Para agentes locais, a lacuna com a qual eu continuo a bater não é a capacidade, mas sim a verificação. O agente diz que leu um arquivo, chamou uma ferramenta ou tomou uma decisão…” — r/LocalLLaMA, “Melhores Agentes Locais — Jun 2026”

“Quando um agente de LLM falha, é uma caixa preta e ninguém sabe por quê. O verdadeiro gargalo para a adoção não é levar um modelo de 92% para 96% de precisão — [é saber por que ele decidiu X].” — r/AI_Agents, “A lacuna entre decisão e execução”

A comunidade convergiu para três instintos: não confiar no modelo a decisão final, rotear a decisão para o menor modelo competente e tornar a decisão explicável. O que tem estado ausente é o quadro (framework) que torna os três acionáveis simultaneamente.

Por que “ele responde, mas ele decide?”

A saída de um modelo é uma distribuição de tokens colapsada em uma única sequência, e o mesmo prompt executado duas vezes pode produzir duas sequências que divergem exatamente no token que importa. Uma decisão, por outro lado, é determinística para uma entrada fixa, satisfaz invariantes explícitos e deixa um rastro de auditoria que registra qual ramo foi tomado e por quê.

Quando um modelo “decide” sem uma maquinaria ao redor, nenhuma dessas propriedades existe. Não há invariante que a saída seja obrigada a respeitar, não há log do ramo tomado, não há forma de reproduzir a decisão e verificar se ela se manteve. A lacuna não é inteligência — é que uma saída probabilística foi colocada em um slot projetado para um determinístico.

O instinto do praticante é manter o modelo fora da decisão completamente:

“O LLM nunca toma decisões finais no sistema. Seu papel é puramente: refinamento de lógica, testes de estresse, geração de cenários, explicação.” — r/AI_Agents, “Usando um LLM como um ‘agente de raciocínio’ para validar preços…”

Essa é a postura correta stated como um lema. Para aplicá-la, você precisa de uma forma de classificar qual papel o modelo deve ter para uma dada ação — o que é o que a taxonomia abaixo fornece.

Cinco papéis de decisão

Toda decisão que um sistema toma pode ser atribuída a um de cinco papéis. O papel determina quanto a saída do modelo pode ser confiada, como é auditado, como falha e se um humano deve estar no circuito.

Leia a tabela como uma restrição, não como um menu. A maioria dos sistemas quebrados compartilha um defeito: um único modelo preenche todos os cinco papéis ao mesmo tempo, de modo que um papel que exige determinismo (decisor) é servido por um componente otimizado para fluência (gerador). Onde o modelo atua como gerador, nenhuma das maquinarias de decisão é necessária — é a revisão de conteúdo. A falha a evitar é confundir esses elementos: “o agente decidiu apagar o ambiente” é geralmente uma falta de portão de aprovação, não um problema de qualidade de decisão.

Roteie a decisão para o menor modelo competente

Uma vez fixado o papel, a questão de roteamento é qual camada (tier) de modelo o serve. Praticantes relatam o benefício diretamente:

“Roteamento de modelo: Haiku para decisões de classificação/roteamento, Sonnet para execução, Opus apenas para design/planificação. O custo caiu cerca de 60% depois que parei de usar Opus para tudo.” — r/AI_Agents, “Qual é a sua pilha completa de agentes de IA em 2026”

Esse número vem de tratar a seleção de modelo como uma decisão por papel em vez de uma por sistema. Uma chamada de roteamento — “isto é uma triagem de e-mail ou uma aprovação de reembolso?” — é uma classificação, e a classificação não precisa de um modelo de fronteira; precisa de um modelo pequeno, rápido, de baixa temperatura, porque ela é executada milhares de vezes. As mecânicas da camada — seleção baseada em capacidade, ciente de custos e ciente de latência, além de cadeias de recurso (fallback) — são cobertas em Roteamento de Modelo: Pare de Usar Um Modelo Para Tudo; os padrões de orquestração ao redor de múltiplos modelos estão em Design de Sistemas Multi-Modelo.

A adição que o enquadramento de decisão contribui é a escalada baseada em confiança, o que faz com que “menor competente” seja medido em vez de assumido. Comece na menor camada. Se o modelo emite uma confiança calibrada — ou uma autoavaliação estruturada — e ela limpa um limiar, pare. Se não, escale uma camada e registre a escalada. A competência é então uma propriedade verificada por chamada, não uma propriedade assumida por modelo.

Uma restrição permanece absoluta independentemente da camada: o próprio papel de roteador não deve ser uma chamada livre de modelo de linguagem. Uma espinha dorsal determinística — regras sobre tipo de tarefa, tamanho da carga útil (payload), orçamento de custo — seleciona o ramo, e o modelo preenche apenas as decisões de folha dentro dele. A espinha dorsal é auditável e testável por unidade; o modelo é contido ao que ele é realmente bom.

Tornando a decisão verificável

É aqui que a lacuna de “o agente diz que fez X” se fecha. A correção é tornar a decisão um artefato estruturado de primeira classe, em vez de um efeito colateral de uma virada de conversa:

1. Um armazém de decisões estruturado. Toda decisão que o modelo é permitido tomar é escrita em uma tabela, não em uma linha de log: a entrada, o papel, o modelo e a camada, a confiança, as alternativas consideradas, o timestamp. Uma decisão é algo que você pode SELECT posteriormente. Se ela vive apenas em um transcrito de conversa, é uma suposição.
2. Um log de decisão, separado do log de execução. O log de execução diz o que aconteceu; o log de decisão diz o que foi decidido e em que base. A separação importa porque a falha está geralmente na decisão, não na execução — o agente executou a perfeitamente; o bug foi decidir apagar. As mecânicas de registro estruturado, somente de adição, são as mesmas usadas para rastros de auditoria de conformidade em Guardrails de LLM na Prática.
3. Invariantes e asserções. Para papéis de decisor e avaliador, a decisão deve satisfazer invariantes checados após o modelo a emitir, em código determinístico. Um recomendador de preço pode emitir qualquer coisa; o invariante “preço recomendado deve estar dentro de [piso, teto]” é aplicado por código. O modelo propõe; o invariante dispõe.
4. Portões de aprovação humana na fronteira de irreversibilidade. O portão é uma propriedade do raio de explosão (blast radius) da ação, não da confiança do modelo. Um reembolso abaixo de um limiar é aprovável automaticamente; um acima dele, não. Um modelo com confiança de 99% ainda não pode aprovar uma ação irreversível para a qual não tem registro de auditoria.

A linha condutora: o empurrão de precisão de 92% para 96% não é o gargalo — é a explicabilidade. Um sistema a 92% com cada decisão registrada, checada por invariantes e portalizada na fronteira é embarcado com segurança, porque os 8% de decisões incorretas são encontráveis antes de causarem danos. Um sistema a 99% com um processo de decisão de caixa preta não é, porque os 1% é um incidente vivo sem registro forense. Onde o próprio portão reside em um assistente — qual componente detém a autoridade de aprovação e como as solicitações chegam até ele — é delineado em Arquitetura de Assistente de IA: LLM, Memória, Ferramentas, Roteamento, Observabilidade.

Exemplos práticos

Três sistemas, uma atribuição de papel cada.

Validação de preço — o modelo como recomendador, nunca decisor. Um agente revisa uma mudança de preço de um fornecedor e produz uma lista ranqueada: aceitar, negociar em X, rejeitar. A chamada final é um slot de decisor preenchido por regras determinísticas: abaixo do piso de custo, aceitar automaticamente; acima do teto, rotear para um humano; no meio, aplicar o invariante “preço negociado deve superar o último aceito em Y%.” O modelo nunca aprova sua própria recomendação, e a recomendação reside no armazém de decisão com seu rastreio de rubrica caso algo corra mal.

Roteamento de tarefas de agentes — a espinha dorsal como decisor, o modelo nas folhas. Uma requisição recebida (e-mail, bilhete, comando) é atribuída a um caminho pela forma da carga útil e categoria de intenção — determinístico, testável por unidade. Um pequeno modelo preenche apenas a decisão de folha dentro do ramo. Um desvio de rota é um evento de raio de explosão, que é exatamente por que a seleção do ramo deve ser determinística.

LLM como juiz — o modelo como avaliador, a rubrica como restrição. Um modelo pontua a saída de outro contra uma rubrica versionada, e a pontuação mais o rastreio da rubrica são armazenados, não apenas o número. O modo de falha conhecido é o viés de auto-preferência — um modelo pontuando seu próprio estilo de geração mais alto — e a mitigação é estrutural: versionar a rubrica para que um modelo nunca esteja silenciosamente pontuando contra critérios que ele próprio moldou.

A fronteira honesta

Há uma classe de decisão que um LLM não deve tomar, e não é uma questão de escala: ações que são irreversíveis, de alta aposta e não têm recurso — exclusão de dados, movimentação de fundos, compromissos externos. A verificação é impossível para uma ação que você não pode reverter, que é por que “agente autônomo” continua a bater na mesma parede independentemente da qualidade do modelo.

O humano-no-circuito que não é teatro reside exatamente nessa fronteira e em nenhum outro lugar. Um humano revisando cada decisão de baixa aposta adiciona atrito e nenhuma segurança; um humano ausente de cada decisão de alta aposta é o incidente. O mesmo princípio aparece em uma forma mais restrita na memória de agentes: laços de memória auto-reforçantes portam gravações de memória candidata atrás de aprovação humana explícita antes de qualquer coisa alcance estado durável — o portão dimensionado ao que a gravação pode quebrar. Para sistemas multi-agente, a questão correspondente é quem pode agir em nome de quem, e a maquinaria de identidade, delegação e rastro de auditoria para isso está em Segurança de Agentes A2A e MCP.

A rubrica de decisão

Execute isto contra qualquer ação no seu sistema:

1. Classifique o papel. Decisor, recomendador, avaliador, gerador ou roteador? Um papel sem nome é um bug — um modelo em um slot de decisor vestindo a confiança de um gerador.
2. Escolha a camada para aquele papel. Menor competente, com escalada baseada em confiança para que a competência seja medida por chamada.
3. Defina a verificação. Quais invariantes devem se manter? O que vai no armazém de decisão? Qual é o rastreio de auditoria? Um papel sem caminho de verificação é um decisor por padrão.
4. Defina o portão humano do raio de explosão, não da confiança. Irreversível ou alta aposta → portalizado. Caso contrário → automático, com a decisão registrada para que seja encontrável.

A mesma disciplina, aplicada a escolhas de engenharia em vez de ações de tempo de execução, é o que registros de decisão fazem — Registros de Decisão para Desenvolvimento Orientado por IA captura por que uma escolha foi feita para que possa ser revisada posteriormente; a rubrica acima faz o mesmo para as decisões que um sistema em execução toma.

O que vem: o decisor como produto

O framework prevê sua própria comoditização: uma vez que “rotear a decisão para o menor modelo competente” se tornou um padrão, o próximo passo foi uma classe de modelo que não faz nada além de decidir. Esse passo já chegou.

Durante outubro de 2026, vários fornecedores lançaram modelos construídos sobre uma receita compartilhada — um esqueleto Qwen congelado, um adaptador LoRA de rank-256 e uma cabeça de esquema conjunta — que emitem decisões tipadas em uma única passagem direta (forward pass): uma escolha de um conjunto enumerado, um sim/não, ou uma pontuação, com probabilidades calibradas e sem texto em forma livre. Não há cadeia de raciocínio (chain of thought) para esperar, porque não há geração. A latência relatada por fornecedores situa-se entre aproximadamente 8 e 210 ms na classe — da menor variante (d1-3B, cerca de 8 ms) até a maior (d3, cerca de 209 ms) — e as pegadas (footprints) são de território de GPU pequena: d1-3B a cerca de 1,67 GB, d3-flash a cerca de 6,6 GB em Q4_K_M. O suporte também moveu-se rápido: o llama.cpp mesclou suporte de arquitetura nativa para vários desses modelos dentro de aproximadamente duas semanas do lançamento.

Duas consequências para o framework acima. Primeiro, a regra de roteamento obtém uma expressão de hardware que não tinha antes: o papel de decisor pode ser servido por um pequeno modelo dedicado em vez de um modo de prompt de um modelo geral, o que torna a decisão da menor-camada-competente parcialmente automática — a camada ou existe para o seu tipo de decisão ou não existe. Segundo, nada sobre verificação muda. Uma decisão tipada em 8 ms ainda precisa do armazém de decisão, dos invariantes e do portão na fronteira de irreversibilidade; o que a classe de modelo remove é o custo de geração e a não-determinística, não a carga de auditoria. Decisões mais rápidas multiplicam o número de registros de decisão a auditar — o gargalo nunca foi a velocidade do modelo, e não é a inteligência do modelo também.

As outras direções para observar são mais silenciosas. A confiabilidade de chamada de ferramentas para modelos pequenos está se aproximando da saturação — o pós-treinamento em uso de ferramentas é o passo de maior impacto e mais barato na pilha, o que desloca a atenção para as linhas acima. Horizontes de planejamento confiáveis continuam se estendendo, o que torna o papel de decisor alcançável para tarefas mais longas e cresce a carga de verificação com o horizonte. Ambos alimentam a mesma conclusão: o recurso escasso em sistemas de agentes são decisões que você pode provar posteriormente terem sido corretas, e tudo mais está a caminho de se alinhar a isso.