LLM ou motor de regras: quando a regra escrita à mão ainda ganha do prompt?

Fala aí, beleza? Vou começar com uma frase que parece heresia em 2026: nem toda decisão precisa de um modelo, e algumas ficam PIORES com ele 😛

Se você está automatizando uma decisão, cedo ou tarde cai nesse dilema

Pode ser aprovar um pedido, classificar um chamado, calcular um preço ou liberar um acesso, a pergunta é sempre a mesma

Escrevo a regra explícita (if, tabela, lista) ou monto um prompt e deixo o LLM inferir o critério?

Essa escolha entre LLM ou motor de regras não se resolve no hype, se resolve por critério

Então bora comparar os dois em cinco pontos: estabilidade da saída, custo de mudança, revisão por quem não é dev, custo e latência, e o jeito de lidar com casos ambíguos 🙂

Motor de regras vs prompt de decisão: comparação por critério

Critério	Regras explícitas	Prompt de decisão (LLM)
Estabilidade da saída	Só produz saídas dentro do conjunto definido: mesma entrada, mesma resposta	Varia entre execuções mesmo configurado pra ser previsível (temperatura 0 reduz, mas não elimina a variação)
Custo de mudança	Edita a linha da regra, roda os testes e segue	Reescreve o prompt, revalida o comportamento e ainda depende do ciclo de vida do modelo
Revisão por quem não é dev	Regra legível e auditável, dá pra revisar junto com o time de negócio	Critério implícito no prompt, o comportamento real só aparece rodando
Custo e latência	Não depende de chamada a modelo	Sistemas agênticos trocam latência e custo por desempenho na tarefa, segundo a Anthropic
Casos ambíguos e texto livre	Fraco, só cobre o que foi previsto	Ponto forte: interpreta intenção e linguagem natural

Lendo a tabela: a regra leva quase todos os critérios, e o LLM ganha num só

Só que esse único critério é exatamente onde a regra não alcança, e é por isso que a resposta certa quase nunca é "só um dos dois"

Mas antes de chegar no híbrido, vale entender por que a regra ganha nos outros pontos

Por que temperatura 0 não deixa o prompt tão estável quanto uma regra?

A primeira reação de quem quer um LLM previsível é: "beleza, coloco temperatura 0 e pronto"

Será? 🤔

Um estudo empírico com o ChatGPT em geração de código (arXiv, 2023) mostrou que temperatura 0 traz mais determinismo que a configuração padrão, porém NÃO garante determinismo

Outro estudo acadêmico, de 2024, focado só nesse tema, observou que configurações ditas "determinísticas" continuam produzindo saídas diferentes entre execuções

E por que isso acontece?

A causa: falta de batch invariance

Em setembro de 2025 a Thinking Machines Lab publicou uma análise apontando a principal causa do não determinismo nos endpoints de inferência: a variação de batch

Que batch?

É o lote de requisições que o servidor processa junto, e o tamanho dele muda conforme a carga do servidor

O problema é que vários kernels (as rotinas de baixo nível que fazem as contas do modelo) não são invariantes ao batch, então o mesmo prompt pode sair diferente dependendo de quem mais está usando o servidor naquele momento haha

O laboratório publicou kernels invariantes ao batch no repo thinking-machines-lab/batch_invariant_ops e demonstrou inferência determinística com temperatura 0 rodando o Qwen3-8B no vLLM

Tome cuidado aqui: isso é uma demonstração específica, com modelo e stack definidos, e não o comportamento padrão de quem consome uma API hospedada

Resumindo o critério: se a decisão precisa dar sempre a mesma resposta pra mesma entrada, a regra entrega isso por construção, sem depender da carga de servidor de ninguém

O custo de mudança que ninguém conta: o modelo também se aposenta

Quando se fala em custo de mudança, todo mundo pensa no lado de dentro: "quanto trabalho dá alterar o critério?"

Só que tem o lado do fornecedor também, e esse ninguém coloca na conta

Na Anthropic, os modelos passam por um ciclo de vida documentado com quatro estados:

• Active: disponível normalmente
• Legacy: estado intermediário do ciclo
• Deprecated: indisponível pra novos clientes, segue funcionando pros atuais até a aposentadoria
• Retired: indisponível, e requisições a um modelo após a data de aposentadoria falham

A política garante pelo menos 60 dias de aviso antes de aposentar um modelo publicamente lançado

Exemplo concreto: o Claude Sonnet 4.5 foi depreciado em 30/09/2026, com aposentadoria tentativa em 30/11/2026

E o que isso significa pro seu prompt de decisão?

Que ele foi calibrado em cima de um modelo específico, e quando o modelo muda, o prompt precisa ser revalidado

Aquele critério que estava redondinho pode mudar de comportamento no modelo novo, e você só descobre testando tudo de novo

Já a regra escrita à mão não tem prazo de validade imposto por terceiros, ela muda quando VOCÊ decide mudar 🙂

Cenários em que escrever a regra é mais rápido e mais seguro

Uma regra ou um lookup só produz saídas dentro do conjunto definido

Pra checagem de conformidade, precificação e permissões, código determinístico elimina uma classe inteira de falhas, e isso vale MUITO mais que a flexibilidade do modelo

Se liga nos cenários:

Checagem de conformidade

O critério vem de norma, contrato ou política interna, então ele já existe escrito em algum lugar

Traduzir isso pra regra deixa o compliance revisar linha por linha, e qualquer auditoria consegue reproduzir a decisão

Cálculo de preço e desconto

Preço não pode "variar um pouquinho" dependendo da execução, né?

Uma tabela de faixas e planos é legível pra qualquer pessoa do comercial, e o resultado é sempre o mesmo

Controle de permissões e acesso

Aqui o erro custa caro: liberar o que não devia é falha de segurança

Uma regra explícita (perfil X acessa recurso Y) é auditável e não depende de o modelo "entender" a política

Roteamento com critério fixo

Quando a entrada tem campos, faixas ou listas conhecidas, decidir o destino é um if, não um problema de interpretação

O time de operação lê a regra e já sabe por que o chamado foi parar naquela fila

Validação de formato que uma regex resolve

CEP, e-mail, código de produto e por aí vai

Pedir pra um LLM validar formato é tipo usar o PC da Nasa pra fazer conta de padaria xD

Pra ter uma ideia do tamanho da coisa, olha como fica a regra na prática:

import re

def calcular_desconto(cliente):
    # regra explícita: o time de negócio lê e entende
    if cliente.plano in PLANOS_COM_DESCONTO:
        return TABELA_DESCONTO[cliente.plano]
    return SEM_DESCONTO

def cep_valido(valor):
    # formato fechado: regex resolve, sem modelo
    return re.fullmatch(PADRAO_CEP, valor) is not None

Repara que dá pra mostrar isso pra alguém do financeiro e ele entende o critério, o que não acontece com um prompt de vários parágrafos

E quando o LLM faz sentido?

O modelo ganha justamente onde a regra trava:

• Texto livre: e-mail de cliente, descrição de problema, comentário aberto
• Intenção ambígua: quando a mesma frase pode significar coisas diferentes
• Casos que o estágio determinístico não cobre: o que sobrou depois que as regras fizeram a parte delas

E tem o meio do caminho, quando a regra depende de contexto e nem sempre cabe num if simples, aí a análise fica mais fina

Arquitetura híbrida: regra primeiro, LLM nos casos difíceis, regra validando a saída

Análises técnicas recentes recomendam um funil em três estágios:

1. Pré-processamento e roteamento determinísticos: a regra resolve tudo que tem critério claro
2. LLM só no que sobrou: o modelo entra apenas nos casos que o estágio determinístico não resolve
3. Validação determinística da saída: uma regra confere se o que o LLM devolveu é aceitável

Na prática, a regra fica nas duas pontas e o modelo fica no meio, só onde ele realmente faz diferença

Isso conversa direto com a distinção que a Anthropic faz no guia Building effective agents

De um lado, workflows: LLMs e ferramentas orquestrados por caminhos de código predefinidos, que oferecem previsibilidade e consistência pra tarefas bem definidas

Do outro, agentes: o LLM dirige o próprio processo e decide dinamicamente o que fazer

O funil híbrido é um workflow, o código manda e o modelo é só uma etapa

Como fica um fluxo de decisão nesse formato?

Imagina um sistema que recebe chamados de suporte

Primeiro, a regra olha os campos: se o chamado veio com uma categoria de uma lista conhecida, ela roteia direto pra fila certa e acabou, sem modelo nenhum

Se o chamado veio só com texto livre, aí sim ele vai pro LLM, que classifica escolhendo entre as categorias da mesma lista fechada

Por último, outra regra confere a resposta: a categoria devolvida existe na lista? Se existe, segue o fluxo, se não existe, o chamado vai pra triagem humana

Assim sendo, o modelo nunca consegue inventar um destino que não existe, porque a saída dele passa por uma porta que só aceita valores do conjunto definido 😀

Veredito: como decidir entre regra e prompt no seu projeto

Meu veredito é bem direto: comece pela baseline determinística

Monte a versão com regra ou regex primeiro, e só adote o LLM se ele superar essa baseline nas métricas de negócio

Se não superar, você economizou custo, latência e uma dor de cabeça de revalidação, não é maravilhoso? haha

Isso bate com a própria diretriz da Anthropic: buscar a solução mais simples possível e só aumentar a complexidade quando necessário, o que pode significar não construir nada agêntico

A mesma lógica vale quando você está codando com IA, às vezes o mais rápido é parar de insistir com o Claude Code e escrever o trecho na mão

Checklist rápido antes de escolher:

• O critério cabe numa regra? Se dá pra escrever como if, tabela ou lista, escreva
• A saída precisa ser reproduzível? Se a mesma entrada tem que dar sempre a mesma resposta, a regra vence
• Alguém fora do time técnico precisa auditar? Regra legível ganha de prompt implícito
• O custo e a latência extras se pagam? Se o LLM não melhora a métrica de negócio, ele não se justifica

Se respondeu "sim" pras três primeiras, nem precisa da quarta: é regra

Vai tirar a regra do papel com o Claude Code?

Pra começar do zero com o Claude Code e usar ele pra implementar regras, validações e fluxos como os deste post, este vídeo do canal mostra 20 recursos da ferramenta, do básico ao avançado

Conclusão: o melhor prompt às vezes é um if

A regra escrita à mão ganha onde a decisão precisa ser estável, barata de mudar e legível pra quem não programa

O LLM ganha no ambíguo, no texto livre e em tudo que não dá pra prever, e o híbrido junta os dois com o código no controle

Próximo passo concreto: liste as decisões do seu sistema, separe as que cabem em regra, monte a baseline e meça o LLM contra ela antes de adotar

Faça o teste no seu projeto, aposto que mais de uma decisão vai virar um if bem simples 🙂

Até o próximo post!

Perguntas frequentes

Usar temperatura 0 no LLM garante a mesma decisão sempre?

Não. Um estudo empírico com ChatGPT em geração de código mostrou que temperatura 0 reduz a variação de saída, mas não elimina ela. Outro estudo acadêmico de 2024, focado só nesse tema, confirmou que configurações ditas determinísticas continuam produzindo saídas diferentes entre execuções. Se a decisão exige resposta idêntica pra mesma entrada, uma regra explícita entrega isso por construção.

Qual a diferença entre workflow e agente de IA na prática?

A Anthropic diferencia os dois assim: workflow é LLM e ferramentas orquestrados por caminhos de código predefinidos, e agente é o LLM decidindo dinamicamente o próprio processo. Workflows entregam previsibilidade e consistência pra tarefas bem definidas, o que aproxima esse modelo do raciocínio de regra explícita. A recomendação da própria Anthropic é achar a solução mais simples possível antes de subir a complexidade pra um sistema agêntico.

Como saber se vale trocar uma regra por um prompt de decisão?

A recomendação é comparar a feature de IA com uma baseline determinística simples, como regex, antes de qualquer coisa. Só segue com o LLM se ele superar essa baseline nas métricas de negócio que importam pro seu caso. Sem essa comparação, a troca é feita no achismo, não no critério.

Dá pra combinar LLM e motor de regras no mesmo sistema?

Sim, e análises técnicas recomendam exatamente isso: um funil onde o pré-processamento e o roteamento são determinísticos, o LLM entra só nos casos que esse estágio não resolve, e a saída do LLM passa por validação determinística. Esse arranjo usa a regra onde ela é mais forte (estabilidade, auditoria) e o LLM só onde ele é mais forte (ambiguidade, linguagem natural).

O que acontece se eu deixar meu prompt calibrado num modelo que entra em aposentadoria?

Na Anthropic, o modelo passa por quatro estados: Active, Legacy, Deprecated e Retired, e chamadas a um modelo depois da data de aposentadoria falham. A política garante pelo menos 60 dias de aviso antes dessa aposentadoria, e o caso do Claude Sonnet 4.5 (depreciado em 30/09/2026, aposentadoria tentativa em 30/11/2026) mostra o prazo real. Isso significa que o prompt precisa ser revalidado quando o modelo muda, algo que a regra escrita à mão não exige.

Por que compliance e controle de permissão costumam usar regra em vez de LLM?

Porque uma regra ou lookup só produz saídas dentro do conjunto definido, então o resultado é sempre reproduzível pra mesma entrada. Em checagem de conformidade, cálculo de preço e controle de acesso, código determinístico elimina uma classe inteira de falhas que viria de variação de saída. É por isso que esses três cenários aparecem como recomendação de regra explícita, não de prompt.