Dagli LLM agli agenti: come governance e architetture operazionali rendono gli agenti AI affidabili in produzione

Amazon aggiunge filtri runtime per dominio e data al connettore web‑search 1.2.0 di AgentCore su Bedrock. Il blocco delle fonti e la finestra temporale ora si impostano per chiamata, con enforcement lato server. La tesi: le aziende stanno spostando l’attenzione dal modello all’ingegneria operativa degli agenti. Governance delle fonti, vincoli di freschezza, invocazioni asincrone e safety senza retention diventano prerequisiti pratici per portare gli agenti in produzione.

Perché la governance delle fonti è diventata prioritaria

I filtri runtime di Amazon mirano a due problemi ricorrenti: provenienza e attualità. Un agente che risponde su finanza non deve citare un blog non verificato. Un agente che parla di prodotti non può basarsi su inventari o prezzi di tre anni fa se l’utente chiede la disponibilità attuale. Il filtro per dominio restringe le sorgenti. Il filtro per data impone la freschezza dei contenuti. Entrambi si impostano per query, quindi aderiscono al contesto dell’utente. L’enforcement lato server evita orchestrazioni esterne.

Le regole runtime si combinano con le policy amministrative sui domini. Gli amministratori fissano un perimetro. Gli sviluppatori lo affinano alla chiamata in base alla richiesta. Ne risulta un filtraggio a più livelli che riduce il rischio operativo. È un passaggio di piattaforma, non di modello. Il valore non sta nel “capire meglio” il web, ma nel decidere prima cosa non consultare.

Questa granularità segnala maturità. Quando un agente ha accesso alla ricerca sul web, la qualità della risposta dipende dal controllo delle fonti almeno quanto dal prompt. I nuovi filtri spostano la leva dal tuning creativo al governo delle dipendenze informative. Il codice dell’agente non cambia. Cambia il contratto di esecuzione: quali siti e quali date contano per una risposta accettabile.

Pattern operativi per scalare senza sprecare risorse

Amazon indica un altro collo di bottiglia: il costo del tempo di attesa. Una funzione serverless, per esempio AWS Lambda, che resta attiva mentre l’agente elabora, paga secondi “a vuoto”. La raccomandazione è chiara: invocare AgentCore in modo asincrono per evitare compute in idle e tagliare la bolletta. Non è una finezza architetturale. È una misura diretta sui costi.

L’esempio è concreto. Un back office di finanziamento immobiliare usa un agente per leggere atti di proprietà o contratti di mutuo, verificarne completezza e coerenza, e restituire un verdetto che sblocca i passi successivi. La latenza varia con prompt, modello e documento. Se la funzione “chiama e aspetta”, somma imprevedibilità e spreco. Con il pattern asincrono, libera le risorse subito e riprende solo alla risposta. Così separa la latenza dal costo.

Qui si vede la stessa traiettoria dei filtri sulle fonti. Non si chiede al modello di “rispondere più in fretta”. Si cambia il modo in cui l’infrastruttura ospita l’agente. Il risultato non è una risposta migliore, ma una risposta che costa il giusto. È una condizione per scalare, soprattutto quando il carico e la lunghezza dei documenti variano.

Multi‑agente e contesto normativo: casi d’uso reali

Fanatics Betting and Gaming ha messo in produzione su AWS un supporto clienti multi‑agente durante Super Bowl e playoff NFL. Le richieste arrivano mentre la partita corre. Accesso all’account. Limiti di deposito. Regole diverse per stato. Materiali sul gioco responsabile. L’utente vuole una risposta nella stessa finestra in cui scommette.

La complessità nasce dal mosaico normativo. Ogni giurisdizione modifica ciò che è consentito. I bot a regole fisse producono escalation. Nei picchi, l’errore pesa di più e il tempo si accorcia. Da qui l’architettura multi‑agente: ridurre il tempo di risoluzione e migliorare la pertinenza rispetto ai bot a menu, applicando le regole dello stato di residenza dell’utente senza percorsi rigidi.

Questo caso chiarisce perché la piattaforma conta. La qualità utile non è il “tono”. È la capacità di restare coerenti con regole locali che cambiano, in tempo reale. Serve un disegno a componenti: chi interpreta il contesto, chi gestisce le regole per stato, chi compone la risposta. Senza direzioni operative, i modelli restano bravi a scrivere ma deboli nel rispettare vincoli.

Safety e privacy: approcci divergenti sulle retention

OpenAI avvia la preview di Private Safety Processing con una scelta netta: analizza gli usi a rischio e non conserva i dati dei clienti al termine del controllo. L’iniziativa è una “anteprima limitata” e punta a una safety centrata sulla privacy, senza storage post‑analisi. Lo scopo resta monitorare il “misuse”, ma senza retention.

Anthropic adotta un’opzione opposta su alcuni modelli. A luglio ha dichiarato di poter conservare “tutte le loro sessioni — e le conversazioni in esse” per 30 giorni per i “covered models”, inclusa la classe Mythos e “future models with similar capabilities”. La società ha riconosciuto che la decisione ha irritato alcuni clienti.

La divergenza impone scelte diverse a chi integra agenti. Con retention a 30 giorni, l’organizzazione può esaminare conversazioni passate, ma deve accettare che una copia resti per il periodo definito. Con il filtro di sicurezza senza retention, l’analisi avviene al volo e i dati spariscono alla fine. La scelta incide sui processi interni: quali audit sono possibili, che consenso serve, come si gestisce una segnalazione di abuso. Qui la “feature di safety” è anche una politica di trattamento dei dati.

Produttività degli sviluppatori e metriche operative con gli agenti

Simon Willison rimette sul tavolo una metrica spesso scartata. “Con agenti si può arrivare a un migliaio di righe di codice già debugged in un giorno”, se la qualità resta identica. In passato, la media stava tra 50 e 60 righe al giorno. Una giornata “incredibilmente buona” valeva 200 righe. Il perimetro è cruciale: contano solo righe di livello produzione, manutenibili e testate. Senza questo vincolo, la metrica non regge.

La tesi di Willison si lega agli aspetti ingegneristici citati prima. Se gli agenti alzano il throughput a parità di qualità, la produttività si misura dove si produce valore: nel codice pronto per la produzione, non nel prompt ben scritto. La condizione è identica a quella dei filtri e delle invocazioni asincrone: mantenere standard operativi mentre si spinge sulla quantità. Da qui l’importanza di vincoli di piattaforma che tengano la qualità stabile mentre cresce il volume.

I numeri non dicono che “bastano gli agenti”. Dicono che, con agenti, la metrica torna utile. Il punto operativo diventa organizzare il lavoro perché quelle righe restino buone: test, review, integrazione con pipeline che non sprecano compute e con agenti che non pescano fonti sbagliate. Il modello conta, ma è la cornice che lo rende affidabile.

Una traiettoria comune

Filtri runtime per dominio e data con enforcement lato server. Invocazioni asincrone per tagliare il costo dell’attesa. Sistemi multi‑agente per contesti normativi che cambiano durante Super Bowl e playoff. Safety senza retention in preview e retention di 30 giorni sui “covered models”. E una metrica di produttività che torna misurabile se la qualità resta costante. Sono tasselli della stessa traiettoria: dai modelli agli agenti, dagli agenti alla piattaforma.

Per chi costruisce sistemi AI in azienda, la checklist di adozione cambia di segno: oggi conta dimostrare, con strumenti di piattaforma, che un agente sa cosa escludere, quanto costa aspettarlo e che traccia lascia dei dati che analizza.