Jev ou motor de regras de negócio: quem decide quando a regra depende de contexto?

Fala aí, beleza? Você já abriu aquele arquivo de regras de negócio que tem um if com sete condições encadeadas, três exceções comentadas com o nome de um cliente e um TODO de 2023?

Eu aposto que sim 😅

E quase sempre o motivo é o mesmo: em algum ponto a regra precisou olhar pra um campo que NÃO é estruturado

Um texto livre de observação, o corpo de um e-mail, a descrição que o cliente digitou no formulário

A tabela de regras não sabe ler isso, então alguém tentou aproximar com contains("urgente") e a partir dali cada caso novo virou mais um if

A pergunta do post é essa: quando vale manter a regra explícita no código e quando vale delegar o julgamento pro Jev?

Bora destrinchar isso com critério, sem torcida

O que é o Jev e por que ele não é "mais um LLM no meio da regra"

O Jev é o primeiro modelo System One da TypeSafe AI

A diferença pro que tu já conhece é estrutural: ele não gera texto

Ele recebe um estado (texto ou JSON) mais perguntas tipadas, e devolve decisões tipadas com probabilidades que teu código consome direto

Estado + perguntas tipadas entram, decisões com probabilidade saem

Se você já trabalhou com validação de schema, a analogia é boa: em vez de receber uma string e ter que parsear a intenção do modelo, você declara o formato da resposta antes e recebe exatamente aquilo

Pré-inscrição Curso Jev

Domine o Jev e coloque decisões de IA dentro do seu sistema

Você vai aprender a usar o Jev, o System One Model da TypeSafe AI, pra automatizar decisões com resposta tipada e confiança medida, sem depender de chat nem de alguém revisando cada passo. Entre na lista de espera para garantir a condição de lançamento!

Quero minha vaga

As três primitivas de pergunta:

• Noul: probabilidade de sim/não
• Choice: uma opção de um conjunto que VOCÊ define, com probabilidade por opção e um campo confidence
• Score: um nível dentro de uma escala ordenada e descritiva, com probabilidade por nível

E a chamada acontece num endpoint próprio de avaliação, não em /chat/completions:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d @payload.json

No payload.json vai o estado e as perguntas tipadas que você quer avaliar contra ele

Outro ponto que muda o jogo: o treino é com RLCD (Reinforcement Learning for Calibrated Decisions), que otimiza pra probabilidade calibrada

Calibrado significa o seguinte: num modelo bem calibrado, os eventos que saem com probabilidade 0,2 acontecem em torno de 20% das vezes

Isso é MUITO diferente de um número de confiança inventado por um LLM que você não sabe se significa alguma coisa

De pano de fundo, só pra situar maturidade: a TypeSafe AI saiu do stealth em 15 de setembro de 2026 com US$ 40 milhões em seed liderado pela DCVC

E o acesso está aberto pra qualquer pessoa, sem waitlist

Beleza, contexto dado

Agora o que interessa 😀

Motor de regras x Jev: comparação nos critérios que importam

Repara numa linha específica dessa tabela: o alias

O jev-latest é o padrão do SDK e é o que aparece nos exemplos da doc

É cômodo, mas ele é um ponteiro móvel dentro do teu sistema de decisão

Tome cuidado! Pra caminho crítico, fixar jev-1.13 é escolha consciente, não frescura

Quando a regra explícita ganha (e quando ela trava)

Tem um conjunto de casos em que nem se discute: fica no código

• Alçada financeira (acima de X reais precisa de aprovação do gestor)
• Qualquer cálculo: imposto, desconto, rateio, juros
• Data e prazo: vencimento, SLA, janela de carência
• Regra regulatória que precisa de trilha de auditoria exata, com a cláusula identificável

E isso não é só preferência estética

A própria TypeSafe lista as limitações conhecidas do jev-1.13, e elas batem certinho com essa lista:

• O Score tem calibração numérica fraca e NÃO serve pra reconstruir números exatos interpolando entre níveis
• O modelo lê datas como texto, não como quantidades ordenadas, então comparação e cálculo com data ficam pouco confiáveis
• E ele tem dificuldade em tarefas que exigem precisão numérica

Ou seja: se a tua condição é "faz mais de 30 dias que o pedido foi criado", isso é uma subtração, não um julgamento

Deixa no código e segue a vida 🙂

Agora, onde a regra explícita TRAVA?

Quando a condição depende de interpretar algo que ninguém tipou

"Se o cliente está claramente irritado, escala pro N2"

"Se o e-mail descreve um problema de cobrança e não de produto, roteia pro financeiro"

"Se a descrição sugere risco de segurança, abre incidente"

Você até começa com uma lista de palavras-chave

Aí chega o ticket que diz "não estou bravo, só queria entender por que me cobraram duas vezes" e a tua heurística manda pro time errado

E a correção vira mais um if, que vira mais um caso de teste, que vira aquele arquivo que ninguém mais quer abrir

Quando o Jev ganha: a regra que não consegue ler contexto

O território natural dele é julgamento de senso comum sobre dado não estruturado

Alguns casos diretos:

• Roteamento de intenção na frente do teu agente, decidindo qual handler invocar em vez de mandar toda mensagem pro LLM caro
• Triagem de ticket: categoria, urgência percebida, se precisa de humano
• Classificação de reclamação por tema e por tom
• Detecção de risco em texto livre (menção a dado sensível, ameaça de churn, pedido de cancelamento disfarçado)

E tem um detalhe operacional que muda o desenho da tua chamada: dá pra misturar Choice, Score e Noul numa única requisição, avaliando várias perguntas contra o MESMO estado

Uma resposta por pergunta, uma chamada só

A documentação mostra que agrupar 13 perguntas em uma chamada sai 10,0x mais rápido do que fazer 13 requisições separadas, sem mudança nas respostas

Isso é ganho de graça, literalmente: mesmo estado, mesmo julgamento, um décimo do tempo de parede

A TypeSafe também afirma que o Jev atinge inteligência comparável à de LLMs em tarefas System One sendo duas ordens de magnitude mais rápido e mais eficiente, o famoso "~100x mais rápido e mais barato" em tarefas de decisão

Marco isso como claim oficial da empresa, não como medição independente

E quando o Jev entra num agente, a divisão fica bem clara: dá pra deixar o Jev decidindo e o LLM escrevendo, cada um no que faz melhor

Auditabilidade e custo de manutenção: o que cada abordagem cobra de você

Essa é a parte que quase ninguém compara direito, então vamos com calma

A regra explícita cobra manutenção

Em troca, ela te dá rastro perfeito: dá pra apontar a linha, o commit, a data e o motivo

Se amanhã um auditor perguntar "por que esse pedido foi aprovado?", a resposta é uma cláusula

O preço é que toda exceção nova é trabalho de engenharia, e a entropia do arquivo de regras só cresce

O Jev cobra disciplina de versionamento e de observação

A decisão vem tipada e com probabilidade calibrada, então dá pra logar a pergunta, a resposta, a probabilidade e o confidence junto do registro da transação

Só que isso exige duas coisas da tua parte:

1. Decidir se você chama jev-1.13 fixo ou o alias jev-latest, sabendo que o alias muda quando sai release novo e as respostas por trás dele podem mudar sem você alterar uma linha de código
2. Manter um conjunto de casos de referência com o resultado esperado, pra rodar quando a versão mudar e detectar deriva

O ponto 2 é o equivalente ao teu teste de regressão do motor de regras

Só que em vez de testar a cláusula, tu testa o julgamento

E tem o óbvio que todo mundo esquece: chamada de rede pode não voltar

Vale desenhar desde o começo o que acontece quando a decisão não chega, porque motor de regras local nunca te ensinou a pensar nisso

O critério simples para escolher

Sem enrolação, o critério que eu usaria:

• A condição pode ser escrita como comparação sobre campo estruturado? Regra em código
• A condição depende de interpretar texto livre ou senso comum? Pergunta tipada pro Jev
• A condição envolve número exato, data ou efeito colateral? Volta pro código, sem discussão

E a própria documentação da TypeSafe empurra pra esse lado, com a orientação de manter fluxo de controle, regras determinísticas e efeitos colaterais no código, deixando pro modelo apenas os julgamentos de senso comum sobre dados não estruturados

Ou seja: não existe vencedor absoluto nesse comparativo, e o Jev NÃO substitui teu motor de regras

Ele resolve a parte que o motor de regras nunca conseguiu resolver, que é enxergar o que está escrito em português no meio do payload

Usando os dois juntos: o desenho que costuma funcionar

O arranjo mais saudável é em camadas

1. Jev na entrada, transformando o não estruturado em decisão tipada

O e-mail, o comentário, a descrição entram como estado

Saem campos: categoria (Choice), tem_risco_financeiro (Noul), urgencia_percebida (Score)

Agrupa tudo numa chamada só, já que múltiplas perguntas por requisição é o caminho barato

2. Motor de regras consumindo esses campos junto dos campos estruturados que você já tinha

A partir daqui é a tua regra de sempre: if categoria == "cobranca" and valor > limite_alcada

Determinístico, testável, auditável

3. Roteamento por confiança antes de automatizar

O padrão oficial usa o campo confidence da resposta pra decidir o caminho:

if answer.confidence < 0.8:
    route_to_human_review(case)
else:
    route_to_handler(answer)

Abaixo do limiar, o caso vai pra revisão humana ou pra um modelo de raciocínio mais caro

Acima, segue direto pro handler automático

O erro comum aqui é tratar todo resultado como verdade absoluta e pular essa bifurcação: aí quando a decisão duvidosa aparece, ela vira incidente em produção em vez de virar fila de revisão

4. Efeito colateral fica no código, sempre

Enviar e-mail, estornar, bloquear conta: isso é responsabilidade do teu handler, nunca do modelo

Sobre caminhos de acesso, tem mais de um: API direta no endpoint de avaliação, o SDK oficial em Python, e o jev-1.13 também aparece em gateways de terceiros como o OpenRouter (typesafe/jev-1.13) e o Cloudflare AI (modelo typesafe/jev)

Se tua stack já fala com um desses, o caminho é curto

Conclusão: decida por natureza da condição, não por modismo

Recapitulando o que interessa

No debate Jev vs motor de regras, o critério não é "qual é mais moderno", é a NATUREZA da condição

Campo estruturado, número, data e efeito colateral: código

Texto livre e senso comum: pergunta tipada, com probabilidade calibrada e roteamento por confiança em cima

Auditoria você não perde em nenhum dos dois, só muda o que tu loga: cláusula de um lado, pergunta + decisão + confidence do outro

Próximo passo concreto, bem pé no chão: abre o teu arquivo de regras e marca os if que só existem porque alguém tentou adivinhar o conteúdo de um texto

Pega UM desses e reescreve como uma pergunta tipada, com as opções que tu já usa hoje

Se você trabalha com agente de código, a TypeSafe mantém uma agent skill oficial, e no Claude Code a instalação é via marketplace de plugins:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Depois é só invocar com /typesafe:typesafe-ai dentro da sessão

Em outros agentes, o caminho é npx skills add typesafe-ai/skills --skill typesafe-ai

O repositório oficial é o typesafe-ai/skills, e é um bom ponto de partida pra entender o formato das perguntas antes de sair chamando a API

E aí, tu já tem um if desses esperando na tua base? Aposto que tem 😛

até o próximo post!