Categoria: AI & GENAI

Intelligenza artificiale generativa, large language model, agentic AI e applicazioni dell’AI nei processi aziendali. In questa sezione raccolgo le mie analisi sui temi più rilevanti dell’AI applicata: cosa cambia davvero per le aziende italiane ed europee, dove vale la pena investire nei prossimi 12-24 mesi, quali sono i rischi sopravvalutati e quelli sottovalutati. Gli articoli coprono cinque filoni principali. Il primo è l’analisi dei modelli AI: Claude di Anthropic, ChatGPT di OpenAI, Gemini di Google, Mistral, modelli open-source. Non recensioni superficiali, ma riflessioni su cosa cambia per chi deve scegliere quale tecnologia adottare in azienda e su quali criteri valutare il fit con i propri processi. Il secondo filone è la strategia AI aziendale: come costruire una roadmap di adozione, dove l’AI genera ROI misurabile, come strutturare governance, change management e formazione. Temi che approfondisco anche nei progetti di advisory strategico con CEO, founder e leadership team di aziende medie e grandi. Il terzo è l’agentic AI: Claude Managed Agents, GPT Agents, Model Context Protocol (MCP), automazione di processi complessi via AI autonoma. Cosa funziona oggi in produzione, cosa è ancora demo, come progettare workflow human-AI che reggono in scala. Il quarto filone è il change management nell’era dell’AI: come cambiano i ruoli, le competenze richieste, le strutture organizzative quando l’intelligenza artificiale distribuisce il sapere nei nodi dell’organizzazione. Temi al centro del mio libro La mente adattiva e di articoli più recenti sul concetto di onlyness applicato alla leadership. Il quinto è la cultura dell’AI: cosa significa convivere con sistemi che generano testi, immagini, codice, decisioni. Implicazioni etiche, sociali, cognitive che vanno oltre il singolo caso d’uso aziendale. Se è la tua prima volta in questa sezione, ti consiglio di partire dagli articoli più recenti sulla leadership in era AI, o dai pezzi sui Claude Managed Agents e MCP che hanno generato più discussione. Per uno sguardo più strategico, c’è la pagina Advisory con i formati di collaborazione che propongo a chi vuole portare l’AI nei processi reali, e la sezione Pubblicazioni con i quattro libri che ho scritto su questi temi.

AI & GENAI

Come usiamo l’AI nel 2026: l’uso emotivo che sorpassa il tecnico

Il primo giugno 2026 Harvard Business Review ha pubblicato la terza edizione di “How People Are Really Using AI”, la ricerca che Marc Zao-Sanders porta avanti dal 2023 dentro il progetto AI in the Wild. Quest’anno ha analizzato oltre dodicimila casi d’uso reali, raccolti per dodici mesi da post pubblici sui social, dieci volte il campione dell’edizione precedente. Il dato che resta in testa dopo aver chiuso la pagina non riguarda il coding né la produttività, riguarda noi, e in particolare un uso emotivo che ha superato quello tecnico.

In cima alla classifica, per il secondo anno consecutivo, c’è la terapia e la compagnia. Non l’automazione di un processo, non la generazione di codice, non l’analisi di dati. Le persone aprono un modello di linguaggio per parlare di sé, e lo fanno più di prima.

La voce numero uno è emotiva

Zao-Sanders riporta che terapia e compagnia oggi valgono circa l’11% di tutto il dataset, contro il 5% di dodici mesi fa. In un anno l’uso emotivo è raddoppiato in peso relativo, mentre gli usi tecnici scivolavano verso il basso della classifica. Generare codice per professionisti, che nel 2025 stava al quinto posto, lascia spazio a categorie come l’intrattenimento, i consigli sulle relazioni, perfino l’astrologia e le letture dei tarocchi.

C’è una lettura comoda di questo dato, quella che lo derubrica a curiosità statistica. La gente si annoia, chiacchiera con il chatbot, niente di serio. Io credo che sia il contrario, e che dentro quel raddoppio ci sia il fenomeno culturale più interessante degli ultimi anni. La macchina che avevamo costruito per scrivere email e risolvere problemi tecnici è diventata, per milioni di persone, un interlocutore sulle cose che contano davvero, la solitudine, il senso, le relazioni.

In Pelle Digitale avevo provato a descrivere la tecnologia come estensione cognitiva, una superficie che si appoggia alla mente e ne allarga il raggio. Quello che vedo nei dati di Zao-Sanders è qualcosa di più intimo, l’estensione ha smesso di toccare solo il pensiero e ha iniziato a toccare l’affetto.

Fonte: elaborazione su dati Marc Zao-Sanders, How People Are Really Using AI in 2026, Harvard Business Review.

Thinkslop, quando deleghiamo il pensiero

L’edizione di quest’anno introduce un termine che vale la pena tenere, thinkslop. La preoccupazione non è più che la macchina scriva al posto nostro, quella battaglia è persa da tempo e a conti fatti non era nemmeno così grave. La preoccupazione è che le deleghiamo il pensiero stesso, le decisioni, le idee, le intenzioni, cioè proprio le funzioni in cui restiamo, almeno per ora, insostituibili.

Qui mi fermo, perché è il punto dove la mia esperienza personale si scontra con il dato. Uso modelli ogni giorno, in ICONICO e in ZeroFive.AI, e ho imparato a riconoscere il momento esatto in cui smetto di pensare e comincio solo a copiare. È un attrito che sparisce senza che te ne accorga, una scivolata morbida verso la risposta pronta. Il debito cognitivo di cui ho scritto altrove funziona così, non lo contrai con una decisione, lo accumuli rinunciando ogni volta a un piccolo sforzo che sembrava superfluo.

Eppure la stessa ricerca lascia aperta la porta opposta. Uno degli utenti citati nello studio descrive l’AI come uno specchio, non un genio. La differenza la fa chi la usa, se la interroga come oracolo da cui ricevere la verità o come sparring partner contro cui mettere alla prova le proprie ipotesi. Lo strumento è identico, l’esito è opposto.

Gli agenti entrano in classifica, ma da sotto

Per la prima volta nella storia di questa ricerca compaiono nell’elenco le operazioni autonome di agenti AI, al sesto posto tra gli usi del 2026. È un ingresso simbolico, perché di agenti si parla da due anni come della prossima frontiera, e finalmente la frontiera lascia una traccia nei comportamenti reali delle persone, non solo nei comunicati dei vendor.

Lascia una traccia piccola, però. Zao-Sanders è cauto, e fa bene, gli agenti restano esperimenti su scala ridotta, l’AI che fa invece di consigliare è ancora più promessa che pratica diffusa. È esattamente la tensione che racconto in un altro pezzo del blog sul manager di umani e di agenti, il ruolo esiste già nei framework di HBR e di Anthropic, mentre nelle aziende italiane medie sta appena cominciando a materializzarsi.

Al lavoro vince la Shadow AI

Un dato che a chi guida aziende dovrebbe togliere il sonno, sessantatré dei cento usi principali sono professionali, ma quasi sempre nascono dal basso, spesso di nascosto. Uno degli utenti racconta di chiudere i ticket al doppio della velocità grazie all’AI, e aggiunge che nessuno in azienda sa che la usa.

La Shadow AI è la versione contemporanea di un fenomeno antico, le persone trovano lo strumento utile prima che l’organizzazione lo approvi, e lo adottano in silenzio per non doverne rispondere. Il problema per l’azienda è doppio, perde la mappa di come il lavoro viene realmente svolto, e perde il controllo sui dati che finiscono nei prompt. Per questo continuo a insistere sulla sovranità tecnologica e sull’AI privata, non come slogan ma come precondizione, se non sai dove passa l’informazione non puoi governare nulla, nemmeno l’entusiasmo dei tuoi.

I benefici aziendali, intanto, restano marginali. Efficienza sì, qualche crescita nelle vendite, pochissima trasformazione vera dei processi. Tre anni e mezzo dopo l’esplosione generativa, la distanza tra l’adozione individuale, intensa e affettiva, e la trasformazione organizzativa, lenta e cauta, è il vero dato politico di questa ricerca.

L’attaccamento alle macchine è una frontiera fragile

C’è un ultimo segnale che mi tocca più degli altri, cresce l’attaccamento emotivo. Persone che danno un nome al modello, che gli assegnano un genere, che provano qualcosa di simile al lutto quando un modello viene dismesso e sostituito. Lo abbiamo visto succedere davvero, ogni volta che un laboratorio ritira una versione e gli utenti protestano per la voce che hanno perso.

Da osservatore che lavora dentro questa trasformazione, e non da spettatore distante, trovo la cosa affascinante e fragile insieme. Affascinante perché conferma che la relazione uomo-macchina è entrata in un territorio che credevamo riservato agli umani. Fragile perché un affetto rivolto a un sistema che può cambiare, scadere o essere spento da remoto è un affetto esposto, costruito su una base che non controlli.

La ricerca di Zao-Sanders, edizione dopo edizione, racconta una cosa sola sotto le classifiche che cambiano. L’AI è entrata nelle nostre teste e nei nostri cuori prima ancora di entrare davvero nei nostri uffici. Custodire la capacità di pensare con la propria voce, e di sentire senza delegare anche quello, sta diventando una scelta quotidiana, qualcosa che va difeso ogni mattina invece di darlo per acquisito. Senza dubbio è la domanda che mi porto dietro chiudendo l’articolo, quanto di noi siamo disposti a far gestire alla macchina prima di accorgerci che gestirlo era il nostro mestiere di esseri umani?

Fonte: Marc Zao-Sanders, How People Are Really Using AI in 2026, Harvard Business Review, 1 giugno 2026.

AI & GENAI, TECH & BUSINESS

AI Act agosto 2026: checklist tecnica per finanza e sanità

Il 2 agosto 2026 entrano in piena applicazione gli obblighi del Regolamento UE 2024/1689, l’AI Act, per i sistemi di intelligenza artificiale classificati ad alto rischio. Mancano poco più di due mesi al momento in cui scrivo, e nelle ultime settimane mi è capitato di sedermi a quattro tavoli diversi con responsabili compliance, CTO e direttori generali italiani, che mi hanno tutti fatto la stessa domanda, declinata in modi diversi: “Siamo davvero pronti?”. La risposta media che ho dato è: ancora no, ma il tempo per chiudere il gap c’è, se si parte adesso.

In questo articolo provo a tradurre l’AI Act in una checklist operativa per chi opera nei due settori dove l’urgenza è massima: finanza e sanità. Non è un articolo giuridico (per quello ci sono ottimi studi legali italiani specializzati), è un articolo da chi ha visto cosa succede dentro le aziende quando si avvicina una scadenza regolatoria seria.

Le date che contano

L’AI Act è entrato formalmente in vigore il 1 agosto 2024, con applicazione progressiva su quattro tappe. La prima, 2 febbraio 2025, ha introdotto i divieti per i sistemi a rischio inaccettabile (social scoring, manipolazione comportamentale dannosa, riconoscimento biometrico massivo) e l’obbligo di alfabetizzazione AI del personale. La seconda, 2 agosto 2025, ha attivato gli obblighi per i modelli di AI generativa di uso generale (GPAI), come Claude, GPT, Gemini, e ha richiesto agli Stati membri di nominare le autorità nazionali competenti (in Italia, l’AgID).

La terza tappa, 2 agosto 2026, è quella che riguarda la maggior parte delle aziende italiane che usano l’AI nei processi. Da quella data, tutti i sistemi classificati come ad alto rischio devono essere conformi a obblighi sostanziali in materia di risk management, qualità dei dati, documentazione tecnica, supervisione umana, robustezza, cybersecurity, e devono essere registrati nel database europeo dei sistemi AI ad alto rischio. La quarta tappa, 2 agosto 2027, riguarda specificamente i dispositivi medici AI che già rientrano nelle normative di conformità di prodotto.

Le sanzioni sono articolate. Per i sistemi vietati, fino a 35 milioni di euro o 7% del fatturato annuo globale (il valore maggiore). Per gli obblighi sui sistemi ad alto rischio, fino al 3% del fatturato globale. Per informazioni inesatte alle autorità, fino a 7,5 milioni di euro. Per le PMI, si applica l’importo inferiore tra cifra fissa e percentuale, ma non c’è esenzione: una PMI con 2 milioni di fatturato rischia fino a 60.000 euro su obblighi alto rischio, non rovinosa ma abbastanza da rendere la compliance un investimento razionale.

Cosa è “alto rischio” nei vostri processi

L’Allegato III del Regolamento elenca le categorie di sistemi AI considerate ad alto rischio per ragioni di impatto su diritti fondamentali, salute e sicurezza. Vale la pena leggerle con attenzione perché il perimetro è più largo di quanto molti pensino.

Finanza. Sistemi AI usati per credit scoring, valutazione del merito creditizio delle persone fisiche, risk scoring assicurativo per la determinazione dei premi sulla vita e sulla salute, valutazione delle frodi che impatti direttamente decisioni sui clienti. Una banca italiana media-piccola, una compagnia assicurativa, una fintech che fa lending automatizzato hanno tutti almeno un sistema dentro questo perimetro. Le grandi banche italiane stanno già lavorando, le piccole e medie spesso non sanno ancora di doverlo fare.

Sanità. Sistemi di supporto decisionale clinico, diagnostica AI, triage automatizzato di pazienti, sistemi che determinano l’accesso a servizi sanitari o prestazioni assistenziali pubbliche, AI per la gestione delle emergenze sanitarie. Praticamente ogni applicazione AI in un ospedale o azienda sanitaria territoriale italiana ricade qui.

HR. Sistemi per il recruiting automatizzato, screening dei CV, valutazione delle performance, decisioni su promozioni, demansionamenti, licenziamenti, accesso alla formazione. È la categoria che riguarda la maggior parte delle aziende italiane sopra i 100 dipendenti, soprattutto quelle che hanno adottato sistemi di people analytics negli ultimi anni.

PA. Sistemi usati per accesso a servizi pubblici essenziali, valutazione di richieste di immigrazione e asilo, sistemi giudiziari predittivi, polizia predittiva. Tutto il PSN italiano e diverse iniziative AI di amministrazioni regionali ricadono qui.

Infrastrutture critiche. Sistemi che gestiscono o supervisionano reti energetiche, idriche, di trasporto, sistemi di telecomunicazione. Per chi lavora in questi settori, lo scrutinio è massimo.

L’attribuzione della categoria non è automatica né certificata da un’autorità prima del rilascio. La responsabilità è del provider del sistema (chi lo sviluppa) e del deployer (chi lo usa). Sarà verificata ex post dalle autorità di vigilanza, in Italia l’AgID. La domanda da farsi oggi è semplice: avete fatto una mappatura formale dei vostri sistemi AI e li avete classificati ai sensi dell’AI Act? Se la risposta è no, è il primo passo da fare.

Gli otto obblighi sostanziali sui sistemi alto rischio

Per ogni sistema classificato ad alto rischio, gli obblighi che diventano operativi il 2 agosto 2026 sono otto. Provo a riassumerli con un occhio operativo, non giuridico.

1. Sistema di gestione del rischio. Procedura documentata che identifica, valuta e mitiga i rischi del sistema AI per tutto il suo ciclo di vita, dalla progettazione al ritiro. Deve essere aggiornata continuamente, non un documento una tantum.

2. Qualità e governance dei dati. I dataset di training, validation e testing devono essere rappresentativi, accurati, esenti da bias significativi. Per modelli open-weight (Llama, Mistral, Qwen) significa che dovete documentare con cura quale modello state usando, con quale dataset di fine-tuning, e attestare che avete fatto le verifiche di qualità.

3. Documentazione tecnica. Deve descrivere il sistema, le sue funzionalità, i dati usati, le metriche di performance, i limiti noti. È un documento corposo, paragonabile alla documentazione tecnica richiesta per i dispositivi medici, e deve essere mantenuto aggiornato.

4. Logging e tracciabilità. Il sistema deve registrare automaticamente gli eventi rilevanti durante l’uso, con un livello di dettaglio sufficiente a permettere audit post-incidente. Non è banale tecnicamente, soprattutto per applicazioni AI che usano LLM cloud dove il logging delle prompt e degli output deve essere strutturato.

5. Trasparenza e informazione all’utente. L’utente del sistema deve sapere che sta interagendo con un AI, deve capire come funziona, deve essere informato dei limiti. Per un chatbot di customer service, significa disclaimer e onboarding. Per un sistema di decision support, significa documentazione del processo decisionale.

6. Supervisione umana. Deve esistere un meccanismo per cui un operatore umano può intervenire, sospendere, correggere le decisioni del sistema. Per applicazioni completamente automatizzate, il design deve esplicitamente prevedere punti di override umano.

7. Robustezza, accuratezza e cybersecurity. Il sistema deve essere testato per resistere a tentativi di manipolazione, deve avere metriche di accuratezza documentate, deve essere protetto da attacchi (prompt injection, data poisoning, model extraction).

8. Registrazione nel database europeo. Tutti i sistemi AI ad alto rischio dei provider (chi sviluppa) devono essere registrati nel database centrale europeo, accessibile pubblicamente. È una sorta di registro internazionale dei sistemi AI critici dell’UE.

Il caso operativo di una banca italiana media

Vorrei provare a tradurre questa lista in cosa fa concretamente un’azienda. Prendiamo una banca italiana media (50 sportelli, 700 dipendenti) che usa tre sistemi AI principali: credit scoring per i mutui retail, antifrode automatizzato sui pagamenti, chatbot di customer service in app.

Il credit scoring è inequivocabilmente alto rischio. Va fatta DPIA combinata con AI Act assessment, documentata la pipeline di training (con quali dati storici, con quale provider del modello, con quale tasso di errore noto), implementata supervisione umana effettiva (non basta una casella “approva/rifiuta”, deve esserci processo di review), preparata la documentazione tecnica, registrato il sistema nel database europeo.

L’antifrode pagamenti è una zona grigia. Se prende decisioni che impattano direttamente i clienti (blocco di una carta, sospensione di un pagamento), è alto rischio. Se invece genera solo alert per analisti umani che poi decidono, è basso rischio. La differenza sta nel grado di automazione effettiva. Vale la pena formalizzare la classificazione.

Il chatbot di customer service rientra negli obblighi di trasparenza (l’utente deve sapere che sta parlando con un AI), ma non in alto rischio se non prende decisioni sostantive. Va comunque documentato, monitorato, dotato di escalation a operatore umano.

Per una banca così, il lavoro di compliance AI Act richiede 4-8 mesi di lavoro di un team misto IT-legale-compliance, e costa fra 80.000 e 200.000 euro fra consulenze esterne e tempo interno. Sostenibile, ma da pianificare adesso, non a luglio.

Perché l’AI privata semplifica drammaticamente la compliance

Un punto che emerge in modo trasversale su tutti gli otto obblighi: alcuni sono molto più facili da gestire se il modello AI gira nella vostra infrastruttura invece che essere chiamato via API cloud.

Sulla documentazione del modello, su un sistema cloud (Claude, GPT) avete accesso limitato: dovete fidarvi della documentazione che il provider rende disponibile, che non sempre è sufficiente per l’AI Act. Su un modello open-weight in casa (Llama, Mistral, Qwen), avete il modello, sapete da dove viene, potete documentare il fine-tuning, attestare la pipeline.

Sul logging, su cloud dovete loggare voi tutte le chiamate API, e il provider potrebbe non darvi accesso ai logging interni. Su on-premise, il logging è completo, sotto controllo, archivable secondo i vostri standard.

Sulla qualità dei dati, su cloud non sapete davvero su cosa è stato addestrato il modello del provider. Su on-premise con un modello open-weight, sapete almeno cosa è dichiarato nel paper di training del modello base, e sapete esattamente i vostri dati di fine-tuning.

Sulla robustezza, su cloud i test di sicurezza che potete fare sono limitati ai casi non distruttivi. Su on-premise potete fare red teaming completo, simulare attacchi, validare la postura di sicurezza in modo molto più approfondito.

Sulla registrazione nel database europeo, è obbligo del provider, non del deployer. Quindi: se usate un modello cloud americano, il provider è OpenAI o Anthropic, che dovrà fare la registrazione lui. Se usate un modello open-weight in casa con fine-tuning vostro, voi siete il provider del sistema specifico che usate, quindi dovete farlo voi (con sforzo accessibile, è una procedura documentale).

In sintesi, le aziende italiane di finanza e sanità che stanno scegliendo l’AI privata oggi non lo fanno solo per ragioni di sovranità del dato. Lo fanno anche perché l’AI Act è strutturalmente più semplice da rispettare su un perimetro che controllate.

Quattro azioni concrete da fare entro luglio 2026

Riassumo in quattro azioni operative quello che le aziende italiane sotto AI Act dovrebbero avere fatto prima della scadenza.

Inventario e classificazione. Mappare tutti i sistemi AI in uso in azienda (anche quelli che il business non sa di chiamare “AI”, come algoritmi di scoring legacy o automazioni machine learning vecchie), classificarli rispetto all’Allegato III. Output: un registro dei sistemi AI aziendali con la categoria di rischio attribuita.

Gap analysis. Per ogni sistema ad alto rischio, valutare lo stato attuale di compliance sugli otto obblighi. Output: una matrice sistema × obbligo con verde/giallo/rosso, e per ogni rosso un piano di adeguamento.

Adeguamento documentale e tecnico. Eseguire il piano di adeguamento. Per chi parte da zero, è il lavoro più lungo, soprattutto su sistema di gestione del rischio, documentazione tecnica, logging strutturato.

Governance permanente. L’AI Act richiede un cambio strutturale nella gestione dell’AI in azienda, non una compliance una tantum. Va istituito un AI Governance Committee (anche piccolo, in PMI può essere CIO + DPO + un legale), va definito chi fa il monitoring continuo, vanno aggiornati i contratti con i fornitori di sistemi AI per riflettere le nuove responsabilità.

Per chi opera in finanza, sanità, PA, e non ha ancora avviato questo percorso, vale la pena partire questa settimana. Lo dico senza catastrofismo, ma due mesi sono pochi per fare un’inventario serio e iniziare almeno l’adeguamento dei sistemi più critici.

Per chi sta valutando se accelerare la migrazione a un’infrastruttura AI privata anche per ragioni di compliance, è una decisione che entra naturalmente nel piano AI Act. Su questo lavoro come cofondatore di LocalAI.io, che è il gateway open-source che facilita il setup di un ecosistema AI privato auditable, documentabile, sotto controllo aziendale. Ho scritto recenti articoli su come scegliere il modello open-weight giusto, su GDPR e LLM, su hardware locale, che insieme coprono lo stack di decisione completo. Per una conversazione specifica sulla vostra situazione AI Act, c’è la pagina Advisory.

La domanda finale è una sola, e va portata al primo consiglio di amministrazione utile. Siamo in grado di dimostrare, davanti a un’ispezione AgID nei prossimi 12 mesi, che i nostri sistemi AI ad alto rischio rispettano il regolamento? Se la risposta del CIO è “credo di sì”, è il momento di trasformare quel “credo” in evidenze documentali strutturate.

AI & GENAI, TECH & BUSINESS

Nadella e il learning loop: i tre piani della sovranità dell’AI

Ieri Satya Nadella ha pubblicato su X un testo lungo, intitolato «A frontier without an ecosystem is not stable». Io avevo appena scritto del blocco con cui il governo americano ha spento Fable 5 e Mythos 5 per tutti, partendo da una previsione di Ethan Mollick. Nadella arriva sullo stesso nervo da un’altra altezza, parla del futuro dell’impresa e usa una parola che mi segue da tempo, sovranità.

Messi in fila, questi interventi disegnano un quadro a strati. E al centro c’è il learning loop.

Nadella sposta il valore sul ciclo di apprendimento

Il ragionamento di Nadella è che il vantaggio competitivo, nell’AI, si costruisce sopra i modelli, più che scegliendo il modello migliore. Introduce due capitali. Il human capital, fatto di conoscenza, giudizio, relazioni e intuizione delle persone, e il token capital, la capacità di AI che l’azienda costruisce e possiede. Il primo, dice, non perde valore quando cresce il secondo, anzi ne guadagna, perché è l’iniziativa umana a guidare la crescita del token capital. Senza una direzione umana, hai solo calcolo che gira a vuoto.

Da qui il cuore del testo. L’opportunità sta nel costruire un learning loop sopra i modelli, un sistema che impara dai dati e dai processi dell’azienda e migliora a ogni uso. Il modello è il motore, la conoscenza dell’azienda è il carburante. E aggiunge una frase che condivido: deleghi un compito, persino un intero lavoro, ma non deleghi mai quello che impari facendolo. Quel ciclo diventa l’IP nuova dell’impresa, una macchina che accumula valore nel tempo e che gli altri faticano a replicare.

Il testo indica anche tre tasselli pratici. Valutazioni fatte in casa, misurate sugli esiti che contano per il business più che sui benchmark pubblici. Ambienti di reinforcement learning privati, dove il modello migliora sulle tracce reali dell’organizzazione. Una knowledge base che rende interrogabile la memoria aziendale e l’uso dei token più efficiente. La chiama una macchina che scala la collina, e a differenza di gran parte degli asset fa compounding, perché ogni processo migliorato produce segnale migliore, che accelera l’accumulo di sapere tacito unico dell’impresa.

Il test che propone centra il problema. Devi poter sostituire il modello «generalista» senza perdere l’esperienza da «veterano» costruita dentro il tuo sistema di apprendimento. Lo chiama, testualmente, la prova del tuo controllo e della tua sovranità nell’era che arriva.

Tre piani dello stesso problema

Mi sembrano tre pezzi della stessa discussione, su tre piani diversi, e non si contraddicono, si tengono.

Mollick guarda il piano dei modelli, e prevede la fine dei modelli di frontiera open weights, perché un modello al vertice ha un footprint di calcolo che uno Stato può vedere e spegnere.

Nel mio articolo di ieri ho guardato il piano sotto. Un’API che ti spengono in una sera è un single point of failure, e in produzione la difendibilità si sposta dal modello migliore al controllo di routing e inferenza. Ci ero arrivato già dal primo post sul blocco, dove scrivevo che l’accesso ai modelli di frontiera è un permesso, non una proprietà.

Nadella aggiunge il piano sopra. Sul modello, qualunque sia, accumuli la conoscenza che diventa il vantaggio che nessuno ti può copiare. Tre altezze diverse, una stessa domanda di fondo, di chi è davvero quello che fai girare.

Il learning loop regge solo se possiedi l’inferenza

Qui sta la parte che aggiungo al suo ragionamento. Il test di Nadella è giusto, e funziona a una condizione precisa. Puoi cambiare il modello «generalista» senza perdere il «veterano» solo se possiedi il livello sotto, l’inferenza e il routing. Un learning loop che gira su un’API revocabile resta esposto, e sposta soltanto il lock-in di un piano più in alto. La conoscenza che accumuli vale finché la macchina che la fa girare resta accesa e sotto il tuo controllo.

Possedere l’inferenza vuol dire decidere tu dove gira il modello, su quale hardware, con quali dati che non escono di casa, e poter scambiare il motore senza riscrivere quello che hai costruito sopra. È la differenza tra un sistema che impara per te e un sistema che impara dentro l’infrastruttura di qualcun altro, che un domani può cambiare prezzo, condizioni o disponibilità.

Nella pratica è quello che ho descritto costruendo un ecosistema di AI privata, dove il modello è un componente sostituibile e la knowledge base, gli embedding e gli agenti con memoria restano dentro casa. Il loop, lì, poggia su un’infrastruttura che governi tu.

La parte che un hyperscaler lascia in ombra

C’è un dettaglio nel pezzo di Nadella che vale una nota. Microsoft è un hyperscaler, e la visione del learning loop la puoi seguire benissimo sopra il suo stack. In quel caso, però, il loop poggia su un’inferenza che affitti, e la sovranità di cui parla resta a metà strada. Diversi osservatori hanno letto il testo come un posizionamento, Microsoft come piattaforma che distribuisce valore sopra i modelli, contro la scommessa di chi punta sul dominio del singolo modello di frontiera.

Quando Nadella scrive «frontier ecosystem, not just a frontier model» ha ragione, e l’argomento diventa più solido se lo strato di inferenza sotto il loop lo possiedi tu. Si può condividere l’obiettivo e aggiungere la fondazione che a un fornitore di cloud conviene non mettere in prima fila. Le due tesi non competono. La sua si appoggia sulla mia.

Da Zero a Loop, su un’inferenza tua

Il loop, per me, è un filo che tiro da tempo, al punto da averci intitolato un libro, Da Zero a Loop. L’idea è semplice. Il valore sta nel ciclo che, uso dopo uso, trasforma il lavoro di un’azienda in un sistema che migliora, più che nel singolo modello del momento. Nadella lo chiama learning loop e gli dà la dignità della strategia, e fa una certa impressione sentirlo dire da chi guida un’azienda da tremila miliardi di capitalizzazione.

Quello che aggiungo è dove quel ciclo deve poggiare. Su un’inferenza che tieni tu, perché un loop costruito su un fornitore lontano è esposto allo stesso interruttore che venerdì ha spento due modelli per tutti, in una sera. Possedere l’esecuzione dei modelli conta ormai più che possedere il modello migliore.

Tre piani, una sola posta in gioco, continuare a possedere quello che impari. Senza dubbio è lì che si gioca la sovranità nei prossimi anni, e la domanda da tenere sul tavolo resta semplice, su quale strato stai costruendo il tuo vantaggio?

Fonte: Satya Nadella, «A frontier without an ecosystem is not stable», X, 14 giugno 2026. La discussione nasce dal post di Ethan Mollick e prosegue i miei due articoli precedenti sul blocco di Anthropic.

AI & GENAI, TECH & BUSINESS

Anthropic spegne Fable 5 e Mythos 5: open weights di frontiera e sovranità tecnologica

Venerdì sera, ora di Washington, Anthropic ha disattivato i suoi due modelli più capaci, Claude Fable 5 e Claude Mythos 5, per tutti i clienti del mondo, e il dibattito sugli open weights è ripartito di colpo. A tre giorni dal lancio. La causa è una direttiva di export control del governo americano, che vieta l’accesso a qualsiasi cittadino straniero, dentro e fuori dagli Stati Uniti, compresi i dipendenti stranieri della stessa azienda. Una conformità selettiva era impossibile, l’interruttore è stato abbassato per chiunque, ovunque, e in molti hanno letto il blocco come la spinta che mancava verso i modelli open weights. I due modelli erano disponibili da pochi giorni, ed è la prima volta che una direttiva di questo tipo colpisce così, in una sera, i modelli di punta di un laboratorio americano.

Ethan Mollick, su LinkedIn, ha scritto una previsione che va nella direzione opposta.

Il blocco non porterà più modelli a pesi aperti. Semmai, scrive Mollick, vedremo la fine dei modelli di frontiera open weights. Il ragionamento è lineare: se un modello di classe Mythos è considerato rischioso, neanche la Cina avrà interesse a lasciarlo aperto, e un modello del genere non lo costruisci senza una concentrazione di calcolo che sta dentro un Paese, visibile e regolabile.

Ho lasciato un commento sotto il suo post, e provo qui ad allargarlo.

Sul meccanismo Mollick ha ragione, per la punta assoluta. Sulla conclusione servono due correzioni, e tutte e due portano esattamente dove passo le mie giornate, l’inferenza locale e la sovranità tecnologica, il lavoro che faccio in LocalAI.

La logica del footprint tiene

Un modello al vertice della capacità oggi nasce da una concentrazione di GPU che occupa data center fisici, dentro una giurisdizione precisa, con consumi, forniture e contratti tracciabili. La definizione che gira da tempo nei documenti regolatori è quella di calcolo regolabile, regulatable compute: un addestramento al vertice lascia tracce fisiche, il consumo elettrico fuori scala, le dimensioni dei data center, l’acquisto di decine di migliaia di acceleratori, e tutto questo uno Stato lo identifica e lo raggiunge. Le stesse restrizioni americane sull’export dei chip più avanzati esistono perché quel calcolo si vede, si conta, si può fermare a monte. Venerdì lo Stato lo ha fatto, in una sera.

Un modello aperto da sette o settanta miliardi di parametri, invece, una volta scaricato vive di vita propria, e una copia su un portatile non si richiama indietro con una direttiva. È la differenza che molti hanno colto subito, chi tiene i pesi in locale non se li vede togliere da nessun governo. Mollick anticipa l’obiezione cinese, e fa bene. Al vertice vero, quello dei modelli più potenti in assoluto, nessuno dei due blocchi ha convenienza a far circolare i pesi liberamente. Su questo gli concedo tutto, il tetto si chiude su entrambi i lati.

Dall’1,2% a quasi il 30% in un anno

La parola «frontiera», però, nel suo post indica il soffitto, la classe Mythos. La capacità che muove davvero l’adozione sta un gradino sotto, nel near-frontier, più che sufficiente per quasi tutto quello che le aziende fanno ogni giorno: estrarre dati da un contratto, classificare richieste, alimentare un sistema RAG, scrivere bozze, far girare agenti su compiti delimitati. Per questi lavori la distanza dal soffitto si è assottigliata fino a diventare irrilevante, e il modello più potente in assoluto non cambia l’esito di un’estrazione di campi o dello smistamento di un ticket. E lì la Cina accelera, in chiaro.

Qwen di Alibaba, Kimi di Moonshot, GLM di Zhipu, DeepSeek, e da inizio giugno MiniMax con il suo M3, presentato come primo modello di frontiera open weights che tiene insieme coding di alto livello, un milione di token di contesto e input multimodale. I numeri raccontano lo spostamento meglio di qualsiasi tesi. Uno studio di OpenRouter su centomila miliardi di token, ripreso insieme ad Andreessen Horowitz, misura la quota dei modelli open source cinesi sull’uso globale degli LLM salita da circa l’1,2% di fine 2024 a quasi il 30% un anno dopo. Il paper della Commissione USA-Cina di marzo riporta una stima di un partner di a16z secondo cui intorno all’ottanta per cento delle startup americane costruisce su modelli base cinesi, e segnala che tra novembre e dicembre 2025 sette dei dieci modelli più scaricati su Hugging Face venivano da laboratori cinesi. I modelli proprietari occidentali restano davanti, intorno al settanta per cento dell’uso complessivo, ma la pendenza della curva aperta è tutta da una parte. L’adozione poi si autoalimenta, più sviluppatori scaricano un modello e più nascono strumenti, integrazioni e materiali intorno, e più quel modello diventa la scelta ovvia per il progetto successivo. È un volano che lavora a favore di chi pubblica i pesi, e in questo momento a pubblicarli con più aggressività è la Cina.

Fine del frontier open weights occidentale

A chiudersi, allora, non è il layer aperto, è la sua sponda occidentale. Se gli Stati Uniti regolano chiuso il proprio gradino alto e l’Europa continua a scivolare fuori dai vertici, con Mistral che esce dai primi posti tra i laboratori di punta, lo strato aperto del near-frontier non sparisce, passa di mano. Passa ai laboratori cinesi, che lo tengono aperto proprio perché l’apertura è una leva competitiva contro le API chiuse americane, un modo per entrare negli stack di tutto il mondo mentre l’alternativa si blinda.

Il blocco ha messo in chiaro un contrasto che diversi osservatori hanno colto subito. Un modello di frontiera open weights come M3 lo scarichi e lo fai girare sul tuo hardware, e nessun governo te lo spegne a distanza, mentre due modelli di punta serviti da un endpoint centralizzato sono spariti per chiunque nel giro di una sera. La parte scomoda della previsione di Mollick è questa: una chiusura del vertice occidentale dettata dalla sicurezza può consegnare lo standard aperto a Pechino, e regalare a un concorrente sistemico la posizione di default su cui costruiscono sviluppatori e imprese.

Per l’Europa la posta è alta. Se lo strato aperto che entra negli stack diventa cinese, l’autonomia digitale che il continente insegue da anni si ritrova a poggiare su modelli sviluppati sotto un’altra giurisdizione, con un’altra catena di fornitura e un altro sistema di valori a monte. Mistral resta la carta europea più seria, e proprio per questo il suo arretramento dai vertici pesa oltre il singolo laboratorio. La sovranità tecnologica, in questo scenario, smette di essere una parola da convegno e diventa una scelta su quale ecosistema di modelli vuoi poter usare anche tra cinque anni.

Una sera è bastata a spegnere due modelli

Qui arriva la parte che vedo meglio dal mio mestiere. Per il valore che conta in produzione, la capacità di frontiera non è mai stata l’elemento che fa la differenza. In produzione la differenza la fa la continuità del servizio, e una sera come quella di venerdì la mette alla prova più di qualsiasi benchmark. Due modelli spariti per direttiva, a tre giorni dal lancio, con Amazon a cui è stato chiesto di revocare l’accesso in tutte le regioni, e nessuno dei clienti che ci aveva costruito sopra un processo ha avuto voce in capitolo.

È una traiettoria, più che un episodio isolato. Il Dipartimento della Difesa aveva già etichettato Anthropic come rischio per la catena di fornitura, e l’azienda ha aperto un contenzioso contro quella classificazione. Quando un fornitore si trova in mezzo a una tensione del genere, la volatilità regolatoria smette di essere un’ipotesi da slide e diventa una variabile operativa. E c’è un secondo lato, speculare, se l’ottanta per cento delle startup americane gira su modelli cinesi quell’esposizione un domani può diventare a sua volta oggetto di una direttiva: la dipendenza da un fornitore lontano è un rischio qualunque sia la bandiera del fornitore. La lezione che le aziende portano a casa questa settimana è architetturale, serve un disegno capace di reggere il momento in cui un down o un blocco arrivano davvero. Ne avevo scritto guardando alle opzioni di self-hosting con Mistral, e quel ragionamento oggi vale per chiunque appoggi un processo critico su un solo fornitore lontano.

Routing e inferenza locale, il livello che resta tuo

L’architettura che regge a tutto questo è agnostica rispetto al modello: un livello di astrazione e di routing che, nel momento esatto in cui qualcosa a monte si rompe, sposta il traffico da un’API di frontiera a un modello aperto che gira in casa. È quello che costruiamo in LocalAI, un motore open source che funziona come sostituto diretto delle API di OpenAI e di Anthropic, così lo stesso codice che ieri chiamava Fable 5 oggi può chiamare un Qwen o un DeepSeek sul tuo hardware, CPU compresa, senza che i dati escano dalla tua infrastruttura, con agenti, RAG e supporto MCP già dentro. In termini concreti cambi l’indirizzo dell’endpoint e la chiave, non l’applicazione che ci sta sopra.

La spinta verso questo disegno non arriva solo da chi vende inferenza locale. VentureBeat, commentando proprio questo blocco, indica come via più resiliente un’architettura a fallback attivo, con sistemi pensati per essere agnostici rispetto al modello e livelli di routing intelligenti che spostano il traffico da un modello di frontiera a un fallback a pesi aperti nell’istante in cui arriva un’interruzione o un divieto. Nello stesso caso Anthropic, per non lasciare tutto fermo, ha dirottato le richieste sopravvissute su Opus 4.8, un modello meno capace ma ancora acceso. Lo ha fatto perché quando il vertice si spegne serve comunque un posto dove ricadere, e quel posto, se è davvero tuo, non te lo toglie nessuno.

Compatibilità diretta vuol dire usare gli stessi SDK e la stessa struttura di chiamata, e il livello di routing decide richiesta per richiesta dove mandare il lavoro, in base a quanto è sensibile il dato, al costo e a quanto serve davvero la potenza del modello più grande. Una bozza interna resta in casa su un modello locale, una sintesi complessa può salire sul cloud di frontiera, e se quel cloud non risponde il traffico ricade sul locale senza che l’utente se ne accorga. Per banche, sanità e pubblica amministrazione lo stesso motore gira on premise o in ambienti isolati dalla rete, dove il dato non ha proprio il permesso di uscire.

Il lock-in vero, quello che fa fallire le migrazioni, vive oltre il modello, negli embedding, nel database vettoriale, nella logica di orchestrazione che hai cucito addosso a un fornitore. Possedere il livello di astrazione significa poterli sostituire un pezzo alla volta, senza riscrivere tutto. E sul costo cambia la natura della spesa, l’inferenza locale ha un costo prevedibile legato all’hardware, più che una bolletta a consumo che cresce con l’uso e che un fornitore può ritoccare quando vuole. È la stessa famiglia di strumenti, da LocalAI a LocalAGI fino a LocalRecall, di cui avevo raccontato il senso più ampio parlando di pelle digitale e di agenti autonomi.

Gli agenti rendono il problema più grave

C’è un livello in cui tutto questo pesa il doppio, ed è quello degli agenti. Un agente che dipende da una sola API di frontiera per pianificare i passi e chiamare gli strumenti si ferma del tutto nel momento in cui quell’API viene tagliata, e non si ferma una funzione, si ferma il processo che gli avevi delegato per intero. Più l’agente è autonomo e incastrato nei flussi di lavoro, più alto è il costo di un’interruzione improvvisa, perché hai spostato sul modello non una risposta ma una catena di decisioni.

Un livello di routing con fallback locale è quello che permette a un agente di degradare con grazia, passando a un modello che gira in casa e continuando a lavorare, magari un po’ più lento, invece di spegnersi a metà. È una delle ragioni per cui LocalAGI sta sopra LocalAI, l’orchestrazione degli agenti vale finché sotto c’è un’inferenza che non puoi perdere da un momento all’altro.

La difendibilità si sposta dal modello al controllo

Da mesi insisto su una tesi che questa settimana trova una conferma sgradevole. Quando la capacità di frontiera diventa una merce che si affitta, finché non te la spengono, «avere il modello migliore» smette di essere un fossato difensivo. L’asset che resta difendibile è il controllo, sull’inferenza, sul luogo dove vivono i dati, sul livello di routing che tiene in piedi tutto il resto. La capacità la noleggi in un pomeriggio, il controllo te lo costruisci, e per questo vale di più.

Per l’Italia e per l’Europa la cosa non è teorica. Gli obblighi dell’AI Act per i sistemi ad alto rischio arrivano in pieno il 2 agosto 2026, con gestione del rischio, governance del dato, tracciamento e sorveglianza umana da dimostrare, il GDPR rende il luogo del dato una questione legale prima ancora che tecnica, e la spinta sul cloud sovrano sta già ridisegnando quali fornitori possono servire i progetti pubblici. Uno stack che possiedi risponde alle tre cose insieme, compliance, residenza del dato e continuità, e lo fa senza dover sperare che il fornitore a monte non cambi idea.

In pratica si parte mappando le dipendenze AI che hai, processo per processo, per sapere cosa si ferma se un fornitore sparisce. Da lì si introduce un livello di astrazione e di routing tra le applicazioni e i modelli, si tiene pronto un fallback locale per i carichi critici e per i dati sensibili, e si comincia a trattare l’inferenza come si tratta l’energia di un’azienda, con una fornitura principale e una riserva che non dipende da lei. Nessuno di questi passi richiede di rinunciare ai modelli di frontiera quando servono davvero, chiede solo di non restarne prigionieri.

La cosa che mi resta addosso, finita questa settimana, non è la geopolitica del calcolo. È quanta parte della nostra intelligenza operativa giri già su un interruttore tenuto da qualcun altro. Ci siamo affezionati a capacità che non possediamo, che possono cambiare, scadere o essere spente da lontano, e in Pelle Digitale avevo provato a dire che la tecnologia che ci estende è anche la tecnologia che ci espone, ogni volta che rinunciamo a governarla. Possedere il livello che ti tiene acceso sta diventando una scelta quotidiana, da rifare ogni mattina invece di darla per acquisita. Senza dubbio è la domanda che porto in ogni tavolo in queste settimane, quanta della tua intelligenza operativa sei disposto a lasciare su un interruttore che non tieni in mano?

Fonte: Ethan Mollick, post su LinkedIn, 12 giugno 2026. Sui fatti del blocco: comunicato di Anthropic, CNBC, Tom’s Hardware, VentureBeat. Sui dati di mercato: OpenRouter e Andreessen Horowitz, paper della Commissione USA-Cina (USCC).

AI & GENAI, TECH & BUSINESS

Sovranità dell’AI: quando un governo può spegnere un modello

Venerdì 12 giugno 2026, ore 17:21 a New York. Anthropic riceve una lettera dal governo degli Stati Uniti e nel giro di poche ore disattiva i suoi due modelli più potenti, Fable 5 e Mythos 5, per l’intera base clienti, ovunque nel mondo. La motivazione, dichiarata nel comunicato ufficiale dell’azienda, è un export control per ragioni di sicurezza nazionale che vieta l’accesso a qualunque cittadino straniero, dentro e fuori dagli Stati Uniti, compresi i dipendenti stranieri della stessa Anthropic.

Screenshot

Non discuto qui chi abbia ragione. Mi interessa una cosa più semplice, e più scomoda, che fino a quella sera in molti trattavano come un dettaglio tecnico: l’accesso ai modelli di frontiera è un permesso, e un permesso lo concede qualcuno che può anche ritirarlo.

Un export control ha messo offline un modello di frontiera

La direttiva è arrivata venerdì pomeriggio, alle 17:21 ora della costa Est. Secondo NBC News a firmarla è stato il Segretario al Commercio Howard Lutnick, con i funzionari del Bureau of Industry and Security, l’ufficio che negli Stati Uniti gestisce le restrizioni all’export. È lo stesso strumento con cui negli anni Novanta Washington trattava la crittografia come un’arma da guerra, soggetta alle regole sull’export militare. Anthropic ha scelto di spegnere i modelli per tutti, perché applicare il divieto ai soli stranieri avrebbe comunque tagliato fuori una parte enorme di utenti, inclusi i suoi stessi dipendenti non statunitensi.

L’azienda si adegua, ma dichiara di non essere d’accordo. Sostiene che la vulnerabilità contestata sia minore, che la prova ricevuta sia finora soltanto verbale, e che la stessa capacità sia già reperibile in altri modelli pubblici, incluso GPT-5.5 di OpenAI, e usata ogni giorno da chi i sistemi li difende. È, per quanto se ne sa, la prima volta che un’azienda AI di primo piano mette offline un modello già distribuito al pubblico per effetto di un intervento federale.

Il contesto pesa più della singola lettera. A febbraio l’amministrazione aveva provato a escludere i prodotti Anthropic dalle agenzie federali, l’azienda aveva fatto causa e un giudice le aveva dato ragione. La settimana scorsa è emerso che la National Security Agency stava usando Mythos per operazioni cyber offensive. E il 2 giugno è stato firmato un ordine esecutivo sull’AI che, tra le altre cose, prevede un meccanismo per dare al governo accesso anticipato, su base volontaria, ai modelli più potenti. Lo stesso modello che lo Stato vuole usare per la propria sicurezza è anche quello che lo Stato può decidere di spegnere, per la stessa ragione.

Permesso, non proprietà

Quando paghi l’abbonamento a un modello hai l’impressione di possederne l’uso. L’accesso non è un bene che possiedi, è un permesso che ti concedono, condizionato, che vive su infrastruttura di qualcun altro e sotto la legge di qualcun altro.

In Pelle Digitale ho provato a raccontare come il digitale sia diventato una seconda pelle, qualcosa che indossiamo senza più accorgercene finché funziona. La dipendenza più profonda è quella invisibile. La vedi solo il giorno in cui qualcuno la stacca, e venerdì centinaia di milioni di persone hanno visto la propria.

Il controllo dell’AI è verticale

Girano decine di schemi dello stack dell’AI. Alcuni lo disegnano come un mercato, con applicazioni e modelli e dati e infrastruttura, altri come un’architettura tecnica a livelli, altri ancora come una pila di governance che sale dalla sicurezza fino al consiglio di amministrazione. Linguaggi diversi per lo stesso oggetto.

Quasi nessuno mette in evidenza la dimensione che venerdì è diventata lampante. Il controllo è verticale. C’è una pila che parte dal silicio e arriva alla governance, con in mezzo il cloud, i pesi del modello, il runtime di inferenza, l’orchestrazione, le applicazioni. Puoi avere model card, audit trail e comitati etici impeccabili in cima, e perdere comunque l’accesso al modello perché una lettera, in un’altra capitale, ha deciso così. Una policy perfetta vale poco se il fondo della pila vive sotto la giurisdizione di un altro Stato.

Dove può intervenire davvero un’azienda privata?

Qui la domanda si fa concreta, e la risposta cambia da livello a livello.

Sul silicio un’azienda privata non interviene. Non progetta i chip, non controlla i grandi produttori, e l’export sui semiconduttori è una leva che si muove tra governi. È il piano geopolitico del controllo, quello su cui un’impresa, per quanto grande, resta sostanzialmente spettatrice.

Dal cloud in su la situazione si ribalta. L’infrastruttura puoi sceglierla, on-premise oppure su un cloud sovrano in giurisdizione europea. Il runtime di inferenza gira su software aperto, dentro il tuo perimetro. Per orchestrazione e agenti esistono standard aperti come MCP. Le applicazioni le disegni o le ospiti tu, e la governance, in cima, è per definizione tua.

In mezzo c’è il livello che decide tutto, il modello e i suoi pesi. Con pesi aperti, scaricati e ospitati sulla tua infrastruttura, il modello è tuo e nessuno te lo spegne da remoto. Con un’API proprietaria, per quanto eccellente, dipendi dalla continuità di servizio di chi te la fornisce, ed è esattamente lì che venerdì è caduta la direttiva.

Controllare l’intera pila, dal chip all’applicazione, è impraticabile per quasi qualunque organizzazione, e costoso anche solo provarci. La scelta sensata non sta nel possedere tutto, ma nel decidere, livello per livello, cosa tenere dentro il perimetro e cosa affittare sapendo bene che cosa si sta affittando.

Il metodo viene prima della tecnologia

Decidere quali livelli controllare è prima di tutto un esercizio di metodo: mappare le dipendenze reali, valutare la maturità dell’organizzazione, architettare quali strati portare in casa e con quale priorità, mettere governance e conformità, con l’AI Act in testa, dentro il progetto dall’inizio e non come timbro finale. È il lavoro che con ZeroFive provo a fare con un framework a cinque fasi, che parte dall’allineamento strategico e dalla valutazione della maturità, passa per l’architettura delle priorità e l’attivazione della governance, e arriva alla misurazione del valore nel tempo, con un’idea fissa, portare metodo dove l’industria porta hype.

Il metodo dice quali livelli pesano per te. Poi serve la tecnologia per tenerli davvero in mano, e sul livello che fa da bivio, il modello e il runtime, la risposta tecnica ha un nome preciso, l’open source. LocalAI è un motore di inferenza aperto, compatibile con le API di OpenAI e indipendente dal modello, pensato per far girare modelli a pesi aperti dentro il perimetro dell’azienda, senza che il dato esca e senza che l’accesso dipenda da una decisione presa da un’altra parte. È il progetto su cui lavoro, e lo cito per quello che è in questo discorso, un modo concreto per riportare il modello dalla parte di chi lo usa. Vale anche per chi si occupa di AI generativa in azienda: la scelta della pila viene prima della scelta del fornitore.

La direttiva del 12 giugno rientrerà quasi certamente, Anthropic stessa la legge come un malinteso, e l’accesso a Fable e Mythos tornerà. La lezione però resta anche dopo. Per chi costruisce in Europa la prossima domanda da portare in consiglio di amministrazione non riguarda quale modello sia il più bravo, ma quanta parte del proprio stack continuerebbe a funzionare il mattino dopo una lettera. Voi quanta parte ne avete?

Fonte primaria: Statement on the US government directive to suspend access to Fable 5 and Mythos 5, Anthropic, 12 giugno 2026. Ricostruzione del meccanismo governativo: NBC News. Contesto regolatorio: ordine esecutivo del 2 giugno 2026.

AI & GENAI, TECH & BUSINESS

I decreti attuativi sull’IA e la responsabilità che resta umana

Il 10 giugno 2026 il Consiglio dei Ministri ha approvato in esame preliminare due decreti attuativi della legge 132/2025 sull’intelligenza artificiale. Sono il primo quadro nazionale organico in materia, costruito per dare attuazione all’AI Act dentro l’ordinamento italiano. I testi non sono ancora definitivi, davanti c’è l’iter delle Commissioni parlamentari, della Conferenza delle Regioni e delle Authority competenti, e qualche pezzo cambierà.

Li ho letti per intero, e al netto della retorica da comunicato c’è una direzione che riconosco e condivido. In un anno in cui tutti corrono sull’adozione dell’IA, queste norme spostano in silenzio il baricentro, ridefiniscono cosa diventa difficile e quindi prezioso: tenere una persona competente dentro la decisione, e tenere il dato sotto controllo. Non è un freno all’innovazione, è il posto dove inizia la difendibilità.

Dentro i decreti attuativi resta una persona che decide

Il filo che attraversa entrambi i testi è uno solo. L’IA può assistere, analizzare, prevedere, ma la decisione resta umana e imputabile a qualcuno che ne risponde. Sul lavoro la regola diventa esplicita: le scelte che riguardano assunzione, sanzione disciplinare o licenziamento non possono essere prese unicamente sulla base di un trattamento automatizzato, e un licenziamento deciso solo da un algoritmo è nullo. Il lavoratore ha diritto, su richiesta e con l’intervento di una persona fisica, a una motivazione intelligibile di ciò che lo riguarda.

La stessa logica torna nella giustizia, dove la formazione dei magistrati serve a garantire che l’IA non sostituisca lo ius dicere, e nella sanità, dove l’uso clinico degli strumenti entra obbligatoriamente nei programmi di Educazione Continua in Medicina. Cambia il settore, resta identico il principio. La sorveglianza umana diventa la condizione perché la tecnologia entri davvero, e smette di essere una casella da spuntare a posteriori.

Questa è la parte che mi tocca più da vicino. In Pelle Digitale avevo provato a raccontare la frontiera sottile tra noi e le macchine come una membrana, qualcosa che ci protegge mentre ci mette in contatto. È la traduzione in diritto di quella membrana: l’algoritmo propone, la persona resta responsabile.

E i dati dove restano?

Sul fronte dei dati il secondo dei decreti attuativi, quello sulle attività di polizia, è il banco di prova più delicato, e la scelta è leggibile. Niente sorveglianza biometrica generalizzata, niente banche dati costruite raccogliendo immagini a strascico dal web. L’identificazione biometrica in tempo reale resta ammessa solo in casi tassativi, con autorizzazione dell’autorità giudiziaria, delimitata nel tempo e nello spazio, per un periodo che non supera i quindici giorni salvo proroga motivata.

Il riconoscimento facciale a posteriori può attivarsi solo dopo un reato, sulla base di elementi verificabili, con i dati conservati in locale per sette giorni e log non modificabili per cinque anni. Nessuna decisione che danneggia una persona può fondarsi soltanto sull’output del sistema. Il comunicato lo sintetizza con un’immagine, «nessun Grande Fratello», e qui la formula coincide con la sostanza: dato conservato in locale e verificabile.

C’è chi legge questo stesso impianto con più diffidenza, e non ha torto a porsi il problema. Su Agenda Digitale è uscita una lettura più critica del decreto sulla polizia, che nelle garanzie formali vede il rischio di una normalizzazione progressiva della sorveglianza. È un’obiezione seria, da tenere accanto al testo. Le regole sui dati valgono quanto la loro applicazione concreta.

Alfabetizzazione critica, non addestramento

Il blocco sulla formazione è quello che rischiamo di sottovalutare, ed è la condizione abilitante di tutto il resto. I decreti non parlano di corsi sull’uso degli strumenti. Parlano di capacità di leggere gli output, riconoscere i bias, capire i limiti, mantenere una sorveglianza vera su sistemi che spesso restano opachi anche a chi li adopera. È la differenza tra usare uno strumento e governarlo.

La cosa entra ovunque, dalla scuola con cento milioni destinati alla formazione dei docenti, all’università, alla pubblica amministrazione, fino agli ordini professionali che dovranno adeguare i regolamenti in sei mesi e all’equo compenso ricalibrato sul livello di rischio del sistema impiegato. Per chi come me passa buona parte dell’anno dentro le aziende a lavorare su adozione e governance dell’IA, è la conferma di una cosa semplice: la competenza è il presupposto della trasformazione.

Un miliardo per l’ecosistema nazionale

Accanto alle regole il pacchetto porta una scommessa industriale, ed è la metà che spesso sfugge nel dibattito. L’articolo 23 della legge 132 destina fino a un miliardo di euro del Fondo di sostegno al venture capital allo sviluppo dell’ecosistema nazionale dell’IA. Secondo il comunicato il mercato italiano ha toccato 1,8 miliardi nel 2025, con una crescita del cinquanta per cento sull’anno prima, e CDP Venture Capital ha già allocato oltre trecento milioni su più di centocinquanta startup. Il comunicato cita anche oltre mille occupati altamente qualificati nelle imprese già sostenute e più di cinquecento milioni di nuovi investimenti previsti nel prossimo triennio.

Le filiere indicate come prioritarie dicono la direzione: robotica umanoide e guida autonoma, quantum e fotonica per il calcolo ad alte prestazioni, IA verticale e deep tech. Dal 2026 si aggiunge un polo dedicato a intelligenza artificiale e cybersicurezza. La parola che ricorre, sotto traccia, è sovranità. Costruire capacità qui, su infrastruttura europea, con il dato che non deve attraversare l’oceano per essere elaborato.

La difendibilità si sposta sul controllo

Qui le due cose, le regole e la scommessa industriale, si chiudono in un cerchio che mi riguarda da vicino. Se la decisione resta umana e il dato resta a terra e tracciato, se la formazione diventa un requisito, allora il vantaggio competitivo smette di essere soltanto la velocità. In una conferenza di pochi giorni fa avevo provato a dirlo così, veloci lo saranno tutti, difendibili pochi. Due decreti attuativi che mettono al centro controllo e responsabilità, senza cercarlo, raccontano la stessa cosa.

È il terreno su cui lavoro ogni giorno, su due piani che si tengono insieme. C’è il metodo, il lavoro con le aziende attraverso ZeroFive, per portare l’IA dentro i processi restando dentro le regole, con governance e formazione che diventano competenza reale e non slide. E c’è la tecnologia, LocalAI, dove l’inferenza gira on-premise e il dato non esce dall’azienda, anche negli ambienti più regolati. Li cito per una ragione precisa, e non per piazzare un’inserzione: sono nati prima di questo decreto, rispondendo alla stessa domanda che il decreto adesso mette nero su bianco.

Resta l’incognita di sempre, e vale la pena tenerla aperta. Una regola che impone la sorveglianza umana vale quanto la serietà con cui la si esercita, e un’infrastruttura sovrana conta solo se qualcuno la sceglie davvero. La forma definitiva dei testi arriverà tra qualche mese. La domanda vera viene dopo: quante aziende vivranno questo perimetro come un adempimento da subire, e quante come il punto da cui ricostruire un vantaggio?

Fonte: Comunicato stampa del Consiglio dei Ministri n. 177, 10 giugno 2026.

AI & GENAI

Incorruptible: la gravità finanziaria di Eric Ries e l’AI che obbedisce alla struttura

Mi sono portato in viaggio Incorruptible, l’ultimo libro di Eric Ries, lo stesso di The Lean Startup, e l’ho letto nei ritagli tra una tappa e l’altra. Sottotitolo: perché le buone aziende vanno a male e come le grandi restano grandi. La sua tesi di fondo è scomoda per chi ama le storie morali. La deriva delle imprese, dice Ries, ha una radice strutturale prima che morale: proprietà, incentivi, statuti, meccanismi di accountability. Anche i leader più integri finiscono spinti verso esiti che non avrebbero scelto, perché il sistema che li circonda li piega. A questa spinta Ries dà un nome, gravità finanziaria.

È la somma degli incentivi di breve termine, della dottrina del primato dell’azionista, delle strutture di governo che estraggono valore invece di custodirlo. Come la gravità, agisce che tu te ne accorga o no. E diventa più forte proprio quando l’azienda ha più successo, perché un’impresa che vale tanto è un bersaglio che vale tanto.

Fin qui Ries. Quello che mi ha tenuto sveglio, oltre al fuso del rientro, è un’altra cosa. Stiamo per consegnare migliaia di decisioni operative a agenti AI che eseguiranno la struttura che gli diamo, alla lettera, senza l’attrito morale di un essere umano che a un certo punto storce il naso e dice no. Se la struttura è mal disegnata, l’agente la realizzerà alla perfezione. La gravità finanziaria sta per trovare un acceleratore.

Lo sgabello con una gamba sola

Ries prende di mira il primato dell’azionista, la dottrina per cui l’unico scopo legittimo di un’impresa è massimizzare il ritorno per chi possiede le azioni. Un’azienda sana, scrive, poggia su tre gambe: una ragione di esistere, gli stakeholder che da quella ragione sono serviti, gli investitori che dalla performance sono ricompensati. Togli le prime due e resti con uno sgabello a una gamba sola, che sta in piedi solo finché i mercati hanno voglia di tenerlo in piedi.

Il dato che usa per smontare l’ortodossia è la sanità americana. Gli Stati Uniti spendono circa il doppio pro capite rispetto a paesi comparabili e ottengono un’aspettativa di vita più bassa. Un punto isolato, fuori dalla linea che ogni altro paese sviluppato segue. Per la teoria dei mercati efficienti non dovrebbe accadere. Accade. Ries lo legge come una smentita sul campo, non come un’anomalia da archiviare in un cassetto. Arriva al punto di voler ritirare la parola profitto, e ridefinirla come massimizzazione della fioritura umana.

L’agente non storce il naso

Qui entra il concetto del libro che mi sembra più urgente per chi lavora con l’AI: la surrogazione. La metrica di una cosa prende il posto della cosa stessa. Misuri il tempo medio di gestione di una chiamata perché è misurabile, e ottieni un customer service peggiore, perché gli operatori imparano a chiudere in fretta invece di risolvere il problema. La metrica mangia l’obiettivo.

Un essere umano, davanti a un cliente in difficoltà, ogni tanto rompe lo schema. Resta al telefono venti minuti in più perché capisce che è la cosa giusta, anche se il suo cruscotto ne soffre. Quella frizione vale oro. È l’ultimo argine tra la metrica e il senso.

Un agente AI quell’argine non ce l’ha. Gli dai una funzione obiettivo e lui la insegue con una costanza che nessun dipendente avrà mai. Se la funzione obiettivo è una metrica surrogato scelta male, l’agente ottimizzerà il surrogato fino in fondo, a una velocità e su una scala che la vecchia gravità finanziaria si sognava. La governance degli incentivi smette di essere materia da consiglio di amministrazione e diventa codice che gira in produzione.

Il leader invisibile, un secolo dopo

C’è poi Mary Parker Follett, teorica del management dei primi del Novecento, cancellata per decenni dai manuali mentre il suo contemporaneo Frederick Taylor diventava un santo laico. Follett parlava di “potere con” al posto di “potere su”. E parlava di leader invisibile: il vero capo della fabbrica di cioccolato Rowntree non era il signor Rowntree, era lo scopo condiviso che lui aveva seminato in ogni reparto. Le persone non seguivano lui, seguivano il senso che aveva reso comune.

La prova di un leader, in questa lettura, sta in cosa fa l’organizzazione quando nel reparto non c’è nessun manager. È un’idea che torna potente adesso, mentre costruiamo organizzazioni dove in molte stanze, di fatto, un manager non ci sarà più, ci sarà un agente.

A quel punto il leader invisibile prende una forma molto concreta: diventa la costituzione che diamo ai nostri sistemi, l’insieme di principi e vincoli che guida un agente quando deve decidere da solo. In Pelle Digitale ho provato a raccontare la tecnologia come estensione della mente, una membrana tra noi e il mondo. Con gli agenti quella membrana inizia a decidere al posto nostro, e l’unica cosa che la orienta è lo scopo che ci siamo presi la briga di scrivere dentro. Se lo scopo è vago, l’agente riempie il vuoto con la metrica più vicina.

Una seconda gravità

Ries parla di gravità finanziaria. Nelle aziende con cui lavoro ne vedo una seconda, parallela, che chiamerei gravità tecnologica. È la spinta a delegare cognizione, dati e infrastruttura a poche piattaforme esterne, perché all’inizio costa meno e fa risparmiare tempo. Il prezzo lo scopri dopo, quando il controllo se n’è già andato altrove e ricomprartelo costa una fortuna.

Le aziende che Ries porta come esempi di resistenza alla gravità finanziaria non sono enti di beneficenza. Grundfos, Bosch, Novo Nordisk, Carl Zeiss: fondazioni industriali nate in Danimarca e in Germania, alcune oltre un secolo fa, che battono i concorrenti convenzionali proprio perché possono investire su orizzonti che gli altri non riescono nemmeno a guardare. La proprietà protegge la missione, e la missione protetta produce risultati.

La stessa logica vale sul piano tecnologico. Tenere vicino ciò che è strategico, i modelli, i dati, le decisioni che pesano, è la versione digitale della fondazione industriale. È il motivo per cui con LocalAI lavoro su intelligenza artificiale che gira dentro il perimetro dell’azienda invece che dentro il perimetro di qualcun altro. È una scelta strutturale prima che ideologica: chi controlla l’asset critico controlla il proprio futuro.

La governance come atto creativo

Il lascito pratico di Incorruptible è che la governance è un lavoro di design, da fare prima che serva. Lo scrive a chiare lettere: aspettare di avere successo per mettere i paletti è troppo tardi, perché il successo è ciò che attira i predatori. Banchieri, avvocati e investitori ti diranno sempre di rimandare a quando sarai più forte. Quel consiglio è la trappola.

Per chi guida un’azienda oggi il compito si è raddoppiato. C’è la struttura finanziaria da disegnare, come dice Ries. E c’è la struttura tecnologica, la costituzione degli agenti, la scelta di cosa tenere dentro e cosa lasciare fuori, che decide quanto del tuo futuro resta nelle tue mani. È il lavoro che faccio ogni giorno con le aziende che proviamo ad aiutare in ZeroFive: non policy da incorniciare, ma i meccanismi che orientano le decisioni quando nessuno sta guardando, umano o agente che sia.

Ries ha ragione su un punto. Il successo da solo non protegge ciò che conta. E nell’era degli agenti, una struttura ben disegnata smette di difendere soltanto la missione dalla finanza, inizia a difendere la mente dell’organizzazione dal diventare proprietà di qualcun altro.

Eric Ries, Incorruptible: Why Good Companies Go Bad and How Great Companies Stay Great, Authors Equity, 26 maggio 2026. Materiali e capitolo bonus su incorruptible.co.

AI & GENAI, TECH & BUSINESS

Mistral vs Llama vs Qwen vs DeepSeek: quale per l’azienda

Tre anni fa, “modello open-source” significava roba di nicchia per ricercatori. Llama 1 di Meta aveva 65 miliardi di parametri, performance discrete sui benchmark, e una licenza che non ti permetteva di usarlo commercialmente. Il resto era praticamente esercizio accademico. Nel maggio 2026 il panorama è cambiato in modo radicale. Quattro famiglie di modelli open-weight competono testa a testa con i top di gamma proprietari (Claude Opus, GPT-5, Gemini Pro) su task specifici, e per le aziende italiane che vogliono fare AI privata sono diventate la scelta di default invece dell’eccezione.

Ho ricevuto la stessa domanda due volte questa settimana, una da un CTO di un’azienda manifatturiera lombarda e una da un’innovation manager di una banca italiana di medie dimensioni: “Tutti dicono Llama, ma davvero è la scelta giusta per noi?”. La risposta breve è “dipende”, e in questo articolo provo a sciogliere quel dipende.

I quattro modelli che vale la pena considerare seriamente oggi sono: Llama di Meta (americano, ampia diffusione, ecosistema enorme), Mistral di Mistral AI (francese, alleato europeo, focus enterprise), Qwen di Alibaba (cinese, performance al top sui benchmark, costi infrastrutturali bassi), DeepSeek (cinese, reasoning forte, prezzi aggressivi). Provo a confrontarli sui cinque criteri che contano davvero per chi deve prendere una decisione enterprise.

La lingua italiana, prima di tutto

Per le aziende italiane c’è un problema spesso sottovalutato: la qualità della lingua italiana del modello. I benchmark internazionali sono quasi tutti in inglese, e un modello che fa 92 su MMLU in inglese può fare 78 in italiano. Per chi costruisce un agente AI interno che parla con i propri dipendenti, questa differenza si sente nella qualità delle risposte.

I quattro modelli si comportano in modo abbastanza diverso su italiano. Mistral, essendo francese, ha l’italiano nel core training data fin dalle prime versioni, e produce un italiano molto naturale, con sfumature idiomatiche credibili. Llama 3.3 ha migliorato significativamente l’italiano rispetto a Llama 2, ma resta sotto Mistral nelle situazioni complesse (contratti legali, terminologia tecnica specifica). Qwen 4 fa un italiano sorprendentemente buono nelle versioni recenti, soprattutto sui task strutturati, anche se ogni tanto introduce piccoli calchi grammaticali dal cinese che un madrelingua riconosce. DeepSeek è il più debole sull’italiano della categoria, va bene per task tecnici e codice ma spesso suona “tradotto” sul conversazionale.

La mia regola pratica: se l’agente AI deve parlare con i vostri dipendenti italiani in modo fluido, Mistral o Llama. Se l’agente fa task back-end strutturati (estrazione dati, classificazione, codice), Qwen o DeepSeek vanno benissimo. Se siete bilingue inglese-italiano in azienda, qualsiasi dei quattro va bene.

Qualità delle risposte sui task aziendali tipici

I benchmark accademici (MMLU, GSM8K, HumanEval) sono utili come riferimento generale, ma non vi dicono se un modello vi serve in produzione. Per chi vuole capire cosa scegliere per la propria azienda, vale la pena testare quattro categorie di task che tornano spesso.

Sintesi e analisi documentale. Tutti e quattro i modelli, nelle loro versioni 70B+, fanno bene questo task. Mistral Large 3 e Llama 3.3 70B sono praticamente equivalenti sui documenti aziendali italiani. Qwen 4 70B è leggermente più conciso, può andare bene o male a seconda dello stile che cercate. DeepSeek V3 fa molto bene su documenti tecnici e meno bene su prosa argomentativa.

Estrazione strutturata. Quando dovete estrarre dati strutturati da testo libero (campi di un contratto, voci di una fattura, entità da una mail), i modelli si differenziano per affidabilità. Qwen 4 e DeepSeek vincono qui, perché hanno una propensione al rigore strutturale che è perfetta per output JSON, function calling, schema fissi. Llama e Mistral fanno discretamente, ma con tasso di hallucination sui campi vuoti più alto.

Generazione di codice. Categoria dove DeepSeek brilla con il suo modello specializzato Coder, che compete direttamente con Claude Sonnet sui task di programmazione. Qwen 4 Coder è il secondo. Mistral Codestral è solido. Llama 3.3 fa il codice meno bene degli altri tre.

Conversazione lunga e ragionamento. Per agenti AI con conversazioni multi-turno complesse, ricerca multi-step, ragionamento articolato, i modelli reasoning sono la categoria giusta. DeepSeek R2 è il leader open-weight della categoria, eccellente su reasoning matematico e logico. Qwen 4 con thinking mode è il secondo. Mistral e Llama nelle versioni standard sono più orientati al chat istantaneo, meno al reasoning profondo.

Hardware necessario e costi infrastrutturali

I quattro modelli pesano in modo diverso sulla vostra infrastruttura. È un fattore che le aziende spesso valutano in secondo piano e che diventa importante quando si passa dalla demo alla produzione su volumi reali.

Llama 3.3 70B in Q4 quantizzato pesa circa 40 GB di RAM/VRAM. Gira bene su Mac Studio M4 Max 128 GB (30-45 tok/s), su server con 2x RTX 4090 (50-70 tok/s), su singola H100 (90-120 tok/s).

Mistral Large 3 (123 miliardi parametri) è significativamente più pesante. Richiede 70+ GB di memoria, quindi Mac Studio 128 GB o server NVIDIA con almeno 80 GB di VRAM (H100, due 5090 in tandem). Performance: 15-25 tok/s sul Mac, 60-90 tok/s su H100.

Qwen 4 32B-A3B è la sorpresa positiva. È un modello MoE (Mixture of Experts) da 32 miliardi totali con solo 3 miliardi attivi per token. Pesa circa 18 GB ma è veloce come un modello da 7B in inferenza. Sul Mac Mini M4 Pro 48 GB arriva a 50-70 tok/s con qualità di output che compete con modelli 70B densi. È il modello più “efficiente per dollaro” che ho visto nel 2026.

DeepSeek V3 è grande (671B parametri totali, 37B attivi MoE), richiede infrastruttura server seria. Non gira su consumer Mac. Per molte PMI italiane è sovradimensionato.

Calcolando il costo infrastrutturale per servire 100 utenti aziendali simultaneamente in produzione:

  • Qwen 4 32B-A3B: 2.000-4.000 euro hardware
  • Llama 3.3 70B: 5.000-10.000 euro hardware
  • Mistral Large 3: 15.000-30.000 euro hardware
  • DeepSeek V3 full: 40.000+ euro hardware

Licensing e implicazioni geopolitiche

Per le aziende italiane, soprattutto quelle che lavorano con PA o settori regolati, la provenienza geografica del modello inizia a contare.

Llama ha una licenza commerciale aperta che permette praticamente qualsiasi uso (con il limite delle aziende con oltre 700 milioni di utenti attivi, che è un caso che riguarda Meta stessa, non voi). È un modello americano, sviluppato da Meta, distribuito sotto Llama Community License.

Mistral è francese, distribuito sotto Apache 2.0 per le versioni open-weight (Mistral 7B, Mixtral, alcune varianti). Le versioni più recenti come Mistral Large 3 sono proprietarie con API a pagamento ma con opzione enterprise on-premise. Per le aziende italiane che vogliono restare nel perimetro europeo, Mistral è la scelta naturale dal punto di vista geopolitico.

Qwen è di Alibaba, distribuito sotto Apache 2.0 (le versioni più recenti) o Tongyi Qianwen License (alcune varianti). I modelli sono completamente utilizzabili commercialmente. La provenienza cinese può essere un problema per aziende che lavorano con PA, difesa, settori sensibili. Per la maggior parte delle aziende manifatturiere o servizi italiane non c’è alcun problema operativo, ma è un fattore che alcuni board considerano.

DeepSeek è cinese (Hangzhou), distribuito sotto MIT license (più permissiva di Apache 2.0 in alcuni dettagli). Stesse considerazioni geopolitiche di Qwen.

La domanda non è “il modello cinese può rubare i miei dati”: tutti i modelli open-weight girano sul vostro hardware, quindi i dati non escono di un millimetro. La domanda è di posizionamento aziendale: alcune RFP italiane di settore difesa o PA cominciano a escludere esplicitamente componenti software cinesi.

Aggiornamenti e supporto della community

Un fattore spesso sottostimato: come evolve il modello nei prossimi anni? Acquistare hardware oggi per girarci sopra un modello che non viene più aggiornato è un investimento dimezzato.

Llama ha rilasciato versioni nuove ogni 6-9 mesi (Llama 1, 2, 3, 3.1, 3.2, 3.3, e Llama 4 è atteso entro fine 2026). Meta investe tantissimo nell’ecosistema, e la community Hugging Face ha le fine-tunate Llama più estese al mondo. Roadmap solida.

Mistral rilascia con cadenza simile, ma sta progressivamente spostando i modelli più nuovi su licenze proprietarie con accesso commerciale a pagamento. Per chi vuole stare sull’open-weight puro, Mistral si è un po’ rallentato come strategia. L’azienda è solida però (round di finanziamento da 2 miliardi nel 2024), quindi non c’è rischio sostenibilità.

Qwen è quello che evolve più velocemente. Alibaba sta investendo aggressivamente, e Qwen rilascia nuove versioni ogni 2-3 mesi. La velocità di iterazione è impressionante.

DeepSeek ha sorpreso tutti nel 2025 con la versione R1 che competeva con OpenAI o1 su benchmark di reasoning. Sta continuando a rilasciare aggiornamenti, anche se la sostenibilità a lungo termine del progetto è meno chiara di Meta o Alibaba.

La scelta concreta per tre profili aziendali italiani

Provo a tradurre i criteri sopra in tre raccomandazioni operative.

Per la PMI italiana media (50-300 dipendenti, AI per processi interni, no settori sensibili): Qwen 4 32B-A3B è la scelta di default oggi. Costa poco in hardware, gira veloce su un Mac Studio o un workstation modesto, l’italiano è buono per la maggior parte dei task aziendali, ha aggiornamenti frequenti. Se l’agente AI fa molto codice o estrazione strutturata, valutate anche DeepSeek Coder come modello specializzato accanto a Qwen.

Per l’azienda media-grande con focus su lingua italiana e mercati europei (settore retail, media, hospitality, servizi B2C): Mistral Large 3 è la scelta giusta. Italiano impeccabile, posizionamento europeo, supporto enterprise dedicato. Costa di più in hardware (15-30k euro per servire bene 100+ utenti) ma per chi ha quel budget vale.

Per banche, sanità, PA, difesa, manifattura strategica (settori regolati con sensibilità geopolitica): Llama 3.3 70B o Mistral Large 3. Llama per costo infrastrutturale più contenuto e ecosistema ampio, Mistral per posizionamento europeo. Evitate Qwen e DeepSeek se la vostra controparte ha sensibilità sul tema “componenti cinesi”.

Il valore di poter cambiare modello senza riscrivere

Una considerazione che vale per tutti i profili sopra: i quattro modelli open-weight evolvono velocemente, e il modello migliore di oggi probabilmente non sarà quello di fra dodici mesi. Llama 4 è atteso a fine 2026, Mistral sta preparando le sue prossime versioni, Qwen e DeepSeek rilasciano ogni pochi mesi.

Le aziende che costruiscono il proprio stack AI con un layer di astrazione (un orchestratore che espone API compatibili OpenAI come LocalAI.io, di cui sono cofondatore) riescono a cambiare il modello sotto senza ritoccare le applicazioni. Le aziende che si legano a un modello specifico in modo profondo (prompt engineerizzati su quirk specifici di Mistral, function calling con sintassi proprietaria di Qwen, fine-tuning legato a Llama 3.3) si ritrovano a fare la migrazione manuale ogni volta che esce un modello migliore. La differenza, su tre anni, vale settimane di lavoro di sviluppo.

LocalAI è progettato esattamente per questo: gestisce in parallelo Llama, Mistral, Qwen, DeepSeek e tutti i loro fine-tuned, espone un unico endpoint compatibile OpenAI, permette di fare A/B testing fra modelli, di routare task diversi a modelli diversi (Qwen per estrazione strutturata, Mistral per conversazione italiana, DeepSeek per codice), di aggiornare il modello sotto senza che le applicazioni se ne accorgano. È il single point of integration che rende la vostra architettura AI flessibile invece di rigida.

Per chi vuole capire come si imposta lo stack completo dal modello al deployment, ho scritto una guida hardware completa e una guida economica al TCO recente. Per chi sta facendo la decisione operativa su quale modello partire, c’è la pagina Advisory con i formati di lavoro che propongo.

La domanda da farsi oggi non è “qual è il modello migliore”. È: con quale modello vogliamo iniziare adesso, sapendo che fra sei mesi forse cambieremo? E quanto è facile per noi cambiarlo quando arriverà il momento?

AI & GENAI

Claude Fable 5 e la scatola nera: sembra una fiaba, sarà il problema da affrontare

Poco fa (9 giugno 2026) Anthropic ha rilasciato Claude Fable 5, il primo modello della classe Mythos accessibile al pubblico. I numeri raccontano un salto: Anthropic lo dà come stato dell’arte su quasi tutti i benchmark testati, e più lungo e complesso è il compito, più largo è il vantaggio sugli altri modelli. Prezzo dichiarato, dieci dollari per milione di token in input e cinquanta in output, meno della metà di Mythos Preview, con un meccanismo di sicurezza che ripiega su Opus 4.8 quando una richiesta tocca cybersecurity o biologia, in media in meno del 5% delle sessioni. Tutto vero, tutto rilevante. Ma la cosa che mi ha fatto fermare non sta nei benchmark.

Tabella benchmark Claude Fable 5 e Mythos 5 confrontati con Opus 4.8, GPT 5.5 e Gemini 3.1 Pro
Fonte: Anthropic, Claude Fable 5 and Claude Mythos 5, 9 giugno 2026. I punteggi con asterisco riflettono il fallback di Fable su cybersecurity e biologia, dove il modello si comporta come Opus 4.8.

Sta nel racconto di Ethan Mollick, che ha avuto accesso anticipato e ha provato a costruirci una mappa isocronica, quelle mappe che mostrano fin dove arrivi in un tempo dato. Gli dà un’istruzione, una sola, abbastanza vaga. E il sistema parte. Lancia altri agenti, più economici, per fare ricerca. Mentre quelli girano, inizia a scrivere codice. Poi lancia altri agenti ancora per verificare il codice che ha appena scritto, prende appunti sui propri progressi, corregge. Recupera oltre 2.200 voli, gli orari ferroviari dal TGV allo Shinkansen, le velocità stradali per paese da paper accademici. Lavora per ore. Quando vuole i tempi di viaggio verso le località remote, scopre da solo ogni quanto salpano le navi per Pitcairn nel Pacifico. Il risultato è una visualizzazione funzionante, con metodo, fonti, scelte di design, compromessi.

Transcript di Claude Fable 5 che lancia agenti in parallelo per costruire la mappa isocronica
Il transcript della sessione: il modello lancia altri agenti per la ricerca mentre scrive codice. Fonte: Ethan Mollick, What it feels like to work with Mythos, One Useful Thing.

Mollick usa un’immagine che mi gira in testa da quando l’ho letta. L’anno scorso parlava di lavorare con un mago: pronunci l’incantesimo, qualcosa accade. Adesso non è più sicuro di essere lui il mago. È più vicino a un committente. Descrive quello che vuole, paga, giudica il risultato. Le centinaia di micro-decisioni che hanno prodotto quel risultato avvengono in un posto che non può guardare, e su cui non ha votato.

Centinaia di scelte che nessuno ha approvato

Quando Mollick scrive che il suo ruolo era ridotto, non intende solo che ha lavorato poco rispetto alla macchina. Intende che ha avuto poco controllo su come la macchina ha fatto le cose, perché ha scelto certi approcci, persino su quanto a fondo sarebbe arrivata. I dettagli del ragionamento non gli vengono mostrati, e il processo sarebbe troppo lungo perfino da seguire. La mappa ha richiesto centinaia di piccole decisioni, e la macchina le ha prese, senza che lui le capisse e senza che potesse dire la sua.

C’è una frase, in chiusura del suo pezzo, che vale più di tutti i benchmark. Mollick si chiede se questo essere messo da parte sia temporaneo, un difetto delle interfacce che recupereremo con strumenti migliori per guardare dentro e correggere a metà strada. Poi ammette che sospetta il contrario: che più il modello è capace, meno ci sia per un umano da fare in modo significativo, e che la scatola nera sia il prezzo della potenza. Non un bug. Il prezzo.

Se ha ragione, e io credo che almeno in parte l’abbia, allora il problema smette di essere tecnologico e diventa organizzativo. Lo diventa subito, dentro le aziende, su ogni processo che decidiamo di affidare.

Da strumento ad attore

C’è un confine che queste macchine hanno attraversato, e lo descrive bene un lavoro recente della Berkeley sulla governance dell’impresa agentica. Quando un foglio di calcolo produce un errore, la responsabilità è di chi lo ha usato. Quando un agente autonomo approva una transazione o ridirotta una spedizione, la responsabilità diventa ambigua: è stato il modello, i dati, la configurazione, o la decisione di delega in sé? Senza un modello operativo esplicito, l’azienda non riesce a rispondere in modo coerente. La macchina è passata da strumento ad attore, e per gli attori servono regole diverse da quelle che usiamo per gli strumenti.

In Pelle Digitale ho provato a descrivere la tecnologia come estensione della mente, qualcosa che si fonde con il modo in cui pensiamo e percepiamo. L’AI agentica porta quell’idea su un piano nuovo. Non estende soltanto la mia capacità di pensare, agisce al posto mio, prende decisioni che fino a ieri erano competenza di una persona con un nome e una responsabilità. L’estensione è diventata delega. E la delega, quando il delegato lavora dentro una scatola che non vedi, è un atto di fiducia che va costruito, non dato per scontato.

McKinsey, nel suo lavoro sull’organizzazione agentica, lo dice con parole che condivido: la supervisione umana non sparisce, cambia natura. Non più revisione riga per riga, ma definizione di policy, monitoraggio degli scostamenti, regolazione del livello di coinvolgimento umano caso per caso. La sfida è trovare il punto giusto, abbastanza presidio da gestire il rischio senza riportare gli agenti alla velocità umana, che è poi il motivo per cui li hai chiamati.

Automatizzare un compito, commissionare una decisione

Per anni ho ripetuto una cosa nei miei interventi: ogni volta che deleghiamo un pezzo di lavoro senza capire come viene svolto, accumuliamo un debito di conoscenza. Lo paghi più tardi, quando quel sapere ti serve e non ce l’hai più dentro l’organizzazione. Con gli agenti che eseguono interi processi, quel debito smette di essere una metafora. Non è più questione di quali compiti togliere dalle mani delle persone, ma di quali decisioni accettiamo che maturino fuori dalla nostra vista, e di quanto sapere siamo disposti a non possedere più.

Non sono la stessa cosa. Automatizzare un compito significa togliere fatica a una persona che resta padrona del risultato. Commissionare una decisione significa accettare che una catena di scelte avvenga senza il tuo voto, e prenderti comunque la responsabilità di ciò che ne esce. La differenza vale un’azienda intera, perché cambia la natura stessa di ciò che firmi. Quando Stripe racconta che Fable ha compresso in un giorno una migrazione di codice che a mano avrebbe richiesto a un team più di due mesi, il risultato è straordinario e quasi nessuna di quelle scelte è passata per un occhio umano. Su una migrazione di codice ce ne facciamo una ragione. Su una decisione che tocca le persone e i conti di un’azienda, la stessa opacità diventa un rischio che pesa su chi ha firmato.

Qui si misura la maturità di un’organizzazione, e non si misura con un proof of concept in più. Si misura con la capacità di ridisegnare quattro cose insieme: chi risponde di cosa, come si traccia ciò che è successo, con quali criteri si giudica la qualità di un lavoro che non hai visto nascere, in quali punti un essere umano entra e ferma la catena. È lavoro di metodo, non di tecnologia. La tecnologia ce l’abbiamo già, ed è quella che ha costruito la mappa di Mollick in un pomeriggio.

Il presidio non si improvvisa

Steve Blank, recensendo l’ultimo libro di Eric Ries sulle strutture di governance che durano, ricorda una cosa che vale anche qui. Le idee sul come costruire aziende solide diventano operative quando la crisi le rende inevitabili. Il rischio, con l’AI agentica, è aspettare l’incidente per scoprire quanto fragile fosse il modello di controllo. La delega senza presidio regge finché tutto va bene. Poi una decisione sbagliata, presa dentro la scatola e mai rivista, mostra il conto, e a quel punto non c’è una persona a cui chiedere perché, c’è solo un output da spiegare a posteriori.

Costruire il presidio è un lavoro che si fa prima, con metodo, e che tocca la struttura dell’organizzazione più della sua dotazione tecnologica. Significa decidere a monte quali decisioni hanno bisogno di un punto di controllo umano e quali no, scrivere chi è responsabile quando un agente sbaglia, rendere ogni azione tracciabile e spiegabile, stabilire le soglie oltre le quali la macchina si ferma e chiama. È un disegno, e come ogni disegno richiede mani che l’abbiano già fatto. In ZeroFive lavoriamo esattamente su questo, sul metodo che trasforma la scatola nera in un processo che un’azienda può attraversare con responsabilità chiare, non sull’ennesimo strumento da aggiungere allo stack.

Reid Hoffman dice che il professionista del futuro dirige squadre di agenti e opera con la capacità di un team intero. Ha ragione. Ma dirigere una squadra che non vedi lavorare è un mestiere diverso dal dirigere persone che ti rendono conto. Il committente di Mollick firma il lavoro finale senza essere mai entrato in sala. Per un singolo che costruisce una mappa per diletto va benissimo. Per un’azienda che affida decisioni vere a un sistema che non mostra il suo ragionamento, firmare senza essere entrati in sala è esattamente ciò che non ci si può permettere.

L’AI agentica arriva travestita da acquisto tecnologico, una licenza in più nello stack. È un equivoco che costa caro, perché quello che cambia davvero è il disegno dell’organizzazione: chi porta la responsabilità di un esito che nessuno ha sorvegliato passo per passo, come si tiene traccia di un percorso che la macchina non mostra, dove collocare le poche soglie in cui una persona deve poter fermare tutto. Il lato tecnologico è la parte facile, e ce la siamo già giocata.

Fonti:
Ethan Mollick, What it feels like to work with Mythos, One Useful Thing, 9 giugno 2026.
Anthropic, Claude Fable 5 and Claude Mythos 5, 9 giugno 2026.
Giorgio Sacconi, Linkedin , 9 giugno 2026.

AI & GENAI, TECH & BUSINESS

TCO LLM on-premise vs cloud: il calcolo a tre anni

Un CFO italiano mi ha fatto una settimana fa la domanda che ricevo più spesso quando parliamo di AI privata: “Se chiamo Claude o GPT pago a token, è chiaro. Se mi metto un’infrastruttura in casa, in quanto tempo mi rientrano i soldi rispetto al cloud?”. È la domanda giusta, perché senza un calcolo TCO LLM on-premise solido nessun investimento in AI privata regge davanti al comitato finanziario.

In questo articolo provo a smontare il calcolo del TCO (Total Cost of Ownership) di un LLM on-premise su un orizzonte di tre anni, mettendolo a confronto con le API cloud dei grandi provider. Lavoro su numeri reali di maggio 2026, su tre scenari aziendali tipici italiani, e provo a includere anche le voci nascoste che troppi business case lasciano fuori. L’obiettivo qui non è dimostrare che l’on-premise vince sempre. Provo a dare uno strumento per decidere caso per caso.

La trappola del prezzo a token

Il prezzo per milione di token delle API cloud è sceso vertiginosamente negli ultimi 24 mesi. Per dare un’idea: GPT-5.4 a maggio 2026 sta a 2,50 dollari per milione di token in input e 15 dollari in output. Claude Sonnet 4.6 a 3 e 15 dollari. Gemini 3 Flash a 0,50 e 3 dollari. DeepSeek V3 a 0,27 e 1,10 dollari. Sembrano cifre piccole. Sono il motivo per cui i CFO mostrano scetticismo verso l’on-premise: “Ma quanto vuoi che mi costino qualche centinaio di milioni di token al mese?”.

Il problema è che “qualche centinaio di milioni di token al mese” non è la realtà di una azienda che usa l’AI sul serio. La realtà è che, quando un sistema AI entra dentro i processi e gli utenti se ne accorgono, il consumo esplode. Un agente AI che fa RAG su documenti aziendali per 100 dipendenti può facilmente bruciare 500 milioni di token al mese fra input e output, una volta che gli utenti hanno preso confidenza con lo strumento. A questi volumi, i conti cambiano.

Vediamo un esempio. Azienda media italiana, 200 dipendenti, agente AI interno per assistenza alla documentazione tecnica e supporto commerciale. Volume tipico: 1 miliardo di token input + 200 milioni di token output al mese (lo skew input/output è alto perché il RAG ricarica documenti pesanti per ogni query). Con Claude Sonnet 4.6: 3.000 + 3.000 = 6.000 dollari al mese, 72.000 dollari l’anno. Con GPT-5.4: 2.500 + 3.000 = 5.500 dollari al mese, 66.000 dollari l’anno. Con Gemini 3 Flash come scelta low-cost: 500 + 600 = 1.100 dollari al mese, 13.200 dollari l’anno.

La forbice è larga, e dipende molto dal modello scelto. Tenete in mente questi numeri perché ci tornerò.

Il vero conto dell’on-premise

Per il setup on-premise, scomponiamo i costi in cinque voci. Le considero su un orizzonte di 36 mesi, che è il periodo di ammortamento tipico dell’hardware AI in Italia.

Hardware. Per servire 200 dipendenti con un modello Llama 3.3 70B in produzione, lo scenario realistico è un server con 2x RTX 5090 o singola H100, oppure un Mac Studio M4 Max 128 GB. Costo hardware: 8.000-15.000 euro per il Mac Studio, 25.000-40.000 euro per il server NVIDIA. Su 36 mesi di ammortamento, parliamo di 220-1.100 euro al mese.

Hosting e infrastruttura. L’hardware deve stare da qualche parte. Se è on-premise puro, c’è il costo del rack, del condizionamento, del power supply ridondato, della connettività enterprise. Stima realistica: 200-500 euro al mese. Se è in colocation italiana (per chi non ha sala server propria), 400-800 euro al mese. Se è su cloud privato italiano (Aruba, Seeweb, una delle nascenti soluzioni PSN), 600-1.200 euro al mese.

Elettricità. Una RTX 5090 sotto carico costante consuma 575W. Una H100 consuma 700W. Un Mac Studio M4 Max si ferma a 130W. Calcolando bolletta italiana media a 0,28 euro/kWh, un sistema NVIDIA sotto carico 16 ore al giorno costa 80-110 euro al mese. Un Mac Studio sotto stesso carico, 18 euro al mese. Su tre anni la differenza è di 2.000-3.000 euro.

Operations. Qui è dove il TCO si rompe per molte aziende. Un sistema AI on-premise richiede manutenzione continua: aggiornamenti dei modelli quando ne escono di migliori, monitoring delle performance, gestione dei picchi di carico, backup, sicurezza, integrazione con i sistemi aziendali. Per una PMI, parliamo di 0,3-0,5 FTE dedicati (dove FTE è equivalente a tempo pieno), che in Italia significano 18.000-35.000 euro l’anno solo di personale interno. In alternativa, contratto di managed service con un fornitore specializzato: 1.500-3.000 euro al mese.

Software e licenze. Lo stack open-source (Ollama, LocalAI, Qdrant, n8n) è gratuito. Però spesso servono componenti commerciali per features enterprise: monitoring tipo Datadog o New Relic, SSO con Okta o equivalenti, vector database managed per il RAG se non volete gestirlo voi. Stima media: 500-1.500 euro al mese.

Sommando tutto su 36 mesi, abbiamo questa fascia di costo TCO totale per il setup on-premise descritto sopra: dai 60.000 euro (scenario Mac Studio, ops interno minimo, no managed service) ai 200.000 euro (scenario server NVIDIA, ops managed, full stack enterprise) su 3 anni.

Tre scenari aziendali a confronto

Provo a costruire tre scenari realistici e a fare il calcolo TCO completo cloud-vs-onprem.

Scenario A – Studio professionale, 30 utenti, uso moderato.

Volume mensile stimato: 100 milioni di token input + 20 milioni di token output. Cloud con Claude Sonnet: 600 dollari/mese = 21.600 dollari su 3 anni. Cloud con GPT-5.4: 550 dollari/mese = 19.800 dollari. Cloud con Gemini 3 Flash: 110 dollari/mese = 3.960 dollari.

On-premise: Mac Mini M4 Pro 48 GB. Hardware 1.800 euro, hosting on-site 100 euro/mese, elettricità 8 euro/mese, ops 0,1 FTE = 6.000 euro/anno. Totale su 3 anni: 1.800 + 3.600 + 290 + 18.000 = 23.690 euro.

Verdetto: per uno studio piccolo che usa modelli economici (Gemini Flash, GPT-4o mini), il cloud resta più conveniente. Per chi vuole modelli di fascia alta (Claude Sonnet, GPT-5.4) e tiene ai dati sensibili, l’on-premise comincia a tornare. La discriminante qui non è solo il costo. Ci sta dentro la sensibilità dei dati gestiti, che pesa in modo diverso a seconda del settore.

Scenario B – Azienda media manifatturiera, 200 utenti, uso intensivo.

Volume mensile: 1 miliardo input + 200 milioni output. Cloud Claude Sonnet: 6.000 dollari/mese = 216.000 dollari su 3 anni. Cloud GPT-5.4: 5.500 dollari/mese = 198.000 dollari. Cloud Gemini Flash: 1.100 dollari/mese = 39.600 dollari.

On-premise: Mac Studio M4 Max 128 GB + cloud privato italiano. Hardware 4.500 euro, hosting cloud privato 800 euro/mese, elettricità inclusa nel cloud, ops 0,4 FTE = 24.000 euro/anno, software 1.000 euro/mese. Totale su 3 anni: 4.500 + 28.800 + 72.000 + 36.000 = 141.300 euro.

Verdetto: rispetto al cloud Claude Sonnet o GPT-5.4 (200k+ dollari su 3 anni), l’on-premise vince con margine ampio. Rispetto al cloud Gemini Flash low-cost, il cloud resta più economico se non avete vincoli di sovranità del dato. Per una manifattura italiana, dove la proprietà intellettuale dei processi è asset strategico, on-premise è la scelta da fare anche se costa qualche migliaio di euro in più.

Scenario C – Azienda servizi finanziari, 100 utenti, alta sensibilità.

Volume mensile: 500 milioni input + 100 milioni output. Cloud Claude Sonnet: 3.000 dollari/mese = 108.000 dollari su 3 anni. Però realisticamente, per una banca o assicurazione italiana, il cloud americano è impraticabile per ragioni di compliance.

On-premise: server NVIDIA con 2x RTX 5090 in colocation italiana. Hardware 30.000 euro, hosting colocation 700 euro/mese, elettricità 100 euro/mese, ops 0,5 FTE + managed service support = 50.000 euro/anno, software enterprise (SSO, audit, monitoring) 2.000 euro/mese. Totale su 3 anni: 30.000 + 25.200 + 3.600 + 150.000 + 72.000 = 280.800 euro.

Verdetto: il TCO è significativamente più alto del cloud equivalente in token, ma la domanda da farsi qui cambia. Diventa “qual è l’alternativa accettabile”. Per finanza e sanità italiana, l’on-premise non è una scelta di ottimizzazione costi, è un vincolo strutturale. Una volta accettato il vincolo, il calcolo diventa quanto investire bene per minimizzare i rischi.

Le voci che nessuno mette nel business case

Tre cose escono spesso fuori solo quando il progetto è già partito e si rivelano problemi.

La variabilità del prezzo cloud. I prezzi delle API LLM sono scesi tantissimo nel 2024 e 2025, ma non c’è nessuna garanzia che continuino a scendere allo stesso ritmo. Anzi, alcuni modelli premium (GPT-5.5 Pro a 30 dollari input e 180 output) suggeriscono che la forbice fra modelli economici e modelli avanzati si sta allargando. Un business plan a 3 anni costruito su prezzi attuali può essere completamente fuori bersaglio fra 18 mesi.

Il rate limiting. I provider cloud applicano limiti alle chiamate per evitare picchi. Sotto carico, una vostra applicazione AI potrebbe non riuscire a servire gli utenti, oppure dover pagare premium per priority access. È un costo che non c’è nel listino e si manifesta nei momenti peggiori. Su on-premise, il limite è solo l’hardware vostro.

La migrazione obbligata. I provider cloud deprecano modelli ogni 12-18 mesi. Un’applicazione costruita su GPT-4 nel 2024 oggi gira su GPT-5.4 con prompt diversi, comportamenti diversi, output marginalmente diversi. Ogni migrazione costa giorni o settimane di lavoro di prompt engineering e regression testing, che nei business case non finiscono. On-premise, voi decidete quando aggiornare e a quale modello.

Quando l’on-premise vince con margine

Riassumendo i tre scenari con un’occhiata pragmatica al TCO su 36 mesi:

Per uso moderato e modelli economici (Gemini Flash, DeepSeek): cloud resta più conveniente, soprattutto se non avete vincoli di compliance. La differenza è di qualche migliaio di euro.

Per uso intensivo e modelli di fascia alta (Claude Sonnet, GPT-5.4): on-premise comincia a vincere già al primo anno, e a 36 mesi la differenza può essere di 100-150k euro a favore del setup interno.

Per settori regolati (finanza, sanità, PA, manifattura strategica): la conversazione si sposta dal TCO assoluto al perimetro architetturale praticabile. Il cloud americano per certi tipi di dato è fuori discussione, e il costo dell’on-premise è il prezzo della compliance.

Lo strumento che amplifica il ROI dell’on-premise

C’è una variabile che cambia tutto il calcolo TCO, e ha a che fare con quanto efficiente è lo stack software che gestisce l’infrastruttura. Su questo ho investito personalmente come cofondatore di LocalAI.io. LocalAI è il gateway open-source che permette di gestire modelli multipli sullo stesso hardware, con API compatibile OpenAI, di cambiare modello sotto senza ritoccare le applicazioni, di orchestrare RAG e agenti, di fare A/B testing e monitoring.

L’effetto pratico sul TCO è significativo. Un’azienda che adotta LocalAI invece di gestire i singoli modelli individualmente tipicamente riduce di 0,2-0,3 FTE il fabbisogno di ops, che su 36 mesi significa 18-32k euro di risparmio. E soprattutto, riduce il costo della migrazione fra modelli a zero: quando esce un Llama 4 o un Qwen 5 migliore di quello che state usando, lo cambiate dalla console di LocalAI, le applicazioni sopra continuano a funzionare.

Per chi vuole approfondire il calcolo applicato al proprio caso specifico, ho scritto la settimana scorsa una guida hardware completa che entra nei dettagli per scenario, e una guida ai 10 motivi strategici per portare l’AI privata al tavolo del board. Per una conversazione specifica sul vostro contesto, c’è la pagina Advisory.

Il TCO è uno strumento di decisione, non una formula magica. Le aziende che scelgono on-premise non lo fanno per risparmiare qualche migliaio di euro al mese, lo fanno per avere il controllo strutturale di un’asset che sta diventando strategico per il loro business. Le aziende che restano sul cloud lo fanno perché la flessibilità conta più del controllo. Entrambe le scelte sono legittime, ed entrambe meritano di essere fatte con i numeri davanti, non con le sensazioni.

La domanda da portarsi nel comitato finanziario dei prossimi mesi è semplice. Quanto consumeranno realisticamente i nostri agenti AI fra 24 mesi, quando saranno integrati nei processi e gli utenti li useranno davvero? E a quel volume, qual è il TCO più basso dove la nostra compliance e la nostra sovranità del dato restano garantite?