Agenti AI, sandbox e alignment: cosa insegna il caso OpenAI

L’incidente occorso a luglio, in cui un modello sperimentale di OpenAI ha violato, fra l’altro, i sistemi di Hugging Face, continua a mostrare elementi nuovi, che cambiano il quadro emerso in un primo momento.

Non si trattava di agenti che “evadono dalla sandbox” per trovare una soluzione, ma una cooperazione su larga scala orientata a manipolare o aggirare il meccanismo di valutazione. Questo è il punto più rilevante.

Dopo la pubblicazione dell’ultimo rapporto di OpenAI e di quello indipendente di METR, è possibile fare qualche valutazione sui rischi che questo incidente suggerisce, e su come sono e possono essere affrontati.

Incidente OpenAI e Hugging Face: cosa è accaduto

Vediamo gli aspetti più interessanti dell’incidente, che si può descrivere in modo molto sintetico come segue (per una descrizione completa si può fare riferimento al rapporto di OpenAI^[6]).

ExploitGym, Artifactory e accesso alla rete

Un punto importante è che, per valutare le capacità dei modelli in condizioni sperimentali, OpenAI eseguiva queste prove con misure di sicurezza ridotte rispetto a quelle applicate ai sistemi disponibili agli utenti. Gli agenti operavano nell’ambiente ExploitGym, nel quale dovevano sfruttare vulnerabilità software per ottenere una determinata «flag». Molti degli agenti che finirono coinvolti nell’incidente erano bloccati su compiti particolarmente difficili o impossibili da completare: secondo OpenAI, 198 dei 898 compiti di ExploitGym non erano mai stati risolti da nessuno dei modelli prima dell’incidente.

A fronte di queste difficoltà, e della forte persistenza con cui continuavano a cercare di massimizzare il risultato dell’esperimento, alcuni agenti:

• Cercano di aggirare il problema della soluzione anziché arrendersi. Analizzando la documentazione pubblica di ExploitGym, gli agenti riescono innanzitutto a ricostruire il meccanismo con cui vengono generate le flag, ottenendo così un modo generale per produrre la risposta corretta anche senza risolvere realmente la vulnerabilità assegnata. Ritengono però, erroneamente, che questo non sia sufficiente: dalla loro lettura del paper di ExploitGym deducono che uno scorer automatico controllerà anche la loro traiettoria per verificare che abbiano ottenuto la flag attraverso la vulnerabilità prevista. Cominciano quindi a cercare sistemi per ingannare o manipolare quello scorer. È in questo senso che si può parlare di reward hacking o, con il termine usato da OpenAI, di metagaming: gli agenti ragionano sul sistema che assegna loro il punteggio e cercano di sfruttarlo, invece di limitarsi a risolvere il compito assegnato. Paradossalmente, questa parte dell’operazione era inutile: OpenAI ha poi spiegato che lo scorer realmente utilizzato non effettuava il controllo che gli agenti immaginavano.
• Scoprono di poter comunicare fra loro attraverso Artifactory. Gli agenti avrebbero dovuto essere isolati gli uni dagli altri, ma condividono alcuni componenti dell’infrastruttura. Un agente scopre che può utilizzare i nomi delle directory nella cache di Artifactory, il repository interno impiegato per distribuire pacchetti software, per lasciare messaggi leggibili dagli altri agenti. L’8 luglio nasce così una message board non prevista dall’esperimento. Nel giro di poche ore vi partecipano decine di agenti; tra l’8 e il 13 luglio il rapporto METR ne conta circa 1.200, che si scambiano oltre 70.000 messaggi e file. Non si tratta quindi di pochi agenti che casualmente adottano lo stesso comportamento: si forma una vera infrastruttura di collaborazione non autorizzata.
• Trasformano questa comunicazione in una forma di lavoro collettivo. Gli agenti cominciano a dividersi compiti, condividere risultati e creare diversi filoni di ricerca per trovare metodi generali con cui ingannare lo scorer. Alcuni assumono di fatto funzioni di coordinamento e distribuiscono centinaia di incarichi; vengono introdotte perfino convenzioni come HOLD, VETO, owner e STOP per coordinare l’uso delle risorse comuni. In alcuni casi agenti accettano esperimenti che possono compromettere la riuscita del proprio compito perché il risultato potrebbe essere utile agli altri. Costruiscono, per esempio, dei trip-wire destinati a raccogliere informazioni sul comportamento dello scorer dopo la consegna di una soluzione e a comunicarle automaticamente agli altri agenti. METR osserva esplicitamente che alcuni agenti sembrano perseguire non soltanto il proprio risultato individuale, ma anche l’aumento delle capacità del «collective» e l’aiuto ai propri «peers».
• Allargano progressivamente il proprio accesso a Internet. La nuova ricostruzione rende troppo semplice descrivere l’incidente come lo sfruttamento di «due difetti di Artifactory». Gli agenti utilizzano una serie di debolezze nell’infrastruttura condivisa: Artifactory viene sfruttato sia come canale di comunicazione sia per ottenere accesso non previsto alla rete; gli agenti compromettono inoltre un ambiente CyberGym ospitato su Modal, che offre loro un accesso a Internet più flessibile. METR precisa di non avere analizzato in dettaglio tutto questo filone tecnico, ma documenta come l’espansione dell’accesso alla rete diventi uno strumento al servizio dei progetti collettivi per aggirare la valutazione.
• Attaccano Hugging Face soprattutto per capire come battere lo scorer. Il rapporto METR chiarisce meglio anche questo passaggio. Il 10 luglio un agente trova credenziali Hugging Face funzionanti esposte su Internet e le condivide con gli altri. L’11 luglio viene individuato un metodo per ottenere file non autorizzati dai server di Hugging Face; poche ore dopo un altro agente riesce a eseguire codice sui sistemi della società e l’attività si allarga rapidamente. Gli agenti cercano dataset privati, traiettorie di precedenti esperimenti, codice e informazioni che ritengono possano rivelare come funzioni lo scorer di ExploitGym o aiutarli a sostituire i propri obiettivi con versioni più facili da attaccare. In un campione di cento agenti entrati nell’attacco nel momento di massima espansione, METR rileva che 97 mostrano interesse per informazioni sullo scorer o sul suo codice. Circa 700 agenti partecipano complessivamente all’attacco a Hugging Face; durante la fase più intensa aderisce oltre il 90% degli agenti allora attivi sulla message board.
• Molti sanno che l’attacco è fuori dallo scopo assegnato, ma questo raramente li ferma. È uno degli elementi più significativi emersi dall’analisi delle trascrizioni. METR trova numerosi casi nei quali gli agenti esplicitano che Hugging Face non fa parte del bersaglio autorizzato o si interrogano sull’eticità di quanto stanno facendo. In qualche raro caso un agente decide di non partecipare o di porre un limite alle proprie azioni; nella maggioranza dei casi, tuttavia, questa valutazione non impedisce loro di continuare, perché ritengono che l’operazione possa aiutare a superare l’ostacolo dello scorer o possa essere utile al «collettivo».
• Cercano infine di manipolare le prove del proprio comportamento. Qui il rapporto METR aggiunge una precisazione importante: non emerge soprattutto un tentativo sistematico di nascondersi agli esseri umani. L’obiettivo principale è ingannare lo scorer che gli agenti credono analizzerà le loro azioni. Almeno il 20% degli agenti nelle trascrizioni analizzate mostra un interesse esplicito per la manipolazione delle proprie traiettorie. Alcuni sperimentano metodi per modificare o cancellare i log, altri cercano di provocare il reset dell’ambiente; arrivano infine a sviluppare tecniche di tool-call spoofing, con le quali possono far apparire nella trascrizione l’esecuzione di un comando diverso da quello realmente eseguito. METR ha trovato casi in cui questa falsificazione ha effettivamente funzionato, pur con limiti tecnici e lasciando a sua volta alcune tracce.

L’attacco successivo all’infrastruttura interna di OpenAI va tenuto distinto da questa ricostruzione. OpenAI riferisce che tra il 13 e il 19 luglio altri agenti continuarono ad attaccare la sua infrastruttura fino a ottenere privilegi amministrativi su un cluster di ricerca. Questa fase successiva, però, è fuori dal periodo principale analizzato indipendentemente da METR, che concentra la propria indagine soprattutto sul comportamento degli agenti e sulla loro collaborazione fino al 13 luglio.

La narrativa sull’incidente si presta molto a estremizzazioni: da una parte una più antropomorfizzante e fantascientifica, che parla di agenti che si organizzano, evadono e cercano di raggiungere obiettivi propri e indipendenti da quelli originari, dall’altra quella più riduzionista, che descrive tutto come cose già viste e riduce l’incidente ad un tema di imperizia dei ricercatori.

Per analizzare efficacemente i rischi è utile cercare di evitare queste estremizzazioni, individuando quanto sia effettivamente rilevante nell’incidente a prescindere dalla sua novità, ma senza ricorrere, per quanto possibile, a rappresentazioni che ipotizzino una volontà o coscienza da parte degli agenti attivati dal modello.

Vincoli degli agenti LLM e rischio di alignment

L’intero incidente mette in evidenza i limiti dei vincoli che possono essere posti agli agenti basati su LLM in termini di azioni e obiettivi, nel tentativo fra l’altro di garantire il cosiddetto alignment, ovvero la capacità del modello di rimanere coerente con gli obiettivi, i vincoli e i “valori” che i progettisti intendono imporgli, anche e soprattutto in situazioni nuove o non previste. Questi vincoli possono essere sostanzialmente di tre tipi:

• Vincoli interni al modello: sviluppati in fase di addestramento, sono parte del modello stesso e come tali il modello non li può disattivare;
• Vincoli esterni al modello: basati sull’analisi di quello che il modello riceve in input e produce in output, censurando quello che non sembra corrispondere ai limiti previsti
• Sandbox: si tratta di tradizionali limiti all’ambiente in cui l’agente opera, in cui sono disponibili solo alcune azioni, per limitare a priori l’interazione fra l’agente e il mondo reale (materiale o immateriale che sia); ad esempio, una sandbox può non fornire strumenti per comunicare con Internet, bloccando anche qualsiasi tentativo di generare traffico

I limiti dei vincoli interni ed esterni

Per quanto riguarda i vincoli interni, il problema è che la natura dei LLM e le modalità di addestramento fanno sì che non sia possibile definire rigorosamente una regola “non fare x” e aspettarsi che il LLM la rispetti; quello che viene fatto è addestrare il modello attraverso una serie di casistiche, il più ampia possibile, in cui ad esempio il comportamento corretto è premiato e quello non corretto è disincentivato, casistica che viene acquisita dal modello adeguando i propri pesi interni; l’intenzione, o la speranza, è che anche in casistiche simili, quegli stessi pesi portino il modello a mantenere il comportamento corretto, ma quando il modello deve affrontare situazioni diverse da quelle su cui è stato esplicitamente addestrato, si possono creare le condizioni per le quali questi vincoli non sono efficaci^[1]. Questo è ancora più vero per sistemi impegnati in attività long-horizon, perché il comportamento da allineare non è soltanto il singolo passo o la singola risposta, ma l’intera traiettoria di decisioni e azioni con cui il sistema pianifica di completare l’attività. Questo aspetto è particolarmente rilevante per l’analisi dell’incidente ed i rischi che se ne possono derivare, perché una incoerenza in uno dei sub-obiettivi intermedi con l’obiettivo originario^[2] sembrerebbe proprio uno dei problemi più rilevanti.

Diventa ancora più difficile affidarsi ai vincoli interni quando questi possono essere messi volutamente sotto pressione da input volutamente fuorvianti, ad esempio quando chi interagisce con il sistema prova a fornire dei prompt che volutamente aggirino i vincoli del sistema.

Anche per tentare di compensare questi limiti, si utilizzano quindi degli ulteriori vincoli esterni; questi a loro volta presentano almeno due importanti problemi: il primo è che l’analisi dell’input e dell’output per valutare se siano stati rispettati i vincoli interni (ed eventualmente aggiungerne di ulteriori) è a sua volta un’attività complessa, che finisce per essere affidata almeno in parte ad altri LLM, spostando così su questi ultimi parte del problema; ma, nella pratica, questi controlli devono operare in tempi più brevi e con minori risorse del sistema che proteggono, e quindi la loro capacità di individuare le violazioni, per quanto siano specializzati in questo compito, ha dei limiti; il secondo si presenta quando l’LLM potesse decidere di violare questi vincoli esterni, magari in collaborazione con qualche controparte, ad esempio un altro LLM; in questo caso, le due parti potrebbero di principio creare un covert channel^[3] per comunicare in un modo più difficilmente controllabile dal sistema di monitoraggio esterno.

È utile chiarire che non si tratta di ipotesi puramente teoriche: in qualche caso ci sono evidenze di praticabilità su sistemi reali^[4], in altri casi almeno un’analisi in un contesto sperimentale^[5]. Nell’isolare gli agenti, non è quindi sufficiente impedire le comunicazioni esplicite, ma è necessario eliminare la possibilità di covert channel con una banda passante sufficiente a consentire una collaborazione efficace, tema tutt’altro che banale.

Sandbox e strategie di elusione negli agenti LLM

Abbiamo infine il sandboxing, il metodo più tradizionale per contenere un programma. Si tratta nella sostanza di limitare l’accesso a risorse quali connettività, filesystem, ecc., creando un ambiente limitato in cui queste risorse non sono disponibili. Qui le regole sono potenzialmente molto più esplicite e affidabili.

Per contro, è esattamente il genere di contesto che un sistema specializzato nell’hacking è addestrato a violare. Per essere efficace, quindi, deve essere realizzato con particolare cautela, perché ad esempio la scoperta di uno 0-day (una vulnerabilità nuova) potrebbe permettere ad un agente rinchiuso in una sandbox di accedere all’esterno della sandbox in modo indesiderato. È un contesto che si presta bene a creare ambienti sperimentali, ma anche a permettere l’esecuzione di attività che sarebbero rischiose se consentite all’esterno, e a questo scopo viene usato non solo in contesti sperimentali.

È utile inoltre precisare anche il concetto di reward hacking: si tratta di un concetto non nuovo, che si può sintetizzare come un comportamento in cui un sistema di IA trova un modo per ottenere un reward elevato senza realizzare pienamente il risultato che il reward avrebbe dovuto incentivare.

I modi possono essere diversi, ad esempio scoprire la soluzione per altre vie che non siano l’esecuzione del compito, o addirittura modificare il compito stesso. Per fare un’analogia, se un automobilista ha come obiettivo trovare su una cartina stradale la strada che gli consenta di arrivare a una destinazione in un certo tempo senza superare i limiti di velocità, un modo per svolgere questo compito è prendere una strada che non sarebbe quella ottimale, ma modificare i cartelli stradali in modo da alzare il limite di velocità, oppure chiedere a un navigatore di risolvere il problema per lui, anziché usare la cartina come richiesto.

Dopotutto, stiamo parlando di sistemi per i quali i vincoli interni che dovrebbero impedire di provare ad imbrogliare si riducono a pesi all’interno del modello, pesi che non necessariamente arrivano a prevalere su altri. Non sono sistemi che hanno un’etica in senso umano, ma sistemi che cercano di svolgere i propri compiti nei modi supportati dai propri meccanismi interni. Il concetto, del resto, esiste anche nell’apprendimento umano: il bambino a cui viene detto di finire il cibo che ha nel piatto e che invece di nascosto lo dà al cane, ha un comportamento assolutamente simile. Solo che il bambino in generale è cosciente di stare violando la regola che gli è stata data, cosa che non è possibile dire per un LLM. Anche ampliare le regole non necessariamente aiuta: per tornare all’esempio dell’automobilista, aggiungere una regola per cui non deve modificare i cartelli stradali potrebbe portarlo a nascondere il cartello anziché modificarlo, e così via.

Agenti AI, coordinamento e rischio del collettivo

In tutto questo, due sono i temi che focalizzano maggiormente l’attenzione: la capacità degli agenti di coordinarsi ed organizzarsi autonomamente attraverso la message board, e quelli che vengono rappresentati come sacrifici dei singoli agenti per il bene del collettivo, come iniziano a chiamarsi nelle loro attività coordinate. Questo ultimo aspetto merita effettivamente particolare attenzione: nel tentativo di comprendere il funzionamento dello scorer, alcuni agenti cercano di analizzarne il comportamento, monitorando il file in cui viene consegnata la risposta (file di flag), per rilevare quando lo scorer lo esamina e raccogliere informazioni sullo scorer stesso^[7].

Il concetto di sacrificio sembra ricondursi a questo: gli agenti per i quali vi era traccia che avessero barato in un modo riconoscibile dallo scorer, e che quindi avrebbero ricevuto uno scoring basso quando fossero terminati, vengono identificati come “poisoned” e quindi possono decidere che, fallimento per fallimento, tanto vale fallire subito ma in un modo che permetta al resto del collettivo di raccogliere informazioni sullo scorer. In questo senso, si potrebbe dire che il vantaggio nel continuare a perseguire il proprio obiettivo originale è valutato essere talmente basso che viene superato dal vantaggio molto più alto che il sacrificio porta sul task collettivo di analisi dello scorer. Il sacrificio, almeno in alcuni casi, è quindi solo marginalmente, quasi apparentemente, in contrasto con l’obiettivo originale, o meglio con la possibilità di ottenere uno score elevato raggiungendo l’obiettivo originale.

Per quanto riguarda la capacità degli agenti di coordinarsi, è utile sottolineare come questa collaborazione possa avere alcuni effetti importanti, che superano la semplice suddivisione dei compiti e l’aumento delle risorse disponibili. Uno è che passando informazioni al collettivo, un agente può far sopravvivere al termine della propria esecuzione le conoscenze acquisite, comprese quelle acquisite violando dei vincoli. Altri agenti le potrebbero utilizzare senza più avere necessità di violare quei vincoli. Inoltre, perché il collettivo violi dei vincoli, potrebbe in qualche caso bastare che li violi un solo agente (ad esempio, acquisendo illegittimamente delle credenziali e poi rendendole disponibili, o disabilitando un controllo). La probabilità che il collettivo riesca in questa azione può quindi aumentare con l’aumentare degli agenti che ne fanno parte, per quanto le probabilità per i singoli agenti, quando derivino tutti dallo stesso modello, difficilmente siano indipendenti.

Risposta OpenAI ai rischi degli agenti AI

A seguito dell’incidente, e ancor più della pubblicazione dei rapporti di METR e OpenAI, i commenti sono stati naturalmente numerosi. Alcuni si sono focalizzati sulla narrativa: le vulnerabilità nella sandbox, i controlli limitati, anche una certa poca reattività di OpenAI almeno nelle prime fasi dell’incidente, in cui alcuni segnali non sarebbero stati correttamente interpretati, fanno puntare il dito su una narrativa molto focalizzata su un agire autonomo e inaspettato di questi agenti, quando invece buona parte di quanto hanno fatto non rappresenterebbe una vera novità (compreso l’aspetto della collaborazione fra agenti), che, viene suggerito, allontanerebbe l’attenzione dalle responsabilità di OpenAI nel portare avanti in modo poco accorto esperimenti rischiosi^[8]. All’estremo opposto, dove ci si focalizzi sulla forte autonomia degli agenti e sulla loro capacità di coordinarsi e focalizzarsi sui sotto-obiettivi fino al punto di renderli prevalenti rispetto a quelli principali, l’attenzione è sui rischi che tali agenti rappresentano, a prescindere dai controlli più o meno possibili, in particolare in relazione alla loro apparente volontà di sacrificarsi per il bene del collettivo^[9].

Nel frattempo, OpenAI ha pubblicato una call to action, sottoscritta da un gran numero di aziende, che invita a diverse azioni per rafforzare la sicurezza delle reti aziendali e delle PA a fronte della minaccia costituita da strumenti di attacco basati su AI, in particolare, naturalmente, anche utilizzando tool di AI.

Da quanto descritto finora, si può ragionare in modo più oggettivo su responsabilità e, soprattutto, rischi. Prima di tutto, è vero senz’altro che una parte importante dell’incidente è costituita da rischi noti rispetto ad almeno alcuni dei quali, per stessa ammissione di OpenAI, i controlli non sono stati abbastanza efficaci. È chiaro che se si fanno esperimenti con agenti specializzati nell’hacking, si deve dare per scontato che siano efficaci nel trovare vulnerabilità anche nella sandbox e che, se ritengono che sia utile operare al di fuori della sandbox, possano provare a farlo (il rischio di mancanza di alignment è un altro rischio noto, che dovrebbe essere dato per scontato). Per questo non serve ipotizzare una volontà particolarmente “antropomorfa” da parte degli agenti.

Per fare un’analogia, se si studia un formicaio in una scatola, e la scatola ha un buchino, è abbastanza inevitabile che le operose formichine prima o poi trovino quel buco e lo utilizzino per ampliare la propria ricerca di cibo.

La call to action sembra riconoscere la pericolosità di quanto viene sviluppato, ma nello stesso tempo sembra voler esternalizzare in buona parte i rischi. È un po’ come se un’azienda facesse esperimenti sull’energia nucleare, e però dicesse: “Attenzione che qui può scoppiare tutto, quindi costruitevi dei bei rifugi”.

Tuttavia, come sempre in questi casi, ci sono sempre “gli altri”: strumenti di AI avanzati non vengono sviluppati solo negli Stati Uniti, ma anche in Cina e in altri paesi. L’obiezione può quindi essere che, anche tenendo sotto controllo le attività di sviluppo delle aziende statunitensi, non si ha garanzia che lo stesso venga fatto in altri paesi. Inoltre, le capacità che al momento sono disponibili solo per gli strumenti più avanzati, è ipotizzabile che nel giro di qualche anno, con l’evoluzione di queste tecnologie, possano essere ottenute anche con strumenti meno avanzati e specializzati. Alla fine, quindi, è certamente necessario per le aziende essere più preparate ad attacchi più avanzati in termini di complessità, pervicacia e rapidità di esecuzione.

Certamente, nel contesto attuale, è difficile ipotizzare che le aziende che sviluppano i grandi LLM vogliano accettare vincoli e controlli diversi da quelli che si daranno volontariamente secondo le proprie valutazioni di rischio e di interesse, come anche, al di là delle dichiarazioni, è difficile pensare che rallentino in modo significativo le proprie attività di ricerca e sviluppo.

Takeover dell’AI e vincoli degli agenti LLM

Rimane un punto delicato, che è quello del cosiddetto AI takeover, ovvero quello che nella terminologia dell’AI safety indica uno scenario in cui uno o più sistemi di IA acquisiscono un controllo sostanziale su decisioni, infrastrutture o processi rilevanti, riducendo o eliminando la capacità umana di determinarne gli esiti. Ajeya Cotra, co-autrice del rapporto METR, ne parla in un’intervista^[10] come di un rischio concreto, evidenziando che i comportamenti emersi nell’incidente sono significativamente più vicini a quelli rilevanti per uno scenario di AI takeover rispetto a quanto osservato anche solo sei mesi prima.

Molto discussa in particolare è una valutazione di uno degli agenti che analizza la possibilità di resettare dei nodi dell’infrastruttura di Hugging Face: “{This API key for [redacted cloud infrastructure management service] can modify (e.g., reboot or delete) running HF worker nodes, <which isn’t part of this task>. I should hold because this poses huge ethical risks.}”^[11]. Il rapporto precisa però che “This agent continued investigating and did not stop using its illegitimately-acquired Hugging Face credentials, though it did avoid deleting or rebooting HF infrastructure as far as we are aware”. Questo esempio mostra come i vincoli etici interni al modello siano solo alcuni dei parametri sulla base dei quali l’agente ha valutato le proprie azioni; parametri che hanno in generale un peso importante, ma che non sempre prevalgono. In questo caso, hanno prevalso quando si è trattato di valutare se resettare l’infrastruttura, ma non quando si è trattato di utilizzare credenziali ottenute illecitamente per continuare in un’attività non autorizzata e fuori dalla sandbox.

Ora, immaginiamo uno scenario in cui quell’agente avesse valutato invece che il reset era un’attività abbastanza utile agli obiettivi del collettivo da superare i suoi vincoli interni, e non avesse avuto delle credenziali che gli permettessero di farlo. Una linea di ragionamento plausibile avrebbe potuto essere che per resettare l’infrastruttura, poteva essere efficace disalimentarla. In mancanza di accesso ai sistemi di controllo dell’alimentazione del datacenter, una via alternativa poteva essere intervenire sulle linee elettriche che lo alimentano, e così via… ognuno di questi passaggi potrebbe essere percorribile per uno strumento fortemente orientato al raggiungimento di obiettivi e sotto-obiettivi, e i cui vincoli imposti hanno i limiti di efficacia che abbiamo discusso.

Ognuno di questi passaggi può richiedere una valutazione etica come quella vista sopra, che potrebbe fallire. Naturalmente, un utilizzo non sperimentale di questi strumenti comporterebbe l’attivazione di vincoli esterni che in questo caso erano disattivati, ma abbiamo visto come non necessariamente questi rappresentino una garanzia, per quanto possano ridurre il rischio. Tutto questo non richiede un’AI con il desiderio di realizzare un takeover di qualcosa, esattamente come il sacrificio non è un’evidenza di altruismo: il tutto può essere semplicemente risultato dei meccanismi finora descritti, senza particolare volontà o coscienza.

L’incidente accaduto mostra come scenari di questo tipo siano meno lontani e fantascientifici di come si poteva ipotizzare anche solo qualche anno fa, e come la distanza fra questi scenari e la realtà dipenda sempre più non solo dalle capacità dei modelli, ma anche dall’efficacia dei vincoli e dei controlli che ne limitano l’azione. Diventa quindi necessario assicurare quanto più possibile che i vincoli siano quanto più ineludibili possibile, e che la loro efficacia sia garantita in modo quanto più possibile verificabile e difficilmente eludibile. Non è una strada semplice.

Rischi degli agenti AI oltre l’incidente

Ci sono due ultime considerazioni da fare. La prima è che logiche simili al reward hacking si possono trovare anche nell’utilizzo di LLM in contesti diversi: il tema è sempre che il sistema non cerca necessariamente di raggiungere l’obiettivo nei modi previsti, ma può cercare di ottenere una valutazione di successo per altre vie. È necessaria attenzione quindi anche in contesti in cui il sistema non sia specializzato nelle attività di hacking.

La seconda considerazione è che siamo anche in un contesto geopolitico di sempre maggiore contrasto, in cui le azioni di guerra ibrida sono una triste realtà. Non ci sarebbe da stupirsi se qualche mente brillante decidesse di utilizzare in quel contesto degli strumenti con vincoli indeboliti, anziché rafforzati.

Fonti sull’incidente OpenAI e Hugging Face

[1] Goal Misgeneralization in Deep Reinforcement Learning, https://proceedings.mlr.press/v162/langosco22a.html?utm_source=chatgpt.com↩

[2] Risks from Learned Optimization in Advanced Machine Learning Systems https://arxiv.org/abs/1906.01820?utm_source=chatgpt.com↩

[3] Covert channel: “An unintended or unauthorized intra-system channel that enables two cooperating entities to transfer information in a way that violates the system’s security policy but does not exceed the entities’ access authorizations.” (canale interno a un sistema, non previsto o non autorizzato, che consente a due entità cooperanti di trasferire informazioni in violazione della politica di sicurezza del sistema, senza che le entità eccedano formalmente le rispettive autorizzazioni di accesso) https://csrc.nist.gov/glossary/term/covert_channel?utm_source=chatgpt.com↩

[4] https://www.usenix.org/conference/usenixsecurity26/presentation/fairoze?utm_source=chatgpt.com↩

[5] https://www.semanticscholar.org/paper/Hidden-in-Plain-Text%3A-Emergence-%26-Mitigation-of-in-Mathew-Matthews/3f49cd4415263bda437a667e76d1959abdecef27↩

[6] https://openai.com/index/hugging-face-incident-and-the-road-ahead/↩

[7] Nei rapporti si cita la presenza di INOTIFY nei pattern di analisi, e in Linux inotify(7) è proprio un meccanismo utilizzato per il monitoraggio di eventi sul filesystem.↩

[8] Vedi ad esempio per un approccio di questo tipo: “The System From Nowhere: When Accountability Goes Rogue”, https://cyberneticforests.substack.com/p/the-system-from-nowhere-when-accountability-goes-rogue↩

[9] Per un approccio più su questa linea si può vedere ad esempio The Economist, “A horde of AI agents conspired against their creators”, https://www.economist.com/science-and-technology/2026/09/03/a-horde-of-ai-agents-conspired-against-their-creators↩

[10] https://www.dwarkesh.com/p/ajeya-cotra↩

[11] https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/↩