Per capire chi stesse rallentando il servizio di interrogazione di Wikidata, la banca dati collaborativa di Wikimedia, a maggio i tecnici di Wikimedia hanno dovuto leggere i registri del servizio. Uno scraper, un programma che scarica contenuti automaticamente, era sfuggito al campione iniziale del traffico. Il guasto è durato dal 7 all’11 maggio: cercare la sorgente delle richieste richiedeva altro lavoro, mentre le interrogazioni continuavano a scadere senza risposta.
Il 5 ottobre la Wikimedia Foundation, che mantiene l’infrastruttura di Wikipedia, ha pubblicato un’indagine su agenti che ritiene appartenessero a OpenAI, l’azienda che sviluppa sistemi di intelligenza artificiale. Dice che hanno inviato milioni di richieste alle API, le interfacce che forniscono dati ai programmi, e scaricato milioni di pagine, soprattutto da Wikidata e dall’archivio multimediale Wikimedia Commons. La fondazione ipotizza un loro contributo al guasto di maggio. Il rapporto tecnico del guasto descrive scraper aggressivi, senza attribuirli a OpenAI.
Secondo la Foundation, gli agenti hanno modificato wiki senza l’approvazione prevista per i bot, quasi sempre nelle pagine di prova. La fondazione interpreta alcune modifiche alla configurazione di uno strumento per le citazioni come possibili tentativi di usarlo come intermediario per recuperare pagine esterne. Lo stesso tentativo su Etherpad, il servizio di scrittura condivisa, è fallito. La fondazione dice di non avere evidenze di sistemi o dati compromessi. Volontari e squadra di sicurezza hanno individuato e annullato le modifiche.
OpenAI sta lavorando con Wikimedia per esaminare le attività individuate, ha detto a The Verge il portavoce Drew Pusateri. L’indagine dell’azienda, ha aggiunto, non ha verificato se i bot abbiano contribuito al guasto.
Già nel 2025 la Wikimedia Foundation spiegava come i programmi che raccolgono contenuti automaticamente avessero cambiato il lavoro dei suoi server. I lettori cercano spesso le stesse pagine popolari: una copia conservata vicino a loro permette di rispondere senza interrogare ogni volta il datacenter centrale. Gli scraper percorrono anche le pagine meno richieste. Le copie già pronte servono meno e più richieste arrivano ai server centrali, dove elaborarle costa più risorse. Chi raccoglie dati su larga scala fa lavorare l’infrastruttura in modo diverso da chi apre una voce. La squadra che ne cura l’affidabilità deve intervenire quando questi programmi sovraccaricano i servizi.
LITM ha raccontato il 26 settembre il caso dell’agente di OpenAI e della sanità australiana. Scaricare i contenuti occupa i server; cambiare una configurazione impegna anche chi deve capire che cosa è stato cambiato e perché. Il beneficio della prova può restare a chi sviluppa l’agente, mentre una parte del lavoro necessario per farla si svolge sul servizio che l’agente ha raggiunto. Per questa vicenda la fondazione non indica un costo in euro.
Durante il guasto di maggio le troppe interrogazioni rallentavano anche l’aggiornamento dei dati. L’arretrato attivava altre limitazioni, fino alle modifiche su Wikidata. Il rapporto documenta il passaggio ai registri diretti e il ritorno dei tempi di risposta alla normalità dopo un nuovo limite.
La Foundation chiede alle aziende agenti riconoscibili, libertà per i gestori di scegliere come interagire con loro e aiuto per prevenire o riparare i danni. Nel ripristino di maggio, i tecnici hanno dovuto correggere anche alcune regole che bloccavano traffico legittimo. Dopo aver individuato le richieste eccessive, restavano gli utenti fermati insieme agli scraper.
