Jev ou outra IA de decisão: que perguntas fazer antes de escolher?

Escolher uma IA de decisão pela demo é fácil

Difícil é defender a escolha quando alguém do time pergunta: "e se ela cair?" ou "e se mudar de comportamento do nada?" 😛

Fala aí, beleza? O Jev, da TypeSafe AI, chegou em early access em 15 de setembro de 2026 e já está aparecendo em muita conversa de arquitetura

Então montei um checklist de perguntas pra tu usar lendo a documentação ou direto com o fornecedor, mostrando o que o Jev já responde publicamente e o que ainda precisa ser cobrado por escrito

Serve pro Jev e serve pra qualquer alternativa, beleza?

O que é o Jev e por que ele pede um checklist diferente?

O Jev é um modelo proprietário da TypeSafe AI, empresa de San Francisco fundada em 2024

É o primeiro modelo público da categoria que a empresa chama de System One

E o que muda isso na prática?

O Jev não gera texto livre: ele recebe um estado (texto ou JSON) e perguntas tipadas (Choice, Score, Noul) e devolve uma opção, uma pontuação ou uma probabilidade, com informação de probabilidade e confiança

Pensa assim: um LLM de chat é tipo um redator, o Jev é mais parecido com um juiz que só responde "A, B ou C" e diz o quão seguro está

Ele é servido pelo endpoint POST /v1/systemone e também tem página no OpenRouter como typesafe/jev-1.13

Por isso o checklist muda de foco

Ninguém vai avaliar se o Jev "escreve bonito", o risco está em outro lugar: a ESTABILIDADE das decisões, quanto ela custa, quanto demora e o que acontece com o que tu manda pra ele

Checklist de avaliação: o que perguntar ao fornecedor, item por item:

Cada item tem a pergunta, o que o Jev documenta hoje e o erro comum daquele ponto

Bora?

1. Latência: quanto tempo a decisão leva de verdade?

Pergunta: qual a latência ponta a ponta típica, e ela foi medida por quem?

O que o Jev documenta: a TypeSafe informa de 70 ms a 500 ms ponta a ponta

Só que esse número é do próprio fornecedor, não é medição independente

O erro comum deste passo: colocar "70 ms a 500 ms" no slide como se fosse benchmark neutro

Na apresentação interna, escreve "segundo a TypeSafe" e mede no teu ambiente, com teu tamanho de estado e tua rede

2. Limites de uso: quanto tráfego aguenta e isso é garantido?

Pergunta: quais os rate limits atuais e existe compromisso contratual sobre eles?

O que o Jev documenta: na documentação de modelos, o jev-1.13.0 tem 100 mil tokens por segundo e 80 requisições por segundo

Porém a própria doc avisa que esses limites estão sendo ajustados dinamicamente e podem mudar sem aviso

O erro comum deste passo: dimensionar a produção pelo número de hoje sem nada por escrito

Se o teu pico depende de 80 req/s, isso tem que estar no contrato, não só na página da doc

3. Custo: por qual token eu pago?

Pergunta: como a cobrança é calculada e o que entra na conta?

O que o Jev documenta: o Jev 1.13 custa US$ 0,042 por milhão de tokens de entrada (US$ 42 por bilhão), e os tokens de saída são gratuitos

O erro comum deste passo: estimar custo pela saída, como se faz com LLM de texto

Aqui a conta é toda no estado que tu manda

Estado inchado = conta inchada (e, como vamos ver no item 7, precisão pior também)

4. Dados enviados: o que acontece com o que eu mando?

Pergunta: vocês treinam com meus dados? Por quanto tempo retêm? Existe retenção zero?

O que o Jev documenta:

• A TypeSafe declara que não treina nem faz fine-tuning de modelos com os prompts ou outros inputs do cliente
• Retenção zero de dados (ZDR) é oferecida para clientes enterprise, mediante contato com [email protected]
• O DPA diz que dados pessoais ficam retidos pelo tempo necessário ao propósito do processamento e conforme a lei aplicável, sem prazo fixo publicado

O erro comum deste passo: assumir retenção zero por padrão

Não é! "Não treina" e "não guarda" são coisas diferentes, tome cuidado com isso na hora de passar pro jurídico

5. Estabilidade entre versões: a resposta muda sem eu mudar o código?

Pergunta: como funcionam os nomes de modelo e como eu sei qual versão respondeu?

O que o Jev documenta: a versão atual é jev-1.13.0

Existem dois aliases:

• jev-latest: aponta pra última versão estável oficial (é o padrão nos SDKs)
• jev-preview: aponta pra release mais recente, oficial ou não

Hoje os dois apontam pra jev-1.13.0 e não há build preview disponível

Que alias é esse?

É só um nome que resolve pra um ID versionado, tipo uma tag latest de imagem Docker

Quando o alias passa a apontar pra outra release, as respostas podem mudar sem nenhuma mudança no teu código

A boa notícia: o campo model da resposta devolve o ID versionado que respondeu (pediu jev-latest, volta jev-1.13.0), então dá pra registrar em log qual versão gerou cada decisão

Um registro de log simples já resolve, algo nessa linha:

{
  "model_pedido": "jev-1.13.0",
  "model_resposta": "jev-1.13.0",
  "decisao": "aprovar",
  "registrado_em": "2026-10-08T14:32:00Z"
}

O erro comum deste passo: calibrar limiares (tipo "acima de tal confiança, aprova") usando jev-latest e não guardar o model no log

A própria doc recomenda fixar o ID versionado pra quem calibrou limiares

Já vi muita gente se ferrar com latest em dependência, aqui é a mesma história 😅

6. Queda do serviço: e quando o Jev não responde?

Pergunta: qual o SLA de disponibilidade? Tem página de status oficial? Qual o comportamento recomendado em caso de falha?

O que o Jev documenta: nos materiais oficiais levantados, não aparece SLA formal, página de status confirmada nem política de fallback publicada

Então essa é pergunta pra mandar direto pro fornecedor, por escrito

E independente da resposta, tu precisa de plano de contingência próprio: o que teu sistema faz quando a decisão não chega? Isso eu destrincho no post sobre timeout e fallback no Jev

O erro comum deste passo: contar com o acesso via OpenRouter como failover automático

O fato do modelo estar listado lá não diz nada sobre o que acontece quando a TypeSafe cai, então não use isso como argumento sem confirmação

7. Limitações conhecidas: onde o modelo erra?

Pergunta: vocês documentam os pontos fracos do modelo? Me manda o equivalente pra versão que eu vou usar

O que o Jev documenta: aqui a TypeSafe é bem transparente, a página de jaggedness do Jev 1.13 lista:

• Leitura literal das perguntas
• Contagem pouco confiável
• Comparação de datas e horários pouco confiável
• Dificuldade com indireção e dupla negação
• Queda de precisão com estado grande e com conteúdo irrelevante
• Não trata o estado como hostil por padrão (conteúdo adversarial pode mudar respostas)
• Confusão com instruções contraditórias
• Influência da ordem das opções em Choice
• Não serve pra gerar texto

O erro comum deste passo: comparar a lista de limitações do Jev com o marketing da alternativa

Se a outra IA não publica nada parecido, não é que ela não tem limitação, é que ninguém te contou ainda…

Jev x outra IA de decisão: tabela para preencher na avaliação:

Essa é a tabela pra copiar e levar na reunião

A última coluna fica em branco pra tu preencher com a resposta da alternativa

Pra due diligence, a TypeSafe publica política de privacidade, termos de uso, master customer agreement, política de uso aceitável e DPA, além de um Trust Center

Pede o pacote equivalente pra alternativa, se ela não tiver, isso já é informação 😉

Quando o Jev faz sentido e quando outra IA atende melhor?

A escolha depende do TIPO de decisão, não de "qual IA é melhor"

Se liga nos cenários que saem direto das capacidades e limitações documentadas:

Encaixa bem:

• Classificar uma entrada em categorias fechadas (Choice)
• Dar uma nota pra algo dentro de um critério claro (Score)
• Decisões tipadas com estado enxuto, onde tu manda só o que importa

Exige cuidado:

• Estado grande ou cheio de ruído: a precisão cai, então filtra antes de mandar
• Conteúdo vindo de usuário não confiável: o Jev não trata o estado como hostil por padrão, então texto adversarial pode virar a resposta
• Regras que dependem de comparar datas, horários ou contar itens: calcula isso no teu código e manda o resultado pronto
• Perguntas com dupla negação ou opções em Choice onde a ordem pode influenciar: reescreve a pergunta de forma direta e testa ordens diferentes

Não serve:

• Qualquer tarefa que precise de texto gerado (resumo, resposta pro cliente, explicação)

Nesse caso o critério de escolha é outro e tu vai estar comparando LLMs generalistas, tipo escolher entre as variantes do DeepSeek V4

Esse é o argumento pra levar pro time: o Jev não compete com chat, compete com regra de negócio escrita na mão e com classificador próprio

Veredito: o Jev passa no checklist?

Sem experiência de primeira mão aqui, o veredito é sobre o que está documentado, beleza?

Onde ele responde bem:

• Dados: declara que não treina com inputs do cliente e publica DPA e Trust Center
• Versionamento: ID fixo jev-1.13.0 e campo model rastreável em cada resposta
• Transparência: a página de limitações é mais honesta que muito material de fornecedor por aí

O que ainda está em aberto:

• Latência só autodeclarada
• Limites de uso que podem mudar sem aviso
• Retenção sem prazo fixo fora do ZDR enterprise
• Nenhum SLA nem política de queda nos materiais públicos
• Status de early access

Minha leitura: viável pra piloto com versão fixada

Produção só depois de fechar essas lacunas por escrito com a TypeSafe

E vale o mesmo rigor pra alternativa, senão a comparação fica desigual

Próximo passo: como usar este checklist na prática:

Resumindo o caminho:

1. Copia a tabela e preenche a coluna da alternativa
2. Manda as perguntas em aberto pro fornecedor, no caso do Jev: SLA, prazo de retenção e estabilidade dos limites de uso
3. Roda um piloto fixando jev-1.13.0 e registrando o campo model em cada decisão
4. Mede a latência no teu ambiente, com teu estado real
5. Repete o mesmo processo com a alternativa antes de levar a decisão pro time

Com isso tu chega na reunião com evidência em vez de print de demo, e aí defender a escolha fica MUITO mais fácil 🙂

Até o próximo post!