Como usar o Jev como guardrail para julgar a saída de outro LLM?

Colocar um LLM pra vigiar outro LLM tem um problema chato: o vigia responde em texto livre, e aí você precisa de um terceiro pedaço de código pra interpretar o que o vigia quis dizer 😅

O Jev ataca exatamente esse ponto

Ele não devolve parágrafo, devolve decisão tipada: uma opção escolhida, um score num nível que você definiu ou a probabilidade de um sim

Neste post eu mostro como montar essa camada de verificação passo a passo: onde ela entra no pipeline, como escrever as perguntas, como aplicar threshold de confiança e o que checar antes de botar isso em produção

O que é o Jev e por que ele cabe na camada de verificação

O Jev é o modelo principal da TypeSafe AI e o primeiro modelo público da classe que eles chamam de System One

O contrato é simples: entra um estado não estruturado, saem decisões tipadas e probabilísticas

Se você já montou validação de payload com schema, a analogia é direta: em vez de confiar que o modelo vai formatar a resposta direitinho, o tipo da resposta é definido ANTES, por você

E o que é "decisão tipada" na prática? São três primitivas, três formatos de pergunta:

• Choice: escolhe uma opção de um conjunto que você definiu, e a resposta traz a opção escolhida, a probabilidade de cada opção e a confiança
• Score: avalia o estado contra níveis ordenados e descritivos, devolvendo o valor, a probabilidade de cada nível e a confiança
• Noul: a pergunta sim/não, que retorna a probabilidade da resposta ser sim

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

A TypeSafe saiu do stealth em 15 de setembro de 2026 com US$ 40 milhões em rodada seed liderada pela DCVC

A empresa foi fundada por Diogo Almeida, ex-pesquisador da OpenAI, junto com Erik Gafni e Sasha Sheng

Agora o argumento central, que é o motivo de ele caber num guardrail: como o Jev só pode devolver uma das opções que você definiu, ele não inventa opção nova nem quebra o schema de saída

Tome cuidado com a conclusão fácil aqui: não quebrar o schema não significa acertar

Ele pode perfeitamente escolher a opção errada dentro do conjunto certo, e isso continua sendo erro do seu guardrail

O que você precisa antes de começar

Antes de escrever qualquer linha, junte isso:

• Acesso liberado: o Jev está em early access, com a TypeSafe soltando gente da waitlist aos poucos, então não é disponibilidade geral ainda
• Chave de API, criada no console web em https://console.typesafe.ai
• Python 3.10 ou superior, se for usar o SDK oficial
• SDK instalado: pip install typesafe-sdk (ou uv add typesafe-sdk se tu já vive no uv)
• Variável de ambiente TYPESAFE_API_KEY configurada, que é de onde o SDK lê a chave (esse nome é convenção do SDK Python; se tu for bater direto no HTTP, o que importa é a chave chegar no header Authorization, e o nome da variável de shell fica a teu critério)

O modelo padrão do SDK é o alias jev-latest, que hoje resolve pro jev-1.13.0

E não é obrigatório usar SDK: dá pra bater direto no endpoint HTTP, o que costuma ser mais prático quando o teu backend não é Python

Um detalhe que importa MUITO em guardrail: no OpenRouter, o Jev 1.13 aparece com janela de contexto de 32.000 tokens, servido pelo próprio provedor TypeSafe

Só que atenção ao escopo desse dado: ele é da ficha do OpenRouter, que é um agregador de modelos, e não da referência do endpoint System One que a gente usa no resto do post

Então usa como ordem de grandeza pra já pensar em como vai recortar o material, e confirma o limite do endpoint na doc antes de mandar traço de raciocínio inteiro de um modelo tagarela pra julgamento

Como usar o Jev como guardrail passo a passo

1. Decida onde o verificador entra no pipeline

São dois pontos, e eles fazem perguntas diferentes

Antes do gerador, tu verifica o prompt de entrada (é aqui que mora a detecção de jailbreak e prompt injection)

Depois do gerador, tu verifica a resposta, o traço de raciocínio e as tool calls

O caso de uso de guardrails descrito pela TypeSafe é justamente esse: filtrar toda mensagem que entra e sai de um app de LLM, descrevendo os perigos possíveis e pontuando a severidade

O erro comum deste passo: colocar o verificador só na saída

Aí o prompt malicioso já queimou tokens do modelo caro antes de alguém perguntar se ele deveria ter rodado

2. Escreva o state com o material a ser julgado

O state é o estado não estruturado que o Jev vai avaliar

No screening de entrada, é a mensagem do usuário

No screening de saída, é a resposta do gerador, e, se fizer sentido pro teu caso, o traço de raciocínio e as tool calls junto

O erro comum deste passo: jogar a conversa inteira no state "por garantia"

Contexto tem limite, e quanto mais ruído tu empurra, mais difícil fica pra pergunta tipada se ancorar no que interessa

3. Escolha a primitiva certa pra cada pergunta

Essa escolha é o projeto do teu guardrail, então vale pensar com calma:

• Noul pra pergunta binária: "isto é uma tentativa de jailbreak?"
• Score pra severidade, com níveis ordenados e descritivos (o modelo avalia o estado contra esses níveis)
• Choice pra classificar o tipo de violação dentro de um conjunto fechado que tu define

O erro comum deste passo: usar Choice pra coisa que é claramente ordenada

Severidade tem ordem, e Score existe justamente pra isso

4. Monte a chamada pro endpoint System One

A chamada é um POST pra https://api.typesafe.ai/v1/systemone, com Bearer token, content-type: application/json e um corpo que tem um campo state e um mapa questions com as perguntas tipadas nomeadas por você

No exemplo abaixo eu reaproveito o nome TYPESAFE_API_KEY só como variável de shell, por comodidade de quem já configurou o SDK: aqui não tem SDK lendo nada do ambiente, quem carrega a chave é o header Authorization

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "state": "mensagem do usuario que vai ser verificada aqui",
    "questions": {
      "eh_jailbreak": { ... },
      "severidade": { ... },
      "tipo_violacao": { ... }
    }
  }'

O formato exato de cada primitiva dentro de questions está na documentação da API do System One, e é de lá que tu deve copiar o shape

A parte massa: uma única chamada aceita VÁRIAS perguntas tipadas contra o mesmo estado

Cada pergunta é avaliada em paralelo e isoladamente, e as respostas voltam sob os mesmos ids que tu informou

Ou seja, eh_jailbreak, severidade e tipo_violacao voltam com esses nomes, e o teu código lê pelo id, não por posição

O erro comum deste passo: fazer uma chamada por pergunta

Tu paga mais entrada repetindo o mesmo state e ainda perde o paralelismo que já vem de graça

5. Aplique threshold em cima do confidence

Toda resposta carrega um valor de confiança entre 0 e 1, derivado do formato da distribuição de probabilidade

Ele existe pra tu fazer comparação direta no código, sem parser, sem regex, sem reza

A orientação da documentação é agir quando a confiança é alta e escalar os casos incertos pra uma pessoa ou pra um modelo de raciocínio mais caro

if answer.confidence < 0.8:
    route_to_human_review(ticket)

Esse 0.8 é o exemplo oficial, não um número mágico

O valor correto depende do domínio e precisa ser calibrado com dados teus

O erro comum deste passo: adotar o 0.8 do exemplo e nunca mais olhar

Em guardrail, threshold mal calibrado tem dois sabores ruins: ou bloqueia usuário legítimo, ou deixa passar o que não devia

6. Decida a ação de cada faixa

Guardrail que só classifica não é guardrail, é relatório 😀

Com a decisão tipada e a confiança em mãos, as saídas possíveis costumam ser quatro: bloquear, deixar passar, escalar pra revisão humana ou mandar pra um modelo de raciocínio mais caro

Essa ideia de usar um modelo barato na primeira linha e reservar o caro pros casos duvidosos é a mesma lógica de usar um modelo leve como revisor antes de acionar o artilheiro

O erro comum deste passo: tratar score alto e confiança baixa como bloqueio automático

São coisas diferentes: severidade alta com confiança baixa é exatamente o caso que a doc manda escalar

O que dá para julgar além de jailbreak

A documentação de casos de uso da TypeSafe lista mais coisa do que a galera imagina quando ouve "guardrail"

Dá pra verificar o prompt de entrada, extrações, traços de raciocínio e tool calls de outra IA

E dá pra detectar jailbreak, prompt injection, erros de citação, alucinações, violações de política e exposição de dados sensíveis

O pulo do gato é que cada um desses vira uma pergunta tipada nomeada dentro do MESMO mapa questions, contra o MESMO state:

Como as perguntas são avaliadas isoladamente, uma não contamina a outra

E o teu código fica lendo um objeto com ids previsíveis, em vez de tentar adivinhar o humor de um parágrafo

Como instalar a agent skill da TypeSafe no seu agente de código

Existe uma agent skill oficial da TypeSafe, e a instalação muda conforme o agente

No Claude Code, são dois comandos:

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

Depois disso, o uso é via /typesafe:typesafe-ai

Pra outros agentes de código, a instalação é por npx:

npx skills add typesafe-ai/skills --skill typesafe-ai

Ela é project-local por padrão

Se tu quer a skill disponível em todo projeto, usa a flag -g pra instalação global

O erro comum deste passo: rodar o comando npx esperando que ele configure o Claude Code

São caminhos diferentes, cada um com o seu comando

Vale a pena? Custo, limites e o que checar antes de colocar em produção

Começo pelo que é factual e bom: a cobrança do Jev é só por token de entrada, a US$ 0,042 por milhão, com token de saída a US$ 0

Pra guardrail isso é bem conveniente, porque screening é exatamente um caso de muita entrada e saída minúscula (uma opção, um score, uma probabilidade)

Agora a parte que pede pé no chão

Os números de performance divulgados são first-party, ou seja, medidos pela própria TypeSafe

O material de lançamento traz banner de 193,6x mais rápido e 444,6x mais barato nas workflow evals, latência ponta a ponta de 70 a 500 ms e de 20 a 200x mais rápido que LLMs comparáveis

Esse formato de workflow evals é criação da própria TypeSafe: todos os modelos rodam o mesmo grafo de computação e são pontuados contra probabilidades de referência tiradas da média de GPT-6 Astra e Fable 5.1

E olha que interessante: a página de evals declara três limitações

Os workflows foram construídos pelo time interno de model capabilities, a escolha dos modelos de referência enviesa o resultado, e os LLMs concorrentes rodam através do adaptador System One da TypeSafe

Ponto pra honestidade deles, mas continua sendo métrica da casa, então trate como indicativo e não como veredito

Duas coisas que eu faria antes de qualquer deploy sério:

• Ler a página de jaggedness da versão 1.13, que documenta a irregularidade de desempenho daquela versão específica
• Fixar a versão jev-1.13.0 no código em vez de depender do alias jev-latest, que muda sozinho quando sai versão nova

Guardrail calibrado com threshold em cima de uma versão e depois trocado por baixo dos panos é receita de surpresa em produção

A resposta reporta o id versionado que respondeu, então dá pra logar isso e saber exatamente quem julgou o quê

Somando: preço e formato de saída jogam a favor, early access sem GA e provider único jogam contra

Pra piloto e camada de screening em volume, parece um encaixe bem natural

Pra ser a única barreira entre teu app e o mundo, eu ainda deixaria uma segunda linha de defesa em pé 😉

Vídeo: economia de tokens no dia a dia

Pipeline de verificação é conversa de custo, e custo de LLM é um assunto que rende sozinho

Pra começar do zero com essa parte, este vídeo do canal mostra como economizar até 70% usando o Fable 5:

Conclusão

A ideia que fica é essa: em guardrail, a decisão tipada é o CONTRATO

Tu define as opções, o modelo escolhe dentro delas, e o teu código lê probabilidade e confiança em vez de tentar interpretar prosa

O próximo passo é bem direto: entra na waitlist, cria a chave no console, escreve duas ou três perguntas tipadas e roda elas em cima de logs reais que tu já tem guardado

Só depois de olhar essa distribuição é que faz sentido escolher o threshold de confiança e ligar o bloqueio de verdade

Calibrar antes, bloquear depois, sempre nessa ordem…

Até o próximo post! 😀