Il 14 agosto il laboratorio cinese Z.ai ha annunciato GLM-5.3 e, insieme al modello, una cosa che vale la pena guardare più del modello. Nelle note di rilascio l’azienda dichiara un salto nelle capacità di sicurezza offensiva che non aveva pianificato: più potenza di calcolo spesa nella rifinitura che segue l’addestramento di base, quella dedicata al codice e agli agenti, avrebbe prodotto come effetto collaterale un miglioramento marcato nella scoperta di vulnerabilità e nel ragionamento sugli exploit. I numeri dichiarati sono l’84,5% su CyberGym, dove il modello riceve sorgenti in chiaro e deve individuare e validare una vulnerabilità facendola scattare, e un ExploitBench, che misura invece quanto il modello riesce a trasformare una vulnerabilità in un attacco funzionante, passato dal 24,4% al 54,4%. Lavorando con squadre di sicurezza cinesi, sostiene l’azienda, i suoi modelli hanno individuato 2.436 vulnerabilità in 269 progetti open source, di cui 1.097 critiche o ad alta gravità, la più vecchia introdotta nel 1981. Una l’ha trovata in Cursor, ed è stata comunicata in privato.
Sono affermazioni del produttore, e come tali vanno prese: nessuno le ha ancora riprodotte in modo indipendente. Ma accanto ai numeri c’è un fatto che non dipende dai benchmark, ed è la forma del rilascio. Le funzioni offensive più sensibili restano dietro un programma di accesso verificato. E i pesi non escono con l’annuncio. I pesi sono i miliardi di numeri in cui finisce tutto quello che il modello ha imparato durante l’addestramento: chi li scarica non ottiene il permesso di interrogare il modello a distanza, ottiene il modello, e può eseguirlo sulle proprie macchine senza chiedere niente a nessuno. Escono, dice l’azienda, circa due settimane dopo l’annuncio, al termine di una valutazione di sicurezza. Le vulnerabilità trovate finiscono in un registro pubblico in cui, al momento dell’annuncio, 53 erano divulgate e 2.383 ancora sotto embargo, con la possibilità di pubblicare l’hash crittografico di una scoperta ancora in disclosure coordinata, così che la si possa verificare dopo senza rivelarne subito i dettagli operativi.
Qualunque cosa si pensi di Z.ai, e qualunque cosa risulti dai benchmark quando qualcuno li riprodurrà, questo è il primo rilascio open-weight di rilievo in cui l’apertura non è un interruttore ma un calendario. È il momento buono per ammettere che la parola con cui discutiamo di tutto questo ha smesso di funzionare.
L’intuizione che ha retto trent’anni
Conviene enunciare l’argomento a favore dell’apertura nella sua forma più forte, non nella sua caricatura, perché è quello contro cui bisogna faticare.
Per trent’anni abbiamo associato l’open source a un’intuizione che è morale prima ancora che tecnica. Se il codice è ispezionabile, modificabile, replicabile e redistribuibile, il potere si sposta dal produttore alla comunità. L’utente può verificare cosa esegue, l’impresa può sottrarsi al lock-in, lo Stato può ridurre dipendenze strategiche, il ricercatore può controllare le affermazioni del vendor invece di crederci. In Europa questa idea è entrata nel lessico ufficiale della sovranità digitale: il 3 giugno 2026, dentro il pacchetto sulla sovranità tecnologica, la Commissione ha presentato per la prima volta una strategia open source autonoma, che tratta il software aperto non come un’opzione di acquisto o una voce di risparmio ma come infrastruttura digitale europea, con linee guida sugli appalti per gli standard aperti, sostegno agli uffici di programma open source delle amministrazioni e priorità su semiconduttori, sistemi operativi, cloud, intelligenza artificiale e cybersicurezza.
Da qui nasce l’obiezione a qualunque restrizione sui modelli open-weight, ed è un’obiezione seria. Se accettiamo che i modelli più capaci restino chiusi perché potenzialmente pericolosi, consegniamo una quantità enorme di potere cognitivo a poche aziende statunitensi e forse cinesi. Quelle aziende decideranno chi accede alle capacità, con quali filtri, a quale prezzo, da quali Paesi, per quali finalità. Potranno cambiare unilateralmente i termini di servizio, ritirare un modello su cui qualcuno ha costruito un prodotto, restringere le applicazioni ammesse, osservare gli utilizzi dei clienti. Per un’impresa europea questo significa dipendenza economica. Per una pubblica amministrazione può significare dipendenza strategica. Per la ricerca significa l’impossibilità di verificare fino in fondo il sistema che si sta studiando, il che equivale a chiedere alla comunità scientifica di lavorare su oggetti che non le è permesso aprire.
In cybersecurity l’obiezione diventa ancora più convincente. Le stesse capacità che permettono a un attaccante di scoprire una vulnerabilità consentono a un difensore di trovarla prima, di generare test, di analizzare codice legacy che nessuno mantiene da dieci anni, di cercare catene di exploit nella propria infrastruttura, di interpretare log e di automatizzare la remediation. Limitare gli strumenti offensivi significa inevitabilmente limitare almeno una parte delle capacità difensive, e chi si difende è quasi sempre quello che ha meno budget. Non a caso il NIST, nella guida AI 800-1 sulla gestione del rischio di abuso dei modelli dual-use, tratta queste tecnologie esattamente per quello che sono, tecnologie a duplice uso, e non come armi per definizione: il problema è gestire il rischio lungo l’intero ciclo di vita, dalla valutazione pre-sviluppo al monitoraggio post-rilascio, non presumere che la capacità in sé sia illegittima.
C’è poi l’argomento più difficile da liquidare, ed è geopolitico. Una politica occidentale molto restrittiva sugli open weights potrebbe non ridurre affatto la proliferazione globale. Potrebbe semplicemente garantire che i modelli aperti più capaci vengano prodotti altrove, sotto altre regole, con altri criteri di rilascio. GLM-5.3 rende questa ipotesi meno teorica di quanto fosse sei mesi fa.
Quindi la tesi non può essere «i modelli offensivi devono essere chiusi». Sarebbe troppo semplice, probabilmente inefficace, e soprattutto tradirebbe alcune delle ragioni migliori per cui l’open source conta.
Che cosa distribuiamo, quando distribuiamo i pesi
Il problema comincia quando ci si accorge che stiamo trasferendo senza correzioni il vocabolario politico dell’open source software a un oggetto tecnologico di natura diversa.
Un server web open source e un modello open-weight condividono una proprietà, ed è quella che ci ha convinti a usare la stessa parola: posso acquisirne una copia e usarla indipendentemente dal produttore. Ma ciò che viene distribuito non è la stessa cosa.
Nel software tradizionale viene distribuito principalmente un insieme di istruzioni. Per ottenere una capacità nuova e significativa devo comprenderle, modificarle, oppure aggiungerne altre. Il codice di nginx non contiene implicitamente migliaia di programmi offensivi che emergono se glieli chiedo. La sua apertura rende disponibile ciò che è scritto nel repository, e nient’altro: non un repertorio implicito di comportamenti che il produttore stesso può conoscere soltanto per via empirica, misurandolo.
Un foundation model, uno di quei modelli generalisti su cui poi si costruisce tutto il resto, è un altro oggetto. I pesi sono una forma compressa di capacità appresa. Non sto aprendo soltanto il meccanismo con cui il sistema funziona: sto distribuendo qualcosa che può generare procedure mai scritte esplicitamente in nessun sorgente, e che possono essere combinate con strumenti esterni: cicli agentici, in cui il modello decide una mossa, la esegue, ne legge il risultato e ricomincia da solo, e poi shell, browser, compilatori, scanner. Il salto non pianificato dichiarato da Z.ai è la dimostrazione più economica di questa asimmetria: nessuno ha scritto la capacità di concatenare exploit, è comparsa mentre si ottimizzava dell’altro, e l’azienda dice di averla scoperta valutando il proprio modello. Se il produttore stesso scopre le capacità del suo oggetto per via sperimentale, la parola «trasparenza» significa una cosa molto diversa da quella che significava per un pacchetto di sorgenti.
Questa differenza sembra tecnica. Cambia invece l’intera filosofia dell’apertura.
Tre diritti che abbiamo trattato come uno solo
Nel software classico il diritto di ispezionare e il diritto di copiare sono quasi inseparabili, e non per scelta ideologica ma per necessità materiale. Se voglio permetterti di verificare davvero il programma, devo consentirti di acquisirlo. E una volta che lo possiedi, impedirti di copiarlo è insieme tecnicamente difficile e politicamente contraddittorio. Le quattro libertà di Stallman stanno in piedi anche perché nel loro mondo non c’era modo di separarle.
Con i modelli possiamo invece distinguere almeno tre diritti diversi: il diritto di conoscere come il modello è stato costruito, il diritto di valutarne indipendentemente le capacità, il diritto di possedere una copia illimitatamente modificabile dei pesi. Li abbiamo trattati finora come se fossero la stessa forma di libertà. Non lo sono necessariamente, e il primo laboratorio che ha spedito i tre in momenti diversi lo ha fatto il 14 agosto.
Qui sta la frattura concettuale: il diritto all’ispezionabilità non implica automaticamente il diritto alla proliferazione illimitata di ogni capacità.
È una frase pericolosa, perché chiunque venda sistemi proprietari opachi può usarla domani mattina per giustificarli. Per questo va delimitata con precisione. Non significa «la sicurezza viene prima della libertà», formula che storicamente ha autorizzato qualsiasi abuso e che qui non c’entra. Significa che forse abbiamo bisogno di inventare per l’AI una grammatica dell’apertura più articolata di quella nata per il software degli anni Ottanta, e che continuare a comprimere otto decisioni distinte dentro una parola sola non è fedeltà a un’idea: è pigrizia.
Conoscenza e capacità non sono la stessa cosa
Il criterio con cui distinguere non può essere «questo modello è potente». Sarebbe arbitrario, e in pratica coinciderebbe con «questo modello è recente». Dovrebbe essere un altro: questa capacità modifica sostanzialmente il costo marginale necessario per produrre un determinato danno?
Cyber offre un caso quasi ideale, perché permette di ragionare in termini concreti invece che in termini di catastrofi immaginate.
Un modello che spiega come funziona una SQL injection non sposta l’equilibrio offensivo di un millimetro: internet contiene già milioni di spiegazioni, molte migliori. Un modello che genera un exploit noto non cambia granché: Metasploit esiste da decenni ed è a un apt install di distanza. La soglia interessante arriva quando un sistema può ricevere una base di codice sconosciuta, individuare autonomamente una vulnerabilità non documentata, sviluppare un exploit affidabile, concatenarlo con un’escalation di privilegi, aggirare le mitigazioni, e rifarlo su bersagli diversi con costi vicini a zero. A quel punto non abbiamo democratizzato una conoscenza. Abbiamo industrializzato una capacità.
Questa distinzione è il cuore della faccenda, ed è più vecchia dell’informatica. Una ricetta per produrre una sostanza pericolosa è informazione. Una macchina automatica che la produce su scala industriale è capacità. Il diritto di accedere alla prima, che difendo, non risolve automaticamente la questione politica della seconda. Gli LLM confondono proprio questo confine, perché trasformano informazione in capacità esecutiva: quando vengono collegati agli strumenti, la distanza fra «sapere come si fa» e «farlo» si riduce fino quasi a sparire, e l’unità di misura del danno smette di essere la competenza dell’attaccante e diventa il numero di ore-macchina che può permettersi.
Ed è qui che l’argomento open source tradizionale incontra un limite storico, non morale. Il movimento nasce in una cultura in cui il costo dominante era l’accesso alla conoscenza e agli strumenti, e in cui abbassare quel costo era quasi sempre emancipatorio: chi non poteva leggere il codice era escluso, e basta. Con l’AI di frontiera abbassiamo simultaneamente il costo della conoscenza e il costo dell’azione. Non è la stessa operazione. L’open source nasce per distribuire il potere di comprendere e modificare le macchine; l’AI open-weight può arrivare a distribuire anche il potere di agire attraverso di esse. Quando le due cose coincidono, la politica dell’apertura si trova davanti a responsabilità che il software libero poteva permettersi di considerare periferiche.
L’irreversibilità, e chi ha interesse a ricordarcela
Il 27 luglio 2026 Anthropic ha pubblicato una posizione a firma di Dario Amodei che comincia con una smentita: l’azienda non ha mai chiesto di vietare i modelli open-weight. Arrivava tre giorni dopo una lettera intitolata Open Weights and American AI Leadership, firmata da 77 fra aziende, fondazioni, fondi e gruppi di ricerca, che difendeva gli open weights e alludeva con chiarezza a chi li starebbe minacciando. La proposta di Anthropic è di tenere accessibili i modelli aperti a rischio più basso e di concentrare i vincoli altrove: controlli sui chip verso i regimi autoritari, freno alla distillazione su scala industriale, cioè al travaso sistematico delle capacità di un modello chiuso dentro uno aperto, test di sicurezza obbligatori per tutti i modelli sufficientemente capaci, aperti e chiusi.
L’argomento centrale è l’irreversibilità. Una volta pubblicati i pesi, i safeguard, cioè le protezioni addestrate nel modello perché rifiuti le richieste pericolose, possono essere rimossi, le copie possono essere ridistribuite o eseguite in privato fuori da qualsiasi monitoraggio, e non esiste alcun intervento successivo possibile sul modello. È un’affermazione interessata, perché viene da un’azienda che vende accesso proprietario ai propri modelli, e va presa nella sua versione più forte e sospettata nello stesso momento.
Prendiamola nella versione più forte, quella con i numeri. Rimuovere il fine-tuning di sicurezza, cioè l’addestramento aggiuntivo che insegna al modello a dire di no, da Llama 3 8B richiede circa cinque minuti su una singola scheda grafica A100, per meno di mezzo dollaro presso quasi qualunque provider cloud, e circa 45 minuti sul modello da 70 miliardi di parametri, per meno di due dollari e mezzo; la stessa procedura gira in mezz’ora e a costo zero su un notebook gratuito di Google Colab. Con LoRA, una tecnica di riaddestramento leggero, e meno di 200 dollari, il tasso di rifiuto di Llama 2-Chat 70B è passato dal 78,9% allo 0,4%, cioè da 618 rifiuti su 783 domande a 3. E la curva conta più dei singoli valori: le ore GPU necessarie a smontare l’addestramento di sicurezza sono passate da centinaia nel 2022 a decine nel 2023 a minuti nel 2024. Chi pubblica i pesi non pubblica il modello con i suoi controlli. Pubblica il modello, e i controlli restano indietro come un’intenzione.
Sospettiamola, adesso. Che il rischio sia reale non rende meno reale l’incentivo economico a presentarlo come argomento a favore dell’API centralizzata, e la stessa azienda che chiede test obbligatori per tutti è quella che venderebbe più accessi ai propri modelli se i concorrenti aperti sparissero. Entrambe le cose sono vere insieme. È esattamente per questo che l’alternativa «Meta ha ragione, Anthropic ha torto» o viceversa è sterile: sono due posizioni di mercato travestite da filosofie, e discuterne come se fossero filosofie ci fa perdere l’unica domanda che serve.
La domanda che serve
Quali proprietà vogliamo preservare, dell’open source?
Se la risposta è «la possibilità di far girare qualsiasi cosa senza alcuna interferenza esterna», allora i pesi completamente aperti sono insostituibili e non c’è altro da dire.
Se la risposta è sovranità, la faccenda si complica, perché sovranità non significa possedere tutto senza restrizioni. Significa non dipendere dalla volontà arbitraria di un altro soggetto, che è una cosa diversa. Un modello accessibile solo attraverso un’unica API americana è una dipendenza evidente. Ma un ecosistema europeo che scarica i pesi di un modello straniero e si ferma lì non è pienamente sovrano: senza potenza di calcolo, competenze, dataset, capacità di riaddestramento, di valutazione e di manutenzione, ha soltanto cambiato il soggetto da cui dipende, e per giunta ne ha scelto uno che non ha alcun obbligo verso di lui. L’open weight è una componente della sovranità, non la sovranità. È la stessa cosa che ho scritto a giugno a proposito del cloud: la sovranità non abita nel data center, e non abita nemmeno in una cartella di parametri sul disco.
L’Europa lo ha già scritto due volte
C’è un dettaglio che il dibattito europeo tende a saltare, e riguarda il fatto che l’Europa questa distinzione l’ha già messa per iscritto, in due leggi diverse, senza quasi accorgersene.
La prima volta è nell’AI Act. L’articolo 53 esonera i fornitori di modelli GPAI, i modelli per finalità generali, rilasciati con licenza libera e aperta da una parte degli obblighi: la documentazione tecnica, quella destinata ai fornitori a valle, la nomina del rappresentante autorizzato per chi è stabilito fuori dall’Unione. Non li esonera dalla politica di rispetto del diritto d’autore né dal riepilogo sufficientemente dettagliato dei dati di addestramento. E soprattutto l’esenzione non si applica ai modelli classificati come GPAI con rischio sistemico, che restano soggetti agli obblighi di valutazione e mitigazione dell’articolo 55, con la presunzione legata alla soglia di 10^25 FLOP e la notifica entro due settimane all’AI Office, l’ufficio della Commissione che vigila su questi modelli. Le linee guida della Commissione del 18 luglio 2025 hanno aggiunto il pezzo che serviva: l’eccezione open source vale solo se la licenza consente davvero accesso, uso, modifica e redistribuzione del modello, pesi compresi, e se il modello è pubblicamente disponibile. Non basta chiamarsi aperti.
La seconda volta è nel Cyber Resilience Act, e passa ancora più inosservata. L’articolo 24 crea la figura dell’open-source software steward e le dà un regime alleggerito: niente marcatura CE, niente valutazione di conformità formale, niente conservazione obbligatoria della documentazione tecnica. Ma non le dà l’esenzione. Lo steward deve dotarsi di una politica di cybersicurezza documentata in modo verificabile, cooperare con le autorità di vigilanza del mercato, segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi. L’articolo 64, paragrafo 10, gli risparmia le sanzioni amministrative, e questo è il punto in cui il legislatore riconosce esplicitamente che non si può trattare un manutentore volontario come un produttore. È una gradazione, non un condono.
Due leggi, la stessa frase implicita: l’apertura modula il regime, non cancella il rischio. È una distinzione filosoficamente migliore di quanto all’AI Act venga di solito riconosciuto, perché il regime non guarda soltanto alla licenza. Guarda alla capacità e agli effetti.
Una scala, non un interruttore
Da qui si arriva alla parte che manca, e che nessuna legge ha ancora scritto per intero: una tassonomia dell’apertura che smetta di essere binaria.
Immaginiamo una scala. Al primo gradino c’è la trasparenza scientifica completa, cioè l’articolo che descrive davvero come è stato costruito il modello. Al secondo l’accesso al dataset e alla metodologia, che è cosa diversa dal descriverli. Al terzo l’accesso per audit indipendente, cioè la possibilità per un terzo qualificato di misurare il modello senza chiedere il permesso di volta in volta. Al quarto l’accesso ai pesi sotto un regime di verifica dell’identità, che è precisamente quello che Z.ai ha applicato alle sue funzioni offensive. Al quinto la redistribuibilità dei pesi. Al sesto il diritto di fare fine-tuning. Al settimo il diritto di rimuovere i safeguard. All’ottavo il rilascio completamente irreversibile, che è la somma di tutti i precedenti più l’impossibilità di tornare indietro.
Sono decisioni diverse, con beneficiari diversi e rischi diversi. Un ricercatore che vuole verificare le affermazioni di un vendor ha bisogno del secondo e del terzo gradino, e quasi mai del settimo. Una pubblica amministrazione che vuole ridurre la dipendenza strategica ha bisogno del quinto e del sesto, e non necessariamente dell’ottavo. Una startup che costruisce un prodotto ha bisogno di sapere che il modello non le verrà tolto da sotto i piedi, il che è una questione di licenza e di durata più che di capacità. L’errore culturale attuale è comprimere tutti e otto i gradini dentro la parola «open», e poi litigare come se ci fosse una sola leva da alzare o abbassare.
Un’opacità liberamente redistribuibile
Da questa compressione nasce un secondo equivoco, quasi linguistico, che ormai costringe anche la stampa generalista a mettere le note. Moltissimi modelli descritti come open source sono in realtà open-weight: si possono scaricare i parametri, ma non si conoscono il dataset, la pipeline completa di addestramento, i filtri, le procedure di annotazione, le condizioni di produzione. La Open Source Initiative ha provato a mettere ordine con la Open Source AI Definition 1.0, che chiede insieme i pesi, il codice completo per addestrare ed eseguire il sistema e informazioni sui dati sufficientemente dettagliate perché una persona competente possa costruirne uno sostanzialmente equivalente. È un compromesso, perché non pretende il dataset in sé, ed è stato contestato per questo dalla Free Software Foundation e dalla Software Freedom Conservancy, secondo cui senza i dati esatti la libertà di modificare è nominale.
Il risultato paradossale è che possiamo avere modelli molto aperti nella capacità di proliferare e molto meno aperti nella capacità di essere compresi. È quasi l’opposto dell’ideale originario del software libero. Puoi copiare perfettamente l’oggetto, e non ricostruire davvero come è nato. Un’opacità liberamente redistribuibile.
E qui vale la pena ricordare che l’apertura, anche nel software classico, non ha mai coinciso con la verifica. Heartbleed ha dimostrato nel 2014 che una libreria su cui poggiava mezzo internet era mantenuta da due persone con circa duemila dollari l’anno di donazioni. XZ Utils ha dimostrato nel 2024 che una campagna paziente di quasi tre anni, con otto commit malevoli su una lunghissima lista di contributi legittimi e una pressione coordinata di account fittizi su un manutentore esausto, poteva arrivare a un passo dal compromettere ogni server SSH del mondo. «Molti occhi» è sempre stato un enunciato sulla possibilità, non sulla pratica. L’avevo già scritto guardando i diecimila repository clonati di giugno: aperto vuol dire ispezionabile, non ispezionato. Vale identico per i pesi, con un’aggravante: ispezionare un modello è enormemente più costoso che rileggere le righe cambiate di un commit, e le persone capaci di farlo seriamente nel mondo si contano a centinaia.
Il precedente che abbiamo già inventato
Esiste già, nella nostra cultura, un istituto che risolve un problema della stessa forma, e lo abbiamo costruito noi della sicurezza.
Prendiamo una vulnerabilità zero-day. Siamo normalmente favorevoli alla divulgazione, perché la conoscenza pubblica costringe il produttore a correggere, permette agli utenti di difendersi, crea conoscenza collettiva. Eppure quasi nessuna comunità di sicurezza seria sostiene che il massimo ideale morale consista nel pubblicare immediatamente una exploit chain funzionante contro un’infrastruttura critica prima che esista una patch. La responsible disclosure introduce tempo, contesto, coordinamento e gradazione senza negare il valore fondamentale dell’apertura. Nessuno l’ha mai considerata un tradimento della trasparenza. È il contrario: è la trasparenza che ha imparato a maneggiarsi.
Forse il futuro dell’open AI assomiglierà meno alla pubblicazione simultanea di un repository e più alla disclosure coordinata: massima apertura come obiettivo di fondo, ma possibilità di differenziare tempi e modalità quando determinate capacità superano soglie concretamente misurabili. Che è, riletto adesso, esattamente il calendario del 14 agosto. Due settimane di ritardo sui pesi, accesso verificato sulle funzioni più sensibili, un registro con gli hash delle scoperte ancora sotto embargo. Non sto dicendo che Z.ai abbia trovato la formula giusta, né che le sue motivazioni siano quelle dichiarate, e un regime di accesso verificato gestito da un’azienda soggetta a un ordinamento non europeo pone problemi tutti suoi. Sto dicendo che la forma è già stata inventata, e che è la nostra.
Chi può fare cosa
A questo punto la domanda normativa può essere posta in modo utile. Non «come impediamo alle persone cattive di avere modelli potenti», che è irrealistico e conduce dritto alla sorveglianza e al controllo centralizzato, cioè alla perdita esatta di ciò che volevamo proteggere. Ma: quale distribuzione del potere tecnologico massimizza contemporaneamente autonomia, verificabilità, capacità difensiva e responsabilità?
Questi valori non coincidono. La trasparenza massimizza la verificabilità. L’open weight massimizza la replicabilità. L’esecuzione locale massimizza l’autonomia. L’accesso condizionato può aumentare la responsabilità, perché crea un soggetto a cui chiedere conto. La centralizzazione consente revoca e monitoraggio, e per questo è pericolosa. La decentralizzazione riduce lock-in e abuso monopolistico, e per questo è preziosa. Non esiste un punto che massimizzi tutto, e sostenere il contrario è propaganda, da qualunque parte arrivi. È esattamente il tipo di problema in cui una buona regolazione non deve trovare una verità universale, ma costruire compromessi locali espliciti e dichiarati come tali.
Il che porta alla tesi più radicale, e la formulo per intero: «open source» non dovrebbe più essere una qualità binaria attribuita al modello, ma un’architettura dei diritti attorno al modello. Chi può ispezionarlo. Chi può valutarlo. Chi può eseguirlo. Chi può modificarlo. Chi può redistribuirlo. Chi può rimuoverne i controlli. Chi può collegarlo a strumenti capaci di agire nel mondo. Chi porta la responsabilità quando queste capacità vengono usate. Sono domande infinitamente più utili di «è open?», e hanno il pregio di essere tutte scrivibili in un contratto, in una licenza o in una legge, che è poi il mestiere che facciamo.
Cyber ci obbliga a capirlo prima degli altri domini perché rende immediatamente visibile ciò che altrove resta astratto: si misura, si conta, si riproduce. Ma un modello biomedicale capace di proporre una molecola pericolosa solleva lo stesso problema. Un sistema che ottimizza la progettazione di droni lo solleva. Un agente che opera autonomamente sui mercati lo solleva. Cyber è soltanto il laboratorio in cui la tensione diventa evidente per prima, e per questo è il posto dove conviene sbagliare adesso, mentre gli errori si contano ancora una vulnerabilità alla volta.
La battaglia che viene
Il problema non è che l’open source abbia smesso di essere un valore. È il contrario: è diventato così importante che non possiamo più permetterci di usarlo come slogan.
Per trent’anni abbiamo difeso l’apertura perché impediva che qualcuno possedesse unilateralmente il potere tecnologico, e quell’intuizione resta valida parola per parola. Ma quando l’oggetto aperto non è più soltanto un utensile che posso studiare, bensì una macchina per usi generali capace di trasformare conoscenza in azione, la libertà di ispezionarla e quella di moltiplicarne senza limiti ogni capacità smettono di essere automaticamente lo stesso diritto. Riconoscerlo non è arrendersi al recinto proprietario. È l’unico modo per difendere l’open source europeo senza trasformarlo in un dogma incapace di ammettere che alcuni oggetti tecnologici hanno cambiato natura sotto le nostre mani mentre continuavamo a chiamarli con lo stesso nome.
La prossima battaglia non sarà decidere se aprire o chiudere l’intelligenza artificiale. Sarà decidere quali forme di apertura preservano davvero la distribuzione del potere, senza trasformare la distribuzione del potere nella distribuzione irresponsabile della capacità di nuocere. E il punto di caduta è politico, non tecnico: sovranità non è poter fare qualsiasi cosa con una tecnologia. È non essere costretti a chiedere il permesso a qualcun altro per capire, governare e decidere che cosa quella tecnologia può fare nella nostra società.
Il 14 agosto un laboratorio ha spedito questa domanda a tutti, sotto forma di calendario. Fra due settimane i pesi saranno online, e la parte che conta non sarà quanto è bravo il modello. Sarà se avremo un vocabolario per dire cosa abbiamo appena ricevuto.
Cosa ti porti a casa
Il 14 agosto Z.ai ha annunciato GLM-5.3 con un salto dichiarato nelle capacità cyber, 84,5% su CyberGym e ExploitBench più che raddoppiato, tenendo le funzioni offensive dietro un programma di accesso verificato e rimandando di circa due settimane la pubblicazione dei pesi, i numeri che permettono a chiunque di scaricare il modello ed eseguirlo per conto proprio, in attesa di una valutazione di sicurezza. I benchmark sono dichiarazioni del produttore, ma la forma del rilascio è un fatto: apertura graduata, non interruttore.
Nel software classico il diritto di ispezionare e il diritto di copiare sono inseparabili. Con i modelli si separano in almeno tre diritti distinti: sapere come è stato costruito, valutarne indipendentemente le capacità, possedere una copia illimitatamente modificabile dei pesi. Li abbiamo trattati come la stessa libertà, e non lo sono.
L’argomento dell’irreversibilità non è retorica interessata soltanto: cancellare da Llama 3 8B l’addestramento che gli insegna a rifiutare le richieste pericolose richiede cinque minuti su una scheda grafica A100 e meno di mezzo dollaro, e il tasso di rifiuto di un modello passa dal 78,9% allo 0,4% con un riaddestramento leggero da meno di 200 dollari. La protezione non viaggia con i pesi. Che questo faccia comodo a chi vende accesso via API è vero allo stesso modo, e non rende il dato meno esatto.
L’Europa ha già scritto due volte che aperto non è un’esenzione: l’articolo 53 dell’AI Act esonera i modelli a licenza libera da parte della documentazione ma non dagli obblighi dell’articolo 55 se c’è rischio sistemico, e l’articolo 24 del CRA dà agli open-source steward un regime alleggerito, non l’assenza di obblighi. Guarda alla capacità e agli effetti, non solo alla licenza.
La domanda utile non è «è open?» ma chi può ispezionarlo, valutarlo, eseguirlo, modificarlo, redistribuirlo, rimuoverne i controlli, collegarlo a strumenti capaci di agire, e chi risponde quando accade. Sovranità non è poter fare qualunque cosa con una tecnologia: è non dover chiedere il permesso a qualcun altro per capire, governare e decidere cosa quella tecnologia può fare da noi.
Domande e risposte
Che cosa distingue un modello open-weight da un software open source?
Il software open source distribuisce istruzioni: per ottenere una capacità nuova bisogna leggerle, modificarle o aggiungerne altre, e il codice di nginx non contiene implicitamente migliaia di programmi che emergono chiedendoglieli. Un modello open-weight distribuisce capacità appresa in forma compressa: i pesi, cioè i numeri in cui è depositato quello che il modello ha imparato, possono generare procedure che nessuno ha mai scritto nel sorgente e che il produttore stesso conosce solo per via empirica, attraverso valutazioni. Sono due oggetti diversi sotto la stessa parola, e la differenza conta soprattutto quando il modello viene collegato a shell, browser, compilatori e scanner.
Vietare i modelli open-weight più capaci ridurrebbe la proliferazione?
Probabilmente no, e questa è la ragione più seria per non provarci. Una politica occidentale molto restrittiva rischia soltanto di garantire che i modelli aperti più capaci vengano prodotti altrove: GLM-5.3, annunciato da Z.ai il 14 agosto 2026 con prestazioni dichiarate ai vertici nella scoperta di vulnerabilità, rende l’ipotesi meno teorica. Il punto non è impedire l’esistenza della capacità, che si sta diffondendo comunque, ma decidere quali forme di apertura preservano davvero la distribuzione del potere.
Le protezioni restano attive in un modello con i pesi pubblici?
No, e non per una debolezza di implementazione ma per una questione di costi. La ricerca disponibile mostra che rimuovere il fine-tuning di sicurezza, l’addestramento aggiuntivo che insegna al modello a dire di no, da Llama 3 8B richiede circa cinque minuti su una singola scheda grafica A100, per meno di mezzo dollaro, e circa 45 minuti sul modello da 70 miliardi di parametri; con LoRA, una tecnica di riaddestramento leggero, e meno di 200 dollari il tasso di rifiuto di Llama 2-Chat 70B è passato dal 78,9% allo 0,4%. Il costo è sceso da centinaia di ore GPU nel 2022 a minuti nel 2024. Chi pubblica i pesi pubblica il modello senza i suoi controlli, indipendentemente dalle sue intenzioni.
L'AI Act esenta i modelli open source dagli obblighi?
Solo in parte, e mai quando c’è rischio sistemico. L’articolo 53 esonera i fornitori di modelli GPAI, i modelli per finalità generali, rilasciati con licenza libera e aperta dalla documentazione tecnica e da quella per i fornitori a valle, oltre che dalla nomina del rappresentante autorizzato, ma non dalla politica sul diritto d’autore né dal riepilogo dettagliato dei dati di addestramento. E l’esenzione decade per i modelli classificati a rischio sistemico, che restano soggetti agli obblighi di valutazione e mitigazione dell’articolo 55. Le linee guida della Commissione del 18 luglio 2025 aggiungono che l’eccezione vale solo se la licenza consente davvero accesso, uso, modifica e redistribuzione, pesi compresi.
Che cosa significa allora sovranità digitale su un modello?
Non significa possedere una copia senza restrizioni. Significa non dipendere dalla volontà arbitraria di un altro soggetto, e sono due cose diverse. Un modello accessibile solo attraverso un’unica API straniera è una dipendenza evidente, ma anche un ecosistema europeo che scarica pesi stranieri senza avere potenza di calcolo, competenze, dataset, capacità di riaddestramento e di valutazione non è pienamente sovrano: sta solo cambiando il soggetto da cui dipende. L’open weight è una componente della sovranità, non la sovranità.
L'autore
