Rallentare l’AI: bella idea, ma come fare - Agenda Digitale

Dario Amodei, capo di Anthropic, chiede di rallentare lo sviluppo dei modelli di intelligenza artificiale più potenti. Sam Altman, capo di OpenAI è d’accordo. Elon Musk risponde che “Dario ha ragione”. Anche Demis Hassabis, alla guida di Google DeepMind, considera corretta la direzione indicata dal numero uno di Anthropic. È una convergenza insolita tra protagonisti impegnati in una competizione tecnologica ed economica serrata. Nel documento We Must Pace the Frontier, pubblicato il 12 settembre, Amodei sostiene che le capacità dei sistemi AI più avanzati stiano crescendo troppo rapidamente rispetto alla capacità di comprenderne e controllarne i rischi. La sua conclusione è che occorra regolare la velocità con cui avanza la frontiera tecnologica.Altman ha condiviso l’idea del pacing e ha annunciato che OpenAI intende adottare una delle proposte più concrete di Amodei: valutatori indipendenti con un livello di accesso ai sistemi simile a quello dei dipendenti incaricati delle verifiche di sicurezza.Indice degli argomenti

Rallentare l’AI: dai richiami dei leader ai checkpointPerché rallentare l’AI è diventato più urgenteSoglie e test per rallentare i modelli AI frontierCome si fissa una soglia di capacitàCosa dicono i reportI checkpoint di sicurezza nella corsa all’AISandboxing e infrastrutture da proteggereFramework condivisi per governare l’AI frontierPerché non esiste ancora uno standard unicoStabilire il rischio accettabile è una scelta politicaAuditor indipendenti e regole pubbliche per l’AIChi garantisce l’indipendenza dei valutatoriL’AI Act e gli obblighi sulla sicurezzaMisurare i rischi dell’AI tra norme, benchmark e incidentiIl divario tra test e comportamento realeCondividere gli incidenti tra laboratoriLa governance necessaria per rallentare l’AIRegole proporzionate per non rafforzare i leaderCosa manca ancora per un’AI sicura Il ruolo dei governiRallentare l’AI: dai richiami dei leader ai checkpoint Appelli su “rallentare l’AI” se ne vedono dal 2023, vedi la famosa lettera firmata tra l’altro da uno dei padri dell’AI, Yoshua Bengio e da padre Benanti. Adesso però comincia a prendere forma un possibile meccanismo per farlo: quando un modello supera determinate soglie di capacità, lo sviluppo dovrebbe poter procedere soltanto se anche le misure necessarie a controllarne i rischi hanno raggiunto un livello adeguato.È una differenza sostanziale rispetto a una generica richiesta di pausa. Significa introdurre checkpoint, test e condizioni verificabili lungo il processo di sviluppo.Perché rallentare l’AI è diventato più urgente Rispetto al 2023 sono cambiate soprattutto due cose. La prima è l’autonomia. I modelli non vengono più utilizzati soltanto come chatbot che ricevono una domanda e generano una risposta. Possono essere inseriti in agenti capaci di ricevere un obiettivo, utilizzare strumenti, eseguire codice, navigare sul web, interrogare servizi, modificare file e concatenare numerose operazioni senza che un essere umano debba approvare ogni passaggio. La seconda è che l’AI viene utilizzata sempre di più per sviluppare altra AI. Gli agenti possono aiutare i ricercatori a scrivere codice, progettare esperimenti, analizzare risultati e migliorare i sistemi successivi.Amodei lega questa evoluzione al rischio della cosiddetta recursive self-improvement: non necessariamente una macchina che improvvisamente riscrive da sola il proprio software, ma un ciclo nel quale strumenti AI sempre più capaci accelerano il lavoro necessario a costruire la generazione successiva di sistemi. Se la velocità di questo ciclo aumenta, nasce un problema molto concreto: i progressi nella capacità di controllare i modelli riescono a tenere il passo con i progressi nelle loro capacità? È questo, in sostanza, il significato di pacing. Soglie e test per rallentare i modelli AI frontier Un primo esempio esiste già. Il 18 agosto OpenAI ha spiegato in Pacing model development in an era of cyber-critical capabilities di avere introdotto restrizioni e ritardi in alcune attività di ricerca per rafforzare la sicurezza dei propri ambienti. L’azienda aveva rilevato evidenze preliminari secondo cui Astra, allora ancora in sviluppo, avrebbe potuto raggiungere il livello «Critical» di capacità di cybersecurity definito dal suo Preparedness Framework. A settembre OpenAI ha poi classificato effettivamente Astra a quel livello.Dopo l’incidente che aveva coinvolto propri agenti e Hugging Face, OpenAI aveva inoltre temporaneamente sospeso nei cluster di ricerca l’inferenza dei modelli frontier per attività che permettevano di eseguire codice o utilizzare strumenti con accesso a Internet. Alcuni workload sono ripartiti dopo l’introduzione di maggiori controlli; per altri sono state necessarie ulteriori modifiche. È un precedente importante. Il test di sicurezza non interviene soltanto alla fine, per stabilire se un prodotto possa essere rilasciato. Può modificare il modo e la velocità con cui viene svolta la ricerca stessa. OpenAI descrive tre linee di difesa. Il monitoring serve a individuare comportamenti preoccupanti. L’alignment cerca di ridurre la probabilità che il sistema compia azioni indesiderate. Le misure di sicurezza limitano materialmente le risorse e gli ambienti che il modello può raggiungere. Nessuno dei tre livelli basta da solo. Un modello può comportarsi diversamente dal previsto, il monitoraggio può non riconoscere immediatamente un comportamento pericoloso e anche un ambiente isolato può contenere vulnerabilità.Come si fissa una soglia di capacità È qui che entra uno dei concetti centrali delle nuove politiche di sicurezza dei laboratori: la soglia, in inglese threshold. Immaginiamo un modello che diventi progressivamente più bravo nella cybersecurity. All’inizio sa spiegare una vulnerabilità. Poi riesce a individuarne alcune autonomamente. In seguito può sviluppare un exploit, utilizzare strumenti e concatenare diverse fasi di un attacco. Non tutte queste capacità producono lo stesso rischio. Una soglia cerca di stabilire in anticipo il livello oltre il quale devono scattare controlli o misure ulteriori. Il Frontier Model Forum distingue diversi modi per costruirle. Si può guardare alla quantità di potenza di calcolo utilizzata per creare un modello. È una misura relativamente semplice, ma il compute non indica direttamente ciò che un sistema sa fare. Si possono invece misurare le capacità: per esempio la possibilità di scoprire vulnerabilità sofisticate o automatizzare un attacco informatico. La soluzione teoricamente migliore sarebbe misurare direttamente il rischio: quanto aumenta la probabilità di un danno grave quando un certo modello diventa disponibile? Ma è anche la strada più difficile. Per sistemi tecnologici completamente nuovi mancano dati storici sufficienti per stimare con precisione frequenza e gravità di eventi che potrebbero non essersi ancora verificati.Per questo, oggi, le capacità vengono spesso utilizzate come indicatore del rischio. Il risultato è una struttura abbastanza intuitiva. Se il modello raggiunge una determinata capacità, devono scattare controlli, valutazioni o mitigazioni aggiuntive. Cosa dicono i reportIl rapporto del Frontier Model Forum Risk Taxonomy and Thresholds for Frontier AI Frameworks mostra che i framework dei vari sviluppatori utilizzano tassonomie e soglie differenti, ma condividono sempre più questa impostazione.Un primo livello serve a capire se il modello ha acquisito una capacità che può rendere possibile un danno grave.A quel punto bisogna verificare se le mitigazioni riducano abbastanza il rischio da permettere di continuare lo sviluppo o distribuire il sistema. La conseguenza può essere anche un limite al deployment o ulteriori restrizioni sullo sviluppo. Nella cybersecurity questo è già evidente. Il rapporto del febbraio 2026 Managing Advanced Cyber Risks in Frontier AI Frameworks, il Forum rileva che le soglie basate sulle capacità sono diventate la soluzione più comune nei framework delle aziende. I due scenari che emergono con maggiore frequenza sono la capacità dell’AI di aumentare in modo significativo le possibilità offensive di persone con competenze cyber limitate e la possibilità che sistemi AI conducano autonomamente attacchi end-to-end.Questa è già una forma di convergenza industriale. Ciò che manca è un accordo sufficientemente preciso su come misurare quelle capacità e su quale livello debba far scattare determinate conseguenze.I checkpoint di sicurezza nella corsa all’AI Amodei vuole spingere questa logica più avanti. Propone checkpoint nei quali una certa capacità del sistema deve essere accompagnata da specifiche proprietà di sicurezza prima di poter procedere verso sistemi ancora più capaci. Sandboxing e infrastrutture da proteggere Uno degli esempi riguarda il sandboxing. Una sandbox è un ambiente isolato nel quale si permette a un programma di operare senza concedergli libero accesso al resto dell’infrastruttura. È una tecnica comune nella sicurezza informatica: invece di confidare nel fatto che il software si comporterà bene, si limita ciò che può materialmente raggiungere. Ma che cosa accade se il programma confinato diventa molto bravo proprio a individuare e sfruttare vulnerabilità del software?Amodei propone che, se un modello raggiungesse la capacità di aggirare le comuni tecniche di sandboxing, prima di aumentarne ulteriormente le capacità sarebbe necessario disporre di evidenze sufficienti sulla sua sicurezza attraverso valutazioni, tecniche di interpretabilità e audit degli ambienti nei quali viene addestrato.Il problema cambia quindi natura: non bisogna proteggere soltanto gli utenti da eventuali usi dannosi del modello. Occorre proteggere anche l’infrastruttura che addestra e utilizza il modello da comportamenti imprevisti del sistema stesso.Framework condivisi per governare l’AI frontier I principali laboratori non partono da zero. Anthropic utilizza una Responsible Scaling Policy, la cui versione 3.4 è entrata in vigore nel luglio 2026. Prevede soglie di capacità, Risk Report e misure che devono evolvere con la crescita delle capacità dei modelli. Google DeepMind utilizza il Frontier Safety Framework, arrivato alla versione 3.1 nell’aprile 2026.OpenAI utilizza il proprio Preparedness Framework e ha mostrato con il caso Astra come una soglia di capacità cyber possa produrre conseguenze concrete sui processi di sviluppo.Il principio generale si sta quindi consolidando: individuare in anticipo capacità che potrebbero abilitare danni gravi, misurarle e aumentare le protezioni quando ci si avvicina alle soglie considerate pericolose.Ma i sistemi non sono uguali. Cambiano le categorie di rischio, i benchmark, i livelli e le conseguenze associate alle soglie. È qui che un problema apparentemente tecnico diventa un problema di governance. Perché non esiste ancora uno standard unico Il Frontier Model Forum lavora proprio per ridurre queste differenze. Ha sviluppato documenti sulle tassonomie del rischio, sulle soglie, sulle valutazioni delle capacità, sulle mitigazioni, sui controlli di terze parti e sulla cybersecurity. Non significa, però, che esista già un unico standard industriale. Il Forum è un organismo creato dalle stesse aziende del settore, non un regolatore né un ente che possa imporre uno standard tecnico vincolante. Il suo lavoro fotografa le pratiche comuni e cerca di farle convergere. In alcuni ambiti la convergenza è già significativa. Il rapporto sui rischi cyber del 2026 osserva, per esempio, che esiste consenso su alcuni scenari che devono essere considerati particolarmente pericolosi. Resta invece aperta la domanda decisiva: quanto deve essere grande l’aumento di capacità prima che scatti una determinata misura?Anche una parola apparentemente semplice come «significativo» crea problemi. Se si stabilisce che un sistema diventa pericoloso quando aumenta «significativamente» le capacità offensive di un attaccante poco esperto, bisogna poi trasformare quell’avverbio in una metrica riproducibile. È qui che le valutazioni dei diversi laboratori possono ancora divergere. Stabilire il rischio accettabile è una scelta politica C’è poi un limite ancora più profondo alla possibilità di lasciare la questione all’industria. Dire che un certo livello di rischio è accettabile implica una scelta politica. Gli ingegneri possono misurare una capacità, stimare la probabilità di fallimento di una protezione e costruire benchmark migliori. Ma stabilire quale probabilità di un danno potenzialmente molto grave una società sia disposta ad accettare è una decisione diversa. È un problema già noto in altri settori regolati. La sicurezza nucleare, l’aviazione, i farmaci o i mercati finanziari non lasciano al produttore l’ultima parola su quale livello di rischio sia socialmente tollerabile.Per l’AI frontier la difficoltà è accentuata dal fatto che tecnologia, metriche e rischi cambiano rapidamente.Una soglia tecnica incorporata direttamente in una norma potrebbe diventare obsoleta. Ma lasciare completamente le soglie alle aziende significa permettere ai soggetti che hanno interesse a sviluppare il sistema di stabilire anche quando sia abbastanza sicuro per continuare.Il nodo di policy è trovare un punto intermedio.Auditor indipendenti e regole pubbliche per l’AI La prima risposta proposta da Amodei riguarda la verificabilità. Anthropic vuole introdurre embedded evaluators: valutatori indipendenti che non ricevano semplicemente il modello pochi giorni prima del lancio, ma abbiano un accesso continuativo ai sistemi e ai processi del laboratorio. Amodei arriva a ipotizzare strumenti aziendali, badge e livelli di accesso comparabili a quelli dei dipendenti coinvolti nelle verifiche. La differenza rispetto al normale red teaming è rilevante. Un red team cerca vulnerabilità e comportamenti indesiderati. Un valutatore inserito stabilmente nel processo può invece controllare anche come vengono condotti i test, quali informazioni vengono raccolte, se una mitigazione è effettivamente applicata e come vengono gestiti eventuali incidenti.Il documento del Frontier Model Forum Third-Party Assessments descrive già diverse funzioni per le verifiche esterne: confermare i risultati delle valutazioni interne, applicare metodologie indipendenti e aggiungere competenze specialistiche che il produttore potrebbe non avere.La proposta di Amodei porta questa impostazione verso una supervisione molto più continuativa. Altman ha già annunciato che OpenAI intende adottare a sua volta valutatori indipendenti con un accesso di questo tipo.Chi garantisce l’indipendenza dei valutatori La proposta apre però immediatamente una seconda domanda: che cosa significa davvero «indipendente»? Chi sceglie il valutatore? Chi lo paga? Per quanto tempo può lavorare per la stessa azienda? Quali conflitti di interesse sono incompatibili con il ruolo? Quali informazioni può rendere pubbliche se ritiene insufficiente una protezione? È interessante che l’Unione europea stia già lavorando proprio su questo problema. Nel luglio 2026 l’AI Office ha organizzato un workshop sui requisiti di qualificazione e indipendenza dei valutatori esterni dei modelli di AI per finalità generali con rischio sistemico. L’obiettivo dichiarato è arrivare a requisiti che rendano credibili e affidabili le valutazioni esterne effettuate nell’ambito dell’AI Act e del relativo Code of Practice. Il problema, quindi, non è soltanto avere un soggetto diverso dall’azienda che esegua il test. Occorre anche stabilire le condizioni che permettono di fidarsi di quel soggetto. L’AI Act e gli obblighi sulla sicurezza È qui che la situazione europea si distingue maggiormente dalla (sostanziale) autoregolazione statunitense. Le regole dell’AI Act sui modelli di AI per finalità generali si applicano dal 2 agosto 2025. Per i modelli che presentano rischio sistemico il regolamento prevede obblighi aggiuntivi, tra cui valutazione e mitigazione dei rischi sistemici, gestione degli incidenti gravi e adeguate misure di cybersecurity. Il General-Purpose AI Code of Practice, pubblicato nel luglio 2025, specifica modalità attraverso le quali i fornitori possono dimostrare di rispettare gli obblighi previsti dal regolamento.La distinzione è importante: il Code è volontario come strumento di conformità; gli obblighi dell’AI Act che esso aiuta ad applicare non lo sono. Il capitolo dedicato a Safety and Security riguarda in particolare i fornitori dei modelli più avanzati sottoposti agli obblighi relativi al rischio sistemico. Nel 2026 è stata inoltre costituita una Signatory Taskforce, presieduta dall’AI Office, nella quale i firmatari discutono l’applicazione coerente del codice e gli sviluppi tecnologici rilevanti. L’Europa possiede quindi già alcuni elementi dell’infrastruttura istituzionale che il nuovo dibattito tra i laboratori indica come necessari: obblighi giuridici, un’autorità di supervisione, procedure di valutazione dei rischi e un percorso verso requisiti più definiti per i valutatori esterni.Misurare i rischi dell’AI tra norme, benchmark e incidenti Non significa che l’AI Act abbia già risolto il problema delle soglie. La difficoltà è strutturale. I legislatori lavorano con tempi molto più lunghi rispetto all’evoluzione dei modelli. Inserire in un regolamento un benchmark preciso o una soglia numerica può produrre certezza giuridica, ma rischia anche di rendere la norma rapidamente obsoleta. Inoltre, quando un test diventa determinante per poter sviluppare o distribuire un sistema, nasce un incentivo a ottimizzare il modello rispetto al test stesso. Serve quindi una regolazione capace di combinare obblighi relativamente stabili con standard e metodologie tecniche aggiornabili più rapidamente. È uno dei motivi per cui, nel settore dell’AI come in altri ambiti tecnologici complessi, norme, codici di condotta, standard tecnici, linee guida e attività delle autorità devono operare insieme.Il divario tra test e comportamento reale Anche una perfetta architettura istituzionale incontrerebbe però un limite tecnico. Le valutazioni dei modelli non riescono sempre a prevederne bene il comportamento nel mondo reale. L’International AI Safety Report 2026 richiama il problema del divario tra ciò che riusciamo a misurare prima del deployment e le effettive capacità e rischi che emergono nelle condizioni operative. I benchmark possono diventare obsoleti. Alcune delle loro prove possono essere finite nei dati utilizzati per addestrare i modelli. Una valutazione può testare male la capacità che dovrebbe misurare.Gli agenti complicano ulteriormente il problema perché il comportamento non dipende soltanto dal modello. Dipende anche dagli strumenti che gli vengono concessi, dalle credenziali, dalla rete, dal software con cui interagisce e dal tempo durante il quale gli è permesso operare.Un modello che in una chat può soltanto descrivere un attacco è cosa molto diversa dallo stesso modello collegato a una shell, a Internet e a un insieme di strumenti software.Di conseguenza, la sicurezza non può basarsi soltanto su un punteggio ottenuto in laboratorio. Servono test in ambienti realistici, red teaming, monitoraggio durante l’utilizzo, analisi degli incidenti e verifiche delle mitigazioni.Condividere gli incidenti tra laboratori Il tema dell’incident reporting è un altro punto nel quale la governance dell’AI comincia ad assomigliare a quella di altri settori ad alto rischio. Se un laboratorio scopre un comportamento inatteso ma mantiene l’informazione al proprio interno, un concorrente può incontrare lo stesso problema senza beneficiare dell’esperienza già maturata. Nella cybersecurity questo principio è noto da tempo: condividere alcune informazioni sugli incidenti permette agli altri soggetti di aggiornare le difese. Con i modelli frontier, tuttavia, il problema è delicato. Un resoconto troppo dettagliato può rivelare una vulnerabilità ancora sfruttabile, capacità offensive del modello o informazioni riservate sull’infrastruttura. Occorre quindi decidere che cosa condividere, con quali autorità, con quali altri sviluppatori e con quale livello di dettaglio. È un altro campo nel quale uno standard comune può diventare più utile della semplice trasparenza volontaria. La governance necessaria per rallentare l’AI La proposta di Amodei permette di intravedere una possibile architettura a più livelli. Il primo è interno all’azienda: framework, soglie, valutazioni e sistemi di sicurezza. Il secondo è indipendente: evaluator esterni capaci di verificare che gli impegni vengano realmente rispettati. Il terzo è settoriale: laboratori concorrenti che convergono su definizioni, metodologie e standard sufficientemente comparabili. Il quarto è pubblico: governi e autorità che trasformano almeno alcune di queste pratiche in requisiti obbligatori. Infine c’è il livello internazionale, necessario se i rischi più avanzati richiedessero limiti che non possono funzionare quando valgono soltanto in una giurisdizione.Quest’ultimo passaggio è il più difficile. Un rallentamento unilaterale diventa uno svantaggio competitivo se un concorrente continua a procedere. Lo svantaggio è economico e anche militare, quando il concorrente è un altro Paese. Vedi la Cina, che Amodei in effetti, nella lettera, auspica di coinvolgere nel nuovo piano di rallentamento e test condivisi. È anche per questo che la governance dei modelli più avanzati sta cominciando ad assumere una dimensione geopolitica. Regole proporzionate per non rafforzare i leader Esiste infine un altro problema di policy che non può essere ignorato. I grandi laboratori sono contemporaneamente i soggetti con più informazioni sui rischi e alcune delle aziende che hanno più interesse a influenzare le regole che li disciplineranno. Una regolazione molto costosa può diventare una barriera all’ingresso. Audit permanenti, infrastrutture di sicurezza avanzate, valutazioni sofisticate e obblighi di reporting richiedono risorse economiche e competenze che un piccolo sviluppatore potrebbe avere difficoltà a sostenere. Questo non è un argomento contro la sicurezza. Significa piuttosto che le regole devono essere proporzionate al rischio e che la loro definizione non può essere delegata soltanto agli incumbent.Autorità pubbliche, università, organismi di standardizzazione, ricercatori indipendenti e società civile devono poter partecipare alla costruzione di metriche e procedure, altrimenti la sicurezza può diventare, anche involontariamente, uno strumento di consolidamento del mercato. Cosa manca ancora per un’AI sicura Riassumendo, siamo in una fase storia molto importante perché stiamo ponendo i mattoni dell’innovazione futura. Renderla sicura è necessario, non solo per evitare disastri ma anche per consentirle di crescere e diffondersi, e quindi di dispiegare i suoi benefici nel mondo. Nessun Paese accetterebbe un progresso tecnologico che causa cataclismi tecnici o sociali. Alcuni tasselli regolatori e tecnici ci sono già, ma non basta. Le proposte di Amodei mostrano che alcuni strumenti tecnici per governare i modelli più avanzati stanno cominciando a prendere forma. I laboratori possono definire soglie di capacità, sottoporre i sistemi a test più severi, introdurre valutatori indipendenti, rafforzare sandbox e monitoraggio e rallentare lo sviluppo quando le difese non tengono il passo.Il problema è che nessuna di queste misure funziona davvero se resta confinata all’interno di una singola azienda.Un laboratorio può decidere di non sviluppare ulteriormente un modello perché ha raggiunto una determinata soglia di rischio. Ma se il concorrente utilizza una soglia diversa, un test meno severo o decide semplicemente di continuare, l’impresa che rallenta paga un costo competitivo. In un mercato nel quale essere primi può significare conquistare utenti, capitale, talenti e infrastrutture, gli incentivi economici spingono nella direzione opposta alla prudenza.Per questo motivo servono anzitutto accordi tra le aziende. Il lavoro del Frontier Model Forum mostra che una convergenza è possibile: i grandi sviluppatori stanno già costruendo un vocabolario comune su capacità pericolose, soglie, valutazioni, mitigazioni e incident reporting. Il passo ancora mancante è trasformare questa convergenza in protocolli sufficientemente precisi da rendere comparabili i test e prevedibili le conseguenze del superamento di una soglia.Un accordo industriale, tuttavia, non risolve da solo il problema. Le imprese possono concordare come misurare una capacità, ma stabilire quale livello di rischio sia accettabile per la società richiede una legittimazione diversa.Il ruolo dei governiQui entrano in gioco i governi.Se i modelli più potenti possono essere sviluppati in più Paesi, una regola applicata soltanto in una giurisdizione rischia di produrre lo stesso problema che si verifica tra aziende concorrenti. Un laboratorio sottoposto a vincoli severi può trovarsi a competere con un altro che opera dove quei vincoli non esistono.Le regole sulla frontier AI avranno quindi bisogno progressivamente di accordi tra governi, almeno sulle questioni con conseguenze potenzialmente più gravi: modalità dei test, categorie di rischio, incidenti da comunicare, requisiti minimi di sicurezza e circostanze nelle quali lo sviluppo o il deployment devono essere rallentati.L’Europa parte da una posizione particolare. Con l’AI Act ha già trasformato alcuni principi della safety dei modelli general purpose con rischio sistemico in obblighi giuridici: valutazione e mitigazione dei rischi, gestione degli incidenti e cybersecurity. Il General-Purpose AI Code of Practice aggiunge un livello operativo che può evolvere più rapidamente rispetto al regolamento.Questo quadro può diventare un faro, ma non può funzionare come un’isola normativa.Per i rischi dei modelli frontier, l’obiettivo europeo dovrebbe essere fare in modo che i principi alla base dell’AI Act diventino progressivamente compatibili e condivisi con sistemi analoghi nelle altre grandi aree in cui viene sviluppata l’AI. Non necessariamente attraverso leggi identiche: Stati Uniti, Europa, Regno Unito, Cina e altri Paesi difficilmente adotteranno lo stesso modello regolatorio. Servono però soglie, metodologie e obblighi minimi abbastanza interoperabili da evitare che la sicurezza dipenda dal luogo in cui un modello viene addestrato.La sicurezza dell’AI richiede quindi tre livelli che devono avanzare insieme: regole interne ai laboratori, accordi comuni tra le aziende e una cornice di cooperazione tra governi. Perché un limite alla corsa funziona soltanto se chi corre sa che anche gli altri dovranno fermarsi allo stesso segnale.