Tag: AI locale

AI & GENAI, TECH & BUSINESS

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

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

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

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

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

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

La logica del footprint tiene

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

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

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

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

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

Fine del frontier open weights occidentale

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

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

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

Una sera è bastata a spegnere due modelli

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

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

Routing e inferenza locale, il livello che resta tuo

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

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

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

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

Gli agenti rendono il problema più grave

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

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

La difendibilità si sposta dal modello al controllo

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

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

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

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

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

AI & GENAI, TECH & BUSINESS

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

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

Screenshot

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

Un export control ha messo offline un modello di frontiera

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

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

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

Permesso, non proprietà

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

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

Il controllo dell’AI è verticale

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

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

Dove può intervenire davvero un’azienda privata?

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

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

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

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

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

Il metodo viene prima della tecnologia

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

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

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

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

AI & GENAI, TECH & BUSINESS

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

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

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

Dentro i decreti attuativi resta una persona che decide

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

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

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

E i dati dove restano?

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

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

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

Alfabetizzazione critica, non addestramento

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

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

Un miliardo per l’ecosistema nazionale

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

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

La difendibilità si sposta sul controllo

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

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

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

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

AI & GENAI, TECH & BUSINESS

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

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

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

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

La lingua italiana, prima di tutto

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

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

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

Qualità delle risposte sui task aziendali tipici

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

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

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

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

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

Hardware necessario e costi infrastrutturali

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

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

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

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

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

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

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

Licensing e implicazioni geopolitiche

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

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

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

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

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

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

Aggiornamenti e supporto della community

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

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

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

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

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

La scelta concreta per tre profili aziendali italiani

Provo a tradurre i criteri sopra in tre raccomandazioni operative.

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

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

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

Il valore di poter cambiare modello senza riscrivere

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

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

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

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

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

AI & GENAI, TECH & BUSINESS

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

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

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

La trappola del prezzo a token

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

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

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

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

Il vero conto dell’on-premise

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

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

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

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

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

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

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

Tre scenari aziendali a confronto

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

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

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

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

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

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

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

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

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

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

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

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

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

Le voci che nessuno mette nel business case

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

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

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

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

Quando l’on-premise vince con margine

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

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

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

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

Lo strumento che amplifica il ROI dell’on-premise

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

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

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

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

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

AI & GENAI

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

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

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

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

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

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

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

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

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

La Plateforme: prezzi reali e cosa costa davvero

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

L’aggancio con LocalAI: come si fa nella pratica

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

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

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

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

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

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

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

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

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

Vibe CLI: l’agente di coding nel terminale

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

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

Compliance e governance: cosa chiedere al vendor

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

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

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

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

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

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

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

Leggi anche: costruire un'infrastruttura AI privata

AI & GENAI, TECH & BUSINESS

Hardware per LLM locale 2026: Mac, NVIDIA, costi reali

Tre anni fa, “far girare un LLM in locale” significava possedere una workstation con due NVIDIA H100, sapere cosa fosse vLLM, e accettare che il tutto sarebbe stato comunque più lento e meno preciso di una qualsiasi chiamata API a GPT-4. Era un esercizio da ricercatori, da appassionati, da aziende con budget infrastrutturali serissimi.

Nel 2026 il quadro è cambiato. Un Mac Mini M4 Pro da 1.799 euro fa girare Llama 3.3 70B a quantizzazione aggressiva, a 5-10 tokens al secondo, sufficiente per la quasi totalità dei task aziendali batch. Un Mac Studio M4 Max a 4.000 euro arriva a 30-45 tok/s sui modelli da 70B. Una workstation NVIDIA con RTX 5090 supera i 100 tok/s. E sotto, una nuova categoria di mini PC ottimizzati per AI sta emergendo come alternativa serissima, con NVIDIA DGX Spark, AMD Strix Halo, Framework Desktop.

Da quando ho cofondato LocalAI.io mi capita ogni settimana di rispondere alla stessa domanda da CTO italiani: “Quale hardware per LLM locale mi serve per cominciare?”. La risposta dipende da tre variabili che vanno tenute insieme, e che voglio provare a smontare in questo articolo: che modelli volete far girare, quanti utenti simultanei dovete servire, quanto budget e quanto tempo siete disposti a investire nell’ops.

Cosa determina davvero la velocità di un LLM in locale

C’è una metrica che vale più di tutte le altre quando si parla di inferenza LLM: la banda di memoria. Non la potenza di calcolo, non i TFLOPS, non i CUDA cores. È la banda con cui il chip riesce a leggere i pesi del modello dalla memoria, perché generare un token nuovo richiede di leggere TUTTI i pesi del modello, ogni volta. Un modello da 70 miliardi di parametri quantizzato a 4 bit pesa 35-40 GB, e ogni token generato è una passata completa di quei 40 GB.

Su questo dato si gioca la partita fra Apple Silicon e NVIDIA. Una RTX 4090 ha 1.008 GB/s di banda di memoria. Un M4 Max arriva a 546 GB/s, un M4 Pro a 273 GB/s, un M4 base a 120 GB/s. Significa che, modello per modello, NVIDIA è 2-3 volte più veloce di Apple Silicon top di gamma sui token al secondo. Però Apple Silicon ha un asso che NVIDIA non ha: la memoria unificata. Un Mac Studio M4 Max con 128 GB di RAM unificata fa girare modelli che non entrano in nessuna GPU consumer NVIDIA, neanche la 5090 da 32 GB. Per le aziende che vogliono lavorare con modelli da 70B in alto, Apple resta spesso l’unica opzione consumer.

Una nota di realismo importante. Apple sta arrivando con M5 Max e M5 Ultra previsti per fine 2026 con banda di memoria che dovrebbe superare 1 TB/s e tensor core FP8 nativi nel Neural Engine. Se le anticipazioni reggono, il gap di throughput per token con NVIDIA H100 si chiuderà quasi del tutto sull’inferenza, e l’asso della memoria unificata resterà comunque sul tavolo.

Quattro fasce hardware e cosa ci fate dentro

Provo a mappare quattro fasce di setup, dalla più accessibile alla più seria, con i numeri reali di throughput misurati con LLMCheck e altre fonti pubbliche aggiornate a maggio 2026.

Fascia 1: laptop e Mac Mini base, sotto i 1.000 euro. Un MacBook Air M2/M3 con 16 GB, un Mac Mini M4 base 16 GB, un mini PC NUC con CPU recente e 32 GB RAM. Modelli che ci girano bene: Phi-5 Mini, Llama 3.2 3B, Qwen 2.5 7B in quantizzazione Q4. Velocità tipica 40-80 tok/s sui modelli piccoli. Adatto a sperimentare, fare RAG su piccoli corpus documentali, sviluppare prototipi. Non adatto a produzione aziendale seria, non adatto a servire più utenti simultanei.

Fascia 2: workstation singolo utente, 1.500-3.000 euro. Mac Mini M4 Pro 24 GB o 48 GB. PC desktop con RTX 4070/4080. Modelli che girano: Llama 3.3 14B, Mistral Small, Qwen 4 32B-A3B (modello MoE con 3B parametri attivi, eccellente rapporto qualità/velocità sul Mac), Gemma 4 26B. Velocità tipica 25-55 tok/s sui modelli 14-32B. Adatto a uno sviluppatore singolo, a piccolo team che condivide, a applicazioni interne con pochi utenti. Il Mac Mini M4 Pro 48 GB a 1.799 euro è il punto di equilibrio prezzo-prestazioni che consiglio più spesso oggi a chi inizia.

Fascia 3: workstation potente, 4.000-7.000 euro. Mac Studio M4 Max con 64 GB o 128 GB. PC desktop con RTX 4090 o 5090 (32 GB VRAM). Modelli che girano: Llama 3.3 70B Q4 a 30-45 tok/s sul Mac Studio, Qwen 4 70B, DeepSeek R2 in versione compressa. Adatto a produzione interna seria su 10-50 utenti, a serving di applicazioni RAG complesse, a fine-tuning leggero. È la fascia dove Apple Silicon vince per memoria, NVIDIA vince per pura velocità, e la scelta dipende molto dal vostro mix specifico di modelli e workload.

Fascia 4: server-class, 15.000 euro in su. Mac Studio M3 Ultra con 256 GB (per workload memoria-bound). Server NVIDIA con due o quattro RTX 5090 in parallelo, oppure singola H100 da 80 GB. Apple offre DGX Spark, NVIDIA i sistemi DGX. Adatto a piccole-medie aziende che vogliono servire il proprio strato AI internamente a centinaia di utenti, a fine-tuning serio, a training di modelli specializzati piccoli. È la zona dove il ragionamento smette di essere consumer-DIY e diventa decisione infrastrutturale aziendale, con tutto quello che comporta in termini di networking, raffreddamento, alimentazione, backup.

Una scelta concreta per ogni profilo aziendale

Vorrei provare a passare dalle tabelle astratte a tre scenari aziendali che ho visto in concreto negli ultimi mesi, e dire cosa consiglierei in ciascuno.

Studio professionale, 10-30 dipendenti, vuole fare AI privata per RAG su documenti interni. Mac Mini M4 Pro 48 GB, modello Llama 3.3 14B o Qwen 4 32B-A3B. Costo totale 1.800 euro una tantum più il tempo di setup. Stack: Ollama come motore di inferenza, LocalAI come gateway compatibile OpenAI, un vector database come Qdrant in Docker per il RAG. Tempo medio di setup completo: una giornata di lavoro per uno sviluppatore che sa cosa fa. Sufficiente per 5-15 utenti simultanei con interazioni occasionali, non per una chat sempre attiva di 30 persone.

Azienda manifatturiera, 100-300 dipendenti, vuole un agente AI interno con accesso a documenti tecnici e gestionale. Mac Studio M4 Max 128 GB, modello Llama 3.3 70B Q4. Costo totale 4.000-5.000 euro hardware. Setup più articolato: LocalAI per orchestrare modelli multipli (uno per chat conversazionale, uno specializzato sui documenti tecnici), Qdrant o Weaviate per la memoria vettoriale, n8n o Make per le integrazioni con i sistemi aziendali. Tempo di setup completo realistico: una settimana di lavoro di un team da 2 persone. Capacità: 30-50 utenti simultanei.

Azienda servizi finanziari medio-piccola, 50-150 dipendenti, vuole un sistema AI con vincoli GDPR strettissimi. Qui non è solo hardware, è architettura completa. Server con 2x RTX 5090 o singola H100 in colocation italiana, modello Qwen 4 70B o Mistral Large, stack di sicurezza completo con SSO, audit log, segmentazione di rete. Costo hardware 20-30k euro, costo annuale di hosting e operations 30-50k. Setup: 4-6 settimane di lavoro di un team specializzato, magari con il supporto di chi conosce il dominio (qui entra il valore dell’advisory). Capacità: 100-300 utenti simultanei con alto livello di compliance.

Il problema dei costi nascosti

Le aziende che valutano l’AI privata guardando solo al costo dell’hardware sbagliano la metà del calcolo. L’altra metà sono tre voci che spesso non finiscono nei business case ma esistono comunque.

La prima è l’elettricità. Una RTX 5090 sotto carico consuma 575 watt. Un Mac Studio M4 Max si ferma a 130 watt. Su un anno di utilizzo continuativo, parliamo di una differenza di 1.500-2.000 euro l’anno solo di bolletta italiana. Il Mac è in questo molto più efficiente, ed è uno dei motivi per cui molte PMI italiane ci stanno arrivando.

La seconda è il tempo di setup e di manutenzione. Una RTX 5090 richiede driver CUDA, configurazione di vLLM o llama.cpp, tuning della quantizzazione, debugging di edge case su modelli specifici. Un Mac Mini con Ollama va da zero al primo prompt in dieci minuti. Per un’azienda piccola, il tempo del proprio sviluppatore è la voce più costosa di tutte: vale la pena pagarla anche 500 euro in più all’hardware se questo significa risparmiare due giorni di setup.

La terza è il rinnovo. L’hardware AI sta evolvendo velocemente. Un acquisto di oggi è probabilmente sostituibile entro 3 anni con qualcosa di significativamente meglio. Vale la pena pensare il setup in modo modulare, dove l’orchestrator (LocalAI), il vector DB, gli agenti, sono indipendenti dal motore di inferenza sottostante, così quando arriva la prossima generazione di chip si cambia solo quello.

Il software che fa la differenza

L’hardware è metà del lavoro. L’altra metà è lo stack software che ci gira sopra, ed è dove negli ultimi 12 mesi è cambiato tutto. Tre componenti vanno scelti bene fin dall’inizio.

Il motore di inferenza. Ollama è la scelta più semplice per cominciare, perfetto per Mac e PC, ha l’API compatibile OpenAI, supporta MLX su Apple Silicon dalla versione 0.5. Llama.cpp è la base sotto Ollama, più tecnico, dà più controllo. vLLM è per setup server seri con GPU NVIDIA, supporta batching e ha throughput superiore per più utenti. MLX è il framework Apple ottimizzato per Metal, può essere 30-50% più veloce di Ollama su Mac per alcuni modelli. La scelta dipende dal vostro hardware e dal team che dovrà manutenerlo.

L’orchestratore. Qui è dove entra LocalAI. Senza un orchestratore, ogni applicazione del vostro stack chiama direttamente Ollama o vLLM, e quando volete cambiare modello dovete ritoccare ogni client. Con un orchestratore, esponete un unico endpoint compatibile OpenAI, ci puntate tutte le applicazioni, e potete scambiare il motore sotto, gestire più modelli in parallelo, fare A/B testing, aggiungere autenticazione e logging. È il single point of integration che vi salva mesi di refactor quando l’hardware sotto cambia.

Il vector database per il RAG. Qdrant è la scelta più equilibrata oggi, gira bene su hardware modesto, ha buona documentazione, supporta filtri complessi. Weaviate è più potente ma più pesante. Chroma è il più leggero per iniziare ma scala meno. La scelta qui dipende dalla dimensione del corpus documentale che pensate di gestire.

Da dove cominciare se siete una PMI italiana

Se siete il CTO di una PMI italiana e state pensando di portare l’AI in casa, il mio consiglio è ridurre il primo step alla minima espressione possibile. Comprate un Mac Mini M4 Pro 48 GB. Installateci Ollama in dieci minuti. Scaricateci sopra Llama 3.3 14B o Qwen 4 32B. Apriteci sopra LocalAI come gateway. Provate una settimana con un caso d’uso piccolo, magari un agente che risponde a domande sul vostro manuale aziendale via RAG. Misurate latenza, qualità delle risposte, soddisfazione degli utenti.

Se la prova regge, scalate. Se non regge, avete speso 1.800 euro e una settimana di tempo per imparare cosa serve davvero. Confronto con un POC su OpenAI o Anthropic che, fra licenze enterprise e committment iniziale, sarebbe costato spesso di più senza darvi controllo dell’infrastruttura.

L’AI privata oggi non è più un esperimento da ricercatori. È una scelta di architettura accessibile, con costi noti e curva di apprendimento ragionevole, soprattutto per chi parte dai modelli open-weight più solidi (Llama, Mistral, Qwen) e da uno stack software maturo (Ollama, LocalAI, Qdrant).

Per chi vuole capire come si costruisce concretamente l’ecosistema sopra l’hardware, ho scritto una guida completa a LocalAI qualche mese fa, e nelle prossime settimane pubblicherò una guida operativa step-by-step all’installazione completa in azienda. Per chi sta valutando il setup giusto rispetto alle proprie necessità specifiche, c’è la pagina Advisory con i formati di lavoro che propongo.

La domanda da farsi oggi non è più “siamo pronti per l’AI privata”. È: che modello vogliamo far girare per primo nei nostri processi, e su che hardware lo facciamo girare nei prossimi sei mesi?

AI & GENAI

I modelli Mistral nel 2026: come scegliere tra Large 3, Medium 3.5, Small 4, Magistral, Devstral

Tra dicembre 2025 e aprile 2026, Mistral ha rilasciato Large 3, Magistral 1.2 in due taglie, Devstral 2 più la versione Small, Mistral Small 4, la nuova famiglia Ministral 3 in tre dimensioni, Codestral 25.08, Codestral Embed, Voxtral per l’audio, Mistral Medium 3.5. A spanne, undici modelli in cinque mesi, con nomi che a chi non segue il settore quotidianamente sembrano scelti per confondere. Quale ti serve davvero dipende dal carico che vuoi spostare, e la risposta cambia molto tra “assistente interno per duecento dipendenti” e “agente di coding autonomo nel terminale”.

Questa è la mappa che uso quando un’azienda mi chiede di capire l’ecosistema Mistral prima di una decisione di acquisto. Niente classifiche universali, niente “il migliore di tutti”: ogni modello vince in uno scenario specifico, e la scelta diventa banale una volta che hai chiaro il caso d’uso. Per il contesto strategico su perché un’azienda italiana dovrebbe guardare Mistral prima degli altri, c’è la guida pillar sulla scelta enterprise. Qui scendiamo nei singoli modelli.

La mappa dei modelli del 2026

Tre famiglie principali, ognuna con una funzione precisa, più due linee verticali specializzate.

Le famiglie generaliste sono tre: Mistral Large 3 (flagship MoE, ammiraglia di gamma), Mistral Medium 3.5 (dense, ottimizzato per self-hosting e workload agentici), Mistral Small 4 (modello unificato reasoning più visione più coding). Tre opzioni che coprono i casi d’uso generici dal più pesante al più leggero.

La linea reasoning è Magistral 1.2, in due taglie: Magistral Medium per l’enterprise, Magistral Small per il self-hosting permissivo. Si chiama in causa quando il task richiede chain-of-thought esplicito: dimostrazioni matematiche, analisi logiche multi-passo, problemi di programmazione algoritmica.

La linea coding è doppia. Devstral 2 (123B parametri) e Devstral Small 2 (24B) per il coding agentico autonomo, Codestral 25.08 e Codestral Embed per l’autocompletamento in IDE e l’embedding di repository.

La linea edge è Ministral 3 in tre tagli (3B, 8B, 14B parametri), pensata per girare su dispositivi: telefoni, edge gateway, sistemi embedded.

La linea multimodale è Voxtral per audio, text-to-speech e trascrizione, recentemente uscita open-weight con dimensioni che permettono il deploy su smartphone.

Tutti i modelli flagship sono rilasciati sotto Apache 2.0 o licenze permissive equivalenti, con l’unica eccezione di Devstral 2 (Modified MIT, che resta open-source ma con qualche clausola in più). I pesi sono pubblicamente scaricabili, il self-hosting funziona davvero, le API La Plateforme sono un’opzione aggiuntiva ma non l’unica.

Mistral Large 3: l’ammiraglia per i carichi generalisti più pesanti

Large 3 è il modello flagship rilasciato a dicembre 2025 con il codename mistral-large-2512. Architettura Mixture of Experts da 675 miliardi di parametri totali, di cui 41 miliardi attivi a ogni inferenza. Tradotto in operativo: la qualità di output di un modello da 675B con il costo computazionale di un modello da 41B, perché il MoE attiva solo gli esperti rilevanti per ogni token.

Sui benchmark indipendenti, secondo le valutazioni LayerLens/Atlas, Large 3 raggiunge il 73,11% su MMLU-Pro e il 93,60% su MATH-500. È debuttato al secondo posto nella categoria open-source non-reasoning di LMArena. Numeri che lo mettono nella stessa fascia di qualità di GPT-4.1 e Claude Sonnet 4.6 per i task generalisti, con un costo per token sull’output che è circa 60% sotto Claude e 40% sotto GPT-4.1 a parità di volume.

Quando ha senso. Carichi di analisi documentale lunga, ragionamenti complessi su contesti misti, generazione di contenuti tecnici lunghi, supporto a decision-making aziendale che richiede capacità di sintesi su corpus eterogenei. È il modello che metti via API La Plateforme quando il task è abbastanza complesso da non poter essere delegato a Medium o Small, ma non così specialistico da richiedere Magistral.

Quando non ha senso. Self-hosting on-premise, perché l’infrastruttura per servire un MoE da 675B richiede otto GPU H200 in cluster, configurazione che fa salire l’investimento iniziale oltre il milione di euro e che ha senso solo per organizzazioni che processano milioni di richieste al giorno. Per chi vuole self-hosting il modello giusto è Medium 3.5, vedi sotto.

Il contesto è 128K token, in linea con GPT-5 e Claude per la versione standard. Non è il modello con la finestra più ampia (DeepSeek V4 e GPT-5.4 offrono 1M), ma per la quasi totalità dei casi enterprise 128K bastano. Quando non bastano, di solito il problema è di architettura del prompt, non di limite del modello.

Mistral Medium 3.5: il modello pensato apposta per il self-hosting enterprise

Medium 3.5 è uscito il 29 aprile 2026, ed è probabilmente il modello più importante della famiglia per il contesto italiano. Architettura dense (non MoE), dimensione tale da girare su due o tre GPU NVIDIA H200, ottimizzato esplicitamente per workload agentici e coding, comportamento più prevedibile dei MoE.

La parola chiave è “prevedibile”. Quando un MoE come Large 3 viene messo in self-hosting, il routing degli esperti introduce una varianza che complica il dimensionamento dell’infrastruttura, la calibrazione del rate limiting, la gestione della latenza percepita. Su un modello dense come Medium 3.5 questi problemi spariscono: ogni richiesta usa tutti i parametri del modello, la latenza è costante, l’infrastruttura è più semplice da governare.

Per un CIO che sta dimensionando un self-hosting on-premise in una banca o in un gruppo manifatturiero, questa prevedibilità vale più di qualche punto percentuale in più sui benchmark. Significa contratti di SLA che si possono firmare, capacity planning che funziona, ops engineering che non passa metà del tempo a debuggare comportamenti inattesi.

Quando ha senso. Self-hosting on-premise come modello principale aziendale, workload agentici con tool use intensivo, integrazione con LocalAI o stack on-premise simili. È il modello che vedo più spesso scelto come default nei progetti enterprise italiani.

Quando non ha senso. Carichi consumer ad altissimo volume dove conta il prezzo al token assoluto: in quel caso Small 4 o Ministral sono più economici. Task di reasoning estremo: meglio Magistral 1.2.

Mistral Small 4: l’unificazione del marzo 2026

Small 4 è uscito il 16 marzo 2026 con un’idea precisa: prendere tre modelli precedenti (Magistral per il reasoning, Pixtral per il multimodale, Devstral per il coding agentico) e fonderli in un unico sistema che faccia tutte e tre le cose decentemente, invece di richiedere tre modelli separati con tre integrazioni diverse.

Contesto 262K token, prezzo La Plateforme a 0,15 dollari per milione di token in input e 0,60 in output. È il modello più economico della fascia “qualità decente” di Mistral, e l’unificazione delle capability significa che si può usare come workhorse per la maggior parte dei task aziendali medi.

Quando ha senso. Il caso d’uso più ricorrente è l’assistente aziendale interno per medie aziende, dove serve un modello che capisca testo, immagini, codice senza dover orchestrare modelli diversi a seconda del task. Anche carichi di chatbot, customer support assistito, analisi documentale di medio livello.

Quando non ha senso. Carichi che richiedono il massimo della qualità su una singola dimensione: Large 3 batte Small 4 sul reasoning generico, Magistral 1.2 lo batte sul reasoning specialistico, Devstral 2 lo batte sul coding agentico autonomo. Small 4 è la scelta giusta quando il valore è nella semplicità architetturale, non nella performance di picco.

Magistral 1.2: la linea reasoning, Medium e Small

Magistral è la famiglia di reasoning models di Mistral, equivalente concettuale di OpenAI o3 e o4. Versione 1.2 rilasciata a settembre 2025 con i codename magistral-medium-2509 e magistral-small-2509. Due varianti: Medium per l’enterprise via API, Small (24B parametri) sotto Apache 2.0 per il self-hosting.

La caratteristica distintiva è la modalità “Flash Answers”, che permette di alternare tra inferenza standard (veloce) e chain-of-thought esplicito (più lento ma con tracciamento del ragionamento). Per task come dimostrazioni matematiche, problem-solving algoritmico, analisi giuridica multi-passo, l’output diventa interpretabile, e questo è un vantaggio enorme quando devi giustificare una decisione assistita da AI in un contesto regolato.

Sui benchmark di pura matematica OpenAI o3 mantiene un margine, ma il prezzo per token su Magistral è significativamente più basso e la latenza in Flash mode è competitiva. Magistral Small è particolarmente interessante: 24 miliardi di parametri, Apache 2.0, gira su una singola GPU H100, ed è quindi il modello di reasoning self-hostable più capace disponibile a giugno 2026.

Quando ha senso. Compliance finanziaria con tracciamento del ragionamento, supporto a decisioni in settori regolati dove l’audit trail è obbligatorio, problem-solving algoritmico, supporto alla redazione giuridica con catena logica esplicita. In tutti questi casi il chain-of-thought tracciabile vale più della pura performance bruta.

Quando non ha senso. Carichi conversazionali generici dove il reasoning esplicito introduce latenza inutile. Per quello c’è Large 3 o Medium 3.5.

Devstral 2 e Codestral: la linea coding

Devstral 2 è uscito a dicembre 2025 insieme alla CLI Mistral Vibe. È il modello coding agentico flagship: 123 miliardi di parametri dense, contesto 256K, raggiunge il 72,2% su SWE-bench Verified secondo Mistral. Per dare un riferimento, è uno dei migliori modelli open-weight per coding autonomo disponibili oggi, e secondo i dati Mistral è “fino a 7 volte più cost-efficient di Claude Sonnet sui task reali”, secondo l’annuncio ufficiale del rilascio.

C’è anche Devstral Small 2 a 24 miliardi di parametri, sotto licenza Apache 2.0, che gira su una singola GPU di fascia consumer-pro. La combinazione Devstral 2 più Vibe CLI è la risposta Mistral a Claude Code di Anthropic: agente di coding che gira nel terminale dello sviluppatore, capace di esplorare codebase, modificare file multipli mantenendo coerenza architetturale, fare debugging iterativo, gestire dipendenze framework.

Codestral è la linea complementare. Codestral 25.08 (codice codestral-2508) è il modello da 22B parametri specializzato in autocompletamento IDE con supporto nativo Fill-in-the-Middle, contesto 256K, ottimizzato per integrazioni JetBrains, VS Code, LangChain. Codestral Embed è invece il modello specifico per generare embedding di codice, utile per indicizzare repository e costruire knowledge base di codice aziendale.

Quando usare cosa. Devstral 2 con Vibe CLI per il coding agentico autonomo, cioè per l’agente che scrive feature complete partendo da una specifica. Codestral 25.08 per l’autocompletamento intelligente dentro IDE durante lo sviluppo manuale. Codestral Embed per indicizzare codebase aziendali e fare retrieval. Tre strumenti complementari, non alternativi.

Ministral 3: la linea edge per dispositivo

Ministral 3, rilasciato a dicembre 2025 insieme a Large 3, è la famiglia “minuscola” pensata per il deploy su dispositivo. Tre taglie: 3 miliardi di parametri, 8 miliardi, 14 miliardi. La 3B gira su uno smartphone, la 14B su un laptop di fascia alta.

Casi d’uso italiani concreti dove l’ho visto applicato. Industria 4.0 con macchinari offline che devono fare diagnostica locale senza connettività garantita, retail con POS che fanno traduzione real-time in più lingue senza chiamare API esterne, settore field service con tecnici che lavorano in cantieri o impianti remoti. In tutti questi scenari Ministral risolve il problema della “AI senza rete”, che con i modelli cloud non si chiude.

Per dare un’idea dei costi: Ministral 3B via La Plateforme costa circa 0,04-0,10 dollari per milione di token, a seconda della versione, il che lo rende uno dei modelli più economici del mercato. In self-hosting, gira gratis su hardware che già hai.

Voxtral: la linea audio

Voxtral è la famiglia audio uscita open-weight a marzo 2026, dimensioni che vanno dal modello da 24 miliardi per uso server fino a varianti compresse che girano su smartphone. Trascrizione, traduzione audio-to-audio, sintesi vocale, comprensione di audio complesso.

Per il contesto enterprise italiano è ancora una linea di nicchia, ma vale la pena tenerla in radar per casi specifici: contact center con trascrizione automatica delle chiamate, sanità con dettatura medica multilingua, accessibilità per servizi PA.

Italiano e multilingua: il discriminante che non viene dai benchmark

I benchmark MMLU e simili sono quasi tutti in inglese. Un modello che fa 92% su MMLU in inglese può fare 78% sul corrispondente italiano. Per chi costruisce assistenti interni in lingua italiana, questa differenza si sente nella qualità delle risposte, e Mistral parte avvantaggiata.

Il motivo è strutturale. Mistral è francese, addestra su corpus europei multilingua fin dalla prima versione, e l’italiano è una delle lingue di confine principali nei dataset di training continentali. Llama 3.3 ha colmato il gap su italiano generico, ma resta sotto Mistral sulla terminologia legale (clausole contrattuali, riferimenti normativi italiani), su quella finanziaria (regolamentazione Consob, normativa bancaria specifica), su quella tecnico-industriale (manuali di processo italiani, certificazioni di settore). Qwen e DeepSeek sono buoni sull’italiano generico ma introducono calchi grammaticali dal cinese che un madrelingua riconosce nei testi lunghi.

Per un’azienda italiana che costruisce un assistente interno destinato a colleghi italiani, questa è la differenza tra un agente che “sembra italiano” e uno che è italiano. Per il confronto sistematico tra le quattro famiglie open-weight principali, ho già pubblicato un confronto operativo Mistral vs Llama vs Qwen vs DeepSeek che entra nel dettaglio delle valutazioni per il mercato italiano.

La griglia di scelta operativa

Per chiudere, la griglia che uso quando un’azienda mi chiede “quale modello Mistral usiamo”.

Se il caso d’uso è un assistente interno generico per uso quotidiano dei dipendenti, Mistral Medium 3.5 self-hosted è la scelta default. Performance ottime, prevedibilità infrastrutturale, costo controllato a tre anni.

Se sono carichi esplorativi o sperimentali a basso volume in cloud, Mistral Large 3 via API La Plateforme. Massima qualità, paghi solo quello che usi.

Se è un workhorse multimodale a basso costo per volumi alti, Mistral Small 4 via API. È il rapporto qualità/prezzo migliore della famiglia per applicazioni mainstream.

Se serve reasoning tracciabile in settori regolati, Magistral Medium 1.2 via API, oppure Magistral Small in self-hosting se il volume giustifica l’infrastruttura.

Se è un agente di coding per il team dev, Devstral 2 con Vibe CLI. Se è autocompletamento dentro l’IDE, Codestral 25.08.

Se è un’applicazione che deve girare su dispositivo o offline, Ministral 3 nella taglia adatta all’hardware target.

Se è audio, Voxtral, sapendo che la linea è ancora in maturazione.

Questa mappa funziona per la maggior parte dei casi enterprise, ma le scelte vere si fanno sui dettagli: volumi di richiesta giornaliera, latenza accettabile, vincoli infrastrutturali esistenti, competenze MLOps disponibili, profilo di rischio del settore. Quello che funziona per una banca da mille dipendenti non funziona per una manifatturiera da trecento, anche se entrambe partono dal “vogliamo Mistral”.

È il tipo di scelta tecnica che mi capita di affiancare nei progetti di assessment AI aziendale: capire quale combinazione di modelli regge il caso d’uso reale, evitando di pagare la complessità di un Large 3 quando basta Medium 3.5, o di scoprire troppo tardi che il task richiedeva Magistral. Se stai facendo questa valutazione per la tua organizzazione, puoi scrivermi per discuterne.

Per la parte di come acquistare e quanto costa davvero, dall’API a La Plateforme fino al self-hosting on-premise con Forge, c’è la guida dedicata su API, self-hosting, Forge in azienda.

Leggi anche: LocalAI

AI & GENAI, TECH & BUSINESS

GDPR e LLM: quando un dato aziendale esce di casa

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

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

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

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

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

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

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

Il caso ChatGPT e cosa è successo davvero

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

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

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

Le quattro verticali italiane dove il problema è già operativo

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

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

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

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

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

La banca italiana che voleva sapere dove gira il modello

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

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

L’unica architettura che chiude il problema alla radice

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

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

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

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

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

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

AI & GENAI

Mistral AI nelle aziende italiane? Perché nel 2026 è diventata la scelta enterprise più seria d’Europa

Tre conversazioni recenti con CIO italiani sullo stesso identico tema. Una banca media del Nord, un gruppo manifatturiero del Veneto, un’azienda sanitaria privata di Roma. Domande diverse, problema sottostante identico: come spostare carichi AI dal cloud americano senza rallentare i progetti e senza far esplodere il budget infrastrutturale.

Ognuno per la sua ragione ovviamente: la banca per la piena applicazione dell’AI Act dal 2 agosto 2026 sui sistemi ad alto rischio, il gruppo manifatturiero perché i dati di produzione non possono finire in dataset di training di nessuno, l’azienda sanitaria perché il GDPR sui dati paziente in cloud extra-UE è diventato un mal di testa che non vale i risparmi.

In tutte e tre le conversazioni Mistral AI è arrivata sul tavolo con sollecitazioni differenti e suggestioni tecniche, e in due casi su tre è già la scelta tecnica in valutazione per il prossimo trimestre.

Mistral nel 2026 non è più interpretabile come “l’alternativa europea sperimentale“. È diventata piuttosto rapidamente la prima risposta seria che si dà a un CIO italiano quando i vincoli sono compliance e sostenibilità dei costi. Provo a spiegare perché, e quando invece non lo è (soprattutto poi sul tema sovranità ci torno in dettaglio).

Chi è Mistral AI

L’azienda è francese, sede a Parigi, fondata nel 2023 da ricercatori usciti da Meta e DeepMind. La distanza tra quel punto di partenza e dove sta oggi vale la pena guardarla con i numeri, perché definisce il tipo di vendor con cui si tratta.

ARR a 400 milioni di dollari a gennaio 2026, salito da circa 20 milioni un anno prima secondo il CEO Arthur Mensch. Valutazione 13,8 miliardi dopo il round chiuso a fine 2025 con Series C guidata da ASML. Quattro sedi globali oltre Parigi: Stati Uniti, Regno Unito, Singapore. E una traiettoria di prodotto che a marzo 2026 ha visto sei rilasci in quindici giorni, dalla famiglia Small 4 che unifica reasoning vision e coding fino a Forge per il training enterprise.

Sul fronte clienti il segnale italiano è arrivato a febbraio e marzo. Il 26 febbraio Accenture ha annunciato una partnership strategica pluriennale per scalare AI enterprise sicure in Europa, con Mauro Macchi, CEO Accenture EMEA, a confermare l’investimento. Il 18 marzo è arrivato l’accordo con Reply, focalizzato proprio su “soluzioni di intelligenza artificiale generativa locali, personalizzabili, sicure e pronte per l’utilizzo in contesti enterprise”, come dichiarato dal CTO Filippo Rizzante. Reply lavora con Mistral nel training e nella valutazione dei modelli per pubblica amministrazione, difesa, financial services e sanità, oltre a telco ed energia. I settori dove la conformità non è un’opzione e la sovranità del dato è un requisito di gara.

Quando un’azienda italiana media decide oggi di mettere Mistral nel proprio stack, non sta scommettendo su una startup. Sta acquistando da un vendor che ASML, Ericsson, ESA, due agenzie governative di Singapore, Accenture e Reply hanno già qualificato in scenari produttivi reali.

Apache 2.0 come scelta strategica non per ideologia

Il vero discriminante di Mistral non è la qualità del modello: su quel terreno la competizione con OpenAI, Anthropic e Google è una corsa serrata che cambia ogni tre mesi o forse meno. Il vero discriminante è la licenza con cui i modelli vengono distribuiti. Apache 2.0, permissiva, commerciale, senza clausole che escludano usi specifici. Mistral Large 3, Magistral Small, Devstral, Ministral: tutti rilasciati con licenza Apache 2.0 o equivalente.

Per un CIO questo significa tre cose pratiche.

La prima è l’assenza di lock-in del vendor. Se domani Mistral aumenta i prezzi API, cambia condizioni contrattuali, viene acquisita da un attore non gradito, viene esclusa da un programma di compliance europea, il modello continua a girare. I pesi del modello sono scaricabili, replicabili, ospitabili dove serve. Non esiste un equivalente in OpenAI, Anthropic o Google: nessuno dei tre rilascia i pesi dei propri modelli flagship. Quando si firma un contratto con loro si firma una dipendenza permanente dall’infrastruttura del fornitore.

La seconda è il self-hosting che funziona davvero. Non quello finto di “Azure OpenAI in region europea”, dove il dato si muove in un perimetro Microsoft ma il modello resta proprietà di OpenAI e la trasparenza sul training data resta zero. Con Mistral si può prendere Mistral Medium 3.5, metterlo su server bare metal in un data center italiano, e avere il controllo completo del flusso: i dati non escono mai dall’infrastruttura, i log restano interni, le richieste non transitano per servizi terzi. Per settori regolati la differenza è strutturale: permette di chiudere il progetto AI in conformità invece di doverlo riprogettare quando arriva l’audit.

La terza è la possibilità di auditare il modello per i requisiti dell’AI Act. Per i sistemi classificati ad alto rischio dall’articolo 6 del regolamento europeo, da agosto 2026 servono evidenze documentali su training data, processo di sviluppo, gestione dei bias, robustezza. Con un modello open-weight si può esaminare quello che effettivamente gira, fare valutazioni indipendenti, produrre la documentazione che chiede AgID. Con un modello chiuso si dipende dalla buona fede e dai certificati del vendor, che vanno bene fino a quando non vanno bene.

Apache 2.0 non è un argomento ideologico. È un’architettura di rischio enterprise.

Mistral contro la concorrenza

I benchmark MMLU-Pro e LMArena occupano metà delle slide nei pitch dei vendor AI, ma non sono il criterio giusto per scegliere quale modello mettere in produzione in un’azienda europea. Lo sono per il singolo task scientifico in laboratorio, non per la decisione di acquisto.

I criteri che muovono davvero la firma di un contratto enterprise in Italia sono cinque, e ho provato a mettere i quattro vendor principali su ognuno.

Sulla residency dei dati nel perimetro UE, Mistral vince netto: La Plateforme gira interamente in data center europei, e il self-hosting permette residency totale. OpenAI offre region europee ma con metadati che possono uscire, Claude di Anthropic non ha ancora residency europea garantita per tutti i tier, Google Gemini ha region UE ma resta soggetto a Cloud Act statunitense.

Sul self-hosting reale, solo Mistral lo offre con i modelli flagship. OpenAI, Anthropic e Google non lo permettono, possono offrirti al massimo deployment in cloud privato gestito da loro.

Sull’italiano nel training data come priorità di prodotto, Mistral parte avvantaggiata perché l’italiano è una lingua di confine della Francia, presente nelle fonti europee usate per il training fin dai primi modelli. OpenAI e Google hanno italiano buono ma derivato, Claude si difende. Il dettaglio si sente quando i casi d’uso sono terminologia legale e finanziaria, o linguaggio medico italiano: Mistral produce testi che un madrelingua riconosce come scritti in italiano, non tradotti.

Sul supporto enterprise europeo, Mistral ha staff in Europa con fusi compatibili, contratti redatti su norma europea, capacità di firmare DPA conformi al GDPR senza emendamenti acrobatici. Gli altri tre vendor possono offrirlo, ma è sempre una negoziazione caso per caso.

Sul presidio fisico in Europa, Mistral ha sede e team principale a Parigi, con presenza commerciale diretta nei principali mercati europei. Per un’azienda italiana questo si traduce in interlocutori reggiungibili, processi di escalation prevedibili, riunioni di servizio fattibili senza notti negli US.

Cinque criteri, Mistral vince su tutti, gli altri tre vendor perdono almeno su due ciascuno. Questo non significa che siano scelte sbagliate in assoluto, significa che se il caso d’uso è italiano e regolato Mistral parte da un vantaggio strutturale che gli altri devono recuperare a forza di concessioni contrattuali.

Quando Mistral non è la scelta giusta

Una guida che racconta solo i vantaggi di un vendor è un brochure di vendita, non un’analisi. Ci sono tre scenari in cui oggi consigliare Mistral è sbagliato, e vale la pena chiamarli con il loro nome.

Il primo è il reasoning scientifico al limite dello stato dell’arte. Se l’applicazione è ricerca farmaceutica avanzata, analisi giuridica multi-giurisdizione su corpus immensi, problemi matematici di livello olimpionico, oggi Claude Opus 4.7 e GPT-5 hanno ancora un margine sul reasoning più sofisticato che Magistral 1.2 sta accorciando ma non ha annullato. Per quei casi la differenza di qualità giustifica i costi e i compromessi sulla sovranità.

Il secondo è la startup early-stage con un team piccolo e zero ops engineering. Mistral via API è semplice, ma quando ha senso passare a self-hosting servono competenze di MLOps che una startup di sei persone non ha. In quei contesti il managed service di OpenAI risparmia mesi di lavoro, e i vincoli di sovranità sono meno stringenti perché il dato del cliente arriva dopo che il prodotto esiste. Mistral diventa la scelta giusta nel passaggio dalla fase early alla fase di scaling enterprise.

Il terzo è il prodotto consumer chat brand-aware. ChatGPT ha vinto la guerra del marchio sul mercato consumer, e per molti casi d’uso l’utente vuole proprio ChatGPT, non un assistente generico. Le Chat di Mistral è un ottimo prodotto, ma se l’obiettivo è uno chatbot brand-coherent per consumer italiani che valga come acquisition channel, l’ecosistema di OpenAI, le sue integrazioni e il suo nome restano un asset che Mistral non eguaglia.

Dire questo apertamente fa parte del lavoro di advisor. Quando un vendor vince sempre su tutto, in un’analisi seria, qualcosa non torna.

I tre scenari italiani dove Mistral è la risposta giusta

Mi è capitato negli ultimi mesi di affiancare aziende che hanno fatto questa scelta, e gli scenari ricorrenti sono tre. Sono quelli che ho davanti più spesso quando mi chiamano per un assessment AI, e probabilmente sono anche i tuoi.

La banca media italiana. Mille o duemila dipendenti, focus retail e PMI, sistemi core legacy ma con un’innovation unit che da due anni sperimenta AI. Il problema concreto è doppio: agosto 2026 porta l’AI Act sui sistemi ad alto rischio, che per le banche include credit scoring, prevenzione frodi, customer journey con decisioni automatiche, e contemporaneamente il rapporto sui costi cloud LLM cresce del 40% trimestre su trimestre.

La configurazione Mistral tipica è ibrida. Mistral Medium 3.5 in self-hosting su due nodi NVIDIA H200 per i carichi sensibili (customer support che tocca dati cliente, sistemi decisionali, generazione documenti contrattuali), Mistral Large 3 via La Plateforme per i carichi esplorativi dove la sovranità è meno critica. Investimento infrastruttura nell’ordine dei 400-500 mila euro una tantum più contratti di supporto, con un break-even sui costi API che si raggiunge tra il diciottesimo e il ventiquattresimo mese per un volume di richieste tipico di un istituto da mille dipendenti.

Il gruppo manifatturiero del Nord. Tre o quattro stabilimenti, ricavi nella fascia 200-500 milioni, prodotti su misura con brevetti propri e know-how di produzione che è il vero asset competitivo. Il problema è che i prompt che farebbero davvero la differenza, quelli che mettono in pari l’AI generativa con un ingegnere senior, contengono dati di produzione, specifiche tecniche riservate, parametri di processo. Caricarli su cloud americano significa metterli in dataset di training futuri, anche con le clausole “data privacy” più tirate, perché il rischio anche solo di esposizione fa già scattare i policy interni.

La configurazione Mistral tipica qui è on-premise pura. Mistral Small 4 o Medium 3.5 su un singolo server NVIDIA H100 in azienda, integrato con la documentazione tecnica via vector database, esposto agli ingegneri di processo come assistente di reparto. Investimento infrastruttura nell’ordine dei 150-200 mila euro, gestione delegata a un partner sistemistico locale, zero traffico esterno per i carichi core. ROI atteso non in risparmio diretto ma in compressione dei tempi di sviluppo prodotto e di problem-solving sulla linea, dove ogni giorno guadagnato vale ordini di grandezza superiori al costo dell’infrastruttura.

La sanità privata romana o milanese. Strutture da 200-500 dipendenti, mix di ambulatorio specialistico, diagnostica, ricovero breve. Il problema è la combinazione GDPR articolo 9 sui dati particolari più AI Act sui sistemi ad alto rischio in sanità, su cui le interpretazioni del Garante diventano più restrittive ogni sei mesi. Inviare dati paziente, anche pseudonimizzati, a un LLM cloud americano significa preparare la difesa legale prima del progetto.

La configurazione Mistral tipica qui è ibrida controllata. Mistral Medium 3.5 self-hosted per tutto quello che tocca dati paziente (refertazione assistita, prima lettura immagini diagnostiche, transcript di visite), Mistral Large 3 via API solo per carichi senza dati personali (knowledge base medica, formazione interna, comunicazione marketing). L’infrastruttura interna costa di più, intorno ai 300 mila euro per il setup iniziale, ma è la sola architettura che permette di sostenere un’ispezione del Garante senza dover dichiarare data breach preventivi.

In tutti e tre i casi, la scelta di Mistral non è ideologica, è strutturale. È quello che permette di fare il progetto AI in conformità con i vincoli esistenti, senza spostare il problema avanti di sei mesi nella speranza che le normative diventino più morbide.

Il percorso pragmatico di impianto

Per un’azienda che oggi sta valutando se Mistral è una scelta sensata, il percorso che funziona è di circa quattro settimane, e non richiede investimenti significativi prima di aver capito se l’opzione regge.

La prima settimana è di assessment dei carichi AI attuali. Mappa di tutte le sperimentazioni in corso, identificazione dei carichi che toccano dati sensibili, classificazione preliminare rispetto all’AI Act, stima del costo annualizzato delle API LLM attuali. Da questa mappa esce la lista dei carichi candidabili a Mistral, che spesso non è il 100% del totale ma una porzione mirata.

La seconda settimana è di prova pilota. Le Chat Pro Team a 24,99 euro al mese per utente per dare ai team interni un assistente che gira su infrastruttura europea, in parallelo qualche giorno-uomo di un developer sui modelli via La Plateforme per validare la qualità sui prompt aziendali reali. Costo totale della prova nell’ordine dei 1.500 euro, output un go/no-go tecnico su Mistral con dati propri, non sui benchmark di marketing.

La terza settimana è di design dell’architettura target. Decisione tra le tre opzioni principali: solo API La Plateforme (low setup, costi ricorrenti), ibrida API più self-hosting parziale (setup medio, ottimizzazione costi a 18 mesi), self-hosting completo (setup alto, sovranità massima). La scelta dipende dal mix dei carichi mappati al primo passo e dal profilo di rischio del settore.

La quarta settimana è di business case e decisione. Confronto a tre anni tra l’architettura proposta e lo status quo, considerando costi infrastrutturali, costi API, costi di gestione, valore della sovranità nel risk management, fattibilità di compliance AI Act. Da qui esce o non esce la decisione di buy.

Questo schema funziona per la maggior parte delle aziende italiane sopra i cento dipendenti. Sotto quella soglia, di solito la complessità organizzativa del self-hosting non si giustifica e Mistral resta interessante via Le Chat e API, senza la parte infrastrutturale.

Queste valutazioni non sono mai solo tecniche. La scelta giusta dipende da come è strutturato il data flow aziendale, dai vincoli regolamentari specifici del settore, dalle competenze interne disponibili, dai progetti AI già in corso. Ogni azienda ha la sua mappa dei rischi e dei vantaggi, e i parametri che ho indicato sono ordini di grandezza che vanno calibrati sul caso reale.

È esattamente il tipo di analisi che mi capita di fare quando un’azienda mi chiede di affiancarla nel ridisegno della propria architettura AI. Se stai facendo questo ragionamento per la tua organizzazione, puoi contattarmi qui per una prima conversazione.

Per chi vuole scendere nel dettaglio dei modelli specifici di Mistral e capire quale conviene per ciascun caso d’uso, ho dedicato un approfondimento su come scegliere tra i modelli Mistral nel 2026 dove confronto Large 3, Medium 3.5, Small 4, Magistral, Devstral e Ministral con i criteri tecnici e di costo. Per chi invece sta valutando le opzioni di acquisto, dall’API a La Plateforme fino al self-hosting on-premise con Forge, c’è la guida dedicata su API, self-hosting, Forge: cosa scegliere e quanto costa davvero.