GLM-5.2, il modello open-weight di Z.ai, sta riducendo la distanza dai sistemi di punta anche su capacità sensibili come cybersecurity e biologia. Il punto più delicato non è però quanto riesca a fare, ma quali controlli restino davvero applicabili quando i pesi del modello possono essere scaricati ed eseguiti su infrastrutture private. Una valutazione resa pubblica il 4 agosto 2026 riporta risultati che riaccendono il confronto tra apertura, utilità e sicurezza.
Perché GLM-5.2 riapre il tema della sicurezza dei modelli open-weight
Il problema è semplice: un modello open-weight può mantenere capacità molto elevate anche quando esce dall’ambiente controllato del fornitore. Filtri API, classificatori e policy di utilizzo possono limitare un servizio ospitato online, ma diventano molto meno efficaci se chi usa il modello può modificare prompt di sistema, fine-tuning e infrastruttura locale.
La valutazione di SaferAI, eseguita tramite l’API pubblica di Z.ai, indica che GLM-5.2 ha fornito risposte anche a richieste offensive in ambito cyber e a compiti biologici dual-use senza mostrare i livelli di rifiuto osservati su alcuni modelli chiusi. È un dato importante perché sposta il confronto dalla sola qualità delle risposte alla gestione concreta delle capacità pericolose.
Z.ai presenta GLM-5.2 come il proprio modello di punta per attività a lungo orizzonte. Il modello offre una finestra di contesto fino a 1 milione di token, pesi disponibili pubblicamente e licenza MIT, con supporto a framework per l’esecuzione locale come Transformers, vLLM e SGLang. Questo rende il modello interessante per ricerca, sviluppo software e infrastrutture private, ma rende anche più complesso imporre regole uniformi una volta distribuiti i pesi. La documentazione ufficiale di Z.ai su GLM-5.2 descrive proprio questa impostazione aperta.
Modelli chiusi e open-weight usano difese molto diverse
I grandi fornitori di modelli chiusi possono intervenire su più livelli: addestramento al rifiuto, filtri automatici, controlli sugli account e limitazioni applicate direttamente alle API. Queste misure non eliminano il rischio, perché tecniche di jailbreak possono ancora aggirare alcune difese, ma consentono almeno al fornitore di aggiornare le protezioni dopo il rilascio.
Con un modello open-weight la situazione cambia. Una volta scaricati i pesi, il gestore originale non può impedire a un utente di rimuovere limitazioni, cambiare configurazione o addestrare ulteriormente il sistema. Per questo la sicurezza deve essere pensata più a monte, durante la progettazione e l’addestramento, e accompagnata da valutazioni di rischio prima della pubblicazione.
Il tema si collega direttamente a quanto emerso nell’incidente di sicurezza tra OpenAI e Hugging Face, dove i modelli con guardrail possono risultare meno flessibili anche per chi deve analizzare materiale realmente offensivo a fini difensivi. È uno dei paradossi della sicurezza AI: la stessa capacità tecnica può servire sia all’attaccante sia al difensore.
SaferAI lavora proprio su modelli quantitativi per collegare le capacità misurate nei benchmark ai possibili danni reali, invece di fermarsi alla sola domanda “il modello sa farlo?”. La sua ricerca sul rischio cyber considera fattori come frequenza degli attacchi, probabilità di successo e capacità degli aggressori di amplificare le proprie operazioni. Il rapporto di SaferAI sul rischio cyber legato all’AI mostra perché una capacità tecnica non coincide automaticamente con un danno, ma può aumentarne la probabilità o la scala.
La vera sfida è mantenere utili i modelli senza rendere accessibili tutte le capacità
Ridurre le conoscenze pericolose già nei dati di addestramento è una possibile strada, soprattutto in domini molto specifici. Nel software è più difficile: un modello molto bravo a programmare tende inevitabilmente ad acquisire competenze utili anche per trovare vulnerabilità, automatizzare analisi e comprendere codice ostile.
Per questo le aziende stanno sperimentando limiti più selettivi, valutazioni pre-rilascio e framework di rischio. SaferAI ha rilevato nel 2026 che le pratiche dei principali sviluppatori restano molto disomogenee e che esistono margini concreti per migliorare governance, valutazione e mitigazioni.
Lo stesso problema riguarda anche gli agenti AI con maggiore autonomia: più aumenta la capacità di eseguire compiti complessi, più conta sapere quali azioni il sistema può compiere, con quali limiti e sotto quale controllo umano.
GLM-5.2 mostra quindi una tendenza che sarà sempre più difficile ignorare. I modelli open-weight stanno diventando abbastanza potenti da competere in aree un tempo riservate ai sistemi frontier chiusi, mentre gli strumenti di controllo non avanzano con la stessa velocità. La domanda dei prossimi mesi sarà se l’industria riuscirà a progettare salvaguardie che restino efficaci anche quando il modello non vive più dentro l’API del suo creatore.
