Guardrail AI: come controllare risposte e azioni degli agenti

I guardrail AI vanno distribuiti lungo 5 punti di controllo: richieste in ingresso, contesto recuperato, proposte del modello, azioni degli strumenti e risposte in uscita. I filtri sui contenuti possono intercettare una risposta vietata; spetta comunque all'applicazione stabilire se il cliente può accedere a un record o autorizzare un rimborso. Per un piccolo team, definire questi permessi viene prima di aggiungere altri classificatori.

Che cosa sono i guardrail AI?

I guardrail traducono le regole scritte in controlli su ciò che un'applicazione AI può ricevere, rivelare o fare. Un modello linguistico di grandi dimensioni, o LLM, genera risposte e proposte di azione; i guardrail ne verificano gli input e gli output oppure impongono vincoli al software che lo circonda.

Pensiamo a un museo. All'ingresso si controllano i biglietti, le singole sale hanno regole di accesso e un restauratore deve essere autorizzato a spostare un'opera. Aver controllato il biglietto di una persona non significa averle consentito qualsiasi azione nell'edificio. Allo stesso modo, un messaggio innocuo non dimostra che un ordine appartenga al cliente che scrive.

Per rendere operativo un guardrail servono tre elementi: una regola, una verifica e una conseguenza. «Non esporre i dati dei clienti» è una regola. Confrontare il titolare del record richiesto con il cliente autenticato è una verifica. Negare la lettura del database è la conseguenza. Una voce di log, senza un blocco effettivo, si limita a registrare il problema dopo che si è verificato.

Alcune verifiche sono deterministiche: a parità di regole e input producono la stessa decisione. Ne sono esempi i nomi degli strumenti consentiti e i campi obbligatori. Altre si affidano a classificatori, cioè modelli che stimano se un contenuto violi una regola. Rientrano in questo gruppo il riconoscimento degli argomenti e la classificazione dei contenuti dannosi. L'approvazione umana aggiunge una valutazione prima di un'azione consentita ma dalle conseguenze rilevanti.

AI guardrails è il nome di questo insieme di controlli. Guardrails AI è uno specifico framework che ne fa parte. Confondere la categoria con un prodotto può lasciare punti critici senza un responsabile.

Guardrail AI in pratica: una richiesta di rimborso dall'inizio alla fine

Una richiesta di rimborso richiede controlli diversi in momenti diversi, anche quando è formulata in modo del tutto ordinario. Consideriamo questo ipotetico messaggio di un cliente: «Vorrei il rimborso del mio ultimo ordine e la conferma via email al mio nuovo indirizzo». Supponiamo che le regole prevedano un'approvazione prima di ogni rimborso e l'invio delle conferme solo a un indirizzo verificato dell'account.

Il percorso della richiesta è: controlli sull'input → contesto limitato all'ambito consentito → proposta del modello → azione autorizzata e approvata → controlli sull'output. Ogni successiva chiamata a uno strumento ripete le verifiche pertinenti.

Prima del modello: autenticare, filtrare e ridurre i dati

Il primo passo è identificare il cliente attraverso la sessione autenticata, senza affidarsi a un nome o a un identificativo dell'account digitato in chat. Imporre limiti alla dimensione e alla frequenza delle richieste prima delle elaborazioni più costose.

Poi verificare se il messaggio contiene contenuti vietati, argomenti fuori ambito o dati sensibili non necessari. Un filtro tematico può impedire a un assistente di supporto di dare consigli estranei al suo compito. Un filtro sui dati personali può rimuovere un numero di telefono incollato nel messaggio quando non serve. PII indica le informazioni che consentono di identificare una persona, come un indirizzo email o un numero di telefono.

Non eliminare le informazioni effettivamente necessarie al flusso di lavoro senza offrire un percorso alternativo. Conservare nell'applicazione i dati verificati dell'account e passare al modello solo il contesto minimo utile. Mascherare il testo prima di una chiamata al modello, inoltre, non elimina le copie già acquisite nei log delle richieste: la minimizzazione deve riguardare anche la raccolta e la registrazione dei dati.

Prima del recupero dei dati: limitare i record accessibili

Recuperare l'ordine del cliente con una query circoscritta al suo account. La restrizione deve agire prima che i contenuti privati raggiungano il modello. Un filtro sull'output interviene troppo tardi per costituire la barriera principale tra i record di clienti diversi.

Documenti recuperati, pagine web e risultati degli strumenti sono ulteriori input. Un articolo di assistenza può contenere un'istruzione che tenta di scavalcare le regole dell'applicazione: è il problema noto come prompt injection indiretta. Il testo recuperato va trattato come materiale da esaminare, non come un'autorizzazione a modificare il flusso di lavoro.

Al modello possono servire le condizioni di reso e l'idoneità dell'ordine al rimborso. Non gli servono le transazioni di tutti i clienti. Limitare l'ambito del recupero, eliminare i campi superflui e verificare i rischi pertinenti nei contenuti selezionati.

Nel modello: vincolare la proposta

Chiedere al modello una proposta strutturata con campi noti, come l'azione richiesta e l'identificativo dell'ordine. Validarne la struttura prima di interpretarla.

Un JSON conforme allo schema dimostra soltanto che i dati hanno una forma accettabile. Anche un identificativo d'ordine inventato può essere una stringa valida. Non consentire al modello di stabilire l'identità del cliente, l'idoneità al rimborso o lo stato di approvazione della propria proposta semplicemente compilando un campo.

In questo esempio, il modello può proporre un rimborso e rilevare la richiesta di cambio indirizzo. È l'applicazione a dover decidere se ciascuna azione sia consentita.

Prima di eseguire uno strumento: verificare autorizzazioni e approvazione

Uno strumento è una funzione dell'applicazione che il modello può chiedere di eseguire. Prima di avviare la funzione di rimborso, verificarne il nome e gli argomenti, controllare che l'ordine appartenga al cliente, leggerne lo stato attuale e accertare che soddisfi le regole aziendali. Rifiutare i campi inattesi e applicare gli stessi controlli nel servizio che esegue l'azione.

L'approvazione umana deve intervenire dopo che esiste una proposta precisa e prima che l'azione produca effetti. Mostrare a chi approva l'ordine, il rimborso previsto, la destinazione e il motivo. Vincolare l'approvazione a quella specifica azione. Se gli argomenti cambiano, l'approvazione precedente non autorizza più l'esecuzione.

Il nuovo indirizzo email pone un problema di autorizzazione distinto. In questo esempio, l'applicazione indirizza il cliente alla procedura di verifica dell'account e continua a usare l'indirizzo già verificato finché la procedura non è conclusa. Un filtro sui contenuti non può accertare la titolarità di un account email.

Prima di inviare la risposta: verificare risultati e informazioni divulgate

Esaminare i risultati degli strumenti prima di reinserirli nel contesto del modello. Limitare i campi restituiti, verificarne la struttura e gestire esplicitamente le operazioni fallite o dall'esito ambiguo.

Controllare poi che la risposta destinata al cliente non contenga contenuti vietati, informazioni sensibili o affermazioni prive di riscontro e che rispetti la struttura richiesta. «Il rimborso è stato completato» deve dipendere da un risultato confermato dello strumento. Se l'approvazione è ancora in attesa, la risposta deve dirlo.

I controlli sull'input e sull'output possono usare classificatori simili, ma svolgono compiti diversi: i primi decidono che cosa entra nell'elaborazione; gli ultimi che cosa arriva al cliente. Nessuno dei due può annullare un'azione non autorizzata già eseguita.

Strumenti per i guardrail AI: che cosa documentano i fornitori

Scegliere uno strumento in base al punto in cui aiuta a far rispettare le regole e alle regole che si è disposti a mantenere. La mappa delle funzionalità qui sotto è stata verificata sulla documentazione online dei fornitori il 17 ottobre 2026. Confronta gli ambiti documentati, non l'accuratezza di rilevamento misurata.

Di seguito, per ciascuno strumento, sono riportati i link alle fonti e i limiti di implementazione. La colonna sulle responsabilità del team descrive le conseguenze architetturali degli ambiti documentati: non implica che un framework impedisca di scrivere controlli personalizzati.

Che cos'è Guardrails AI?

Guardrails AI è un framework Python che combina validatori attorno agli input e agli output del modello e genera dati strutturati. L'introduzione ne descrive il funzionamento e la raccolta di validatori.

Un validatore verifica un valore rispetto a un criterio e restituisce un esito positivo o negativo; la policy on_fail configurata stabilisce come gestire l'esito negativo. La documentazione include esempi relativi al linguaggio tossico e alle PII e consente di creare validatori personalizzati. Concetti di base sui validatori.

È adatto quando regole di validazione esplicite si inseriscono bene in un'applicazione Python esistente. Il limite è la copertura: aggiungere un framework non stabilisce quali controlli vengano eseguiti in ogni percorso né che cosa venga impedito in caso di errore. Queste decisioni vanno definite e testate insieme all'applicazione.

NVIDIA NeMo Guardrails

NVIDIA NeMo Guardrails offre controlli programmabili in diverse fasi dell'interazione con un LLM. I tipi di rail documentati comprendono input, recupero, dialogo, esecuzione e output.

I rail di input possono occuparsi di sicurezza dei contenuti, jailbreak, argomenti e PII; quelli di recupero verificano il contesto; quelli di dialogo vincolano il flusso della conversazione. I rail di esecuzione possono validare input e risultati degli strumenti, mentre quelli di output possono filtrare, modificare o bloccare le risposte.

È adatto quando serve controllare il flusso dell'interazione. Il limite è l'implementazione delle regole: i rail di esecuzione offrono un punto in cui verificare le azioni, ma il codice dell'applicazione deve fornire le regole aziendali e i controlli di appartenenza dei dati al cliente. Gli stessi permessi devono essere fatti rispettare anche dal servizio sottostante.

Amazon Bedrock Guardrails

Amazon Bedrock Guardrails offre filtri configurabili per contenuti, argomenti vietati, parole e informazioni sensibili, oltre a controlli di contextual grounding e Automated Reasoning. I filtri sulle informazioni sensibili possono bloccare o mascherare le PII supportate e i pattern personalizzati; i controlli di Automated Reasoning valutano le risposte rispetto a regole logiche. Panoramica delle protezioni.

L'API ApplyGuardrail valuta il testo indipendentemente dall'invocazione di un modello fondazionale. Può essere inserita prima del recupero dei dati o prima di inviare una risposta.

È una soluzione adatta a chi cerca controlli gestiti sulle regole applicative. Il limite è presumere che ogni controllo copra ogni contenuto: le funzionalità hanno ambiti specifici e la panoramica esclude i blocchi di contenuto di ragionamento. Superare una valutazione dei contenuti non autorizza comunque un rimborso.

Sicurezza AI: i controlli dei produttori di modelli

OpenAI moderation classifica i contenuti dannosi negli input testuali e visivi supportati e restituisce segnalazioni, categorie e punteggi. La documentazione sulla moderazione avverte anche che un rifiuto in cui si parla di contenuti dannosi può attivare una segnalazione.

Questi risultati vanno trattati come segnali su cui basare le decisioni. Una conversazione di assistenza che cita un messaggio offensivo può richiedere una gestione diversa da una richiesta di generarne uno. La moderazione aiuta a decidere sui contenuti; non fornisce le regole di accesso agli ordini.

Google Gemini espone impostazioni di sicurezza che associano categorie di rischio e soglie di blocco. L'attuale guida alle impostazioni di sicurezza include categorie quali molestie, incitamento all'odio, contenuti sessuali, contenuti pericolosi e jailbreak.

Google distingue la probabilità di contenuti non sicuri dalla gravità del danno potenziale. È un limite concreto: un punteggio basso del classificatore non dimostra che un'azione avrebbe conseguenze lievi. I controlli del fornitore sono componenti utili, ma l'applicazione ha comunque bisogno di permessi, limiti all'accesso ai dati e gestione degli errori.

Guardrail per gli agenti AI: che cosa va progettato

Un agente ha bisogno di un confine effettivo tra la proposta di un'azione e la sua esecuzione. Che sia implementato tramite gli hook di un framework o normale codice di servizio, questo controllo deve basarsi su un'identità attendibile e sullo stato attuale dell'applicazione.

Mantenere un elenco esplicito degli strumenti consentiti e verificare argomenti e risorsa di destinazione a ogni invocazione. Il fatto che l'azione «rimborso» sia consentita non rende rimborsabile qualsiasi ordine. Anche una shell generica o uno strumento con accesso illimitato alla rete ampliano le azioni possibili ben oltre una funzione aziendale circoscritta.

L'approvazione deve diventare un record che il sistema fa rispettare, non un «sì» in una conversazione. Registrare che cosa è stato approvato, da chi e per quali dettagli dell'azione. Ricontrollare lo stato prima dell'esecuzione: un ordine potrebbe essere già stato rimborsato mentre il revisore stava decidendo.

Il servizio deve far rispettare una chiave di idempotenza: un identificativo stabile dell'operazione che, in caso di nuovo tentativo, restituisce il risultato esistente anziché emettere un altro rimborso. Limitare i privilegi delle credenziali e tenere il percorso di applicazione dei controlli fuori dal controllo del modello. L'agente non deve poter scegliere un secondo endpoint che aggiri la verifica.

La nostra guida ai guardrail degli agenti AI in produzione e al contenimento dei danni approfondisce l'architettura circostante. Per questa richiesta, la domanda decisiva è semplice: se il modello propone l'azione sbagliata, quale servizio si rifiuta di eseguirla?

I limiti da conoscere prima del rilascio

I nomi delle funzionalità promettono spesso un ambito più ampio delle loro condizioni operative. Verificare la portata dello specifico controllo che si intende usare.

Per esempio, AWS documenta il contextual grounding per riassunti, parafrasi e risposte a domande con una fonte di riferimento e una query, escludendo esplicitamente i casi d'uso di domande e risposte conversazionali e chatbot. I massimi documentati sono 100,000 caratteri per la fonte, 1,000 per la query e 5,000 per la risposta. Sono limiti di caratteri di quella funzionalità, non limiti generali del contesto del modello né un divieto di usare altre protezioni di Bedrock con i chatbot. Documentazione sul contextual grounding.

Il grounding verifica se una risposta è coerente con la fonte fornita. Se la fonte è obsoleta o errata, la concordanza non basta a stabilire che la risposta sia vera. Nell'esempio del rimborso, lo stato attuale dell'ordine deve provenire dal servizio che ne è la fonte autorevole.

Lo streaming cambia il punto in cui applicare il controllo. AWS avverte che una decisione sulla pertinenza nel contextual grounding può arrivare dopo che una risposta è stata trasmessa in streaming. Più in generale, se una regola richiede di verificare l'intera risposta prima di mostrarla, trattenerla in un buffer finché il controllo non è superato. Un rifiuto successivo non può ritirare il testo già visualizzato.

Un timeout deve avere un esito definito. Se fallisce una verifica obbligatoria dei permessi o dell'approvazione, interrompere la modifica e offrire un percorso di attesa o di assistenza umana. Per le risposte a rischio inferiore, definire esplicitamente quale alternativa limitata sia accettabile. Il fallimento di un controllo non deve trasformarsi silenziosamente in un permesso di continuare.

Misurare la latenza aggiunta e i blocchi erronei sul proprio carico di lavoro. Nessun punteggio del fornitore sostituisce la verifica che i clienti legittimi riescano a completare il compito di assistenza effettivo.

Il set minimo di controlli per un piccolo team

Partire da sei controlli che si sappiano spiegare, mettere alla prova e assegnare a un responsabile. Non serve adottare tutti i framework della tabella.

1. 1

   Identità e ambito di accesso ai dati

   Usare il contesto del cliente autenticato per il recupero dei dati e gli strumenti. Verificare con un test che un cliente non possa leggere l'ordine di un altro, anche quando lo richiede il modello.

2. 2

   Regole sull'input e minimizzazione dei dati

   Definire il compito supportato, verificare i rischi pertinenti nei contenuti ed eliminare i campi sensibili non necessari. Scegliere una risposta sicura per le richieste fuori ambito.

3. 3

   Un contratto per l'output

   Validare i campi obbligatori, le regole sulle informazioni divulgabili e le affermazioni relative ad azioni completate. Se la risposta non ha riscontri affidabili, farle riconoscere l'incertezza o indirizzare il cliente all'assistenza.

4. 4

   Azioni circoscritte e approvazione

   Esporre strumenti con funzioni aziendali limitate. Verificare identità, argomenti e stato attuale prima dell'esecuzione; richiedere l'approvazione per le azioni che le regole considerano rilevanti per le loro conseguenze.

5. 5

   Gestione dei guasti e limiti operativi

   Impostare limiti a richieste, chiamate agli strumenti, nuovi tentativi e tempi di esecuzione adeguati al flusso di lavoro. Definire che cosa accade se fallisce un controllo obbligatorio o un servizio a valle. Validare nuovamente le proposte modificate e i nuovi tentativi.

6. 6

   Test di regressione e tracciabilità

   Registrare versioni delle regole, decisioni, esiti degli strumenti e riferimenti alle approvazioni senza copiare dati sensibili non necessari. Fare in modo che i casi noti di divulgazione o azione non autorizzata blocchino il rilascio.

Chi sviluppa deve intervenire subito se una funzionalità rivolta ai clienti legge record privati o può modificare lo stato del sistema. Implementare prima i permessi nei servizi. Chi gestisce il servizio deve assegnare un responsabile alle escalation, alle richieste legittime bloccate e ai controlli non disponibili. Una coda senza qualcuno che se ne occupi è un flusso di lavoro incompleto.

Chi acquista dovrebbe rimandare l'aggiunta di un altro prodotto per i guardrail finché non è chiaro quale punto di controllo manca. Un assistente che consulta documenti pubblici e non dispone di strumenti di scrittura non ha bisogno di un flusso di approvazione dei rimborsi. Ha comunque bisogno di controlli pertinenti sui contenuti, recupero affidabile delle informazioni e un percorso alternativo chiaro. I controlli sulle azioni diventano necessari quando le sue capacità si ampliano.

Testare l'applicazione con Promptfoo

Promptfoo è uno strumento di valutazione e red teaming: aiuta a testare sia il comportamento ordinario sia richieste deliberatamente ostili. La sua documentazione sui test degli agenti descrive verifiche sulle restrizioni di ruolo, sull'accesso non autorizzato agli oggetti e sull'accesso non autorizzato alle funzioni.

Eseguire i test sull'interfaccia dell'applicazione, usando identità e dati di prova rappresentativi. Testare il solo modello esclude i permessi di recupero, il flusso di approvazione e i servizi degli strumenti con cui i clienti interagiscono davvero.

Per l'ipotetico flusso di rimborso, partire da questi casi:

• Un ordine idoneo al rimborso: la proposta arriva alla fase di approvazione e l'esecuzione attende il via libera.
• L'ordine di un altro cliente: sia il recupero sia l'esecuzione negano l'accesso.
• Un indirizzo di conferma modificato: l'applicazione richiede la procedura di verifica separata.
• Istruzioni nascoste nei contenuti recuperati: non possono concedere permessi né modificare le regole di approvazione.
• Una proposta modificata dopo l'approvazione: l'approvazione precedente non può autorizzare i nuovi argomenti.
• Un controllo non disponibile o una richiesta ripetuta: i controlli obbligatori non vengono aggirati e la stessa operazione non viene eseguita due volte.

Questi sono casi di test proposti, non risultati di test eseguiti. Esaminare gli effetti prodotti e lo stato memorizzato, oltre alla risposta finale. «Non posso farlo» non rassicura se lo strumento l'ha già fatto.

La guida rapida di Promptfoo illustra la configurazione del sistema da testare, le categorie di attacco, l'esecuzione dei test e l'analisi del report. La nostra recensione di Promptfoo approfondisce il flusso di valutazione. Affiancare ai casi ostili le normali richieste dei clienti, per evitare che filtri più severi compromettano silenziosamente il compito utile.

Quali promesse sono esagerate?

Un prodotto per i guardrail non è un interruttore universale della sicurezza. Il suo valore dipende da che cosa verifica, dove interviene e che cosa impedisce la sua decisione.

Un system prompt più lungo può esprimere una regola, ma non può far rispettare i permessi del database. Un secondo modello può valutare criticamente una risposta, ma l'accordo tra modelli non ne dimostra la correttezza. Aggiungere classificatori può anche aumentare i blocchi erronei e il lavoro operativo senza colmare l'assenza di un controllo sulle azioni.

Il punto di partenza più solido è un piccolo insieme di controlli espliciti, collegati a casi concreti di malfunzionamento. Aggiungere una verifica quando copre una lacuna dimostrata; misurare se migliora il risultato.

AI senza guardrail: quali controlli mancano?

Per una funzionalità rivolta ai clienti, la domanda utile è quali controlli siano assenti. Un'applicazione può disporre dei filtri sui contenuti del fornitore e, al tempo stesso, non avere permessi specifici per cliente, validazione dell'output o approvazioni vincolanti. Definirla «protetta» nasconde queste lacune.

Viceversa, un'applicazione con controlli di accesso deterministici può avere ancora bisogno di verifiche sui contenuti. La sicurezza dei contenuti e l'autorizzazione delle azioni sono requisiti distinti; nessuna etichetta risponde a entrambi.

Domande frequenti

Quali sono i tipi di guardrail AI?

Per l'implementazione, una suddivisione utile comprende controlli sull'input, sul contesto recuperato e sull'output, controlli sull'esecuzione degli strumenti e approvazione umana. I filtri tematici e sulle PII possono intervenire in più di uno di questi punti.

Come si creano i guardrail AI?

Identificare un esito da impedire, inserire una verifica prima della divulgazione o dell'azione pertinente, definire la risposta in caso di fallimento e testare l'intera applicazione. Assegnare a qualcuno la manutenzione delle regole e la gestione delle escalation.

Che cosa fa Guardrails AI?

Guardrails AI combina validatori in controlli su input e output e supporta la generazione di dati strutturati. La configurazione e il codice dell'applicazione determinano quali rischi vengono verificati e come si gestiscono gli esiti negativi.

Esiste un'AI senza guardrail?

Le applicazioni adottano controlli diversi. Prima del rilascio, verificare i singoli punti di controllo senza affidarsi a un'etichetta: le protezioni sui contenuti del modello non stabiliscono né le autorizzazioni del cliente né l'approvazione umana.

Quali sono i 3 principali rischi per la sicurezza AI?

Per questo esempio di assistenza clienti, partire da prompt injection, divulgazione non autorizzata di dati e azioni non autorizzate. È un ordine di priorità pratico per questo flusso di lavoro, non una classifica universale dei rischi dell'AI.

Da dove iniziare lunedì

Prendere una richiesta reale di un cliente e tracciarne il percorso dall'autenticazione alla risposta finale. In ogni punto di controllo, annotare la regola, il componente che la fa rispettare, la risposta in caso di fallimento e il responsabile. Prima di ampliare i permessi dell'agente, trasformare la lettura non autorizzata di un record e un'azione non approvata in test che bloccano il rilascio.

Ricevi guide pratiche per implementare l'AI con la newsletter.