Tag: AI governance

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

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?

AI & GENAI

Mistral in azienda: API, self-hosting, Forge. Cosa scegliere e quanto costa davvero

Diciamo che hai deciso. Mistral è la direzione, per i motivi che ho elencato nella guida sulla scelta enterprise, e i modelli giusti li hai identificati con la mappa operativa. Resta la domanda che sposta davvero il progetto dal documento di intenti al go-live: come lo compri, dove lo metti, quanto costa nei prossimi tre anni. Le quattro opzioni sul tavolo sono Le Chat per i team interni, API La Plateforme per i developer, self-hosting on-premise per chi vuole sovranità totale, Forge per chi vuole un modello proprietario addestrato sui propri dati. Non vanno lette come alternative tra cui scegliere una, sono livelli architetturali che convivono nelle implementazioni enterprise reali.

Provo a metterle in ordine di complessità crescente, con costi realistici per un’azienda italiana media e i criteri per capire dove fermarsi.

Le quattro modalità di consumo, in un colpo d’occhio

Le Chat è il prodotto consumer e team. Interfaccia chat web, mobile app, integrazioni con Drive e altri storage. La versione Pro a 14,99 dollari al mese per utente è equivalente a ChatGPT Plus. La versione Team a 24,99 dollari per utente al mese aggiunge funzioni di collaborazione. La versione Enterprise è negoziata con il vendor e include SLA, supporto dedicato, SSO, audit log avanzati. Caso d’uso: dare ai dipendenti un assistente AI senza far passare dati per cloud americano.

La Plateforme è il prodotto API. Modello pay-per-token, accesso a tutti i modelli (Large, Medium, Small, Magistral, Devstral, Codestral, Ministral, Voxtral). Free tier con quote giornaliere per prototipazione, fatturazione mensile pay-per-use senza minimi contrattuali. I dati transitano dai data center europei di Mistral, l’azienda dichiara residency UE. Caso d’uso: developer che integrano AI nei prodotti, applicazioni esistenti che aggiungono funzionalità AI.

Self-hosting on-premise è il deployment dei modelli open-weight sull’infrastruttura aziendale. Scarichi i pesi, li metti su server GPU che possiedi o noleggi, esponi un endpoint compatibile OpenAI agli applicativi interni. Caso d’uso: settori regolati o con vincoli di sovranità del dato che escludono qualsiasi cloud, anche europeo.

Forge è la piattaforma di training custom annunciata da Mistral a NVIDIA GTC il 17 marzo 2026. Non è una soluzione di fine-tuning né di RAG: supporta pre-training e post-training completi sui dati aziendali, per costruire un modello proprietario dell’azienda. Caso d’uso: organizzazioni con dataset proprietari significativi e necessità di un modello che incorpori conoscenza interna profonda. Tra i primi clienti dichiarati ci sono ASML, Ericsson, European Space Agency, Reply, le agenzie governative di Singapore DSO e HTX.

In una banca media tipica le quattro modalità coesistono: Le Chat Team per i dipendenti, La Plateforme per i progetti di sviluppo interni, self-hosting per i carichi sensibili, e Forge entra in considerazione solo se c’è un dataset proprietario abbastanza grande da giustificarlo (di solito non è il caso, su cui torno sotto).

La Plateforme: prezzi reali e cosa costa davvero

I prezzi La Plateforme cambiano spesso, ma a maggio 2026 gli ordini di grandezza sono questi, in dollari per milione di token, secondo i dati ufficiali Mistral e tracker indipendenti come Artificial Analysis e Pricepertoken.

Per Mistral Large 3 si paga circa 2 dollari per milione di token in input e 6 dollari in output. Il dato che conta per il confronto con i concorrenti è che l’output a 6 dollari è circa il 60% sotto Claude Sonnet (15) e il 50% sotto Gemini Pro (12), e nei task aziendali tipici l’output pesa di più dell’input perché i modelli generano spesso testi più lunghi dei prompt.

Per Mistral Medium 3 il pricing è intorno a 0,40 dollari in input e 2 dollari in output, posizione di mezzo tra Small e Large che per la maggior parte dei carichi aziendali è il miglior rapporto qualità/prezzo.

Per Mistral Small 4 si scende a 0,15 dollari in input e 0,60 in output, prezzi paragonabili a DeepSeek e tra i più bassi del mercato per modelli multimodali di qualità accettabile.

Per Ministral 3B si sta intorno a 0,04-0,10 dollari per milione di token, e per Codestral 0,30 in input e 0,90 in output. Magistral Medium è circa 2 in input e 5 in output, Magistral Small intorno a 0,50 e 1,50.

Un esempio numerico per fissare l’ordine di grandezza. Un’azienda con duecento dipendenti che usa Mistral Medium come assistente interno via API, con un volume medio di trenta prompt al giorno per dipendente, prompt da 500 token e risposta da 1500 token, su 220 giorni lavorativi l’anno, fa circa 2,2 milioni di prompt/anno per circa 4,4 miliardi di token in totale. Costo annuale stimato intorno ai 5.000-7.000 dollari di API, più costi di rete e logging. Per la stessa azienda su Large 3 sarebbe nell’ordine dei 25.000-35.000 dollari. Su Small 4 scenderebbe sotto i 2.000.

C’è da aggiungere l’IVA italiana (Mistral fattura escludendo le imposte) e i costi di gestione (FinOps, monitoring, allocazione per centro di costo). Sono ordini di grandezza, non preventivi, ma servono a rompere l’illusione del “tanto l’AI costa poco”: per progetti significativi i numeri annui salgono velocemente, e proprio qui inizia ad avere senso ragionare di self-hosting.

Self-hosting on-premise: i veri costi totali a tre anni

Questo è il pezzo che mi viene chiesto più spesso, e dove vedo più stime a spanne. Provo a essere preciso, perché la differenza tra un calcolo serio e uno approssimativo è quello che fa fallire o riuscire il business case.

Per servire Mistral Medium 3.5 in self-hosting con throughput sufficiente a 500-1000 utenti aziendali concorrenti, servono mediamente due o tre GPU NVIDIA H200 con 141GB di memoria HBM3e ciascuna. Costo di acquisto a giugno 2026, listino e canale italiano, intorno ai 35-45 mila euro per GPU, quindi 80-120 mila euro di sole GPU. Aggiungi il server che le ospita (chassis Supermicro o Dell con due CPU EPYC, RAM, storage NVMe veloce per il caching), altri 25-35 mila euro. Tot hardware iniziale: 110-160 mila euro.

A questo si aggiunge il software stack: motore di inferenza (vLLM o TensorRT-LLM, gratuiti ma con configurazione che richiede competenze), vector database (Qdrant, Weaviate o Pinecone se non self-hosted), orchestratore di richieste (LangChain, LlamaIndex, o custom), monitoring (Prometheus, Grafana). Tutti open-source o a basso costo, ma servono 30-50 giornate-uomo di setup iniziale di un MLOps engineer, che ai prezzi italiani sono altri 18-30 mila euro tra interno e consulenza.

Operations a regime: il consumo elettrico di due H200 in carico medio è intorno ai 1500W per coppia, su 24/7 fanno circa 13 MWh/anno, intorno ai 3-4 mila euro/anno di sola elettricità in Italia (con prezzi industriali 2026). Manutenzione hardware con contratto vendor, 5-8% del valore l’anno, quindi 6-10 mila euro. Persona dedicata: di solito non serve un FTE intero ma 30-40% del tempo di un MLOps engineer, che diviso significa 25-35 mila euro/anno di costo allocato. Tot ops/anno: 35-50 mila euro.

Sommando: anno 1 = 130-210 mila euro (hardware + setup + ops), anni 2-3 = 35-50 mila euro/anno. Totale a tre anni: circa 200-310 mila euro, con il modello Mistral Medium 3.5 in self-hosting capace di servire un’azienda da 500-1000 dipendenti senza limiti di volume.

Confronto API: la stessa azienda su Mistral Medium via La Plateforme, con i numeri della sezione precedente moltiplicati per scala maggiore, spenderebbe nell’ordine dei 30-60 mila dollari/anno, quindi 90-180 mila dollari su tre anni. Il break-even economico tra le due opzioni si raggiunge tra i 18 e i 30 mesi per volumi di richiesta tipici enterprise. Per volumi più alti il break-even scende; per volumi più bassi sale.

Ma il punto centrale, per cui le aziende scelgono self-hosting anche oltre il break-even economico stretto, va al di là dei costi e tocca la sovranità del dato. Per un’organizzazione che ha vincoli regolatori sul “dove” del dato, il TCO va calcolato includendo il valore del rischio compliance evitato, che spesso è ordini di grandezza superiore al costo infrastrutturale puro.

Sull’analisi di TCO completa cloud vs on-premise ho scritto in dettaglio nella guida dedicata al TCO LLM, che entra anche sui costi nascosti che molti business case dimenticano.

L’aggancio con LocalAI: come si fa nella pratica

Mistral è il modello che vedo più frequentemente girare sotto stack open-source di self-hosting nelle implementazioni italiane, e nello specifico sotto LocalAI. Il motivo è banale: LocalAI espone un endpoint OpenAI-compatible che permette di sostituire le chiamate openai.chat.completions.create() con chiamate al server locale senza riscrivere applicazioni esistenti, e supporta nativamente il caricamento dei modelli Mistral via Hugging Face.

La configurazione tipica di un’implementazione enterprise italiana è questa. Server bare metal in un data center proprietario o presso un provider cloud sovrano (es. ACI, Aruba, WIIT). LocalAI come orchestratore di inferenza, configurato per caricare Mistral Medium 3.5 quantizzato (di solito FP8 o INT8 per ottimizzare memoria GPU senza degrado qualitativo significativo). Vector database Qdrant per il RAG sui documenti aziendali. Endpoint esposto al solo perimetro interno via VPN o rete privata.

I tempi sono concreti. Setup iniziale di un’implementazione standard: 4-6 settimane di sviluppo per portarla in produzione, dato che parta da zero, con un team di un MLOps engineer più un developer più un security engineer part-time. Stabilizzazione: altre 4-8 settimane per tarare ottimamente il modello sui carichi reali e il prompt engineering interno. Da quel momento, gestione a regime con 30-40% di un MLOps engineer.

Forge: il livello più alto della scala, e quando ha davvero senso

Forge è la promessa più ambiziosa di Mistral: non più adattare un modello generico al tuo contesto via fine-tuning o RAG, ma costruire un modello proprietario completo addestrato esclusivamente sui dati aziendali. Pre-training, post-training, reinforcement learning, tutto sull’infrastruttura del cliente. Il modello finale è dell’azienda, non di Mistral, e gira dove vuole il cliente.

Il modello commerciale è particolare. Forge è venduto come piattaforma software con license fee, mentre il compute lo paga l’azienda direttamente (di solito sul proprio cluster GPU o su NVIDIA DGX Cloud). C’è l’opzione di “forward-deployed scientist” Mistral che si installano fisicamente in azienda per gestire il progetto, costo extra. È un modello da consulenza enterprise più che da SaaS.

Quando ha davvero senso. ASML ha aderito perché ha decenni di dati proprietari sulla produzione di macchine litografiche per semiconduttori, dataset altamente specialistici che nessun modello generico cattura correttamente. Ericsson per le specifiche di rete 5G e 5G Advanced, knowledge base che vale anni di R&D interna. ESA per dati di missione e analisi spaziale. Questi sono i profili di cliente Forge: organizzazioni con dataset proprietari di grandezza terabyte o petabyte e necessità di un modello che incorpori conoscenza specialistica profonda.

Quando non ha senso. Per la quasi totalità delle aziende italiane medie (banche regionali, manifatturiere da qualche centinaio di milioni di fatturato, sanità privata), Forge è eccessivo. Il loro problema non è “il modello generico non capisce abbastanza il mio dominio”, è “ho bisogno di un modello con sovranità del dato che lavori sulla mia knowledge base”. Quel problema lo risolve self-hosting più RAG, non Forge. Forge ha senso solo quando il dataset proprietario è la fonte primaria di valore competitivo dell’azienda, ed è abbastanza grande da giustificare un investimento da diversi milioni di euro nel training.

Un’analisi onesta del mercato, fatta da Nick Patience del Futurum Group a marzo 2026, evidenzia che secondo la Data Intelligence Decision Maker Survey 1H 2026, “il 42% degli intervistati spende più della metà del proprio tempo a mantenere e organizzare i dati esistenti invece di usarli produttivamente”. Il messaggio è che Forge presuppone un livello di maturità del dato che la maggior parte delle aziende non ha ancora raggiunto. Per la maggior parte dei progetti italiani, Forge è da considerare in fase due, non al primo go-live.

Vibe CLI: l’agente di coding nel terminale

Una nota breve su Mistral Vibe, perché è la componente che chiude il quadro per i team di sviluppo. Vibe è la CLI agentica di Mistral, lanciata insieme a Devstral 2 a dicembre 2025 e portata a Vibe 2.0 a gennaio 2026 con custom subagents e workflow controls. È paragonabile a Claude Code di Anthropic: un agente di coding che gira nel terminale dello sviluppatore, accede al filesystem del progetto, modifica file multipli mantenendo coerenza architetturale, esegue comandi, fa debugging iterativo.

Per un team di sviluppo italiano che già usa Mistral come provider primario, Vibe è il complemento naturale al modello via API. Per un team che invece sta valutando se Mistral è la scelta giusta anche per il coding agentico, Vibe più Devstral 2 sono concorrenti diretti di Claude Code più Claude Opus, e i confronti sui benchmark mettono Devstral 2 al 72,2% su SWE-bench Verified, in linea con i top di gamma proprietari ma a costi significativamente inferiori secondo i dati Mistral.

Compliance e governance: cosa chiedere al vendor

Chiudo con la parte che salva i progetti dai problemi a regime, e che spesso non viene trattata nelle slide commerciali del vendor.

AI Act: per i sistemi classificati ad alto rischio dal Capo II del regolamento, Mistral fornisce la documentazione tecnica del modello che alimenta gli adempimenti dell’articolo 11. Per il self-hosting questo è particolarmente importante perché la documentazione include training data approfondito, processi di mitigazione bias, valutazioni di robustezza. Chiedi al vendor il Model Card completo e il documento di valutazione del rischio per ciascun modello che usi.

GDPR: La Plateforme dichiara residency UE. Verifica nel DPA Mistral le clausole su sub-processor, trasferimenti, conservazione dei log. Per self-hosting il tema GDPR si sposta sulla tua infrastruttura, semplificando il quadro legale ma spostando l’onere tecnico sull’azienda.

NIS2: per le aziende soggette a NIS2 dall’ottobre 2024, le clausole di security incident notification con Mistral devono essere allineate. Il self-hosting riduce la superficie di rischio terza ma aumenta la responsabilità interna; entrambi gli scenari richiedono presidi di sicurezza adeguati.

Audit log: per qualsiasi implementazione enterprise, esigi log completi delle richieste con retention di almeno 12 mesi. Per self-hosting questo lo configuri tu (ed è un vantaggio: controllo totale). Per La Plateforme verifica nel contratto le condizioni di accesso ai log e il loro export.

Su queste decisioni mi è capitato di affiancare aziende italiane in tutte e quattro le configurazioni, da Le Chat Team in un’azienda di servizi professionali da centocinquanta persone fino a self-hosting completo con LocalAI in un istituto bancario. Quello che cambia il successo del progetto non è mai la tecnologia in sé, è la calibratura tra il caso d’uso reale, i vincoli regolatori specifici e la capacità organizzativa di sostenere l’architettura scelta nel tempo.

Se stai facendo questa valutazione per la tua organizzazione e ti serve un punto di vista esterno, contattami per una prima conversazione. Il primo passo è sempre capire quale combinazione regge il tuo caso reale, non quale è “la migliore” in astratto.

Leggi anche: costruire un'infrastruttura AI privata

AI & GENAI, TECH & BUSINESS

GDPR e LLM: quando un dato aziendale esce di casa

Il 18 marzo 2026 il Tribunale di Roma ha annullato la sanzione da 15 milioni di euro che il Garante per la protezione dei dati personali aveva irrogato a OpenAI nel novembre 2024 per la gestione di ChatGPT. Sentenza 4153/2026, motivazioni non ancora depositate, solo dispositivo. Quella sanzione era diventata, in due anni, il caso simbolo del rapporto fra GDPR e LLM. Adesso è caduta, e con lei l’idea che bastasse un provvedimento del Garante a chiarire i confini fra normativa europea e AI generativa americana.

Però il problema giuridico resta intatto: quando un dipendente di un’azienda italiana scrive il nome di un cliente dentro ChatGPT o Claude per riassumere un contratto, quel dato attraversa l’Atlantico, finisce in un’infrastruttura americana, viene processato da un modello di cui non controlliamo i dataset di training, e torna indietro come output. Sopra questo flusso si sovrappongono GDPR, AI Act, Schrems II, Data Privacy Framework, decisioni dei garanti nazionali, sentenze dei tribunali. Il risultato per chi lavora in azienda è una tela densa di vincoli che cambiano spesso, raramente in modo sincronizzato, e ognuno applicabile a casi specifici che non sempre il giurista interno riesce a circoscrivere bene.

Mi capita spesso, lavorando come advisor con CEO e CTO italiani, di sentire la stessa domanda formulata in modi diversi: ma alla fine, posso usare OpenAI sui dati dei miei clienti, o no? La risposta breve è che dipende, e quel dipende è dove si sta giocando una partita seria fra sovranità giuridica europea e dominanza tecnologica americana. Vorrei provare a dare una mappa praticabile, da imprenditore che ha visto il problema dal vivo, non da giurista.

Cosa dice il GDPR di un dato che entra in un LLM

Il GDPR è del 2016, è entrato in applicazione nel 2018, e nessuno dei suoi articoli è stato scritto pensando ai large language model. Però i suoi principi cardine restano applicabili a qualsiasi trattamento di dati personali, e un prompt che contiene il nome di una persona, l’indirizzo di un’azienda, una mail di un fornitore, una pratica medica, sono tutti dati personali ai sensi dell’articolo 4.

Quattro dimensioni del GDPR si attivano quando un dato personale finisce dentro un LLM cloud: la base giuridica del trattamento (articolo 6), la trasparenza nei confronti dell’interessato (articoli 12-14), la minimizzazione del dato (articolo 5), e il trasferimento internazionale verso paesi terzi (capitolo V, articoli 44-50). Il caso ChatGPT ha attivato tutte e quattro: il Garante italiano contestava a OpenAI di non avere una base giuridica adeguata per addestrare il modello sui dati personali, di non aver dato informativa agli interessati, di non aver implementato sistemi di age verification, e di trasferire dati verso gli Stati Uniti.

Il punto più sottile, però, è il quarto. Schrems II ha invalidato nel luglio 2020 il Privacy Shield che fino ad allora regolava il flusso di dati UE-USA. Da quel momento, ogni azienda europea che usa un servizio americano deve fare una valutazione caso per caso del rischio di sorveglianza governativa, deve adottare clausole contrattuali standard rafforzate, deve implementare misure tecniche supplementari come la cifratura end-to-end con chiavi che restano in UE. Nel luglio 2023 è arrivato il Data Privacy Framework, terzo tentativo dopo Safe Harbor e Privacy Shield, e Max Schrems ha già annunciato che lo porterà nuovamente davanti alla Corte di Giustizia. La storia, vista dall’esterno, sembra un loop che continua a non chiudersi.

Il caso ChatGPT e cosa è successo davvero

Vale la pena ricostruire il caso in tre passaggi, perché segna lo stato dell’arte del rapporto fra LLM e GDPR in Italia.

Marzo 2023: il Garante blocca temporaneamente ChatGPT in Italia per la prima volta. OpenAI si adegua su quasi tutti i punti contestati, il servizio viene riattivato dopo qualche settimana. Dicembre 2024: il Garante conclude l’istruttoria e sanziona OpenAI per 15 milioni di euro, ordinando anche una campagna informativa di sei mesi. Marzo 2026: il Tribunale di Roma annulla la sanzione, sentenza 4153/2026. Le motivazioni non sono ancora pubbliche al momento in cui scrivo, però il dispositivo è chiaro: la sanzione cade integralmente.

Cosa significa per chi deve decidere oggi se usare ChatGPT, Claude o Gemini sui dati aziendali? Tre cose, secondo me. La prima è che lo strumento sanzionatorio del Garante è meno solido di quanto sembrasse: i tribunali stanno mostrando di poter ribaltare provvedimenti anche molto strutturati. La seconda è che il fatto stesso che il caso sia arrivato fino qui dimostra quanto la materia sia controversa, e che ogni azienda italiana resta esposta a contestazioni se non struttura bene la propria posizione documentale. La terza è la più importante: l’annullamento della sanzione non significa che il trattamento sia lecito, significa solo che quel provvedimento specifico non reggeva. Il sostrato GDPR resta in piedi, e il prossimo caso può essere il vostro.

Le quattro verticali italiane dove il problema è già operativo

Negli ultimi diciotto mesi ho seguito direttamente o di sponda progetti in quattro settori italiani dove l’uso degli LLM cloud sta già generando attriti giuridici concreti. Vorrei riportare cosa ho visto succedere.

Banche e finanza. Le grandi banche italiane hanno tutte progetti AI attivi, però il commitment legale è massimo. Le sandbox interne usano modelli open-weight in infrastruttura privata. L’uso di ChatGPT o Claude su dati di clientela è proibito per policy nella stragrande maggioranza dei casi. Le DPIA (Data Protection Impact Assessment) sono diventate documenti corposi, con sezioni dedicate ai modelli AI, e gli ispettori di Banca d’Italia stanno cominciando a chiederle. Per le banche medio-piccole, che non hanno il budget per un’infrastruttura AI privata, il dilemma è reale: aspettare l’evoluzione normativa, o cominciare con il cloud accettando il rischio. La risposta che vedo emergere è terza: AI privata su Mistral, Llama o modelli simili, gestita on-premise o su cloud sovrano italiano.

Sanità. Qui la sensibilità è massima per ovvi motivi: i dati sanitari sono categoria particolare ai sensi dell’articolo 9 GDPR. Le aziende sanitarie pubbliche e private che ho visto adottare LLM stanno tutte andando su soluzioni private. Niente ChatGPT, niente Claude.ai dalla finestra del browser. Strumenti AI integrati nei gestionali clinici, con modelli fine-tuned su dataset sanitari e infrastruttura sotto controllo dell’azienda. Il vincolo qui è doppio: GDPR più normativa specifica sanitaria, e nessun primario è disposto a mettere la firma su un trattamento dove il dato esce dal perimetro ospedaliero.

Pubblica amministrazione. Il PSN (Polo Strategico Nazionale) e l’Agenzia per la Cybersicurezza Nazionale stanno dettando linee guida sempre più stringenti sull’uso di AI nei processi della PA. La direzione è chiara: dati pubblici dei cittadini italiani devono restare in cloud sovrani, su infrastrutture nazionali. Questo apre uno spazio commerciale enorme per soluzioni AI private che possano installarsi dentro il perimetro PSN. Diverse software house italiane si stanno posizionando su questo, e ho il sospetto che nei prossimi diciotto mesi vedremo accelerazione forte.

Manifattura e proprietà intellettuale. Qui il problema non è solo il dato personale, è il segreto industriale. Aziende manifatturiere italiane che caricano disegni tecnici, formule, processi produttivi dentro ChatGPT per chiedere ottimizzazioni stanno regalando informazioni potenzialmente strategiche a un fornitore che, per quanto contrattualmente impegnato a non trainare sui dati enterprise, opera comunque sotto giurisdizione americana. Il punto qui sfora dal GDPR, va su trade secret, segreto industriale, sicurezza economica nazionale. Però è una conversazione che adesso i CTO italiani fanno con i CEO, e prima non si faceva.

La banca italiana che voleva sapere dove gira il modello

Racconto una scena reale, leggermente anonimizzata. Lavoro nel 2025 con il team innovazione di una banca italiana medio-grande che sta valutando di adottare un sistema AI generativa per la customer assistance. Il fornitore propone un’integrazione standard con un grande modello cloud americano. Il responsabile compliance, dopo aver letto il contratto, chiede una cosa apparentemente semplice: “Possiamo avere certezza che, quando un nostro consulente filiale interroga il sistema con il nome di un cliente per ricostruire la sua posizione, quel nome non passi per un data center fuori dall’Unione?”. Il fornitore impiega due settimane per rispondere, poi torna con una soluzione ibrida che usa pre-processing locale e poi chiama il modello cloud su dati anonimizzati. Funziona, ma costa il doppio del setup originale, e introduce latenza.

Quella domanda era la domanda giusta, ed è la domanda che oggi fanno i clienti sofisticati durante le RFP. Se la vostra applicazione AI non sa rispondere bene a quella domanda, perde la gara. E rispondere bene, sempre più spesso, significa: “Il modello gira nella nostra infrastruttura, sotto controllo italiano, mai i dati escono dal perimetro”.

L’unica architettura che chiude il problema alla radice

Ci sono tre modi di gestire la conformità GDPR su un’applicazione AI in produzione. Il primo è usare un grande LLM cloud americano e costruire un apparato documentale e contrattuale robusto (DPIA, clausole contrattuali, registro dei trattamenti, valutazione TIA per il trasferimento dati). Funziona, ma è costoso da mantenere, e ogni cambio di policy del fornitore impone una nuova valutazione. Il secondo è usare un LLM cloud europeo, tipo Mistral hostato in Francia. Mitiga il problema del trasferimento extra-UE, ma non lo elimina del tutto perché Mistral comunque processa dati su infrastruttura cloud condivisa. Il terzo è portare il modello in casa, on-premise o su cloud privato sotto controllo aziendale.

Il terzo modo, che fino a due anni fa era proibitivo per ragioni di capex hardware e complessità operativa, oggi è alla portata di aziende dai 50 dipendenti in su. I modelli open-weight (Llama 3.3, Mistral, Qwen, DeepSeek) sono molto vicini alle prestazioni dei top di gamma cloud sui task aziendali standard. L’hardware necessario per farli girare in locale è sceso a una frazione di quello che serviva nel 2023. E lo stack software per orchestrarli sta maturando rapidamente.

Su questo terreno ho investito personalmente, come cofondatore di LocalAI.io. LocalAI è un progetto open-source che permette di costruire ecosistemi di AI privata partendo dai modelli open-weight esistenti, con tutto lo stack che serve per portare un prodotto in produzione: gateway compatibile con le API OpenAI, gestione di modelli multipli, RAG, agenti con memoria, deployment on-premise o su cloud privato italiano. È usato in produzione da aziende che hanno deciso di avere il proprio strato AI in casa, e da team che vogliono mantenere la flessibilità di cambiare modello senza rifare il prodotto.

La conversazione su GDPR e LLM nel 2026 si è spostata. Da terreno legale astratto è diventata terreno di architettura concreta. Le aziende italiane che capiscono questo, e che spostano il proprio stack AI dentro un perimetro controllato, eliminano alla radice il 70-80% delle questioni che oggi tengono sveglio il responsabile DPO. Le altre continueranno a discutere clausole contrattuali con i fornitori americani, a stipulare TIA che invecchiano dopo pochi mesi, a sperare che il prossimo accordo UE-USA regga davanti alla Corte di Giustizia. È legittimo, ma è un modo molto laborioso di costruire un prodotto AI serio.

Per chi sta vivendo questa decisione, ho scritto la settimana scorsa un articolo che riassume le dieci ragioni per portare l’AI privata al tavolo del board, e dopo questo articolo ne pubblicherò altri sul tema (TCO, scelta del modello open-weight, AI Act ad agosto 2026). Per una conversazione diretta sul vostro caso specifico, c’è la pagina Advisory.

La domanda finale, quella che vale la pena tenere davanti quando si decide oggi su un progetto AI aziendale, è semplice. Volete che la vostra compliance GDPR dipenda da una sentenza che può arrivare fra tre anni, da un accordo UE-USA che può essere annullato fra cinque, da un fornitore americano che può cambiare le sue policy fra tre mesi? Oppure preferite costruire il vostro prodotto sopra un’infrastruttura che resta sotto il vostro controllo, dove la conformità è una proprietà strutturale invece di un esercizio documentale continuo?