Un'azienda manifatturiera italiana integra un assistente AI interno per rispondere alle domande dei commerciali su prezzi, margini e specifiche di prodotto. Dopo tre settimane, il sistema inizia a citare listini riservati a clienti premium nelle conversazioni con agenti senza quella autorizzazione. Nessun attacco, nessun bug. Solo un LLM che non sapeva dove si fermava il suo perimetro.
Questo scenario è più comune di quanto si pensi. Il problema non è l'AI in sé: è che la maggior parte delle aziende deploy-a un LLM interno senza aver mai scritto nero su bianco cosa può e cosa non può fare. E quando qualcosa va storto, si reagisce bloccando tutto, rendendo il sistema inutile. Esiste una via di mezzo, ed è fatta di architettura, policy e decisioni umane chiare.
Cosa sono i guardrail e perché non bastano quelli del modello base
I guardrail sono vincoli operativi che delimitano il comportamento di un LLM in produzione. Non si tratta solo dei filtri di sicurezza che OpenAI, Anthropic o Google hanno già incorporato nei loro modelli. Quelli esistono e funzionano per i casi generali: contenuti illegali, istruzioni pericolose, hate speech.
Il problema è che i guardrail nativi dei modelli non conoscono il tuo contesto aziendale. Non sanno che la tua politica commerciale vieta di discutere sconti sopra una certa soglia senza approvazione del direttore vendite. Non sanno che certi dati contabili sono visibili solo al CFO. Non sanno che determinate informazioni su clienti non devono mai uscire da un certo reparto.
Quindi hai due livelli di problema distinti. Il primo riguarda la sicurezza generale del modello, che in larga parte è già gestita dal provider. Il secondo riguarda la governance interna, che è responsabilità tua al cento per cento.
I tre strati di una strategia di guardrail efficace
Una architettura solida di guardrail per LLM aziendali si costruisce su tre strati sovrapposti, ciascuno con uno scopo preciso.
Strato 1: System prompt e contesto operativo. Ogni LLM aziendale dovrebbe ricevere, prima di qualsiasi interazione, un system prompt che definisce identità, perimetro e limitazioni. Non basta scrivere "sei un assistente aziendale". Devi specificare cosa può fare, cosa non può fare, e come deve comportarsi quando una richiesta si avvicina al confine. Questo non è un esercizio di copywriting: è una decisione di governance.
Strato 2: Filtri input/output. Prima che il prompt arrivi al modello e prima che la risposta raggiunga l'utente, puoi applicare filtri programmatici. Sul lato input, puoi intercettare richieste che contengono certi pattern (nomi di clienti specifici, codici prodotto riservati, termini finanziari sensibili). Sul lato output, puoi analizzare la risposta generata prima che venga mostrata, cercando pattern che non dovrebbero apparire. Strumenti come Llama Guard, i moderatori nativi di OpenAI o soluzioni custom in Python fanno esattamente questo.
Strato 3: Controllo accessi e segmentazione dei dati. Se il tuo LLM recupera informazioni da database interni tramite RAG (retrieval-augmented generation), il guardrail più efficace non è nel modello: è a monte, nel sistema di recupero. L'utente vede solo le informazioni che il sistema è autorizzato a recuperare per lui. Non serve insegnare all'AI a tacere se semplicemente non ha accesso a certi dati.
Chi decide cosa: il problema della governance
La parte più sottovalutata della strategia di guardrail non è tecnica. È organizzativa.
In molte PMI italiane, la decisione su cosa l'AI può o non può dire viene lasciata al team IT o, peggio, al fornitore esterno che ha implementato il sistema. Questo è un errore. Le decisioni su cosa è confidenziale, su chi può accedere a quali informazioni, su come gestire i casi limite, sono decisioni di business che appartengono alla direzione.
Una struttura pratica che funziona prevede tre figure con ruoli chiari:
- Il responsabile di processo (es. direttore commerciale, HR, CFO) definisce le regole di dominio: cosa è riservato, chi vede cosa, quali argomenti sono fuori perimetro.
- Il team tecnico traduce queste regole in configurazioni concrete: system prompt, filtri, architettura dei permessi.
- Un referente di conformità o legale valida che le scelte non creino rischi normativi, specialmente in ottica GDPR e AI Act europeo.
Senza questa triangolazione, i guardrail vengono scritti a istinto e vengono cambiati ogni volta che qualcuno si lamenta. Non è una strategia: è triage continuo.
Fallback: cosa fa il sistema quando non sa cosa fare
Un guardrail ben progettato non blocca e basta. Definisce cosa succede dopo il blocco.
Se un utente fa una domanda che esula dal perimetro, il sistema deve avere una risposta di fallback chiara e utile. Non un generico "non posso rispondere a questa domanda" che frustra l'utente e non spiega nulla. Meglio una risposta del tipo: "questa informazione non è disponibile tramite questo canale, contatta il tuo responsabile di area".
I fallback servono anche a raccogliere dati. Ogni volta che il sistema entra in modalità fallback, quella richiesta va loggata e analizzata periodicamente. Se lo stesso tipo di domanda genera fallback decine di volte al mese, hai due possibilità: o il guardrail è troppo restrittivo e stai bloccando qualcosa di utile, o hai identificato un bisogno reale degli utenti che non stai soddisfacendo in nessun altro modo.
Entrambi i casi richiedono una decisione deliberata, non una patch affrettata.
Il rischio opposto: guardrail troppo stretti che uccidono l'utilità
Il pendolo opposto è altrettanto pericoloso. Aziende che dopo un incidente iniziale restringono i guardrail al punto da rendere il sistema inutile. L'AI non risponde a nulla di specifico, si rifugia in risposte vaghe, e i colleghi smettono di usarla entro due settimane.
Questo succede quando i guardrail vengono progettati per coprire il rischio legale di chi li ha implementati, non per servire chi li usa. Il test pratico è semplice: fai rispondere il sistema alle domande più frequenti dei tuoi utenti reali. Se il tasso di fallback supera il quindici o venti per cento delle interazioni ordinarie, il problema non è l'utente. È la configurazione.
L'equilibrio giusto non si trova una volta sola. Va calibrato nel tempo, con dati reali di utilizzo e feedback strutturato dagli utenti interni.
La mossa concreta per domani mattina
Prendi il tuo LLM aziendale attuale (o quello che stai valutando) e scrivi un documento di una pagina con tre colonne: cosa il sistema può fare liberamente, cosa può fare solo con certi utenti o in certi contesti, e cosa non deve mai fare in nessuna circostanza. Fallo firmare o almeno validare dal responsabile di processo principale. Quel documento diventa la base del tuo system prompt e della tua architettura di filtri. Senza quel documento, stai costruendo su sabbia.