Gli agenti in produzione vogliono guardrail

I controlli runtime non sono osservabilità

Un agente in produzione non diventa sicuro solo perché il team può guardare una trace dopo un incidente. L’osservabilità spiega cosa è successo. I guardrail runtime decidono cosa può succedere mentre la richiesta è ancora in corso.

La differenza diventa concreta quando l’agente viene esposto a clienti, colleghi o sistemi interni con costi e dati reali. Un agente di supporto utile può entrare in un loop di retry. Un agente di coding può chiamare un modello per tutta la notte. Un agente di ricerca può inviare testo sensibile a un provider che non avrebbe dovuto riceverlo. Un workflow pulito in staging può diventare rumoroso, costoso o rischioso appena incontra traffico di produzione.

LangChain ha descritto bene il problema nell’articolo di luglio 2026 sul LangSmith LLM Gateway: gli agenti in produzione richiedono controlli centralizzati sulle chiamate ai modelli, tra cui limiti di spesa, rate limit, fallback tra modelli, gestione dei dati sensibili e metadati nelle trace. Il prodotto è specifico, ma la lezione architetturale è più ampia: i team che costruiscono agenti hanno bisogno di un livello di enforcement tra la logica dell’agente e le chiamate esterne, non di controlli dispersi dentro ogni implementazione. LangChain presenta questo pattern come un livello centrale di governance per i controlli runtime.

Per questo i contratti di trace sono necessari, ma non bastano. In L’osservabilità degli agenti AI vuole contratti, la trace è il documento che rende ispezionabile il comportamento dell’agente. I guardrail runtime sono il contratto di deployment che limita quel comportamento prima che la trace diventi il referto di un incidente.

Cosa contiene un contratto di guardrail per agenti?

Un buon contratto runtime è volutamente poco spettacolare. Non parte da una teoria universale della sicurezza AI. Parte dai controlli che evitano i guasti più comuni in produzione.

Primo: limiti di spesa. Il contratto deve dire chi possiede il budget, quale finestra temporale vale, quali utenti o tenant hanno limiti separati e quale risposta riceve l’agente quando il limite viene raggiunto. Un cap senza fallback progettato diventa un outage a sorpresa. Un cap con una decisione di prodotto associata diventa una degradazione controllata.

Secondo: rate limit. Il traffico degli agenti è raramente ordinato come la media di una dashboard. Un import di un nuovo cliente, un bug in un loop, un processo batch o un utente interno troppo entusiasta possono generare uno spike. I rate limit dovrebbero esistere al livello giusto: organizzazione, workspace, API key, utente, tenant o workflow. La tassonomia esatta conta meno di un punto: il limite deve vivere fuori dal prompt e fuori dal percorso più ottimistico del codice applicativo.

Terzo: fallback routing. Se il modello preferito non è disponibile, è lento, è rate-limited o costa troppo per quella richiesta, il sistema deve sapere cosa fare. Può passare a un modello più piccolo, a un altro provider, a una risposta in cache, a una coda o a una review umana. I fallback sono comportamento di prodotto, non solo infrastruttura. Un modello più economico può andare bene per classificare un ticket, ma non per scrivere testo legale. Una risposta ritardata può essere accettabile per un arricchimento dati, ma non per il supporto durante un checkout.

Quarto: trattamento dei dati sensibili. La redazione deve avvenire prima della chiamata al modello, non solo nei log salvati. Il contratto deve specificare quali dati vanno rimossi, mascherati, sostituiti o bloccati. Deve anche distinguere tra dati inviabili a un modello approvato, dati utilizzabili solo in un ambiente privato e dati che devono far scattare un’escalation.

Quinto: review delle trace. Quando un limite blocca una richiesta o un fallback viene attivato, la trace deve rendere leggibile la decisione. Il team deve vedere quale policy è stata applicata, quale identità o tenant era coinvolto, quale route di modello è stata tentata e se la risposta era adeguata al contesto utente.

Dove devono vivere fallback e limiti di spesa?

Il posto sbagliato è dentro ogni singolo agente. Sembra veloce quando c’è un agente e un provider. Diventa fragile quando ci sono cinque agenti, tre team, più tenant e un portafoglio di modelli che cambia ogni mese.

Il pattern più robusto è un gateway runtime. L’agente continua a possedere la logica del task, la pianificazione, la scelta degli strumenti e l’interazione con l’utente. Il gateway possiede le policy trasversali per chiamate a modelli e strumenti. Questa separazione offre a product ed engineering lead un contratto più pulito: ciò che l’agente prova a fare sta in un livello, ciò che l’organizzazione permette a runtime sta in un altro.

Questo non significa che ogni azienda debba adottare lo stesso gateway vendor. Alcuni team useranno una piattaforma commerciale. Altri costruiranno un proxy interno leggero. Altri ancora combineranno regole di API gateway, model routing, servizi di policy e pipeline di trace. L’implementazione può cambiare. Il requisito architetturale resta: deve esistere un percorso enforceable in cui spesa, rate, fallback, redazione e metadati di trace vengano applicati in modo coerente.

Il punto è ancora più importante quando l’agente può usare strumenti. Se una chiamata al modello può portare a modificare dati, inviare messaggi, aprire ticket o attivare workflow collegati a pagamenti, la policy runtime non può limitarsi al costo dei token. La logica di Agenti AI: servono permessi, non accesso totale vale anche qui. I permessi definiscono cosa può fare l’agente. I guardrail runtime definiscono quando, quante volte, a quale costo, con quali dati e con quale comportamento di fallback.

Quando un guardrail diventa comportamento di prodotto?

Un guardrail diventa comportamento di prodotto nel momento in cui l’utente ne vede l’effetto.

Se un agente di supporto dice: “Serve una verifica umana”, quello è prodotto. Se un agente di ricerca usa una fonte in cache perché il budget per il modello premium è esaurito, quello è prodotto. Se un assistente di coding rifiuta di processare un secret incollato nel prompt, quello è prodotto. L’utente non distingue tra codice applicativo, proxy e gateway. Vive il sistema come un unico prodotto.

Per questo i guardrail hanno bisogno di linguaggio di prodotto, non solo di linguaggio infrastrutturale. Non basta documentare “limite superato”. Bisogna documentare lo stato utente. Il task viene messo in coda? La risposta è degradata? L’utente deve restringere la richiesta? L’incidente è silenzioso, visibile o escalato? Chi può fare override? Quali clienti hanno limiti diversi per piano, contratto o profilo di rischio?

Qui i team di automazione dovrebbero collegare i controlli runtime alle classi di errore. In L’automazione AI ha bisogno di classi di errore, la mossa chiave è smettere di trattare ogni fallimento come un invito a riprovare. Un rate limit, un blocco di policy, una redazione di dati e un outage del provider sono classi diverse. Meritano percorsi di recupero diversi.

Fai audit di un agente prima del prossimo deploy

Prima del prossimo rilascio, scegli un agente già in produzione o vicino al lancio. Non partire da una migrazione di piattaforma. Parti da un contratto runtime di una pagina.

Scrivi cinque sezioni. Limiti di spesa: chi paga, quale limite vale e cosa succede quando viene raggiunto. Rate limit: quale livello di identità conta e come vengono gestiti gli spike. Fallback routing: quali task possono passare a un altro modello, a una coda, a una cache o a una persona. Dati sensibili: cosa deve essere redatto, bloccato o mantenuto dentro un perimetro privato. Trace review: quali metadati devono essere registrati quando una policy scatta.

Poi marca ogni sezione come enforced, parziale o aspirazionale. I vuoti scomodi sono il senso dell’esercizio. Un agente in produzione senza guardrail runtime non è per forza irresponsabile, ma è incompleto. Può essere osservabile, impressionante e utile, e comunque mancare dei controlli che lo rendono operabile su scala.

La tesi è semplice: gli agenti in produzione hanno bisogno di guardrail runtime. Non come slide in un documento di governance. Non come commenti sparsi nel codice dell’agente. Non come review manuale eroica dopo che qualcosa è andato storto. Hanno bisogno di limiti di spesa, rate limit, fallback routing, redazione dei dati sensibili e trace review trasformati in un contratto runtime prima che l’agente tocchi utenti reali, dati reali e soldi reali.