Il nuovo modello GLM-5.2 di Zhipu AI, società cinese nota anche come Z.ai, sta attirando l’attenzione delle aziende italiane perché evidenzia un tema finora considerato principalmente in termini di competizione geopolitica: la capacità dei modelli di intelligenza artificiale di individuare vulnerabilità software.

Secondo quanto riportato da The Verge, alcuni ricercatori sostengono che GLM-5.2 raggiunga prestazioni simili a Mythos in determinati scenari di bug-finding e cybersecurity. Per le imprese italiane, l’aspetto cruciale non è stabilire se un modello cinese superi o meno quelli statunitensi in ogni benchmark, ma aggiornare la gestione degli strumenti AI capaci di analizzare codice, configurazioni e vulnerabilità.

In Italia, ACN ricorda che il D.Lgs. 138/2024 ha recepito la direttiva NIS2: per i soggetti coinvolti, la gestione del rischio cyber non può più essere separata dall’adozione di modelli AI utilizzati da team interni, fornitori, consulenti o security operation center.

La distanza si accorcia sui bug

La notizia nasce dal rilascio di GLM-5.2 come modello open-weight. The Verge riporta che il modello non eguaglia Anthropic o OpenAI nei compiti generali, ma che il divario si è ridotto nella capacità di trovare bug. Questa distinzione è importante per le imprese: un modello meno competitivo nelle attività generaliste può comunque diventare molto efficace in un ambito tecnico specifico, come l’analisi del codice o l’individuazione di vulnerabilità.

Alcuni ricercatori hanno sostenuto che GLM-5.2 sia in grado di eguagliare Mythos in specifici scenari di cybersecurity e bug-finding. Non si tratta di un sorpasso generalizzato, né di un dominio complessivo sui modelli statunitensi: il dato comunicato riguarda casi d’uso particolari.

Per chi gestisce software aziendale, applicazioni web, ambienti cloud o prodotti digitali, questa è la parte da osservare, perché l’efficacia nei test di vulnerabilità incide sul lavoro di red team, bug bounty, audit applicativi e revisione del codice.

The Verge collega il progresso di Z.ai al confronto tecnologico tra Cina e Stati Uniti. Il governo statunitense ha cercato di limitare l’accesso della Cina a modelli avanzati come Mythos e Fable di Anthropic, oltre che all’hardware necessario per addestrarli ed eseguirli. La stessa fonte scrive che l’amministrazione Trump considera Mythos e altri modelli avanzati, capaci di identificare vulnerabilità, come minacce per la sicurezza nazionale.

Open-weight, controllo più difficile

La scelta tecnica che cambia il profilo di rischio è il formato open-weight. GLM-5.2 può essere scaricato ed eseguito da chiunque su hardware facilmente reperibile. Questo riduce la dipendenza da piattaforme cloud controllate dal vendor e offre agli utenti esperti un accesso più profondo al modello, ma riduce anche le possibilità di supervisione centralizzata sull’uso effettivo.

Questa caratteristica produce due effetti opposti. Da un lato, security team, ricercatori e aziende possono sperimentare strumenti di analisi più flessibili, anche in ambienti isolati o senza inviare codice sorgente a servizi esterni. Dall’altro, The Verge osserva che un modello eseguibile con poca supervisione può essere sfruttato da attori malevoli: la tecnologia che aiuta a trovare difetti nel software può essere usata anche per cercare punti deboli in sistemi non autorizzati.

Per le imprese italiane, il primo controllo pratico è censire dove entrano questi modelli: workstation di sviluppatori, ambienti di test, strumenti di application security, piattaforme di consulenti esterni, servizi gestiti di cybersecurity. Un modello open-weight non passa necessariamente dal procurement tradizionale di un servizio SaaS; può essere introdotto come dipendenza tecnica, container, notebook o componente locale.

La policy sull’AI generativa, se limitata agli account aziendali su servizi cloud, rischia quindi di non intercettare l’uso reale. Nel perimetro NIS, questo si traduce in processi documentabili: chi autorizza l’uso del modello, quali dati può analizzare, dove vengono conservati prompt e output, quali ambienti possono eseguire pesi open-weight e quali attività richiedono revisione umana.

L’obiettivo non è bloccare ogni sperimentazione, ma evitare che strumenti di bug-finding vengano usati senza tracciabilità su codice, infrastrutture o sistemi di terzi. L’esecuzione locale di modelli open-weight cambia controlli, tracciabilità e gestione dei dati tecnici.

L’Europa spinge sulla tracciabilità

Il quadro europeo combina due livelli: la cybersecurity, con la direttiva europea NIS2 su EUR-Lex, che stabilisce misure di gestione del rischio e obblighi di segnalazione per i settori inclusi; e la governance dell’intelligenza artificiale, dove l’AI Act disciplina anche i modelli di uso generale.

GLM-5.2 non supera i rivali USA nei compiti generali, ma la corsa sui bug obbliga le imprese a governare l’AI nei processi cyber. La Commissione europea spiega che i fornitori di modelli general-purpose devono documentare informazioni tecniche e renderle disponibili, su richiesta, all’ AI Office e alle autorità nazionali competenti.

La disciplina riguarda il lato dei provider, ma le aziende che integrano modelli nei propri sistemi devono comunque poter dimostrare di aver valutato limiti, rischi e catena di responsabilità. Nel caso di modelli open-weight, la tracciabilità diventa più concreta e meno contrattuale: se un team scarica un modello e lo esegue localmente, l’impresa deve sapere quale versione è stata usata, con quali parametri, su quali dati e per quale attività.

Per un audit interno o per una verifica post-incidente, non basta indicare che “è stata usata l’AI”: servono registri, responsabilità e procedure di escalation quando l’output riguarda vulnerabilità sfruttabili. Il recepimento italiano della NIS2 attraverso il D.Lgs. 138/2024 porta questo tema dentro le priorità di governance cyber.

I soggetti essenziali e importanti devono organizzare la gestione del rischio in modo coerente con processi, fornitori e sistemi effettivamente usati. Se l’AI entra nel ciclo di vulnerability management o nelle attività di sviluppo sicuro, deve comparire anche nei controlli interni, non solo nelle linee guida generiche sull’innovazione.

Dalla ricerca alle procedure aziendali

La capacità di un modello di trovare bug non sostituisce le attività di sicurezza già previste. Può però cambiare tempi, costi e volume delle verifiche: un team applicativo può usare un modello per evidenziare pattern sospetti nel codice; un fornitore di servizi gestiti può accelerare il triage; un attaccante può provare a replicare lo stesso metodo su software esposto.

La convergenza tra strumenti difensivi e strumenti offensivi è il motivo per cui il controllo dell’uso diventa parte della postura aziendale. Per PMI tecnologiche, software house e system integrator italiani, la misura minima è separare gli ambienti: i modelli destinati a test di sicurezza dovrebbero operare su copie controllate, repository autorizzati e dataset privi di segreti operativi non necessari.

Chi sviluppa prodotti per clienti regolati dovrebbe prevedere clausole sul ricorso a modelli open-weight, sulla conservazione degli output e sulla gestione delle vulnerabilità emerse durante l’analisi. Per enterprise e infrastrutture critiche, il nodo è la catena dei fornitori: un consulente può usare strumenti AI per accelerare un assessment, ma l’azienda committente deve sapere se l’analisi avviene su sistemi locali, su ambienti cloud o tramite modelli scaricati.

Anche quando il modello non invia dati a un servizio esterno, restano rischi di configurazione, accessi non autorizzati, output sensibili e uso improprio dei risultati. I board e i comitati rischio dovrebbero quindi chiedere una mappa operativa: quali modelli vengono usati in ambito cybersecurity, chi li gestisce, quali controlli impediscono attività non autorizzate, come vengono validati i risultati e come si decide se una vulnerabilità individuata deve essere notificata, corretta o condivisa con un fornitore.

L’arrivo di modelli più accessibili rende queste domande meno teoriche. CIO, CISO e responsabili rischio devono integrare l’AI nei processi di sicurezza applicativa e supply chain.

La partita industriale Cina-Stati Uniti

The Verge colloca GLM-5.2 in una fase di competizione tecnologica più ampia: la Cina avrebbe ridotto in modo marcato il divario rispetto agli Stati Uniti in alcune capacità dei modelli AI. Non significa che Z.ai abbia raggiunto OpenAI o Anthropic su tutti i fronti, ma che il confronto si è fatto più stretto in un’area specifica.

Per le imprese europee, la dinamica industriale produce un effetto pratico: le capacità più sensibili non restano necessariamente confinate dentro pochi servizi chiusi. Se modelli specializzati diventano scaricabili, replicabili e utilizzabili su hardware disponibile, i confini tradizionali tra vendor, cliente e utilizzatore finale diventano più difficili da governare.

Cosa mettere nel piano rischi Nel breve periodo, le aziende italiane dovrebbero trattare i modelli AI per il bug-finding come strumenti dual-use. Questo implica inventario degli strumenti, autorizzazioni chiare, ambienti isolati, logging delle attività, revisione umana degli output e procedure di disclosure per le vulnerabilità.

Le organizzazioni soggette a NIS2 dovrebbero collegare questi controlli ai processi già esistenti di gestione incidenti, supply chain security e sicurezza applicativa. La notizia su Z.ai non dice che GLM-5.2 sia il miglior modello generale sul mercato, né che ogni impresa debba adottarlo. Dice che la distanza tra modelli cinesi e statunitensi si è ridotta in un’area specifica e sensibile: trovare bug. Per CIO, CISO e imprenditori italiani, il passo successivo è trasformare le policy sull’AI da documento generale a controllo operativo sul modo in cui codice, vulnerabilità e modelli open-weight entrano nei processi aziendali.