Categoria: TECH & BUSINESS

Tecnologia e business: l’intersezione tra strumenti digitali, modelli di impresa, leadership e strategia in contesti complessi. In questa sezione raccolgo articoli che mettono al centro le decisioni d’impresa: come si scelgono le tecnologie, come si costruiscono team, come si scalano aziende, come si guida la trasformazione digitale senza inseguire l’hype. Il primo filone è la trasformazione digitale concreta delle aziende. Niente narrazioni astratte sulla digital transformation, ma casi specifici di come cambia il lavoro quando entrano AI, automazione, dati, piattaforme cloud. Quali decisioni i CEO devono prendere personalmente e quali possono delegare. Dove servono nuove competenze e dove no. Il secondo filone è l’innovazione di prodotto e di business model. Cosa significa costruire prodotti AI-native, come si fa product management in un’epoca in cui la tecnologia abilitante cambia ogni sei mesi, dove sta la differenza tra innovazione che genera valore e innovazione vetrina. Spunti che vengono dai miei progetti come imprenditore in ICONI.CO, ZeroFive.AI, LocalAI.io. Il terzo è la leadership in contesti tecnologici complessi. Come si guida un team distribuito quando metà delle attività operative passa attraverso l’AI, come si forma la prossima generazione di leader quando le palestre tradizionali non bastano più, cosa servirà sapere ai manager dei prossimi dieci anni. Temi che riprendo anche dal libro La mente adattiva. Il quarto è la strategia di investimento. Dove conviene mettere capitale e attenzione: AI infrastructure, agenti autonomi, spatial computing, vertical SaaS, modelli open-source. Punti di vista basati su quello che vedo sul campo con le aziende che seguo come advisor e board member. Un quinto filone, più trasversale, è dedicato a casi di studio e narrazioni di imprese. Aziende italiane ed europee che hanno fatto bene la trasformazione, errori comuni che ho visto ripetersi nei boardroom, scelte coraggiose che hanno pagato. Storie utili per chi sta affrontando decisioni simili. Per chi vuole approfondire dal punto di vista strategico, c’è la pagina Advisory con i formati di collaborazione. Per chi cerca formazione strutturata sui temi tech-business, la sezione Formazione raccoglie i master e i percorsi executive che tengo nelle business school italiane.

2 Luglio 20262 Luglio 2026AI & 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.

1 Luglio 20262 Luglio 2026AI & GENAI, TECH & BUSINESS

Tokenmaxxing: cosa serve oltre a bruciare token

Ottantacinquemila dipendenti di Meta compaiono in una classifica interna dedicata al tokenmaxxing. Si chiama Claudeonomics, l’hanno costruita loro stessi incrociando i dati di utilizzo aziendale, e misura una cosa sola: quanti token ciascuno consuma lavorando con l’AI. In cima ci sono i “Token Legend”, vince chi ne brucia di più. A fine aprile Business Insider ha raccontato la lista, a fine maggio Amazon ha spento la sua versione interna dello stesso gioco, e a giugno Fortune titolava che il tokenmaxxing era già finito.

Finito nella forma che fa notizia, forse. Nella forma che sposta budget vero dalle assunzioni al motore agentico, il tokenmaxxing è appena cominciato, e le due cose vengono continuamente confuse.

Amazon ha spento la classifica interna sui token

La dinamica descritta da chi l’ha vissuta è semplice. Un dashboard aziendale mette in fila i dipendenti per numero di token consumati, il numero diventa visibile ai manager, e da lì in poi la classifica smette di misurare qualcosa e comincia a determinarlo. È il meccanismo che gli economisti chiamano legge di Goodhart: una misura, appena diventa un obiettivo dichiarato, smette di essere una buona misura. Al Financial Times alcuni dipendenti Amazon hanno raccontato di aver fatto girare agenti su compiti inutili solo per restare in classifica, mentre Uber, secondo Fortune, ha esaurito l’intero budget AI del 2026 in quattro mesi.

Il paradosso è che nessuno, in questa versione del fenomeno, sta ridisegnando un solo processo. Si sta solo alzando un contatore. Ridisegnare i flussi di lavoro attorno all’AI è lavoro lento, spendere token per apparire “AI-native” è immediato, e la seconda cosa continua a travestirsi da prova della prima.

Il bilancio AI di Uber esaurito in quattro mesi

Nello stesso periodo, però, circola un’idea quasi opposta con lo stesso nome. Y Combinator la spiega ai suoi fondatori così: tokenmaxx, non headcountmaxx. Diana Hu, partner del fondo, lo dice senza troppi giri: una persona con gli strumenti giusti oggi può valere quello che prima valeva un intero team di ingegneria, e un budget API “scomodamente alto” è spesso più economico di un organico gonfiato.

Qui il token non è un trofeo da esibire su una classifica interna, è una voce di bilancio che sostituisce uno stipendio. Una startup che nasce nel 2026 non deve disimparare trent’anni di processi legacy per diventare AI-native, li costruisce così fin dal primo giorno: meno persone, più agenti, decisioni che si prendono dentro un flusso continuo invece che in una riunione settimanale.

Due aziende possono dichiararsi entrambe “tokenmaxxing” e fare l’esatto contrario: una infila numeri in un dashboard per sembrare avanti, l’altra riscrive l’organigramma attorno a quei numeri.

Cosa distingue un token che produce conoscenza da uno sprecato

Il test operativo che circola tra chi studia il tokenmaxxing si riduce a una domanda: quando il volume di token sale, cosa cambia nel lavoro che viene effettivamente accettato? Se la risposta è “niente”, si sta guardando la versione di vanità. Se la risposta è “un ciclo di revisione in meno, una decisione presa prima, un cliente servito senza aspettare”, si è dentro qualcosa che vale la pena misurare.

Un sistema che moltiplica le interazioni con l’AI senza lasciare che quelle interazioni si accumulino in qualcosa di riusabile genera un debito. Non lo vedi nella fattura del mese, lo vedi tre mesi dopo, quando ogni nuovo agente riparte da zero perché nessuno ha organizzato ciò che il primo aveva già imparato. Il vantaggio, in questo genere di sistemi, smette di stare nel modello e finisce nella memoria che un’azienda accumula, e lo stesso principio vale per il conto dei token: quel che resta dopo la spesa pesa più del numero speso.

Il ciclo che rende utile il tokenmaxxing

L’azienda che tokenmaxxa in modo utile non brucia token in sessioni isolate, li fa girare in un ciclo che si autoalimenta. Un ticket di supporto genera una sintesi, la sintesi aggiorna la base di conoscenza condivisa, la base di conoscenza informa il prossimo agente che risponde a un cliente simile, e ogni giro rende il giro successivo più preciso e più economico. Satya Nadella lo scorso mese ha messo lo stesso meccanismo al centro della sua visione d’impresa, chiamandolo learning loop, e il punto che aggiungo io è che il ciclo regge solo se qualcuno possiede l’infrastruttura che lo fa girare, non solo il modello che lo alimenta.

La meccanica del ciclo: trigger, non riunioni

Il loop non si costruisce con più call di allineamento, si costruisce con eventi che si attivano da soli. Un ticket chiuso genera un webhook, il webhook passa il testo a un agente con accesso al contesto storico del cliente, l’agente produce una sintesi strutturata e la scrive in un repository condiviso, e quella sintesi diventa automaticamente parte del contesto disponibile per il prossimo ticket simile. Nessun passaggio richiede che un umano apra una chat e formuli una domanda: il trigger sostituisce la richiesta.

Nel tokenmaxxing che funziona, la differenza tecnica che conta è tra un agente che risponde quando qualcuno lo interpella e un agente che si attiva quando cambia lo stato di un sistema: un CRM aggiornato, un documento modificato, una trascrizione caricata. Il secondo tipo tiene il ciclo vivo anche quando in azienda nessuno sta guardando, ed è quello che separa un assistente da un processo.

I loop cambiano forma da reparto a reparto

In assistenza clienti il loop più maturo parte da un ticket risolto: il caso alimenta una base di risposte pronte, e il prossimo cliente con lo stesso problema riceve una soluzione prima ancora che un operatore la legga. In ingegneria il ciclo passa dai code review, ogni commento di un revisore diventa una regola che l’agente applica al pull request successivo invece di essere ripetuto una volta di più. Nelle vendite il loop nasce dalla trascrizione delle chiamate: l’agente estrae le obiezioni ricorrenti e le carica nel CRM come suggerimenti per la trattativa dopo, senza aspettare il report trimestrale. Nella finanza aziendale il ciclo si chiude sulle policy di spesa, ogni eccezione approvata aggiorna la regola scritta e la richiesta successiva non arriva più a un umano se rientra nel nuovo perimetro. Nelle risorse umane il loop gira attorno alle domande sui benefit: la prima risposta corretta diventa voce di una base consultabile, la centesima non richiede più nessuno.

Il segnale che il ciclo funziona si misura sul tempo, non sui reparti coinvolti: quanto passa tra un’interazione e il momento in cui quell’interazione aggiorna qualcosa di consultabile per la prossima. Se la risposta è “mai”, quel reparto sta ancora solo usando l’AI, il loop non è partito.

Non conta quanto token bruci ma cosa resta dopo

Le aziende nate trent’anni fa restano indietro non perché usino meno AI, ma perché il loro organigramma è stato disegnato prima che esistesse un’alternativa al mettere una persona su ogni compito. Cambiarlo ora significa smontare processi che hanno funzionato per decenni, ed è un lavoro che nessun dashboard di token può velocizzare. Le aziende che nascono oggi non hanno questo problema, e la differenza tra chi vince e chi perde questa fase si vede meno nella fattura di Anthropic o OpenAI e più in quante decisioni, alla fine del trimestre, vengono ancora prese da un umano che rilegge tutto da capo.

Il ruolo umano che resta, in questo schema, è quello descritto anche in un pezzo recente su chi oggi gestisce insieme persone e agenti: meno produzione diretta, più verifica, correzione, approvazione finale. Un lavoro che a differenza dei token non si può comprare a peso.

Chi guarda la classifica dei token e pensa di aver capito qualcosa dell’azienda del 2026 sta guardando la metrica sbagliata. La domanda utile non è quanti token, ma quanti di quei token tornano indietro sotto forma di conoscenza che il prossimo agente non deve reinventare.

Fonti: Fortune, The Pragmatic Engineer, Business Insider / Y Combinator.

29 Giugno 202629 Giugno 2026AI & GENAI, TECH & BUSINESS

Manager di umani e di agenti: un mestiere che sta cambiando

A febbraio 2026 Harvard Business Review ha pubblicato un articolo a firma Suraj Srinivasan (Harvard Business School) e Vivienne Wei (Salesforce) sul nuovo ruolo del manager di agenti AI nelle aziende, intitolato To Thrive in the AI Era, Companies Need Agent Managers. Dentro c’è la giornata di Zach Stauber, support agent manager a Salesforce: comincia e finisce davanti a dashboard, scorecard e sistemi di osservabilità degli agenti. Non gestisce persone, gestisce una flotta di agenti AI che lavorano su supporto, vendite e marketing dentro Agentforce. Marc Benioff a luglio 2025 aveva già detto che Salesforce è passata da 9.000 a 5.000 ruoli nel customer support, riallocando il resto in vendite e customer success, e che gli agenti chiudono autonomamente l’85% dei ticket clienti.

Sembra una notizia di Silicon Valley, ed effettivamente il caso Salesforce è estremo. La categoria di lavoro che descrive però, quella del manager di agenti che orchestra un gruppo misto di umani e di sistemi automatizzati, sta arrivando a velocità inattesa anche dentro aziende italiane molto meno radicali. Lo vedo nei progetti di advisory che seguo, lo sto vivendo addosso io stesso nel modo in cui lavoro, e ho la sensazione che molti CEO italiani non abbiano ancora messo a fuoco quanto profondamente questo cambierà l’organigramma reale delle loro aziende entro 24 mesi.

A casa di chi costruisce AI, questo è già il presente

Lo studio Anthropic How AI Is Transforming Work at Anthropic, pubblicato il 4 dicembre 2025, ha analizzato 132 ingegneri e ricercatori interni, 53 interviste qualitative e i dati di uso di Claude Code. Un numero solo, fra i tanti che il paper mette sul tavolo, mi è rimasto in mente: il 27% del lavoro fatto con assistenza AI è lavoro che senza AI non sarebbe stato fatto affatto. Esperimenti che restavano nel cassetto, dashboard nice-to-have, documentazione interna sempre rinviata, strumenti che sarebbero costati troppo da prototipare a mano. Tutto questo adesso si fa, perché il costo marginale di iniziare è crollato.

Sotto quel 27% c’è una conseguenza meno raccontata, ma evidente nelle interviste: gli ingegneri Anthropic descrivono se stessi sempre più come supervisori, persone che danno indicazioni e controllano output, che indirizzano il lavoro invece di farlo direttamente. La quota di lavoro che dicono di poter “fully delegate” all’AI resta intorno al 10-20%, ma il restante 80-90% è collaborazione attiva, con il loro tempo che scivola dall’esecuzione diretta al controllo, dalla scrittura del codice alla revisione del codice scritto da Claude. Anthropic è il caso estremo perché Claude è il loro prodotto, ma la curva che descrivono è la stessa che vedo nei team di sviluppo italiani che hanno adottato Claude Code o Cursor o equivalenti negli ultimi sei mesi.

“Il McKinsey” che ha messo sul tavolo i numeri

A gennaio 2026, sul podcast All In, Bob Sternfels (global managing partner McKinsey) ha dichiarato che la sua azienda ha 60.000 dipendenti totali, di cui 25.000 agenti AI a fianco di 40.000 umani, con l’obiettivo di parità entro fine anno. Sul valore reale di quei 25.000 agenti il dibattito è aperto, e i concorrenti EY e PwC hanno fatto notare che una manciata di agenti ben fatti spesso produce più valore di una flotta numerosa. La notizia più seria di quella conferenza, come ho scritto in maggio, era però un’altra: McKinsey sta spostando una quota maggiore della remunerazione dei partner da cash a equity, perché i ricavi diventano volatili e il vecchio modello non regge più.

Una conseguenza che né McKinsey né i suoi concorrenti hanno ancora interiorizzato è questa: se metà della tua workforce è composta da agenti, hai bisogno di una struttura manageriale che gestisca gli agenti come si gestiscono le persone, ma con strumenti diversi.

Servono ruoli di accountability per le performance degli agenti, persone che ne misurino la qualità, che li riallenino quando deragliano, che decidano quando un caso va escalato a un umano. È esattamente quello che fa Stauber a Salesforce, ed è il primo abbozzo di una professione che fino a 18 mesi fa non esisteva.

Come sto vivendo io questo cambiamento

Mi è capitato negli ultimi mesi di trovarmi a fare il lavoro che fino a 24 mesi fa avrei diviso fra tre o quattro junior. Brief di scoping per un cliente, ricerca preliminare di mercato, prima stesura di un’offerta tecnica, analisi di documenti corposi, audit di una codebase. Quattro cose che richiedevano persone diverse, tempi distribuiti su settimane, riunioni di coordinamento. Adesso le orchestro da solo, con Claude Code che lavora sulla parte tecnica, Claude o GPT che mi preparano i deck e le bozze, RSS Intelligence che mi setaccia le fonti, MCP server che leggono i miei progetti aziendali su Biztrack e li trasformano in materiale per il cliente. Non è perfetto, non sempre regge, ma il salto di efficienza è reale.

Ed è qui che inizia il dubbio, quello che lo studio Anthropic intercetta nelle sue interviste e che condivido. Se il junior che avrebbe fatto la ricerca di mercato per me non lo faccio più assumere, perché un agente la fa decentemente in venti minuti, dove lo formerà la prossima generazione di consulenti e advisor? E se la prima bozza di un’offerta tecnica la scrive un agente che ho istruito sui miei pattern, quando avrò ancora il tempo e l’occasione di fare quel lavoro io stesso, con la lentezza che serve per capirlo davvero?

Su questo voglio essere chiaro: non sto facendo argomenti contro l’adozione dell’AI, su cui sono fra i più convinti. Sto argomentando per adottarla con la consapevolezza che ogni nuova efficienza implica una scelta di cosa non sviluppiamo più come capacità umana. La supervisione di un agente richiede competenza profonda dello stesso dominio che l’agente ha automatizzato. Se quella competenza non si forma più sul campo, fra due cicli generazionali la supervisione diventa nominale.

Il ruolo del manager si sta sdoppiando

Quello che osservo nelle aziende italiane medie con cui lavoro, fra le tecnologiche di Roma e le manifatturiere del Nord, è che la figura del manager si sta sdoppiando in due direzioni che convivono nella stessa persona.

Una direzione resta quella tradizionale, fatta di relazione umana fra persone: motivare un collega che attraversa un momento complicato, costruire e mantenere fiducia, gestire i conflitti che nascono inevitabilmente in ogni team, prendere decisioni su altre persone. Questa parte non viene erosa dall’AI, anzi: con team più piccoli e più senior, ogni decisione su una persona pesa di più, ogni riunione conta di più, ogni colloquio di sviluppo diventa più strategico. Il manager di umani non scompare, diventa più importante per quei pochi umani che resteranno nel team.

L’altra direzione è completamente nuova. Si tratta di definire i task degli agenti, scegliere il modello adatto al singolo carico, versionare i prompt come si versionano i contratti, monitorare derive e performance, decidere quando portare un agente da pilot a produzione e quando spegnerlo. Sono attività che assomigliano al lavoro di un product manager più che a quello di un people manager, ma vivono dentro lo stesso perimetro di responsabilità.

Il risultato è che il manager italiano del 2027 dovrà essere bilingue. Parlare la lingua delle persone e la lingua dei sistemi agentici. E queste due lingue si imparano in scuole molto diverse.

Ambizione, giudizio, creatività: cosa cerca davvero Sternfels

A Las Vegas, sempre a gennaio, Sternfels ha indicato che McKinsey cerca oggi nei candidati junior tre qualità precise: ambizione, giudizio, creatività. Sembra una lista da ufficio HR, ma se la leggi con la lente del lavoro che descrive Stauber a Salesforce, ti accorgi che è la descrizione esatta del manager di agenti.

L’ambizione conta perché chi gestisce agenti non ha più la routine del controllo gerarchico stretto, ha invece il problema di decidere cosa far fare di nuovo a un sistema che fa molto da solo. Il giudizio conta perché la quasi totalità delle decisioni operative la prendono gli agenti, e l’umano interviene proprio nei casi limite dove non ci sono regole chiare. Sulla creatività poggia tutto il resto, dato che definire bene un agente significa immaginare casi d’uso e prompt che non sono nel playbook esistente.

Tutte e tre queste organizzazioni stanno cercando le stesse tre competenze, e stanno cercandole in nuovi ruoli mentre tagliano in quelli vecchi. È lo scenario che le aziende italiane medie devono interiorizzare, perché succederà anche da loro, con due-tre anni di ritardo e a una scala più piccola, ma con la stessa logica.

Come imposto i progetti dove serve un manager di agenti

Quando un CEO italiano mi chiede come si prepara la sua azienda al manager di agenti, gli rispondo che non si prepara con un master di sei mesi né con un progetto di consulenza chiavi in mano. Si prepara mettendo subito un piccolo gruppo di manager attuali in condizione di lavorare quotidianamente con agenti veri, su task veri, e di imparare sul campo cosa va e cosa non va.

Praticamente significa scegliere un caso d’uso non strategico ma reale, dove il rischio è basso e l’apprendimento alto: drafting di prime risposte commerciali, analisi periodica di documentazione regolatoria, gestione della knowledge base interna. Poi serve dare al manager interno tutto lo stack per orchestrare l’agente, dall’accesso ai modelli alla dimestichezza con MCP e tool calling, fino al controllo dei prompt e alle dashboard di monitoraggio. Infine, e qui è il passaggio che vedo più trascurato, quel manager va valutato non sull’output diretto ma sulla qualità con cui gestisce l’agente, esattamente come Stauber a Salesforce.

Questa logica funziona meglio quando si appoggia su un’architettura AI dentro al perimetro aziendale, perché un manager italiano che orchestra agenti su dati di clientela o su documentazione sensibile non può farlo bene se gli agenti girano su infrastruttura americana sotto Cloud Act. Senza sovranità del dato, il manager diventa supervisore di un sistema di cui non controlla i confini, e la sua funzione si svuota.

Il rischio che non discutiamo abbastanza

C’è una parte del lavoro manageriale che la sostituzione con agenti rischia di erodere, e credo valga la pena nominarla con calma. È il mentoring informale, quello che succede quando un giovane fa una domanda a un collega più anziano in corridoio, quando un junior osserva un senior gestire una telefonata difficile, quando un team-leader passa mezz’ora con un nuovo assunto per capire come ragiona.

Quel sapere tacito, che le aziende trasmettono per contagio quotidiano, ha bisogno di numero. Servono junior che facciano domande e senior che rispondano, e servono spazi fisici e mentali dove l’asimmetria di esperienza si trasforma in relazione di apprendimento. Se gli agenti rispondono prima e meglio, i junior smettono di chiedere ai colleghi e i senior smettono di formare, e l’azienda smette di trasferire memoria operativa. È una perdita che non si vede nei KPI trimestrali, si vede nel decennio.

In Pelle Digitale ho provato a descrivere il modo in cui l’interfaccia digitale media le nostre relazioni e modifica anche quello che credevamo di sapere su noi stessi. Vale lo stesso, in modo più specifico, dentro le organizzazioni. Un’azienda dove l’interlocutore di prima istanza è un agente, e non più il collega di stanza, è un’organizzazione diversa nella sostanza, non solo nelle prestazioni. Il buon manager di agenti del 2027 dovrà difendere attivamente gli spazi dove l’apprendimento informale avviene fra umani, perché non avverrà più da solo.

La domanda da porsi

Settembre 2026 sarà probabilmente il primo trimestre in cui molte aziende italiane medie metteranno in piedi i primi prototipi seri di agentic adoption, dopo la prova generale del 2025 e i pilot del 2026. Per chi guida quelle aziende, e per chi guida funzioni dentro quelle aziende, una domanda che vale la pena tenere davanti è semplice. Quale manager della mia organizzazione è già di fatto un orchestratore di agenti senza ancora averlo dichiarato, e quale invece sta rifiutando di diventarlo perché ne percepisce l’aliquota di disagio? Perché il primo va riconosciuto e formalizzato in fretta, prima che lo riconosca un concorrente. E il secondo va ascoltato, perché la sua diffidenza spesso vede cose che chi è già dentro non vede più.

26 Giugno 202619 Giugno 2026AI & GENAI, TECH & BUSINESS

Guidare Claude Code: la guida completa a skill, hook, subagent e regole

Il 18 giugno 2026 Anthropic ha pubblicato una mappa di tutti i modi in cui si può dire a Claude Code come comportarsi. Sono sette, e la cosa interessante non è l’elenco, è che ognuno di quei sette modi risponde a tre domande diverse: quando l’istruzione entra in memoria, se ci resta quando la sessione si allunga, e quanto è vincolante. Lavoro con questi agenti tutti i giorni, e ho imparato che la maggior parte degli errori di configurazione nasce dall’aver messo l’istruzione giusta nel posto sbagliato.

Per chi scrive codice da solo è una questione di efficienza. Per chi porta la responsabilità della tecnologia in un’azienda diventa qualcosa di più, perché la distanza tra un’istruzione e una garanzia è la stessa che separa una buona intenzione da una regola che nessuno può aggirare. Questa guida prova a mettere ordine: cosa sono i sette meccanismi, come si comportano quando la sessione cresce, e dove conviene scrivere ogni tipo di istruzione.

Ogni istruzione ha un costo e un’autorità

Ogni riga che finisce nella finestra di contesto di Claude occupa spazio e influenza il comportamento, e questi due effetti vanno tenuti insieme. Lo spazio è il costo: token che paghi a ogni richiesta, che l’istruzione serva o no in quel momento. L’autorità è il peso: quanto Claude segue quell’istruzione quando le cose si complicano, in una sessione lunga, in una situazione ambigua, o quando un file letto durante il lavoro contiene istruzioni nascoste che spingono in direzione opposta.

I sette meccanismi si distribuiscono lungo questi due assi. Alcuni costano molto e valgono sempre, altri costano poco perché entrano in scena solo quando servono, altri ancora non vivono affatto nel contesto perché sono codice che gira per conto suo. Sapere dove cade ciascuno è metà del lavoro. L’altra metà è una sola domanda, che torna a ogni scelta: questa cosa deve succedere quando il modello decide di farla, o deve succedere e basta?

CLAUDE.md, il file che Claude rilegge a ogni avvio

Il CLAUDE.md è un file markdown nella radice del progetto. Si carica all’inizio della sessione e ci resta per tutta la durata. Comandi di build, struttura delle cartelle, organizzazione di un monorepo, convenzioni di codice, norme del team: tutto questo sta bene qui, perché sono fatti che Claude deve avere sempre sottomano.

Ne esistono due tipi, e si comportano in modo opposto. Quello nella radice è sempre presente, sopravvive alle sessioni lunghe, e quando Claude Code comprime la conversazione per liberare spazio lo rilegge da capo. Quelli nelle sottocartelle invece si caricano su richiesta, solo quando Claude legge un file dentro quella cartella. Un app/api/CLAUDE.md non entra all’avvio, entra quando si tocca qualcosa sotto app/api, e sparisce di nuovo finché non si torna lì.

Il problema del file nella radice arriva con la scala. In un repository condiviso cresce come ogni configurazione senza padrone: ogni team aggiunge le sue righe, nessuno cancella niente, e quel testo si carica in ogni sessione di ogni persona, che riguardi il suo lavoro o no. Si pagano token, e si diluisce l’aderenza alle istruzioni che contano.

Il consiglio di Anthropic è di tenerlo sotto le duecento righe, dargli un proprietario, e trattarne le modifiche come si tratta il codice, con una revisione. Pensa a questo file come a un indice: una mappa del progetto che rimanda ad altri file dove Claude trova il dettaglio quando gli serve. Per le regole che devono valere su ogni repository dell’organizzazione, politiche di sicurezza o requisiti di conformità, esiste un CLAUDE.md gestito centralmente, distribuito sulle macchine via MDM, che il singolo non può escludere.

Le regole si caricano solo dove servono

Le regole sono file markdown dentro .claude/rules/, e danno a Claude vincoli o convenzioni precise. Senza un raggio d’azione si comportano come il CLAUDE.md: caricate all’avvio, rimesse dentro dopo ogni compressione, sempre presenti anche quando il compito non le riguarda.

Con il campo paths nell’intestazione cambia il momento del caricamento. Una regola legata a src/api/** resta fuori dal contesto durante una sessione che tocca solo la documentazione, e si carica unicamente quando Claude legge un file dentro quella cartella. L’intestazione si scrive così:

---
paths:
  - "src/api/**"
  - "**/*.handler.ts"
---
Ogni handler API deve validare l'input con Zod prima di processarlo.

Un vincolo legato a un file specifico, tipo le migrazioni che si possono solo aggiungere e mai modificare, sta bene come regola con il suo paths. Conviene preferire una regola con raggio d’azione a un CLAUDE.md annidato quando l’istruzione riguarda un aspetto trasversale, o un tipo di file che compare in più punti del codice ma non ovunque.

Le skill portano dentro la procedura al momento giusto

Le skill vivono in .claude/skills/, cartelle che contengono istruzioni, script e risorse, ognuna con un file SKILL.md fatto di nome, descrizione e corpo. All’avvio della sessione si caricano solo il nome e la descrizione. Il corpo entra quando la skill viene invocata, con un comando slash come /code-review oppure perché Claude riconosce che il compito corrisponde a quella descrizione.

/code-review è una skill già inclusa: legge le modifiche correnti e riporta cosa ha trovato senza toccare i file. La skill definisce il copione, e Claude segue lo stesso percorso ogni volta che la richiami. Quando la conversazione viene compressa, le skill già invocate vengono rimesse dentro fino a un tetto di token condiviso tra tutte: se ne hai usate molte nella stessa sessione, le più vecchie cadono per prime.

La regola pratica è corta. Le istruzioni procedurali, un flusso di deploy o una checklist di rilascio, stanno in una skill, non nel CLAUDE.md. Claude Code arriva con le sue skill, ma puoi scriverne di tue, ed è proprio quello che faccio per il lavoro editoriale e di consulenza, impacchettando in una cartella le procedure che ripeto.

Un agente separato per il lavoro che non vuoi leggere

I subagent sono file markdown in .claude/agents/, e definiscono assistenti isolati per compiti laterali. Ogni file ha un’intestazione YAML, nome e descrizione più eventuali campi per il modello e per gli strumenti a cui può accedere, seguita da un corpo che diventa il prompt di sistema di quel subagent.

Somigliano alle skill, perché all’avvio si caricano nome, descrizione ed elenco degli strumenti, mentre il corpo non si attiva da solo: Claude lo chiama tramite lo strumento Agent passandogli un prompt. La differenza vera è l’isolamento. Il corpo del subagent non entra mai nella conversazione principale. Il subagent gira in una finestra di contesto tutta sua, e al termine torna alla sessione madre solo il suo messaggio finale, spesso il risultato aggregato di molti passaggi, più qualche metadato.

Questo schema scala in un modo che vale la pena capire. I subagent si annidano fino a cinque livelli, e i flussi di lavoro dinamici orchestrano da decine a centinaia di agenti in background senza che tu debba specificare ogni dettaglio. Il piano di orchestrazione e i risultati intermedi vivono dentro variabili di script invece che nel contesto di Claude, e questo permette di crescere senza perdere fedeltà alle istruzioni.

L’isolamento è il motivo principale per scegliere un subagent invece di una skill. Lo usi quando un compito laterale, una ricerca profonda o l’analisi di un log ingombrerebbe la conversazione principale con risultati intermedi che non riguarderai più. Usi una skill quando vuoi che la procedura si svolga dentro il thread principale, sotto i tuoi occhi, un passaggio alla volta. La documentazione sui subagent entra nel dettaglio dei campi dell’intestazione e dei permessi sugli strumenti.

Gli hook girano fuori dal contesto

Gli hook sono comandi, endpoint HTTP o prompt che danno un controllo più deterministico sul comportamento di Claude, perché scattano su eventi precisi del suo ciclo di vita: una modifica a un file, una chiamata a uno strumento, l’avvio della sessione. Si registrano nel settings.json, nelle impostazioni gestite, o nell’intestazione di una skill o di un agente.

Ne esistono di cinque tipi: command, HTTP, mcp_tool, prompt e agent. Tutti scattano in modo deterministico, ma i primi tre eseguono codice, mentre prompt e agent usano il giudizio di Claude invece di una regola fissa per decidere l’output. Il costo in contesto è basso, perché la configurazione vive fuori dalla finestra principale. Qualche output può rientrare: l’errore di un hook che blocca un’operazione viene salvato nel contesto, così Claude sa perché la chiamata è stata negata. La maggior parte degli hook invece non lascia traccia, a meno che la configurazione non lo preveda. Se hai salvato la cronologia della chat in un altro file prima della compressione usando l’evento PreCompact, Claude non saprà in quale file l’hai messa.

È qui che gli hook si staccano dal CLAUDE.md, dalle regole e dalle skill. Servono per tutto ciò che deve accadere in modo deterministico: far girare un linter dopo ogni modifica, scrivere su Slack a lavoro finito, bloccare certi comandi prima che partano. Un hook PreToolUse può ispezionare qualunque chiamata a uno strumento e uscire con codice 2 per negarla. Costano poco perché sono codice che l’ambiente esegue, non istruzioni che Claude deve caricare e interpretare.

Output style e system prompt: l’autorità più alta

Gli output style sono file in .claude/output-styles/ che iniettano istruzioni nel prompt di sistema. Non vengono mai compressi, si caricano all’inizio di ogni sessione, e dopo la prima richiesta restano in cache, quindi il costo in contesto è moderato. Stando nel prompt di sistema portano il peso di aderenza più alto tra tutti i metodi visti finora, e vanno usati con misura.

C’è una trappola. Cambiare l’output style sostituisce quello predefinito, a meno che tu non imposti keep-coding-instructions: true nell’intestazione. In Claude Code questo cancella le istruzioni che dicono a Claude di star aiutando con un lavoro di ingegneria del software, e con loro abitudini critiche come quando aggiungere o togliere commenti al codice, come gestire le questioni di sicurezza, l’abitudine a far girare i test prima di dichiarare finito un lavoro. Senza accorgertene, Claude Code diventa un assistente generico invece di un assistente che programma. Prima di scriverne uno tuo, conviene guardare quelli già inclusi: Proactive, Explanatory e Learning coprono i bisogni più comuni.

L’alternativa più leggera è il flag append-system-prompt. Dove modificare un output style può avere effetti larghi e non voluti, il flag è solo additivo: non cambia il ruolo di Claude, gli aggiunge istruzioni. Si passa al momento dell’invocazione e vale solo per quella, non resta come file tra le sessioni. Costa qualche token in più in ingresso, attenuato dalla cache dopo la prima richiesta, ed è la via giusta per standard di codice specifici, formati di output, conoscenza di dominio. Con un avvertimento che vale per tutti i metodi a prompt: più istruzioni infili, meno Claude le segue alla lettera, soprattutto se qualcuna contraddice le altre.

Quando l’istruzione è nel posto sbagliato

Ci sono segnali che dicono che un’istruzione andrebbe spostata altrove. Se ti ritrovi a scrivere “ogni volta che X, fai sempre Y” nel CLAUDE.md, e quel comportamento deve essere affidabile, tipo far girare prettier dopo ogni modifica, quello è un hook nel settings.json. Il modello che sceglie di lanciare un formattatore è un’altra cosa rispetto al formattatore che parte da solo.

Se nel CLAUDE.md compare un “non fare mai questo”, l’istruzione è lo strumento sbagliato. Claude la seguirà quasi sempre, ma sotto pressione, in una sessione lunga, in una situazione ambigua, o per via di un’iniezione di prompt dentro un file aperto durante il compito, il modello può non rispettarla. Una barriera vera è deterministica, e si costruisce con gli hook e i permessi. Un hook PreToolUse ispeziona la chiamata ed esce con codice 2 per bloccarla. Le impostazioni gestite vanno oltre: le distribuisce un amministratore, l’utente non le può sovrascrivere, e sono l’unico modo per imporre una barriera deterministica su tutta l’organizzazione.

Una procedura di trenta righe nel CLAUDE.md va in una skill. Una regola che vale solo per src/api/** va scritta con il suo paths, perché senza è meccanicamente identica a mettere quel testo nel CLAUDE.md, sempre caricata, sempre a consumare token. E le preferenze personali, tipo usare sempre messaggi di commit semantici, vanno nei file a livello utente, che valgono per ogni sessione a prescindere dal repository, non nel file di progetto condiviso con il team.

Un’istruzione non è una garanzia

Tutto questo si riduce a una distinzione che per chi guida la tecnologia conta più di qualunque dettaglio di configurazione. Un’istruzione a prompt, stia nel CLAUDE.md o in una regola o in un output style, è una richiesta che il modello interpreta e quasi sempre rispetta. Una barriera costruita con hook e permessi è un fatto meccanico che non dipende dal giudizio del modello. La prima si piega sotto pressione, la seconda no. Quando in gioco ci sono dati sensibili, ambienti di produzione, o un comando che non deve partire mai, l’unica risposta seria è quella deterministica.

C’è anche un costo che si accumula nel tempo, e somiglia parecchio a quello di cui scrivo da mesi a proposito del debito cognitivo. Un CLAUDE.md senza proprietario cresce, e ogni riga in più si carica in ogni sessione di ogni persona, pesando sul budget di token e annacquando le istruzioni che servono. È un debito di contesto: lo paghi poco alla volta, finché un giorno la finestra è piena di righe che nessuno legge e il modello segue peggio quelle importanti. La cura è la stessa di sempre, un proprietario, una revisione, e la disciplina di spostare ogni istruzione dove il suo costo e la sua autorità corrispondono al compito.

Nei vari testi che scrivo da un po’ ho provato più volte a descrivere l’interfaccia tra la mente e gli strumenti che la estendono, e guidare un agente è proprio quel punto: il momento in cui un’intenzione umana si traduce in qualcosa che una macchina eseguirà al posto tuo. Quando hai qualcuno di questi meccanismi a posto, puoi raccoglierli insieme, skill, subagent, hook e output style, dentro un plugin, e condividere un assetto coerente con il team o tra i progetti.

Senza dubbio nei prossimi mesi questi strumenti diventeranno più semplici e più capaci. La domanda che resta aperta è chi, nella tua organizzazione, possiede la mappa di cosa Claude può e non può fare, e la tiene aggiornata mentre la finestra di contesto si riempie. Se è il genere di mappa che serve disegnare per la tua azienda, è una delle conversazioni che porto al tavolo nel mio lavoro di advisory.

Fonte: Anthropic, Steering Claude Code: CLAUDE.md files, skills, hooks, rules, subagents and more, 18 giugno 2026. Approfondimenti nella documentazione ufficiale su subagent e output style.

25 Giugno 202625 Maggio 2026AI & 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.

22 Giugno 202625 Maggio 2026AI & 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.

20 Giugno 202620 Giugno 2026AI & 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?

19 Giugno 202617 Giugno 2026AI & 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?

18 Giugno 202625 Maggio 2026AI & GENAI, TECH & BUSINESS

Installare LocalAI in azienda in 90 minuti: la guida operativa

Questo articolo è diverso dagli altri che ho scritto in questa serie su AI privata. Gli altri parlano di strategia, architettura, scelte di alto livello. Questo è una guida tecnica step-by-step. Se siete il CTO o il tech lead che ha deciso di portare un ecosistema AI privato dentro l’azienda e volete sapere esattamente cosa fare lunedì mattina per partire, è qui.

Lavoro come cofondatore di LocalAI.io dal 2023, e in questi anni ho visto centinaia di setup in produzione. Ho distillato in questa guida il percorso operativo che, a partire da un Mac Mini M4 Pro o un server Linux base, in 90 minuti porta un’azienda dal “non abbiamo niente” a un ecosistema AI privato completo, con gateway compatibile OpenAI, modello locale funzionante, vector database per il RAG, primo agente che risponde alle domande sui vostri documenti aziendali.

La guida è scritta per chi sa cosa è Docker e ha terminale aperto. Se siete completamente nuovi al mondo dell’infrastruttura container, vi consiglio di lavorare insieme a un developer che vi affianchi sui primi step. Il setup di base è semplice, ma la produzione richiede un occhio operativo.

Prerequisiti hardware e software

Per una prima installazione LocalAI di valutazione, ipotizziamo lo scenario più semplice: un Mac Mini M4 Pro 48 GB. Vanno bene anche un Linux server con almeno 32 GB di RAM, una workstation con RTX 4070 o superiore, oppure un server cloud privato italiano con GPU dedicata. Per produzione su 100+ utenti simultanei serve hardware più potente (vedere la mia guida hardware precedente).

Software preliminare: Docker installato e funzionante (Docker Desktop su Mac, Docker Engine + Compose v2 su Linux), 50 GB di spazio disco libero (i modelli pesano), connessione internet veloce per il primo download dei modelli, terminale e un editor di testo.

Verifica preliminare:

docker --version
docker compose version
df -h

Se Docker non è installato, fermarsi qui e installarlo (su Mac da docker.com, su Linux con i package manager standard). Procediamo assumendo che il setup di base sia pronto.

Step 1: avvio di LocalAI base (15 minuti)

Creiamo la cartella del progetto e il file Docker Compose minimo:

mkdir -p ~/ai-aziendale/{models,data}
cd ~/ai-aziendale

Creiamo il file docker-compose.yml:

services:
  localai:
    image: localai/localai:latest
    container_name: localai
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      - LOCALAI_API_KEY=cambia-questa-chiave-in-produzione
      - MODELS_PATH=/models
      - CONTEXT_SIZE=4096
      - THREADS=8
    volumes:
      - ./models:/models
      - ./data:/data

Se siete su server Linux con GPU NVIDIA, usate l’immagine localai/localai:latest-gpu-nvidia-cuda-12 e aggiungete la configurazione GPU sotto deploy.resources.reservations.devices.

Avviamo il container:

docker compose up -d

Il primo avvio scarica l’immagine, può richiedere 5-10 minuti a seconda della velocità della connessione. Verifichiamo che sia attivo con curl http://localhost:8080/readyz. Se vede risposta OK, LocalAI è in piedi. La Web UI è raggiungibile a http://localhost:8080.

Step 2: scaricare e caricare il primo modello (20 minuti)

LocalAI ha una galleria integrata di modelli pre-configurati. Per partire, scarichiamo Qwen 4 32B-A3B che è la mia raccomandazione di default per la PMI italiana (rapporto qualità/velocità ottimale).

Dalla Web UI: tab Models → cercare “qwen” → cliccare Install sul modello desiderato. In alternativa via CLI:

curl -X POST http://localhost:8080/models/apply 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer cambia-questa-chiave-in-produzione" 
  -d '{"id": "huggingface@Qwen/Qwen3-32B-A3B-Instruct"}'

Il download impiega 15-20 minuti per un modello da 32B (18 GB di peso quantizzato Q4). Quando il modello è caricato, testiamolo:

curl http://localhost:8080/v1/chat/completions 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer cambia-questa-chiave-in-produzione" 
  -d '{
    "model": "qwen3-32b-a3b",
    "messages": [
      {"role": "system", "content": "Rispondi in italiano professionale."},
      {"role": "user", "content": "Cosa sai dell AI Act europeo?"}
    ],
    "temperature": 0.7
  }'

Se la risposta arriva, il modello è funzionante. Su un Mac Mini M4 Pro, aspettate 50-70 token al secondo.

Step 3: integrare un’applicazione esistente (10 minuti)

LocalAI espone API completamente compatibili OpenAI. Qualsiasi applicazione che usa la libreria OpenAI può essere ripuntata sostituendo base_url e api_key. Esempio Python:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="cambia-questa-chiave-in-produzione"
)

response = client.chat.completions.create(
    model="qwen3-32b-a3b",
    messages=[
        {"role": "system", "content": "Sei un assistente aziendale."},
        {"role": "user", "content": "Riassumi il documento allegato in 3 punti."}
    ]
)

print(response.choices[0].message.content)

Da qui in poi, ogni applicazione AI che il vostro team ha sviluppato (chatbot, tool interni, integrazioni con CRM) può essere ripuntata su LocalAI con tre righe di codice. È il vero superpotere dell’API-compatibility: zero refactor.

Step 4: aggiungere il vector database per RAG (20 minuti)

Per RAG (Retrieval Augmented Generation), serve un vector database che indicizzi i documenti aziendali e li recuperi semanticamente durante le query. Qdrant è la scelta più equilibrata oggi.

Aggiungiamo Qdrant al docker-compose.yml:

  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"
      - "6334:6334"
    volumes:
      - ./qdrant_storage:/qdrant/storage

Restart dei container con docker compose up -d e verifica con curl http://localhost:6333/healthz.

Ora serve un modello di embedding per generare le rappresentazioni vettoriali dei vostri documenti. LocalAI supporta nativamente modelli di embedding. Carichiamo un modello multilingue:

curl -X POST http://localhost:8080/models/apply 
  -H "Content-Type: application/json" 
  -H "Authorization: Bearer cambia-questa-chiave-in-produzione" 
  -d '{"id": "huggingface@BAAI/bge-m3"}'

Step 5: ingestione documenti aziendali (15 minuti)

Carichiamo i documenti aziendali nel vector database. Script Python di esempio per indicizzare una cartella di PDF:

import os
from openai import OpenAI
from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct
from pypdf import PdfReader
import uuid

openai_client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="cambia-questa-chiave-in-produzione"
)
qdrant = QdrantClient(host="localhost", port=6333)

collection_name = "documenti_aziendali"
qdrant.recreate_collection(
    collection_name=collection_name,
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE)
)

docs_folder = "./documenti"
for filename in os.listdir(docs_folder):
    if not filename.endswith(".pdf"):
        continue
    reader = PdfReader(os.path.join(docs_folder, filename))
    for page_num, page in enumerate(reader.pages):
        text = page.extract_text()
        if not text.strip():
            continue
        chunks = [text[i:i+500] for i in range(0, len(text), 500)]
        for chunk in chunks:
            embedding = openai_client.embeddings.create(
                model="bge-m3",
                input=chunk
            ).data[0].embedding
            qdrant.upsert(
                collection_name=collection_name,
                points=[PointStruct(
                    id=str(uuid.uuid4()),
                    vector=embedding,
                    payload={"text": chunk, "filename": filename, "page": page_num}
                )]
            )
print("Indicizzazione completata.")

Questo script va eseguito una volta sui vostri documenti iniziali, poi pianificato per girare quando si aggiungono nuovi documenti (cron job, n8n workflow, manuale).

Step 6: il primo agente RAG (10 minuti)

L’ultimo pezzo: l’agente che usa il vector database per rispondere a domande sui vostri documenti.

from openai import OpenAI
from qdrant_client import QdrantClient

openai_client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="cambia-questa-chiave-in-produzione"
)
qdrant = QdrantClient(host="localhost", port=6333)

def chiedi(domanda: str) -> str:
    embedding = openai_client.embeddings.create(
        model="bge-m3",
        input=domanda
    ).data[0].embedding
    
    risultati = qdrant.search(
        collection_name="documenti_aziendali",
        query_vector=embedding,
        limit=5
    )
    
    contesto = "nn".join([r.payload["text"] for r in risultati])
    
    risposta = openai_client.chat.completions.create(
        model="qwen3-32b-a3b",
        messages=[
            {"role": "system", "content": "Rispondi solo sulla base del contesto fornito. Se non sai, dillo."},
            {"role": "user", "content": f"Contesto:n{contesto}nnDomanda: {domanda}"}
        ]
    )
    
    return risposta.choices[0].message.content

print(chiedi("Quali sono le regole sui rimborsi spese?"))

Eseguite lo script e ponete domande sui documenti che avete indicizzato. Se le risposte sono accurate, avete un primo agente AI RAG funzionante.

Da prototipo a produzione: cosa manca ancora

Quello che abbiamo costruito in 90 minuti è un prototipo funzionante. Per portarlo in produzione su 50-200 utenti aziendali servono altri tre componenti che vale la pena pianificare subito.

Autenticazione e gestione utenti. Il setup base usa una API key condivisa. In produzione serve SSO (Okta, Azure AD, Google Workspace), oppure almeno un sistema di user management. LocalAI supporta multi-tenancy nativo, va configurato.

Frontend. Per gli utenti finali serve un’interfaccia. Open WebUI è la scelta più rapida (compatibile OpenAI, si integra con LocalAI in cinque minuti). In alternativa, sviluppate un’interfaccia custom usando librerie come Vercel AI SDK o LangChain.

Monitoraggio e logging. Per l’AI Act servirà logging strutturato di tutte le interazioni, metriche di performance, alert su anomalie. LocalAI esporta metriche Prometheus, che potete agganciare a Grafana per dashboard di monitoraggio. Per il logging completo, vale la pena integrare un sistema come Langfuse o un equivalente custom.

Backup e disaster recovery. I modelli pesano decine di GB e sono difficili da redownlodare velocemente. Il vector database con i vostri documenti indicizzati è ancora più critico. Pianificare backup periodici delle cartelle models/ e qdrant_storage/.

Stack alternativo e specializzazioni

Lo stack base che ho descritto va bene per la PMI italiana media. Per scenari più specifici:

Per aziende che vogliono modelli multipli in parallelo (uno per chat, uno specializzato per estrazione strutturata, uno per codice): LocalAI gestisce nativamente più modelli, basta caricarli tutti e routare le richieste applicativamente.

Per workload server con alta concorrenza (200+ utenti simultanei): valutare vLLM come motore di inferenza sotto LocalAI, oppure deployment distribuito su più nodi GPU.

Per fine-tuning su dati aziendali specifici: LocalAI supporta fine-tuning LoRA. Setup più complesso, vale la pena partire dal supporto della community o di chi conosce il dominio.

Cosa fare nei prossimi 30 giorni

Una volta avviato lo stack di base, vale la pena pianificare le prime quattro settimane di adozione interna con metodo.

Settimana 1: setup completo (i 90 minuti di questa guida), indicizzazione di un primo corpus documentale ristretto (es. policy HR, FAQ tecniche), test con 3-5 utenti early adopter del team interno.

Settimana 2: raccolta feedback, miglioramento del system prompt, espansione del corpus a documenti aggiuntivi, prima integrazione con un sistema aziendale (CRM, helpdesk).

Settimana 3: apertura a 10-20 utenti, monitoraggio metriche (latenza, qualità delle risposte, errori), aggiunta del frontend Open WebUI o equivalente.

Settimana 4: valutazione roll-out più ampio, definizione del piano di scalabilità (più hardware, più modelli, integrazione con SSO aziendale), pianificazione governance.

Per chi sta valutando l’avvio di un ecosistema AI privato aziendale e vuole supporto operativo, c’è la pagina Advisory dove descrivo i formati di collaborazione che propongo. Per la community LocalAI in italiano, il canale Discord di LocalAI.io è il posto giusto.

La domanda finale, quella che cambia il modo di fare AI aziendale nei prossimi 12 mesi, è semplice. Lunedì mattina, avete in casa il vostro primo endpoint AI privato funzionante? Se la risposta è no, questa guida vi dà tutto quello che serve per cambiarla entro le 12.

18 Giugno 202617 Giugno 2026AI & GENAI, TECH & BUSINESS

Guerra dei prezzi AI: la difendibilità si sposta sul controllo dell’inferenza

Il 13 giugno il Wall Street Journal ha raccontato la fuga verso i modelli cinesi: aziende e startup, sfiancate dal conto dei token, che spostano i carichi di lavoro su alternative più economiche e quasi sempre open source. Bradley Olson racconta di strumenti che fanno rimbalzare il lavoro da un modello all’altro, Claude o ChatGPT per i compiti che lo meritano, modelli aperti per tutto il resto. OpenAI e Anthropic, tutte e due con il fascicolo per la quotazione già depositato, stanno valutando di tagliare i prezzi.

Sotto la cronaca del taglio c’è un movimento più lento, e per chi quei sistemi li mette in produzione conta molto di più. La guerra dei prezzi AI sta spaccando il mercato in due, e le due metà non si difendono allo stesso modo. Da una parte i volumi, che scivolano verso il basso costo. Dall’altra il valore, che resta in alto, dove le capacità di frontiera sono ancora poche e ancora difficili da replicare.

I volumi seguono i modelli cinesi

Il pavimento dei prezzi lo ha colato DeepSeek, e da lì in giù si è mosso tutto il resto. Su OpenRouter, la piattaforma di instradamento che migliaia di sviluppatori usano per scegliere a chi mandare le proprie richieste, i modelli cinesi pesano oggi intorno al 46% del traffico identificato. Anthropic, Google e OpenAI messe insieme stanno sotto al 36. Un anno fa i cinesi erano sotto il due per cento. Qwen, DeepSeek, Kimi, GLM, MiniMax: nomi che fino a poco fa nessun ufficio acquisti pronunciava, e che adesso girano dentro metà dei flussi agentici del pianeta.

La ragione è prosaica, e la dice bene un investitore citato nel pezzo, Tommy Shaughnessy di Delphi: il modello è il costo più grosso per chi vende inferenza, e questi se lo ritrovano gratis. I laboratori cinesi rilasciano modelli di livello frontiera come pesi aperti, chi fa inferenza li serve a costo quasi azzerato, e il prezzo finale crolla a una frazione, da sette a cinquanta volte meno a seconda del confronto che si fa. Per moltissimo lavoro quotidiano, una sintesi o una classificazione o una bozza da rifinire, la differenza di qualità tra i modelli cinesi e quelli di punta semplicemente non si vede in busta paga. E nel frattempo i conti dei token diventano insostenibili: c’è chi, come Uber, ha bruciato l’intero budget AI dell’anno entro aprile.

Il prezzo basso ha un indirizzo

Un modello che costa quasi niente è comodo, fino al momento in cui ti accorgi da dove arriva, e che quel quasi niente per chi lo produce ha una funzione. GLM-5 di Zhipu è addestrato e servito su silicio Huawei Ascend, niente NVIDIA: per le imprese e gli enti cinesi quell’indipendenza dall’hardware americano vale più di un punto di benchmark. Distribuire frontiera come open weight, a costo zero per il mondo, è anche una mossa di quota e di influenza, un loss leader giocato su scala geopolitica.

Negli Stati Uniti la cosa ha già smesso di essere teorica. Ad aprile la commissione della Camera sul Partito Comunista Cinese ha aperto un’indagine su Airbnb e Anysphere per l’uso di modelli cinesi, segno che dentro un’app che usi ogni giorno può girare inferenza che a qualcuno, a Washington, non piace affatto. E l’Europa, in questa mappa, è quasi un buco: tanti utilizzatori, pochissimi produttori, con Mistral come eccezione più citata che strutturale. Dipendere da una sola sponda è un rischio già scomodo. Appoggiare il proprio lavoro su due sponde lontane, e su nessun pezzo di casa, è una postura che vale la pena guardare prima che diventi un vincolo.

Il routing come punto di controllo

Lo strumento che il Wall Street Journal descrive, quello che smista il lavoro tra modello esterno, sistema interno e open source self-hosted, è la cosa più importante dell’articolo, e quasi nessuno la nomina. Nel momento in cui i modelli diventano intercambiabili e quasi gratuiti, il pezzo di valore si sposta su chi decide dove va ogni richiesta, con quali regole, con quali dati, dentro quali confini. Orchestrazione, routing, inferenza locale: qui si gioca il margine, e qui si gioca la difendibilità.

È lo stesso filo che avevo provato a tirare quando una direttiva americana ha spento Fable 5 e Mythos 5 in tutto il mondo: in produzione vince meno il modello migliore e vince di più chi controlla l’instradamento e tiene l’inferenza vicina. Per chi compra in azienda, e ancora di più per una pubblica amministrazione o un settore regolato, questo livello smette di essere un dettaglio da architetti e diventa oggetto di governance, e materia da mettere a gara: la domanda da scrivere nel capitolato diventa chi orchestra, dove gira il carico, cosa esce dal perimetro, più che quale modello ci sia in fondo. È esattamente la direzione di prodotto su cui lavoro con LocalAI, inferenza che resta dentro casa.

La frontiera resta un permesso, non una proprietà

L’altra metà del cielo, quella del valore, ha una sua fragilità che il prezzo basso ci fa dimenticare. Le capacità di punta restano accessibili a condizioni decise da altri. Anthropic ha pubblicato la classe Mythos con due nomi e due regole: Fable con i guardrail, che dirotta le richieste su cyber, bio e chimica verso un modello più sorvegliato, e Mythos vero e proprio, senza freni pubblici, riservato a un programma ristretto. Sopra questa scelta industriale è arrivata la geopolitica, con il blocco all’export che ha staccato i modelli di frontiera dal resto del mondo da un giorno all’altro.

Chi costruisce sopra una API di frontiera costruisce sopra un permesso. Un permesso ottimo, potente, conveniente finché dura, e revocabile per ragioni che non dipendono da te: una direttiva o una decisione di sicurezza nazionale presa in un fuso orario lontano. Tenere tutto il valore della propria azienda dentro quel permesso è una scommessa che in pochi farebbero a occhi aperti, se la guardassero per quello che è.

Costruire da qui con quello che si controlla

Da questa biforcazione non si esce scegliendo una metà contro l’altra. La frontiera serve, per i compiti dove la differenza si vede e si paga. L’open economico serve, per il volume. Quello che cambia è dove si mette il proprio baricentro, e quanto del proprio destino si lascia in mano a un listino o a un permesso altrui.

Per un’organizzazione che parte adesso, e parte da qui, il punto fermo viene prima della tecnologia. Prima il metodo, la mappa di quello che quel processo fa davvero, di quali dati non possono uscire, di dove la frontiera vale il prezzo e dove i modelli cinesi aperti bastano e avanzano. Poi la tecnologia, scelta su quella mappa: orchestrazione propria, inferenza che si può portare in casa, libertà di cambiare modello senza riscrivere l’azienda. In Pelle Digitale avevo descritto la tecnologia come una superficie che ci portiamo addosso, e una pelle si sceglie con cura, non si appalta al primo che la regala. La velocità di mettere AI in produzione, ormai, ce l’avranno tutti. La difendibilità, quella, resta di chi controlla il proprio stack.

Senza dubbio la domanda che lascio aperta è semplice: del valore che la tua azienda affida all’AI, quanta parte vive su qualcosa che puoi spegnere tu, e quanta su qualcosa che possono spegnere altri?