Perché un agente AI senza guardrail è un rischio, non un risparmio

Negli ultimi due anni ho visto lo stesso schema ripetersi in una decina di aziende diverse: qualcuno collega un modello linguistico a un tool — un database, una casella email, un CRM — lo testa cinque volte con successo, e lo mette in produzione. Funziona benissimo, finché non incontra il sesto caso che nessuno aveva previsto.

Un agente AI non è un branch di codice deterministico. È un sistema probabilistico che, alla stessa domanda, può rispondere in modi leggermente diversi a seconda del contesto, della temperatura del modello, di un aggiornamento silenzioso a monte. Trattarlo come se fosse una funzione pura — input, output, fine — è l’errore che sta creando i disastri silenziosi del 2026: query che cancellano righe sbagliate, email inviate al cliente sbagliato, importi scritti con un decimale spostato.

Cosa intendo per “guardrail”, in pratica

Non è un concetto astratto. Per ogni agente che costruisco per un cliente, ci sono almeno quattro livelli di controllo prima che tocchi qualcosa di reale:

Perimetro delle azioni. L’agente non ha accesso diretto a “tutto il database”. Ha accesso a un set di funzioni esplicite, ciascuna con permessi minimi — se deve leggere gli ordini, non può scrivere sugli ordini, punto.

Validazione strutturata dell’output. Prima che un’azione venga eseguita, l’output del modello passa attraverso uno schema (tipicamente JSON Schema o simile) che rifiuta qualunque cosa non sia nella forma attesa. Se il modello “inventa” un campo o un valore fuori range, l’azione non parte.

Soglie di conferma umana. Sotto una certa soglia di impatto (rispondere a una FAQ, categorizzare un ticket) l’agente agisce da solo. Sopra quella soglia (un rimborso, una modifica a un contratto, un’email a un cliente enterprise) l’azione viene proposta, non eseguita — un umano approva con un click.

Log e reversibilità. Ogni azione dell’agente è tracciata e, dove possibile, reversibile. Se non riesci a rispondere in trenta secondi alla domanda “cosa ha fatto esattamente l’agente alle 14:32 di martedì e perché”, il sistema non è pronto per la produzione.

Il costo nascosto del “tanto risparmiamo tempo”

Il motivo per cui questo discorso conta economicamente, non solo tecnicamente, è che il costo di un incidente con un agente mal progettato è quasi sempre più alto del tempo che quell’agente avrebbe fatto risparmiare in un anno. Un’email sbagliata a un cliente enterprise, un dato di fatturazione errato che finisce in un report per l’investitore, un rimborso automatico duplicato cento volte in un weekend: sono scenari reali, non ipotesi da conferenza.

Questo non significa che gli agenti AI non funzionino — significa l’opposto. Funzionano, generano valore reale, e per questo vanno progettati con lo stesso rigore ingegneristico che si userebbe per qualsiasi altro sistema che tocca dati di produzione. La differenza tra un agente che fa risparmiare ore ogni settimana e uno che genera un incidente è quasi sempre nella progettazione dei limiti, non nel modello scelto.

Quando costruisco un agente per un cliente, il tempo che passo a definire cosa l’agente non può fare è comparabile a quello che passo a definire cosa deve fare. È la parte meno visibile del lavoro, ed è quella che decide se il sistema regge nel tempo o diventa un problema da spegnere in fretta. È lo stesso approccio che porto nei progetti di automazioni e agenti AI che costruisco per le aziende.