AUTONOMOS.CITY / AI APPLICATA
Jev e Claude per l’AI nei processi aziendali
Dalle probabilità alle regole operative e ai sistemi on premise
Un cliente segnala una anomalia. Il sistema deve capire a chi assegnare la richiesta, riconoscere un’eventuale urgenza e preparare una risposta. Sono attività diverse, anche se partono dallo stesso messaggio.
Per assegnarle in automatico potremmo affidarle tutte a un modello conversazionale. Possiamo anche progettare un flusso in cui un componente valuta le alternative, il software applica le regole dell’azienda e Claude scrive la risposta usando le informazioni disponibili. Ecco, Jev rende interessante questa seconda possibilità.
Ma per capire come e dove usare l’AI in azienda, prima di tutto, dobbiamo collegare ogni possibile funzione automatica a un lavoro reale. Nel nostro esempio, la qualità del testo è solo una parte del risultato: contano anche il reparto scelto e il tempo impiegato per riconoscere un’urgenza. Servono decisioni definite, dati di verifica e qualcuno che risponda delle regole.
L’occasione per parlarne è Jev’s Architecture Unmasked di Archer Hume, pubblicato il 17 settembre 2026. L’autore analizza il comportamento dell’API e propone una ricostruzione del modello. Le sue ipotesi sull’architettura vanno distinte dalle caratteristiche documentate da TypeSafe.
Che cosa restituisce Jev
TypeSafe presenta Jev come un modello per decisioni strutturate. Gli forniamo uno stato, cioè le informazioni da valutare, e domande con un formato di risposta definito. Riceviamo valori che il software può usare direttamente. Le primitive disponibili sono tre. Documentazione TypeSafe
Scorri la tabella orizzontalmente →
| Tipo | Domanda possibile | Risultato |
|---|---|---|
| Choice | Quale reparto deve gestire la richiesta | Una scelta e le probabilità delle alternative |
| Noul | Il messaggio segnala una macchina ferma | Un valore da 0 a 1 che stima la probabilità del sì |
| Score | Quanto è completa la segnalazione | Un punteggio su livelli descritti da noi e la relativa distribuzione |
Le domande possono condividere lo stesso stato ed essere valutate in parallelo. Se una decisione dipende dal risultato di un’altra, invece, bisogna collegarle nel software e prevedere passaggi successivi.
Qui la grafica di una demo può trarre in inganno. Anche Claude può restituire dati strutturati. La differenza dichiarata da TypeSafe riguarda il modello e il suo addestramento: Jev è progettato per produrre decisioni probabilistiche senza generare una risposta testuale token dopo token. TypeSafe chiama questo addestramento RLCD, Reinforcement Learning for Calibrated Decisions. Presentazione di Jev
Hume ipotizza che il modello elabori un contesto comune, valuti separatamente le domande e legga le probabilità dalle rappresentazioni interne. Considera meno certa l’ipotesi di un’architettura con esperti specializzati, detta Mixture of Experts. Questa ricostruzione aiuta a ragionare sul funzionamento possibile, ma non permette di riprodurre Jev né di identificarne con certezza il modello di base. Analisi originale
Una probabilità va verificata sul lavoro reale
Immaginiamo che un sistema assegni circa l’80% di probabilità a mille valutazioni comparabili. Se è ben calibrato, l’esito previsto dovrebbe risultare corretto approssimativamente nell’80% di quei casi. Questa proprietà riguarda un insieme di osservazioni. Non certifica la singola risposta. È anche il significato di calibrazione descritto da TypeSafe. AI primer
Va inoltre distinta la probabilità di una scelta: una confidence di 0,9 non equivale automaticamente a una probabilità del 90% che la risposta sia corretta. Noul restituisce invece direttamente il valore associato al “sì”.
Per un’azienda, la verifica comincia dalle sue richieste: italiano informale, abbreviazioni, errori di battitura, informazioni mancanti. Un risultato ottenuto su un benchmark generale non dimostra che il modello sappia riconoscere un fermo impianto descritto come “è successo di nuovo, siamo bloccati”.
Anche la promessa commerciale di assenza di allucinazioni va letta con precisione.
Limitare l’output alle alternative ammesse elimina una classe di errori di formato; resta possibile scegliere l’alternativa sbagliata. Lo schema corretto è una proprietà dell’interfaccia. La correttezza della decisione si misura sui casi reali.
Jev e Claude
Prendiamo un servizio di assistenza. Il cliente scrive: “La linea si è fermata due volte stamattina. Dopo il riavvio riparte, ma non possiamo continuare così”.
L’applicazione recupera dal gestionale modello della macchina, contratto e interventi precedenti. Quei dati vengono da sistemi verificabili, senza chiedere al modello di inventarli.
Il flusso proposto è questo:
- L’applicazione prepara lo stato con messaggio originale e dati pertinenti, rispettando i permessi del cliente.
- Jev valuta il reparto competente e la presenza di un fermo macchina. Le domande sono separate perché servono a decisioni diverse.
- Il software applica le soglie e le regole di assegnazione. I casi dubbi arrivano a un operatore.
- Claude riceve il messaggio, i dati verificati e l’esito operativo. Prepara una bozza che riconosce il problema e chiede le informazioni mancanti.
- L’applicazione registra decisione, versione del modello e correzione dell’operatore. L’invio segue le autorizzazioni previste dal servizio.
Per provare soltanto la valutazione, si può usare il Playground TypeSafe dopo aver ottenuto accesso, oppure chiamare l’API. La documentazione indica POST https://api.typesafe.ai/v1/systemone, autenticazione Bearer e corpo JSON. La chiave rimane sul server, fuori dal codice della pagina web.
Questo è un esempio di corpo della richiesta, costruito sul contratto dell’API e ridotto al solo messaggio.
{
"model": "jev-latest",
"state": "La linea si è fermata due volte stamattina.",
"questions": {
"reparto": {
"type": "choice",
"instructions": "A quale reparto assegnare il caso?",
"criteria": {
"assistenza": "Guasti e problemi delle macchine",
"amministrazione": "Fatture e pagamenti",
"altro": "Nessuna delle categorie precedenti"
}
},
"fermo": {
"type": "noul",
"instructions": "Il testo segnala un fermo macchina?"
}
}
}Supponiamo di ricevere 0,94 per assistenza, 0,01 per amministrazione e 0,05 per altro; per il fermo macchina, 0,88. Sono numeri inventati per spiegare il flusso, non risultati di un test su Jev.
Una regola dimostrativa potrebbe assegnare automaticamente il reparto quando la sua probabilità supera 0,90 e aprire una revisione prioritaria quando la probabilità di fermo supera 0,20.
Una soglia più bassa sul fermo serve a intercettare più segnalazioni, accettando più falsi allarmi. Prima dell’uso operativo, entrambe le soglie vanno scelte sui dati e sui costi degli errori.
Se manca una risposta valida dell’API, il caso passa alla coda manuale. Se il testo parla di fatture, il controllo del fermo rimane comunque attivo: una richiesta amministrativa può contenere anche una segnalazione urgente. Il reparto e la priorità non si escludono a vicenda.
Claude può ricevere questa istruzione: “Prepara una bozza per l’operatore usando esclusivamente il messaggio e i dati verificati allegati. Riconosci il fermo segnalato e chiedi codice errore e matricola se mancano. Non confermare interventi, tempi o coperture contrattuali non presenti nei dati”. La bozza resta soggetta ai controlli del servizio.
Farsi aiutare da Claude Code
Claude Code può costruire questa integrazione. TypeSafe pubblica una skill ufficiale che fornisce all’agente istruzioni sull’API. I comandi documentati sono questi. Agent skill
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-aiJev non sostituisce il modello che scrive il codice. È il servizio che l’applicazione userà per le proprie valutazioni. La documentazione TypeSafe chiarisce esplicitamente questa distinzione. Jev with coding agents
Un compito da dare a Claude Code è il seguente:
Usa la skill TypeSafe per costruire un prototipo di smistamento delle richieste di assistenza. Parti da dati sintetici. Crea un servizio sul server che chiami Jev per reparto e fermo macchina, mantenendo domande e soglie in un file di configurazione. Leggi
TYPESAFE_API_KEYdall’ambiente. Conserva la distribuzione completa e la versione restituita dal modello. Se la richiesta fallisce o i risultati non superano i controlli, assegna il caso alla revisione umana. Aggiungi la generazione di una bozza con Claude solo dopo la valutazione. Non inviare messaggi e non modificare il gestionale. Prepara una modalità di prova che confronti le previsioni con etichette verificate da un operatore.
Si può anche esporre la valutazione come strumento chiamabile da Claude tramite API. In questo caso Claude richiede l’uso dello strumento; il nostro software esegue la chiamata a Jev e restituisce il risultato a Claude. È il normale meccanismo dei client tools descritto da Anthropic. Come funziona il tool use
Per uno smistamento che deve avvenire sempre, preferirei però far partire la valutazione dal software. Così quel passaggio non dipende dalla scelta del modello conversazionale di richiamare uno strumento. Claude interviene quando è utile formulare una risposta o analizzare il caso con maggiore profondità.
Che cosa significa davvero on premise
Un database interno non basta a rendere locale l’intero sistema. Se il contenuto di un ticket viene inviato a un’API esterna per la valutazione o per la risposta, quella fase avviene fuori dall’infrastruttura aziendale.
Al 22 settembre 2026, nelle fonti pubbliche consultate per questo articolo, Jev è utilizzabile tramite il servizio TypeSafe; non emerge una distribuzione dei pesi o una procedura pubblica per installarlo on premise. Un’eventuale offerta privata andrebbe verificata direttamente con il fornitore. Accesso e API
Per progettare il sistema conviene distinguere tre configurazioni.
Scorri la tabella orizzontalmente →
| Configurazione | Dove avvengono le valutazioni | Che cosa comporta |
|---|---|---|
| Jev e Claude via API | Presso i rispettivi fornitori | Prototipo integrato con servizi esterni |
| Applicazione interna con API esterne | Dati e regole in azienda, inferenza esterna | Architettura ibrida con trasferimento dei contenuti inviati |
| Sistema interamente locale | Modelli e applicazione nell’infrastruttura aziendale | Componenti locali da scegliere, adattare e verificare |
La terza strada riprende un principio utile mostrato da Jev: separare valutazioni ristrette, regole operative e generazione del testo. Richiede però un progetto distinto. Non possiamo attribuirgli automaticamente l’architettura, la calibrazione o le prestazioni di Jev.
Un progetto locale da cui partire
Per comodità restiamo sullo stesso servizio di assistenza. La prima versione può avere un classificatore locale per il reparto e un secondo controllo per il fermo macchina. Per categorie relativamente stabili, si può adattare un modello di classificazione su esempi etichettati dall’azienda. La libreria Transformers documenta questa procedura; il modello concreto va scelto anche per la lingua italiana e per la licenza d’uso.
La scelta del reparto produce punteggi che vanno calibrati e valutati su dati separati da quelli di addestramento. Strumenti come scikit-learn permettono di costruire curve di calibrazione e correggere le stime. Serve poi un insieme di test finale, mai usato per scegliere soglie o correzioni.
L’applicazione applica le medesime regole di assegnazione del prototipo. Quando serve scrivere, un modello generativo eseguibile localmente riceve i dati autorizzati e, se utile, i passaggi pertinenti dei manuali interni. Un server di inferenza come vLLM può esporre un modello supportato alle altre applicazioni. Questo componente serve a eseguire il modello, non a garantirne la qualità. Documentazione vLLM
Proporrei di iniziare così: una sola famiglia di macchine, pochi reparti, esempi reali corretti dagli operatori e funzionamento iniziale in parallelo al lavoro umano. Il classificatore suggerisce; l’operatore continua a decidere. Le divergenze mostrano dove mancano informazioni, dove le categorie si sovrappongono e quali casi vanno lasciati alla revisione.
Un classificatore addestrato su categorie fisse non acquisisce, per questo, la capacità di rispondere a nuove domande descritte in linguaggio naturale. Se cambiano le categorie, può servire un nuovo addestramento. Anche un modello locale che genera un JSON con un numero chiamato “probabilità” richiede verifica: la forma del dato non ne dimostra la calibrazione.
Claude può aiutare a sviluppare questo sistema lavorando su codice e dati sintetici, mentre il prodotto finale esegue l’inferenza localmente. Se il vincolo impone che nessun contenuto aziendale esca dalla rete, va rispettato anche durante lo sviluppo. OCR, ricerca nei documenti, registri e monitoraggio devono rientrare nel perimetro previsto: la località va verificata lungo tutto il percorso dei dati.
Come misurare il vantaggio (ritorno)
Lo smistamento dell’assistenza è un buon esperimento perché produce un esito verificabile. Lo stesso schema si può provare nella classificazione di documenti in ingresso o nella verifica di completezza di una richiesta prima di passarla a un collega. In tutti questi casi dobbiamo poter descrivere gli esiti ammessi e riconoscere un errore.
Per confrontare Jev con Claude usato da solo, con un classificatore locale o con semplici regole, terrei fissi i casi di test e le condizioni operative. Misurerei:
- La quota di richieste gestite correttamente senza intervento umano e il costo degli errori su quelle automatizzate.
- I fermi macchina persi e i falsi allarmi, separatamente dalla correttezza del reparto assegnato.
- La corrispondenza tra probabilità previste ed esiti osservati, anche per lingua e tipo di richiesta.
- Il tempo dell’intero flusso, compresi rete, recupero dei dati, generazione e attese degli operatori.
- Il costo per pratica correttamente conclusa, includendo revisioni, manutenzione e infrastruttura.
Le dichiarazioni di velocità e convenienza di un fornitore aiutano a scegliere cosa provare. Il vantaggio per l’azienda emerge da questo confronto. Se il volume è basso e le categorie sono semplici, potrebbe bastare una regola. Se le eccezioni dominano, l’automazione dovrà fermarsi spesso: è un risultato utile da conoscere prima di ampliarla.
Raccontare l’AI attraverso questi processi aiuta a capire che cosa possiamo affidarle davvero. Jev offre un’interfaccia interessante per alcune valutazioni; Claude può trasformare informazioni e risultati in comunicazione utile; il software stabilisce le azioni consentite. Un progetto on premise deve ricostruire e verificare questi ruoli con i componenti che può eseguire localmente.
Scegli una decisione ripetitiva del tuo processo, raccogli casi di cui conosci l’esito e definisci quanto costa sbagliare. È da lì che comincia una prova utile.