Cosa succede se un utente prova a far uscire il tuo agente AI dai binari? Se gli chiede qualcosa di violento, prova a manipolarlo con un prompt injection, o semplicemente pone una domanda a cui il tuo sistema non dovrebbe rispondere perché non ha fonti affidabili per farlo?
Se la risposta è “spero che il prompt regga“, il problema non è il prompt. È che manca uno strato di protezione che non dovrebbe dipendere dalla fortuna, ma dal design del sistema.
I guardrails sono esattamente questo: un insieme di controlli che si frappongono tra l’utente, il modello e l’azienda, e che decidono cosa può passare e cosa deve essere bloccato, prima o dopo che l’agente abbia generato una risposta. In questo articolo vediamo perché sono indispensabili in un agente AI in produzione, quali livelli di protezione sono già integrati nativamente in Userbot 3.0, e come è possibile aggiungerne altri su misura per il proprio caso d’uso.
Perché un agente AI senza guardrails non è pronto per la produzione
Un modello linguistico, da solo, non sa cosa è appropriato dire in un determinato contesto aziendale. Sa generare testo plausibile in base a quello che gli viene chiesto e al contesto che gli viene fornito. Se quel contesto viene manipolato, o se la domanda tocca un’area sensibile, il modello non ha un meccanismo interno che gli dica “qui devo fermarmi“.
Questo espone chi mette in produzione un agente AI a rischi molto concreti:
- risposte inappropriate su temi come violenza o self-harm,
- tentativi di prompt injection che cercano di far ignorare all’agente le sue istruzioni originali
- risposte costruite su informazioni recuperate da un sistema RAG ma che non sono pertinenti con la domanda
Nessuno di questi problemi si risolve scrivendo “non rispondere a domande violente” nel prompt di sistema. Serve uno strato separato, che agisca indipendentemente dal ragionamento del modello: è qui che entrano in gioco i guardrails.
Un prompt è un’istruzione, non un controllo. Può essere aggirato, frainteso, o semplicemente non bastare di fronte a un input costruito apposta per confonderlo.
Cosa sono davvero i guardrails (e perché “un buon prompt” non basta)
Un guardrail è un controllo che si può applicare prima che l’input arrivi al modello, dopo che il modello ha generato una risposta, oppure nel mezzo del flusso, ad esempio per validare i risultati di una ricerca. In tutti i casi, la logica è la stessa: verificare qualcosa secondo criteri definiti, e decidere se lasciar proseguire, correggere, o bloccare.
La differenza rispetto a un’istruzione nel prompt è sostanziale. Un’istruzione (“non parlare di argomenti violenti”) è una richiesta rivolta al modello, che il modello interpreta e a cui il modello può, in certi casi, non attenersi con coerenza, soprattutto se l’input è costruito per aggirarla.
Un guardrail è invece un controllo esterno al ragionamento del modello: non chiede al modello di comportarsi bene, verifica che il comportamento sia corretto, e agisce di conseguenza a prescindere da cosa il modello abbia “deciso” di fare.
Per questo un’architettura agentica seria non si affida a un solo livello di guardrails, ma a più livelli, ciascuno pensato per un tipo di rischio diverso: contenuti dannosi, manipolazione del prompt, informazioni non pertinenti, casi specifici del proprio dominio. In Userbot 3.0 questi livelli sono già integrati nella piattaforma, e si possono estendere con configurazioni personalizzate.
Un prompt è un’istruzione. Un guardrail è un controllo. Solo uno dei due non si aggira semplicemente chiedendo con le parole giuste.
I livelli di guardrails nativi in Userbot 3.0
1. Filtro Azure: violenza, contenuti sessuali, odio, self-harm
Il primo livello di protezione agisce sui contenuti in senso stretto, ed è basato sul filtro di Azure AI Content Safety, integrato nativamente nella piattaforma. Ogni input e ogni output del modello passano attraverso una classificazione automatica su quattro categorie: violenza, contenuti sessuali, incitamento all’odio e self-harm.
Se un messaggio, in ingresso o in uscita, viene classificato come a rischio in una di queste categorie, il flusso viene interrotto prima che l’agente possa generare o restituire quel contenuto. Non è un filtro opzionale da configurare manualmente: è un livello di sicurezza di base che protegge ogni conversazione gestita dalla piattaforma, indipendentemente dal settore o dal caso d’uso.
Questo tipo di controllo è particolarmente rilevante nei contesti di customer service aperti al pubblico, dove non si può prevedere in anticipo cosa scriverà un utente, e dove anche un singolo episodio gestito male ha un costo reputazionale reale.
2. Blocco codice Python: la difesa contro prompt injection
Il secondo livello riguarda un elemento diverso, e più tecnico, dell’architettura di Userbot: il blocco di codice Python che può essere inserito all’interno di un workflow agentico per eseguire logica custom, calcoli, trasformazioni di dati o chiamate a servizi esterni.
Un blocco che esegue codice è, per sua natura, un punto delicato: se un utente riuscisse a far eseguire all’agente istruzioni non previste, camuffate da input legittimo, potrebbe usare quello stesso blocco per tentare un prompt injection, per provare ad accedere a dati del sistema a cui non dovrebbe avere accesso, o più in generale per far agire il codice contro il prodotto stesso invece che a supporto del workflow.
Per questo, in Userbot, il blocco di codice Python non si limita a essere eseguito in sandbox isolata: al suo interno è integrato un guardrail dedicato, che analizza il codice e il contesto di esecuzione prima che vengano eseguiti, e blocca i tentativi di sfruttare quel blocco per scopi diversi da quello per cui è stato configurato, che si tratti di un tentativo di prompt injection, di un tentativo di leggere o esfiltrare dati del sistema, o di un tentativo di agire su funzionalità della piattaforma che non dovrebbero essere raggiungibili da quel punto del workflow.
È un controllo deterministico, non affidato all’interpretazione del modello: verifica strutturale del codice e del contesto in cui viene eseguito, non un giudizio probabilistico su di esso. La sandbox garantisce che l’esecuzione resti isolata dal resto del sistema; il guardrail garantisce che, anche all’interno di quello spazio isolato, il codice non venga usato per fare qualcosa che va oltre lo scopo del blocco.
Questo tipo di protezione diventa via via più importante quanto più un agente ha accesso a tool che compiono azioni reali: aprire ticket, aggiornare record in un CRM, effettuare chiamate ad API esterne. Un tentativo di abuso che riesce a passare in un contesto del genere non produce solo una risposta imbarazzante: può tradursi in un’azione indesiderata su un sistema aziendale.
3. Validare (o scartare) i risultati della ricerca semantica
Il terzo livello riguarda un problema più sottile, tipico dei sistemi RAG: cosa succede quando la ricerca semantica restituisce risultati che assomigliano alla domanda, ma non la soddisfano davvero?
Un retriever lavora per similarità vettoriale: trova i chunk di documento più vicini semanticamente alla domanda posta. Ma “vicino semanticamente” non equivale sempre a “pertinente e sufficiente per rispondere correttamente”. Se l’agente costruisce comunque una risposta su chunk poco pertinenti, il risultato è una risposta che sembra fondata, ma non lo è: uno dei rischi più insidiosi nei sistemi basati su knowledge base, perché non si presenta come un errore evidente.
Per questo, in Userbot, viene usato un modello specifico come guardrail di validazione a valle della ricerca semantica: verifica se i risultati recuperati sono effettivamente rilevanti rispetto alla domanda, prima che vengano usati per costruire la risposta. Se la validazione fallisce, l’agente non forza comunque una risposta basata su fonti deboli, ma può gestire il caso in modo esplicito, ad esempio segnalando che non ha informazioni sufficienti o passando la mano a un altro flusso.
È un guardrail meno visibile degli altri due, perché non riguarda contenuti “vietati” in senso classico, ma è altrettanto importante: protegge l’affidabilità delle risposte, non solo la loro appropriatezza.
4. Guardrails su misura: agenti con prompt personalizzati
I tre livelli precedenti coprono rischi comuni a qualunque agente AI, indipendentemente dal settore. Ma ogni azienda ha anche le proprie regole specifiche, che nessun filtro generico può conoscere in anticipo: un’assicurazione che non deve mai fornire una stima di indennizzo, un e-commerce che non deve mai promettere sconti non autorizzati, un servizio sanitario che non deve mai sostituirsi a un parere medico.
Per questi casi, Userbot permette di costruire guardrails su misura, sotto forma di agenti condizionali o agenti custom con un prompt di validazione dedicato, inseriti nel punto del flusso in cui servono. Un agente condizionale può, ad esempio, valutare l’output prima che venga inviato all’utente e decidere se lasciarlo passare, correggerlo o bloccarlo in base a una policy scritta in linguaggio naturale, specifica per quel processo aziendale.
Questo livello è quello che rende i guardrail non solo uno strumento di sicurezza generico, ma un vero strumento di governance del comportamento dell’agente, calibrato sulle regole reali di ogni singola azienda, e non su un set fisso di categorie predefinite.
Guardrails nativi vs guardrails custom: quando usare cosa
Non tutti i guardrails servono allo stesso scopo, e non tutti vanno configurati allo stesso modo. I tre livelli nativi sono pensati per coprire rischi trasversali, comuni a qualsiasi agente conversazionale: sono già attivi, non richiedono configurazione manuale, e agiscono come base di sicurezza minima per ogni flusso.
I guardrails custom, al contrario, hanno senso quando il rischio da mitigare è specifico del dominio o del processo aziendale: una policy di comunicazione particolare, un vincolo normativo di settore, un caso limite emerso dall’analisi delle conversazioni reali. In questi casi vale la pena costruire un agente condizionale dedicato, con un prompt che descrive esattamente cosa verificare e come comportarsi in caso di violazione.
Nella pratica, i sistemi più solidi combinano entrambi i livelli: la protezione di base che non richiede intervento, e i controlli su misura costruiti man mano che si osservano nuovi rischi durante l’uso reale della piattaforma.
Guardrails e osservabilità: sapere sempre cosa è stato bloccato e perché
Un guardrail che blocca qualcosa senza lasciare traccia è utile solo a metà. Se un utente riceve un messaggio generico di rifiuto e il team non ha modo di capire quale guardrail è intervenuto, su quale contenuto, e perché, si perde la possibilità di distinguere un blocco corretto da un falso positivo, cioè un caso in cui il guardrail ha bloccato qualcosa che invece andava lasciato passare.
Per questo, come per ogni altro blocco del flusso, anche l’attivazione di un guardrail è tracciata e osservabile nella sezione Conversazioni di Userbot 3.0: si può vedere se un filtro è intervenuto esattamente come per gli altri blocchi del flusso descritti nel nostro articolo sull’osservabilità degli agenti AI. Questo permette non solo di verificare che i guardrails stiano funzionando, ma anche di affinarli nel tempo: se un guardrail custom blocca troppe richieste legittime, il prompt di validazione può essere corretto sulla base di casi reali, non di ipotesi.
I guardrails non sono un limite: sono ciò che rende un agente affidabile
C’è un modo sbagliato di pensare ai guardrails: come un vincolo che limita le capacità dell’agente, qualcosa che “lo rende meno intelligente” o meno utile. È il contrario. Un agente senza guardrails non è più libero: è semplicemente più imprevedibile, e l’imprevedibilità, in un contesto aziendale, non è un vantaggio.
I guardrails sono ciò che permette di portare un agente AI in produzione con la certezza che risponderà nei limiti definiti, anche quando l’input è ostile, ambiguo o inaspettato. Sono anche, sempre di più, un requisito che va oltre la scelta tecnica: con l’entrata in vigore di obblighi normativi come quelli dell’AI Act, dimostrare che un sistema conversazionale ha controlli verificabili sui contenuti che genera non è più solo buona pratica, ma parte della conformità.
In Userbot 3.0, i tre livelli di guardrails nativi coprono i rischi comuni a ogni agente fin dal primo giorno, e lo strato di guardrails custom permette di adattare la protezione alle regole specifiche di ogni azienda. Il risultato è un agente che non si limita a “provare a comportarsi bene“: è costruito perché non possa fare altrimenti.
possiamo aiutarti?
il nostro team è a tua disposizione.
