Un software riceve una richiesta di assistenza. Deve capire se riguarda una fattura, un guasto o una proposta commerciale, valutarne l’urgenza e scegliere il percorso successivo. Per svolgere questo lavoro non gli serve necessariamente una risposta scritta: gli servono una decisione utilizzabile e un modo per gestire l’incertezza.
Jev, il primo modello pubblico di TypeSafe AI, nasce per occupare questo spazio. Il suo lancio del 15 settembre 2026 accompagna l’uscita della società dallo stealth e un round seed da 40 milioni di dollari guidato da DCVC. La notizia è confermata dall’investitore e dal comunicato aziendale; le promesse di velocità e affidabilità, invece, richiedono una lettura più attenta. Annuncio DCVC.
Analisi aggiornata al 18 settembre 2026. Abbiamo confrontato documentazione tecnica, comunicati e copertura editoriale: i risultati sperimentali riportati sono attribuiti ai rispettivi autori, non sono benchmark eseguiti da WebAlchemy.
TypeSafe AI: 40 milioni di dollari e un team con esperienza nei grandi laboratori
TypeSafe AI è stata fondata nel 2024 e ha sede a San Francisco. I tre cofondatori sono Diogo Almeida, Erik Gafni e Sasha Sheng. Il capitale annunciato finanzia una tesi precisa: rendere l’intelligenza artificiale un componente che il software possa richiamare e combinare, anche senza un’interfaccia conversazionale. Il comunicato identifica DCVC come capofila del seed; non è corretto trasformare le precedenti esperienze professionali del team in un elenco di investitori. Comunicato TypeSafe distribuito da Business Wire.
Almeida, CEO, ha lavorato in OpenAI e Google Brain. Un riferimento verificabile al suo contributo scientifico è la presenza fra gli autori del paper Training language models to follow instructions with human feedback, pubblicato a NeurIPS 2022: il lavoro su InstructGPT che ha contribuito allo sviluppo dei moderni assistenti conversazionali. È una credenziale concreta, più precisa dell’etichetta semplificata di “inventore di ChatGPT”. Paper originale e lista degli autori.
Il CTO Erik Gafni porta esperienza da fondatore e nello sviluppo di sistemi AI in produzione, con trascorsi in Invitae e Freenome. Sasha Sheng, COO, proviene dall’ingegneria di ricerca in Meta/FAIR. La pagina ufficiale presenta un gruppo con esperienze anche in Stripe, Airbnb, Plaid e Docker. Questo aiuta a capire l’attenzione all’integrazione nei prodotti, ma non costituisce una prova delle prestazioni del modello. Team ufficiale TypeSafe.
Come funziona Jev: uno stato, domande precise e risposte tipizzate
TypeSafe chiama questa famiglia System One Models, richiamando la distinzione fra pensiero rapido e ragionamento deliberativo resa popolare da Daniel Kahneman. È la denominazione proposta dall’azienda, non una certificazione di superiorità cognitiva. Jev comprende input testuali e produce giudizi circoscritti: non scrive articoli, codice o spiegazioni del proprio ragionamento. Documentazione System One.
La richiesta contiene uno state: può essere un testo, un oggetto JSON o un array. A questo si affiancano le domande. Immagini, audio e video non sono attualmente input nativi: un’applicazione deve prima convertirli in informazioni testuali utilizzabili. È quindi importante distinguere “capisce una descrizione dell’ambiente” da “vede direttamente l’ambiente”. Formati dello state.
Le tre primitive rendono il funzionamento abbastanza intuitivo:
| Primitiva | Cosa chiediamo | Cosa restituisce |
|---|---|---|
| Choice | Quale reparto deve gestire una richiesta? | Un’opzione fra quelle definite, probabilità delle alternative e confidenza. |
| Score | Quanto è urgente, secondo una scala descritta? | Un valore ponderato sui livelli della scala, distribuzione e confidenza. |
| Noul | Il messaggio richiede un rimborso? | La probabilità, fra 0 e 1, che la risposta sia sì. |
Fonti delle primitive: Choice, Score e Noul. Un punteggio su una scala qualitativa non è una misura esatta: “urgenza 1,4” su tre livelli descrive un giudizio, non un tempo di risposta contrattuale.
RLCD: addestrare il modello per decisioni calibrate
TypeSafe denomina il proprio approccio Reinforcement Learning for Calibrated Decisions, RLCD. L’obiettivo dichiarato è produrre decisioni accompagnate da probabilità utili all’automazione. Il confronto proposto dall’azienda è con RLHF, che utilizza preferenze umane, e RLVR, basato su ricompense verificabili. Questa spiegazione descrive gli obiettivi del produttore: non basta, da sola, a dimostrare che un metodo superi gli altri in ogni applicazione. AI primer ufficiale.
La parte interessante per chi sviluppa è la separazione delle responsabilità. Il modello interpreta l’ambiguità; il programma conserva regole, permessi, calcoli e azioni. In un gestionale, per esempio, si può chiedere di riconoscere il motivo di una contestazione, lasciando al codice la verifica del numero d’ordine, dell’importo e dei diritti dell’operatore.
“Zero allucinazioni” non significa zero decisioni sbagliate
Se le opzioni ammesse sono fatturazione, assistenza e commerciale, un’interfaccia vincolata può impedire che il modello restituisca una quarta categoria inventata. Può comunque scegliere commerciale quando la richiesta riguarda una fattura. Validità del formato e correttezza del giudizio sono proprietà diverse.
Anche il confronto con i modelli generativi va aggiornato: gli LLM moderni possono già utilizzare output vincolati a uno schema. La documentazione di OpenAI distingue esplicitamente i Structured Outputs dal semplice JSON valido. La proposta di Jev va quindi valutata sul complesso di addestramento, distribuzioni restituite, latenza e costo, non sull’idea che gli altri modelli sappiano soltanto scrivere paragrafi liberi. Structured Outputs: documentazione OpenAI.
Probabilità e confidence: due numeri da non confondere
Per Choice e Score, confidence è una statistica ricavata dalla forma della distribuzione delle probabilità. Non è semplicemente la probabilità dell’opzione vincente. Noul restituisce invece la probabilità del sì e non ha un campo separato di confidence. Trattare indistintamente tutti questi valori come “percentuale di risposte corrette” porterebbe a soglie operative sbagliate. Come TypeSafe definisce la confidenza.
La calibrazione si valuta su gruppi di previsioni: in un sistema ben calibrato, gli eventi stimati all’80% dovrebbero verificarsi circa otto volte su dieci. Non garantisce il singolo caso. Per un’azienda, il controllo utile è misurare la relazione fra probabilità e risultati su dati propri, comprese richieste ambigue, lingue diverse e casi nuovi. La soglia per suggerire una categoria può essere diversa da quella necessaria per autorizzare un’operazione economica.
Quanto è veloce e quanto costa: numeri verificati, risultati attribuiti
Sul sito TypeSafe compaiono i moltiplicatori 193,6 volte più veloce e 444,6 volte meno costoso. Sono risultati dichiarati per specifiche valutazioni del produttore, non una promessa valida per qualsiasi sistema. Il prezzo pubblicato è 0,042 dollari per milione di token di input, equivalenti a 42 dollari per miliardo. Sito e listino TypeSafe.
Il post di lancio colloca le risposte end-to-end fra 70 e 500 millisecondi. Precisa però che le misurazioni sono generalmente effettuate dalla costa occidentale degli Stati Uniti, dove è situato il servizio, e che i guadagni principali possono rappresentare la fascia alta dei benefici reali. Una chiamata dall’Italia, con input più lunghi o carico diverso, deve essere misurata nel proprio ambiente. Annuncio tecnico e cautele metodologiche.
Le valutazioni pubblicate riguardano quattro workflow: incidenti di sicurezza, osservabilità delle tracce degli agenti, elaborazione di fatture e servizio clienti. La qualità è confrontata con probabilità di riferimento prodotte da altri modelli: l’annuncio identifica la media di GPT-6 Astra e Fable 5.1. I workflow sono stati costruiti dal team TypeSafe e il produttore riconosce possibili distorsioni. Accordo con modelli di riferimento e accuratezza su una verità verificata esternamente non sono la stessa cosa. Workflow evals e metodo dichiarato.
Un primo test esterno mostra il compromesso
Every ha pubblicato prove dirette interessanti, pur limitate. Mike Taylor riporta 777 giudizi su 37 documenti, con 21 domande per documento, in meno di 0,7 secondi. Un secondo confronto di Dan Shipper, su 12 passaggi sintetici, rileva una mediana di 0,35 secondi per Jev contro 8,83 secondi per Fable 5.1 a impegno elevato. Jev individua 6 dei 7 difetti inseriti, Fable tutti e 7. Sono misure pubblicate da Every, non una replica nostra né una valutazione rappresentativa di ogni settore. Il risultato rende concreto il potenziale, ma mostra anche perché risparmiare tempo non autorizzi a ignorare gli errori. Test originale di Every.
Il costo di un workflow, con un esempio calcolabile
Supponiamo 100.000 richieste, ciascuna con 1.500 token di input fatturabili complessivi: sono 150 milioni di token. Alla tariffa indicata, la componente Jev vale 6,30 dollari. Un milione di richieste dello stesso tipo vale 63 dollari. È un calcolo illustrativo sul listino, non un preventivo di progetto.
Restano da considerare recupero dei dati, gateway, infrastruttura, ritentativi, monitoraggio ed eventuale altro modello che scrive la risposta al cliente. Soprattutto, conta il costo dei casi sbagliati o rinviati agli operatori. La metrica aziendale sensata è il costo per pratica risolta correttamente, non soltanto il costo per chiamata.
Versione e limiti attuali
| Parametro | Documentazione al 18 settembre 2026 |
|---|---|
| Versione stabile indicata |
jev-1.13.0; alias jev-latest
|
| Contesto complessivo | 64k token per richiesta |
| Vincolo aggiuntivo | 32k token per state più domanda più lunga |
| Input | Solo testo, anche organizzato in JSON |
| Output | Non addebitato |
| Limiti di traffico pubblicati | 250.000 token/secondo e 1.200 richieste/minuto; dichiarati variabili |
Gli alias possono cambiare versione. Dopo aver validato soglie e comportamento, conviene registrare il modello effettivo restituito dall’API e controllare gli aggiornamenti. Il produttore indica inoltre l’inglese come lingua con prestazioni migliori: per assistenza e documenti in italiano serve una valutazione specifica. Modelli, limiti e lingue supportate.
Dove può essere utile a un’azienda
La nostra lettura è che Jev sia particolarmente interessante dove esiste già un processo e manca un piccolo passaggio interpretativo. Ecco tre ipotesi di applicazione, non casi cliente o risultati che abbiamo misurato.
- Assistenza ed e-commerce: distinguere problemi di consegna, prodotto e pagamento; rilevare urgenza o informazioni mancanti. Il gestionale mantiene la responsabilità di controllare ordine, disponibilità e autorizzazioni.
- CRM e richieste commerciali: classificare il bisogno espresso, individuare il reparto competente e segnalare contatti da approfondire. Una probabilità alta non equivale a consenso marketing o a qualificazione commerciale già verificata.
- Controllo di agenti e contenuti: segnalare una risposta non pertinente, un passaggio non supportato dalle fonti o un’azione proposta da sottoporre a revisione. Il controllo semantico affianca validazioni e permessi applicativi.
Per esempio, il codice potrebbe applicare una regola del genere:
richiesta → controllo dati obbligatori
→ Jev: categoria + urgenza + ambiguità
→ regole applicative e soglie validate
→ reparto competente oppure revisione umana
→ eventuale modello generativo per la rispostaQuesto schema è illustrativo. Il modello non deve poter ampliare da solo l’elenco delle operazioni consentite. Il codice decide anche cosa fare in caso di timeout, risposta inutilizzabile o informazioni insufficienti. La stessa architettura permette di sostituire il componente AI senza riscrivere l’intero processo.
I limiti che il produttore documenta apertamente
La pagina Jev 1.13 jaggedness, revisionata il 17 settembre, descrive difficoltà con conteggi, precisione numerica, confronti fra date, negazioni complesse e contesti lunghi pieni di dettagli irrilevanti. Segnala anche che contenuti costruiti per indirizzare il modello possono modificarne le risposte. Dunque formato vincolato non significa immunità alla prompt injection.
La conseguenza pratica è semplice: calcoli, validazione di date e controlli esatti devono rimanere nel software. Jev può aiutare a interpretare una frase; non è il componente da usare per verificare aritmeticamente il totale di una fattura. Nemmeno due formulazioni apparentemente equivalenti garantiscono identiche distribuzioni: soglie calibrate su una domanda vanno rivalutate quando cambia la domanda. Limiti ufficiali di Jev 1.13.
Come valutarlo prima di integrarlo
Un pilot utile parte da una decisione ripetitiva, osservabile e reversibile. Per alcune settimane il modello può lavorare in parallelo al processo esistente senza eseguire azioni: si confrontano risultati e casi incerti con una valutazione umana.
Nel test misureremmo almeno errori per categoria, falsi positivi e falsi negativi, percentuale di pratiche che richiede revisione, latenza mediana e al 95° percentile, costo complessivo e comportamento sugli input italiani. Separare i dati usati per regolare le soglie da quelli della verifica finale evita di ottimizzare soltanto sugli esempi già conosciuti.
Anche il contenuto inviato va progettato: meno dati irrilevanti, informazioni aggiornate, origine delle evidenze tracciata. Per documenti aziendali occorre valutare contratto, trattamento dei dati e impostazioni del canale scelto. Il guadagno atteso è una procedura più controllabile, non la rimozione indiscriminata delle verifiche.
Come provare Jev: waitlist ufficiale e canali di integrazione
Chi vuole seguire il progetto può iscriversi alla waitlist sul sito ufficiale TypeSafe AI, tramite il pulsante Join Waitlist. Anche noi di WebAlchemy ci siamo iscritti. L’articolo nasce dalla verifica delle fonti pubbliche: non abbiamo ancora effettuato un test diretto del modello.
La disponibilità dipende però anche dal canale. Vercel ha annunciato Jev su AI Gateway il 16 settembre, con l’API sperimentale evaluate dell’AI SDK e identificativo typesafe-ai/jev. Per chi usa quell’ecosistema è un percorso distinto dall’accesso diretto TypeSafe, con proprie condizioni e configurazioni. Annuncio ufficiale Vercel.
Per comprendere il contratto tecnico prima di scegliere un’integrazione, la documentazione dell’API TypeSafe descrive POST /v1/systemone, i campi state, model e questions e le risposte associate alle domande. È un punto di partenza più affidabile di snippet ricopiati da articoli che possono riferirsi a versioni precedenti.
La scommessa che merita attenzione
Il round e l’esperienza del team rendono TypeSafe un progetto da seguire. La questione decisiva, per chi costruisce prodotti digitali, è quanto lavoro interpretativo si possa trasformare in decisioni economiche, misurabili e inserite in processi controllati.
Jev propone di rendere quel passaggio abbastanza rapido da usarlo spesso. Il valore si misurerà quando una richiesta verrà indirizzata meglio, un’eccezione individuata prima o un operatore riceverà meno casi banali senza perdere quelli importanti. È su questi risultati, oltre che sul listino, che valuteremo l’utilità di questa tecnologia nei progetti di intelligenza artificiale e automazione aziendale.
