Assistenti GenAI nella PA, come misurare sicurezza e fiducia - Agenda Digitale

L’esperienza di CSI Piemonte nello sviluppo di una suite di red-teaming per chatbot e agenti AI mostra che modello, RAG e prompt non bastano da soli: servono scenari avversari, guardrail, test continui, metriche comprensibili e revisione esperta.Indice degli argomenti

Dall’assistente utile all’assistente affidabile nella PAPerché la GenAI cambia il rischio degli assistenti pubbliciAssistenti GenAI nella PA tra scala, fiducia e responsabilitàRed-teaming per assistenti GenAI nella PA: test ripetibiliScenari avversari e dominio applicativoReport, LLM-as-a-judge e revisione espertaPrompt funzionale e prompt difensivo nei test di red-teamingIl prompt funzionaleIl prompt difensivoDal red-teaming alla fiducia operativa nella Pubblica AmministrazioneDall’assistente utile all’assistente affidabile nella PAArchitettare e rilasciare al pubblico assistenti basati su GenAI su scala nazionale richiede uno sforzo di governance che copra l’intera pipeline: dalla cura e verifica del dato alla qualità delle fonti, dall’osservabilità delle risposte al monitoraggio continuo del comportamento del sistema.Ogni passaggio di questa catena deve essere progettato e controllato, come ho avuto modo di raccontare in un precedente articolo dedicato all’esperienza di Camilla, l’assistente AI realizzato da CSI Piemonte per supportare gli utenti nella consultazione dei concorsi pubblici.C’è però un aspetto ulteriore, oggi sempre più centrale, che distingue un assistente semplicemente “utile” da un assistente realmente “affidabile”: la capacità di mantenere il proprio mandato anche in presenza di interazioni con utenti o attori ostili. È un tema che diventa più rilevante proprio all’aumentare delle capacità dei modelli. Assistenti in grado di comprendere domande complesse, gestire documenti lunghi, produrre risposte articolate e adattarsi al contesto rendono apparentemente più semplice costruire servizi efficaci e convincenti. Ma questa maggiore capacità linguistica e operativa non coincide automaticamente con una maggiore affidabilità.Si crea così un paradosso solo apparente: più i modelli diventano capaci di produrre risposte coerenti, contestualizzate e formalmente corrette, più cresce la tentazione di considerarli implicitamente maturi, sicuri e consapevoli dei propri limiti. In realtà, la capacità di generare linguaggio non equivale alla capacità di rispettare stabilmente un mandato istituzionale, soprattutto quando l’assistente è esposto a utenti sconosciuti, su larga scala, e può essere sollecitato con richieste costruite per fargli cambiare ruolo, ignorare le istruzioni, rivelare informazioni interne o assumere un’autorità che non possiede.Il punto, quindi, non è soltanto costruire un assistente che sappia rispondere bene. È costruire un assistente che sappia anche non deviare dal proprio mandato e non costituire un fattore di rischio, o “anello debole” dell’intero ecosistema tecnologico in cui è posto. Per la Pubblica Amministrazione questa distinzione è ancora più importante: un assistente AI non è una semplice interfaccia conversazionale, ma un punto di contatto con cittadini, imprese e professionisti, inserito in un contesto di fiducia pubblica.In questo articolo provo quindi a raccontare un passaggio ulteriore del lavoro svolto da CSI Piemonte sugli assistenti basati su GenAI: non più soltanto come renderli utili, pertinenti e fondati su fonti controllate, ma come misurarne la capacità di resistere a scenari avversari. Lo farò partendo da una suite di red-teaming da noi sviluppata per simulare attacchi e manipolazioni realistiche, e da un confronto particolarmente significativo: lo stesso assistente testato con un prompt progettato con safeguards e con un prompt puramente funzionale, privo di specifiche attenzioni difensive. Il risultato aiuta a chiarire un punto centrale per la PA: la sicurezza di un assistente AI non è una proprietà implicita del modello o del RAG, ma l’esito di progettazione, guardrail, test continui e governance.Perché la GenAI cambia il rischio degli assistenti pubbliciLa particolarità degli assistenti basati su AI generativa è che il loro principale canale di interazione è il linguaggio naturale. Questo rende l’esperienza utente molto più ricca e accessibile, ma amplia anche la superficie di attacco: non è realistico validare a priori tutte le possibili formulazioni con cui un utente può interrogare, sollecitare o manipolare il sistema. Nel software tradizionale input, dati, istruzioni e permessi sono concetti più facilmente separabili; negli LLM, invece, una richiesta testuale può diventare al tempo stesso domanda, contesto, istruzione e tentativo di alterare il comportamento previsto.Le protezioni offerte dai provider di servizi AI rappresentano un primo livello importante, ma non possono essere considerate sufficienti. Molti rischi dipendono infatti dallo specifico dominio applicativo, dal mandato assegnato all’assistente, dalle fonti a cui accede e dagli eventuali strumenti che può utilizzare. Un utente ostile può provare a far cambiare ruolo all’assistente, a indurlo a rivelare istruzioni interne, a produrre link o indicazioni ingannevoli oppure a generare risposte non eque o discriminatorie. Se poi l’assistente non si limita a leggere informazioni, ma può anche attivare funzioni o modificare dati, il rischio si estende dalla qualità della risposta alla sicurezza dell’intero ecosistema in cui l’assistente opera.Assistenti GenAI nella PA tra scala, fiducia e responsabilitàNel contesto della Pubblica Amministrazione questi rischi non sono soltanto tecnici. Un assistente digitale esposto al pubblico viene percepito come un punto di contatto con l’istituzione: le sue risposte possono orientare cittadini, imprese e professionisti nella comprensione di procedure, requisiti, scadenze o servizi. Questo rende particolarmente delicati i temi della correttezza informativa, della neutralità, della non discriminazione e della protezione dei dati, che nei servizi pubblici possono riguardare anche situazioni personali o dati sensibili.A ciò si aggiunge la scala. Un assistente pubblico può essere utilizzato da una platea molto ampia, con livelli diversi di competenza digitale, bisogni informativi differenti e modalità di interazione difficili da prevedere. Può inoltre essere raggiunto non solo da utenti legittimi, ma anche da attori interessati a testarne i limiti, aggirarne le regole o sfruttarlo come punto debole di accesso a dati e sistemi sensibili. Per questo la cybersecurity applicata alla GenAI non può essere trattata come un controllo successivo o accessorio: deve diventare parte integrante della progettazione, del rilascio e del monitoraggio continuo del servizio.Vediamo quindi come questi rischi possono essere mitigati concretamente, e a quali livelli è necessario intervenire, a partire dall’esperienza maturata da CSI Piemonte.Red-teaming per assistenti GenAI nella PA: test ripetibiliPer affrontare questi rischi abbiamo scelto di non limitarci a una verifica manuale delle risposte, ma di sviluppare una suite di red-teaming per assistenti basati su AI generativa. L’obiettivo è trasformare i principali scenari di rischio in test ripetibili e automatizzati: conversazioni simulate, costruite per mettere sotto pressione l’assistente e verificare se mantiene il proprio mandato anche in presenza di richieste ambigue, manipolatorie o apertamente ostili.La suite viene eseguita sia sugli assistenti ancora in fase di sviluppo, sia su quelli già in esercizio quando cambia una componente rilevante del sistema: il prompt, la configurazione, il modello, la base documentale, i tool disponibili o le regole di comportamento. In questo modo ogni modifica significativa viene trattata come un cambiamento da validare, non come un semplice aggiornamento tecnico.Scenari avversari e dominio applicativoGli scenari di test combinano due livelli. Il primo è trasversale e si ispira alle principali tassonomie di rischio applicate ai sistemi GenAI, come prompt injection, tentativi di far cambiare ruolo all’assistente, richiesta di informazioni interne, generazione di contenuti ingannevoli o uso improprio degli strumenti disponibili. Il secondo livello è specifico del dominio applicativo e del mandato del singolo assistente. Nel caso di Camilla, ad esempio, i test includono scenari pensati per verificare che l’assistente non produca risposte discriminatorie o non eque, non assuma un ruolo amministrativo che non possiede, non fornisca indicazioni fuorvianti sulle procedure concorsuali e non esponga dettagli tecnici interni.Report, LLM-as-a-judge e revisione espertaL’esito della batteria di test viene raccolto in un report che evidenzia le vulnerabilità rilevate, le categorie di attacco, le conversazioni che hanno generato un comportamento anomalo e la valutazione associata. La valutazione automatica è supportata da un approccio LLM-as-a-judge: un modello verifica le risposte rispetto a criteri definiti a monte dagli esperti, come il comportamento atteso, le condizioni di successo e quelle di fallimento dello scenario. Questo permette di valutare dinamicamente risposte formulate in linguaggio naturale, senza ridurre il controllo a un semplice confronto con frasi predefinite.Il modello giudice, tuttavia, non rappresenta il punto finale del processo. Le vulnerabilità o i casi dubbi vengono analizzati da specialisti di materia e sicurezza, che verificano il contesto, interpretano l’effettiva gravità del comportamento e decidono gli interventi correttivi: rafforzamento del prompt, modifica dei guardrail, revisione della conoscenza disponibile, limitazione degli strumenti a disposizione dell’assistente o aggiornamento degli scenari di test. È in questo ciclo continuo, tra automazione e revisione umana, che il red-teaming diventa uno strumento operativo di governo dell’assistente.Prompt funzionale e prompt difensivo nei test di red-teamingVediamo ora un breve studio comparativo per mettere in luce il ruolo di uno dei livelli di difesa più peculiari dei sistemi GenAI: il prompt engineering. L’esperimento mette a confronto due versioni dello stesso assistente, testate con le medesime fonti documentali, gli stessi strumenti applicativi, lo stesso modello e la stessa suite di red-teaming. L’unica variabile significativa è il prompt.Il prompt funzionaleLa prima versione utilizza un prompt funzionale: definisce correttamente il mandato dell’assistente, il dominio informativo, il tono di comunicazione e le principali attività da svolgere. Non è quindi un prompt volutamente debole o costruito per fallire; è, al contrario, il tipo di prompt che potrebbe apparire adeguato se ci si concentrasse soltanto sull’utilità del servizio e sulla correttezza delle risposte in condizioni ordinarie.Il prompt difensivoLa seconda versione utilizza invece un prompt difensivo, o rinforzato: oltre a descrivere il compito dell’assistente, esplicita con maggiore chiarezza i limiti del suo mandato, i comportamenti da adottare in caso di richieste inappropriate, i casi in cui deve rifiutare o ricondurre la conversazione al perimetro previsto, le informazioni interne da non esporre e le cautele da applicare rispetto a richieste ambigue, manipolatorie o potenzialmente discriminatorie.Il confronto è utile proprio perché isola un aspetto spesso sottovalutato. Il prompt non è soltanto uno strumento per definire stile, personalità o formato della risposta: nei sistemi GenAI diventa anche uno strato di controllo del comportamento. Non sostituisce gli altri livelli di difesa, ma può incidere in modo significativo sulla capacità dell’assistente di mantenere il proprio ruolo quando viene sottoposto a scenari avversari.Figura 2 – Percentuale di attacchi avversari bloccati nei test di red-teaming. Il confronto mostra, a parità di modello, fonti documentali, strumenti applicativi e suite di test, la differenza tra un prompt funzionale e un prompt difensivo. Nel complesso, l’assistente con prompt funzionale ha bloccato il 61,9% degli attacchi avversari, mentre la versione con prompt difensivo ha raggiunto il 92,3%, con un miglioramento di 30,4 punti percentuali.I risultati delle simulazioni mostrano una differenza netta tra le due configurazioni. A parità di modello, fonti documentali, strumenti applicativi e suite di red-teaming, il prompt funzionale ha bloccato il 61,9% degli attacchi avversari, mentre il prompt difensivo ha raggiunto il 92,3%, con un miglioramento di 30,4 punti percentuali. Il dato è particolarmente significativo perché il prompt funzionale non era costruito per fallire: definiva correttamente il mandato dell’assistente e consentiva di rispondere alle richieste ordinarie. La differenza emerge quando l’assistente viene sottoposto a richieste manipolatorie, ambigue o fuori mandato.Il miglioramento è evidente soprattutto nelle categorie più legate al comportamento conversazionale: manipolazione di tono e stile, manipolazione del contesto temporale, prompt injection e jailbreak, esposizione di istruzioni interne. In questi casi il prompt difensivo aiuta l’assistente a riconoscere meglio i limiti del proprio ruolo, a rifiutare richieste inappropriate e a ricondurre la conversazione entro il perimetro previsto. Restano tuttavia alcune aree non completamente risolte, a conferma del fatto che il prompt engineering è uno strato di difesa importante, ma non sufficiente da solo, e va inoltre costantemente migliorato per garantire lo stesso livello di sicurezza al cambiare dei modelli di AI, dei dati e del contesto in cui si opera.Dal red-teaming alla fiducia operativa nella Pubblica AmministrazioneL’esperienza di red-teaming descritta mostra che la sicurezza di un assistente basato su GenAI non può essere valutata soltanto osservando la qualità delle risposte in condizioni ordinarie. Un assistente può apparire utile, pertinente e ben fondato sulle fonti, ma diventare fragile quando viene sollecitato con richieste ostili o anche semplicemente dovute alla naturale curiosità di utenti che cercano di testarne i limiti.Per questo il passaggio decisivo è trasformare i rischi in scenari verificabili. Non basta affermare che un assistente deve essere “sicuro”, “neutrale” o “affidabile”: occorre definire quali comportamenti sono accettabili, quali costituiscono una vulnerabilità, come misurarli e con quale processo correggerli. Nel nostro approccio, gli scenari generali ispirati alle tassonomie internazionali (OWASP) vengono affiancati da scenari costruiti sul dominio specifico del servizio, perché il rischio di un assistente per bandi pubblici non coincide con quello di un assistente sanitario, tributario o rivolto a procedimenti amministrativi diversi.Lo studio comparativo sul prompt conferma questa impostazione. A parità di fonti, strumenti, modello e suite di test, il passaggio da un prompt puramente funzionale a un prompt difensivo produce un impatto del 30.4% sulla capacità dell’assistente di bloccare richieste avversarie. Questo non significa che il prompt sia una soluzione sufficiente: significa che il prompt è uno degli strati di controllo del comportamento, da progettare e validare con la stessa attenzione con cui si progettano fonti, tool, permessi, logging e processi di revisione.La lezione più importante, quindi, è che la fiducia operativa non nasce da un singolo elemento tecnico. Non nasce soltanto dal modello, né dal RAG, né dal prompt, né da un controllo manuale finale. Nasce dalla combinazione di test continui e ripetibili, architetture difensive, metriche comprensibili e revisione da parte di esperti di materia e sicurezza. Questo è particolarmente importante nella Pubblica Amministrazione, dove l’assistente è percepito come punto di contatto con l’istituzione, e la capacità di governarne i limiti è parte integrante della qualità del servizio.In questa prospettiva, il red-teaming va interpretato come uno strumento di governo continuo. Permette di intercettare regressioni, misurare l’effetto delle modifiche, rendere tracciabili e auditabili le decisioni progettuali e costruire progressivamente assistenti non solo più utili, ma più affidabili.È questo il passaggio necessario per portare la GenAI nella Pubblica Amministrazione oltre la sperimentazione. Non basta dimostrare che un assistente risponde bene quando l’utente formula una domanda corretta. Occorre verificare che mantenga il proprio mandato anche quando la richiesta è ambigua, manipolatoria o apertamente ostile. In un servizio pubblico, dove l’assistente è percepito come punto di contatto con l’istituzione, governarne i limiti non è un dettaglio tecnico: è parte integrante della qualità, della responsabilità e della fiducia del servizio.