L’AI cinese riduce il divario nella cybersecurity, più rischi per le imprese

Il nuovo modello GLM-5.2 di Zhipu AI, società cinese nota anche come Z.ai, entra nel radar delle imprese italiane perché sposta un tema finora trattato soprattutto come competizione geopolitica: la capacità dei modelli di intelligenza artificiale di individuare vulnerabilità software. Secondo quanto riportato dalla ricostruzione pubblicata da The Verge, alcuni ricercatori sostengono che GLM-5.2 raggiunga Mythos in determinati scenari di bug-finding e cybersecurity.

Per le aziende italiane, il punto operativo non è stabilire se un modello cinese superi o meno quelli statunitensi in ogni benchmark, ma aggiornare il modo in cui vengono gestiti strumenti AI capaci di analizzare codice, configurazioni e vulnerabilità. In Italia, la pagina ACN sulla normativa NIS ricorda che il D.Lgs. 138/2024 ha recepito la direttiva NIS2: per i soggetti coinvolti, la gestione del rischio cyber non può più restare separata dall’adozione di modelli AI usati 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 riesce a eguagliare Anthropic o OpenAI nei compiti generali, ma che il divario si sarebbe ridotto nella capacità di trovare bug. La distinzione è centrale per le imprese: un modello meno competitivo nelle attività generaliste può comunque diventare molto efficace in un ambito tecnico delimitato, come l’analisi di codice o l’individuazione di vulnerabilità.

Secondo la fonte, alcuni ricercatori hanno sostenuto che GLM-5.2 sia in grado di eguagliare Mythos in specifici scenari di cybersecurity e bug-finding. Non viene indicato un sorpasso generalizzato, né 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 è comunque 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 lavorato per 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. Secondo The Verge, 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 a utenti esperti un accesso più profondo al modello, ma riduce anche le possibilità di supervisione centralizzata sull’uso effettivo.

La stessa 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. Il punto non è bloccare ogni sperimentazione, ma evitare che strumenti di bug-finding vengano usati senza tracciabilità su codice, infrastrutture o sistemi di terzi.

L’Europa spinge sulla tracciabilità

Il quadro europeo combina due livelli. Il primo è 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. Il secondo è la governance dell’intelligenza artificiale, dove l’AI Act disciplina anche i modelli di uso generale.

La Commissione europea spiega, nelle domande sui modelli AI generali, 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, richiamato da ACN, 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.

La partita industriale Cina-Stati Uniti

The Verge colloca GLM-5.2 in una fase di competizione tecnologica più ampia. La Cina, secondo la fonte, 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: il testo distingue chiaramente tra attività generali, dove GLM-5.2 resta indietro, e scenari di bug-finding, dove il confronto si è fatto più stretto.

La stessa fonte cita anche GPT-5.6 di OpenAI, presentato con accesso limitato dopo preoccupazioni sul possibile uso improprio. 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.