Cosa sono i typed decision models?

Un typed decision model è un modello di intelligenza artificiale addestrato per rispondere a domande già tipizzate su uno stato applicativo, anziché generare testo libero parola per parola: riceve un contesto non strutturato, per esempio il messaggio di un cliente o lo stato di un processo, insieme a una domanda con risposte predefinite, una scelta tra opzioni date, un punteggio su una scala, un sì o no, e restituisce quel valore in un unico passaggio parallelo, con una probabilità calibrata invece che un testo da interpretare. Il primo esempio pubblico è Jev di TypeSafe, presentato il 15 settembre 2026 come apripista di una categoria che l'azienda chiama System One models, richiamando il pensiero rapido di Kahneman contro quello lento di un LLM generalista. Per chi lo integra, un output che appartiene già allo schema dichiarato non può uscire malformato, e il costo per decisione, nelle cifre dichiarate da TypeSafe, scende di ordini di grandezza rispetto a un modello generalista.

Leggi anche: RLCD vs RLHF · RLHF premia risposte che convincono un umano; RLCD premia decisioni con probabilità calibrata sull'accuratezza reale.

Come funziona, e cosa non è

Il meccanismo non è generazione di testo a cui si impone un formato a valle: TypeSafe descrive un'architettura dedicata più un metodo di addestramento chiamato Reinforcement Learning for Calibrated Decisions, pensato per produrre direttamente un valore già nel formato giusto e un numero che dice quanto il modello è sicuro di quella risposta, in base a cui il codice può poi scegliere un ramo, ordinare o instradare. La differenza pratica con le funzioni che già oggi permettono a un grande LLM di rispondere in un formato preciso (l'output strutturato, per esempio un JSON) o di scegliere quale funzione del programma chiamare (il function calling) sta nel percorso: lì il modello genera comunque testo, vincolato allo schema mentre lo produce, qui la risposta nasce già in quella forma, senza passare dal testo. È anche diverso da un motore a regole scritto a mano, dove è un umano a dichiarare le condizioni: qui le soglie sono probabilità apprese dai dati. Il costo di questa specializzazione è il perimetro: un typed decision model risponde bene a domande chiuse e ricorrenti su uno stato noto in anticipo, instradamento, moderazione, punteggio, un controllo sì/no prima di un'azione automatica; per i compiti aperti che richiedono ragionamento esteso, sintesi o testo libero resta necessario il modello generalista.

Un esempio enterprise

Un'azienda di logistica riceve ogni giorno migliaia di richieste di assistenza via email e chat: un LLM generalista le legge, decide il reparto competente e scrive una risposta di conferma, con un costo per token che cresce linearmente col volume e una latenza di qualche secondo per messaggio. Instradare la richiesta al reparto giusto è però una domanda chiusa, quale tra otto reparti, con quale urgenza, che non richiede di scrivere nulla: separandola dalla generazione della risposta e affidandola a un typed decision model, il routing diventa un passaggio quasi istantaneo e il modello generalista resta acceso solo dove serve davvero, per comporre il testo finale. Il risparmio non è marginale su volumi alti, ma la scelta ha un costo di progetto: il flusso di instradamento va riscritto attorno a un secondo modello, con la sua osservabilità e le sue soglie di confidenza.

Perché conta per chi decide

Per chi valuta l'adozione, i benchmark pubblicati dal vendor mostrano questa categoria di modelli già competitiva sui compiti System One, e la categoria si sta allargando, con casi d'uso già concreti che vanno dal routing di ticket e richieste alla moderazione dei contenuti, dal punteggio di rischio o frode al filtro di rilevanza prima di una RAG, fino ai guardrail che decidono se un agente può procedere con un'azione o deve fermarsi. Il mercato però è appena nato: pochi giorni dopo Jev è comparso Laya, un concorrente a pesi aperti (licenza Apache 2.0, ospitabile in proprio (self-hosted)) addestrato anch'esso con RLCD, quindi la scelta oggi è tra un'API ospitata e un'alternativa open source altrettanto giovane. Altri modelli della stessa famiglia stanno già comparendo, come this-that-model-1.0, presentato in un preprint con un proprio confronto contro Jev, e tutti i numeri di confronto restano per ora autodichiarati da chi li pubblica. Adottarne uno in un flusso critico resta comunque un impegno di vendor lock-in o di manutenzione interna su un'architettura giovane, da isolare dietro un livello di disaccoppiamento che permetta di sostituirla se il mercato si consolida diversamente. E resta un confine di governance: nel perimetro dell'AI Act un sistema che smista automaticamente richieste o filtra contenuti può comunque ricadere tra i sistemi di IA con obblighi di trasparenza e sorveglianza umana, a seconda del caso d'uso e anche se non genera testo.

Questa voce è informativa e non costituisce consulenza legale: per l'applicazione al tuo caso coinvolgi il tuo DPO o il tuo legale.