Como usar o Jev para pontuar risco de fraude em tempo real?

Fala aí, beleza? Antifraude é um dos poucos lugares do software onde a resposta certa chegando tarde vale zero

O cliente tá com o dedo no botão de pagar, o gateway tá esperando, e você tem um orçamento de latência que se mede em milissegundos

Aí você tenta encaixar um LLM nesse buraco e a conta não fecha: ele gera texto, token por token, e cobra por isso

O Jev ataca exatamente esse ponto. Ele é o primeiro modelo da classe System One da TypeSafe AI, anunciado em 15 de setembro de 2026, e a proposta é outra: em vez de gerar texto, ele recebe um state e um mapa de perguntas tipadas e devolve decisões com probabilidades calibradas

A TypeSafe declara de 70ms a 500ms fim a fim, porque o modelo é não autorregressivo e avalia todas as perguntas contra o state num único passe paralelo

Neste post a gente monta o fluxo completo de scoring de transação: state, perguntas, chamada, leitura da resposta e o roteamento que decide aprovar, revisar ou barrar 🙂

O que você precisa antes de começar

Antes de sair codando, se liga no checklist. Metade dos problemas que aparecem depois nasce aqui

Do lado da TypeSafe:

• Conta no console: a lista de espera foi removida, hoje qualquer pessoa cria conta direto em console.typesafe.ai
• Crédito inicial: contas novas recebem US$ 5 em crédito gratuito, o equivalente a cerca de 120 milhões de tokens de entrada. Dá MUITA transação de teste com esse valor
• Chave de API: criada em console.typesafe.ai/settings/keys. A orientação da própria doc é exportar como variável de ambiente, não colar no código
• Python 3.10 ou superior, que é o mínimo exigido pelo SDK oficial

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

Do seu lado, que é a parte que ninguém te lembra:

• Sinais da transação já estruturados: valor, método, idade da conta, país do BIN, device, histórico. Se isso ainda tá espalhado em três serviços, resolve isso primeiro
• Um destino real pra revisão humana: fila, painel, o que for. Sem isso, a faixa de confiança média não tem pra onde ir e você vai acabar aprovando tudo por preguiça
• Transações históricas rotuladas: você vai precisar delas pra calibrar o corte de confiança, e não dá pra inventar isso depois

O preço ajuda a decidir o tamanho do teste: US$ 0,042 por milhão de tokens de entrada, com a saída cobrada a zero

Como usar o Jev para pontuar risco de fraude passo a passo

A ordem aqui importa. Cada passo depois do primeiro assume que o anterior tá certo

1. Instale o SDK e configure as variáveis de ambiente

pip install typesafe-sdk

export TYPESAFE_API_KEY="sua_chave_do_console"
export TYPESAFE_BASE_URL="https://api.typesafe.ai"
export TYPESAFE_DEFAULT_MODEL="jev-latest"

O pacote typesafe_sdk exporta dois clientes: TypeSafeClient e AsyncTypeSafeClient

from typesafe_sdk import TypeSafeClient, AsyncTypeSafeClient

client = TypeSafeClient()  # le TYPESAFE_API_KEY do ambiente

Pra uma camada antifraude que vive dentro de um request de pagamento, o cliente assíncrono é o caminho natural: você não quer segurar a thread esperando resposta de rede

O erro comum deste passo: rodar em Python 3.9 e tomar erro de instalação sem entender o motivo. O mínimo é 3.10, confere com python --version antes de xingar o pip

2. Monte o state da transação com sinais estruturados

O state é o "mundo" que o modelo enxerga. Se o sinal não tá lá, ele não existe pro Jev

state = {
    "transacao": {
        "valor_brl": 4890.00,
        "metodo": "cartao_credito",
        "parcelas": 1,
        "bin_pais": "US",
        "ip_pais": "BR",
        "horario_local": "03:42",
    },
    "conta": {
        "idade_dias": 2,
        "email_verificado": False,
        "compras_anteriores": 0,
        "trocas_de_senha_24h": 1,
    },
    "device": {
        "fingerprint_novo": True,
        "contas_no_mesmo_device_30d": 4,
        "vpn_detectada": True,
    },
    "historico_alertas": [
        {"tipo": "tentativa_cartao_recusado", "quantidade_1h": 6},
    ],
}

O orçamento de contexto tem duas contas separadas: 64k cobre o state mais todas as perguntas somadas, e 32k se aplica ao state mais a pergunta isolada mais longa

Na prática isso significa que dá pra fazer bastante pergunta em cima do mesmo state, desde que nenhuma delas seja um textão sozinha

O erro comum deste passo: despejar o objeto inteiro do banco dentro do state "por garantia". Você queima contexto, aumenta o payload e enche o modelo de campo irrelevante. Manda sinal, não manda dump

3. Escreva o mapa de perguntas com as três primitivas

Aqui é onde o desenho acontece de verdade. O corpo da requisição carrega o state mais um mapa de perguntas montado com três primitivas: Choice, Score e Noul, todas avaliadas num passe paralelo com uma resposta tipada pra cada

Pensando em fraude, o mapeamento sai quase sozinho:

• Noul é a primitiva sim/não, pra proposições fechadas: "o padrão de tentativas nessa conta é compatível com teste de cartão", "a geolocalização do IP é inconsistente com o histórico da conta". Ela devolve a probabilidade da proposição ser verdadeira
• Score é a régua de risco, com os níveis descritos por VOCÊ: mínimo de 2 níveis e máximo de 10 aceitos pela API. É aqui que mora o score de risco da transação
• Choice é a categorização: qual o tipo de fraude mais provável (teste de cartão, conta tomada, fraude de primeira parte, chargeback amigável, nenhum). Uma pergunta Choice aceita até 255 opções, ou seja, taxonomia grande não é problema

Escreva os níveis do Score como descrições, não como números. O modelo é literal, então "conta com menos de 7 dias e nenhuma compra anterior" funciona melhor do que "risco 4"

O erro comum deste passo: criar uma régua de 10 níveis logo de cara achando que granularidade é precisão. Comece com 4 ou 5 níveis que você consegue descrever com clareza e que se traduzem em ações diferentes. Nível que não muda nenhuma decisão é nível inútil

4. Faça a chamada única e leia a resposta tipada

A API da TypeSafe tem um único endpoint: POST https://api.typesafe.ai/v1/systemone, na base https://api.typesafe.ai, e todos os modelos da página de modelos são servidos por ele

É uma chamada só. State mais todas as perguntas, resposta tipada pra cada uma. Não é uma sequência de prompts, não é cadeia de raciocínio

Esse detalhe é justamente o que faz o orçamento de latência fechar num fluxo de pagamento

O erro comum deste passo: quebrar as perguntas em várias requisições "pra organizar o código". Você joga fora o passe paralelo, multiplica a latência e paga contexto repetido, já que o state vai junto toda vez

5. Interprete score, probabilities e confidence

A resposta de um Score traz o score (que pode cair entre dois níveis), a probabilidade de cada nível e um confidence

Respostas de Choice e Score trazem a propriedade probabilities com a distribuição completa, e o confidence deriva do formato dessa distribuição: concentrada gera confiança alta, espalhada gera confiança baixa, num valor entre 0 e 1

E tem uma pegadinha boa de saber: Noul não tem campo de confiança. O próprio valor já é a certeza, então 0.5 significa indeciso

Se você tentar ler confidence de um Noul, não vai achar, e não é bug

O erro comum deste passo: tratar score alto e confiança alta como a mesma coisa. Score alto com confiança baixa quer dizer "parece arriscado mas eu não tenho certeza", que é exatamente o caso que merece um humano olhando

Como transformar score e confiança em aprovar, revisar ou barrar

Score sozinho não é decisão. Decisão é score mais o que você faz quando o modelo não tá seguro

A TypeSafe documenta esse padrão com nome: confidence-gated routing, em três faixas

6. Implemente as três faixas do roteamento por confiança

O padrão oficial é assim: confiança alta age automaticamente, média segue com cautela (confirmação ou flag pra revisão) e baixa não age, mandando pra humano, pedindo esclarecimento ou caindo em outro sistema

Traduzindo pro antifraude: alta vira decisão automática, média vira fila de revisão, baixa vira investigador ou fallback pro seu motor de regras antigo

def rotear(score_risco, confidence, corte=0.8):
    if confidence < corte:
        return "revisao_humana"  # nao age sozinho
    if score_risco >= 4:
        return "barrar"
    if score_risco >= 3:
        return "revisao_humana"
    return "aprovar"

O erro comum deste passo: não ter a faixa do meio. Sistema com só dois caminhos empurra todo caso ambíguo pra um dos extremos, e é sempre o lado errado

7. Use 0.8 como ponto de partida, não como resposta

A documentação mostra um exemplo concreto que manda o caso pra revisão humana quando a confiança fica abaixo de 0.8

Mas ela mesma orienta calibrar o corte plotando confiança contra acurácia nos seus próprios dados, com limiares diferentes por ação conforme o risco

Então 0.8 é onde você começa, não onde você para

8. Use limiares diferentes por ação

Essa é a parte que muita gente pula. Barrar e aprovar não têm o mesmo custo de erro

Barrar errado queima um cliente bom e gera ticket de suporte. Aprovar errado vira chargeback

O limiar pra barrar automaticamente merece ser mais rígido que o de aprovar, porque a ação é irreversível do ponto de vista do cliente naquele instante

LIMIARES = {
    "barrar": 0.92,   # acao destrutiva, exige mais certeza
    "aprovar": 0.80,  # ponto de partida da doc
}

O erro comum deste passo: usar um número único pro sistema inteiro e depois culpar o modelo quando a taxa de falso positivo sobe. O limiar é decisão de produto, não de engenharia

9. Meça antes de ligar o automático

Rode o fluxo em shadow mode: o Jev decide, mas quem manda ainda é o sistema atual, e você só grava as duas decisões lado a lado

Depois de um volume razoável, você tem o gráfico de confiança contra acurácia pra escolher o corte com dado, e não no feeling

Vale a pena combinar isso com um jeito de medir o impacto do Jev, senão você troca de motor sem saber se melhorou

Onde esse padrão encaixa além do score da transação

O mapa de casos de uso da TypeSafe cita fraude e KYC de forma explícita, e o legal é que cada cenário cai numa primitiva diferente

Avaliar narrativas de transação e documentos de KYC: a doc fala em analisar narrativas, documentos de KYC e histórico de alertas em busca de características suspeitas. Isso é terreno de Noul, uma proposição fechada por característica: "a narrativa apresentada é inconsistente com o histórico de uso da conta"

Priorizar a fila de alertas: priorizar alertas por risco e evidência é literalmente uma régua ordenada, ou seja, Score. Em vez de o analista pegar a fila por ordem de chegada, ele pega por nível de risco com a probabilidade de cada nível na mão

Rotear casos ambíguos pra investigadores: rotear caso ambíguo pra investigador é a faixa baixa do confidence routing funcionando como feature, não como falha. O modelo dizendo "não sei" é informação valiosa

Categorizar o tipo do caso: Choice com a sua taxonomia interna, até 255 opções, pra cada alerta já chegar na fila do time certo

E repara que o padrão é o mesmo fora do antifraude. Trocar o state e as perguntas te leva direto pra outros fluxos de triagem, tipo qualificar e priorizar leads no funil, com a mesma mecânica de score mais confiança

Vídeo: contexto sobre modelos trabalhando em conjunto

Pra pegar contexto sobre a ideia de modelos diferentes atuando em conjunto numa mesma resposta, esse vídeo do canal dá o panorama

Problemas comuns ao pontuar fraude com o Jev (e como prevenir)

A TypeSafe publica uma página de jaggedness pro jev-1.13 listando os limites reais do modelo. Ler isso ANTES economiza uns dias de debug

Sintoma: o score sai estranho em casos que dependem de conta

Causa: o modelo tem dificuldade com tarefas que exigem precisão numérica. Pergunta do tipo "a soma das transações das últimas 6 horas passou do limite da conta" não é o forte dele

Prevenção: faça a conta no seu código e coloque o RESULTADO no state, já mastigado ("soma_6h_excede_limite": true). Deixa o Jev julgar o padrão, não calcular o número

Sintoma: a resposta ignora a exceção que você tinha em mente

Causa: ele é bem literal, lê escopo, negação e condições implícitas ao pé da letra

Prevenção: escreva a exceção explícita na descrição do nível ou da proposição. "Condições implícitas" no seu setor não são implícitas pro modelo, escreva tudo

Sintoma: a resposta tá tecnicamente certa mas não é o que você queria saber

Causa: ele responde a pergunta escrita, não a pretendida. Clássico

Prevenção: leia sua pergunta em voz alta fingindo que você não conhece o produto. Se der pra entender de duas formas, ela vai ser lida da forma errada. Tome cuidado principalmente com perguntas que misturam duas coisas num "e" só

Sintoma: você espera uma justificativa em texto pro analista e não vem nada

Causa: o Jev não é treinado pra gerar texto, ponto. Não é configuração faltando

Prevenção: monte a explicação do lado do seu sistema a partir das respostas tipadas: nível do score, distribuição de probabilidades e quais Noul deram alto. Isso vira um resumo estruturado decente pro painel de revisão

Sintoma: uma transação com campo de texto do cliente sai com score suspeito de baixo

Causa: essa é a mais séria. A doc avisa que o state é tratado como dado e não como hostil por padrão. Conteúdo escrito pra dirigir o modelo de forma adversarial (instrução injetada, enquadramento enganoso, texto que argumenta pela própria classificação) pode mover a resposta

Prevenção: campo livre preenchido pelo usuário é superfície de ataque. Sanitize, delimite claramente o que é dado do cliente dentro do state, e trate qualquer campo controlado por terceiro como não confiável. Em antifraude isso não é detalhe, é o adversário fazendo o trabalho dele

Vale usar o Jev na sua camada antifraude? Limites honestos

O ganho real tá em dois lugares bem concretos

Latência declarada de 70ms a 500ms fim a fim, que é um número que cabe dentro de um fluxo de pagamento sem virar problema de UX

E o custo: US$ 0,042 por milhão de tokens de entrada, com a saída cobrada a zero. Num volume de transação alto, saída a zero muda a conta de lugar

A própria TypeSafe publicou uma comparação na mesma tarefa:

E aqui vai o aviso: esses números são auto reportados pela própria empresa, no benchmark dela, na tarefa escolhida por ela. Não é motivo pra descartar, é motivo pra você reproduzir com os seus dados antes de virar slide de decisão

Do outro lado da balança, três coisas que você precisa aceitar:

Calibração é propriedade agregada. Modelos System One são treinados com probabilidades otimizadas contra desfechos reais, mas a calibração é medida em grupos de previsões e não garante que uma resposta individual esteja certa. Ou seja: confiança 0.95 não é promessa naquele caso específico, é comportamento estatístico do conjunto

Rate limits são dinâmicos. A TypeSafe informa que eles são ajustados dinamicamente e podem mudar sem aviso conforme a infraestrutura escala, com limites maiores em planos custom e enterprise. Pra camada crítica de pagamento, isso pede fallback desenhado desde o dia um

Regra numérica e explicação pro cliente continuam do seu lado. Precisão numérica é limite reconhecido e geração de texto não existe. Então o Jev entra como camada de julgamento em cima de um pipeline que já faz conta e já sabe comunicar

Resumindo o veredito: como substituto do seu motor de regras inteiro, não. Como camada de julgamento rápida e barata em cima dos sinais que você já tem, com humano na faixa de baixa confiança, faz bastante sentido 🙂

Conclusão

O caminho é curto e dá pra fazer essa semana

Cria a conta em console.typesafe.ai, que não tem mais waitlist, e usa parte dos US$ 5 de crédito inicial pra replicar o fluxo: state com os sinais da transação, Noul pras proposições, Score pra régua de risco e Choice pra categoria

Roda em cima de transações históricas que você JÁ sabe se eram fraude ou não

Depois plota confiança contra acurácia, escolhe o corte por ação (mais rígido pra barrar) e só então liga qualquer decisão automática em produção

Modelo calibrado sem limiar calibrado é meio caminho, e em antifraude meio caminho custa caro

Bora testar? até o próximo post!