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\u00e9 non ha fonti affidabili per farlo?<\/p>\n\n\n\n
Se la risposta \u00e8 “spero che il prompt regga<\/em>“, il problema non \u00e8 il prompt. \u00c8 che manca uno strato di protezione che non dovrebbe dipendere dalla fortuna, ma dal design del sistema.<\/p>\n\n\n\n I guardrails<\/strong> sono esattamente questo: un insieme di controlli che si frappongono tra l’utente, il modello e l’azienda, e che decidono cosa pu\u00f2 passare e cosa deve essere bloccato, prima o dopo che l’agente abbia generato una risposta. In questo articolo vediamo perch\u00e9 sono indispensabili in un agente AI in produzione, quali livelli di protezione sono gi\u00e0 integrati nativamente in Userbot 3.0<\/strong>, e come \u00e8 possibile aggiungerne altri su misura per il proprio caso d’uso.<\/p>\n\n\n\n Un modello linguistico, da solo, non sa cosa \u00e8 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<\/em>“.<\/p>\n\n\n\n Questo espone chi mette in produzione un agente AI a rischi molto concreti: <\/p>\n\n\n\n Nessuno di questi problemi si risolve scrivendo “non rispondere a domande violente<\/em>” nel prompt di sistema. Serve uno strato separato, che agisca indipendentemente dal ragionamento del modello<\/strong>: \u00e8 qui che entrano in gioco i guardrails.<\/p>\n\n\n\n Un prompt \u00e8 un’istruzione, non un controllo. Pu\u00f2 essere aggirato, frainteso, o semplicemente non bastare di fronte a un input costruito apposta per confonderlo.<\/p>\n<\/blockquote>\n\n\n\n Un guardrail<\/strong> \u00e8 un controllo che si pu\u00f2 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 \u00e8 la stessa: verificare qualcosa secondo criteri definiti, e decidere se lasciar proseguire, correggere, o bloccare<\/strong>.<\/p>\n\n\n\n La differenza rispetto a un’istruzione nel prompt \u00e8 sostanziale. Un’istruzione (“non parlare di argomenti violenti”) \u00e8 una richiesta rivolta al modello, che il modello interpreta e a cui il modello pu\u00f2, in certi casi, non attenersi con coerenza, soprattutto se l’input \u00e8 costruito per aggirarla. <\/p>\n\n\n\n Un guardrail \u00e8 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.<\/p>\n\n\n\n Per questo un’architettura agentica seria non si affida a un solo livello di guardrails, ma a pi\u00f9 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<\/strong> questi livelli sono gi\u00e0 integrati nella piattaforma, e si possono estendere con configurazioni personalizzate.<\/p>\n\n\n\n Un prompt \u00e8 un’istruzione. Un guardrail \u00e8 un controllo. Solo uno dei due non si aggira semplicemente chiedendo con le parole giuste.<\/em><\/p>\n<\/blockquote>\n\n\n\n Il primo livello di protezione agisce sui contenuti in senso stretto, ed \u00e8 basato sul filtro di Azure AI Content Safety<\/strong>, 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<\/strong>.<\/p>\n\n\n\n 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 \u00e8 un filtro opzionale da configurare manualmente: \u00e8 un livello di sicurezza di base che protegge ogni conversazione gestita dalla piattaforma, indipendentemente dal settore o dal caso d’uso.<\/p>\n\n\n\n Questo tipo di controllo \u00e8 particolarmente rilevante nei contesti di customer service<\/strong> aperti al pubblico, dove non si pu\u00f2 prevedere in anticipo cosa scriver\u00e0 un utente, e dove anche un singolo episodio gestito male ha un costo reputazionale reale.<\/p>\n\n\n\n Il secondo livello riguarda un elemento diverso, e pi\u00f9 tecnico, dell’architettura di Userbot: il blocco di codice Python<\/strong> che pu\u00f2 essere inserito all’interno di un workflow agentico per eseguire logica custom, calcoli, trasformazioni di dati o chiamate a servizi esterni.<\/p>\n\n\n\n Un blocco che esegue codice \u00e8, 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<\/strong>, per provare ad accedere a dati del sistema a cui non dovrebbe avere accesso, o pi\u00f9 in generale per far agire il codice contro il prodotto stesso invece che a supporto del workflow.<\/p>\n\n\n\n Per questo, in Userbot, il blocco di codice Python non si limita a essere eseguito in sandbox isolata<\/strong>: al suo interno \u00e8 integrato un guardrail dedicato<\/strong>, 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 \u00e8 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\u00e0 della piattaforma che non dovrebbero essere raggiungibili da quel punto del workflow.<\/p>\n\n\n\n \u00c8 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.<\/p>\n\n\n\n Questo tipo di protezione diventa via via pi\u00f9 importante quanto pi\u00f9 un agente ha accesso a tool<\/strong> 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\u00f2 tradursi in un’azione indesiderata su un sistema aziendale.<\/p>\n\n\n\n Il terzo livello riguarda un problema pi\u00f9 sottile, tipico dei sistemi RAG<\/strong>: cosa succede quando la ricerca semantica restituisce risultati che assomigliano alla domanda, ma non la soddisfano davvero?<\/p>\n\n\n\n Un retriever<\/a><\/strong> lavora per similarit\u00e0 vettoriale: trova i chunk di documento pi\u00f9 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 \u00e8 una risposta che sembra fondata, ma non lo \u00e8: uno dei rischi pi\u00f9 insidiosi nei sistemi basati su knowledge base, perch\u00e9 non si presenta come un errore evidente.<\/p>\n\n\n\n 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\u00f2 gestire il caso in modo esplicito, ad esempio segnalando che non ha informazioni sufficienti o passando la mano a un altro flusso.<\/p>\n\n\n\n \u00c8 un guardrail meno visibile degli altri due, perch\u00e9 non riguarda contenuti “vietati” in senso classico, ma \u00e8 altrettanto importante: protegge l’affidabilit\u00e0 delle risposte, non solo la loro appropriatezza.<\/p>\n\n\n\n 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\u00f2 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.<\/p>\n\n\n\n Per questi casi, Userbot permette di costruire guardrails su misura<\/strong>, sotto forma di agenti condizionali<\/strong> o agenti custom<\/strong> con un prompt di validazione dedicato, inseriti nel punto del flusso in cui servono. Un agente condizionale pu\u00f2, 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.<\/p>\n\n\n\n Questo livello \u00e8 quello che rende i guardrail non solo uno strumento di sicurezza generico, ma un vero strumento di governance del comportamento dell’agente<\/strong>, calibrato sulle regole reali di ogni singola azienda, e non su un set fisso di categorie predefinite.<\/p>\n\n\n\n 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\u00e0 attivi, non richiedono configurazione manuale, e agiscono come base di sicurezza minima<\/strong> per ogni flusso.<\/p>\n\n\n\n I guardrails custom, al contrario, hanno senso quando il rischio da mitigare \u00e8 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.<\/p>\n\n\n\n Nella pratica, i sistemi pi\u00f9 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.<\/p>\n\n\n\n Un guardrail che blocca qualcosa senza lasciare traccia \u00e8 utile solo a met\u00e0. Se un utente riceve un messaggio generico di rifiuto e il team non ha modo di capire quale guardrail \u00e8 intervenuto, su quale contenuto, e perch\u00e9, si perde la possibilit\u00e0 di distinguere un blocco corretto da un falso positivo<\/strong>, cio\u00e8 un caso in cui il guardrail ha bloccato qualcosa che invece andava lasciato passare.<\/p>\n\n\n\n Per questo, come per ogni altro blocco del flusso, anche l’attivazione di un guardrail \u00e8 tracciata e osservabile<\/strong> nella sezione Conversazioni<\/strong> di Userbot 3.0: si pu\u00f2 vedere se un filtro \u00e8 intervenuto esattamente come per gli altri blocchi del flusso descritti nel nostro articolo sull’osservabilit\u00e0 degli agenti AI<\/a>. Questo permette non solo di verificare che i guardrails stiano funzionando, ma anche di affinarli nel tempo<\/strong>: se un guardrail custom blocca troppe richieste legittime, il prompt di validazione pu\u00f2 essere corretto sulla base di casi reali, non di ipotesi.<\/p>\n\n\n\n C’\u00e8 un modo sbagliato di pensare ai guardrails: come un vincolo che limita le capacit\u00e0 dell’agente, qualcosa che “lo rende meno intelligente<\/em>” o meno utile. \u00c8 il contrario. Un agente senza guardrails non \u00e8 pi\u00f9 libero: \u00e8 semplicemente pi\u00f9 imprevedibile<\/strong>, e l’imprevedibilit\u00e0, in un contesto aziendale, non \u00e8 un vantaggio.<\/p>\n\n\n\n I guardrails sono ci\u00f2 che permette di portare un agente AI in produzione con la certezza che risponder\u00e0 nei limiti definiti, anche quando l’input \u00e8 ostile, ambiguo o inaspettato. Sono anche, sempre di pi\u00f9, un requisito che va oltre la scelta tecnica: con l’entrata in vigore di obblighi normativi come quelli dell’AI Act<\/a><\/strong>, dimostrare che un sistema conversazionale ha controlli verificabili sui contenuti che genera non \u00e8 pi\u00f9 solo buona pratica, ma parte della conformit\u00e0.<\/p>\n\n\n\n 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 \u00e8 un agente che non si limita a “provare a comportarsi bene<\/strong>“: \u00e8 costruito perch\u00e9 non possa fare altrimenti.<\/p>\n\n\n\nPerch\u00e9 un agente AI senza guardrails non \u00e8 pronto per la produzione<\/h2>\n\n\n\n
\n
\n
Cosa sono davvero i guardrails (e perch\u00e9 “un buon prompt” non basta)<\/h2>\n\n\n\n
\n
I livelli di guardrails nativi in Userbot 3.0<\/h2>\n\n\n\n
1. Filtro Azure: violenza, contenuti sessuali, odio, self-harm<\/h3>\n\n\n\n
2. Blocco codice Python: la difesa contro prompt injection<\/h3>\n\n\n\n
3. Validare (o scartare) i risultati della ricerca semantica<\/h3>\n\n\n\n
4. Guardrails su misura: agenti con prompt personalizzati<\/h3>\n\n\n\n
Guardrails nativi vs guardrails custom: quando usare cosa<\/h2>\n\n\n\n
Guardrails e osservabilit\u00e0: sapere sempre cosa \u00e8 stato bloccato e perch\u00e9<\/h2>\n\n\n\n
I guardrails non sono un limite: sono ci\u00f2 che rende un agente affidabile<\/h2>\n\n\n\n
\n\n\n\n