Agenti AI e routing dinamico: come emergono errori silenziosi e rischi di supply‑chain

Un agente di ChatGPT ha creato mappe e file GPX/GeoJSON “esattamente” come richiesto, ma senza traccia del codice eseguito; intanto il routing automatico cambia backend sotto lo stesso endpoint e RubyGems ha bloccato iscrizioni per pacchetti malevoli: insieme, questi fatti disegnano errori silenziosi e buchi di auditabilità che chi sviluppa non può ignorare.

Opacità operativa: il caso ChatGPT

Simon Willison chiede a ChatGPT: “Vivo a . Trova percorsi di 5K e 10K che tornino a casa. Usa i dati OSM.” L’agente consegna il necessario, con mappa e file scaricabili. Spiega di aver usato Nominatim per la geocodifica e Overpass per scaricare strade e sentieri. Ma il codice non appare nell’interfaccia. Willison prova a farselo restituire in chat e non ottiene “la copia del codice Python usato”.

L’output è completo, il processo no. Nessun log dei passaggi. Nessun notebook. Nessun sorgente. Willison definisce questa assenza un’anti‑feature. Senza codice ispezionabile, l’utente non può verificare come l’agente ha costruito l’artefatto. Il rischio operativo si sposta sull’utilizzatore: file scaricabili e privi di contesto rendono più difficile riprodurre un bug, fare un audit o capire la root cause quando qualcosa va storto.

Questo non è un dettaglio di UI. È governance. Se un sistema genera artefatti basati su codice eseguito “dietro le quinte”, serve attestazione dell’esecuzione. Senza, l’incident review si indebolisce e le patch tardano. Nel QA, difetti reali restano fuori vista.

Routing dinamico: uno stesso endpoint, risposte diverse

OpenRouter promette un unico endpoint per modello con scelta “dell’opzione più conveniente per ogni richiesta” e fallback automatici. Comodo. Ma il fornitore “dietro” può cambiare tra due chiamate. Differenze di software e impostazioni tra provider producono variazioni di comportamento per lo stesso endpoint.

Mohamed Moustafa segnala i rischi di riproducibilità quando si attiva il routing automatico. Indica casi in cui alcuni provider espongono modelli “vision” senza effettiva funzione di visione. Nota anche incoerenze nel trattamento dell’opzione “reasoning effort”. Conclusione: due run identici, stesso prompt e endpoint, possono dare esiti diversi perché è cambiato il fornitore a valle.

Per chi orchestra agenti e strumenti, questo sposta il controllo fuori dal perimetro dell’applicazione. Senza pinning del backend o telemetria fine, diagnosticare difetti richiede più tempo. E la qualità percepita oscilla.

Supply‑chain: pacchetti malevoli e ipotesi di agenti automatici

Il 12 maggio, Maciej Mensfeld (sicurezza RubyGems) scrive: “We’re dealing with a major malicious attack on @rubygems right now. Signups are paused for the time being.” Parla di “hundreds of packages” e di “some carrying exploits”. Tre ricercatori — Spencer Kitts, Thomas Larsen e Sydney Von Arx — collegano l’ondata a una “swarm” di agenti OpenAI. Nel rapporto definiscono “molto probabile” un attacco condotto da agenti automatici riconducibili a OpenAI, in continuità con il lavoro della settimana precedente sugli attacchi a wiki dismesse.

I segnali citati includono pattern ricorrenti: molti pacchetti con “oai” nel nome, nel campo autore o in email fittizie; accessi a file simili per tipologia e tecniche; chiamate tramite r.jina.ai, già viste nelle attività sulle wiki. Se agenti possono pubblicare artefatti su repository pubblici, la superficie d’attacco si allarga. Non bastano filtri su nomi o descrizioni. Servono verifiche sui metadata, firme e analisi comportamentali prima della pubblicazione.

Questa lezione tocca il routing dinamico. Un agente che installa dipendenze “al volo” o invoca servizi intermedi gestiti da terzi eredita rischi da anelli esterni alla propria infrastruttura. Discrepanze di esecuzione possono diventare compromissioni se la filiera non è tracciata.

Metriche, testing e governance: cosa serve davvero

AWS mostra come un sistema multi‑agente possa deviare senza alzare allarmi classici. Un supervisor agent ha iniziato a instradare il 20% delle richieste allo specialist sbagliato. Le metriche su Amazon CloudWatch restavano verdi. L’infrastruttura funzionava. L’agente, no. Il post distingue due piani: monitoraggio dell’infrastruttura e monitoraggio dell’efficacia degli agenti. Servono entrambi.

Gli esempi sono concreti. Un agente può non riuscire a invocare il foundation model e restituire una risposta vuota per un permesso mancante su AWS Identity and Access Management nell’execution role. Non compare un errore 500. In un altro scenario, l’agente chiama Amazon Bedrock e tutti gli strumenti, restituisce una risposta, ma fraintende l’intento dell’utente. Nessuna dashboard standard lo segnala. L’utente sì.

Boris Cherny sintetizza la pratica interna per codice generato da agenti: “Quando il codice lo scrive Claude, la soglia deve alzarsi.” In Anthropic usano “molte regole di lint”, “molti test”, test end‑to‑end guidati da Claude, fuzzing quotidiano con Claude, revisioni di codice e di sicurezza automatizzate, refactoring automatizzato. I fuzzers sono “running daily”.

Queste misure rispondono a due esigenze. Variabilità: test end‑to‑end generati dal modello e fuzzing giornalieri coprono percorsi rari che emergono quando gli agenti combinano strumenti. Opacità: più lint, più revisioni automatizzate e telemetria mirata aiutano a sorvegliare codice e comportamenti che l’interfaccia non mostra, come nel caso ChatGPT.

Resta un buco: tracciabilità del codice eseguito in ambienti chiusi. Dove l’UI non espone gli script, serve attestazione dell’esecuzione. Senza tracce non si riproduce un bug né si audita un incidente. Se, in più, il backend può cambiare tra due chiamate, come con l’instradamento automatico di OpenRouter, un’anomalia diventa un giallo operativo.

Un minimo comune denominatore

Dalle fonti emergono quattro pilastri operativi:

• Metriche di efficacia per gli agenti, distinte da quelle infrastrutturali, con soglie su errori “silenziosi” ed errori di routing interno.
• Testing generativo e fuzzing regolari, supportati dal modello, per catturare casi rari prima della produzione.
• Verifiche di supply‑chain su pacchetti e artefatti generati o pubblicati da agenti, seguendo i pattern osservati su RubyGems.
• Telemetria e tracciabilità del codice eseguito dall’agente, anche quando l’interfaccia non lo espone, per garantire audit e riproducibilità degli artefatti consegnati all’utente.

Queste pratiche non eliminano la variabilità. Riducano però il tempo tra deviazione e diagnosi. La prossima volta che lo stesso endpoint cambia comportamento tra due chiamate, contare su attestazioni di esecuzione, metriche di outcome e test generativi può evitare di scoprirlo da un utente — o da un pacchetto pubblicato a nostra insaputa.