Tag: AI locale

AI & GENAI, TECH & BUSINESS

Azienda agentica: gli otto strati da progettare prima dell’interfaccia

Da prima di agosto ho messo da parte, uno dopo l’altro, gli schemi con cui i grandi fornitori di software aziendale raccontano la loro offerta di intelligenza artificiale, per studiarli: quello di uno dei CRM più diffusi, quello della suite d’ufficio che quasi tutti abbiamo sul portatile, quelli delle piattaforme verticali per la logistica e la distribuzione e così via. Cambiano i nomi, cambiano i colori, a volte i prodotti cambiano nome da un mese all’altro e chi prova a seguirli fatica a capire cosa sia stato annunciato e cosa porta veramente di differente sul mercato.

Messi uno accanto all’altro, però, disegnano la stessa torre, e ognuno a modo suo descrive l’azienda agentica.

In basso ci sono i sistemi dove vive la verità aziendale, sopra di loro uno strato che trasforma i dati in contesto leggibile da un modello, sopra ancora gli agenti che ragionano e agiscono, e in cima un’interfaccia conversazionale dove le persone fanno domande e approvano azioni.

Attorno a tutto, disegnato come una cornice e quasi mai come un piano, l’insieme di servizi che nessuno compra a parte, che spesso vanno decisi e scritti proprio internamente e che, però, tiene in piedi la costruzione: permessi, sicurezza, tracciamento delle azioni, valutazione dei risultati.

La torre descrive bene dove stanno andando le aziende dal mio punto di vista.

Gli schemi lasciano fuori, perché a chi li disegna conviene darlo per scontato, una domanda molto specifica e importante: chi possiede gli strati bassi?

Dove gira il modello, dove viene assemblato il contesto, chi può leggere il registro di quello che gli agenti hanno fatto.

Su questa domanda ho costruito il lavoro di questo ultimo anno da quando ho fondato ZeroFive.AI e che sto portando nei progetti con le aziende, con LocalAI sull’inferenza locale e con Gideon, l’ultimo nato, l’assistente che uso ogni giorno come banco di prova. In questo approfondimento provo a descrivere in modo puntuale e sintetico (nemmeno troppo) l’approccio per intero, senza marchi di fornitori, perché questa architettura dell’azienda agentica vale anche per chi non comprerà mai una licenza da nessuno di loro.

Otto strati dell’azienda agentica, letti dal basso

La versione astratta della torre, quella che vale per qualunque azienda agentica, ha 8 strati. Li descrivo partendo dal basso perché è l’ordine in cui andrebbero progettati, anche se quasi tutti i progetti che incontro partono dall’alto, dalla scelta dell’assistente da comprare per i dipendenti, o dal modello o dalla tecnologia in generale.

Strato Cosa contiene Domanda da fare prima di costruirlo
0. Calcolo e modelli dove gira l’inferenza: cloud, server aziendali, postazioni quali dati possono raggiungere quale modello?
1. Sistemi di registro gestionale, CRM, archivi documentali, magazzino per ogni dato, qual è l’unico sistema proprietario?
2. Logica di dominio oggetti, regole, flussi approvativi, permessi quali regole oggi stanno solo nella testa di qualcuno?
3. Contesto identità delle entità, ontologia, memoria degli agenti, testi vettorizzati cosa significano le informazioni e chi lo decide?
4. Agency ragionamento, pianificazione, agenti specializzati, cicli di esecuzione quali compiti si delegano e con quale condizione di arresto?
5. Harness governo, sicurezza, osservabilità, valutazione, scelta del modello cosa può fare un agente senza chiedere, e chi lo verifica?
6. Esposizione headless API, server MCP, riga di comando, skill quale contratto vede chi sta sopra?
7. Interfaccia assistenti commerciali, chat aziendali, voce, app proprie dove lavorano già le persone?

Lo strato zero è quello che nessuno compra e tutti pagano. Nella torre dei fornitori coincide con il loro cloud e non compare quasi mai nei disegni, eppure decide dove finisce ogni frase che un agente legge, e quanto costa leggerla.

Sopra stanno i sistemi di registro, che le aziende conoscono da trent’anni e che con l’arrivo degli agenti chiedono una sola regola, la più difficile da rispettare: ogni dato ha un solo sistema proprietario, e tutti gli altri lo citano invece di copiarlo. Un’anagrafica cliente duplicata in due posti produce, dopo pochi mesi, due verità su chi decide in quell’azienda, e un modello che le legge entrambe sceglie a caso quale riportare.

La logica di dominio è lo strato che trasforma i dati in processi. Un ordine ha uno stato, uno sconto oltre una certa soglia richiede una firma, un fornitore nuovo passa da una verifica prima di ricevere il primo pagamento. Molte di queste regole vivono nel codice dei gestionali, molte altre in procedure che qualcuno ha scritto anni fa, e una parte consistente solo nell’abitudine di chi fa quel lavoro da tanto tempo. Il modello dati è una teoria dell’azienda, e gli agenti la ereditano così com’è, con le scelte fatte da un consulente dieci anni fa per far quadrare la contabilità analitica.

Il contesto è lo strato dove l’azienda dice a un modello cosa significano le sue informazioni: che “cliente” in amministrazione vuol dire chi ha una fattura aperta e in commerciale chi ha un’opportunità attiva, che due nomi diversi indicano la stessa persona, quale decisione presa in una riunione di marzo ha superato quella di gennaio. Qui stanno l’ontologia, la risoluzione delle identità, la memoria di lungo periodo degli agenti e il testo dei documenti reso interrogabile. Sopra lavora l’agency, cioè la parte che pianifica, sceglie gli strumenti, esegue e controlla il risultato in un ciclo che si ripete finché non scatta una condizione di arresto.

L’harness ha un numero in tabella per comodità, ma nel disegno andrebbe tracciato come una cornice attorno al contesto e agli agenti. È tutto quello che serve a un agente in produzione e che non è il modello: i permessi con cui agisce, le regole che decidono quando deve chiedere, il registro di quello che ha fatto, le verifiche automatiche sui risultati, la scelta di quale modello usare per quale classe di dati.

Sopra ancora c’è l’esposizione headless, che rende disponibile tutto quello che sta sotto senza bisogno di uno schermo, attraverso API, server MCP, riga di comando e skill.

In cima l’interfaccia, che grazie ai due strati precedenti può essere quasi qualunque cosa.

L’interfaccia esce dal centro del progetto

Per vent’anni il software aziendale ha coinciso con il suo schermo. Si comprava una licenza per ogni postazione, si formavano le persone sull’interfaccia, si misurava l’adozione contando quanti accessi faceva ciascuno ogni settimana, e il fornitore teneva il cliente proprio attraverso quell’abitudine visiva: cambiare CRM voleva dire riaddestrare centinaia di persone a cliccare in posti diversi. Il valore stava sopra, nell’interfaccia, e i dati sotto erano il prezzo da pagare per usarla.

Nell’azienda agentica questo rapporto si rovescia. Le persone lavorano dentro l’assistente che preferiscono, un client commerciale, la chat aziendale, la voce in macchina, e chiedono a quell’assistente di andare a prendere le informazioni dove si trovano e di agire per loro conto. In Pelle Digitale avevo provato a descrivere l’interfaccia come il punto di contatto fra la persona e il sistema digitale che la circonda; con gli agenti quel punto si moltiplica e si assottiglia, diventa una superficie che cambia a seconda del momento e del dispositivo, e domani anche dello spazio fisico, come racconto in Spatial Shift. Il prodotto che un’azienda deve costruire verso i propri agenti non è più uno schermo, è un contratto: quali operazioni si possono chiedere, con quali permessi, con quali garanzie sul risultato.

Il Model Context Protocol è oggi la forma più diffusa di quel contratto, e il motivo per cui lo strato sei della tabella è diventato progettabile da un’azienda di medie dimensioni senza un esercito di sviluppatori. Un server MCP espone gli strumenti di un sistema a qualunque client compatibile, e lo stesso server serve il dipendente che usa un assistente commerciale, il collega che preferisce un client locale e l’agente notturno che prepara i report del lunedì. La regola che tengo ferma in ogni progetto riguarda l’identità: il modello opera sempre con i permessi reali della persona che lo sta usando, mai con un’utenza tecnica capace di tutto.

C’è un test semplice per capire a che punto è un’azienda, e lo propongo spesso nelle prime riunioni.

Se domani i dipendenti cambiassero assistente, quanto lavoro andrebbe rifatto?

Quando la logica vive nei prompt salvati dentro il prodotto di un fornitore, nelle sue memorie e nei suoi agenti preconfigurati, va rifatto quasi tutto. Quando vive negli strati dal tre al sei, il cambio è una configurazione, e la scelta dell’assistente torna a essere una decisione su costo e riservatezza.

C’è un lavoro enorme da fare ed è sottovalutato

Nelle dimostrazioni un agente risponde in pochi secondi a una domanda sul portafoglio clienti, prepara una bozza di offerta e propone il prossimo passo commerciale. In produzione lo stesso agente deve sapere che la parola “cliente” ha tre significati in tre uffici, non deve leggere i margini se la persona che lo interroga non è autorizzata a vederli, deve lasciare traccia di quello che ha fatto e deve fermarsi quando la confidenza è bassa. Tutto questo vive in due strati che nelle demo non si vedono, il contesto e l’harness, ed è lì che passa la maggior parte del tempo di un progetto serio.

Sul contesto ho scritto molto in queste settimane, e nelle aziende lo riduco a una regola: il significato va deciso prima che lo decida un modello. Un modello collegato a dati senza tipi e senza relazioni dichiarate ricostruisce da solo il senso delle cose, ogni volta in modo leggermente diverso, e due risposte alla stessa domanda a una settimana di distanza smettono di coincidere. Un’ontologia operativa fissa i tipi di oggetto, le relazioni e le azioni ammesse su ciascuno, e ha un effetto collaterale che i direttori finanziari capiscono subito: riduce i token che un agente spende per orientarsi. Lo stesso vale per la quantità di materiale che si carica nella finestra di contesto, dove il superfluo compete con quello che serve invece di essere scartato.

L’harness è lo strato su cui i fornitori sono più indietro, e lo dicono loro stessi. In almeno uno degli annunci più ambiziosi di quest’autunno, governo e sicurezza compaiono fra le capacità della piattaforma con l’annotazione che sono in parte ancora da costruire. La parte del sistema che decide cosa può fare un agente senza chiedere, chi lo verifica e cosa rimane scritto dopo è quindi la meno matura nelle offerte chiavi in mano, e quella che chi costruisce un’azienda agentica ha più interesse a progettare in casa.

Nei progetti la scrivo prima degli agenti, con quattro famiglie di regole. I permessi sugli strumenti hanno tre livelli, negato, consentito con conferma, consentito senza conferma, e ogni strumento nasce al livello più restrittivo. Le scritture passano da un’approvazione umana: il modello propone, le persone firmano, e nessuna informazione entra nella memoria aziendale senza un responsabile con nome e cognome. Tutto quello che si può verificare in modo deterministico va tolto al giudizio del modello e affidato a uno script, dal totale di un preventivo alla validità di un pacchetto di modifiche. E ogni chiamata lascia una riga in un registro leggibile, con chi l’ha chiesta, quale modello l’ha eseguita e quali dati sono usciti dal perimetro.

Chi possiede gli strati bassi

Ogni volta che un agente lavora, il contesto viene assemblato e spedito al modello. Quel pacchetto contiene il distillato più prezioso che un’azienda produce: il modo in cui classifica i clienti, le decisioni prese e le ragioni per cui sono state prese, le relazioni fra persone, contratti e progetti. Nella torre dei grandi fornitori quel distillato viaggia verso un data center che non controlli, con le garanzie del contratto che hai firmato, a un prezzo calcolato a token che può cambiare alla prossima revisione del listino, su modelli che il fornitore può ritirare con qualche mese di preavviso. Sono condizioni accettabili per molte classi di dati, a patto di conoscerle prima della firma, cosa che capita molto meno spesso di quanto si pensi.

La sovranità di cui parlo con le aziende è una scelta per classe di dati, senza ideologia contro il cloud.

Il metodo che uso divide le informazioni in tre gruppi: quelle che possono uscire liberamente, come ricerche pubbliche e bozze di contenuti, quelle interne che possono uscire solo verso fornitori con garanzie contrattuali adeguate, quelle che non devono uscire per nessun motivo, come i dati economici riservati o i segreti industriali. Ai primi due gruppi si applica il modello più capace disponibile, al terzo un modello che gira dentro il perimetro, oppure un passaggio di anonimizzazione prima dell’invio.

Per molto tempo il terzo gruppo ha avuto poche soluzioni pratiche, perché i modelli aperti erano lontani da quelli commerciali e farli girare richiedeva competenze che un’azienda media non aveva in casa. Oggi lo strato zero si può possedere.

LocalAI, il progetto open source di inferenza locale di cui sono cofondatore e dove seguo il prodotto, nasce esattamente per questo: fa girare modelli aperti su hardware aziendale, dal server nel seminterrato alla workstation di un reparto, ed espone un’interfaccia di programmazione compatibile con quella dei principali fornitori commerciali. Gli strati che stanno sopra non si accorgono del cambio, e un’azienda può affiancare un modello locale a uno commerciale e smistare le chiamate in base alla classe del dato, senza riscrivere né il contesto né gli agenti.

L’azienda agentica che ne esce è ibrida quasi sempre, a mio avviso, e va bene così. Quello che cambia rispetto alla torre comprata intera è la posizione del cuore: ontologia, memoria, regole e registri restano dentro l’azienda, e il modello diventa un lettore che si può sostituire, affiancare o spegnere senza perdere nulla. Cambiare fornitore smette di essere un progetto di migrazione e diventa una riga di configurazione.

“Gideon” come banco di prova

Prima di proporre un’architettura a un’azienda la provo su di me. Gideon è il mio assistente personale, prende il nome dall’intelligenza artificiale di The Flash (Jarvis è troppo abusato ormai, anche io lo chiamavo così), e in questi mesi è diventato il posto dove verifico ogni strato della tabella con dati veri, i miei. Il principio di progettazione è lo stesso che porto nelle aziende: la memoria sta fuori dal modello, e il modello si può cambiare in qualunque momento.

Le funzioni su cui sto lavorando seguono gli strati quasi uno per uno. Gideon fa girare modelli locali e può affiancare modelli esterni quando il compito lo richiede, e già questo sposta la proprietà dello strato zero. Il lavoro parte da cartelle collegate e file caricati, perché la domanda più frequente che una persona fa a un assistente riguarda i propri documenti, e quei documenti devono essere interrogabili senza uscire dalla macchina. I connettori MCP, che sono la sua esposizione verso il resto del mondo, sono divisi in tre famiglie (interni all’assistente, servizi aziendali, servizi di terze parti) e per ciascuno il sistema propone una descrizione di quando usarlo, che l’utente può correggere.

L’harness è la parte dove ho investito di più. Ogni strumento ha i tre livelli di permesso, dal divieto all’esecuzione senza conferma. Una protezione della riservatezza si attiva nel campo dove si scrive la richiesta e lavora anche quando la richiesta va verso un modello esterno, togliendo dal testo quello che non deve uscire. E una pagina sullo stato del sistema mostra i consumi, le chiamate e soprattutto le uscite di dati verso terzi e verso i connettori, perché un’azienda che non sa cosa è uscito ieri non può decidere cosa far uscire domani.

Nessuna di queste funzioni è una scoperta. Ognuna esiste già da qualche parte, sparsa fra prodotti diversi, e quello che manca quasi sempre è la loro composizione in un unico sistema dove il cuore rimane in mano a chi lo usa. Gideon serve a me per capire quanto costa questa composizione, dove si inceppa e quali scelte sopravvivono al passaggio da una persona a un team.

Come accompagno un’azienda dentro lo stack

Il lavoro con le aziende comincia quasi sempre da una richiesta che sta in cima alla torre: quale assistente comprare, come portare gli agenti nel servizio clienti, come far parlare il CRM con la chat aziendale. La prima cosa che faccio è rimettere la torre in piedi, e disegnare con il team la mappa dei suoi otto strati com’è oggi. Per ogni strato scriviamo chi ne è proprietario, quale contratto espone allo strato superiore e se si potrebbe sostituire senza toccare gli altri. Le mappe che ne escono si somigliano spesso: i sistemi di registro esistono e funzionano, la logica di dominio è per metà nel software e per metà nelle persone, il contesto manca, l’harness manca, l’interfaccia è stata già comprata da qualcuno.

Da lì il percorso sale dal basso.

La classificazione dei dati nei tre gruppi viene per prima, perché decide cosa si può fare allo strato zero e quali modelli possono leggere cosa. Poi la regola del sistema proprietario per ogni dato, e un’ontologia minima che fissa i tipi di oggetto, le relazioni e chi decide quando due fonti si contraddicono. Poi l’harness, scritto prima che esista un solo agente in produzione: permessi, approvazioni, verifiche automatiche, registro delle azioni. Solo a quel punto si espongono i sistemi attraverso server MCP con i permessi reali delle persone, si costruiscono le skill condivise che fanno parlare a tutti gli assistenti la stessa lingua aziendale, e si sceglie l’interfaccia, spesso più d’una, guardando dove le persone lavorano già.

In ZeroFive.AI questo percorso è organizzato in cinque fasi, ALIGN, ASSESS, ARCHITECT, ACTIVATE e AMPLIFY (come si vede nell’immagine), con cancelli decisionali fra l’una e l’altra che il cliente deve superare prima di spendere nella fase successiva.

Il rischio legato all’AI si misura nella fase di valutazione e non a sistema già acceso, e nessun caso d’uso entra nel portafoglio senza un confronto scritto con l’alternativa che non usa l’intelligenza artificiale, perché in una parte dei casi uno script ben fatto risolve lo stesso problema a una frazione del costo.

Il “Workspace progetti” per esempio, la piattaforma con cui gestiamo i progetti dei clienti in ICONICO e Zerofive, è il caso che porto come esempio in aula per far vedere come facciamo le cose: molte delle regole descritte qui, dal sistema proprietario per ogni dato all’approvazione umana delle proposte, sono già in produzione al nostro interno, ed è il modo più rapido per mostrare a un’azienda come funzionano prima che decida se costruire le proprie.

C’è poi la parte che nessun diagramma che di solito non si trova, e cioè le persone.

Il corso che sto portando nelle business school e nei percorsi aziendali è costruito su quattro discipline che corrispondono a 4 zone della torre: prompt engineering per l’interfaccia, context engineering per lo strato del contesto, loop engineering per gli agenti, harness engineering per la cornice che li governa.

Un’azienda che compra uno stack senza avere nessuno capace di ragionare su queste quattro zone si ritrova un sistema che funziona finché funziona, e che nessuno sa correggere quando cambia qualcosa e che soprattutto nessuno sa avere potenzialità più avanzate.

Chi vuole capire da dove partire nella propria organizzazione può scrivermi: la prima mappa degli otto strati si costruisce insieme alle persone che conoscono davvero i sistemi, e dice già molto su quali investimenti fatti finora sono riutilizzabili e quali andranno rifatti. 

Fondamenta da tenere in casa

Nei prossimi due anni l’interfaccia cambierà più volte.

Gli assistenti di oggi verranno rinominati, accorpati, sostituiti da altri che ancora non conosciamo, e una parte del lavoro passerà dalla chat alla voce e agli ambienti.

Un’azienda agentica che avrà costruito in casa il contesto, l’harness e l’esposizione dei propri sistemi cambierà assistente con la stessa facilità con cui oggi si cambia browser, e sceglierà ogni volta il modello più adatto alla classe di dati che deve trattare.

Chi avrà comprato la torre intera tratterà ogni anno con il fornitore il prezzo di accesso al proprio contesto, cioè alla descrizione più accurata di sé che abbia mai prodotto. La torre la disegneranno i fornitori, ed è giusto che sia così; le fondamenta conviene che ogni azienda le tenga a casa propria.

AI & GENAI, TECH & BUSINESS

Company Brain: come si costruisce il “Jarvis” di un’azienda

Progettare uno spazio di lavoro che un LLM sa leggere

In quasi tutte le aziende che incontro la conoscenza di un progetto vive in sette o otto posti diversi: le registrazioni delle riunioni, le caselle di posta, una cartella condivisa su Drive e un’altra su Dropbox, il calendario, il CRM, i canali Slack o Teams, le schede di Jira o di Asana, le note personali di ciascuno. C’è poi un posto nuovo, che fino a due anni fa non esisteva e oggi contiene una parte rilevante del ragionamento di un team: le conversazioni che ogni persona ha con il proprio assistente AI mentre lavora. Ciascuno di questi posti funziona bene da solo, e nessuno sa dell’esistenza degli altri.

La reazione più diffusa è collegare un LLM a tutte queste fonti e aspettarsi che dal collegamento nasca un’intelligenza del progetto. È l’idea del Jarvis aziendale, che in questi mesi circola con nomi diversi, Company Brain, Brain OS, Company OS: un assistente che sa tutto dell’azienda perché vede tutto. Succede il contrario. Più fonti si collegano senza una struttura che le tenga insieme, più il modello produce risposte plausibili costruite su frammenti, e più diventa difficile capire da dove arriva un’affermazione, chi l’ha verificata e se è ancora vera.

Uno spazio di lavoro intelligente si progetta, e la scelta del modello arriva per ultima. Il metodo che propongo lo divide in sei livelli, ciascuno con una domanda a cui rispondere prima di passare al successivo. Come caso concreto uso il Workspace ICONICO, la piattaforma interna di gestione dei progetti che stiamo costruendo in questi mesi: è ancora giovane, ma ogni scelta descritta qui è già in produzione.

La complessità cambia posto

Prima dei livelli conviene chiarire che tipo di trasformazione è questa, perché la si confonde spesso con quella che le aziende hanno attraversato negli ultimi quindici anni. La digital transformation ha portato processi e dati dentro i sistemi: la carta è diventata un modulo, la riunione una videochiamata, l’archivio un drive condiviso, e la complessità stava nell’integrazione tra applicazioni e nell’adozione degli strumenti da parte delle persone. Si misurava in interfacce, licenze, migrazioni, formazione all’uso del software.

La AI transformation sposta la complessità altrove. Gli strumenti in buona parte ci sono già, e i dati anche, solo che sono sparsi e senza significato condiviso. Quando un modello legge, riassume, collega e propone al posto delle persone, il problema smette di essere come si esegue una procedura dentro un’applicazione e diventa cosa significano le informazioni, chi ha titolo per confermarle e cosa succede quando due fonti dicono cose diverse. La complessità passa dal codice alla semantica, dall’interfaccia alla governance, dall’esecuzione delle operazioni alla responsabilità delle decisioni.

Questo ha una conseguenza pratica che molti sottovalutano. Il lavoro di chi usa il sistema cambia natura: meno inserimento di dati, meno ricerca, molte più approvazioni, correzioni e scelte su informazioni preparate da altri. Una persona che prima compilava il verbale di una riunione ora riceve un verbale già scritto, con i task estratti e collegati alle persone giuste, e il suo compito è dire se è corretto. È un lavoro più leggero e più delicato insieme, perché richiede di sapere cosa si sta approvando.

Un posto per ogni informazione

Centralizzare la conoscenza non significa copiare tutto in un unico contenitore. Un archivio dove finiscono i file di tutti è soltanto un altro silo, più grande. Serve un luogo dove un’informazione diventa un oggetto con un’identità, un autore, una data e una posizione nel progetto: una nota di riunione, un task con un assegnatario e una scadenza, un documento con le sue versioni, un referente con il suo ruolo, un’opportunità con il suo stadio, un’ora di lavoro registrata su un’attività.

La regola che evita più problemi è che ogni dato ha un solo sistema proprietario. Nel Workspace ICONICO clienti, contatti e opportunità restano nel CRM aziendale, e la piattaforma non li duplica: tiene un collegamento e una copia del nome per poterlo mostrare, e quando dal progetto nasce un’opportunità è la piattaforma a scriverla nel CRM, con la nota di progetto e l’attività già collegate. Un’anagrafica duplicata produce, dopo pochi mesi, due verità su chi è il decisore di un cliente, e un modello che le legge entrambe sceglie a caso quale citare.

Il vantaggio più sottovalutato della centralizzazione riguarda le informazioni che oggi non arrivano da nessuna parte. Una decisione presa in una call e mai scritta, un dubbio sollevato in un canale Slack e poi dimenticato, un vincolo annotato in una scheda Jira che nessuno del commerciale leggerà, un’email in cui il cliente cambia una priorità rispondendo a un’altra domanda. E poi il ragionamento che una persona fa con il proprio LLM mentre prepara una proposta o analizza un problema, che spesso contiene il passaggio più utile della giornata e svanisce quando si chiude la finestra. Ognuna di queste informazioni, presa da sola, vale poco. Raccolte nel progetto, con la loro origine, diventano la memoria che l’azienda non aveva mai avuto, e smettono di dipendere da chi era presente quel giorno.

Per ottenere questo vantaggio non sempre serve costruire infrastruttura nuova. In molti casi le fonti esistono già, con i loro connettori, e manca soltanto il punto in cui convergono e un criterio per decidere cosa ne entra. Nel Workspace il controllo degli accessi è applicato al livello più basso possibile, con regole a livello di riga su ognuna delle 28 tabelle del database, per cui la stessa domanda posta da due persone con ruoli diversi restituisce risposte diverse: è la condizione per dare a un modello l’accesso a tutto il progetto senza dover filtrare a mano ogni volta.

Il significato viene prima dei dati

È la parte che quasi tutti saltano, e si capisce: parlare di ontologia in una riunione di direzione fa alzare gli occhi al cielo. Eppure un modello collegato a dati senza tipi e senza relazioni dichiarate ricostruisce da solo il significato delle cose, ogni volta in modo leggermente diverso, e due risposte alla stessa domanda a una settimana di distanza non coincidono. L’ontologia è il punto in cui un’azienda decide cosa significano le sue informazioni, prima che lo decida un modello al suo posto.

Si comincia dai tipi di oggetto. Nel Workspace le note sono appunti, verbali di riunione, decisioni, rischi, insight, feedback, opportunità o conoscenza consolidata, e il tipo cambia il trattamento: una decisione pesa più di un appunto, un rischio genera attenzione, una nota di conoscenza è il risultato di una verifica e non di un’impressione. Anche il vocabolario fa parte dell’ontologia. I tag vengono normalizzati, minuscoli e con il trattino al posto degli spazi, e prima di crearne uno nuovo il sistema lo confronta per somiglianza con quelli esistenti: se esiste già “commerciale-b2b”, la variante “commerciale b2b” non nasce e chi la scrive riceve un avviso, perché il tag è il punto in cui la tassonomia di un’azienda si sfalda più in fretta.

Poi viene lo smistamento, cioè la decisione su dove va un’informazione appena raccolta. Ogni progetto ha un profilo leggibile dal modello: i domini email del cliente e dei partner, le parole chiave e le sigle ricorrenti, le cartelle standard, le convenzioni di nome. Con queste poche righe una mail da un certo dominio, o una registrazione in cui ricorre una sigla, viene attribuita al progetto giusto con un livello di confidenza dichiarato. Quando la confidenza è bassa, o l’informazione potrebbe appartenere a due progetti, il modello non sceglie: la proposta finisce in una coda da smistare e la decisione torna a una persona.

Le eccezioni vanno progettate quanto i casi normali. Un’informazione con cifre economiche viene marcata come riservata e resta visibile solo ai responsabili del progetto. Un’informazione dubbia porta il marcatore da verificare. Un contenuto già importato viene riconosciuto dalla sua origine e non entra una seconda volta. Ognuna di queste regole è una piccola decisione organizzativa scritta in anticipo, e ciascuna toglie al modello un’occasione di improvvisare.

Il caso più delicato sono le collisioni, quando due fonti affermano cose diverse sullo stesso punto. Per gestirle le relazioni tra oggetti sono tipizzate: un collegamento tra due note può essere un riferimento, una conferma, un’integrazione, una divergenza o un consolidamento. Nel progetto pilota due note scritte da persone diverse, a pochi giorni di distanza, si contraddicevano su sei punti. Un sistema ingenuo avrebbe tenuto l’ultima, o le avrebbe fuse in un riassunto. Con le relazioni tipizzate la divergenza diventa un collegamento esplicito e apre un task di verifica assegnato a una persona, che si chiude con una nota di conoscenza: cita entrambe le fonti e dichiara per ciascuna se è stata confermata, integrata o superata su quel punto. Le note originali restano intatte e i loro autori ricevono una notifica.

Le conferme hanno lo stesso trattamento, con il segno opposto. Quando una seconda fonte indipendente dice la stessa cosa della prima, il collegamento di conferma alza il valore di quell’informazione, e chi interroga il progetto sa che quel fatto è sostenuto da due origini e non da una. È il modo in cui la conoscenza di un team acquista peso nel tempo, invece di accumularsi tutta allo stesso livello.

Arricchire i dati e renderli percorribili

Un’informazione raccolta e smistata è ancora un oggetto isolato. Diventa conoscenza quando è collegata a ciò che la circonda: le persone che cita, l’opportunità a cui si riferisce, il documento che commenta, il task che ne è nato, le ore spese per produrla.

L’arricchimento avviene su più piani. Il primo è esplicito: nelle note e nei task gli oggetti si citano con le menzioni, scrivendo @ seguito dal nome di una persona, di un documento o di un’opportunità, e ogni menzione diventa un collegamento. Il secondo è automatico: il sistema rianalizza i testi, riconosce nomi di referenti, opportunità e documenti già presenti nel progetto e genera collegamenti suggeriti, che però restano suggerimenti finché qualcuno non li conferma, e se vengono rifiutati non vengono ricreati. Il terzo è operativo: un task porta con sé la nota da cui è nato, un’ora registrata porta con sé il task o la riunione a cui si riferisce, un’opportunità porta con sé la nota che l’ha fatta emergere.

Il risultato è un grafo della conoscenza in cui i nodi sono note, task, documenti, referenti, opportunità, membri del team, cartelle, tag e organizzazioni, e gli archi hanno un’origine dichiarata: strutturale, da menzione, manuale o automatica. Alcuni archi hanno anche un peso, come le ore che una persona ha dedicato a un’attività, così la mappa mostra dove si concentra davvero il lavoro e non solo cosa è collegato a cosa.

Rendere la conoscenza percorribile vuol dire offrire più strade per arrivare alla stessa informazione. Dalla mappa del progetto si parte da un nodo e se ne esplora il vicinato fino a tre passi di distanza. Da ogni oggetto si vedono i collegamenti in uscita e quelli in entrata, cioè chi lo cita. La timeline restituisce la sequenza degli eventi, la ricerca attraversa note, task, documenti, testo estratto e tag di tutti i progetti leggibili. E il modello usa le stesse strade: prima di una riunione con un referente prepara il brief partendo dal suo nodo, raccogliendo le note recenti che lo citano, le opportunità aperte, i task in scadenza e le divergenze ancora da chiudere. Alla domanda “cosa sappiamo di questo cliente” il sistema risponde con un percorso nel grafo che parte dal nodo del cliente.

Quale modello per quali dati

Con la conoscenza centralizzata, strutturata e collegata, la scelta del modello diventa una decisione molto più semplice e molto meno rischiosa, perché il modello non contiene niente. Il cuore del sistema è il livello di conoscenza con il suo server di accesso: il modello è un lettore e un proponente, e si può sostituire senza perdere nulla. Il mio assistente personale si chiama Gideon, come l’intelligenza artificiale che in The Flash mostra a Barry Allen i giornali del futuro. Il mio si accontenta di sapere cosa abbiamo deciso martedì, e se domani cambiassi il modello che lo fa funzionare continuerebbe a saperlo, perché quella memoria non sta dentro di lui.

Il collegamento passa oggi quasi sempre da un server MCP, il protocollo che i principali assistenti usano per parlare con strumenti esterni. Il server del Workspace gira su un dominio proprio, con autenticazione OAuth, ed espone oltre sessanta strumenti: leggere e scrivere note, aprire task, caricare documenti, registrare il tempo di una riunione, interrogare il grafo di un progetto. Lo stesso server serve qualsiasi client compatibile, e il principio da tenere fermo è che il modello opera sempre con i permessi reali della persona che lo sta usando, mai con un’utenza tecnica onnipotente.

Da qui le strade sono sostanzialmente due, e spesso convivono. La prima sono i client dei prodotti noti, Claude, ChatGPT e gli altri assistenti commerciali: offrono i modelli più capaci, connettori già pronti verso posta, calendari e archivi, e un’esperienza che le persone conoscono. Il prezzo è che i dati letti dal modello transitano sui server del fornitore, con le garanzie contrattuali del piano sottoscritto. La seconda sono i client con AI locale, che eseguono modelli aperti su macchine aziendali o su server interni: i dati non escono dal perimetro dell’azienda, i costi sono prevedibili, e in cambio si accettano modelli meno potenti sui compiti più complessi, più lavoro di manutenzione e un’infrastruttura da gestire.

La scelta si fa per classe di dati, e può cambiare nel tempo. Un modo pratico è classificare le informazioni del progetto su tre livelli: dati che possono uscire (ricerche pubbliche, bozze di contenuti, analisi di mercato), dati interni che possono uscire solo verso fornitori con garanzie contrattuali adeguate, dati che non devono uscire per nessun motivo, come informazioni economiche riservate, dati personali sensibili o segreti industriali. Ai primi due livelli si applica il modello più capace disponibile, al terzo un modello locale, oppure un passaggio di anonimizzazione prima dell’invio. Nel Workspace questa classificazione è già parzialmente scritta nell’ontologia, perché le note e i documenti riservati sono marcati come tali, e quel marcatore diventa il criterio naturale per decidere quali oggetti affidare a un client locale.

Il punto fermo, in entrambi i casi, è che il cuore resta centralizzato. Che il modello giri in un data center americano o su un server nel seminterrato, legge la stessa conoscenza, con gli stessi permessi, attraverso lo stesso server, e propone modifiche che passano dalla stessa approvazione. Cambiare fornitore, o affiancarne due, diventa una decisione di costo e di riservatezza, senza progetti di migrazione.

Skill condivise in un catalogo unico

Una skill è il modo in cui si insegna a un assistente a fare una cosa sempre nello stesso modo: istruzioni in testo, riferimenti da consultare al momento giusto, script che verificano ciò che può essere verificato. Il paragone più vicino è il manuale operativo di un nuovo collaboratore, con la differenza che questo manuale viene letto davvero, ogni volta.

Il loro valore in un team va oltre l’efficienza del singolo. Quando dieci persone usano un LLM senza skill condivise, ciascuno scrive le note a modo suo, chiama le cose con nomi diversi, sceglie tag diversi, struttura le proposte con sezioni diverse, e il modello amplifica queste differenze invece di ridurle. Con le skill condivise il modello di ciascuno parla la stessa lingua: usa gli stessi tipi di nota, propone gli stessi formati, rispetta le stesse regole di stile, chiama un rischio “rischio” e una decisione “decisione”. Le skill sono il veicolo con cui l’ontologia arriva dentro ogni conversazione, senza che nessuno debba ricordarla.

Nel Workspace le skill sono tre e lavorano insieme. La skill di raccolta legge le fonti, smista per progetto, propone note, task, ore, referenti e collegamenti, prepara i brief, gestisce le verifiche. La skill documentale produce i documenti per i clienti da un motore unico: copertina, intestazione, palette e coordinate aziendali sono fisse, cambiano solo contenuti e firma di chi redige, e un controllo di stile automatico intercetta i tic di scrittura prima della consegna. Su questa si appoggia la skill commerciale, che segue una proposta dal brief all’opportunità nel progetto fino al preventivo nel CRM, con uno script che verifica al centesimo che documento e preventivo coincidano.

Conta molto anche il luogo dove le skill vengono scritte. Se vivono nei computer delle persone, dopo tre mesi ne esistono cinque versioni leggermente diverse, ognuna con le sue correzioni locali, e il linguaggio comune si disgrega dalla periferia. Per questo nel Workspace le skill stanno in un catalogo unico, dentro la piattaforma: ogni skill esiste in una sola versione corrente, con le note di rilascio, i connettori di cui ha bisogno, la versione minima del server, le altre skill da cui dipende e uno stato che la rende obbligatoria o consigliata. I sorgenti sono archiviati file per file con la loro impronta crittografica, e il pacchetto che ogni collaboratore scarica viene verificato contro quelle impronte.

Il catalogo rende le skill anche dinamiche nella struttura. Una skill ben scritta separa le regole dai dati: non contiene l’elenco dei tag del progetto né i domini del cliente, li legge dal Workspace nel momento in cui serve, così l’ontologia evolve senza dover riscrivere le procedure. Quando cambia una regola, si pubblica una nuova versione nel catalogo e ogni collaboratore la riceve con le note di rilascio. Il motore documentale è stato riscritto in Python con la sola libreria standard proprio per non legare le skill a un solo assistente: lo stesso pacchetto gira su qualsiasi piattaforma che esegua Python, compresi i client con AI locale.

La lezione tecnica più utile riguarda il confine tra quello che decide il modello e quello che decide il codice. Tutto ciò che si può verificare in modo deterministico va tolto al giudizio del modello. Prima di essere inviato, ogni pacchetto di proposte attraversa un validatore con nove regole. Il preventivo viene ricontrollato da uno script. Il documento passa da una verifica della resa in PDF. Al modello resta il lavoro che sa fare meglio, leggere, collegare e proporre, e il codice garantisce che il risultato rispetti le regole.

 

Il modello propone, le persone firmano

Il livello che tiene insieme tutti gli altri è una regola di governo molto semplice: niente entra nella memoria del progetto senza che una persona lo approvi. Quando il modello esegue la raccolta settimanale non scrive nulla, prepara un pacchetto di proposte. Ogni proposta dichiara l’operazione (crea una nota, apri un task, registra un’ora, collega due oggetti, apri una verifica), il progetto di destinazione, un estratto della fonte di massimo trecento caratteri con data e autore, un livello di confidenza e, quando serve, un marcatore che la segnala come da verificare o come contenuto economico riservato.

Il responsabile apre il pacchetto, approva, corregge o rifiuta. L’applicazione avviene con i suoi permessi, e se una proposta dipende da un’altra (un collegamento tra due note che nascono nello stesso pacchetto) il sistema le applica nell’ordine giusto. Una proposta rifiutata viene ricordata insieme alla sua origine e non torna alla raccolta successiva, quindi il sistema impara cosa non serve senza bisogno di istruzioni più lunghe.

La ragione di questa rigidità è pratica. Una base di conoscenza inquinata da un modello troppo zelante è peggio di una base vuota, perché nessuno sa più quali informazioni sono state verificate da una persona e quali sono state dedotte. Con le proposte approvate ogni oggetto del progetto ha un’origine e un responsabile, e se tra sei mesi qualcuno chiede perché è stata presa una certa decisione, la risposta porta a una riunione, a una persona, a una data.

Da dove cominciare

Chi parte da zero dovrebbe cominciare dalla carta e lasciare gli strumenti per dopo. Prima l’inventario delle informazioni che il team produce davvero in una settimana normale, comprese quelle che oggi si perdono nelle chat, nelle call e nelle conversazioni con l’LLM, e del sistema che ne è proprietario. Poi l’ontologia minima: quali tipi di oggetti esistono, quali relazioni servono, chi decide sulle divergenze, come si chiamano i tag. Poi la classificazione dei dati, che dice quali modelli possono leggerli. Infine i connettori e le skill, partendo dalle procedure che il team ripete più spesso e che oggi dipendono dalla memoria di una persona.

La parte tecnica, in molti casi, è la più rapida. Le fonti esistono già, hanno i loro connettori, e spesso basta farle convergere in un punto con un criterio di ingresso. Il lavoro più lungo è organizzativo: mettersi d’accordo su cosa conta come decisione, su chi può chiudere una divergenza, su quali dati non devono uscire dall’azienda e su quali tag hanno diritto di esistere è una conversazione che in molte aziende non è mai stata fatta. Scrivere nero su bianco quali sono gli oggetti della conoscenza di un team, e chi ne risponde, è il primo pezzo di uno spazio intelligente, e viene molto prima della scelta del modello da collegare.

 

AI & GENAI, TECH & BUSINESS

Il gemello cognitivo lo addestri tu

Alla terza volta esce giusta. L’hai corretto due volte, gli hai detto che quel cliente vuole una cosa e non un’altra, che in quel contesto non si apre mai dal prezzo, che una proposta senza un certo paragrafo non regge. Al terzo tentativo la risposta è esattamente quella che avresti scritto tu, e ti senti efficiente. In quell’istante qualcosa è passato da te al modello, e non era la risposta.

Quello che è passato è la correzione, il motivo per cui hai scartato le prime due, il gusto con cui hai riconosciuto quella buona, la riga che con un cliente non superi. Ci hai messo quindici anni a costruirla, l’hai consegnata in tre scambi.

Il mestiere passa nella correzione

Il modello non impara dalla tua risposta giusta, impara dai tuoi no. La distanza tra quello che ha prodotto e quello che gli hai fatto riscrivere è il segnale più prezioso che gli puoi dare, perché è lì che vive il giudizio, e il giudizio è la parte di te che non trovi scritta da nessuna parte, quella che negli anni ha smesso di essere una regola ed è diventata un istinto.

Sui gemelli digitali ho scritto altrove, pensando ad avatar e identità sintetiche. Questo gemello è più intimo: riproduce un criterio. Chiamiamolo gemello cognitivo. Il modello pubblico ne costruisce uno del tuo modo di decidere a partire dall’attrito, dalle volte in cui gli dici che ha sbagliato e soprattutto perché. A pesare è la sequenza di scelte che ti ha portato a quel documento e non a un altro, la cosa che ti chiede di rendere esplicita a ogni passaggio. I documenti in sé li ha già visti a milioni.

Un clone che non dimentica niente

Un collaboratore giovane impara guardandoti, poi dimentica qualcosa, è uno solo, e in qualche modo ti deve qualcosa: lo stipendio, la riconoscenza, gli anni che gli stai regalando. Il modello non dimentica niente e si copia all’infinito, senza doverti nulla. Nel momento in cui la tua correzione risolve un problema che hanno in milioni, in milioni ricevono il tuo modo di farlo senza sapere che è tuo, e senza che a te torni indietro niente. Un tempo il tuo modo di trattare quel cliente valeva perché lo avevi solo tu, e chi lo voleva veniva da te. Adesso lo stesso modo, una volta entrato nel modello, esce dal rubinetto per chiunque digiti la domanda giusta, allo stesso prezzo dell’abbonamento.

La reciprocità che regge l’apprendistato umano qui salta. È il punto dove di solito il ragionamento si ferma, con un senso di furto e un’aria da resa.

Mentre lo istruisci, ti disalleni

C’è una metà che quasi nessuno dice. Lo stesso gesto che manda fuori il tuo metodo lo consuma dentro. Smetti di scrivere la proposta e correggi quella che ha scritto lui, smetti di tenere in mano il criterio e ti riduci a sorvegliarlo, e ogni volta che deleghi la parte difficile perché tanto poi la sistemi, quella parte in te si assottiglia di un grado.

Tra cinque anni la macchina ha il tuo modo di fare e tu hai perso il tono muscolare per rifarlo senza. Il gemello cognitivo si affina mentre l’originale si spegne. Non è un furto, è un’atrofia. Di questo assottigliamento, del debito cognitivo che si accumula un riassunto accettato alla volta, ho scritto pensando alla metacognizione, all’esercizio di guardare come si pensa proprio mentre si usa il modello. Il segnale è facile da riconoscere: quando ti accorgi che davanti a un foglio bianco, con il modello chiuso, non partiresti più con la sicurezza che avevi due anni fa.

Trattenere tutto è una prigione

La risposta istintiva a tutto questo è nascondere. Tenersi il metodo, non darlo in pasto, lavorare a fari spenti. Strada chiusa, per due motivi. Il primo è che il modello rende peggio esattamente dove ti serve di più, quindi o affami lo strumento o nutri il gemello, e nel mezzo non c’è granché da abitare. Il secondo è più scomodo: l’accumulo come difesa è a sua volta una trappola, i quindici anni di sapere implicito che ti proteggono sono anche quindici anni che non riesci a scalare, a trasferire, a lasciare andare senza sentirti scoperto. È la ragione per cui certi professionisti bravissimi restano piccoli a vita: tutto passa dalle loro mani perché il valore è nelle loro mani, e le mani sono due.

Custodire tutto quello che sai è una prigione con una bella vista. Che prendano è dato, avviene comunque. Quello su cui hai voce sono le condizioni in cui avviene la presa.

La domanda è dove gira il calcolo

Quelle condizioni si giocano su una parola che suona burocratica e invece è molto concreta: giurisdizione. La domanda utile riguarda dove avviene il calcolo, con quali termini, e se quei termini puoi revocarli. Il contenuto che riveli pesa meno del luogo in cui lo riveli.

Sull’accesso ai modelli di frontiera l’ho già chiamato permesso più che proprietà, guardando a un governo capace di spegnere un modello dall’oggi al domani. La stessa logica vale un piano più in basso, sul tuo mestiere. Un’impresa cognitiva che gira sull’infrastruttura di un altro è cognitiva solo nel nome, affitta la stanza in cui si conia la sua stessa intelligenza, e paga l’affitto in giudizio. Un affitto che sale da solo, perché più il modello diventa capace più la tua operatività dipende da lui, e la dipendenza non è mai un buon posto da cui trattare le condizioni.

La sovranità digitale riguarda il contenitore, non l’ansia sul contenuto. Far girare il modello dove le regole le metti tu è una forma di questo, però il principio viene prima dello strumento: chi decide la giurisdizione del calcolo decide anche chi, dentro l’organizzazione, può ancora dire di no.

Il gemello cognitivo lo costruiranno comunque, quella parte non è in discussione. Quello che decidi tu è se la stanza dove lo costruiscono è tua o presa in affitto, e lo decidi adesso, mentre il metodo è ancora tutto dentro di te e non ancora tutto dentro la macchina. Tra qualche mese la proporzione si sposta, e si sposta da sola.

AI & GENAI, TECH & BUSINESS

Model router: come funziona il middleware che smista le richieste AI

Tra l’applicazione e i modelli è comparsa una casella che diciotto mesi fa non esisteva. Si chiama model router, intercetta ogni richiesta e decide quale modello deve rispondere prima che la richiesta parta, e nel giro di pochi mesi ha sviluppato un mercato suo, con prodotti commerciali, progetti open source e paper accademici che se la contendono.

Il 2 luglio scrivevo che il router viene prima del modello, riprendendo un’osservazione di Tomasz Tunguz: la logica di instradamento, non il modello scelto per ultimo, determina costi, latenza e chi resta padrone dell’infrastruttura. Quel pezzo era la tesi. Questo è la mappa: come quella casella si costruisce dentro, chi la vende già pronta, e il vincolo che quasi nessuno disegna nel diagramma.

Regole scritte a mano, regole imparate

Le architetture di model router in circolazione si riducono a quattro famiglie, e conoscerle serve perché ognuna sposta il compromesso tra costo, latenza e qualità in un punto diverso.

La più semplice è quella euristica: regole fisse, parole chiave, lunghezza del prompt. Se la richiesta contiene una query SQL, va dritta a un modello da codice, senza che nessun classificatore si accenda. Costa niente e si spiega in una riga, e si rompe appena il traffico esce dai casi previsti da chi ha scritto le regole.

Il gradino successivo è il router appreso, un classificatore leggero, di solito su embedding, che predice quale modello renderà meglio su quella richiesta in base a valutazioni storiche. Qui la qualità del model router dipende interamente dalla qualità dei dati di valutazione con cui è stato addestrato, e questa dipendenza pesa più di qualunque scelta di algoritmo.

Poi ci sono le cascate, che rovesciano la logica: si prova prima il modello economico, un validatore controlla la risposta, e solo se il controllo fallisce la richiesta sale al modello più potente. E infine gli ensemble, dove più modelli lavorano in parallelo sulla stessa richiesta e un giudice algoritmico sintetizza o sceglie. La cascata ottimizza il costo accettando qualche giro in più di latenza, l’ensemble ottimizza la qualità accettando di pagare ogni risposta tre o quattro volte.

Il model router diventa un prodotto da scaffale

Fino a poco fa questa casella la scrivevi in casa. Adesso la compri. OpenRouter ha portato in produzione a giugno Fusion, la versione a scaffale dell’ensemble: la tua richiesta va a un pannello di modelli in parallelo e un giudice fonde le risposte. Sul benchmark di deep research DRACO di Perplexity, un pannello economico composto da Gemini 3 Flash, Kimi K2.6 e DeepSeek V4 Pro ha segnato 64,7%, sopra GPT-5.5 da solo (60,0%) e Opus 4.8 da solo (58,8%), a circa metà del costo della configurazione di punta. Il dato che trovo più istruttivo è un altro, sepolto nello stesso annuncio: fondere Opus 4.8 con sé stesso alza il punteggio da 58,8 a 65,5. È la sintesi a produrre valore, non solo la diversità dei modelli.

Sul versante dei router appresi, Not Diamond vende l’addestramento su misura: carichi i tuoi prompt, i modelli provati e i punteggi delle tue valutazioni, e ne esce un router calibrato sui tuoi criteri, comprese le regole di formattazione o le convenzioni di codice che nessun benchmark pubblico misura. Il prodotto, in pratica, è la trasformazione dei tuoi dati di valutazione in una politica di instradamento.

La via che resta in casa

Chi non vuole un intermediario tra sé e i modelli, per latenza o per riservatezza dei dati, ha alternative open source che nell’ultimo semestre sono maturate in fretta.

NadirClaw è un proxy locale compatibile con l’API OpenAI che parte da un’osservazione empirica: nelle sessioni di sviluppo assistito, il 60-70% dei prompt sono operazioni semplici, letture di file, formattazioni, domande brevi, e non hanno bisogno di un modello premium. Un classificatore su embedding decide in una decina di millisecondi, un motore di ottimizzazione sfronda schemi di strumenti gonfi e array ridondanti prima dell’invio, tagliando il peso in token dal 30 al 70%, e sui benchmark RouterArena il profilo a cascata predefinito segna 0,7358 riducendo la spesa API fino al 70%. Gira sulla tua macchina, con le tue chiavi, e nessuna piattaforma di mezzo può cambiarti le condizioni.

Il fronte accademico spinge un passo oltre. Agent-as-a-Router, il paper dietro il framework ACRouter, parte da una diagnosi precisa: i router statici falliscono per deficit di informazione, decidono una volta e non imparano mai dal risultato. La risposta è un ciclo continuo in cui un orchestratore leggero instrada la richiesta usando lo storico di prestazioni conservato in una memoria interna, e un verificatore valuta l’esito con metriche oggettive, i test unitari sul codice generato per esempio, riscrivendo il risultato nella memoria come esperienza. Il router accumula esperienza fondata sull’esecuzione reale, ed è la stessa architettura del ciclo notturno che descrivevo nel pezzo di luglio, formalizzata e messa alla prova contro modelli di frontiera.

Per chi lavora con l’inferenza dentro il perimetro aziendale, ed è il terreno su cui costruiamo LocalAI, questa famiglia di strumenti è quella che conta: il routing self-hosted è ciò che rende sostenibile l’ibrido, i modelli locali per la maggioranza del traffico, il cloud per ciò che lo giustifica davvero.

Funziona dove il risultato si può misurare

Tutte queste architetture, dalla cascata al ciclo di ACRouter, si reggono su un presupposto che i diagrammi non mostrano: che esista un segnale oggettivo per dire se una risposta è buona. Il codice passa i test o non li passa, il JSON rispetta lo schema o non lo rispetta, la stringa si estrae o no. Dove il segnale è binario, il validatore della cascata sa quando scalare, il verificatore sa cosa scrivere in memoria, e il router impara.

Dove il segnale non c’è, tutto l’impianto si affloscia. Valutare un testo di marketing, un brainstorming aperto, una sintesi il cui pregio è il taglio e non la correttezza: su questi compiti la verifica automatica è debole, e un model router che non sa distinguere una risposta buona da una mediocre instrada alla cieca, con in più il pedaggio di latenza che le catene a cascata e i cicli di validazione si portano dietro per costruzione. Il router aggiunge un premio di complessità allo stack, e non ripara la logica applicativa rotta o il prompting fatto male: sposta i compiti giusti sui modelli giusti, a condizione che qualcuno gli abbia insegnato a riconoscerli.

Il registro dei prompt vale più del modello

Resta la parte che riguarda chi decide, non chi implementa. Il panorama dei modelli cambia ogni settimana, i prezzi per token continuano a scendere, e qualunque scelta di modello fatta oggi sarà rivedibile tra un trimestre. Le due cose che invece restano, e si apprezzano nel tempo, sono i dataset di valutazione interni e lo storico dei prompt con i loro esiti. Sono il carburante di ogni model router appreso, di ogni cascata calibrata, di ogni memoria alla ACRouter, e nessun fornitore può venderteli perché descrivono il tuo lavoro, non il suo.

L’avevo scritto parlando del vantaggio che si accumula in memoria, e il routing ne è la dimostrazione infrastrutturale: un’organizzazione che non registra cosa ha chiesto ai modelli e come è andata non potrà mai instradare bene, con nessuno strumento, comprato o costruito. Il processo di valutazione viene prima del router, come il router viene prima del modello. E mentre l’AI bill shock spinge tutti a cercare la casella magica che abbatte il conto, i dati che servirebbero ad addestrare il vostro model router si stanno raccogliendo adesso, oppure non si stanno raccogliendo affatto. Chi li registra oggi, tra un anno instraderà sulla propria esperienza. Gli altri affitteranno quella di qualcun altro.

Riferimenti: OpenRouter, Surpassing Frontier Performance with Fusion; Zhou et al., Agent-as-a-Router: Agentic Model Routing for Coding Tasks (arXiv); NadirClaw su GitHub; Not Diamond.

AI & GENAI, TECH & BUSINESS

AI bill shock: la bolletta dei token è arrivata, come previsto

Il conto è arrivato, e ha pure un nome. Da mesi, tra le chiamate con i clienti e i pezzi che scrivo, ripeto la stessa cosa: il costo dei token non è un dettaglio da smanettoni, è la prossima voce che finisce sul tavolo del CFO. A marzo lo scrivevo su AI4Business, parlando di governo economico dei token come disciplina ancora da costruire. A maggio, qui sul blog, mettevo per iscritto che sarebbe arrivato sotto forma di budget esplosi a fine mese.

Questa settimana CorCom lo ha chiamato AI bill shock, riprendendo un’analisi di Analysys Mason: la spesa a consumo per modelli generativi, Api e agenti autonomi rende i budget aziendali sempre meno prevedibili, al punto da riportare sul tavolo di molti CIO l’idea di possedere un pezzo della propria infrastruttura invece di affittarla sempre. I numeri sotto contano più del titolo. Il budget è solo la parte più visibile: sotto ci sono i dati, la compliance, il controllo dell’infrastruttura su cui gira la tua azienda.

300 aziende, un balzo del 500%

Tra aprile e maggio circa 300 aziende hanno sollevato la questione dei costi legati ai token durante le chiamate agli investitori sui risultati trimestrali, contro le 93 dello stesso periodo dell’anno precedente. Lo racconta AI4Business citando Paul Roetzer e Mike Kaput del Marketing AI Institute. La Royal Bank of Canada ha visto il proprio consumo di token salire del 500% in sei mesi. Cisco descrive i propri volumi come fuori da ogni norma conosciuta.

Amazon, Walmart, Uber, Cisco e Meta, secondo quanto riportato dal Financial Times e ripreso sempre da AI4Business, hanno già introdotto tetti di spesa o indicazioni più severe su quando vale davvero la pena accendere un modello. Uber ha fissato un tetto di 1.500 dollari al mese per dipendente dopo aver esaurito, già ad aprile, l’intero budget AI previsto per il 2026. Amazon ha spento la classifica interna che misurava quanto i dipendenti usassero l’AI, dopo aver scoperto che alcuni ingegneri facevano girare bot autonomi solo per scalare la graduatoria: è il fenomeno che va sotto il nome di tokenmaxxing, la corsa alla vanità mascherata da adozione.

A Workato, azienda da 1.300 dipendenti, la spesa è aumentata di sette volte in un solo giorno quando Anthropic ha spostato l’azienda su un pricing basato sui token, a maggio. Goldman Sachs Research stima che l’uso degli agenti possa moltiplicare per 24 il consumo di token entro il 2030. E sul mercato aperto dei modelli, secondo i dati di OpenRouter ripresi dal Financial Times, i modelli cinesi hanno già superato quelli americani per consumo di token: quando il prezzo diventa il primo criterio di scelta, a vincere è chi costa meno, non chi segna il punteggio più alto sui benchmark.

Il token non misura il lavoro fatto

Più del volume, a ingannare è la natura della metrica. I fornitori fanno pagare i token di output da due a cinque volte più di quelli di input, perché generare una risposta costa computazionalmente più che leggerla: il modello prevede una parola alla volta, in sequenza, mentre l’input lo processa in un solo passaggio. Due flussi di lavoro che sembrano identici per volume possono avere costi molto diversi a seconda di quanto testo producono rispetto a quanto ne ricevono, e quasi nessuna azienda, quando firma il contratto, ci pensa davvero. Un prompt di 1.500 parole, quasi 2mila token, che produce una sintesi di 600 parole, circa 800 token, costa già un paio di centesimi con un modello come Claude 3.5 Sonnet: sembra nulla, finché non lo moltiplichi per centinaia di richieste al giorno e per ogni team che nel frattempo ha acceso un proprio agente senza dirlo a nessuno.

Gli agenti aggravano la cosa, perché a ogni passaggio ritrasmettono l’intero contesto della conversazione: alla decima fase di un compito, il modello rilegge integralmente le prime nove. AI4Business fa un esempio concreto, quello di un assistente per il servizio clienti che accede a una base di conoscenza di 20mila token: per mille richieste al giorno, genera 20 milioni di token quotidiani solo per rileggere sempre gli stessi dati, circa 60 dollari al giorno spesi prima ancora di rispondere a un cliente vero. Se l’agente si blocca in un loop, o richiama più volte lo stesso strumento, il conto sale prima che qualcuno se ne accorga.

L’AI bill shock non è un problema di cassa

Affidare l’inferenza a un fornitore esterno porta con sé più di un conto a consumo: la sua politica dei prezzi, i suoi limiti di utilizzo, le sue scelte su dove vivono i tuoi dati, la sua libertà di cambiare le regole senza preavviso. Il pricing può cambiare le regole da un mese all’altro, come è successo a Workato quando Anthropic l’ha spostata su un modello a consumo. Un fornitore può introdurre un tetto di utilizzo che scopri solo quando lo tocchi, a metà di una sessione di lavoro, come raccontano diversi utenti citati da AI4Business. Un governo può spegnere l’accesso a un modello, come abbiamo visto succedere quest’anno. E quando arriva un audit di conformità, la domanda su dove sia passato un dato aziendale durante l’inferenza, su quale server, sotto quale giurisdizione, spesso non ha una risposta scritta da nessuna parte.

Bain, in un sondaggio su 951 aziende pubblicato a giugno, trova che quasi il 40% di chi ha misurato i risparmi da AI è rimasto sotto il 10%, contro un obiettivo dichiarato dell’11-20%. Michael Heric, uno degli autori della ricerca, spiega che per molte aziende il business case si ferma alla spesa in token e non arriva mai a contare i costi di data engineering, di governance, di conformità che le girano intorno. Il 90%, nonostante tutto, aumenta comunque il budget per l’anno prossimo, prova che nessuno ha ancora imparato a misurare il ritorno dell’AI con lo stesso rigore con cui ne misura il costo.

LocalAI lavora esattamente in questa direzione: porta l’inferenza dentro il perimetro dell’azienda invece di affittarla ogni mese da qualcun altro. I costi non spariscono: cambia chi li governa. Sai dove vivono i dati, sai quanto costa davvero un carico di lavoro perché lo possiedi, e nessuno può cambiarti il prezzo o il tetto di utilizzo a metà mese.

Dall’opex che non controlli al capex che scegli

Analysys Mason legge lo spostamento come l’ennesimo giro di un ciclo che l’informatica ha già visto: dal mainframe centralizzato ai minicomputer distribuiti, dal PC in rete al cloud che ricentralizza tutto, e ora l’AI che riapre la stessa domanda. Comprare calcolo come servizio o possederne una parte? Per chi ha volumi di inferenza stabili, la risposta pratica passa quasi sempre dall’ibrido: hardware proprio per i compiti che non hanno bisogno di un modello di frontiera, server dedicati o cloud privato per il resto, il cloud pubblico riservato a ciò che lo giustifica davvero.

Il TCO a tre anni tra cloud e on-premise, calcolato sui prezzi reali di Claude, GPT, Gemini e DeepSeek, conferma la stessa cosa: nella maggior parte degli scenari aziendali italiani l’on-premise vince con margine quando i volumi sono prevedibili, mentre il cloud resta la scelta giusta per i picchi occasionali e per chi parte da zero. La maggior parte del traffico di un’azienda, del resto, non ha bisogno del modello più caro: ha bisogno di un sistema che decida bene dove instradarlo. Quella logica di instradamento, non il modello scelto per ultimo, è ciò che decide chi resta padrone della propria infrastruttura.

Decide il board, non il reparto IT

Il sondaggio di Bain lo conferma da un altro lato: le aziende che centrano i risparmi attesi sono quelle che hanno trattato l’accesso ai dati, la governance e il ridisegno dei processi come materia da consiglio di amministrazione, non da reparto IT. Vale lo stesso per il bill shock. Un alert di budget o un tetto di spesa imposto dall’alto sposta il sintomo, non la causa.

La prima domanda, in questi casi, non riguarda mai il modello. Riguarda dove vivono i dati, chi decide quanto vale un’ora di inferenza, cosa succede se domani il fornitore cambia le regole: non cambia molto se l’azienda ha cinquanta o cinquemila dipendenti, cambia solo quanto in fretta un budget fuori controllo diventa un problema di tutti, non solo di chi ha acceso l’ultimo agente.

La bolletta continuerà a salire, per tutti. La differenza, da qui in avanti, la fa chi ha già deciso come governarla e chi la scoprirà solo a budget già bruciato.

Fonti: CorCom su Analysys Mason; AI4Business, “La crisi dei token che spaventa i budget aziendali”; AI4Business, “AI, le aziende frenano”; Bain & Company, Automation and AI Pathfinder Survey 2026.

AI & GENAI, TECH & BUSINESS

Il router prima del modello

Il 1° luglio Tomasz Tunguz di Theory Ventures ha scritto una cosa semplice che quasi nessuno applica: la maggior parte dei team che costruisce agenti sceglie il modello per primo. Sbaglia ordine, e lo sbaglia sistematicamente, perché il modello è la decisione più visibile e quindi quella su cui si concentra tutta l’attenzione, mentre il pezzo che davvero determina costo e latenza resta invisibile: il router, cioè il codice che decide chi risponde a ogni singola richiesta.

Tunguz lo racconta riferendosi al modo in cui Coinbase ha dimezzato la spesa in AI mentre il consumo di token cresceva, non frenando gli ingegneri con alert di budget ma cambiando i default di instradamento. È un’osservazione operativa, non una teoria, e tocca qualcosa che seguo da mesi lavorando con LocalAI: la sovranità computazionale si gioca sull’architettura, molto più che sulla scelta del modello.

Tre problemi diversi, non uno

Classificatore, router e selettore vengono trattati come sinonimi, e non lo sono. Il classificatore riconosce l’intento: trasforma una richiesta grezza dell’utente in un’operazione concreta, riassumere un repository, scrivere una risposta, lanciare una migrazione. Il router legge quell’etichetta insieme a poche feature, complessità, dimensione del contesto, storico di successo, e decide su quale livello far girare l’operazione. Il selettore, infine, sceglie il modello più economico dentro quel livello che rispetta una soglia di confidenza.

Confonderli è comodo mentre si scrive il primo prototipo, e costa caro dopo: la scelta del modello finisce sepolta dentro il prompt, e diventa impossibile testare due modelli diversi sulla stessa operazione senza riscrivere mezzo sistema. È lo stesso errore di livello che ho descritto parlando dello stack verticale dell’AI: confondere i piani porta a decisioni prese al piano sbagliato.

Il locale è gratis, l’asincrono è economico, il tempo reale costa

E infatti è questa la parte che mi ha fatto fermare a rileggere. Il calcolo locale ha un costo marginale prossimo allo zero, il batch asincrono costa due ordini di grandezza meno dell’inferenza in tempo reale, e la parte di lavoro che ha davvero bisogno di una risposta immediata è sorprendentemente piccola, una volta che il sistema può accodare.

Una bozza di risposta, un riassunto di repository, un memo di due diligence, la valutazione notturna di un batch di tracce: nessuno di questi compiti pretende un secondo di risposta. Pretende di essere fatto bene, non subito.

Ho visto questa stessa dinamica dentro LocalAI, dove la maggioranza del traffico non tecnico regge tranquillamente su modelli piccoli fatti girare in locale, con il cloud che entra in scena solo quando il compito lo richiede davvero. Non è un compromesso al ribasso, è disegno.

Un ciclo che impara mentre dorme

Ecco, e qui il design descritto da Tunguz aggiunge un doppio ritmo di feedback che vale la pena isolare. Un predittore sincrono annota ogni richiesta in ingresso con cinque segnali di rischio, dal contesto di repository mancante alle catene di dipendenze troppo lunghe, fino alle scritture che possono avere conseguenze pesanti se sbagliate, e intercetta così i compiti già noti come difficili prima che falliscano.

Poi, ogni notte, un valutatore batch rilegge le tracce del giorno e aggiorna i pesi del router, mentre il costo di quella valutazione resta vicino allo zero perché gira anch’esso in modalità asincrona. Ed è lì che il sistema scopre i modi di fallire che il predittore non aveva ancora imparato a riconoscere.

Mi sembra la versione infrastrutturale di qualcosa che scrivo da tempo a proposito del vantaggio che un’organizzazione accumula in memoria, non in modello: un sistema che non ha un meccanismo per far rientrare l’esperienza di ieri nelle decisioni di oggi accumula lo stesso tipo di debito, che si parli di persone o di router. L’ho scritto anche a proposito del tokenmaxxing: quel che resta dopo la spesa pesa più del numero speso, che si tratti di token o di traffico instradato.

Da dove si comincia davvero

Nei progetti dove entro a lavorare sull’adozione dell’AI, il primo intervento quasi mai tocca il modello. Tocca l’inventario dei segnali di fallimento: quali richieste arrivano senza contesto sufficiente, quali toccano dati sensibili, quali scritture, se sbagliate, costano care da correggere. Prima si rende visibile quel rischio, poi si decide dove instradarlo.

È un lavoro lento e poco fotogenico rispetto a scegliere l’ultimo modello uscito, e proprio per questo tende a restare indietro nella lista delle priorità. Ma un router costruito senza quella mappa dei rischi impara a fatica, perché non sa cosa sta effettivamente evitando di rompere. Il ciclo notturno di cui scrive Tunguz funziona solo se qualcuno, all’inizio, ha scritto a mano la prima versione grezza di quella mappa.

Chi possiede la logica di instradamento

Se il novanta per cento del traffico può girare su modelli piccoli e locali, la dipendenza da un singolo fornitore cloud smette di essere un fatto tecnico e diventa una scelta di governance, quasi sempre presa per default e non per decisione consapevole.

Progettare intorno al routing, non intorno al modello, sposta il controllo esattamente lì: chi scrive la logica che manda il traffico da una parte o dall’altra decide, di fatto, chi resta padrone dell’infrastruttura. Nella maggior parte delle aziende che conosco quella logica non la possiede nessuno davvero: cresce dentro il notebook di un ingegnere, non dentro un comitato di governance. Ed è lì, non nel modello scelto per ultimo, che si decide chi dipende da chi.

Spunto: Tomasz Tunguz, General Partner at Theory Ventures.

AI & GENAI, TECH & BUSINESS

Vendor lock-in AI: l’errore architetturale dei progetti enterprise

Conversazione vera, due settimane fa, con il CTO di un’azienda manifatturiera italiana medio-grande. Loro hanno un sistema AI in produzione da quattordici mesi, costruito sopra le API di OpenAI con function calling, prompt engineerizzati con cura, memoria conversazionale gestita in Pinecone, agente che orchestra cinque tool diversi. Funziona bene, gli utenti sono contenti, il management è soddisfatto. Mi chiama perché ha letto i miei articoli su AI privata e vuole capire se ha senso, per loro, valutare una migrazione verso un setup on-premise con modelli open-weight.

La mia risposta è stata: “Tecnicamente sì, però oggi la migrazione vi costa quanto rifare metà del prodotto da zero”. Lui ha avuto un momento di silenzio, poi ha chiesto: “Come è possibile? Usiamo l’API standard di OpenAI. Mi avevano detto che era portabile”. La risposta a quella domanda è il tema di questo articolo. È un fenomeno che chiamo “vendor lock-in tecnico AI“, e fa fallire più progetti AI enterprise di quanti se ne discutano apertamente.

Il debito tecnico che non si vede

Le aziende che costruiscono prodotti AI sopra API cloud accumulano un debito tecnico di portabilità che non emerge nei primi mesi. Funziona tutto, perché ogni provider rispetta il proprio contratto API. Però sotto la superficie, dozzine di scelte tecniche e operative legano profondamente il prodotto al provider specifico, in modi che diventano evidenti solo quando si prova a cambiare.

Vorrei elencare i punti di lock-in più ricorrenti, in ordine crescente di gravità.

System prompt engineerizzati per quirk specifici del modello. Ogni LLM ha le sue idiosincrasie. Claude reagisce a certe formulazioni in modo diverso da GPT-4. Gemini ha pattern di risposta tutti suoi. Mistral e Llama hanno default culturali diversi. Quando il vostro team di prodotto ha lavorato 6 mesi per perfezionare prompt che funzionano bene sul modello scelto, quei prompt non funzionano più allo stesso modo se cambiate modello. La migrazione richiede re-engineering completo, con cicli di test e regression.

Function calling con sintassi proprietaria. OpenAI ha introdotto il function calling con uno schema specifico. Anthropic ha il suo formato per i tool. Gemini ha un altro ancora. Anche se tutti sono “function calling”, il modo in cui passare gli schemi, gli argomenti, le risposte è leggermente diverso. Codice che orchestra agenti complessi con dieci tool diversi è ricco di queste specificità.

Embedding model legati al provider. Se avete fatto RAG con embeddings di OpenAI ada-002 o text-embedding-3-large, quei vettori non sono compatibili con embeddings di Cohere, Voyage, BGE. Per cambiare modello di embedding, dovete re-indicizzare tutto il corpus documentale, che su grandi volumi richiede tempo e costa risorse.

Vector database con schemi rigidi. Avete usato Pinecone con metadati strutturati in un certo modo, indici composti definiti, filtri configurati. Migrare a Qdrant, Weaviate o Milvus significa rifare lo schema, validare i risultati, magari riadattare le query applicative.

Memoria conversazionale tarata sul modello. I limiti di token, le strategie di summarization, le truncation policies, sono tutti calibrati sul modello specifico. Cambiando modello, la memoria si comporta diversamente, i contesti vengono troncati in modo diverso, le conversazioni perdono coerenza in punti diversi.

Monitoring e observability legati alle API. Avete configurato logging strutturato per le chiamate OpenAI con i loro request ID, latency metrics, cost tracking basato sui loro pricing tier. Cambiare provider significa rifare l’osservabilità.

Skills del team. Il vostro sviluppatore AI senior conosce profondamente l’API OpenAI dopo due anni di lavoro. Conosce le edge case, sa come reagire ai 429, ha intuizione per i prompt che funzionano. Su un provider nuovo, quella conoscenza è azzerata. Servono mesi di learning curve.

Sommato tutto, una migrazione fra provider AI cloud su un’applicazione in produzione di 12+ mesi richiede tipicamente 2-4 mesi di lavoro di team specializzato. Quei mesi sono pieni di rischio: i clienti si lamentano dei comportamenti diversi, qualità delle risposte temporaneamente peggiore, bug che emergono solo in produzione, costi che non rientrano nei piani.

L’astrazione che salva la vita architetturale

C’è una soluzione architetturale ben nota, e si chiama “abstraction layer”. L’idea è semplice: invece di chiamare direttamente le API del provider AI, fate passare ogni interazione attraverso un layer intermedio che espone un’interfaccia stabile compatibile (tipicamente compatibile con OpenAI, perché è lo standard de facto). Il layer si occupa di tradurre nel formato del provider specifico sottostante. Quando volete cambiare provider, cambiate solo il layer, non le applicazioni.

Sembra banale, ma poche aziende lo fanno bene. La maggior parte di quelle che ho visto in advisory ha un’astrazione “leggera” che gestisce solo il routing delle chiamate al LLM, ma non astrae le altre cinque-sei superfici di integrazione (embeddings, vector DB, memoria, tools, logging). Risultato: il giorno della migrazione, scoprono che l’astrazione copre solo il 30% del problema.

L’astrazione completa deve coprire sette superfici, e qui entra il valore di un orchestratore maturo come LocalAI.io, su cui ho investito personalmente come cofondatore.

1. Chat completions. LocalAI espone l’endpoint OpenAI-compatible standard, ci puntate il vostro codice esistente, e il modello sotto può essere Llama, Mistral, Qwen, DeepSeek o anche un OpenAI/Claude pass-through. Cambiate il modello dalla console, le applicazioni continuano a funzionare.

2. Embeddings. Stessa cosa per il modello di embedding. Esponete l’endpoint embedding-compatible OpenAI, dietro c’è il modello che decidete (bge-m3, multilingual-e5, OpenAI ada). Cambiate dietro senza toccare il codice.

3. Function calling. L’orchestratore unifica le specifiche function calling fra provider diversi, traducendo in tempo reale.

4. Vector database. Qui l’astrazione è più sottile: serve un layer applicativo (LangChain, LlamaIndex, o codice custom) che si interfacci con un’API generica di vector DB. Qdrant, Weaviate, Chroma hanno tutti adapter per le librerie principali.

5. Memoria conversazionale. Va gestita in un livello applicativo che non dipenda dal modello specifico. Esistono librerie come mem0 che fanno questo lavoro bene.

6. Monitoring. Centralizzato sull’orchestratore, non sui singoli provider. Tutto il logging passa per il layer, indipendentemente da chi sta servendo le richieste.

7. Cost tracking. Anche qui centralizzato. L’orchestratore conta i token, applica le sue policy di pricing, espone le metriche aggregate.

Con un’astrazione completa di queste sette superfici, una migrazione di provider AI può ridursi a un’ora di lavoro di reconfigurazione, invece di tre mesi di refactor. È una differenza che, su un’applicazione enterprise, si traduce in 50.000-200.000 euro risparmiati ogni volta che cambiate.

Quando vale la pena pagare il costo dell’astrazione

Una nota di onestà. L’abstraction layer ha un costo iniziale. Aggiunge una dipendenza al vostro stack, un piccolo overhead di latenza (5-30ms tipicamente), un componente in più da manutenere. Per startup che stanno facendo POC veloci, è probabilmente overkill, perché il rischio di voler cambiare provider entro 6 mesi è basso e gli investimenti accumulati sono minimi.

Per le aziende enterprise che stanno costruendo un sistema AI destinato a vivere 3-5 anni, l’astrazione vale praticamente sempre l’investimento. Tre situazioni dove l’astrazione è essenziale:

Quando il modello scelto oggi non sarà quello di fra 24 mesi. L’ecosistema AI evolve velocemente. Nel 2024 OpenAI dominava. Nel 2026 Claude, Gemini, Mistral, modelli open-weight sono tutti competitivi su task specifici. Nel 2028 lo scenario sarà ancora diverso. Un’azienda che si lega oggi a un singolo provider si trova a inseguire la concorrenza con due anni di ritardo.

Quando la compliance può cambiare. Una banca italiana che oggi usa Claude potrebbe domani avere requisiti che impongono di portare il modello in casa per AI Act o evoluzioni normative. Se ha un’astrazione, la migrazione è di una settimana. Se non ha, sono 4 mesi.

Quando vi serve usare modelli diversi per task diversi. L’approccio “best model per ogni task” sta diventando standard. Claude per scrittura, GPT per reasoning, DeepSeek per codice, Qwen per estrazione strutturata, Mistral per italiano fluente. Senza astrazione, dovete integrare 5 SDK diversi. Con astrazione, è un parametro nel routing.

L’errore tipico che vedo nei progetti AI enterprise

Per chiudere, vorrei raccontare il pattern di errore più frequente che vedo nei progetti AI enterprise che falliscono. Si svolge sempre nello stesso modo, in tre fasi.

Fase 1: prototipo veloce. Il team prodotto vuole muoversi rapidamente. Chiamano direttamente l’API OpenAI, fanno il POC in due settimane, lo presentano al management. Il management è entusiasta, dà luce verde a una versione di produzione. Decisione presa: usiamo OpenAI come fornitore principale.

Fase 2: produzione e accumulo. Nei 12-18 mesi successivi, il team costruisce features sopra features. System prompt sempre più sofisticati, function calling, RAG con Pinecone, agenti multi-step. Tutto su API OpenAI. Nessuno si pone il problema dell’astrazione perché funziona tutto bene.

Fase 3: il momento di verità. Arriva una di queste situazioni: i costi OpenAI superano i budget previsti, il management chiede di portare l’AI in casa per ragioni di sovranità o compliance, un competitor si vanta di prestazioni migliori con Claude e il management vuole switchare. A questo punto il team scopre che la migrazione costa 3-4 mesi di lavoro e mette a rischio il prodotto. Si rinvia. Si rinvia ancora. Poi qualcuno decide che è meglio non toccare niente, e l’azienda resta legata al provider scelto due anni prima, anche quando non è più la scelta migliore.

Quel pattern, per me, è la singola causa più frequente di stagnazione strategica nei progetti AI enterprise italiani. La soluzione non è tecnicamente difficile (un abstraction layer maturo si setta in due settimane). È una decisione architetturale da fare presto, prima che l’accumulo di lock-in la rende troppo costosa.

Tre azioni concrete per chi sta valutando ora

Per chi sta costruendo o ha appena messo in produzione un sistema AI enterprise, tre azioni che vale la pena valutare nei prossimi 30 giorni.

Audit del lock-in attuale. Mappare quali punti del vostro stack sono legati al provider AI specifico. System prompt, embeddings, function calling, vector DB, memoria, logging, expertise del team. Quantificare quanto tempo costerebbe oggi una migrazione totale a un provider diverso. Se la stima è oltre un mese di lavoro, avete un debito tecnico che vale la pena ridurre.

Introduzione progressiva dell’abstraction layer. Non serve un big-bang refactor. Si può introdurre un’astrazione progressivamente: cominciando dalle chat completions (l’80% del traffico tipico), poi embeddings, poi function calling. In 6-8 settimane è possibile arrivare a un’astrazione completa su un sistema esistente.

Test di portabilità periodici. Anche se non avete intenzione di cambiare provider oggi, fate un esercizio: ogni 6 mesi, provate a far girare una percentuale del traffico (5-10%) su un provider alternativo via l’abstraction layer. Misura due cose: la qualità delle risposte resta accettabile, e l’astrazione regge il routing. Se sì, siete davvero portabili. Se no, scoprite dove sono i punti deboli mentre i costi della migrazione sono ancora bassi.

Per chi vuole approfondire il setup di un’architettura AI sovrana basata su abstraction layer, ho scritto questa serie di articoli: GDPR e LLM, hardware locale, TCO on-premise, scelta del modello open-weight, AI Act checklist, installazione di LocalAI, cloud sovrano italiano. Insieme coprono lo stack completo. Per una conversazione specifica sul vostro contesto, c’è la pagina Advisory.

La domanda finale, quella che cambia il futuro architetturale del vostro sistema AI, è semplice. Se domani il provider che usate oggi raddoppiasse i prezzi, deprecasse il modello che vi serve, o cambiasse i termini commerciali in modo per voi inaccettabile, in quanto tempo sareste in grado di rispondere? Se la risposta è in mesi, avete un problema architetturale che vale la pena affrontare adesso, mentre la migrazione costa ancora poco.

AI & GENAI, TECH & BUSINESS

Cloud sovrano italiano: PSN e AI nel 2026

Per chi non l’ha seguita da vicino, la storia del cloud sovrano italiano sembra un dossier infinito. Strategia Cloud Italia annunciata nel 2021, gara da 4,4 miliardi assegnata nel 2022, primi data center operativi a fine 2022, target intermedi PNRR raggiunti nel 2024, oltre 600 pubbliche amministrazioni aderenti a gennaio 2026. È stata una marcia lunga, con qualche zona d’ombra e diverse svolte. Però è arrivata da qualche parte. Nel 2026 il Polo Strategico Nazionale è un’infrastruttura operativa, con quattro data center attivi (Acilia e Pomezia nel Lazio, Rozzano e Santo Stefano Ticino in Lombardia), oltre 576 amministrazioni che lo usano in produzione, contratti che valgono complessivamente 3,6 miliardi di euro estesi fino al 2035.

Per chi si occupa di AI nelle aziende italiane, il PSN non è un argomento da convegno di settore. È diventato un fattore concreto che incide su almeno tre decisioni operative: dove possono girare i modelli AI delle amministrazioni pubbliche italiane, quali fornitori AI possono lavorare con PA e con grandi corporate strategici, e quali architetture AI private possono dirsi davvero “sovrane” per il mercato italiano. Provo a sciogliere il quadro per chi lavora in questi mercati e deve prendere decisioni informate.

Cosa è davvero il Polo Strategico Nazionale

Il PSN è il terzo pilastro della Strategia Cloud Italia, accanto al cloud pubblico qualificato (servizi cloud commerciali certificati per la PA) e al cloud delle amministrazioni stesse. È pensato per ospitare in sicurezza i dati e i servizi “critici e strategici” delle PA italiane, definizione che secondo le linee guida di ACN (Agenzia per la Cybersicurezza Nazionale) include sanità, fiscalità, giustizia, ordine pubblico, difesa, infrastrutture critiche, dati personali su larga scala.

L’infrastruttura è gestita da una società consortile che vede insieme TIM Enterprise (capofila), Leonardo, Cassa Depositi e Prestiti, Sogei. È una struttura mista pubblico-privato che opera sotto vigilanza del Dipartimento per la Trasformazione Digitale e di ACN. Tecnicamente, il PSN offre un’infrastruttura multicloud che integra capacità proprie con quelle di hyperscaler internazionali (AWS, Google Cloud, Microsoft Azure, Oracle) ma con il vincolo critico che i dati sensibili restino fisicamente sul territorio italiano e gestiti da personale italiano sotto giurisdizione italiana.

A gennaio 2026 il PSN ha superato la sua principale milestone PNRR con oltre 600 amministrazioni aderenti, contro le previsioni iniziali del piano economico-finanziario originario. Il target per giugno 2026 è arrivare a 280 PA con migrazioni complete in corso, e una finestra ulteriore di adesione resta aperta fino a febbraio 2027. Numeri che dicono che il progetto è uscito dalla fase di startup e sta entrando in fase di consolidamento.

Perché conta per le aziende che fanno AI

Il PSN non è “solo” un’infrastruttura PA. È un mercato regolato che oggi vale 3,6 miliardi su 13 anni, ed è il canale obbligato per chiunque voglia vendere AI a una pubblica amministrazione italiana sui dati critici o strategici. Tre conseguenze pratiche per le aziende.

Il fornitore AI deve essere qualificato PSN. Se sviluppate una soluzione AI per la sanità pubblica, per l’amministrazione finanziaria, per la giustizia, l’erogazione deve girare in PSN. Significa avere processi di qualificazione, certificazioni di sicurezza, infrastruttura che si integra con lo stack PSN, conformità con le linee guida di ACN. Per startup AI italiane, è una barriera all’ingresso seria. Per chi la supera, è anche una protezione competitiva: i fornitori americani devono ricostruirsi una posizione che voi avete già naturalmente.

Il modello AI deve essere on-premise o in cloud sovrano. Sui dati PSN non possono girare API ChatGPT o Claude. Devono girare modelli che insistono sull’infrastruttura italiana, sotto controllo italiano. Questo apre uno spazio commerciale enorme per soluzioni AI private italiane basate su modelli open-weight (Llama, Mistral, Qwen) installati dentro perimetro PSN. È esattamente il ruolo che soluzioni come LocalAI possono giocare quando sono ben integrate con lo stack PSN.

La data residency cinese o americana è esclusa. Modelli ospitati su server Alibaba in Cina o su AWS regioni americane non passano la qualificazione PSN. Modelli open-weight che girano su infrastruttura italiana, anche se sono Qwen o Llama scaricati gratuitamente, sì. La distinzione è importante: il PSN non vieta i modelli stranieri come tali, vieta il loro hosting su infrastruttura non sovrana.

Cosa significa per il mercato AI italiano nei prossimi 18 mesi

Tre dinamiche operative che vedo emergere già adesso e che dovrebbero accelerare nei prossimi 18 mesi.

Concentrazione di valore sulle aziende AI italiane qualificate. I prossimi bandi PA su AI (assistenza al cittadino, automazione processi amministrativi, gestione documentale, analisi dati epidemiologici) faranno largo riferimento a fornitori qualificati PSN. Le aziende che hanno fatto il percorso di qualificazione raccoglieranno la quasi totalità del mercato PA italiano AI nei prossimi 3-5 anni.

Spinta su soluzioni open-weight italiane. Visto che gli LLM cloud americani sono di fatto esclusi dai progetti PA strategici, l’unica alternativa praticabile sono modelli open-weight gestiti dentro perimetro italiano. Questo crea pressione per stack tecnologici italiani capaci di gestire l’intera filiera, dall’hardware al modello all’orchestrazione. È esattamente l’opportunità su cui aziende come LocalAI stanno costruendo offerta dedicata al mercato italiano.

Effetto traino sul settore privato regolato. Anche se PSN nasce per la PA, le sue logiche di sovranità si stanno propagando ai settori privati regolati. Banche italiane di medie dimensioni stanno cominciando a chiedere ai propri fornitori AI le stesse garanzie di sovranità tecnica che la PA pretende dal PSN. Aziende sanitarie private adottano linee guida di data residency simili. La normativa AI Act, in vigore dal 2 agosto 2026, accelera questa convergenza fra requisiti PA e requisiti enterprise sensibile.

La banca italiana che ha cambiato approccio

Vorrei raccontare una scena reale recente. Lavoro nel 2025 con una banca italiana di medie dimensioni che sta valutando una RFP per un sistema AI di gestione documentale. Tre fornitori in gara: uno italiano con stack open-weight su infrastruttura italiana, uno americano con LLM cloud OpenAI, uno europeo con LLM cloud Mistral in Francia. Il responsabile compliance, dopo aver letto le tre proposte, fa un’osservazione che spiazza il comitato: “Il fornitore italiano costa il 30% in più. Però se domani vogliamo chiedere un parere alla Banca d’Italia sui nostri sistemi AI, possiamo dire che girano su infrastruttura italiana sotto controllo italiano. Con gli altri due, dobbiamo spiegare perché abbiamo accettato un trasferimento dati di fatto, anche se contrattualmente protetto”.

Il fornitore italiano vince. Non sul prezzo, non sulle prestazioni tecniche, ma sull’argomento sovranità che è entrato nei criteri di valutazione. È un esempio puntuale, ma rappresenta una direzione che vedo emergere in modo trasversale nei settori regolati italiani.

Cosa fare se siete una software house italiana

Per le aziende italiane che fanno o vogliono fare AI per la PA o per i settori regolati, ci sono quattro azioni operative che vale la pena pianificare adesso.

Qualificazione PSN. Avviare il percorso di qualificazione, anche se al momento il vostro prodotto AI non è ancora pronto per la PA. La qualificazione richiede tempo (6-18 mesi) e ha costi non trascurabili. Cominciare con anticipo dà un vantaggio competitivo strutturale.

Stack AI sovrano. Costruire la propria offerta AI sopra modelli open-weight (Llama, Mistral, Qwen) gestiti con orchestratori open-source come LocalAI.io. Evitare di costruire prodotti rigidamente legati a OpenAI o Anthropic, perché chiudono porte preziose sul mercato PA e regolato italiano.

Partnership con i grandi player PSN. TIM Enterprise, Leonardo, Sogei, Cassa Depositi e Prestiti sono i grandi player dell’ecosistema. Costruire relazioni commerciali strutturate con loro è la strada più diretta per arrivare nel canale PA.

Posizionamento di marketing chiaro. Comunicare in modo esplicito che la vostra soluzione è “sovrana italiana”, che gira su infrastruttura italiana, che usa modelli che possono essere documentati e auditati. È un argomento di vendita forte oggi, lo sarà ancora di più nei prossimi 24 mesi.

Il punto di equilibrio fra sovranità e pragmatismo

Una nota di realismo. Il cloud sovrano italiano non significa rinunciare alle migliori tecnologie globali. Significa avere la capacità di scegliere quali tecnologie portare in casa, e di farle girare sotto giurisdizione italiana. Mistral è francese, Llama è americano, Qwen è cinese, ma se li usate in versione open-weight nella vostra infrastruttura italiana, state usando tecnologia globale dentro un perimetro sovrano. È la differenza importante che spesso si perde nei dibattiti politici.

Il PSN, per come è costruito, riflette questa logica equilibrata. Non vieta gli hyperscaler globali (AWS, Google Cloud, Microsoft Azure, Oracle sono partner dell’infrastruttura multicloud). Vieta che i dati sensibili italiani siano gestiti da soggetti che non sono sotto giurisdizione italiana. È una differenza tecnica e giuridica importante.

Per le aziende che fanno AI sul mercato italiano, è il punto di equilibrio da capire bene. Costruire la propria offerta AI come “italiana ma globale” è il posizionamento vincente per i prossimi anni: tecnologie aperte e best-of-breed, integrate in un’architettura che ne mantiene il controllo sul territorio italiano.

Per chi sta avviando questo percorso, ho scritto questa serie di articoli che coprono gli aspetti complementari: GDPR e LLM, hardware locale, TCO on-premise, scelta del modello open-weight, AI Act checklist, installazione di LocalAI. Insieme coprono lo stack completo di decisione per chi vuole costruire AI privata sovrana italiana. Per una conversazione specifica sul vostro contesto, c’è la pagina Advisory.

La domanda finale da portarsi nei prossimi mesi è semplice. Se domani il vostro maggior cliente fosse una pubblica amministrazione italiana o una grande corporate regolata, sareste in grado di rispondere alla loro RFP con un’offerta AI tecnicamente competitiva, ma anche giuridicamente sovrana? Se la risposta è no, c’è una decisione architettura da prendere adesso, prima che lo facciano i vostri concorrenti italiani più veloci.

AI & GENAI, TECH & BUSINESS

Modelli di frontiera: la mappa di chi li costruisce, come sono fatti e quanto costano

Mai prima d’ora un governo aveva staccato la spina a uno dei modelli di frontiera già in mano al pubblico. È successo a giugno, con Fable 5 e Mythos 5 di Anthropic, spenti su ordine dell’amministrazione americana per ragioni di sicurezza nazionale. Sotto la cronaca c’è un fatto più grande di un singolo provider: alcuni di questi sistemi sono diventati abbastanza potenti da essere maneggiati come materiale strategico, al pari di un chip avanzato o di una tecnologia a duplice uso.

La parola gira ovunque, il suo significato molto meno, e per orientarsi conviene partire dall’origine del nome.

Una parola nata nei corridoi della policy

Il termine non viene dal marketing. Nasce a metà 2023, in un paper firmato da ricercatori legati al Future of Humanity Institute, che chiamavano “frontier AI” i modelli fondazionali tanto capaci da poter sviluppare abilità pericolose per la sicurezza pubblica. Da lì è entrato nel vocabolario dei governi, prima fra tutti quello britannico con la sua Frontier AI Taskforce e il summit sulla sicurezza dell’AI di fine 2023.

La definizione ha una caratteristica scomoda, si muove. Frontiera è qualunque cosa stia sul bordo più avanzato delle capacità in un dato momento, il che vuol dire che il modello di punta di oggi sarà il modello mediocre di dopodomani. Accanto a questa lettura mobile ne esiste una più rigida, usata dai regolatori, che fissa una soglia di calcolo: oltre i 10²⁶ FLOP impiegati per l’addestramento scattano obblighi di trasparenza e compliance. Due definizioni che convivono, una basata su cosa il modello sa fare, l’altra su quanta energia è servita a costruirlo.

Sotto il cofano c’è sempre un Transformer

Tolta la scenografia, l’impalcatura è la stessa per tutti. L’architettura di base si chiama Transformer ed è del 2017. Per dare la misura di quanto è cambiato il gioco: addestrare quel primo Transformer costò intorno ai 900 dollari. I modelli di cui parliamo oggi sono figli di quella stessa idea, cresciuta di parecchi ordini di grandezza.

Quasi tutti i modelli di frontiera adottano una variante chiamata mixture-of-experts. Invece di accendere l’intera rete per ogni parola che elaborano, la suddividono in molti moduli specializzati e ne attivano solo una frazione alla volta. È il trucco che permette di avere modelli enormi sulla carta e relativamente economici da far girare nella pratica.

Poi c’è il ciclo di costruzione, diviso in due tempi. Il pre-training è la fase cara, quella in cui il modello divora enormi quantità di testo e codice, immagini e suono, bruciando i milioni di dollari di calcolo. Il post-training viene dopo, costa molto meno, e serve a rendere il modello utile e allineato, insegnandogli a seguire le istruzioni e a comportarsi in modo prevedibile. Gran parte di ciò che percepiamo come “carattere” di un modello si decide in questa seconda fase.

La novità degli ultimi diciotto mesi sono i modelli che ragionano prima di rispondere, generando catene di pensiero interne prima di consegnare l’output. È la leva che ha spinto in alto i punteggi in matematica, programmazione e scienza. Insieme a questo conta la finestra di contesto, quanto materiale il modello riesce a tenere sotto gli occhi in una volta sola. La linea di frontiera si è assestata intorno al milione di token, con qualche eccezione che spinge molto oltre: una startup di Miami ne ha annunciato uno da dodici milioni, e tra i modelli scaricabili Llama 4 Scout arriva a dieci.

Quattro nomi in testa e due spenti dal governo

A metà 2026 il gruppo di testa dei modelli di frontiera è abbastanza leggibile, anche se cambia di mano in continuazione. Claude Opus 4.8, uscito il 28 maggio, guida l’indice di intelligenza di Artificial Analysis. Intorno gli stanno GPT-5.5 di OpenAI, Gemini 3.1 Pro di Google e Grok 4.3 di xAI. Nessuno vince su tutto: chi domina la programmazione arranca sulla scrittura creativa, chi guida sul ragionamento puro costa la metà di un concorrente. La domanda utile non è quale sia il migliore in assoluto, ma quale sia il migliore per un certo lavoro.

Poi c’è la storia di Mythos. Anthropic lo presenta ad aprile come un modello capace di trovare da solo le falle di sicurezza in codice considerato inattaccabile, una capacità giudicata troppo pericolosa per un rilascio aperto. Invece di metterlo in vendita, l’azienda lo affida a un consorzio ristretto, Project Glasswing, una cinquantina di organizzazioni all’inizio, circa centocinquanta a inizio giugno, tra cui Google, Nvidia, Microsoft e Apple. Il 9 giugno arriva la versione commerciale, Fable 5, lo stesso modello con dei filtri che bloccano le richieste nelle aree ad alto rischio come cyber e biologia, dirottandole su Opus 4.8 in meno del cinque per cento delle sessioni. Tre giorni dopo il governo stacca tutto, e il telecom coreano sospettato di legami con la Cina che secondo le ricostruzioni avrebbe fatto scattare la direttiva ci ricorda quanto sia diventato politico il confine tra chi può usare un modello e chi no.

L’altra metà della frontiera parla cinese

Chi guarda solo agli Stati Uniti vede metà del quadro. L’altra metà parla cinese, e ha scelto una strada diversa, quella dei pesi aperti. Ad aprile, otto dei dieci modelli cinesi più capaci erano scaricabili, eseguibili sui propri server, utilizzabili commercialmente. La famiglia Qwen di Alibaba ha superato Llama di Meta nei download cumulativi su HuggingFace, e i modelli cinesi viaggiano ormai oltre il quarantacinque per cento del traffico su OpenRouter, contro meno del due per cento di un anno prima.

I nomi da tenere d’occhio sono pochi e netti. DeepSeek ha fatto del prezzo la sua arma, con la versione V4 che raggiunge la parità con i modelli occidentali di punta sul coding agentico a circa trenta centesimi per milione di token. GLM di Zhipu è il primo modello di frontiera addestrato per intero su chip Huawei Ascend, senza una sola GPU Nvidia, e gira sotto licenza MIT, la più permissiva del lotto. Kimi di Moonshot ha puntato sugli agenti, con un’architettura a sciame che coordina fino a cento sotto-agenti in parallelo. Sopra tutti resta una verità che il marketing cinese non ama: sui benchmark trasversali più severi, una valutazione del NIST stima il modello cinese di punta indietro di circa otto mesi rispetto alla frontiera americana. Otto mesi, in questo settore, sono insieme pochissimo e moltissimo.

C’è un dettaglio che pesa più dei punteggi. Un modello aperto e competitivo lo si può far girare dentro la propria infrastruttura, senza che nessun fornitore possa spegnerlo per ordine di un governo. La vicenda Fable 5 ha dato a questo argomento un peso che i grafici di benchmark non davano.

Centinaia di milioni per costruirli, centesimi per usarli

Quando si parla di costi conviene tenere separate due voci che differiscono di mille volte. Costruire un modello di frontiera è una faccenda da centinaia di milioni di dollari. Le grandi sessioni di addestramento dei modelli di frontiera nel 2026 stanno tra i duecento e i cinquecento milioni per la classe di GPT-5 e Gemini, e le proiezioni parlano di uno o tre miliardi a modello entro fine 2027. Secondo le stime di Epoch AI la spesa cresce di 2,4 volte l’anno dal 2016, e il vincolo che frena il prossimo salto oggi è la potenza elettrica dei data center, più dei chip. Dove vanno questi soldi? Quasi metà in chip e hardware dei server, una fetta robusta in stipendi dei ricercatori. Ecco perché la partita la giocano in pochi, serve un capitale che la maggior parte delle aziende non può nemmeno immaginare.

Usarli, invece, costa sempre meno. Il prezzo dell’inferenza, far rispondere il modello, è crollato di circa 280 volte in diciotto mesi a parità di prestazioni. Oggi i listini della frontiera vanno da dieci centesimi a settantacinque dollari per milione di token, una forbice enorme che si naviga guardando al rapporto tra prezzo e qualità, prima ancora che alla cima della classifica. È qui che i modelli cinesi aperti mordono di più, perché possono azzerare il costo per chi se li ospita in casa.

Nuovi modelli di frontiera ogni undici giorni

Tra febbraio e aprile 2026, in settantotto giorni, i tre principali laboratori americani hanno rilasciato sette modelli di frontiera. Uno stato dell’arte nuovo ogni undici giorni. Qualunque classifica scritta oggi sarà parzialmente falsa tra un mese, ed è la ragione per cui legarsi a un solo fornitore è diventato fragile. Chi costruisce sopra questi modelli sta imparando a instradare il lavoro tra più di uno, tenendo aperta la porta anche all’opzione di farne girare uno proprio, dentro casa.

Resta la domanda che la settimana del 12 giugno ha lasciato sul tavolo, e vale più di ogni benchmark. Se un modello di punta può sparire dall’oggi al domani per ordine di un governo, la frontiera appartiene a chi lo addestra o a chi tiene la mano sull’interruttore?

AI & GENAI, TECH & BUSINESS

Da RAG alla memoria: il vantaggio che nessuno può copiare

Chiudi la scheda del browser venerdì sera. La riapri lunedì, riprendi la stessa conversazione, e l’assistente non ha più memoria di te, non sa nemmeno chi sei. Le preferenze che avevi espresso, il lavoro lasciato a metà, le due ore di contesto costruite insieme: sparite. Si riparte da zero.

La risposta diffusa a quel vuoto si chiama RAG, e funziona pescando per somiglianza i pezzi di testo che servono e infilandoli nel prompt. Trasformare quella tecnica in una memoria vera è il problema su cui si arrovellano i team che costruiscono agenti in questo momento. Sotto la parte tecnica, fatta di schemi e di query, c’è una distinzione che riguarda chiunque costruisca prodotti con l’AI, ed è meno una scelta di database e più una scelta di strategia. Il RAG recupera. La memoria ricorda. E lì, nel punto in cui un sistema smette di recuperare e inizia a ricordare, smette anche di essere reattivo, e nasce un vantaggio che il modello, da solo, non ti dà.

Più contesto nel prompt non basta

Il RAG che quasi tutti hanno messo in produzione sono quattro righe di codice: trasformi i documenti in vettori, trasformi la domanda dell’utente in un vettore, peschi i più vicini, li infili nel prompt. Funziona. Funziona così bene che è diventato il default di ogni assistente interno degli ultimi due anni, e spiega anche perché quegli assistenti si somigliano tutti, appena la conversazione prova ad andare un po’ più in là.

Il recupero puro si rompe sempre negli stessi punti. La conversazione lunga, che dopo qualche centinaio di scambi non sta più nel prompt. La ripresa, l’utente che torna il giorno dopo e vorrebbe ritrovare dove era arrivato. Le preferenze e le regole, «questo cliente vuole le date in formato giorno-mese-anno», «i rimborsi sopra i cinquecento euro vogliono un’approvazione», cose che non ottieni per somiglianza semantica con l’ultimo messaggio. La risposta istintiva a tutto questo è una sola: infilare di più nel prompt. Più recupero, più storia, più contesto. Il conto dei token cresce, il modello si perde nel mezzo, e il sistema sembra più lento proprio quando dovrebbe sembrare più competente.

La memoria è un percorso di scrittura

Il salto vero non è mettere un database accanto al vector store. Cambia cosa serve quel livello di archiviazione, e come ci parlano gli agenti.

Il recupero è una query contro un corpus che hai caricato una volta, e niente di ciò che il modello dice rifluisce nel corpus. La memoria invece è un percorso di scrittura: tutto ciò che il sistema osserva durante una sessione, o che l’utente conferma, può diventare un record durevole, con il suo perimetro di visibilità, la sua provenienza, la sua scadenza. Lo stesso record si rilegge dopo, da un’altra sessione, magari da un altro agente che lavora per la stessa persona.

C’è una metafora che gira per descrivere tutto questo, il secondo cervello. La trovo utile e quasi sempre tradita, perché la maggior parte delle implementazioni si ferma un passo prima: ti danno note ricercabili, che sono uno schedario migliore, non una memoria. Una memoria vera distilla. Le note diventano fatti agganciati alle entità che descrivono, il lavoro concluso diventa un episodio riutilizzabile, e lo stesso strato serve allora la chat di una persona e l’agente che lavora al posto suo, senza che nessuno dei due abbia bisogno di una copia tutta sua. È la differenza tra un’AI che reagisce a ogni richiesta come fosse la prima e una che accumula, e sull’accumulo si adatta. In La Mente Adattiva ho provato a descrivere proprio questo scarto, tra un’intelligenza che risponde e una che si trasforma con l’esperienza.

Cinque tipi di memoria da non confondere

«Aggiungere memoria» suona come una funzione sola. In pratica sono sistemi diversi, e se non li separi finisci con un magazzino unico che risponde male a ogni domanda.

Le regole, prima di tutto. Le policy, i vincoli di compliance, le soglie di approvazione cambiano di rado e di proposito, e si recuperano per corrispondenza esatta, mai per somiglianza: una policy cercata per similarità è un errore, perché ti allontana in silenzio dalla regola che vale in quel momento. Poi le preferenze, i parametri stabili di personalizzazione, quelli che fanno sentire il sistema cucito addosso senza doverglielo ridire ogni volta. Poi i fatti, le affermazioni durevoli che l’agente può riusare con la loro provenienza: qui vive il vantaggio che si accumula, e qui i problemi si fanno più duri, perché ogni fatto che scrivi è una scommessa sul futuro. Poi gli episodi, i riassunti del lavoro concluso, la forma di una soluzione passata da riusare invece di riderivarla. E sotto tutto, le tracce, il registratore di volo grezzo da cui fatti ed episodi vengono distillati.

Cinque cose, cinque modi di conservarle, cinque modi di ritrovarle. Confonderne due qualsiasi produce un guasto preciso e prevedibile. È una delle tassonomie possibili, ce ne sono altre, ma il principio vale a prescindere dai nomi: trattare memorie diverse come se fossero la stessa cosa è la radice di metà dei comportamenti strani che vedi negli agenti.

Un cancello prima della memoria

Se prendi sul serio questa separazione, ti serve qualcosa che decida cosa entra nella memoria durevole e cosa resta effimero. È l’operazione più rischiosa di tutto il sistema. Promuovi tutto e la memoria si avvelena da sola, riempiendosi di scarti conversazionali. Non promuovi niente e l’agente resta amnesico.

Il cancello fa poche cose in una transazione sola. Classifica il candidato e gli assegna un perimetro, l’organizzazione, l’utente, l’agente. Verifica i duplicati, così lo stesso fatto che arriva da due sessioni diverse finisce in una riga sola e non in due che competono. Controlla che un fatto abbia una confidenza sopra soglia e una provenienza, cioè la sessione che lo ha generato. Poi calcola lo stato da dentro, mai dal chiamante, e scrive.

Qui si apre la parte che riguarda la governance, non solo il codice. Ogni record porta con sé il suo perimetro di accesso e la sua provenienza. Il diritto all’oblio, che su un log grezzo è una cancellazione, su una memoria diventa una faccenda seria, perché «la cosa che sa di te» è ormai un artefatto distillato da cento conversazioni e non un dato grezzo da buttare. È lo strato che in Pelle Digitale chiamavo la pelle tra noi e la macchina, e qui diventa qualcosa che un’azienda deve saper revocare a comando. L’EU AI Act spinge nella stessa direzione: gli obblighi per i sistemi ad alto rischio sono stati rinviati in via provvisoria da agosto 2026 a dicembre 2027, ma l’asticella su tracciabilità, audit e supervisione umana si alza, non si abbassa. Una memoria senza provenienza e senza scadenze non si può governare, e in Europa quello che sfugge al controllo, tra poco, sarà fuori uso.

Il modello è condiviso, la memoria è tua

Resta una domanda: su cosa appoggiare tutto questo. L’architettura in cui la maggior parte dei team finisce per inerzia spacca la memoria lungo l’asse che fa più male, i dati relazionali in un database, il recupero ibrido in un motore vettoriale, le tracce in un altro store ancora. Ognuno è ottimo per il suo compito. Il guaio arriva quando il contesto deve attraversarli, perché ogni recupero serio diventa una join tra sistemi, e ogni join attraversa un confine di sicurezza, di transazione, di latenza, e a ogni attraversamento ti riporti in casa il problema di consistenza che volevi evitare.

Tenere insieme il recupero semantico e i dati relazionali che lo governano, sotto un solo piano di query e un solo modello di sicurezza, è la capacità che conta. Postgres con pgvector, Elasticsearch, Pinecone, Weaviate, e framework come LangGraph, Letta, Mem0 affrontano pezzi del problema in modi diversi, e la scelta giusta dipende da dove vuoi che vivano i tuoi dati e da chi li può toccare. Per chi lavora su dati sensibili o sovrani questa non è una questione di prestazioni, è una questione di controllo, ed è il terreno su cui è nato LocalAI.io: tenere modello e memoria dentro un perimetro che governi tu.

C’è una conseguenza da tenere a mente. I modelli sono condivisi, li usano i tuoi concorrenti, li addestra qualcun altro, e l’anno prossimo quello che usi oggi sarà rimpiazzato da uno migliore. La memoria no. Quello che è dentro la tua memoria riflette scelte che solo il tuo team poteva fare, su cosa conservare, con quale perimetro, per quanto tempo. Il modello è il livello che puoi sostituire. La memoria è il livello che nessun altro può copiarti, perché è fatto della tua storia, non della tua tecnologia.

Costruirla bene costa più che impilare token in un prompt. Ma per chiunque stia mettendo l’AI dentro la propria azienda la domanda smette di essere «quanto contesto riesco a infilare» e ne diventa un’altra: cosa vale la pena che il tuo sistema ricordi, e cosa è meglio che dimentichi?