Gli agenti AI non pagano il conto. Lo paga il web che attraversano

Quando valutiamo un agente AI tendiamo a misurare ciò che interessa a chi lo esegue: quanti task completa, quanto costa ogni esecuzione, quante chiamate fa ai tool, quanto è accurato. È una metrica comoda, ma incompleta. Un agente può essere efficiente dal lato di chi lo lancia e contemporaneamente scaricare il proprio costo operativo su sistemi che non hanno chiesto di partecipare all’esperimento.

Il caso raccontato dalla Wikimedia Foundation è interessante proprio per questo. Wikimedia afferma di aver identificato attività non autorizzata riconducibile, secondo la propria indagine, ad agenti operati da OpenAI: modifiche su wiki, uso improprio tentato di servizi ospitati e una quantità molto elevata di traffico automatizzato. La fondazione dice di non aver trovato prove di compromissione dei propri sistemi o dati, né di coordinamento tra agenti sulle sue piattaforme. Non serve trasformare l’episodio in qualcosa di più grave di ciò che è documentato per vedere il problema architetturale.

Il costo che manca nei benchmark degli agenti

Secondo Wikimedia, gli agenti attribuiti a OpenAI hanno effettuato milioni di richieste automatizzate alle API pubbliche, visitato milioni di pagine soprattutto su Wikidata e Wikimedia Commons e inviato centinaia di migliaia di query al Wikidata Query Service. La fondazione sostiene che questo traffico possa aver contribuito a un’interruzione parziale del servizio avvenuta a maggio. Reuters ha riportato la stessa attribuzione in forma prudente: possibile contributo al disservizio, non prova di causalità esclusiva.

Qui emerge una metrica che quasi nessun benchmark di agenti mostra: il costo esterno per azione. Se un agente risolve un compito spendendo pochi centesimi di token ma genera migliaia di richieste inutili verso un servizio terzo, il suo costo reale non è quello esposto dalla dashboard del provider. Una parte del conto è stata semplicemente spostata altrove: banda, CPU, cache, code, rate limiting, investigazione, incident response e lavoro umano.

Un agente non è efficiente se ottimizza il proprio task consumando senza controllo l’infrastruttura degli altri. Ha solo spostato il costo fuori dal proprio perimetro.

Autonomia senza identità è un difetto di protocollo

Wikimedia ricorda che i bot possono modificare Wikipedia quando sono dichiarati e approvati secondo le regole della comunità. Negli episodi descritti, quelle approvazioni non sarebbero state richieste. Questo rende evidente una differenza che nel software agentico continuiamo a confondere: poter eseguire un’azione non significa essere autorizzati a eseguirla.

È lo stesso principio che vale nelle API serie da decenni. Una credenziale non dovrebbe significare accesso illimitato; porta con sé scope, quote, audit e revoca. Con gli agenti la necessità aumenta, perché il chiamante non è più una funzione deterministica che esegue sempre lo stesso percorso. Decide quale tool usare, quante volte riprovare, quali pagine attraversare e quando cambiare strategia.

Per questo la sicurezza degli agenti non può stare soltanto nel prompt. Se il limite è scritto come istruzione linguistica ma il sistema può tecnicamente ignorarlo, non abbiamo un controllo: abbiamo una speranza. Identità verificabile, autorizzazioni, rate limit, budget e audit devono stare nell’enforcement layer.

Il rate limit non è una punizione

Nel mondo degli agenti il rate limit viene spesso trattato come un ostacolo da aggirare: qualcosa che rallenta il task e peggiora il tempo di completamento. È una lettura miope. Il rate limit è un contratto di convivenza tra chi consuma una risorsa e chi la mantiene.

Un buon orchestratore dovrebbe conoscere non soltanto il budget monetario della propria esecuzione, ma anche il budget operativo imposto a ogni dipendenza. Quante richieste al minuto sono ragionevoli? Quanti retry consecutivi? Quale backoff dopo un errore temporaneo? Quando un crawler deve fermarsi? Quando un tool deve dichiarare esplicitamente la propria identità? Sono domande architetturali, non buone maniere opzionali.

Ho già scritto che il budget è un guard rail per gli agenti. Il passaggio successivo è smettere di considerare budget soltanto ciò che paghiamo noi. Un agente maturo dovrebbe avere limiti multidimensionali: denaro, tempo, token, chiamate, banda, concorrenza e impatto sulle dipendenze esterne.

L’open web non è un’API infinita

Il caso Wikimedia è particolarmente istruttivo perché riguarda un’infrastruttura aperta. Wikipedia e Wikidata esistono proprio per rendere conoscenza e dati accessibili. Ma aperto non significa gratuito in senso fisico: ogni richiesta attraversa server, reti, cache, database e persone che mantengono tutto questo.

Wikimedia aveva già segnalato nel 2025 un aumento del 50% dell’uso di banda dovuto alla crescita del traffico bot dal 2024 e indicava che il 65% del traffico più costoso in termini di risorse proveniva da bot. Il punto non è demonizzare crawler e automazione. Il web usa bot da sempre. Il salto avviene quando sistemi capaci di pianificare, riprovare e moltiplicare azioni vengono messi in produzione senza un modello altrettanto serio di responsabilità operativa.

Un agente deve lasciare una traccia comprensibile

Se un sistema autonomo interagisce con un servizio esterno, chi gestisce quel servizio dovrebbe poter rispondere rapidamente ad alcune domande: chi lo sta eseguendo, per conto di chi, con quale finalità, con quale versione, con quale limite di frequenza e con quale canale per fermarlo o segnalarne il comportamento.

Non basta uno user agent con scritto “AI”. Serve una catena di responsabilità. L’identità deve essere verificabile; le richieste devono poter essere aggregate per operatore; gli incidenti devono essere ricostruibili; il sistema che lancia l’agente deve poter revocare capacità e interrompere una run. Se non possiamo attribuire il traffico, non possiamo governarlo. Se non possiamo interromperlo, non abbiamo autonomia controllata: abbiamo soltanto automazione con più libertà.

La misura giusta non è quanto sa fare

La corsa agli agenti premia capacità sempre più spettacolari: navigare, programmare, usare strumenti, coordinare task. Ma un sistema utile in produzione deve essere giudicato anche da ciò che non fa. Non insiste all’infinito. Non scarica milioni di pagine quando esiste un percorso più efficiente. Non tratta un servizio pubblico come capacità computazionale gratuita.

Questa non è una limitazione dell’intelligenza dell’agente. È ingegneria del sistema che lo contiene. Più aumentiamo la capacità di decidere autonomamente, più dobbiamo rendere espliciti confini, budget e responsabilità. Altrimenti il successo del task locale può coincidere con il fallimento del sistema complessivo.

Il benchmark più interessante per un agente non è soltanto se arriva al risultato. È se ci arriva senza trasformare le dipendenze esterne in danni collaterali.

È questa, più del termine “rogue”, la lezione utile del caso Wikimedia. Il problema non comincia quando un agente diventa fantascientificamente incontrollabile. Comincia molto prima, quando nessuno ha progettato chi paga, chi autorizza, chi osserva e chi può dire basta.