enterprise AI Archives - Pagina 3 di 4

18 Giugno 202620 Luglio 2026AI & GENAI, TECH & BUSINESS

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

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

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

I volumi seguono i modelli cinesi

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

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

Il prezzo basso ha un indirizzo

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

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

Il routing come punto di controllo

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

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

La frontiera resta un permesso, non una proprietà

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

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

Costruire da qui con quello che si controlla

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

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

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

17 Giugno 202615 Giugno 2026AI & GENAI, TECH & BUSINESS

Ontologie e grafi di conoscenza: la struttura del sapere in azienda

Il marketing scrive «lead» e intende un indirizzo email lasciato in un form. Le vendite scrivono «lead» e intendono qualcuno pronto a firmare un contratto. Stessa parola, due significati lontani, e nel mezzo riunioni che girano a vuoto perché nessuno, in tutta l’azienda, si è mai seduto a stabilire cosa voglia dire davvero.

Capita ovunque, e quasi sempre resta invisibile. Finché non arriva un modello a cui chiediamo di leggere i nostri documenti e restituirci un po’ d’ordine: a quel punto il disaccordo che tolleravamo da anni smette di essere un fastidio di fondo e diventa la prima cosa che ci scoppia in mano.

Per capire perché, conviene tenere separate due idee che arrivano dal mondo del web semantico e che quasi tutti scambiano l’una per l’altra: l’ontologia e il grafo di conoscenza. Si somigliano e non coincidono, e la differenza dice parecchio su come è fatto il sapere dentro un’organizzazione.

Ogni azienda parla una lingua che non ha mai scritto

Un’ontologia, ridotta all’osso, è l’elenco delle cose che esistono in un certo mondo e delle regole con cui possono stare insieme. Quali tipi di oggetti ci sono (un cliente, un progetto, un margine, una commessa), come si legano tra loro (un cliente firma un contratto, un progetto consuma un budget), quali vincoli valgono sempre (una fattura appartiene a un solo cliente). Funziona meno come un diagramma pieno di frecce e più come una mappa condivisa del significato, tanto precisa che sopra ci può ragionare una persona appena arrivata quanto una macchina.

Solo che quasi nessuno la chiama così. Ogni azienda gira già su un’ontologia, implicita, non scritta, quasi sempre contesa. La parola «cliente» nel CRM, nell’amministrazione e nel customer care indica tre cose che si assomigliano senza combaciare. «Chiuso» per un commerciale e «chiuso» per chi gestisce la delivery raccontano due momenti diversi della stessa storia. Il vocabolario c’è, le regole pure, ma vivono nella testa delle persone, tramandate per consuetudine, mai messe nero su bianco.

La conoscenza che non sta in nessun documento

Se l’ontologia è la mappa del significato, il grafo di conoscenza è il territorio già abitato: i fatti concreti, le persone e le cose reali, collegati uno all’altro. Questo cliente legato a quella commessa, quella decisione presa sulla base di quel dato, quel fornitore che conosce bene quel reparto. Nodi e relazioni, niente di più.

E qui si tocca un nervo scoperto. Buona parte di questo grafo, nelle aziende, esiste già, però vive sparso: nelle teste delle persone, nei thread di chat, nelle mail, nei fogli di calcolo, nella memoria tacita di chi è lì da quindici anni e «sa come funziona». I documenti conservano testo. Le relazioni, che sono poi la materia che ci serve quando dobbiamo decidere o rispondere a una domanda, restano fuori, intrappolate tra le righe o, peggio, solo dentro una testa che prima o poi andrà in pensione. Un’azienda capace di tenere insieme quelle connessioni inizia a comportarsi come un’impresa che ragiona, più che come un archivio da consultare.

L’intelligenza artificiale disegna lo schema e poi lo riempie di errori

Fino a ieri tutto questo aveva un costo proibitivo. Scrivere l’ontologia voleva dire uno specialista chino su un editor formale per settimane. Popolare il grafo voleva dire eserciti di curatori a mano, oppure estrattori rigidi che si inceppavano al primo caso fuori standard. Lento di qua, lento di là, e quasi sempre un progetto che moriva prima di servire a qualcosa.

I modelli linguistici ribaltano l’economia della faccenda. Dai a un modello un paragrafo e ti restituisce entità e relazioni in pochi secondi. Il costo di rendere esplicito l’implicito, di tirare fuori dai testi sia la mappa sia i fatti, crolla quasi a zero. È la stessa frontiera sottile che in Pelle Digitale ho provato a raccontare, quella membrana dove il senso passa di continuo tra noi e le macchine senza che nessuno dei due lo possieda del tutto.

Poi c’è il rovescio, ed è la parte che in azienda fa più male. Lasciata a sé, l’AI inquina. Inventa categorie che non esistono, sbaglia i tipi, asserisce legami plausibili e falsi con la stessa disinvoltura con cui ne asserisce di veri. La disciplina che la salva è una sola: prima si concorda la mappa del significato, poi si lascia che sia quella mappa a fare da guinzaglio all’estrazione. Lo schema diventa il guardrail. Prima il senso condiviso, poi i fatti che lo riempiono, in quest’ordine e mai nell’altro.

E tutto regge a una condizione, che vale la pena dire per intero. La parte faticosa non è mai stata battere a tastiera i fatti, ma metterci d’accordo su cosa significano. L’AI toglie la digitazione e ci lascia esattamente lì, faccia a faccia con il disaccordo che avevamo nascosto sotto il tappeto. Vale anche quando colleghiamo questi modelli ai sistemi che già usiamo, per metterli a contatto con i dati che teniamo sparsi ovunque: la tecnologia per pescare nel nostro sapere c’è, però non decide al posto nostro cosa quel sapere voglia dire.

Chi possiede il significato di «cliente»?

Se l’AI smonta la fatica meccanica e ci consegna il disaccordo bello e impacchettato, allora la domanda vera si sposta dalla tecnologia all’organizzazione. Tutto si stringe attorno a una questione di potere: chi ha l’autorità di decidere cosa significa «cliente». Per anni la risposta è stata «nessuno», oppure stava sepolta in un team di enterprise architecture con cui mezza azienda non si parlava. Adesso quella domanda torna al centro e pretende una risposta esplicita.

Decidere il significato è un atto che pesa. Stabilire che «cliente» vuol dire una certa cosa equivale a scegliere quale definizione vince quando il marketing e la finanza la vedono in modo opposto, e quindi chi comanda su quel pezzo di realtà condivisa. È una scelta di disegno organizzativo travestita da dettaglio tecnico. L’ontologia smette di essere un artefatto da reparto IT e diventa un oggetto di governo, qualcosa che qualcuno deve possedere, mantenere, presidiare.

Le aziende che saltano questo passaggio non evitano la decisione. La delegano in silenzio al modello, che una definizione se la sceglie comunque, e se ne accorgeranno il giorno in cui i conti non torneranno e nessuno saprà spiegare il perché.

L’ontologia generica si copia con un prompt, la propria no

C’è un’ultima conseguenza, e riguarda la competizione. Se chiunque può chiedere a un modello di abbozzare un’ontologia generica e plausibile per un certo settore, allora il generico vale sempre meno. Scivola verso la commodity, alla portata di tutti allo stesso prezzo, vale a dire quasi gratis.

Quel che resta difficile da replicare è la mappa precisa e ben curata del proprio dominio. La struttura del sapere di quella specifica azienda, costruita sulle sue relazioni reali e sulle definizioni che le sono costate anni di discussioni e aggiustamenti, validata e tenuta in ordine, non si tira fuori con un prompt astuto. La barriera si sposta: dal possesso dei dati, che ormai hanno tutti, al possesso della struttura di significato sopra quei dati.

Ed è una barriera solida proprio perché è lenta. Costa tempo costruirla, costa presidio mantenerla, si nutre di conoscenza che su internet non c’è perché vive solo dentro quell’organizzazione. Reggere la spinta di questa trasformazione, come ha imparato chi ha visto le aziende assorbire gli shock di mercato degli ultimi anni, vorrà dire trattare la propria ontologia come un patrimonio, più che come lo scarto di un progetto finito in un cassetto.

La parte tecnica, ormai, è quasi un gioco da ragazzi. Gli strumenti per abbozzare un’ontologia dentro una scheda del browser esistono già e funzionano sorprendentemente bene. A mancare è altro: la voglia di sederci in una stanza, noi, e decidere una volta per tutte cosa vogliono dire le nostre parole.

Allora forse la domanda da cui partire non riguarda l’intelligenza artificiale. Mappare il nostro sapere lo saprà fare, e prima di quanto immaginiamo. Riguarda noi, e suona più o meno così: siamo davvero pronti a metterci d’accordo su cosa quel sapere significhi? Perché la mappa la disegnerà la macchina, ma il significato, quello, tocca ancora a noi.

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

15 Giugno 202620 Luglio 2026AI & 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.

14 Giugno 202620 Luglio 2026AI & 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).

Copertina del libro Incorruptible di Eric Ries

12 Giugno 202615 Giugno 2026AI & 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.

11 Giugno 202611 Giugno 2026AI & GENAI, TECH & BUSINESS

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

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

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

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

La lingua italiana, prima di tutto

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

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

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

Qualità delle risposte sui task aziendali tipici

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

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

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

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

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

Hardware necessario e costi infrastrutturali

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

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

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

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

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

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

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

Licensing e implicazioni geopolitiche

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

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

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

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

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

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

Aggiornamenti e supporto della community

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

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

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

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

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

La scelta concreta per tre profili aziendali italiani

Provo a tradurre i criteri sopra in tre raccomandazioni operative.

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

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

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

Il valore di poter cambiare modello senza riscrivere

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

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

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

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

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

9 Giugno 202613 Giugno 2026AI & 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.

8 Giugno 202625 Maggio 2026AI & 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?

5 Giugno 20268 Giugno 2026AI & 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.