O blog de segurança da FireAI

Por FireAI Security & Research Team · Publicado

O Jev e a Ascensão dos Modelos de Decisão: O Que a IA "Sistema Um" Significa para as Ferramentas de Segurança

O Jev e a Ascensão dos Modelos de Decisão: O Que a IA "Sistema Um" Significa para as Ferramentas de Segurança

A 25 de setembro de 2026, a TypeSafe AI anunciou o Jev, o primeiro modelo naquilo a que chama a categoria "Sistema Um": não um chatbot, nem simplesmente um modelo de linguagem maior, mas aquilo que a empresa descreve como um modelo de decisão — algo construído para responder a uma pergunta delimitada com uma resposta tipada e calibrada, em vez de um parágrafo de texto corrido. O anúncio está repleto de números específicos, por isso este artigo percorre-o exatamente como foi afirmado, assinala claramente o que pudemos e não pudemos verificar, e analisa por que razão a ideia subjacente, decidir em vez de gerar, vale a pena levar a sério, em particular para o software de segurança.

O que a TypeSafe realmente anunciou

A TypeSafe AI foi fundada por Diogo Almeida, que escreve no anúncio: "Na OpenAI, ajudei a construir os métodos que tornaram os modelos de linguagem úteis a seguir instruções e a conversar com as pessoas." O Jev, chamado o "primeiro modelo público" da empresa, é apresentado como uma tarefa inteiramente diferente: produzir aquilo a que a TypeSafe chama valores estruturados de tipo seguro (type-safe), com probabilidades calibradas e pontuações de confiança, gerados através daquilo a que chama um amostrador paralelo, em vez da habitual descodificação token a token, e treinado com um método a que a empresa chama Aprendizagem por Reforço para Decisões Calibradas, ou RLCD.

  • A TypeSafe reporta um tempo de resposta de ponta a ponta de "70ms-500ms", contra o que mediu como "3 a 329 segundos" para os modelos de linguagem de fronteira com que comparou o Jev.
  • A TypeSafe cobra os tokens de entrada a "0,042 USD / MTok", com os tokens de saída indicados como gratuitos.
  • Nas suas próprias avaliações de fluxos de trabalho, a TypeSafe reporta o Jev a correr "193,6 vezes mais depressa, 444,6 vezes mais barato" do que as políticas com que foi medido.
  • A TypeSafe descreve um erro de tipo na saída do Jev como, nas suas próprias palavras, "matematicamente impossível".
  • O Jev está em acesso antecipado; a TypeSafe diz que está a trazer programadores "da lista de espera o mais depressa que conseguirmos."

Geração versus decisão

Uma grande parte daquilo a que se chama "IA em produção" não é, na verdade, uma tarefa de escrita. Permitir ou bloquear uma ligação. Escalar ou fechar um chamado. Sinalizar ou libertar uma transação. Encaminhar uma mensagem para uma fila ou para outra. A saída pretendida não é texto corrido, é um rótulo retirado de uma lista curta e fixa, por vezes com uma pontuação associada. Fazer passar esse tipo de pergunta por um modelo construído para produzir parágrafos fluentes é um desencontro: volta um bloco de JSON que tem de ser analisado e cuja validade se espera, e qualquer confiança declarada tende a não significar grande coisa em particular, porque nada obrigou o modelo a acompanhar a sua verdadeira taxa de erro.

Vale a pena separar aqui duas afirmações, porque não são a mesma coisa: tipado, e calibrado. Uma saída tipada limita a forma da resposta — uma pergunta de "escolha" devolve uma das opções da lista, uma pergunta de "pontuação" devolve um número dentro de um intervalo declarado, nunca uma frase avulsa ou um campo inventado. A calibração é uma ideia muito mais antiga e inteiramente separada. É uma propriedade estatística, não estilística: significa que, quando o sistema declara uma probabilidade de 0,62, tem razão nessa frequência ao longo de muitas previsões semelhantes, de modo a que um programa a jusante possa efetivamente definir um limiar sobre esse número, em vez de o tratar como decoração.

A própria nomenclatura da TypeSafe pede emprestado o seu vocabulário à psicologia, e não à estatística. Daniel Kahneman, que recebeu o Prémio do Banco da Suécia em Ciências Económicas em memória de Alfred Nobel em 2002 "por ter integrado conhecimentos da investigação psicológica na ciência económica, especialmente no que respeita ao juízo humano e à tomada de decisão em condições de incerteza", popularizou os termos em Pensar, Depressa e Devagar: o "Sistema 1" é "rápido, automático, frequente, emocional, estereotipado, inconsciente", enquanto o "Sistema 2" é "lento, esforçado, pouco frequente, lógico, calculista, consciente". A metáfora é evocativa, mas descreve a cognição humana, não uma garantia sobre uma peça de software. Um modelo pode ser rápido da forma como o Sistema 1 é rápido, sem que a sua confiança declarada signifique seja o que for — a calibração tem de ser conquistada e medida, não implícita num nome.

O que "não pode alucinar" pode e não pode significar

A afirmação da TypeSafe de que um erro de tipo é "matematicamente impossível" está a descrever a descodificação restringida (constrained decoding), uma técnica que já existe noutros sítios. O próprio guia de Saídas Estruturadas da OpenAI faz uma garantia semelhante: a funcionalidade, diz, "garante que o modelo vai sempre gerar respostas que respeitam o esquema JSON fornecido, para que não tenha de se preocupar com o modelo a omitir uma chave obrigatória, ou a alucinar um valor de enumeração inválido." Essa garantia é real e útil. É também mais restrita do que parece: limita a forma da resposta, não se a resposta está certa. Uma pergunta de "escolha" com três opções devolverá sempre uma das três — incluindo, se o modelo tiver interpretado mal a entrada, uma resposta confiante, validamente tipada, e errada.

A calibração é a parte que tem de ser verificada, não afirmada. A ferramenta padrão é um diagrama de fiabilidade: agrupar as previsões pela sua confiança declarada, e, para cada grupo, traçar a frequência com que essas previsões se revelaram efetivamente corretas; o desvio entre a diagonal e a linha observada é geralmente resumido como erro de calibração esperado. Esta não é uma questão nova para a aprendizagem automática — o artigo de 2017 de Guo et al., "On Calibration of Modern Neural Networks", concluiu que "as redes neuronais modernas... estão mal calibradas" por defeito, e que uma correção simples, de um único parâmetro, chamada escalonamento de temperatura, era "surpreendentemente eficaz" a corrigi-lo. A lição generaliza-se para além desse artigo: a calibração não é uma propriedade que um modelo possa anunciar sobre si próprio. É algo que se verifica, nos seus próprios dados rotulados, porque tende a degradar-se exatamente onde mais se precisa dela — em entradas que não se parecem em nada com aquilo em que o modelo foi ajustado.

Um conjunto mínimo de avaliação (modelo)

Antes de encaminhar uma decisão real através de qualquer modelo de decisão, seja o Jev ou outro, três perguntas importam mais do que qualquer número de um fornecedor: a resposta tipada é sempre válida contra o seu esquema, uma confiança declarada acompanha a sua verdadeira taxa de acerto numa amostra rotulada dos seus próprios dados, e essa calibração sobrevive em entradas diferentes de tudo o que o modelo já viu. O esboço abaixo é um modelo construído em torno da forma de pedido mostrada na própria documentação de início rápido da TypeSafe. Não faz qualquer afirmação sobre o que executá-lo contra o Jev mostraria — não o executámos, e isto é pseudocódigo ilustrativo, não um relatório.

calibration_check.py — apenas um modelo, não executado contra o Jev
# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own
# quickstart docs (POST /v1/systemone with state, model, and typed questions).
# Not run against Jev or any live API; no results are claimed here.
import requests

def ask(state: str, question_id: str, question: dict) -> dict:
    resp = requests.post(
        "https://api.typesafe.ai/v1/systemone",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"state": state, "model": "jev-latest", "questions": {question_id: question}},
    )
    return resp.json()["answers"][question_id]

# 1. Shape check: does every response parse against the declared type, on your
#    own edge cases, not just a vendor demo set?
# 2. Calibration check: bucket the stated confidence and compare it to the
#    true label rate, on data the model has never seen.
buckets = {i: {"n": 0, "correct": 0} for i in range(10)}
for state, true_label in labeled_sample:          # your own traffic, labeled by hand
    answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"})
    bucket = min(int(answer["noul"] * 10), 9)
    buckets[bucket]["n"] += 1
    buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label)

for b, s in buckets.items():
    if s["n"]:
        stated = (b + 0.5) / 10
        observed = s["correct"] / s["n"]
        print(f"stated~{stated:.2f}  observed={observed:.2f}  n={s['n']}")  # the gap here is your calibration error
  • Se a resposta tipada é sempre válida, em entradas que o seu próprio sistema produz, e não apenas num conjunto de demonstração de um fornecedor.
  • Se uma confiança declarada de 0,9 tem razão nove vezes em dez no seu próprio tráfego rotulado, e não num conjunto de avaliação de outra pessoa.
  • Se essa calibração se mantém em entradas diferentes de tudo o que já viu antes: uma nova aplicação, um novo protocolo, um remetente que leu o mesmo anúncio que acabou de ler.
  • O que quem chama o modelo faz perante um tempo-limite ou uma indisponibilidade, já que um sistema de decisão precisa de um valor seguro por defeito quando o modelo de decisão está inacessível.

Por que isto importa para as ferramentas de segurança

Uma firewall, um filtro de spam, uma verificação de fraude, uma fila de triagem: cada um destes é um sistema de decisão, a responder repetidamente à mesma forma de pergunta — dada esta entrada, permitir ou bloquear, com que confiança, e onde fica o limiar. A própria página de avaliações da TypeSafe retira os seus exemplos exatamente deste território: decidir se se fecha um alerta de segurança, se se escala para uma pessoa, ou se se contém imediatamente, é uma decisão de triagem, não uma tarefa de escrita, e é o tipo de chamada que uma ferramenta de segurança faz constantemente, a um volume que nenhum analista conseguiria rever à mão.

Comparação ilustrativa, não é a transcrição de nenhum sistema real.
Resposta de um LLM generativoDecisão tipada (ao estilo Jev)
SaídaUm parágrafo a explicar que a ligação a um endereço pouco comum, numa porta invulgar, "pode valer a pena rever"{ allow: false, confidence: 0.81 }
AnáliseRegex, ou uma segunda chamada ao modelo, para extrair uma ação de texto corridoGarantidamente corresponde ao esquema declarado
Definição de limiarSem confiança numérica para comparar com uma políticaUm valor de confiança sobre o qual quem chama pode definir um limiar diretamente
Modo de falhaFluente, com um som plausível, e por vezes simplesmente erradoErrado com um número associado, o que uma verificação de calibração pode pelo menos apanhar em média

O compromisso de privacidade, com honestidade

O Jev, tal como a TypeSafe o descreve, é uma API alojada: um pedido transporta o "estado", ou seja, quaisquer dados sobre os quais a pergunta incide, até aos servidores da TypeSafe através da internet. Para os exemplos de incidentes de segurança e triagem que a própria TypeSafe destaca, esse estado é exatamente o tipo de informação que muitas pessoas prefeririam não entregar a terceiros por defeito — qual a aplicação a falar com que endereço, com que frequência, a partir de que dispositivo. Enviá-lo para qualquer modelo na nuvem, por mais rápido ou barato que seja, significa que esses dados saem da máquina de onde vieram.

O FireAI, a própria firewall da HisnLabs para macOS, fez a escolha oposta exatamente para esta categoria de decisão de que trata este artigo. O FireAI corre em macOS 14 ou posterior, em silício da Apple, por 49 € pagos uma única vez, e não é explicitamente um antivírus nem uma VPN. Quando uma aplicação que nunca viu tenta chegar à rede, o FireAI pode correr um pequeno modelo no próprio dispositivo — uma transferência opcional de 1,5 GB — para rever essa ligação e mostrar-lhe uma razão em linguagem simples; o tráfego a ser revisto nunca é enviado para lado nenhum. Cada uma dessas decisões assistidas por IA torna-se numa regra visível, associada à assinatura de código da aplicação, que pode ver e desfazer, ao lado de feeds de ameaças que são aplicados localmente, em vez de consultados junto de um servidor remoto.

Não estamos a afirmar que o modelo do FireAI, no próprio dispositivo, iguala o Jev, ou qualquer outro modelo de sistema um, em correção pura, velocidade ou preço — não fizemos essa comparação e não temos avaliações próprias para publicar aqui. O que este anúncio sustenta é uma direção de conceção: que uma decisão de segurança é bem servida por um modelo pequeno, rápido e delimitado, a correr perto dos dados, em vez de ser encaminhada através de um chatbot de uso geral algures noutro sítio. A TypeSafe está a fazer essa defesa a partir do lado da API; o FireAI já constrói sobre ela a partir do lado do dispositivo, e por uma razão diferente — porque, especificamente para uma firewall, os dados em questão não deveriam ter de sair da máquina para sequer serem avaliados.

Questões em aberto

  • Avaliações independentes: nenhuma parte externa publicou ainda uma reprodução dos múltiplos de velocidade ou de custo do anúncio da TypeSafe, em dados que a TypeSafe não tenha escolhido.
  • A calibração sob mudança de distribuição — exatamente o cenário de que trata o artigo de Guo et al., e o que mais importa perante um adversário que se adapta assim que um método de defesa se torna público.
  • Se o preço se mantém a um volume real de produção, e se a latência declarada se mantém sob carga sustentada, e não apenas num único pedido de demonstração.
  • Como se comporta o modelo perante entradas adversariais ou genuinamente ambíguas, onde uma resposta tipada e confiante pode ser menos honesta do que uma resposta que diga "não está claro".
  • Quando o acesso antecipado se abre para além da lista de espera, a quem, e em que termos para os dados enviados como "estado".

Para já, o Jev é um conjunto de afirmações de uma equipa com credenciais reais e ainda sem verificação externa. A categoria que tenta nomear, modelos de decisão em vez de modelos de geração, aponta para uma lacuna real na forma como o software de segurança tem, até agora, sido feito para usar IA. Quer o próprio Jev se confirme ou não sob teste independente, é um lembrete útil de que a pergunta interessante para uma firewall, um filtro de fraude ou uma fila de triagem nunca foi "consegue escrever uma frase convincente" mas sim "consegue tomar uma decisão que consiga defender, suficientemente depressa para importar." É essa a pergunta que fazemos sobre o modelo no próprio dispositivo dentro do FireAI sempre que o alteramos — e é por isso que, para nós, a resposta permanece no dispositivo, em vez de se tornar num pedido à API de outra pessoa.

O papel do FireAI e da HisnLabs

We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it.

O FireAI é o produto da HisnLabs: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade Autopilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.

Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.

Fontes