Tag: AI governance

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

La gravità finanziaria di Eric Ries e l’AI che obbedisce alla struttura

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

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

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

Lo sgabello con una gamba sola

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

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

L’agente non storce il naso

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

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

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

Il leader invisibile, un secolo dopo

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

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

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

Una seconda gravità

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

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

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

La governance come atto creativo

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

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

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

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

AI & GENAI

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

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

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

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

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

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

Centinaia di scelte che nessuno ha approvato

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

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

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

Da strumento ad attore

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

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

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

Automatizzare un compito, commissionare una decisione

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

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

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

Il presidio non si improvvisa

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

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

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

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

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

AI & GENAI, TECH & BUSINESS

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

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

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

La trappola del prezzo a token

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

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

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

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

Il vero conto dell’on-premise

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

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

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

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

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

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

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

Tre scenari aziendali a confronto

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

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

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

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

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

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

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

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

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

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

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

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

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

Le voci che nessuno mette nel business case

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

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

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

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

Quando l’on-premise vince con margine

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

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

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

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

Lo strumento che amplifica il ROI dell’on-premise

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

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

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

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

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

AI & GENAI

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

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

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

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

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

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

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

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

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

La Plateforme: prezzi reali e cosa costa davvero

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

L’aggancio con LocalAI: come si fa nella pratica

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

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

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

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

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

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

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

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

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

Vibe CLI: l’agente di coding nel terminale

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

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

Compliance e governance: cosa chiedere al vendor

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

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

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

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

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

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

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

Leggi anche: costruire un'infrastruttura AI privata

AI & GENAI, TECH & BUSINESS

GDPR e LLM: quando un dato aziendale esce di casa

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

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

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

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

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

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

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

Il caso ChatGPT e cosa è successo davvero

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

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

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

Le quattro verticali italiane dove il problema è già operativo

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

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

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

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

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

La banca italiana che voleva sapere dove gira il modello

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

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

L’unica architettura che chiude il problema alla radice

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

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

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

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

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

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

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.

AI & GENAI

Magnifica Humanitas: Leone XIV e il bivio dell’IA

Al centro di Magnifica Humanitas, la prima enciclica di Leone XIV, ci sono due immagini bibliche contrapposte. Una è la torre di Babele, costruita per toccare il cielo e per farsi un nome, fatta crollare nella confusione delle lingue. L’altra sono le mura di Gerusalemme che Neemia ricostruisce dopo l’esilio, pezzo per pezzo, affidando a ciascuna famiglia un tratto. Babele come progetto di potere, uniformità, autosufficienza. Gerusalemme come opera lenta e distribuita, fondata su responsabilità condivisa.

Quando oggi ho letto questa coppia di immagini, nelle prime pagine di Magnifica Humanitas, mi sono accorto che la stessa polarità l’avevo descritta in modo diverso quando ho scritto il mio libro Pelle Digitale ormai qualche mese fa, ma con altri nomi.

Babele per me si chiama “megastruttura accidentale”, riprendendo Bratton. Gerusalemme l’ho chiamata “umanesimo aumentato”. Stesso concetto, lessico diverso, e la cosa mi ha stupito non poco: c’è poco da stare sereni e pensare che sia un caso se una visione tecnologica converge con una visione teologica e spirituale. È un segnale, probabilmente, che il tempo del dibattito puramente tecnico è finito o sicuramente ormai superato.

Cosa dice Magnifica Humanitas

Leone XIV non scrive contro la tecnica e a mio avviso nemmeno contro l’AI. La inserisce dentro un quadro di responsabilità che le tecnologie da sole non possono darsi. L’impalcatura di tutto il testo si regge su cinque punti.

Il primo è la denuncia del paradigma tecnocratico, già al centro di Laudato si’, qui aggiornato all’IA con un’accentuazione nuova. Al paragrafo 95 il Papa scrive che il controllo di piattaforme, dati e capacità di calcolo non appartiene più agli Stati ma a grandi attori economici e tecnologici “che, di fatto, fissano le condizioni di accesso”. Lo dice un Papa, ma potrebbe averlo scritto Shoshana Zuboff, sociologa ed economista americana, professoressa dell’Harvard Business School che è diventata un riferimento centrale del dibattito critico sul digitale per via di un libro del 2019, The Age of Surveillance Capitalism (in italiano Il capitalismo della sorveglianza, Luiss University Press), considerato uno dei testi più influenti dell’ultimo decennio su economia digitale e potere delle piattaforme.

Il secondo punto è un’antropologia del limite contro transumanesimo e postumanesimo. I sistemi di IA, scrive al paragrafo 99, “imitano alcune funzioni dell’intelligenza umana” ma non hanno esperienza né corpo, non hanno coscienza morale. Non capiscono ciò che producono. La distinzione fra imitare e capire diventa il fulcro di un’intera argomentazione che oppone la pienezza umana, fatta di limite e relazione, alla promessa di un potenziamento illimitato.

Il terzo punto è la fenomenologia delle nuove schiavitù digitali. Ghost worker che etichettano dati per pochi centesimi, adolescenti che lavorano nelle miniere di terre rare, reti criminali che usano profilazione e pagamenti anonimi per la tratta, neocolonialismo dei dati sanitari estratti dal Sud globale sotto l’etichetta della ricerca. Su tutto questo, ai paragrafi 173-178, c’è un passaggio in cui il Papa chiede sinceramente perdono a nome della Chiesa per il ritardo storico sulla condanna della schiavitù, e usa quel precedente come monito a queste nuove forme di schiavitù.

Il quarto punto salda epistemologia e democrazia. Senza ricerca condivisa della verità dei fatti, la vita democratica si svuota. Hannah Arendt viene citata direttamente: il suddito ideale dei totalitarismi è chi non distingue più fra fatto e finzione. La disinformazione non nasce con l’IA, ma trova in questa un moltiplicatore.

Il quinto punto è il disarmo dell’IA. Rifiuto delle armi autonome letali, critica all’idea che il giudizio morale possa essere ridotto a calcolo, controllo umano effettivo come condizione non negoziabile. Qui dentro c’è il paragrafo 107, uno dei più affilati, complessi e delicati del testo, che secondo me dovrebbe leggerlo chiunque sviluppa modelli: non basta moralizzare la macchina, allinearla a valori umani, se non si discute chi decide quei valori. La domanda dell’alignment, scrive Leone XIV, non è un tema tecnico ma politico.

Sette nodi dove mi ritrovo in quello che scrivo spesso

Il primo nodo è il paradigma tecnocratico. In Pelle Digitale apro descrivendo Apple, Google e Amazon come “signori della gabbia dorata”, architetti di ecosistemi che catturano l’esperienza e la monetizzano. L’enciclica al paragrafo 95 arriva alla stessa diagnosi da un lessico apparentemente opposto. Io descrivo un meccanismo, fatto di estrazione di dati, monetizzazione, lock-in degli utenti. Il Papa nomina un peccato: idolatria del profitto, dominio sull’altro, pretesa di autosufficienza. Linguaggi differenti che vengono da tradizioni che da secoli non si parlano, e che improvvisamente convergono sulla stessa fotografia: pochi attori privati che decidono per tutti, con strumenti opachi e responsabilità diluite.

Poi c’è l’ambiente. Io lo chiamo “pelle digitale” e “sistema nervoso invisibile” e intendo lo strato che avvolge persone, oggetti e città. Leone XIV al paragrafo 76 parla esplicitamente di “ecosistema digitale” che, come l’ambiente naturale, può essere custodito o sfruttato, condiviso o monopolizzato. La metafora ambientale, applicata al digitale, è uguale.

Il terzo nodo è l’opacità algoritmica. Nel capitolo 7 del libro io racconto i bias, facendo degli esempi in particolare cito COMPAS sulla recidiva e il caso del recruiting di Amazon, e arrivo a parlare di “teocrazia digitale” per descrivere algoritmi-divinità che decidono senza dover dare spiegazioni. L’enciclica, ai paragrafi 102-107, costruisce la stessa argomentazione con parole più “sobrie”: black box, accountability, catena di responsabilità non delegabile alla macchina. Il Papa non usa “teocrazia”. Ma il problema che descrive è esattamente quello a mio avviso.

Quarto nodo: i ghost worker. Nel libro dedico una pagina alla materia che si nasconde dietro l’immaterialità apparente del cloud e al lavoro umano che c’è dietro. Una catena globale di corpi e luoghi che regge la leggerezza apparente di una risposta generata in due secondi. Il paragrafo 173 di Magnifica Humanitas entra in questa anatomia con una forza che pochi documenti pubblici hanno. Leone XIV scrive che ogni risposta dell’IA proviene da “una lunga catena di mediazioni” che include risorse naturali, infrastrutture energetiche e persone. Nomina la fatica invisibile di chi etichetta dati e modera contenuti per compensi minimi, “spesso giovani donne”. Aggiunge l’estrazione delle terre rare, dove “adolescenti e bambini lavorano in condizioni pericolose”. E chiude con la frase che spacca la sezione: “corpi segnati, mutilati, consumati perché il flusso del calcolo non si interrompa”.

Quando un Papa nomina i corpi mutilati dentro un’enciclica sull’intelligenza artificiale, sta facendo un’operazione che nessun rapporto o paper accademico può fare: mette la materia umana al centro morale del dibattito, e non ai suoi margini. La conseguenza al paragrafo 174 è esplicita e a mio avviso centrale: una tecnologia che promette emancipazione ma produce nuove forme di subordinazione globale contraddice il principio fondamentale della dignità della persona.

C’è poi tutto il tema della mente estesa, attenzione catturata, forme di dipendenza che ne derivano. Nel capitolo 4 io ho scritto della cognizione distribuita di Andy Clark, e nel capitolo 6 sull’economia dell’attenzione progettata per catturarci. L’enciclica ai paragrafi 100 e 170 parla di “delega” cognitiva e di modelli imprenditoriali che “prosperano sulla debolezza umana”. Qui c’è uno scarto interpretativo che vale la pena tenere aperto: Clark vede nell’estensione un guadagno, il Papa la legge come rischio. E a mio avviso tutte e due sono vere.

Sesto, c’è il tema dello human-in-the-loop, che ho dichiarato pilastro del capitolo finale del libro. L’enciclica, parlando di IA militare al paragrafo 200, usa la stessa nozione con parole quasi sovrapponibili: la forza letale non può essere delegata a processi automatizzati, deve restare sotto “un controllo umano effettivo, consapevole e responsabile”.

Settimo, il più delicato a mio avviso. L’alignment come questione politica. Nel libro parlo di ethics by design e cito Stuart Russell sull’allineamento ai valori umani. Il Papa al paragrafo 107 fa un passo che la letteratura tecnica raramente fa: chiede chi decide quei valori. Se l’allineamento è una scelta morale, è una scelta che non può essere appannaggio di pochi laboratori. È un punto della discussione che sposta tutta la conversazione sull’IA dall’ingegneria alla politica, e lo fa con una precisione che dovrebbe far riflettere chi lavora su questi temi.

Dove Magnifica Humanitas va ben oltre le riflessioni comuni

Il primo punto è la questione delle armi autonome. Io ne parlo in modo leggero nel capitolo sull’agency degli agenti, ma non la centro. Leone XIV le mette al cuore di un intero capitolo, riconosce che la riabilitazione contemporanea della guerra come strumento di politica internazionale è uno dei segni più gravi del tempo, e collega il riarmo all’IA in modo che dieci anni fa sarebbe stato impensabile. Ha ragione e condivido pienamente, gli scenari ibridi e gli attacchi cyber stanno cambiando la grammatica dei conflitti, e non si può parlare di etica dell’IA senza arrivare a parlare di questo.

Il secondo è il neocolonialismo dei dati sanitari. Nel libro descrivo l’asimmetria della medicina basata su dati, ma resto sul piano dell’individuo. L’enciclica al paragrafo 178 lo allarga ai popoli: chi possiede oggi i dati sanitari di intere popolazioni, raccolti sotto il segno della ricerca, “possiede in realtà una leva strutturale sul futuro”. È una lettura geopolitica dell’estrazione dei dati che a gennaio, quando ho pubblicato il libro, per quanto ne fossi consapevole non ho pensato di affrontare.

Il terzo, e forse il più importante, è la memoria storica. Il Papa usa il ritardo con cui la Chiesa ha condannato la schiavitù come monito sul presente: se non vogliamo chiedere perdono in futuro per non aver visto le nuove asimmetrie di oggi, dobbiamo nominarle adesso. È una valutazione che solo un’istituzione con quel tempo lungo può fare. La riflessione laica contemporanea, la mia compresa, ha una memoria corta. Senza memoria lunga, certe asimmetrie restano fuori dal campo visivo.

E poi c’è il nodo del lavoro

C’è un punto su cui Leone XIV passa, e su cui non ho una posizione netta. È il capitolo sul lavoro, paragrafi 148-169, praticamente la parte più operativa di tutta l’enciclica a mio avviso e quella che parla più direttamente al mondo dell’impresa e della trasformazione digitale.

Il Papa cita san Benedetto e l’ora et labora, parla del lavoro come cammino di maturità e realizzazione. Al paragrafo 148 “lavoro” significa opera e contributo, fatica che ha senso, attività con cui prolunghiamo in qualche modo l’opera del Creatore. Ma già al paragrafo 149 la parola scivola sull’occupazione retribuita che produce sostentamento.

Un’ambiguità antica, che la Dottrina Sociale trascina dalla Rerum Novarum del 1891 in poi, e che oggi pesa, perché tiene insieme due cose che dovremo scindere con intelligenza.

Lo scenario che mi interessa, e che discuto da tempo con un amico parroco con cui non sono d’accordo, è quello in cui l’automazione derivante da AI e Robot libera davvero l’umanità dalla necessità di lavorare per sussistere. È uno scenario plausibile, forse il più radicale (e ottimista per certi versi). In quel mondo un reddito universale di base diventa obbligo strutturale prima ancora che scelta politica: senza, l’IA produce solo concentrazione di ricchezza e povertà di massa. E se la base materiale è garantita, si apre uno spazio per un altro tipo di lavoro, fondato su contributo e non su scambio. Il lavoro dei monaci copisti che hanno salvato la civiltà occidentale tra il VI e il XII secolo. Il lavoro delle madri che crescono i figli. Il lavoro dei volontari che reggono le associazioni, dei contributori di codice open source, dei ricercatori che pubblicano senza ricavarne nulla. Nessuna di queste attività è retribuita. Tutte sono lavoro nel senso pieno benedettino del termine.

Il mio amico Don Michele la pensa diversamente. Non esiste dignità senza lavoro, mi ripete ogni volta che ne parliamo, e lo dice con una fermezza esperienziale prima che ideologica. Vede ogni giorno cosa succede alle persone che il lavoro lo perdono o non lo trovano. Vede come si perde il senso di sé. Per lui il lavoro è un dato antropologico, non un dettaglio economico: è la forma stessa attraverso cui l’essere umano matura e si riconosce. Ed è qui che la sua tradizione e la mia visione del futuro si incontrano in modo costruttivo, perché ha ragione anche lui, su un pezzo del problema che spesso chi ragiona di reddito universale rimuove.

L’essere umano matura attraverso il fare che ha conseguenze. Senza un’opera che lo metta in rapporto con la realtà, con i limiti dei materiali, con il giudizio degli altri, con la propria fatica, la dignità diventa un’astrazione interiore che non regge. La tradizione cristiana lo sa da Genesi in poi, l’uomo è collaboratore della creazione e non spettatore. E sociologicamente succede esattamente quello che il mio amico vede sul campo: nelle comunità dove l’occupazione collassa senza essere sostituita da altre forme di contributo riconosciuto, le persone non fioriscono, si rovinano, entrano in forme diverse di collisione sociale. Le ricerche sulle zone deindustrializzate americane, sui quartieri operai italiani dopo le chiusure delle fabbriche, lo confermano. Se le persone non si sentono utili, tutto collassa.

Magnifica Humanitas apre un varco proprio su questo nodo. Al paragrafo 154 Leone XIV scrive che una società che garantisse occupazione solo a una minoranza esporrebbe molti a “inattività forzata, assenza di responsabilità, mancanza di impegni e stimoli quotidiani, con esiti di impoverimento umano e culturale in contrasto con l’elevato livello di sviluppo tecnico”. Lo chiama “paradosso di progresso materiale e regressione antropologica”. E conclude che è necessario “ripensare il lavoro stesso e il suo rapporto con la cittadinanza, perché l’assenza di occupazione non pregiudichi la partecipazione sociale”. Il Papa non sta dicendo che senza occupazione retribuita non c’è dignità. Sta dicendo che la nozione novecentesca di lavoro, quella che lega stipendio e dignità in un nodo unico, sta diventando inadeguata e va sciolta con cura.

Il “lavoro” come lo intendiamo oggi, un’attività salariata separata dalla vita domestica, misurata in ore, scambiata sul mercato del lavoro, è un’invenzione industriale di duecento anni.

Prima c’erano contadini e artigiani, monaci e madri di famiglia, scribi e copisti. Tutte figure che producevano valore senza essere “occupate” nel senso novecentesco. Hannah Arendt nella Condizione umana distingue tre cose. Labor, la fatica per sopravvivere. Work, la creazione di opere durevoli. Action, l’azione che lascia traccia nel mondo umano. Solo il primo è lavoro nel senso economico stretto. Gli altri due sono ciò che intendo quando parlo di un lavoro non remunerato fatto di passione e contributo.

Da Arendt in poi sappiamo che la dignità del lavoro stipendiato novecentesco era un fascio di tre cose tenute insieme. Un fare che incontra resistenza reale: i materiali e il tempo, la fatica, il giudizio degli altri. Senza questo l’identità si squaglia. Un riconoscimento sociale del valore di quel fare. Senza questo l’attività diventa hobby privato e non sostiene la dignità pubblica. Una base materiale di sussistenza che permetta di farlo senza disperazione. Senza questa, ogni discorso su “passione e ambizione” è privilegio per ricchi. Il salario industriale offriva i tre insieme, e questo ne ha fatto il modello dominante per due secoli. L’errore di chi parla solo di reddito universale, il mio compreso quando alleggerisco troppo il discorso, è pensare che la sola base materiale basti. L’errore opposto, di chi difende una visione ottocentesca del lavoro, è pensare che solo il lavoro retribuito possa fornire le altre due.

C’è poi un nodo geografico che l’enciclica nomina al paragrafo 153 e che vale la pena ripetere. La transizione non procederà in modo omogeneo. Le società ricche si automatizzano caoticamente e producono disoccupazione. Vaste regioni del Sud globale restano intrappolate in quelle che Leone XIV chiama “economie ibride” dove lavoro umano sottopagato e tecnologie parziali convivono senza mai trasformarsi davvero. Diventano serbatoi di manodopera precaria e focolai di migrazioni forzate. Il discorso sul futuro del lavoro va sempre tenuto a due velocità, perché chi parla di reddito universale spesso parla da Paesi ricchi e dimentica che intere economie del pianeta non hanno mai conosciuto il salario industriale come modello.

Siamo all’inizio di una transizione in cui dobbiamo inventare istituzioni che riconoscano come lavoro il fare non retribuito. Se non lo facciamo, la sostituzione algoritmica del lavoro stipendiato sarà una catastrofe antropologica, e su questo l’enciclica ha ragione a essere allarmata. Se lo facciamo, può essere lo spostamento di senso del lavoro più grande dai tempi della riforma benedettina. La domanda concreta, quella che resta aperta, è questa: quali istituzioni possono oggi riconoscere come dignità il lavoro non remunerato? La parrocchia ne è una storica. L’associazione di volontariato un’altra. La famiglia estesa un’altra ancora. Sono tutte istituzioni in crisi, ognuna per ragioni sue. Servono forme nuove, e quelle vecchie vanno rigenerate. Su questo l’enciclica è ambigua secondo me, e credo che il prossimo passo della Dottrina Sociale dovrà essere più esplicito di quanto Leone XIV osi oggi in questa enciclica.

Cosa cambia, se cambia qualcosa

Chi sviluppa e finanzia IA, chi la regola, non può più dichiararsi “tecnico” come schermo. Il paragrafo 209 dell’enciclica chiama in causa scienziati e imprenditori, investitori e autorità accademiche, politici. Quando ci si limita a guardare al proprio settore, scrive Leone XIV, ci si illude di svolgere un compito moralmente neutro. Mi ci ritrovo perfettamente, perché è la stessa argomentazione che faccio nel manifesto finale del libro: il fallimento etico è un fallimento progettuale.

La responsabilità progettuale, che chiamo ethics by design, l’enciclica la riformula come responsabilità condivisa fra istituzioni capaci di regolare, imprese che riconoscono nel lavoro e nella dignità un criterio di successo, corpi intermedi che ricostruiscono fiducia.

C’è un altro elemento operativo che vale la pena segnalare, perché passa sottotraccia ma c’è e non è sottovalutabile. Magnifica Humanitas al paragrafo 159 chiede esplicitamente di superare il Prodotto Interno Lordo come metrica unica dello sviluppo. Servono, scrive Leone XIV, parametri complementari capaci di misurare dignità del lavoro, prosperità condivisa, riduzione delle disuguaglianze, salvaguardia ambientale. Per chi lavora in impresa e si confronta ogni trimestre con KPI finanziari, è un invito a chiedersi quali metriche stiamo davvero usando per misurare il successo dei progetti tecnologici che lanciamo.

Lo stesso vale per il paragrafo 163, dove il Papa elenca quattro criteri operativi che diventano una check-list utile per chi progetta sistemi di IA che incidono su persone. Trasparenza e responsabilità nelle decisioni algoritmiche che riguardano accesso al credito e al lavoro, ai servizi essenziali. Inclusione e accesso ai benefici dell’innovazione, perché la tecnologia non allarghi il divario fra chi ha e chi non ha. Misure di equità che correggano gli squilibri creati dalla concentrazione di ricchezza e potere. Cooperazione internazionale, perché molte decisioni economiche superano i confini degli Stati. Sono cose verificabili, più che principi generici. E sono il vero terreno comune fra una riflessione laica sulla tecnologia e la Dottrina Sociale aggiornata.

Nessuno di noi che lavora su queste materie ha gli strumenti per agire da solo. La convergenza fra tradizioni distanti, su questo, è un dono che vale la pena prendere sul serio.

Neemia ricostruì le mura di Gerusalemme con famiglie diverse, ognuna su un tratto. Nessuna ricostruì l’intera cinta da sola. A chi progetta tecnologia oggi tocca il tratto in cui passa la decisione su cosa deleghiamo, cosa controlliamo, cosa restiamo capaci di giudicare. Il prossimo noi, come scrivevo a chiusura del manifesto di Pelle Digitale, inizia da lì.

Lettera Enciclica Magnifica Humanitas di Papa Leone XIV, 15 maggio 2026.

Leggi anche: cosa mi muove oltre la tecnologia