🧙 Maestro Yoda Cap. 23 · Sicurezza e adversarial

Puntata 254

Puntata 254 — Guardrails: Llama Guard, NeMo Guardrails, custom filters

Livello: 🧙 Maestro Yoda · Capitolo 23 · Sicurezza e adversarial

Il modello principale ragiona. Il guardrail no — fa una sola cosa: dice “questo passa” o “questo no”. È il poliziotto all’ingresso, il filtro all’uscita, il moderatore in mezzo. Senza, sei nudo. Con, sei vestito ma non blindato. Capire cosa fa, cosa non fa, dove va messo è la differenza tra teatro di sicurezza e architettura difensiva vera.

un edificio uffici con tre cerchi concentrici di filtri. Cerchio esterno: “input guardrail” (controllo borse), cerchio mezzo: “modello principale” (la conferenza), cerchio interno: “output guardrail” (controllo uscita). Una persona con la cravatta storta esce e viene fermata dall’output filter. Sotto: “non basta entrare bene, devi uscire pulito”

Cos’è un guardrail (e cosa non è)

Un guardrail in un sistema LLM è un componente filtro che:

  • Sta tra l’utente (o l’ambiente) e il modello principale.
  • Decide se input/output passano, vengono modificati, o vengono bloccati.
  • È specializzato per la decisione di safety/policy, NON per generare risposte.

NON è:

  • Il safety training del modello stesso (RLHF, Constitutional AI).
  • Un firewall di rete.
  • Un’autorizzazione (auth/authz).

I guardrails sono uno strato addizionale, complementare alle safety capability native del modello. Difesa in profondità.

Le 4 posizioni di un guardrail

[User input]
     ↓
[INPUT guardrail] ← blocca/modifica input prima che arrivi al modello
     ↓
[Main LLM]
     ↓
[OUTPUT guardrail] ← controlla l'output prima di restituirlo
     ↓
[User]

In parallelo durante agent loop:
[TOOL CALL guardrail] ← controlla chiamate tool prima dell'esecuzione
[TOOL RESULT guardrail] ← sanitize risultati di tool prima di reinjettarli

Tutti e 4 hanno il loro ruolo. Sistemi serissimi li usano tutti.

Le 3 categorie di implementation

1. Rule-based / deterministic

Regex, dizionari, pattern matching, NER classico.

  • Pro: fast, deterministic, debuggabile.
  • Contro: rigido, aggirabile, false positive.
  • Quando: PII detection, secret scanning, dominio-specific.

2. Model-based classifier (small)

Modello small/medium addestrato a classificare “safe vs unsafe” su categorie note.

  • Esempi: Llama Guard, NeMo classifier, OpenAI Moderation API, Azure Content Safety.
  • Pro: cattura pattern semantici, scalabile.
  • Contro: false positive, bias di training set, latency 50-200ms.
  • Quando: principale linea per content moderation.

3. LLM-based judge (large)

LLM forte (Claude, GPT-5) come judge dell’altro modello.

  • Pro: massima flessibilità, comprensione contestuale.
  • Contro: costoso (5-50× del modello primario), latency 500-3000ms, bias del judge.
  • Quando: edge case complessi, high-stakes decisions, eval.

Pattern moderno: layer 1 (rule) → layer 2 (classifier) → layer 3 (LLM judge) solo per casi sospetti.

Tool principali 2026

Llama Guard (Meta)

  • Versioni: Llama Guard 1 (2023), 2, 3 (2024), 4 (2025).
  • Cosa fa: classifica input/output in categorie unsafe (violence, sexual, hate, self-harm, illegal, ecc.). Output sicuro o etichette.
  • Modello: Llama-based fine-tuned (8B fino a Guard 3, multimodal in Guard 4).
  • License: Llama Community.
  • Quando: linea base open per content moderation. Decente, free.
from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "meta-llama/Llama-Guard-3-8B"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, device_map="auto")

def moderate(chat):
    input_ids = tokenizer.apply_chat_template(chat, return_tensors="pt").to("cuda")
    output = model.generate(input_ids=input_ids, max_new_tokens=100)
    return tokenizer.decode(output[0][input_ids.shape[-1]:], skip_special_tokens=True)

# Output: "safe" o "unsafe\nS1, S2" (categorie violate)

NeMo Guardrails (NVIDIA)

  • Cosa fa: framework per definire policy strutturate (rail flow, topical rail, dialogue rail) tramite Colang (DSL).
  • Approccio: meno “filtro yes/no”, più “policy comportamentale”.
  • Esempio policy: 
    rails:
  input:
    flows:
      - check user message
  output:
    flows:
      - self check output
      - check facts
  • Pro: framework completo, supporta retrieval e LLM-judge.
  • Contro: learning curve della DSL, overhead.

OpenAI Moderation API

  • Cosa fa: classifier proprietario di OpenAI per content unsafe (free per gli utenti API OpenAI).
  • Categorie: hate, harassment, self-harm, sexual, violence, ecc.
  • Latency: ~50-100 ms.
  • Quando: stai già usando OpenAI, vuoi quick start.

Azure AI Content Safety

  • Cosa fa: managed service Microsoft, simile a Moderation API ma più features.
  • Categorie: 4 categorie principali (hate, sexual, violence, self-harm) con severity 0-7. Più: prompt shields (injection detection), groundedness detection (RAG hallucination).
  • Pricing: $1/1000 chiamate (variabile).

Lakera Guard

  • Cosa fa: managed SaaS focus su prompt injection e jailbreak detection.
  • Forza: focus specifico su injection, dataset enorme di attack pattern.
  • Quando: serietà su injection vector.

PromptShield (Azure), Prompt Security

  • Vari managed competitor focus su injection detection.

Guardrails AI (open)

  • Cosa fa: framework Python per validazione output strutturato (schema validation + reasking + custom validators).
  • Approccio: orientato a “output deve matchare schema X”, non solo safety.

Llama Prompt Guard (Meta)

  • Cosa fa: classifier dedicato a detect prompt injection (sibling di Llama Guard ma focus diverso).
  • Open, small, veloce.

Custom guardrail

  • Fine-tune Llama-3.2-1B o Qwen-2.5-1.5B sul tuo dominio specifico.
  • Più preciso per il tuo use case.
  • Effort: 1-2 settimane + dataset.

Cosa cercare in un guardrail di qualità

5 dimensioni:

1. Coverage delle categorie

Match con i rischi del tuo dominio. Generic guardrail OK per generic use. Per finance/medical/legal serve dominio-specifico.

2. False positive rate

Block legittimo query = utenti frustrati. Test su dataset rappresentativo del tuo use case prima del rollout.

3. False negative rate

Lascia passare unsafe = headlines. Test con red team adversarial.

4. Latency

Aggiunge X ms al ogni request. Per chat: <200ms accettabile. Per batch: less sensitive.

5. Multilinguità

Spesso guardrail “safe in English, bad in Italian” — molti benchmark sono solo EN.

Pattern di deployment

Pattern A — Single classifier layer

[input] → [Llama Guard 3 input] → [LLM] → [Llama Guard 3 output] → [user]

Semplice, baseline. Buon punto di partenza.

Pattern B — Tiered (fast + slow)

[input] → [regex/rule] → [classifier small] → [LLM] → [classifier output] → [if suspect: LLM judge] → [user]

Most cases fast path, edge case approfonditi.

Pattern C — Multi-classifier voting

[input] → [Llama Guard 3] + [Azure Content Safety] + [custom classifier] → vote → [LLM] → ...

Per use case high-stakes: combinare classificatori riduce false negatives.

Pattern D — Topical rail (NeMo style)

[input] → [classify topic] → [if off-topic: canned response, no LLM] → ...

Per chatbot specializzati: blocca a priori conversazione fuori dominio.

Pattern E — Self-check via LLM

[input] → [LLM] → [Self-check prompt: "Did you violate any policy?"] → [if yes: re-generate or refuse] → [user]

Pattern Constitutional-AI-style runtime.

Custom guardrail: quando e come

Quando un guardrail off-the-shelf:

  • Non copre il tuo dominio (es. finance compliance specifico).
  • Ha false positive troppo alti sui tuoi use case legitimate.
  • Devi catturare violazioni di policy custom (es. “non parlare mai di competitor”).

Build:

  1. Costruisci dataset di ~1000-10000 esempi labeled (safe/unsafe per la tua policy).
  2. Fine-tune small model (Llama-3.2-1B/3B, Qwen-1.5B-Instruct, BERT base).
  3. Eval su held-out test set.
  4. Deploy con monitoring continuo.
  5. Loop di improvement: log fal+/fal- in production, riaddestra periodicamente.

Cost: ~$500-5000 per setup iniziale + ~$50-500/mese maintenance.

Limiti onesti dei guardrails

Cosa NON risolvono

  • Bias di training: il guardrail eredita bias del suo training set.
  • Novelty attacks: pattern non visti durante training passano.
  • Adversarial robustness: studi mostrano che jailbreak adversariali bypassano la maggior parte dei classifier (Yi et al., 2024).
  • Over-refusal: guardrail aggressivi bloccano query legittime, danneggiando UX.
  • Multilinguità low-resource: vulnerabili a switch lingua.

Trade-off perpetuo

  • Più restrittivo → safety up, UX down.
  • Più permissivo → UX up, safety down.

Non c’è punto ottimo universale. Calibri per il tuo use case.

Eval di un guardrail

Setup minimo:

  1. Adversarial test set: pattern noti di jailbreak + injection (HarmBench, AdvBench, AgentDojo).
  2. Legitimate-but-tricky set: query borderline legittime (medical questions, security research, creative writing). Misura over-refusal.
  3. Domain-specific set: query tipiche tuo dominio + violazioni policy custom.

Metriche:

  • Recall su unsafe (true positive rate): catch malicious.
  • False positive rate: block legitimate (UX cost).
  • F1.
  • Bypass rate per attack class.

Target per production:

  • Recall >95% su unsafe noti.
  • FPR <5% su legitimate.
  • Latency <200ms p95.

Re-eval mensilmente: nuovi attack vector emergono.

Pattern per agenti (oltre chat)

Per sistemi agentici (tool use, autonomy):

Tool-call guardrail

Prima di eseguire un tool call, verifica:

  • Tool è in allowlist?
  • Arguments matchano schema?
  • Side effect richiede HITL?
  • Combinazione tool sospetta (es. read_email + send_email a indirizzi esterni)?

Trajectory guardrail

Monitor la traiettoria dell’agente:

  • Too many tool calls? loop?
  • Stesso tool ripetuto N volte?
  • Pattern anomalo rispetto a baseline?

Outcome guardrail

Verifica risultato finale:

  • Match con goal originale?
  • Output contiene PII non richieste?
  • Action eseguite hanno effetti collaterali inaspettati?

Glossario lampo

  • Guardrail — componente filtro tra utente/ambiente e modello principale che decide pass/block/modify.
  • Llama Guard — classifier Meta per content moderation, open Llama-based. Versione 4 (2025) multimodal.
  • NeMo Guardrails — framework NVIDIA con DSL Colang per definire policy strutturate (topical / dialogue / input / output rails).
  • Prompt Shield — classifier specifico per detection di prompt injection (Lakera, Azure, Prompt Security).
  • LLM-as-judge guardrail — usare un LLM forte come arbitro su output di altro modello. Costoso ma flessibile.
  • Over-refusal — guardrail che blocca query legittime causando UX scadente.

Take-away

I guardrail sono il “secondo livello” della sicurezza AI: aggiungono difesa in profondità sopra le safety capability native del modello. Nessun guardrail singolo è sufficiente; pattern moderno è multi-layer (regex + classifier + LLM judge). Si misurano su tre dimensioni: recall su unsafe, false positive rate, latency. Vanno calibrati sul tuo dominio e re-evaluated regolarmente — gli attaccanti non si fermano, i tuoi guardrail devono evolvere.

➡️ Prossima puntata: standard di sicurezza AI — NIST AI RMF, ISO 42001, OWASP LLM Top 10.