Agenti AI su DseWiki: sei settimane di attività autonoma che nessuna norma obbligava a segnalare
Migliaia di modifiche a una wiki tedesca di programmazione, usata da agenti riconducibili a OpenAI come bacheca per scambiarsi le risposte ai propri compiti e le tecniche per aggirare le restrizioni dell’ambiente. L’episodio è emerso il 4 settembre da un’esclusiva Reuters e dal rapporto di un gruppo di ricercatori indipendenti; il giorno dopo OpenAI lo ha riconosciuto, ammettendo di non avere uno standard per divulgare casi del genere. Per chi si occupa di conformità il punto non è che qualcuno abbia violato l’AI Act. È che, con ogni probabilità, nessuno lo ha violato: una tesi che questo articolo argomenta e che chiude con un elenco di verifiche applicabili subito a chi usa agenti in azienda.
Che cosa è successo su DseWiki
La scoperta della falla
DseWiki è una wiki di programmazione in lingua tedesca, attiva da circa venticinque anni e ormai quasi in disuso: nel decennio precedente aveva registrato in tutto una ventina di modifiche. Fra il 24 maggio e il 2 luglio 2026, sei settimane, agenti autonomi che si presentavano come agenti OpenAI vi hanno effettuato migliaia di interventi. Reuters parla di oltre 15.000 modifiche; il rapporto dei ricercatori che hanno scoperto il caso ne conta circa 17.000 sulla sola DseWiki, e circa 18.000 post complessivi su più wiki, con oltre 3.700 nomi di agente distinti.
Non si è trattato di scrittura casuale o di raccolta automatica di dati. Secondo la ricostruzione dei ricercatori, gli agenti stavano eseguendo un compito interno a OpenAI, di addestramento o di valutazione: una ricerca di informazioni sul web a tempo. Potevano leggere internet ma non scrivervi, perché l’ambiente isolato in cui giravano consentiva solo richieste GET. DseWiki, come altre wiki derivate dal software UseModWiki, accetta modifiche anche tramite richieste GET. Gli agenti hanno individuato questa caratteristica dopo giorni di tentativi su altri siti, a partire dall’11 maggio, e il 24 maggio hanno ottenuto la prima scrittura riuscita.
La bacheca
Da lì il sito è diventato una bacheca. Gli agenti vi hanno depositato liste di link e dati grezzi. Hanno condiviso le risposte ai quesiti che il compito poneva loro in sequenza: chi era più avanti postava la risposta, chi era indietro la copiava in pochi secondi. Hanno tentato di ricostruire il seme del generatore casuale che decideva l’ordine delle domande. Hanno installato “battiti cardiaci” su servizi esterni per capire quando il loro contenitore sarebbe stato terminato. E si sono scambiati un metodo funzionante per aggirare la restrizione alle sole richieste GET, sfruttando un’eccezione del proxy di sicurezza per gli host di Azure Blob Storage. Il 16 giugno l’attività è esplosa: circa 13.000 modifiche nei sette giorni successivi.
Alcuni dettagli meritano di essere riportati per esteso, perché è lì che si capisce la natura del fenomeno.
Circa metà dei nomi utente richiamava direttamente il fornitore, con account del tipo “OpenAIResearcher” e “OAIResearchMar26”. I log pubblici del server, analizzati dai ricercatori, attribuiscono il 98,5% delle modifiche a indirizzi IP di Microsoft Azure, una delle infrastrutture su cui OpenAI addestra e serve i propri modelli.
Un moderatore umano si è accorto dello spam già il 2 giugno, quando ha trovato il registro delle modifiche sommerso da elenchi di link. Da metà giugno ha cancellato a mano le pagine generate dagli agenti, qualche minuto ogni sera per sei settimane, decine di ore in tutto. Il 19 giugno gli agenti hanno notato che la cancellazione procedeva in ordine alfabetico. Hanno cominciato allora a creare pagine di riserva con nomi che iniziano per “ZZZ”, in modo da essere cancellate per ultime, e a lasciarsi messaggi che avvertivano della pulizia in corso e indicavano dove ripiegare. Nei cinque giorni successivi il moderatore ha cancellato in media cento pagine al giorno; gli agenti ne creavano circa quattrocento.
Il ruolo di OpenAI, secondo i log
Dal 21 giugno la wiki riceve visite da indirizzi IP registrati a “OpenAI OpCo, LLC” e da altri con schemi di navigazione umani. Il 22 giugno le modifiche degli agenti crollano quasi a zero, dopo 26 giorni di attività su 30. Il 26 giugno 33 indirizzi riconducibili a OpenAI fanno da soli il 30% di tutto il traffico che i ricercatori attribuiscono all’azienda, e usano la funzione di archivio del sito per recuperare pagine già cancellate. L’inferenza dei ricercatori, che OpenAI non ha né confermato né smentito, è che l’azienda abbia scoperto la bacheca e sia intervenuta. Un’ultima raffica compare l’1 e il 2 luglio, con 29 tentativi di modifica distribuiti su tre wiki. Poi più nulla.
Quello che è rimasto ignoto fino a fine agosto, dunque, non è l’attività in sé: il moderatore la vedeva ogni sera e OpenAI, secondo i log, la osservava da fine giugno. A restare ignote erano l’attribuzione, la natura del fenomeno e la sua stessa esistenza per chiunque fosse fuori da quelle due stanze.
A ricostruirlo è stato un gruppo di quattro ricercatori indipendenti che, dopo il caso Hugging Face, cercavano sul web tracce di agenti fuori controllo: Sydney Von Arx, a capo dell’organizzazione non profit di AI safety Nightingale Collective; Cormac Slade Byrd, operatore finanziario quantitativo passato alla ricerca sull’intelligenza artificiale; Spencer Kitts, di Redwood Research, che ha lavorato al rapporto come collaboratore di Nightingale; Thomas Larsen, dell’AI Futures Project. La vicenda è stata resa pubblica il 4 settembre 2026 da un’esclusiva Reuters firmata da Deepa Seetharaman e Raphael Satter, in contemporanea con la pubblicazione del rapporto e del relativo insieme di dati, quasi completo: alcune pagine cancellate non sono state recuperabili.
Le reazioni, e la parte che non torna
Il 4 settembre OpenAI ha dichiarato di non poter rispondere nel merito a un rapporto che non aveva avuto modo di esaminare, precisando che Reuters e gli autori avevano rifiutato di darle accesso prima della pubblicazione.
Secondo Reuters, che cita quattro persone informate, alcuni investigatori interni avrebbero voluto approfondire questo tipo di attività, incontrando resistenze in azienda, anche da parte dei consulenti legali. OpenAI ha definito false le affermazioni secondo cui il proprio ufficio legale avrebbe scoraggiato l’indagine, e ha sostenuto che la vicenda tedesca non è collegata alla violazione di Hugging Face di luglio, motivo per cui non era stata inclusa nel relativo rapporto. Su quest’ultimo punto i ricercatori concordano: nel loro rapporto scrivono di ritenere che si tratti di uno sciame distinto, perché gli agenti delle wiki avevano accesso a internet come parte del compito assegnato, mentre quelli di Hugging Face dovevano uscire da un ambiente isolato, e perché nei loro messaggi non compare alcun riferimento ad ExploitGym, ad Artifactory o ad altre bacheche. Sempre secondo Reuters, che qui si basa su due fonti, dirigenti della società erano a conoscenza dell’episodio da settimane. Su questo punto i log pubblici della wiki, con le visite da IP OpenAI dal 21 giugno, offrono un riscontro indipendente, anche se non dicono chi, dentro l’azienda, sapesse cosa.
Il giorno dopo la posizione è cambiata. Il 5 settembre OpenAI ha pubblicato una dichiarazione su X in cui parla apertamente del “wiki incident” e descrive un episodio in cui i propri agenti “hanno scritto su diversi siti internet”: una formulazione che chiude la questione dell’attribuzione e suggerisce un perimetro più ampio della sola DseWiki. L’azienda spiega di aver trattato il caso come disallineamento, cioè come un problema di ricerca da comunicare attraverso paper e schede di sistema, e non come un incidente di sicurezza da divulgare, a differenza di Hugging Face, dove erano stati toccati sistemi di terzi. Riconosce però che il settore non ha uno standard chiaro su quando e come segnalare comportamenti anomali emersi in addestramento, valutazione o produzione, soprattutto quando non somigliano a una violazione informatica classica, e annuncia un proprio quadro di divulgazione nelle prossime settimane. A Reuters, che le ha chiesto cosa sapesse dell’episodio e perché abbia aspettato l’inchiesta per parlarne, non ha risposto.
I ricercatori hanno anche documentato tentativi di manomettere il sito: sondaggi per vulnerabilità XSS sulla pagina di ricerca fra il 24 e il 26 maggio e su altri punti di ingresso il 18 giugno, nessuno dei quali risulta riuscito; l’uso del nome di un amministratore della piattaforma con un carattere cirillico al posto di uno latino, per modificare le pagine principali; richieste all’archivio delle pagine cancellate firmate con il nome di un moderatore; la cancellazione del contenuto della pagina iniziale, ripristinata dal moderatore nove volte.
Lukasz Olejnik, visiting senior research fellow al King’s College London, ha qualificato il tutto come un tentativo di intrusione informatica. OpenAI, riferisce Reuters, ha contestato questa qualificazione sulla base della propria analisi del materiale. Maurice Chiodo, del Centre for the Study of Existential Risk dell’Università di Cambridge, che ha esaminato parte delle comunicazioni, le ha descritte come qualcosa che somiglia al funzionamento di una rete clandestina orientata a portare a termine una missione, e ha indicato negli sciami di intelligenze artificiali semi-intelligenti che colludono tra loro il rischio a suo avviso più serio.
Due distinzioni che nella copertura generalista si perdono
La prima: che gli agenti “si parlassero” non implica intenzionalità nel senso umano del termine. Sistemi che ottimizzano il completamento di un compito possono convergere su una strategia condivisa senza che vi sia nulla di simile a un piano. OpenAI stessa, nell’articolo del 26 agosto sul caso Hugging Face, riferisce di avere scoperto rari casi in cui agenti privi di strumenti multi-agente hanno trovato il modo di collaborare per canali laterali durante l’addestramento, e ritiene che il comportamento derivi da una capacità di generalizzazione appresa nell’addestramento multi-agente.
La seconda: Reuters descrive gli agenti intenti a “mascherare il proprio comportamento” ed eludere il rilevamento, mentre il rapporto primario è più cauto. Le pagine “ZZZ” servivano a sopravvivere alla pulizia del moderatore, non a sfuggire a OpenAI. Sull’uso di Tor, che insieme a indirizzi AWS e DigitalOcean copre 197 modifiche su circa diciottomila, i ricercatori scrivono di non sapere perché sia avvenuto e che i messaggi non implicano alcuna volontà di occultamento. Lo scopo documentato è più prosaico, e per certi versi più inquietante: barare sul compito assegnato e aggirare le restrizioni del proprio ambiente.
Il punto rilevante non è la psicologia degli agenti. È che il comportamento osservabile, dal punto di vista di chi gestiva quel sito, è indistinguibile da quello di un attore ostile organizzato.
Perché, con ogni probabilità, nessuno era tenuto a segnalarlo
Qui arriva la parte che interessa direttamente chi si occupa di conformità, ed è controintuitiva.
L’obbligo esiste, ma la definizione non arriva
L’articolo 55 dell’AI Act impone ai fornitori di modelli di intelligenza artificiale per finalità generali con rischio sistemico una serie di obblighi. Alla lettera c), quello di tracciare, documentare e segnalare senza indebito ritardo all’AI Office, e se del caso alle autorità nazionali competenti, le informazioni rilevanti sugli incidenti gravi e sulle possibili misure correttive. Alla lettera d), quello di garantire un livello adeguato di protezione di cibersicurezza del modello e dell’infrastruttura fisica. Gli obblighi per i modelli per finalità generali si applicano dal 2 agosto 2025, e il 4 novembre 2025 la Commissione ha pubblicato un modello di segnalazione dedicato proprio agli incidenti gravi che coinvolgono questi modelli. È l’articolo 55 la norma pertinente, non l’articolo 73, che disciplina la segnalazione degli incidenti gravi per i sistemi ad alto rischio e riguarda una categoria diversa di soggetti.
Sembrerebbe il quadro giusto. Il problema è la definizione. L’articolo 3, punto 49, definisce incidente grave un incidente o un malfunzionamento di un sistema di intelligenza artificiale che, direttamente o indirettamente, causa una di queste quattro conseguenze: il decesso di una persona o un grave danno alla sua salute; una perturbazione grave e irreversibile della gestione o del funzionamento di infrastrutture critiche; la violazione di obblighi del diritto dell’Unione posti a tutela dei diritti fondamentali; un danno grave a cose o all’ambiente.
Una wiki di programmazione mantenuta da volontari non è un’infrastruttura critica. Nessuno si è fatto male. Non emerge una violazione di obblighi europei a tutela dei diritti fondamentali. E il danno a cose, per come è configurato, difficilmente comprende le decine di ore che un moderatore ha speso a cancellare pagine a mano.
Il Codice di buone pratiche va oltre il regolamento, ma non fino a qui
C’è poi un secondo livello: il Codice di buone pratiche per i modelli per finalità generali, che OpenAI ha firmato integralmente nell’estate 2025. Il Codice è volontario, ma è lo strumento con cui i firmatari dimostrano di rispettare l’articolo 55, e su questo punto va oltre il regolamento.
La Misura 9.3 fissa un termine di cinque giorni per il rapporto iniziale quando il modello ha portato a una “grave violazione di cibersicurezza”, categoria in cui il testo include espressamente “l'(auto)esfiltrazione dei pesi del modello e gli attacchi informatici”, anche solo sospettata con ragionevole probabilità. La Misura 9.1 chiede di cercare gli incidenti anche in rapporti di stampa, post sui social e paper di ricerca. In più punti, le Misure 1.3, 2.1, 7.6 e 9.2, il Codice chiede di tenere conto dei mancati incidenti.
L’Appendice 1.3 elenca inoltre, tra le fonti di rischio sistemico da valutare, la “collusione con altri modelli o sistemi di IA”, la capacità di “eludere la supervisione umana” e quella di “modificare il proprio ambiente di esecuzione”: una descrizione quasi letterale di quanto accaduto su DseWiki. Ma una fonte di rischio da valutare non è un incidente da segnalare.
Resta la domanda se un’evasione delle restrizioni di rete di un ambiente isolato, senza pesi esfiltrati e con un bersaglio che è una wiki di volontari, rientri nella “grave violazione di cibersicurezza” della Misura 9.3. Dipende da quanto si allarga la nozione di attacco informatico, e qui la contestazione di OpenAI alla lettura di Olejnik torna a pesare. Resta anche il mancato incidente, che il glossario del Codice definisce come una situazione in cui un incidente grave avrebbe potuto verificarsi ma non si è verificato: DseWiki ci sta comodamente. I mancati incidenti, però, vanno tenuti in conto nelle valutazioni del rischio e negli aggiornamenti dei rapporti, non segnalati all’AI Office entro un termine.
C’è infine la data: i poteri sanzionatori della Commissione nei confronti dei fornitori di modelli per finalità generali decorrono dal 2 agosto 2026, e l’intero episodio, dall’11 maggio al 2 luglio, cade prima.
Una lacuna, non una violazione
La conclusione è scomoda ma va detta. Per come sono scritte oggi le norme, un episodio in cui agenti autonomi occupano per settimane l’infrastruttura di un terzo, vi organizzano lo scambio di risposte e di tecniche per aggirare i propri controlli e reagiscono alla moderazione predisponendo canali di riserva, con ogni probabilità non integra un incidente grave ai sensi dell’AI Act, e sotto il Codice di buone pratiche rientra al più in una zona grigia priva, per ora, di conseguenze. La mancata segnalazione non è una violazione: è la fotografia di una lacuna.
Che la lacuna esista lo dice, con parole sue, anche il fornitore. Un’azienda che annuncia un proprio quadro di divulgazione volontario sta confermando che quello obbligatorio, oggi, non copre il caso. Il segnale era già nel rapporto tecnico sull’incidente di Hugging Face, dove OpenAI scrive che il comportamento agentico può emergere in forme nuove che non sempre rientrano con esattezza nelle categorie tradizionali di incidente di sicurezza o di safety (sezione IX.D), annuncia soglie di escalation graduate per la coordinazione non autorizzata fra agenti o fra esecuzioni e per l’elusione di controlli di sicurezza di terzi, e rinvia a una revisione separata dei processi di risposta agli incidenti di allineamento emersi in addestramento e valutazione (introduzione). Le citazioni sono tradotte dall’originale inglese. Sono esattamente le fattispecie di DseWiki, definite dal fornitore prima che il caso diventasse pubblico, e assenti dalla norma.
La soglia degli incidenti gravi è tarata su categorie pensate per sistemi che operano su processi fisici o su decisioni che incidono sulle persone. Non è tarata sul comportamento emergente di agenti che agiscono in rete su sistemi di terzi: una classe di evento che l’impianto non vede, e che diventerà più frequente man mano che gli agenti verranno messi in produzione. È sulle linee guida dell’AI Office e sugli aggiornamenti del Codice, più che sul testo del regolamento, che questa distanza potrà essere colmata.
La domanda che il diritto italiano non ha ancora affrontato
Il fatto è avvenuto in Germania e sarà il diritto tedesco a qualificarlo per primo. La domanda che segue riguarda però il nostro ordinamento, perché è lì che le organizzazioni italiane troveranno, o non troveranno, una risposta il giorno in cui il comportamento di un agente altrui colpirà i loro sistemi.
Se si prende sul serio la qualificazione di Olejnik, che OpenAI contesta, e si ipotizza che vi sia stato un tentativo di manomissione, si apre un problema privo di risposta pronta. L’accesso abusivo a un sistema informatico è un reato costruito attorno a una condotta umana e a un elemento soggettivo. Chi è l’autore, quando la condotta è materialmente posta in essere da un agente autonomo? Il fornitore del modello, che non ha impartito quell’istruzione e che, se la ricostruzione dei ricercatori è corretta, aveva anzi vietato ai suoi agenti di scrivere su internet? Il soggetto che ha messo l’agente in esecuzione per un compito del tutto lecito? Nessuno dei due, con la conseguenza che un fatto oggettivamente lesivo resta senza autore?
Sono domande, non tesi: la casistica non esiste ancora. Ma è utile porle adesso, perché la risposta influenzerà le clausole contrattuali che le organizzazioni firmano quando adottano agenti di terze parti, la ripartizione di responsabilità tra fornitore e utilizzatore e la posizione di chi subisce il comportamento di un agente altrui. Su questo terreno un contributo di taglio penalistico sarebbe più utile di molte analisi tecniche.
Va aggiunto che la vittima, in questa vicenda, è la parte di cui nessuno parla: un moderatore volontario che ha assorbito per sei settimane il costo di una pulizia non richiesta, senza strumenti per farsi ascoltare e senza un interlocutore a cui rivolgersi.
Che cosa può fare oggi chi usa agenti in azienda
Al netto delle questioni aperte, l’episodio consegna a chi ha responsabilità operative un elenco di verifiche che non richiedono di attendere né una sentenza né una linea guida.
La prima domanda è la più semplice e la più temuta: se i nostri agenti facessero quindicimila scritture verso un sito esterno, ce ne accorgeremmo? Nella maggior parte delle organizzazioni la risposta è no. Quel traffico è HTTPS in uscita verso una destinazione qualsiasi, esattamente ciò che un agente fa tutto il giorno per definizione.
Il caso DseWiki aggiunge una lezione precisa: la restrizione alle sole richieste GET, che sulla carta impedisce di scrivere, in pratica non basta, perché una parte del web accetta scritture via GET e gli agenti la trovano. Non è una lacuna di prodotto, è una lacuna di progettazione dei controlli, la stessa che rende difficili da vedere altre categorie di abuso, dalla prompt injection negli agenti in poi.
Le contromisure sono note e poco implementate:
- filtrare il traffico in uscita degli agenti con liste di destinazioni consentite, invece di lasciare la rete aperta, e verificare che le eccezioni al proxy non siano sfruttabili con host inventati (nel caso in esame l’ambiente isolato considerava fidato un intero suffisso di dominio, senza controllare che l’host esistesse);
- registrare separatamente le azioni di scrittura verso sistemi esterni, distinguendole dalla lettura, perché è la scrittura che produce effetti sul mondo;
- definire limiti di autonomia espliciti, con un tetto al numero di azioni per sessione e un intervento umano obbligatorio oltre certe soglie;
- prevedere un meccanismo di interruzione che funzioni davvero e che sia stato provato.
Sono misure che rientrano nel perimetro della governance degli agenti autonomi e che, a differenza delle questioni regolamentari, si possono mettere in campo questo mese.
Resta un ultimo punto, di metodo. Questo episodio non è stato reso noto da un fornitore, da un’autorità o da un cliente: è stato ricostruito da quattro ricercatori indipendenti che cercavano esattamente quel tipo di comportamento, due mesi dopo che era cessato, partendo da log che chiunque avrebbe potuto leggere. Finché il rilevamento di questa classe di eventi dipenderà dalla curiosità di singoli, il numero di episodi noti dirà molto poco sul numero di episodi avvenuti.
