Un modello che classifica sbaglia senza lasciare traccia: l'etichetta che restituisce è sempre formalmente valida. L'elenco delle risposte possibili gliel'hai scritto tu, e lui ne sceglie sempre una.
A settembre 2026 è arrivata sul mercato una categoria di modelli costruita esattamente così: leggono un testo e restituiscono una decisione — un'etichetta, un punteggio, una probabilità — senza scrivere una riga di spiegazione.
Se in azienda hai un flusso che vale la pena automatizzare perché smista volumi — ticket, mail, candidature, fatture — questa è la forma di AI che ti riguarda più del chatbot. E cambia la cosa da misurare.
Una classe di modelli che non scrive niente
TypeSafe ha presentato Jev e i «System One model» il 15 settembre 2026, descrivendoli come «a new class of frontier models built to make fast, structured decisions that software can use directly». Il modello è disponibile in accesso riservato a pochi clienti.
La documentazione elenca tre tipi di domanda, e sono tutto quello che il modello sa fare:
- Choice — scegli un'opzione da un elenco;
- Score — assegna un punteggio su una scala;
- Noul — questa affermazione è vera?
Choice e Score restituiscono il valore scelto, la distribuzione di probabilità e un numero di confidenza. Noul restituisce solo un valore fra 0 e 1, e lì la confidenza non c'è. Oltre a questo il modello tace: «No text generation, no parsing.»
I numeri dichiarati sono grossi. TypeSafe scrive «End-to-end response time is 70ms-500ms» contro «3 to 329 seconds» dei modelli generalisti, e parla di «40x-200x faster». Il confronto più spinto — «193.6x faster, 444.6x cheaper» — viene dalle prove che TypeSafe ha fatto sui propri flussi di valutazione, e la pagina stessa avverte che sono «on the higher end of real world gains»: il limite superiore del guadagno, non il guadagno tipico. Il prezzo è pubblico: 0,042 dollari per milione di token in ingresso e zero in uscita, con una finestra di 32.000 token, come risulta oggi sulla scheda del modello su Cloudflare Workers AI.
C'è poi una garanzia formulata in modo molto forte: «The model never makes type errors», e l'annuncio aggiunge che falsificarla basterebbe un controesempio, ma «it is mathematically impossible».
Quella garanzia riguarda la forma della risposta, non il suo contenuto. Dice che riceverai sempre una delle etichette che hai dichiarato, con accanto un numero ben formato. Dice niente su quale etichetta sia quella giusta.
L'errore cambia forma, e smette di somigliare a un errore
Quando un modello generativo sbaglia, di solito lascia una traccia. Scrive un importo che non torna, cita una norma che non esiste, nomina un codice prodotto che a catalogo non c'è. Chi legge ha qualcosa su cui inciampare — e infatti le contromisure che funzionano lavorano su quella traccia: togliere al modello il compito di scrivere i numeri, o vincolare l'uscita a un catalogo valido.
Qui la traccia manca. L'uscita è valida per costruzione, perché l'elenco delle etichette lo hai scritto tu. Un ticket classificato «amministrazione» invece di «tecnico» è una parola legittima in un campo legittimo, con accanto 0.91. Passa i controlli formali, entra nel flusso, viene instradato.
L'unica informazione che ti resta per distinguere una decisione buona da una sbagliata è quel numero. Quindi la domanda si sposta dall'accuratezza media del modello a un'altra: il numero che dichiara corrisponde al tasso di errore reale sui tuoi dati?
«Calibrato» è la promessa vera, e vale solo sui tuoi dati
Un modello si dice calibrato quando le sue probabilità sono oneste: fra tutte le decisioni che restituisce a 0,80, circa l'80% è corretto. TypeSafe lo mette tra le caratteristiche del prodotto — «Calibrated: higher confidence means higher accuracy» — e attribuisce il risultato a un metodo di post-addestramento che chiama RLCD, Reinforcement Learning for Calibrated Decisions.
Del metodo esiste il nome. Il dataset, la funzione di ricompensa e la metodologia di valutazione restano non pubblicati. Un preprint del 24 settembre 2026 costruisce un banco di prova intorno a Jev, ma usa il modello come strumento: come sia stato addestrato non lo documenta.
La pagina sulla confidenza dice da dove viene quel numero — dalla concentrazione della distribuzione di probabilità — e rinvia il calcolo vero a un ricettario che al momento non c'è. La formula che mostra, «(3 × largest probability − 1) / 2», è l'approssimazione usata nella demo interattiva per le domande a tre opzioni, non il conto che fa il modello.
L'esempio di codice usa due soglie: 0,5 come pavimento sotto cui non agire, 0,9 per le operazioni delicate. La documentazione aggiunge: «The correct threshold values depend on your domain and the performance of the model for your use case. Start with conservative thresholds, test with your own data, and adjust as you observe results.»
Quei due numeri sono un punto di partenza che il fornitore stesso ti chiede di ricalibrare. Dati empirici sulla calibrazione — l'errore medio fra confidenza dichiarata e accuratezza osservata — nella documentazione mancano.
Tre prove indipendenti, e la calibrazione tiene solo dove il modello è già stato
Nelle due settimane dopo l'annuncio, diverse persone hanno provato a misurare la calibrazione di Jev dall'esterno. Prima dei risultati, il peso delle tre che pubblicano metodo e dati grezzi: sono lavori individuali, usciti senza rivista, su campioni che vanno da 500 a qualche migliaio di casi. Uno dei tre ha già corretto un numero dopo la segnalazione di un lettore, e due segnalano che l'alias del modello può cambiare versione senza avviso.
Sulle prove d'esame pubbliche la calibrazione tiene. Su un compito nuovo si allarga di 4,4 volte. La misura più diretta è di scienthoon, pubblicata fra il 19 e il 22 settembre 2026: 900 ticket di assistenza generati da regole, che il modello non può avere visto, più 3.721 casi presi da tre prove pubbliche, per 4.621 chiamate e circa 0,06 dollari di spesa. Sulle prove pubbliche l'errore di calibrazione misurato (ECE, la distanza media fra confidenza dichiarata e accuratezza osservata) sta fra 0,024 e 0,032, da una a meno di due volte il rumore di fondo del rispettivo campione. Sui 900 ticket nuovi sale a 0,107, contro un rumore di fondo di 0,024: 4,4 volte. L'autore avverte che la contaminazione delle prove pubbliche è impossibile da escludere, e che quelle righe valgono come contesto, non come prova di generalizzazione. Per te conta la seconda cifra, perché il tuo flusso somiglia ai ticket e non a una prova d'esame.
Il verso dell'errore cambia col tipo di domanda, sugli stessi testi. Nello stesso lavoro: le domande Choice a quattro opzioni arrivano all'89,0% di accuratezza e stanno appena sopra la calibrazione — la temperatura di correzione è 1,30, dopo che il 22 settembre l'autore ha rettificato il valore più alto pubblicato il primo giorno. Le domande Noul stanno al 91,7%, e lì il modello è più prudente del necessario. Le Score a quattro livelli crollano al 44,7%, con ECE 0,325: è l'unico tipo su cui risulta nettamente troppo sicuro. Due avvertenze dell'autore vanno insieme ai numeri: di leggere il verso e non l'ampiezza, e che il confronto fra tipi è indebolito dal fatto che il Noul è l'unico le cui probabilità non toccano mai 0 e 1. Sulle accuratezze pesa anche una scelta del generatore: il 5% delle etichette è corrotto di proposito, quindi su quei ticket nessun modello può superare circa il 95%.
Quel crollo dello Score ha una causa precisa. La priorità di un ticket, in quel compito, dipendeva da una politica aziendale che nel testo del ticket non compariva. La risposta non era ricavabile, e il modello ha risposto comunque.
Dallo stesso lavoro esce la riga più pratica per chi deve mettere una soglia: il campo confidence restituito dal modello si è comportato peggio della probabilità massima grezza su tutti i suoi insiemi — ECE 0,035 su OpenBookQA, 0,078 su HellaSwag, 0,18 sul set sintetico. Il numero su cui verrebbe naturale mettere la soglia è quello che ha funzionato meno bene.
Togliendo al modello la possibilità di dire «non lo so», la calibrazione si disintegra. È il risultato di un audit via API pubblicato il 18 settembre 2026, sette esperimenti per circa 7.000 chiamate su MMLU-ProX e KoBBQ. Rimosse le opzioni di astensione, sui casi senza risposta l'accuratezza passa da 0,950 a 0,000 e l'ECE da 0,023 a 0,793. Su KoBBQ, che è un banco di prova sui pregiudizi, la quota di risposte stereotipate sale da 0,03 a 0,79, e lo fa a una confidenza di 0,79: il modello non si limita a sbagliare, sceglie lo stereotipo e resta sicuro. È il caso da tenere a mente se quello che stai smistando sono candidature. Lo stesso autore osserva che il campo confidence non è documentato e lavora sulle probabilità grezze.
Contro un classificatore addestrato sul tuo dominio, il confronto si stringe. Il banco di prova di Dhruv Mehra del 22 settembre 2026 mette Jev 1.13 contro cinque alternative su tre dataset pubblici, 500 casi ciascuno. Su Banking77 — 77 etichette, il caso più vicino a uno smistamento aziendale vero — Jev fa 76,4% di accuratezza con ECE 0,125; un DistilBERT addestrato su quel dominio fa 88,0% con ECE 0,101, in 8 millisecondi e senza costi di API. Su testi a quattro categorie Jev sta all'84,3%, il DistilBERT al 91,0%. Quel DistilBERT però si addestra in 579 secondi su un campione già etichettato: è lo stesso campione che serve a te per la misura della prossima sezione. L'autore dichiara che a 500 casi l'intervallo di confidenza sull'accuratezza è di circa ±2,5 punti, e che i due dataset più facili i modelli generalisti li hanno quasi certamente già visti.
Le stesse tabelle ridimensionano i due numeri dell'annuncio. La latenza mediana misurata per Jev è intorno ai 380 millisecondi — dentro la forchetta dichiarata, ma all'estremo alto — contro i circa 2.000 millisecondi di un modello generalista di fascia alta: cinque volte, non quaranta né duecento. Sul costo, 0,08 dollari contro 6,43 per mille chiamate su Banking77: ottanta volte, non quattrocentoquarantaquattro.
La misura che puoi fare su un tuo campione già etichettato
Nessuno dei numeri qui sopra vale per te, e il motivo è proprio quello che quelle prove hanno trovato: la calibrazione regge sui compiti che il modello ha già visto e si allarga su quelli nuovi. Il tuo flusso è un compito nuovo.
La misura si fa in mezza giornata, su dati che probabilmente hai già.
Serve un campione vero, già etichettato da persone. Duecento o trecento casi presi dallo storico — ticket già smistati, candidature già scartate o passate, fatture già imputate. Vecchi abbastanza da avere l'esito, e pescati dal lavoro reale invece che costruiti per la prova.
Registra due colonne: l'etichetta scelta e la probabilità. Prendi anche la probabilità grezza dell'opzione vincente, così puoi confrontarla con la confidenza — che sulle domande Noul non esiste proprio, e che nella prova indipendente ha fatto peggio.
Raggruppa per fascia e conta. Fascia 0,5-0,6, poi 0,6-0,7, fino a 0,9-1,0. In ogni fascia calcola la percentuale di risposte che coincidono con l'etichetta umana. In una fascia 0,8-0,9 ti aspetti circa l'85% di risposte corrette. Se ne trovi il 60%, il modello è troppo sicuro su quei casi, e una soglia a 0,8 sta lasciando passare da sola due decisioni sbagliate su cinque. Se trovi il 97%, sei troppo prudente e stai mandando a una persona lavoro che poteva correre.
Ripeti la conta per tipo di domanda e per etichetta. Le prove indipendenti lo suggeriscono: sugli stessi testi, la stessa versione del modello era troppo sicura su un tipo di domanda e troppo prudente su un altro. Una media su tutto nasconde entrambe le cose.
Guarda separatamente i casi in cui la risposta non è nel testo. Costruisci una ventina di casi la cui classificazione dipende da una regola interna che nel documento non compare. Se il modello risponde con confidenza alta invece di scendere, hai trovato il punto in cui il tuo flusso sbaglierà in silenzio. Le soglie lì non intercettano niente, perché il numero è alto.
Se la decisione dipende da più fattori, spezzala. La documentazione stessa consiglia una domanda per fattore, con i pesi nel tuo codice invece che dentro il modello. È anche l'unico modo per sapere quale fattore ha sbagliato.
Rifai la misura quando cambia la versione. Vale per il modello e per le descrizioni delle etichette: nel banco di prova sopra, riscriverle ha spostato l'accuratezza di un punto e mezzo.
Da qui la soglia diventa una conseguenza: una percentuale osservata su un campione tuo, da rivedere quando cambia qualcosa.
Una riga dell'AI Act parla proprio di questo
L'articolo 86 del Regolamento (UE) 2024/1689 si intitola «Diritto alla spiegazione dei singoli processi decisionali». Dà a chi è oggetto di una decisione presa sulla base dell'output di un sistema ad alto rischio dell'allegato III — escluso il punto 2, le infrastrutture critiche — il diritto di ottenere dal deployer, cioè dall'azienda che lo usa, «spiegazioni chiare e significative sul ruolo del sistema di IA nella procedura decisionale e sui principali elementi della decisione adottata». Le condizioni sono strette: la decisione deve produrre effetti giuridici o incidere in modo analogo sulla persona, e la persona deve ritenere che l'impatto sulla sua salute, sulla sua sicurezza o sui suoi diritti fondamentali sia negativo. I paragrafi 2 e 3 lasciano fuori i casi già coperti o limitati da altro diritto dell'Unione o nazionale.
L'articolo si applica dal 2 agosto 2026, la data generale dell'articolo 113, e l'Omnibus digitale sull'IA (Regolamento (UE) 2026/1744) non lo nomina mai. Quanto morda da qui a dicembre 2027 resta una domanda aperta: lo stesso Omnibus rinvia al 2 dicembre 2027 il capo III, sezioni 1, 2 e 3 per i sistemi dell'allegato III, e lì dentro c'è l'articolo 6, paragrafo 2, che è la norma che quei sistemi li classifica ad alto rischio.
Il punto 4, lettera a) dell'allegato III comprende i sistemi destinati a «analizzare o filtrare le candidature». Se lo smistamento che stai valutando è quello, il 2 dicembre 2027 è dopodomani per un flusso che stai costruendo adesso — e una schermata con un'etichetta e 0.91 è distante da una spiegazione dei principali elementi della decisione. La stessa distanza l'abbiamo già percorsa dal lato di chi compra: che cosa chiedere a un fornitore di AI per la selezione del personale.
Prima di dare una soglia a un numero
Un modello che classifica è la parte di AI più facile da mettere in produzione e la più difficile da controllare dopo. Costa poco, risponde in mezzo secondo, e quello che sbaglia resta invisibile. Restituisce sempre qualcosa di formalmente corretto, anche quando la risposta giusta non era nel testo che gli hai dato.
Quello che ti resta in mano per capire quando fidarti è un numero. Le prove indipendenti dicono che quel numero è onesto sui compiti che il modello conosce e lo è meno su quelli nuovi, con uno scarto che cambia verso da un tipo di domanda all'altro. Il tuo flusso è uno di quelli nuovi.
Il lavoro da fare è una misura: un campione già etichettato, le risposte divise per fascia di confidenza, il conto di quante sono giuste in ciascuna. Mezza giornata, e da quel momento la supervisione delle persone diventa una soglia che sai difendere con un numero tuo.
Nel flusso che stai automatizzando, sai già quante delle decisioni classificate con confidenza alta sono sbagliate — o stai usando la soglia che era nell'esempio della documentazione?