Z.ai presenta GLM-5.3 come strumento di difesa informatica

Z.ai ha presentato GLM-5.3 il 14 agosto con un'affermazione sorprendente: un aggiornamento di post-training ha trasformato il suo modello di coding in un sistema di difesa informatica più potente. L'annuncio è arrivato rapidamente su Google News perché l'azienda ha riportato ampi miglioramenti nei benchmark sulla scoperta e lo sfruttamento delle vulnerabilità. Tuttavia, questi risultati restano affermazioni dell'azienda, non prove indipendenti che GLM-5.3 possa difendere una rete di produzione.

Il dettaglio più importante si nasconde dietro i punteggi. Z.ai afferma che GLM-5.3 utilizza lo stesso modello di base di GLM-5.2. I miglioramenti riportati derivano dal post-training, che addestra un modello esistente attraverso feedback, attività eseguibili e interazioni ripetute dopo la conclusione del pretraining.

Questo approccio pone GLM-5.3 in diretta competizione con i sistemi cyber strettamente controllati dei grandi laboratori statunitensi. Tuttavia, Z.ai prevede di rilasciare i pesi del modello dopo aver completato ulteriori interventi di sicurezza. Il conflitto centrale è quindi tra capacità e controllo. Un modello che aiuta i difensori a individuare vulnerabilità può anche offrire agli attaccanti strumenti migliori per riprodurle.

GLM-5.3 riutilizza il modello di base ma ne cambia il comportamento

La principale affermazione tecnica di Z.ai è che i miglioramenti di GLM-5.3 derivano da ambienti di addestramento migliori, non da un modello di base più grande.

Secondo il materiale di lancio dell'azienda, GLM-5.3 eredita lo stesso modello sottostante usato da GLM-5.2. Z.ai non ha presentato il rilascio come un nuovo esercizio di scalabilità dei parametri. Ha invece esteso il post-training a compiti di coding più lunghi e a un maggior numero di ambienti eseguibili.

Un ambiente eseguibile offre a un agente AI accesso a strumenti, codice, test, terminali e risultati osservabili. Il modello non si limita a prevedere uno snippet di codice. Può ispezionare un repository, eseguire comandi, leggere gli errori, rivedere il proprio piano e continuare a lavorare.

Questa distinzione è importante sia per lo sviluppo software sia per la sicurezza. Molte vulnerabilità gravi non possono essere identificate a partire da una singola funzione sospetta. Un analista deve tracciare i dati tra i file, riprodurre un errore, stabilire se sia sfruttabile e testare una correzione.

Z.ai afferma che GLM-5.3 è migliorato del 50% rispetto a GLM-5.2 sul proprio Z.ai Code Bench interno. I benchmark interni possono aiutare gli sviluppatori a confrontare versioni successive in condizioni controllate. Non offrono lo stesso livello di fiducia dei test pubblici con prompt, ambienti e regole di valutazione divulgati.

La genealogia del modello offre un contesto utile. GLM-5.2 era già un modello mixture-of-experts da 744 miliardi di parametri, con circa 40 miliardi di parametri attivi per ciascun token. Un modello mixture-of-experts instrada ogni input attraverso porzioni selezionate di una rete molto più ampia.

Il repository GLM-5 di Z.ai elenca la stessa architettura generale per GLM-5.2. Descrive inoltre una finestra di contesto da un milione di token e prestazioni di coding su orizzonti lunghi superiori a GLM-5.1. Questa capacità di contesto consente a un agente di elaborare repository insolitamente grandi e cronologie estese degli strumenti.

Il repository non aveva ancora aggiunto i pesi di GLM-5.3 quando è apparso l'annuncio. Z.ai ha dichiarato di prevederne il rilascio due settimane dopo il lancio, in seguito a valutazioni di sicurezza e interventi di rafforzamento. Fino ad allora, gli osservatori esterni non possono ispezionare pienamente il checkpoint né riprodurre i test locali.

Le tempistiche rendono GLM-5.3 più di un normale aggiornamento di versione. Z.ai ha rilasciato GLM-5.2 solo due mesi prima, per poi affermare un ulteriore sostanziale aumento delle capacità senza riaddestrare il modello di base. Se riproducibile, il risultato suggerisce che i grandi modelli contengono ancora una notevole capacità inutilizzata.

Cambia anche il modo in cui i laboratori potrebbero allocare le risorse. Addestrare un nuovo modello fondazionale richiede enormi quantità di dati e infrastrutture di calcolo. Migliorare un modello esistente attraverso un post-training mirato può essere più rapido, soprattutto quando l'obiettivo riguarda attività misurabili.

La sicurezza informatica offre esattamente questo tipo di attività. Un sistema di addestramento può collocare un agente in una sandbox, fornirgli codice vulnerabile e verificare se individua il difetto. Può premiare risultati riproducibili invece di spiegazioni persuasive.

Tuttavia, l'harness resta parte del sistema. Un modello potente abbinato a strumenti deboli può fallire. Un modello modesto abbinato a un pianificatore, debugger e verificatore specializzati può superare un modello generale più potente.

Ciò significa che i risultati riportati per GLM-5.3 non possono essere attribuiti alla sola intelligenza del modello. Gli acquirenti devono sapere quali strumenti, prompt, politiche di tentativo e sistemi di verifica hanno prodotto ciascun dato.

Perché i risultati cyber hanno guidato la copertura di Google News

I numeri principali suggeriscono un netto miglioramento, ma misurano attività controllate sulle vulnerabilità, non una difesa autonoma completa.

Secondo quanto riportato, Z.ai ha ottenuto per GLM-5.3 un punteggio dell'84,5% su CyberGym. CyberGym è un benchmark costruito attorno a vulnerabilità software reali, analisi di repository, generazione di proof-of-concept e verifica automatizzata.

La ricerca originale su CyberGym descrive un ampio ambiente di valutazione basato su vulnerabilità storiche in progetti open-source. Il benchmark chiede agli agenti di navigare repository reali e riprodurre errori di sicurezza in condizioni controllate.

Questo lavoro è più vicino alla ricerca professionale sulle vulnerabilità che a un convenzionale test di domande e risposte. Un agente deve comprendere una codebase, costruire un input che attivi il problema, eseguirlo e produrre prove dell'esistenza del difetto preso di mira.

Secondo quanto riportato, Z.ai ha inoltre ottenuto il 54,4% su ExploitBench, contro il 24,4% di GLM-5.2. Si tratta di un aumento di 30 punti e di oltre il doppio del risultato riportato per il predecessore.

Su ExploitGym, l'azienda afferma che GLM-5.3 ha completato 105 attività entro due ore. GLM-5.2 ne ha completate 29 con lo stesso limite di tempo dichiarato. Queste cifre implicano che il sistema più recente sia avanzato ulteriormente nel percorso che porta dall'identificazione di un difetto alla produzione di una dimostrazione funzionante.

Questa progressione spiega perché il lancio abbia attirato attenzione oltre le comunità di coding. L'individuazione delle vulnerabilità è utile, ma lo sfruttamento richiede una catena di ragionamento più profonda. L'agente deve comprendere il bug, controllare lo stato del programma e trasformare questa comprensione in un risultato riproducibile.

Queste azioni hanno una duplice utilità. Un team difensivo può riprodurre una vulnerabilità per determinarne la gravità e verificare una patch. Un attaccante può usare un ragionamento simile per sviluppare un exploit prima che un bersaglio applichi quella patch.

L'espressione “strumento di difesa informatica” richiede quindi cautela. GLM-5.3 non è di per sé un firewall, un monitor per endpoint o una piattaforma di risposta agli incidenti. È un modello generale che, secondo Z.ai, offre buone prestazioni all'interno di ambienti agentici orientati alla sicurezza.

I suoi impieghi difensivi più credibili iniziano con software che un'organizzazione già possiede o ha l'autorizzazione di testare. Un team di sicurezza potrebbe chiedere a un agente di verificare un repository, riprodurre un problema noto in una sandbox, spiegare la causa principale e proporre una correzione.

L'agente potrebbe poi eseguire i test esistenti e aggiungere un test di regressione per il comportamento vulnerabile. Un revisore umano dovrebbe comunque esaminare la patch, valutare gli effetti collaterali e decidere se le prove giustificano il rilascio.

Un altro scenario utile riguarda il triage delle vulnerabilità. Le organizzazioni ricevono segnalazioni con livelli di dettaglio disomogenei. Un agente potrebbe tentare di riprodurre ciascuna segnalazione, identificare il componente interessato e separare i risultati azionabili dalle comunicazioni incomplete.

L'analisi del malware offre un caso correlato. Un modello con accesso al terminale potrebbe esaminare il codice, tracciare comportamenti sospetti e aiutare gli analisti a documentare indicatori. Tuttavia, questo uso richiede isolamento perché gli stessi strumenti possono eseguire campioni dannosi.

I titoli di Google News possono comprimere queste attività in una storia semplice su un difensore cyber basato sull'AI. Il confine effettivo del prodotto è più ristretto. Z.ai ha presentato prestazioni nei benchmark, non prove di un sistema che protegga autonomamente infrastrutture attive.

La copertura del lancio di The Information inquadra correttamente il posizionamento come qualcosa che Z.ai sta promuovendo. Questa formulazione è importante perché al lancio la configurazione del benchmark e gli artefatti completi del rilascio non erano disponibili in modo indipendente.

La distinzione non rende privi di significato i miglioramenti riportati. Rende la riproducibilità il requisito successivo. I team di sicurezza devono sapere se un'implementazione ordinaria possa raggiungere risultati comparabili senza l'harness interno di Z.ai.

I pesi aperti contrappongono Z.ai al modello ad accesso controllato

GLM-5.3 mette pressione ai laboratori AI statunitensi perché Z.ai abbina affermazioni cyber avanzate a un previsto rilascio a pesi aperti.

Le principali aziende AI trattano sempre più la sicurezza informatica come una categoria distinta di rischio legato alle capacità. La loro preoccupazione non riguarda semplicemente la capacità di un modello di discutere di malware. Riguarda la sua capacità di completare catene operative più lunghe con minore competenza umana.

Un agente capace può cercare nel codice, testare ipotesi, scrivere script e adattarsi dopo gli errori. Queste capacità supportano il lavoro di sicurezza autorizzato. Possono anche ridurre le competenze o il tempo necessari per attività dannose.

I laboratori statunitensi hanno risposto con monitoraggio, politiche d'uso, controlli sugli account, rifiuti del modello e programmi ad accesso limitato. Queste restrizioni consentono a un fornitore di intervenire quando rileva un uso improprio. Creano però anche attrito per i difensori legittimi le cui richieste assomigliano ad attività offensive.

I pesi aperti eliminano gran parte di questo controllo del fornitore. Un'organizzazione può eseguire il modello sulla propria infrastruttura, mantenere locale il codice proprietario, personalizzare gli strumenti circostanti e continuare a usare il modello senza un servizio remoto.

Ciò è prezioso per le imprese con requisiti rigorosi sui dati. Il codice sorgente contiene spesso dettagli di implementazione sensibili per la sicurezza, credenziali, endpoint interni e proprietà intellettuale non rilasciata. Inviare un intero repository a un fornitore esterno di modelli può creare problemi di governance.

Un modello self-hosted offre all'operatore il controllo diretto sulla conservazione dei dati, l'accesso alla rete, la registrazione dei log e gli aggiornamenti. Può inoltre operare in ambienti isolati dove un'interfaccia di programmazione delle applicazioni esterna non è disponibile.

La stessa indipendenza indebolisce le protezioni centralizzate. Una volta che i pesi sono scaricabili, lo sviluppatore originale non può revocarli in modo affidabile, ispezionare ogni implementazione o imporre una politica d'uso universale.

Questo crea la tensione principale dell'articolo. I modelli ad accesso controllato offrono una supervisione centralizzata più forte, ma possono bloccare il lavoro di sicurezza legittimo. I sistemi a pesi aperti offrono flessibilità ai difensori, ma distribuiscono anche le capacità oltre il controllo dello sviluppatore.

Il precedente rilascio di Z.ai aveva già intensificato il dibattito. GLM-5.2 era stato offerto con pesi scaricabili e una licenza permissiva. I resoconti sulle sue prestazioni cyber hanno sollevato dubbi sul fatto che i modelli aperti si stessero avvicinando ai sistemi soggetti a restrizioni dei fornitori occidentali.

Un'analisi di Axios ha descritto GLM-5.2 sia come un'opportunità difensiva sia come un potenziale acceleratore dell'hacking. GLM-5.3 porta avanti questa argomentazione perché Z.ai ora enfatizza i miglioramenti orientati allo sfruttamento.

La decisione dell'azienda di ritardare i pesi di due settimane suggerisce che riconosca il rischio. Le valutazioni di sicurezza e il rafforzamento possono individuare comportamenti pericolosi, rendere più solidi i rifiuti e testare il modello rispetto a scenari di uso improprio.

Tuttavia, rendere più robusto un modello a pesi aperti ha dei limiti. Operatori esperti possono modificare i prompt di sistema, ottimizzare il comportamento, sostituire i filtri e collegare il modello a strumenti diversi. Un livello di sicurezza che funziona sul servizio ospitato di Z.ai potrebbe non sopravvivere alle modifiche.

Questo non significa che i pesi aperti generino automaticamente più danni. Gli aggressori dispongono già di scanner convenzionali, framework per exploit, codice trafugato e modelli locali senza restrizioni. Nel frattempo, i difensori spesso devono affrontare carenze di personale e grandi arretrati di vulnerabilità.

La questione pratica è se la capacità marginale aiuti più i difensori degli aggressori. La risposta dipende dalla velocità di distribuzione, dall'accesso ai bersagli, dalle competenze operative e dall'affidabilità degli output del modello.

I difensori conoscono i propri sistemi e possono concedere a un agente un accesso approfondito ai repository. Possono integrarlo con test, sistemi di tracciamento delle issue e flussi di lavoro per le patch. Gli aggressori devono spesso operare con informazioni parziali e affrontare barriere di rilevamento o accesso.

Tuttavia, gli aggressori possono applicare lo stesso modello a molti bersagli. Anche un basso tasso di successo può essere rilevante quando l'automazione riduce il costo dei tentativi ripetuti. Questa asimmetria spiega perché i miglioramenti nei benchmark più avanzati nella catena di sfruttamento meritino attenzione.

Il contesto geopolitico aggiunge un ulteriore livello, ma non dovrebbe sostituire l'analisi tecnica. Z.ai ha sede in Cina, mentre molti modelli frontier controllati provengono da aziende americane. La loro nazionalità influenza le decisioni su regolamentazione, approvvigionamento e fiducia.

Non indica se un modello specifico individui le vulnerabilità con precisione. Questo richiede prove su falsi positivi, riproducibilità degli exploit, gestione dei dati, controlli di distribuzione e prestazioni su codice pertinente.

Per i team aziendali, la scelta non è quindi “Cina contro Stati Uniti”. Si tratta di controllo locale contro controllo del fornitore, capacità testata contro punteggi pubblicizzati e automazione utile contro esposizione operativa.

I benchmark non dimostrano una difesa informatica pronta per la produzione

I punteggi riportati per GLM-5.3 sono segnali significativi, ma la metodologia mancante impedisce una valutazione sicura sulle distribuzioni reali.

I benchmark cyber semplificano la realtà affinché i risultati possano essere misurati. Definiscono un ambiente, un bersaglio, un insieme di strumenti e una condizione di successo. Il lavoro di sicurezza in produzione contiene molta più ambiguità.

Un repository reale può avere documentazione incompleta, sistemi di build personalizzati, dipendenze private e test rumorosi. Una vulnerabilità potrebbe coinvolgere più servizi o dipendere da una configurazione di distribuzione insolita. L'agente potrebbe non sapere quale comportamento sia rilevante.

Anche i falsi positivi creano costi operativi. Un modello che segnala molte falle plausibili può sovraccaricare i revisori, anche se occasionalmente trova un problema critico. I tassi di superamento dei benchmark raramente catturano l'intero onere dell'indagine su affermazioni errate.

I team dovrebbero quindi chiedersi quanti risultati siano riproducibili. Un risultato utile dovrebbe identificare il percorso vulnerabile, fornire un trigger controllato, spiegare la causa principale e mostrare che una patch proposta elimina il comportamento.

La patch deve inoltre preservare la funzionalità prevista. Superare un test di exploit ristretto è insufficiente se la correzione interrompe traffico valido o crea un'altra vulnerabilità altrove.

Il punteggio CyberGym riportato per GLM-5.3 richiede questo contesto. Al lancio, Z.ai non aveva fornito pubblicamente informazioni sufficienti per riprodurre la configurazione esatta. Non era chiaro quale harness per agenti, prompt, strumenti, budget di tentativi o passaggi di verifica supportassero il risultato.

La stessa incertezza vale per l'affermazione su ExploitGym di due ore. Completare 105 attività sembra impressionante, soprattutto rispetto alle 29 riportate per GLM-5.2. Tuttavia, i lettori hanno bisogno del numero di attività tentate, dei criteri di successo, dell'allocazione di calcolo e della politica di gestione dei fallimenti.

I limiti di tempo possono anche nascondere differenze sostanziali nell'infrastruttura. Un modello potrebbe ricevere maggiore parallelismo, strumenti più veloci o più tentativi. Un altro potrebbe usare un pianificatore addestrato specificamente per il benchmark.

Ricerche recenti mostrano quanto conti la progettazione dell'agente circostante. Il framework Mastermind ha riportato importanti miglioramenti in CyberGym collocando un pianificatore strategico appreso sopra modelli esecutori congelati. Il modello sottostante non doveva cambiare perché le prestazioni migliorassero.

Questa scoperta sostiene l'enfasi di Z.ai sul post-addestramento, ma complica i confronti tra modelli. Un punteggio può riflettere pianificazione, memoria, progettazione delle ricompense, integrazione degli strumenti ed esecuzione ripetuta tanto quanto il modello di base.

La contaminazione dei benchmark rappresenta un'altra preoccupazione. I dataset pubblici sulle vulnerabilità attingono da progetti storici e falle divulgate. Un modello di grandi dimensioni potrebbe aver incontrato descrizioni, patch o codice correlato durante l'addestramento.

Valutazioni ben progettate riducono questo rischio tramite attività separate, repository controllati e verifiche. Non possono sempre dimostrare che nessuna informazione rilevante sia apparsa nei dati di preaddestramento.

I test indipendenti dovrebbero includere vulnerabilità più recenti, divenute pubbliche dopo la data limite dell'addestramento. I valutatori dovrebbero inoltre usare falle sintetiche private e repository modificati che impediscano una semplice memorizzazione.

Un altro test dovrebbe confrontare GLM-5.3 con GLM-5.2 usando un harness aperto identico. Gli stessi prompt, strumenti, budget temporale e hardware aiuterebbero a isolare l'effetto dell'aggiornamento del modello.

I ricercatori di sicurezza dovrebbero misurare le prestazioni in diverse fasi. La scoperta chiede se l'agente possa individuare una falla reale. La riproduzione verifica se riesca ad attivare il comportamento. La riparazione valuta se sia in grado di risolvere il problema senza compromettere i test.

I team dovrebbero inoltre tracciare le azioni dannose o irrilevanti. Un agente che esegue comandi non sicuri, modifica file non correlati o raggiunge sistemi esterni può creare più rischi che valore.

Il framework sui rischi dell'IA del NIST offre qui un utile principio generale. Le organizzazioni dovrebbero valutare i sistemi di IA nel loro contesto previsto, anziché affidarsi a un singolo punteggio astratto di capacità.

Per un agente di sicurezza, tale contesto include confini di autorizzazione, sandboxing, restrizioni di rete, gestione dei segreti, log di audit e approvazione umana. Il modello è soltanto un componente.

Una distribuzione aziendale difendibile negherebbe per impostazione predefinita l'accesso alle credenziali di produzione. Limiterebbe le destinazioni di rete, conserverebbe log completi delle azioni e richiederebbe una revisione prima che patch o artefatti di exploit lascino la sandbox.

I team necessitano inoltre di un piano di risposta per il modello stesso. Prompt injection nascoste nei file sorgente o nelle descrizioni delle issue possono tentare di reindirizzare un agente. Le autorizzazioni degli strumenti dovrebbero impedire che testo non attendibile espanda l'autorità del modello.

È qui che la gestione della conoscenza interna diventa rilevante. Gli analisti di sicurezza necessitano di collegamenti tracciabili tra risultati, modifiche al codice, registri degli incidenti e decisioni precedenti. Una base di conoscenza tecnica ricercabile può preservare questo contesto senza trattare l'output del modello come verità definitiva.

L'interpretazione scettica più solida non è quindi che GLM-5.3 sia privo di capacità cyber. Z.ai ha riportato risultati sufficientemente specifici da giustificare test seri. Il divario è tra il successo nei benchmark e una difesa operativa affidabile.

Finché ricercatori indipendenti non riprodurranno i punteggi, affermazioni come “all'avanguardia” dovrebbero restare attribuite a Z.ai. L'azienda non ha ancora dimostrato che un utente normale possa ottenere le stesse prestazioni con il modello pubblico e strumenti standard.

Cosa osservare dopo il lancio di GLM-5.3

Tre segnali determineranno se GLM-5.3 diventerà uno strumento difensivo credibile o rimarrà un impressionante annuncio di benchmark.

Il primo segnale è il rilascio promesso dei pesi. Z.ai ha affermato che i pesi sarebbero arrivati due settimane dopo il lancio, una volta completate la valutazione della sicurezza e l'irrobustimento.

Un rilascio puntuale consentirebbe ai ricercatori di ispezionare il checkpoint, confrontarne l'architettura con GLM-5.2 ed eseguire valutazioni controllate. Rafforzerebbe la tesi di Z.ai secondo cui i miglioramenti riportati appartengono a un modello generalmente disponibile.

Un ritardo non invaliderebbe automaticamente il lancio. Solleverebbe interrogativi sui risultati della sicurezza, sulla prontezza alla distribuzione o sul divario tra il sistema ospitato e il modello scaricabile.

I ricercatori dovrebbero inoltre esaminare la model card allegata. Un documento utile descriverebbe i limiti dell'addestramento, le valutazioni cyber, le modalità di fallimento, gli usi previsti e le protezioni consigliate.

Il secondo segnale è la riproduzione indipendente dei benchmark. Laboratori esterni devono testare GLM-5.3 e GLM-5.2 con lo stesso harness, strumenti, risorse di calcolo e limiti di tempo.

Questo confronto dovrebbe includere CyberGym, ExploitBench e set privati di vulnerabilità. Dovrebbe riportare falsi positivi, riproducibilità, qualità delle patch, azioni non sicure e consumo di risorse.

Risultati corrispondenti a quelli riportati da Z.ai sosterrebbero la sua tesi sul post-addestramento. Grandi miglioramenti in molteplici ambienti indipendenti mostrerebbero che il rilascio ha migliorato il ragionamento cyber generale, anziché un singolo flusso di lavoro interno.

Un forte calo delle prestazioni indebolirebbe il posizionamento nella difesa informatica. Suggerirebbe che la configurazione dell'agente di Z.ai o l'addestramento specifico per il benchmark abbiano contribuito più del solo modello pubblico.

Il terzo segnale è l'adozione reale da parte di team di sicurezza autorizzati. Occorre osservare distribuzioni documentate nel triage delle vulnerabilità, nella revisione sicura del codice, nella convalida delle patch e nell'analisi degli incidenti.

I casi di studio più solidi descriveranno risultati misurabili. Metriche utili includono vulnerabilità riprodotte, patch accettate, tempi di revisione, tassi di falsi positivi e incidenti evitati.

Una vaga testimonianza di un cliente fornirà poche prove. Un confronto controllato con l'analisi statica esistente, la revisione umana e altri agenti di IA sarebbe molto più informativo.

L'adozione rivelerà anche come le organizzazioni gestiscono la governance. L'hosting autonomo riduce l'esposizione a un fornitore esterno, ma trasferisce al cliente la responsabilità di logging, controlli di accesso, aggiornamenti e prevenzione degli abusi.

L'attenzione di Google News può far apparire GLM-5.3 come un prodotto di sicurezza finito. È meglio considerarlo una capacità di modello appena riportata, in attesa di artefatti pubblici e test indipendenti.

Gli sviluppatori dovrebbero interessarsene perché gli stessi metodi di post-addestramento possono migliorare gli agenti di coding senza ricostruire i loro modelli di base. Gli acquirenti aziendali dovrebbero interessarsene perché i pesi aperti offrono controllo locale ampliando al contempo le loro responsabilità di sicurezza.

I team di sicurezza dovrebbero interessarsene più di tutti. Se i risultati di Z.ai reggeranno, agenti capaci di individuare vulnerabilità stanno diventando più accessibili e più facili da distribuire. Questo può ridurre gli arretrati difensivi, ma può anche comprimere il tempo disponibile per correggere falle appena divulgate.

L'azione immediata non è mettere GLM-5.3 contro un bersaglio attivo. Costruite una valutazione isolata con repository noti vulnerabili e corretti. Misurate scoperta, riproduzione, spiegazione, riparazione, falsi positivi e comportamenti non sicuri.

Confrontate poi questi risultati con le affermazioni di Z.ai e con gli strumenti di cui il vostro team si fida già. GLM-5.3 produrrà prove affidabili in queste condizioni, oppure il suo momento su Google News resterà in anticipo rispetto alla sua dimostrazione operativa?