Sezione “Test di Robustezza e Analisi Avversaria”
La sezione “Test di Robustezza e Analisi Avversaria” riduce di fatto l’analisi avversaria, nel caso della GenAI, al solo contrasto alla prompt injection e presenta i guardrail come filtri di contenuto sull’output che agiscono da “membrana di sicurezza esterna”. Questa impostazione rischia di indirizzare le Pubbliche Amministrazioni verso un modello di sicurezza troppo ristretto. La tassonomia di riferimento oggi più solida per l’adversarial machine learning copre infatti un insieme più ampio di categorie di attacco, che includono almeno evasion, poisoning, privacy attacks e model extraction, oltre alle minacce specifiche dei sistemi generativi e agentici. Inoltre, i guardrail intesi come filtri di input o output e classificatori di prompt injection costituiscono utili misure di difesa in profondità, ma non dovrebbero essere presentati come presidio sufficiente da soli: la sicurezza richiede anche controlli architetturali, separazione tra istruzioni e dati, limitazione delle capability, controlli umani per operazioni sensibili e testing continuo del sistema nel suo complesso.
Raccomandazione: riformulare la sezione prevedendo: (a) un’analisi avversaria estesa alle principali categorie di attacco AI-specifiche, includendo almeno evasion, poisoning, prompt injection diretta e indiretta, model extraction, membership inference e abuso dei tool nelle architetture agentiche; (b) una qualificazione esplicita dei guardrail come misura di difesa in profondità di natura euristica, da affiancare a controlli architetturali e non sostitutiva di essi, distinguendo tra filtri di input, filtri di output e policy engine; (c) l’introduzione del red-teaming dei sistemi di IA come attività ricorrente e proporzionata al rischio, condotta sul sistema nel suo complesso e non sul solo modello, nonché di test di regressione di sicurezza da rieseguire a ogni modifica significativa del sistema, quali aggiornamenti del modello, modifiche del prompt di sistema, aggiunta di tool o connettori, o modifiche del corpus RAG.
Sezione “Specializzazione del Modello: Fine-tuning”
La sezione sul fine-tuning tratta correttamente la qualità del dataset verticale e l’efficienza computazionale di tecniche come LoRA e QLoRA, ma non affronta due profili di sicurezza specifici. Il primo è che il modello pre-addestrato di partenza, in particolare se open-weight e ottenuto da repository di terze parti, costituisce un componente di supply chain a tutti gli effetti, e richiede verifiche di integrità, provenienza e tracciabilità analoghe a quelle richieste per altri componenti software critici. Il secondo è che il fine-tuning, anche quando parameter-efficient, può alterare in modo sostanziale il comportamento di sicurezza del modello base e degradarne l’allineamento, rendendo necessaria una nuova validazione prima della messa in esercizio. Più in generale, adattatori e tecniche PEFT non sono solo uno strumento di ottimizzazione, ma anche una superficie tecnica che può introdurre regressioni o alterazioni indesiderate del comportamento del modello.
Raccomandazione: integrare la sezione Fine-tuning prevedendo, per l’Operatore Avanzato o Esperto: (a) il trattamento del modello pre-addestrato di partenza come componente di supply chain, con verifica di integrità dei pesi e degli adattatori, accertamento della provenienza e tracciamento in un inventario strutturato dei componenti del sistema; (b) il trattamento del modello risultante dal fine-tuning come versione sostanzialmente modificata ai fini della sicurezza, da sottoporre prima della messa in esercizio a una nuova validazione di sicurezza, con particolare attenzione a possibili regressioni dell’allineamento rispetto al modello base; (c) la documentazione, nella scheda del modello, della tecnica di fine-tuning applicata, del dataset utilizzato, degli esiti dei test di sicurezza post fine-tuning e degli eventuali scostamenti rilevati rispetto al comportamento di sicurezza del modello base.
Sezione “Retrieval-Augmented Generation (RAG)”, indici vettoriali ed embedding come asset sensibili
La descrizione tecnica del vector database è corretta, ma non riconosce in modo esplicito che embedding e indici vettoriali sono rappresentazioni derivate dai documenti sorgente e possono, in determinate condizioni, esporre o rendere inferibili informazioni rilevanti sui contenuti originali. Quando i documenti indicizzati contengono dati personali o informazioni riservate, embedding e indici ereditano almeno in parte la sensibilità di tali contenuti e dovrebbero essere trattati come asset da proteggere, non come semplici strutture tecniche ausiliarie. Inoltre, la sezione non affronta un punto operativo essenziale: se il layer di retrieval non applica controlli di accesso coerenti con i permessi documentali del sistema sorgente, il RAG può restituire frammenti di documenti non autorizzati all’utente che ha posto la domanda, trasformandosi in un canale di esposizione non intenzionale delle informazioni.
Raccomandazione: integrare la sezione RAG prevedendo esplicitamente che: (a) embedding e indici vettoriali siano trattati come asset sensibili, con cifratura a riposo, controllo di accesso stretto, tracciamento degli accessi e politiche di dismissione sicura coerenti con la natura di rappresentazioni derivate; (b) il retrieval sia subordinato a un controllo di accesso allineato ai permessi documentali dell’ente, in modo che a ciascun utente siano restituiti solo frammenti provenienti da documenti per i quali è autorizzato; (c) le pipeline di indicizzazione siano progettate in coerenza con il modello dei permessi documentali, evitando indici o modalità di retrieval che annullino la segregazione di accesso esistente nei sistemi documentali sorgente.
Sezione “Retrieval-Augmented Generation (RAG)”, prompt injection indiretta e Super-Prompt
La descrizione del “Super-Prompt” cattura correttamente la meccanica del RAG, ma non evidenzia che la fusione, in un unico contesto del modello, di istruzioni di sistema, domanda dell’utente e contenuto di documenti recuperati costituisce la superficie di attacco classica per la prompt injection indiretta. In tale tipologia di attacco, istruzioni malevole nascoste all’interno dei documenti indicizzati o di contenuti esterni recuperati vengono interpretate dal modello come istruzioni operative e possono alterarne il comportamento, indurre divulgazione di informazioni o, nelle architetture agentiche, favorire l’invocazione non autorizzata di tool. Questo rischio è particolarmente rilevante in contesti PA in cui il corpus può includere documenti provenienti da fonti esterne, quali allegati, istanze, PEC o atti notificati, che devono essere trattati come input non fidato.
Raccomandazione: integrare la sezione RAG prevedendo che: (a) i frammenti di documenti recuperati siano trattati come input non fidato, indipendentemente dalla collocazione del corpus, e a maggior ragione quando questo include contenuti acquisiti da fonti esterne; (b) l’orchestratore implementi una separazione di fiducia tra istruzioni di sistema, domanda dell’utente e contenuto recuperato, adottando tecniche di delimitazione del contesto e di contenimento delle istruzioni embedded nei documenti, con l’esplicita consapevolezza che tali tecniche hanno natura euristica e non costituiscono garanzia assoluta; (c) le capability esercitabili dal modello a valle della costruzione del Super-Prompt siano limitate secondo il principio del minimo privilegio, in particolare nelle architetture agentiche in cui il modello può invocare tool con effetti su sistemi esterni; (d) il sistema sia sottoposto a test specifici per prompt injection indiretta come parte della validazione di sicurezza.
Sezione “Retrieval-Augmented Generation (RAG)”, “Sicurezza e Privacy” e definizione di data leakage
La sezione “Sicurezza e Privacy” presenta il vantaggio del RAG quasi esclusivamente nel fatto che i dati non vengano assorbiti nei pesi del modello durante l’addestramento. Questa osservazione è corretta, ma è troppo limitata per descrivere la reale postura di sicurezza di un sistema RAG. Restano infatti fuori dal perimetro descritto aspetti essenziali quali la sensibilità di embedding e indici vettoriali, l’allineamento del retrieval ai permessi documentali, la prompt injection indiretta tramite documenti recuperati, la protezione dei log di prompt e output e la dismissione sicura degli artefatti derivati. Inoltre, la definizione di “data leakage” inserita tra parentesi corrisponde al significato classico di machine learning, cioè contaminazione del training set con dati di test o validazione, mentre nel contesto della sezione il lettore presumibilmente si aspetta il significato pertinente alla sicurezza e alla privacy, cioè esposizione o fuoriuscita non autorizzata di dati riservati. L’accostamento dei due significati nello stesso passaggio è fonte di confusione.
Raccomandazione: riformulare e ampliare la sezione “Sicurezza e Privacy” del paragrafo RAG, in particolare: (a) eliminare l’equivalenza implicita tra “dati non assorbiti nei pesi” e “rischi di data leakage ridotti”, chiarendo che il confinamento dei dati nei sistemi della PA è una proprietà utile ma non sufficiente; (b) integrare esplicitamente i rischi specifici dei sistemi RAG, tra cui la sensibilità di embedding e indici come rappresentazioni derivate, la necessità di un retrieval coerente con i permessi documentali, la prompt injection indiretta tramite documenti recuperati, la protezione dei log di prompt e output e la dismissione sicura degli artefatti del sistema; (c) correggere o eliminare la definizione tra parentesi di “data leakage”, sostituendola con il significato pertinente al contesto di sicurezza e privacy oppure rinviando alla corrispondente voce del glossario, ove integrata.