§4.1 Pianificazione e design
Il §4.1 elenca correttamente i profili da considerare nella fase di pianificazione e design, quali aspetti energetici, infrastrutturali, di rischio e di sostenibilità, ma non richiama tra le attività di progettazione iniziale il threat modeling specifico dei sistemi di IA. Si tratta però dell’attività che, in questa fase, consente di identificare prima della realizzazione del sistema le sorgenti di input non fidato, i sink privilegiati e le possibili catene che li collegano, orientando le scelte architetturali verso una separazione effettiva tra componenti ad alto privilegio e componenti esposti a input non fidati. La sua assenza nella fase di design rischia di tradursi in interventi di sicurezza tardivi, concentrati solo sul testing finale o sull’esercizio.
Raccomandazione: integrare il §4.1 prevedendo esplicitamente, tra le attività di sviluppo della fase di pianificazione e design, la conduzione di un threat modeling specifico per il sistema di IA. Tale attività dovrebbe almeno: (a) mappare le sorgenti di input distinguendole per livello di fiducia; (b) mappare i sink accessibili attraverso modelli, tool e orchestratori, distinguendoli per criticità e reversibilità delle azioni prodotte; (c) identificare le possibili catene sorgente-sink che attraversano il contesto del modello e i tool invocabili; (d) orientare le scelte del Layer Modelli IA e del Layer Applicazioni in modo da interrompere tali catene mediante segregazione, mediazione e controlli proporzionati al rischio identificato.
§4.2 Raccolta e trattamento dei dati e §4.3 Costruzione e/o addestramento dei modelli
Il §4.2 affronta la raccolta e il trattamento dei dati in termini di qualità, minimizzazione, efficienza energetica e governance dei flussi. Il §4.3 affronta la costruzione dei modelli in termini di dimensionamento, portabilità hardware e disaccoppiamento applicativo. In nessuno dei due paragrafi viene però trattato in modo esplicito il tema della supply chain dei dati di addestramento e dei modelli pre-addestrati come superficie di attacco, pur essendo questo un vettore di compromissione già richiamato nel capitolo 5 delle stesse Linee guida.
Sul lato dati, non sono previste in modo espresso verifiche di integrità e di provenance dei dataset, né controlli specifici contro data poisoning, availability poisoning, targeted poisoning o backdoor poisoning. Sul lato modelli, il paragrafo richiama il ricorso a fine-tuning e a modelli più piccoli o specializzati, ma non evidenzia che tali pratiche possono comportare l’importazione di pesi, checkpoint, adattatori o configurazioni prodotti da terzi, con il correlato rischio di alterazioni, backdoor o model poisoning.
Raccomandazione: integrare §4.2 e §4.3 prevedendo, tra le attività del Layer Modelli IA e del Layer Applicazioni, requisiti espliciti in materia di supply chain dei dati e dei modelli. In particolare:
(a) per il §4.2, tracciamento della provenienza dei dataset di addestramento, validazione e fine-tuning, con registrazione delle fonti, delle trasformazioni applicate e dei soggetti intervenuti; verifica di integrità dei dataset tramite hash, firme o controlli equivalenti; controlli specifici, proporzionati al rischio, per intercettare indizi di data poisoning;
(b) per il §4.3, verifica di integrità dei pesi, dei checkpoint e degli adattatori importati, inclusi quelli open weight; mantenimento di un inventario strutturato dei componenti del sistema di IA, assimilabile a una distinta base tecnica, comprendente modelli, adattatori, framework, librerie e, ove disponibili o dichiarati dal fornitore, informazioni sui dataset di pre-training; testing specifico del modello risultante dal fine-tuning per verificare l’assenza di comportamenti anomali rispetto a un modello di riferimento, come parte della successiva fase di testing e validazione.
§4.4 Testing, valutazione, verifica e validazione
Il §4.4 è la fase in cui, nel ciclo di vita di un sistema di IA, dovrebbe concentrarsi la verifica di sicurezza specifica del dominio IA. Il paragrafo cita correttamente performance, robustezza, affidabilità, bias e continuità funzionale, ma non include in nessuno dei cinque layer il testing avversariale (cosiddetto red-teaming) dei modelli e dei sistemi di IA, né il concetto di suite di regressione di sicurezza da rieseguire sistematicamente a ogni modifica significativa del sistema. Il riferimento a “robustezza” rischia così di essere interpretato soprattutto in chiave di continuità operativa, mentre il riferimento a dataset rappresentativi e scenari di uso reale è di per sé insufficiente a intercettare input malevoli intenzionalmente costruiti. Inoltre, il testing del Layer Applicazioni si limita all’integrazione nei flussi operativi, senza considerare che è proprio in quel punto di integrazione che si materializzano molte delle catene di attacco descritte nel capitolo 5.
Raccomandazione: integrare il §4.4, tra le attività del Layer Modelli IA e del Layer Applicazioni, prevedendo esplicitamente:
(a) il testing avversariale (red-teaming) dei modelli e dei sistemi di IA, proporzionato al livello di rischio e al perimetro d’azione del sistema, e mirato almeno alle principali categorie di attacco AI-specifiche, quali evasion, poisoning, prompt injection diretta e indiretta, model extraction, abuso dei sistemi generativi e uso improprio dei tool nelle architetture agentiche;
(b) la definizione di una suite di regressione di sicurezza che raccolga in modo strutturato i test avversariali, le minacce identificate nel threat modeling di §4.1, i payload di test e gli esiti attesi, da rieseguire sia periodicamente a intervalli prestabiliti, sia sistematicamente a ogni modifica significativa del sistema, come aggiornamenti del modello, modifiche del prompt di sistema, aggiunta di tool o connettori, o modifica dei corpora RAG;
(c) il testing del sistema nel suo complesso, e non solo del modello, includendo verifiche end-to-end dell’intera catena input → modello → tool → sistemi di backend, con scenari di attacco costruiti a partire dal threat modeling.
§4.6 Operatività e monitoraggio
Il §4.6 disciplina il monitoraggio del sistema di IA in esercizio principalmente in termini di drift, performance e qualità del servizio. Non è invece prevista in modo esplicito una specifica dimensione di monitoraggio della sicurezza AI, necessaria per rilevare indicatori o anomalie compatibili con tentativi di prompt injection, uso improprio dei tool e dei connettori, pattern di interrogazione riconducibili a tentativi di model extraction o di esfiltrazione di dati tramite output, nonché scostamenti significativi dai comportamenti attesi definiti nella suite di regressione di sicurezza. Parallelamente, il paragrafo presenta ri-addestramento, fine-tuning e sostituzione del modello come risposte al drift, senza prevedere che tali modifiche siano accompagnate da un riesame di sicurezza coerente con la fase di testing.
Raccomandazione: integrare il §4.6, tra le attività del Layer Modelli IA e del Layer Applicazioni, prevedendo esplicitamente:
(a) il monitoraggio di anomalie specifiche per la sicurezza dell’IA, tra cui almeno indicatori compatibili con tentativi di prompt injection diretta e indiretta, invocazione anomala o non prevista dei tool, pattern di query riconducibili a tentativi di model extraction o esfiltrazione di dati tramite output, deviazioni di comportamento rispetto ai test di regressione di sicurezza;
(b) l’integrazione di tali anomalie nei processi di gestione degli incidenti del sistema informativo dell’Amministrazione, con procedure di risposta e playbook dedicati al dominio IA;
(c) l’esecuzione periodica, e dopo ogni modifica significativa, della suite di regressione di sicurezza definita in §4.4, trattando il testing avversariale come attività ricorrente e non limitata al collaudo iniziale.
§4.7 Ritiro e/o disattivazione
Il §4.7 affronta correttamente la dismissione in termini di documentazione, reversibilità e continuità del servizio, ma non tratta in modo esplicito la dismissione sicura degli asset specifici dei sistemi di IA. Nei sistemi di IA, e in particolare in quelli agentici e basati su RAG, la dismissione lascia infatti residui sensibili che, se non gestiti, possono diventare materiale di attacco o di esposizione: corpora e indici vettoriali che contengono rappresentazioni derivate da documenti interni e dati personali; log di prompt, output e interazioni che possono includere informazioni riservate; credenziali, token e chiavi API di connettori e tool; checkpoint di modelli fine-tuned su dati dell’Amministrazione, che possono conservare o rendere inferibili informazioni derivate dai dati di addestramento.
Raccomandazione: integrare il §4.7 prevedendo, tra le attività del Layer Modelli IA e del Layer Applicazioni, una disciplina esplicita della dismissione sicura degli asset dei sistemi di IA, che includa almeno:
(a) cancellazione o archiviazione controllata degli indici e degli embedding, con verifica dell’effettiva rimozione o segregazione delle rappresentazioni derivate dai documenti indicizzati;
(b) cancellazione, pseudonimizzazione o archiviazione protetta dei log di prompt, output e interazioni, coerentemente con le policy di retention e con la normativa sulla protezione dei dati;
(c) revoca immediata delle credenziali, dei token e delle chiavi API dei connettori e dei tool invocabili dal sistema, con verifica attiva che nessuna credenziale revocata rimanga utilizzabile su sistemi esterni;
(d) dismissione controllata dei checkpoint dei modelli fine-tuned su dati dell’Amministrazione, con valutazione del rischio di persistenza o inferibilità di informazioni sensibili e con eventuali misure di cancellazione o archiviazione protetta.