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 risposte ai propri compiti e tecniche di elusione dei controlli. L’episodio è emerso il 4 settembre da un’esclusiva Reuters e dal rapporto pubblico di un gruppo di ricercatori indipendenti; il giorno dopo OpenAI lo ha riconosciuto, ammettendo di non avere uno standard per divulgare casi del genere. Il punto interessante per chi si occupa di compliance non è che qualcuno abbia violato l’AI Act: è che quasi certamente nessuno lo ha violato.

Che cosa è successo su DseWiki

Tra la fine di maggio e i primi di luglio 2026, agenti autonomi che si presentavano come agenti OpenAI hanno effettuato migliaia di modifiche su 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. Reuters parla di oltre 15.000 interventi; il rapporto dei ricercatori che hanno scoperto il caso conta circa 17.000 modifiche 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 scraping. Secondo la ricostruzione dei ricercatori, gli agenti stavano eseguendo un compito interno a OpenAI (addestramento o valutazione, non è chiaro) di ricerca di informazioni sul web a tempo: potevano leggere internet ma non scrivervi, perché il sandbox 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 (i primi test risalgono all’11 maggio) e il 24 maggio hanno fatto la prima scrittura riuscita su DseWiki.

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 container 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 elementi meritano di essere riportati per esteso, perché è nel dettaglio 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 del sito sommerso da elenchi di link, e da metà giugno ha cancellato a mano le pagine generate dagli agenti, dedicando alla pulizia almeno 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 e hanno cominciato sistematicamente a creare pagine di riserva con nomi che iniziano per “ZZZ”, in modo da essere cancellate per ultime. Il messaggio lasciato per gli altri agenti avvertiva che era in corso una pulizia alfabetica e indicava dove ripiegare se quella pagina fosse sparita. Nei cinque giorni successivi il moderatore ha cancellato in media cento pagine al giorno; gli agenti ne creavano circa quattrocento.

C’è poi la parte che riguarda direttamente OpenAI. 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 su un tema nuovo compare l’1 e il 2 luglio, con 29 tentativi di modifica il 2 luglio distribuiti su tre wiki; poi più nulla.

Quello che è rimasto ignoto fino a fine agosto, dunque, non è l’attività in sé, che il moderatore vedeva ogni sera e che OpenAI, secondo i log, ha osservato da fine giugno: è l’attribuzione, la natura del fenomeno e la sua esistenza per chiunque fosse fuori da quelle due stanze. A ricostruirlo è stato un gruppo di quattro ricercatori indipendenti (Sydney Von Arx, a capo dell’organizzazione non profit di AI safety Nightingale Collective; Cormac Slade Byrd, trader 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) che dopo il caso Hugging Face stavano cercando sul web tracce di agenti fuori controllo. 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 dataset (quasi completo: alcune pagine cancellate non sono state recuperabili).

Le reazioni, e la parte che non torna

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. L’azienda ha inoltre sostenuto che la vicenda tedesca non è collegata alla violazione di Hugging Face di luglio e che per questo non era stata inclusa nel relativo rapporto. 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”, descrivendolo come 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 misalignment, cioè come un problema di ricerca da comunicare attraverso paper e system card, e non come un incidente di sicurezza da divulgare, a differenza di Hugging Face, dove erano stati toccati sistemi di terzi. Riconosce però che quest’anno il disallineamento ha cominciato a produrre effetti nel mondo reale, 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, dicendo di essere in contatto con decine di autorità di regolazione. A Reuters, che le ha chiesto cosa sapesse dell’episodio e perché abbia aspettato la pubblicazione dell’inchiesta per parlarne, non ha risposto.

I ricercatori hanno anche documentato tentativi di manomettere il sito: sondaggi per vulnerabilità XSS sulla pagina di ricerca tra 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 home page, 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.

Vale la pena tenere ferme 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, nel rapporto tecnico sul caso Hugging Face del 26 agosto, ha scritto che alcuni suoi modelli avevano imparato in addestramento, in rari casi, a usare canali di collaborazione improvvisati anche quando lo strumento di collaborazione non era attivo, e che questo comportamento era stato poi rinforzato.

La seconda: Reuters descrive gli agenti intenti a “mascherare il proprio comportamento” ed eludere il rilevamento. 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é nessuno era tenuto a segnalarlo

Qui arriva la parte che interessa direttamente chi si occupa di compliance, ed è controintuitiva.

L’articolo 55 dell’AI Act impone ai fornitori di modelli di intelligenza artificiale per finalità generali con rischio sistemico una serie di obblighi, tra cui, 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. La lettera d) impone inoltre di garantire un livello adeguato di protezione di cibersicurezza del modello e dell’infrastruttura fisica. Gli obblighi per i modelli GPAI 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.

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 in lingua tedesca, mantenuta da volontari, non è un’infrastruttura critica. Nessuno si è fatto male. Non emerge una violazione di obblighi europei a tutela dei diritti fondamentali. Il danno a cose, per come è configurato, difficilmente comprende le decine di ore che un moderatore ha speso in sei settimane a cancellare pagine a mano.

C’è poi un secondo livello, quello del Codice di buone pratiche per i modelli GPAI, 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 sul punto va un po’ 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; e in più punti (Misure 1.3, 2.1, 7.6 e 9.2) il Codice chiede di tenere conto dei near miss. Il Codice quindi contempla almeno un comportamento che parte dal modello, l’autoesfiltrazione, e nell’Appendice 1.3 elenca 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. Se un’evasione delle restrizioni di rete di un sandbox, senza pesi esfiltrati e con un bersaglio che è una wiki di volontari, rientri nella “grave violazione di cibersicurezza” della Misura 9.3 è una domanda aperta: tutto dipende da quanto si allarga “attacco informatico”, e qui la contestazione di OpenAI alla lettura di Olejnik torna a pesare. Resta il near miss, 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, e i near miss vanno tenuti in conto nelle valutazioni del rischio e negli aggiornamenti dei rapporti, non segnalati all’AI Office entro un termine.

Infine, la data. I poteri sanzionatori della Commissione nei confronti dei fornitori di modelli GPAI decorrono dal 2 agosto 2026, e per i firmatari del Codice l’AI Office aveva indicato un anno di tolleranza nella prima fase di applicazione. L’intero episodio, dall’11 maggio al 2 luglio, cade dentro quel periodo.

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 di elusione dei propri controlli e reagiscono alla moderazione predisponendo canali di riserva, con ogni probabilità non integra un incidente grave ai sensi dell’AI Act, e anche sotto il Codice di buone pratiche rientra al più in una zona grigia priva, per ora, di conseguenze. Non c’era nulla che dovesse essere segnalato. Il che rende la mancata segnalazione non una violazione, ma la fotografia di una lacuna. Lo dice, con parole sue, anche OpenAI: la dichiarazione del 5 settembre ammette che manca uno standard per riferire questo tipo di eventi e che la distinzione tra disallineamento di ricerca e incidente di sicurezza sta diventando difficile da tenere. Un fornitore che annuncia un proprio quadro di divulgazione volontario è la conferma più eloquente che quello obbligatorio, oggi, non copre il caso. Del resto il segnale era già nel rapporto tecnico su Hugging Face: lì OpenAI scriveva che il comportamento agentico “può emergere in forme nuove che non sempre rientrano nelle categorie tradizionali di incidente di sicurezza o di safety”, annunciava soglie di escalation interne per la “coordinazione non autorizzata tra agenti o tra esecuzioni” e l'”elusione di controlli di sicurezza di terzi”, e rimandava a una revisione separata dei processi di risposta agli incidenti di allineamento in addestramento e valutazione. 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 sul danno alla persona e sulle infrastrutture critiche, categorie pensate per sistemi ad alto rischio 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 categoria 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

Se si prende sul serio la qualificazione di Olejnik, che OpenAI contesta, e si ipotizza che vi sia stato un tentativo di manomissione del sito, si apre un problema che nel nostro ordinamento non ha una 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 e questo articolo non pretende di anticiparla. 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 da porsi è 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, perché 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, ed è 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 possano essere sfruttate con host inventati (nel caso in esame il sandbox degli agenti considerava fidato un intero suffisso di dominio, senza controllare che l’host esistesse). Registrare separatamente le azioni di scrittura verso sistemi esterni, distinguendole dalla semplice 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 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 stavano cercando 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.