NeMo vs Llama Guard vs Guardrails AI: F1 fino a 0,99 [2026]

Nel 2026 quasi ogni applicazione costruita sopra un modello linguistico deve rispondere a una domanda scomoda: cosa succede se qualcuno prova a manipolarla? Gli attacchi di prompt injection, sia quelli scritti direttamente in chat sia quelli nascosti dentro un documento, un’email o un ticket che un agente elabora, sono passati da curiosità da conferenza a rischio operativo concreto. Le aziende che costruiscono chatbot, assistenti RAG o agenti autonomi hanno iniziato a inserire uno strato di controllo tra l’utente e il modello: i cosiddetti guardrail, filtri che intercettano input e output sospetti prima che raggiungano il modello o l’utente finale.

Il problema è che il mercato dei guardrail per LLM si è affollato in fretta. I tre nomi che tornano più spesso nelle discussioni tecniche sono NeMo Guardrails di NVIDIA, Llama Guard di Meta e Guardrails AI. A questi si aggiungono alternative come LLM Guard di Protect AI e servizi cloud gestiti come Azure AI Content Safety e AWS Bedrock Guardrails. Questo confronto mette sul tavolo licenze, numeri di GitHub verificati in tempo reale, benchmark pubblicati da fonti indipendenti, prezzi reali e casi d’uso concreti, con l’obiettivo di aiutare chi deve scegliere uno di questi strumenti prima della fine del 2026.

Cosa sono i guardrail per gli LLM e perché nel 2026 sono indispensabili

Un guardrail per un modello linguistico è, in sostanza, un filtro applicato prima o dopo la generazione del testo. I filtri di input controllano ciò che l’utente, o un documento ingerito da un agente, invia al modello, cercando i pattern tipici del jailbreak o dell’iniezione di comandi nascosti. I filtri di output controllano invece la risposta del modello, bloccando contenuti tossici, fughe di dati personali o violazioni di policy aziendali prima che arrivino a chi ha fatto la richiesta.

Gli specialisti di sicurezza distinguono due famiglie di strumenti. Gli scanner, come Garak (NVIDIA, licenza Apache 2.0), PyRIT (Microsoft, licenza MIT), Promptfoo (MIT), FuzzyAI (CyberArk) e Augustus di Praetorian, arrivato a febbraio 2026 con oltre 210 probe distribuiti su 47 categorie di attacco e supporto per 28 provider LLM, si usano prima del deploy, durante i test di sicurezza. Servono a scoprire le debolezze di un’applicazione simulando attacchi, non a bloccarli in tempo reale.

I detector inline, al contrario, girano in produzione e intercettano ogni richiesta mentre transita nel sistema. È qui che si collocano NeMo Guardrails, Guardrails AI, Llama Guard e LLM Guard, framework pensati per stare tra l’utente e il modello, o tra il modello e uno strumento esterno che l’agente può chiamare, a ogni singola interazione.

La distinzione conta perché nel 2026 gli agenti AI non si limitano più a rispondere a domande: chiamano API, leggono email, eseguono codice. L’OWASP Top 10 per le applicazioni basate su LLM elenca la prompt injection come rischio numero uno da anni, e la diffusione crescente di agenti che ingeriscono contenuto non fidato ha spinto progetti come StackOne Defender a costruire librerie dedicate proprio all’injection indiretta, quella nascosta dentro dati che l’agente processa senza che l’utente li digiti direttamente. Per un’azienda europea, scegliere il guardrail giusto non è più solo una questione tecnica: incide su conformità GDPR, gestione del rischio secondo l’AI Act e su chi controlla i dati che passano attraverso il modello.

NeMo Guardrails di NVIDIA: architettura e stato di maturazione

NeMo Guardrails nasce nei laboratori NVIDIA e viene distribuito con licenza Apache 2.0, il che lo rende completamente self-hostabile senza vincoli commerciali. La sua caratteristica distintiva è il livello a cui applica i controlli: non solo al turno di conversazione, ma anche al singolo chunk recuperato da un sistema RAG e alla singola chiamata di tool da parte di un agente. Per un’azienda che collega un assistente a un database interno o a strumenti esterni, questo significa poter bloccare un documento sospetto prima che entri nel contesto del modello, non solo filtrare la risposta finale.

Interrogando direttamente l’API di GitHub il 18 settembre 2026, il repository NVIDIA-NeMo/Guardrails mostra 7.165 star e l’ultima release pubblicata è la v0.24.1, uscita appena due giorni prima, il 16 settembre 2026. È un ritmo di rilascio molto sostenuto, segno di un progetto ancora in evoluzione rapida più che di un prodotto stabilizzato.

C’è però un avvertimento che chi valuta NeMo Guardrails per un progetto critico non può ignorare. La documentazione ufficiale del progetto ha per lungo tempo descritto il toolkit come non raccomandato per la produzione così com’è, sottolineando che un deployment reale richiede un lavoro di hardening aggiuntivo rispetto alla configurazione di base. NVIDIA suggerisce di distribuirlo tramite server API locale, container Docker o microservizi dedicati, senza però fornire garanzie di stabilità paragonabili a un prodotto enterprise maturo.

Sul fronte delle prestazioni, NVIDIA ha pubblicato una nota secondo cui orchestrare fino a cinque guardrail accelerati su GPU in parallelo porta a un miglioramento di 1,4 volte nel tasso di rilevamento delle minacce, al costo di circa 0,5 secondi di latenza aggiuntiva sulla risposta finale. È un compromesso ragionevole per un assistente interno, meno per un chatbot pubblico dove ogni frazione di secondo di attesa pesa sulla conversione.

Llama Guard di Meta: il classificatore più diffuso, con qualche limite di licenza

Llama Guard, il classificatore di sicurezza sviluppato da Meta, resta il punto di riferimento per chi vuole un modello dedicato a rilevare contenuti pericolosi secondo una taxonomy di rischio predefinita, ed è arrivato alla quarta generazione. A differenza di NeMo Guardrails e Guardrails AI, i modelli Llama Guard 4 sono distribuiti sotto la Llama Community License: si possono scaricare, modificare e ospitare in autonomia, ma non si tratta di una licenza open source riconosciuta dalla Open Source Initiative, e porta condizioni d’uso specifiche di Meta. Le guide comparative del 2026 descrivono spesso questa differenza come la scelta tra possedere i propri guardrail (Apache 2.0) e prenderli in prestito secondo le condizioni di un vendor.

Il repository meta-llama/PurpleLlama, che ospita l’implementazione di Llama Guard insieme ad altri strumenti di sicurezza di Meta, segnava 4.400 star alla verifica del 18 settembre 2026 tramite l’API di GitHub. È un numero più basso di NeMo Guardrails e Guardrails AI, ma va letto insieme al fatto che Llama Guard non è un progetto community-driven: è un modello pubblicato da un’azienda che ne mantiene il controllo tramite licenza.

Sul piano prestazionale, lo studio accademico “No Free Lunch With Guardrails”, pubblicato su arXiv, ha misurato F1 e latenza di Llama-Guard su più batterie di benchmark. Su una prima batteria (PHTest, un sottoinsieme del benchmark di Guardrails AI, Arena, Awesome e NoRobots) il modello ottiene F1 di 0,971, 0,860, 0,975, 0,972 e 0,995, con una latenza media di 1,54 secondi. Su un’altra batteria di test gli stessi autori registrano punteggi F1 in calo, fino a 0,494, con una latenza di 0,959 secondi: la precisione di questi classificatori varia parecchio in base al tipo di contenuto testato, non è un numero fisso da citare senza contesto.

Le guide di produzione pubblicate nel 2026 riportano poi cifre diverse per le due taglie disponibili di Llama Guard 3: la variante da 1 miliardo di parametri raggiunge un p99 di 250 millisecondi su GPU T4, con F1 attorno a 0,87 sul benchmark interno di Meta sulla taxonomy dei rischi, mentre la variante da 8 miliardi sale a un p99 di 900 millisecondi con F1 vicino a 0,92. Più parametri significano più accuratezza, ma anche più attesa per l’utente finale.

Guardrails AI: l’opzione open source più componibile

Guardrails AI punta su un’idea diversa da quella di un unico modello monolitico che classifica tutto. Offre un framework componibile di “validator”, piccoli controlli specializzati, uno per il rilevamento di dati personali, uno per la tossicità, uno per le allucinazioni, uno per i tentativi di prompt attack, che si possono combinare in pipeline su misura. È distribuito con licenza Apache 2.0 e può funzionare sia come libreria Python integrata nel codice, sia come servizio REST self-hosted separato dall’applicazione principale.

Interrogando l’API di GitHub il 18 settembre 2026, il repository guardrails-ai/guardrails mostra 7.433 star, la cifra più alta tra i quattro framework open source di questo confronto, con licenza Apache 2.0 confermata e ultima release v0.11.0, pubblicata il 14 agosto 2026.

Sulla latenza, gli articoli di ingegneria pubblicati nel 2026 riportano numeri nettamente più bassi rispetto a NeMo Guardrails e Llama Guard quando i validator girano in locale: un singolo controllo richiede tra 20 e 200 millisecondi, mentre una pipeline con cinque guard concatenati arriva a 300-500 millisecondi su una macchina con 4 vCPU e 16 GB di RAM, senza bisogno di GPU dedicata. È l’opzione più leggera da far girare anche su infrastrutture modeste, un vantaggio concreto per chi non dispone di cluster NVIDIA dedicati.

Guardrails AI promuove anche una versione enterprise, Guardrails Pro, pensata per team che devono distribuire guardrail su scala attraverso l’infrastruttura AI di un’intera organizzazione. Non esistono però numeri pubblici sul numero di clienti o sul volume di richieste gestite in produzione: va considerata una posizione di marketing più che un dato verificabile, e su questo punto specifico conviene restare cauti.

LLM Guard, Rebuff e il resto dell’ecosistema open source

Oltre ai tre nomi principali, l’ecosistema open source per la sicurezza degli LLM comprende diversi altri progetti utili da conoscere. LLM Guard, sviluppato da Protect AI, si presenta come un toolkit con 15 scanner per l’input e 20 per l’output, pensato per intercettare tossicità, fughe di dati e tentativi di injection prima che raggiungano il modello o l’utente. Al 18 settembre 2026 il repository protectai/llm-guard conta 3.208 star, licenza MIT confermata via API, e l’ultimo tag pubblicato è v0.3.16: un ordine di grandezza sotto NeMo Guardrails e Guardrails AI in termini di popolarità.

Dal punto di vista della latenza, però, LLM Guard è il più rapido del gruppo quando si limita a controlli basati su classificatori leggeri: un singolo controllo di tossicità basato su un modello BERT gira in circa 45 millisecondi su CPU, e una pipeline con cinque guardie concatenate resta sotto i 120 millisecondi, secondo le misurazioni riportate da blog di ingegneria di produzione nel 2026.

Rebuff, un’altra libreria citata spesso negli elenchi di strumenti anti-injection, non dispone invece di benchmark pubblici comparabili su latenza o F1 pubblicati nel 2025-2026: le fonti disponibili ne descrivono le funzionalità ma senza numeri verificabili, un limite da tenere presente prima di sceglierlo per un progetto dove serve un dato quantitativo da presentare a un audit di sicurezza.

Due sviluppi più recenti meritano una menzione. InjecGuard, un modello prompt guard open source, dichiara un miglioramento del 30,8% rispetto al precedente stato dell’arte sul benchmark NotInject, concentrandosi sulla riduzione dei falsi positivi da over-defense, cioè i casi in cui il guardrail blocca richieste legittime scambiandole per attacchi. StackOne Defender, invece, è una libreria dedicata proprio all’injection indiretta nascosta in documenti, email e ticket che un agente consuma durante il suo lavoro, un rischio che i classificatori generalisti come Llama Guard non sono progettati per intercettare in modo specifico. Sul fronte degli standard, l’ecosistema comincia a fare riferimento a OWASP Agent Memory Guard, mappato sulla categoria ASI06 dedicata all’avvelenamento della memoria degli agenti, e al PIC Standard, un protocollo che vincola le azioni di un agente a controlli di intento e provenienza.

Guardrail cloud gestiti: Azure AI Content Safety e AWS Bedrock Guardrails

Chi non vuole gestire l’infrastruttura di un guardrail self-hosted può rivolgersi ai servizi cloud gestiti. Azure AI Content Safety copre la moderazione di contenuti d’odio, violenza, materiale sessuale e autolesionismo, e aggiunge i Prompt Shields, classificatori pensati per bloccare tentativi di jailbreak diretti e injection indiretta nascosta dentro documenti che il modello elabora. È un’API completamente gestita da Microsoft, fatturata a consumo, che si integra naturalmente con chi ha già un’infrastruttura Azure.

AWS Bedrock Guardrails segue una logica simile ma copre almeno sei dimensioni di policy in modo nativo: moderazione dei contenuti, rilevamento di prompt attack, classificazione per argomento, redazione di dati personali, verifica del grounding contestuale per individuare le allucinazioni, e controlli di ragionamento formale tramite Automated Reasoning. I team che lavorano su più cloud si trovano quindi a confrontare Azure, AWS e gli stack open source insieme, non più un singolo fornitore isolato.

La differenza più rilevante per un’azienda europea riguarda la sovranità dei dati. Le tabelle comparative pubblicate nel 2026 classificano NeMo Guardrails, Guardrails AI e LLM Guard come self-hostabili, gratuiti e sotto licenza open source, quindi eseguibili interamente on-premise o in un cloud sovrano europeo, mentre Azure AI Content Safety e AWS Bedrock Guardrails restano API commerciali gestite e fatturate a consumo, con tutte le implicazioni che ne derivano per chi deve dimostrare conformità al GDPR sulla localizzazione dei dati trattati.

Specifiche tecniche a confronto: la tabella completa

Prima di scegliere, conviene guardare tutte le variabili fianco a fianco. La tabella seguente riassume licenza, requisiti hardware, popolarità e caratteristiche chiave dei quattro framework open source più citati, con i dati verificati direttamente sulle rispettive pagine GitHub il 18 settembre 2026.

Caratteristica	NeMo Guardrails	Llama Guard 4	Guardrails AI	LLM Guard
Sviluppatore	NVIDIA	Meta	Guardrails AI Inc.	Protect AI
Licenza	Apache 2.0	Llama Community License	Apache 2.0	MIT
Star GitHub (18/9/2026)	7.165	4.400 (repo PurpleLlama)	7.433	3.208
Ultima release	v0.24.1 (16/9/2026)	Llama Guard 4	v0.11.0 (14/8/2026)	v0.3.16
Tipo di controllo	Rail configurabili (RAG, tool-call, dialogo)	Classificatore dedicato per taxonomy di rischio	Validator componibili	Scanner input/output modulari
GPU richiesta	Consigliata per i rail LLM-based	Sì, per prestazioni accettabili	No per i validator locali	No, classificatori CPU-friendly
Linguaggio/integrazione	Python, config YAML/Colang	Pesi del modello, chiamabile via API	Python, libreria o servizio REST	Python, libreria
Supporto RAG a livello di chunk	Sì, nativo	No	Parziale, via validator dedicati	Parziale
Supporto tool-calling	Sì, nativo	No	Parziale	No
Pronto per produzione critica	La documentazione consiglia hardening aggiuntivo	Sì, con attenzione alla licenza	Sì, con supporto enterprise Pro	Sì, per casi CPU-only
Latenza tipica per singolo controllo	150-400 ms	250-900 ms secondo la taglia	20-200 ms	45 ms
Caso d’uso ideale	Agenti enterprise con RAG e tool-calling su GPU NVIDIA	Classificazione di rischio generalista	Pipeline leggere, CPU-only, alta componibilità	Firewall input/output a basso overhead

Benchmark di latenza e accuratezza: cosa dicono tre fonti indipendenti

Non esiste, a settembre 2026, un unico studio che metta NeMo Guardrails, Llama Guard, Guardrails AI e LLM Guard in una sola tabella comparativa con la stessa metodologia. Ricostruire il quadro richiede quindi di combinare tre tipi di fonti diverse, ognuna con i suoi limiti.

La prima fonte è lo studio accademico “No Free Lunch With Guardrails”, che confronta classificatori statici come NeMo-Guard e Llama-Guard su più benchmark pubblici. Su una batteria di test, NeMo-Guard ottiene F1 di 0,928, 0,640, 0,858, 0,900 e 0,986 con una latenza di 1,019 secondi, mentre su un’altra batteria arriva a F1 di 0,978, 0,917, 0,840, 0,974 e 0,937 con latenza di 0,690 secondi. Llama-Guard, sulle stesse due batterie, oscilla tra F1 di 0,494 e 0,995, con latenza rispettivamente di 0,959 e 1,54 secondi. Il messaggio centrale dello studio è che nessuno dei due classificatori vince su tutti i tipi di contenuto testato.

La seconda fonte è un benchmark del 2026 pubblicato da un vendor di sicurezza AI (Lasso Security, per la propria suite LEAP) che confronta il self-check di NeMo con Llama Guard 4. Il NeMo self-check, basato su un LLM come giudice, ottiene F1 di 0,65 con recall di 0,99 e un tasso di “over-defense” di 0,72, con un throughput di 14,4 documenti al secondo e una latenza p50 di circa 835 millisecondi. Llama Guard 4 segna invece F1 di 0,46, recall di 0,39 e over-defense di 0,95, con throughput di 15,8 documenti al secondo e latenza p50 di circa 630 millisecondi. In altre parole: NeMo self-check rileva più minacce ma blocca anche più richieste legittime, Llama Guard 4 è più rapido ma lascia passare più attacchi reali in questo specifico test.

La terza fonte sono i blog di ingegneria di produzione pubblicati nel 2026, che riportano intervalli di latenza misurati su infrastrutture reali piuttosto che punteggi F1 di laboratorio: Guardrails AI tra 20 e 200 millisecondi per un singolo controllo, NeMo Guardrails tra 150 e 400 millisecondi per un controllo singolo e tra 600 millisecondi e 1,2 secondi per una pipeline multi-rail, Llama Guard 3 a 8 miliardi di parametri a circa 800 millisecondi su GPU A100, LLM Guard a circa 45 millisecondi per un controllo di tossicità su CPU. Il quadro che emerge, incrociando le tre fonti, è coerente: i classificatori dedicati come Llama Guard offrono accuratezza alta ma variabile a seconda del contenuto, i validator leggeri di Guardrails AI e LLM Guard vincono sulla velocità, e NeMo Guardrails si posiziona a metà, pagando la sua flessibilità architetturale con latenza più alta.

Prezzi 2026: self-hosting gratuito contro servizi cloud a consumo

Tutti i quattro framework open source di questo confronto sono gratuiti nel senso stretto del termine: nessuna licenza da pagare per usarli. Il costo reale non è nella licenza, ma nell’infrastruttura necessaria a farli girare, che varia molto in base al framework scelto. Guardrails AI e LLM Guard possono girare su semplici istanze CPU, mentre NeMo Guardrails e Llama Guard 3/4 a 8 miliardi di parametri richiedono GPU dedicate per restare sotto il secondo di latenza.

I servizi cloud gestiti, al contrario, hanno un listino prezzi pubblico e trasparente. Azure AI Content Safety fattura 0,375 dollari per 1.000 record di testo (un record equivale a un massimo di 1.000 caratteri Unicode) nella regione East US, con un livello gratuito di 5.000 record di testo e 5.000 immagini al mese, e 0,75 dollari per 1.000 immagini analizzate. AWS Bedrock Guardrails applica invece un listino a più voci: 0,15 dollari per 1.000 unità di testo per i filtri di contenuto e per gli argomenti vietati, 0,10 dollari per 1.000 unità per la rilevazione di dati personali basata su machine learning e per i controlli di grounding contestuale, e 0,17 dollari per 1.000 unità per ogni policy di Automated Reasoning attiva. I filtri basati su regex e le liste di parole vietate restano invece gratuiti su Bedrock.

Soluzione	Modello di prezzo	Costo indicativo	Note
NeMo Guardrails	Gratuito, self-hosted	Solo costo del compute GPU/CPU	Apache 2.0, nessuna licenza da pagare
Guardrails AI	Gratuito (community) / Guardrails Pro (enterprise)	Community gratis, Pro a listino su richiesta	Validator locali girano anche su CPU economica
Llama Guard 4	Gratuito, self-hosted	Costo GPU (T4 per 1B, A100 consigliata per 8B)	Licenza Llama Community, non OSI open source
LLM Guard	Gratuito, self-hosted	Costo compute CPU, minimo	MIT, nessun vincolo di licenza
Azure AI Content Safety	A consumo (S0)	0,375 $ per 1.000 record di testo, 0,75 $ per 1.000 immagini	Free tier: 5.000 record testo + 5.000 immagini/mese
AWS Bedrock Guardrails	A consumo, per filtro	0,07-0,17 $ per 1.000 unità di testo secondo il filtro	Filtri regex e word list gratuiti

Per fare un esempio concreto: un’applicazione che elabora un milione di messaggi al mese, ognuno stimabile in una unità di testo, spenderebbe circa 150 dollari al mese solo per il filtro contenuti di base su AWS Bedrock Guardrails, prima di aggiungere PII detection o Automated Reasoning. Su Azure, lo stesso volume costerebbe circa 375 dollari al mese per la sola analisi testuale con Content Safety. Un’azienda che invece self-hosta NeMo Guardrails o Guardrails AI su un’istanza cloud già esistente, magari condivisa con altri carichi di lavoro, può restare sotto queste cifre, ma deve considerare anche il tempo di configurazione, hardening e manutenzione, che non compare in nessun listino ma pesa comunque sul budget del team.

Sei casi reali di adozione dei guardrail per LLM

Al di là dei benchmark, conta vedere dove questi strumenti vengono effettivamente usati. Ecco sei scenari concreti documentati nel 2025-2026.

• Microsoft 365 Copilot integra i Prompt Shields di Azure AI Content Safety per filtrare i tentativi di jailbreak e l’injection indiretta nei documenti che l’assistente elabora durante l’uso quotidiano in ambito enterprise.
• Assistenti finanziari enterprise: le guide tecniche pubblicate da NVIDIA nel 2026 descrivono pipeline che usano NeMo Guardrails per vincolare un assistente bancario a rispondere solo su argomenti autorizzati, bloccando richieste che escono dal perimetro consentito prima che raggiungano il modello.
• Piattaforme educative con tutor AI: uno studio del 2026 su un sistema di tutoraggio ha misurato NeMo Guardrails in produzione su un set di 480 query, di cui 369 tentativi di injection e 111 richieste legittime, registrando un tasso di bypass del 16,22% e latenza media di circa 1.470 millisecondi, un risultato che lo stesso studio classifica come poco adatto all’uso reale senza ulteriori ottimizzazioni.
• Agenti che leggono email e ticket: StackOne Defender viene usato per proteggere agenti che ingeriscono documenti, email e ticket di supporto, un canale che i classificatori generalisti come Llama Guard non coprono in modo specifico perché progettati per il testo digitato direttamente dall’utente.
• Team che distribuiscono guardrail su scala: diverse organizzazioni enterprise citate nelle guide 2026 di Guardrails AI usano la versione Pro del framework per applicare gli stessi validator a più applicazioni interne contemporaneamente, evitando di duplicare la logica di sicurezza in ogni singolo progetto.
• Pipeline di test di sicurezza pre-deploy: team di AppSec usano scanner come Garak, PyRIT, Promptfoo e Augustus per fuzzare agenti e chatbot prima del rilascio, integrando questi test nelle pipeline CI/CD insieme ai guardrail inline che poi restano attivi in produzione.

Quale guardrail scegliere in base al caso d’uso

Non esiste una risposta unica: la scelta dipende da infrastruttura disponibile, tolleranza alla latenza e vincoli di conformità. Ecco le raccomandazioni pratiche che emergono dai dati raccolti.

• Startup con un solo sviluppatore, proof of concept rapido: Guardrails AI, per la libreria leggera che gira anche su CPU economica e non richiede infrastruttura GPU dedicata.
• Enterprise con GPU NVIDIA e pipeline RAG/tool-calling complesse: NeMo Guardrails, per il controllo nativo a livello di chunk e di chiamata di tool, accettando però il lavoro di hardening extra richiesto prima della produzione.
• Team che ha solo bisogno di una classificazione di rischio generalista senza infrastruttura RAG: Llama Guard 4, valutando con attenzione le condizioni della Llama Community License prima di distribuirlo in un prodotto commerciale.
• Applicazioni che devono restare a bassissima latenza e senza GPU: LLM Guard, grazie ai suoi 45 millisecondi per controllo su CPU e alla licenza MIT priva di vincoli.
• Aziende che vogliono un SLA e supporto contrattuale senza gestire infrastruttura: Azure AI Content Safety o AWS Bedrock Guardrails, accettando il costo a consumo e valutando l’impatto sulla residenza dei dati secondo il GDPR.
• Team di sicurezza applicativa che devono validare un agente prima del rilascio: scanner come Garak, PyRIT, Promptfoo o Augustus, da usare in CI/CD e non in produzione, affiancati poi da un guardrail inline per la fase live.

Guida alla migrazione tra framework di guardrail

Cambiare framework di guardrail a metà progetto, o dopo aver scoperto che la scelta iniziale non regge il carico di produzione, è più comune di quanto si pensi. Questi sono i passaggi che riducono il rischio di lasciare buchi di sicurezza durante la transizione.

1. Mappa tutte le regole attive nel framework attuale: categorie bloccate, soglie di confidenza, whitelist e blacklist di pattern.
2. Traduci ogni regola nel formato del nuovo framework, senza aggiungerne o rimuoverne, per avere un confronto pulito nella fase successiva.
3. Esegui i due guardrail in parallelo, in modalità shadow, loggando le decisioni di entrambi sullo stesso traffico reale senza bloccare nulla con il nuovo sistema.
4. Confronta i log per individuare divergenze: falsi positivi nuovi, falsi negativi nuovi, differenze di latenza misurate sullo stesso campione di richieste.
5. Calibra le soglie del nuovo framework sulla base delle divergenze osservate, ripetendo il confronto shadow finché il tasso di errore non è pari o inferiore al sistema precedente.
6. Attiva il nuovo guardrail in produzione con un rollout progressivo, per esempio sul 10% del traffico, monitorando latenza e tasso di blocco prima di estenderlo al 100%.
7. Mantieni il vecchio framework disponibile in modalità passiva per almeno due settimane dopo il rollout completo, per poter tornare indietro rapidamente in caso di anomalie.

Un esempio pratico di come cambia la configurazione passando da Guardrails AI a NeMo Guardrails, per un controllo semplice sui dati personali in output, mostra bene la differenza di approccio tra i due framework:

# Guardrails AI: validator Python componibile
from guardrails import Guard
from guardrails.hub import DetectPII

guard = Guard().use(DetectPII, on_fail="fix")
result = guard.validate(llm_output)

# NeMo Guardrails: rail definito in Colang/YAML
# config.yml
rails:
  output:
    flows:
      - self check output
prompts:
  - task: self_check_output
    content: |
      Verifica se la risposta contiene dati personali
      non autorizzati prima di restituirla all'utente.

La logica di fondo resta la stessa, intercettare l’output prima che raggiunga l’utente, ma il modo di dichiararla cambia radicalmente: Guardrails AI resta dentro il codice applicativo, NeMo Guardrails sposta la configurazione in un file dichiarativo separato, più vicino a un sistema di policy che a una libreria software.

Pro e contro di ogni soluzione

Riassumere vantaggi e svantaggi aiuta a decidere rapidamente quando il tempo per un test approfondito manca.

• NeMo Guardrails. Pro: controllo granulare su RAG e tool-calling, licenza Apache 2.0, sviluppo attivo con release quasi settimanali. Contro: la documentazione stessa scoraggia l’uso in produzione senza hardening, latenza più alta delle alternative leggere, richiede spesso GPU per restare performante.
• Llama Guard 4. Pro: accuratezza alta su molti benchmark pubblici, backing di Meta, aggiornamenti regolari con nuove generazioni. Contro: licenza Llama Community non riconosciuta come open source dalla OSI, latenza elevata sulla variante più accurata a 8 miliardi di parametri, nessun controllo nativo su RAG o tool-calling.
• Guardrails AI. Pro: latenza bassissima sui validator locali, licenza Apache 2.0 senza restrizioni, il maggior numero di star tra i quattro framework, componibilità elevata. Contro: nessun benchmark F1 pubblico su standard riconosciuti come NotInject, il supporto enterprise Pro non ha numeri di adozione verificabili.
• LLM Guard. Pro: latenza minima, licenza MIT permissiva, adatto a infrastrutture CPU-only, buon numero di scanner pronti all’uso. Contro: community più piccola delle altre tre opzioni, meno benchmark accademici pubblicati a confronto.

Conformità normativa: AI Act, GDPR e sovranità dei dati in Europa

Per un’azienda italiana o europea, la scelta del guardrail non riguarda solo prestazioni e prezzo. L’AI Act classifica molti sistemi che elaborano contenuto generato da utenti come a rischio da gestire attivamente, e i guardrail sono uno degli strumenti concreti per dimostrare che quel rischio viene mitigato prima del deploy, non dopo un incidente.

Il vantaggio di NeMo Guardrails, Guardrails AI e LLM Guard, in questo contesto, è la possibilità di eseguirli interamente all’interno dell’infrastruttura europea dell’azienda, senza che il testo elaborato transiti verso un servizio cloud extra-UE. Per chi deve dimostrare conformità al GDPR sulla localizzazione dei dati, questo semplifica sensibilmente l’audit: i log di ogni decisione del guardrail restano dove restano i dati stessi.

Azure AI Content Safety e AWS Bedrock Guardrails offrono regioni europee e contratti che coprono i trasferimenti di dati, ma restano servizi gestiti da aziende soggette anche alla giurisdizione statunitense. Non è un problema automaticamente bloccante, molte aziende europee li usano senza difficoltà, ma è una variabile da valutare insieme al team legale prima di scegliere, soprattutto per applicazioni che processano dati sanitari, finanziari o giudiziari, dove la sensibilità dei contenuti filtrati dal guardrail è più alta della media.

Il verdetto: quale guardrail vince nel 2026

Non c’è un vincitore assoluto, e chi promette il contrario probabilmente sta vendendo qualcosa. Guardrails AI si porta a casa il titolo di framework open source più equilibrato: 7.433 star su GitHub, licenza Apache 2.0 senza vincoli, latenza tra 20 e 200 millisecondi per controllo e nessun bisogno di GPU dedicata. Per la maggior parte dei team che partono da zero, è il punto di partenza più ragionevole.

NeMo Guardrails resta la scelta giusta solo per chi ha già investito in infrastruttura NVIDIA e costruisce agenti complessi con RAG e tool-calling profondo, accettando che la sua stessa documentazione lo descriva come da rafforzare prima della produzione, con release v0.24.1 arrivata appena due giorni prima della pubblicazione di questo confronto, segno di un progetto ancora in movimento. Llama Guard 4 conviene quando serve un classificatore generalista di alta qualità e la licenza Llama Community non è un ostacolo per il proprio caso d’uso commerciale, ma i suoi tempi di risposta, fino a 900 millisecondi sulla variante più accurata, lo rendono meno adatto a chatbot conversazionali dove la reattività conta.

LLM Guard resta la scelta più pragmatica quando l’unico obiettivo è un firewall di base a bassissimo costo computazionale, senza pretese di sofisticazione architetturale. E per chi preferisce non gestire nessuna infrastruttura, Azure AI Content Safety e AWS Bedrock Guardrails restano opzioni solide, a patto di accettare un costo che cresce linearmente con il volume di traffico, circa 375 dollari al mese per un milione di messaggi su Azure, e di valutare con attenzione le implicazioni sulla residenza dei dati secondo il GDPR.

Domande frequenti

NeMo Guardrails, Llama Guard e Guardrails AI possono essere usati insieme?

Sì, e in pratica molti team li combinano: un classificatore rapido come LLM Guard o Llama Guard per il primo filtro, seguito da rail più specifici di NeMo Guardrails o da validator di Guardrails AI per i controlli legati al contesto applicativo. La combinazione aumenta il tasso di rilevamento ma somma anche le latenze, quindi va misurata con attenzione prima di portarla in produzione.

Serve davvero una GPU per usare questi guardrail?

Dipende dal framework. Guardrails AI e LLM Guard girano bene anche su CPU per la maggior parte dei validator. NeMo Guardrails e Llama Guard 3/4 nella variante a 8 miliardi di parametri, invece, restano sotto il secondo di latenza solo con una GPU dedicata, mentre su CPU i tempi di risposta diventano difficilmente accettabili per un’applicazione interattiva.

Llama Guard è davvero open source?

No, non nel senso tecnico del termine. È distribuito sotto la Llama Community License di Meta, che permette download, modifica e self-hosting ma non è approvata dalla Open Source Initiative. Va considerato “source-available” più che open source, una distinzione che conta soprattutto per chi deve rispondere a requisiti legali o di procurement basati su definizioni formali di licenza.

Qual è il framework più economico da mantenere?

Tra le opzioni self-hosted, LLM Guard e Guardrails AI hanno i costi infrastrutturali più bassi perché girano su CPU economica. Tra i servizi cloud gestiti, AWS Bedrock Guardrails risulta generalmente meno costoso di Azure AI Content Safety a parità di volume, grazie a filtri come le regex e le word list che restano gratuiti anche su larga scala.

Questi guardrail bloccano anche l’injection indiretta nei documenti?

Non tutti allo stesso modo. I classificatori generalisti come Llama Guard sono pensati soprattutto per il testo digitato dall’utente. Per l’injection nascosta in documenti, email o ticket che un agente consuma, servono strumenti dedicati come StackOne Defender, oppure rail configurati appositamente in NeMo Guardrails a livello di chunk RAG.

Quanto tempo richiede implementare un guardrail da zero?

Per un’integrazione base con Guardrails AI o LLM Guard, poche ore bastano a collegare i primi validator o scanner a un’applicazione esistente. Per un deployment completo di NeMo Guardrails con rail personalizzati su RAG e tool-calling, il lavoro si misura in giorni, non ore, soprattutto considerando l’hardening aggiuntivo raccomandato dalla documentazione ufficiale prima di andare in produzione.

Un guardrail elimina completamente il rischio di prompt injection?

No. I dati dello studio “No Free Lunch With Guardrails” mostrano F1 che scendono fino a 0,494 su alcuni benchmark, e lo studio sul tutor educativo ha misurato un tasso di bypass del 16,22% per NeMo Guardrails su un set di query reali. Nessun guardrail attuale garantisce protezione totale: riduce la superficie di attacco, non la elimina, e va sempre affiancato da monitoraggio continuo e test periodici con strumenti come Garak o Promptfoo.

Perché Guardrails AI ha più star su GitHub di NeMo Guardrails se NVIDIA ha più risorse?

Il numero di star riflette l’adozione da parte della community di sviluppatori indipendenti, non il budget dell’azienda che sponsorizza il progetto. Guardrails AI, con la sua architettura più semplice e leggera, si presta meglio a essere adottato rapidamente da singoli sviluppatori e piccoli team, mentre NeMo Guardrails richiede un investimento iniziale maggiore che ne limita la sperimentazione spontanea, pur restando molto attivo in termini di sviluppo, come dimostra la release v0.24.1 uscita il 16 settembre 2026.