La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 5. Sicurezza cibernetica.
I commenti dovranno includere il numero del paragrafo o sotto-paragrafo (se presente) e un riferimento puntuale al brano di testo al quale si riferiscono (ad esempio paragrafo 4.3, terzo capoverso).
Si propone di rafforzare, nel capitolo 5 - Sicurezza cibernetica, il riferimento a soluzioni locali, modulari e open source basate su server Linux LTS hardenizzati, LLM locali leggeri e applicazioni in Python/Flask.
Tale approccio consente maggiore controllo su dati, documenti, configurazioni, log e processi, rafforza tracciabilità, resilienza, portabilità e riduce l’esposizione a dipendenze tecnologiche esterne. In questa prospettiva, la sicurezza cibernetica risulta maggiormente governabile dall’amministrazione lungo tutto il ciclo di vita del sistema di IA.
Nel paragrafo 5.5 - Tassonomie di attacco si potrebbero inserire ulteriori tipologie di attacco senza modificare le macro-categorie individuate.
Propongo di inserire un paragrafo relativo alla sicurezza della supply chain dei modelli, e non limitare ad uno scenario da tenere in considerazione nelle scelte progettuali.
Sicurezza della supply chain dei sistemi di intelligenza artificiale
Nell’ambito dello sviluppo e dell’adozione di sistemi di intelligenza artificiale, le Pubbliche Amministrazioni devono considerare i rischi connessi alla supply chain dei modelli, dei dataset e delle componenti software utilizzate.
L’utilizzo di modelli pre-addestrati, framework di machine learning, librerie software e dataset provenienti da terze parti può introdurre vulnerabilità o componenti compromesse all’interno dei sistemi di IA. In particolare, tali rischi possono includere l’utilizzo di modelli alterati, dataset malevoli, dipendenze software vulnerabili o componenti provenienti da fonti non affidabili.
Per mitigare tali rischi, le amministrazioni dovrebbero adottare misure volte a garantire la provenienza, l’integrità e la tracciabilità delle componenti utilizzate nei sistemi di IA, lungo l’intero ciclo di vita del sistema, dalla fase di sviluppo fino al deployment e alla gestione operativa.
A tal fine, le Pubbliche Amministrazioni dovrebbero prevedere:
meccanismi di verifica della provenienza dei modelli e dei dataset utilizzati, privilegiando fonti affidabili e repository ufficiali;
la verifica dell’integrità dei modelli e degli artefatti software, ad esempio attraverso meccanismi di firma digitale o controllo degli hash;
procedure di gestione e monitoraggio delle dipendenze software utilizzate nei framework e nelle pipeline di machine learning;
strumenti di inventario e tracciabilità delle componenti dei sistemi di IA, analoghi ai Software Bill of Materials (SBOM), inclusi modelli emergenti di AI Bill of Materials (AI-BOM) per la documentazione delle componenti e delle dipendenze dei sistemi di IA.
L’adozione di tali misure contribuisce a rafforzare la sicurezza della supply chain dei sistemi di IA e a ridurre il rischio di introduzione di componenti compromesse o vulnerabili nei sistemi utilizzati dalla Pubblica Amministrazione.
Contributo a cura della Taskforce IA dell’Autorità Nazionale Anticorruzione (ANAC)
L’impostazione del capitolo è sbilanciata sul piano teorico. Pur offrendo una classificazione completa delle minacce, mancano indicazioni operative su come implementare concretamente le misure di mitigazione. Questo gap rischia di rendere le Linee Guida difficilmente applicabili, soprattutto per le amministrazioni con minori competenze specialistiche.
Rileviamo inoltre una scarsa integrazione con le pratiche di sicurezza già consolidate in ambito IT (DevSecOps, IAM, sicurezza API, cloud), con il rischio di trattare la sicurezza IA come un dominio isolato. Analogamente, il richiamo a normative come la NIS2 non è accompagnato da una traduzione in controlli tecnici e organizzativi concreti.
Riteniamo quindi necessario integrare il capitolo con esempi operativi di mitigazione, rafforzare il collegamento con i framework di sicurezza esistenti e definire una baseline minima di sicurezza per i sistemi IA, eventualmente differenziata per livelli di rischio, così da garantire maggiore uniformità ed efficacia nell’applicazione.
§5.6.1 Modellare le minacce ai sistemi
Il paragrafo richiama correttamente il threat modeling specifico per l’IA e rinvia alle Linee guida AGID su Secure/Privacy by Design, ma non declina in modo esplicito le peculiarità del threat modeling per sistemi di IA moderni, in particolare quelli agentici e basati su RAG descritti al capitolo 3. In tali sistemi, la superficie di attacco si caratterizza per la presenza simultanea di sorgenti di input con diverso livello di fiducia, quali prompt utente, documenti recuperati via RAG, output di tool o contenuti provenienti da fonti esterne, e di sink privilegiati, quali tool che invocano API, eseguono codice, modificano file o accedono a backend, collegati attraverso il contesto del modello. Un threat modeling condotto con le sole tecniche tradizionali rischia di non cogliere adeguatamente le catene sorgente-sink che attraversano il modello e di non orientare le scelte architetturali verso un’effettiva separazione tra input meno affidabili e capability più privilegiate.
Raccomandazione: integrare il §5.6.1 prevedendo esplicitamente che, nel threat modeling dei sistemi di IA, si proceda a: (a) mappare le sorgenti di input del sistema distinguendole per livello di fiducia, includendo i canali indiretti come i corpora RAG e gli output di tool e connettori; (b) mappare i sink privilegiati accessibili attraverso il modello, i tool e l’orchestratore, distinguendoli per criticità e reversibilità delle azioni prodotte; (c) identificare le catene sorgente-sink attraverso cui un input non fidato può influenzare un sink privilegiato, in particolare nelle architetture agentiche; (d) orientare le scelte architetturali verso una separazione di fiducia e privilegi proporzionata alle catene identificate, limitando le capacità esercitabili a valle di input a minore affidabilità.
§5.6.2 Analisi statica e dinamica del codice
SAST e DAST sono tecniche consolidate per il codice applicativo tradizionale e restano necessarie anche per i sistemi di IA, ma non intercettano da sole le classi di vulnerabilità specifiche del dominio IA, quali prompt injection diretta e indiretta, evasion, model extraction, abuso di tool nelle architetture agentiche o esfiltrazione via output. Tali vulnerabilità emergono infatti dal comportamento del modello e dalle interazioni tra modello, contesto, tool e orchestratore, e non risultano pienamente visibili all’analisi del codice sorgente o alle tecniche DAST convenzionali. Il paragrafo, inoltre, non introduce ancora in modo esplicito il concetto di regressione di sicurezza specifica per il dominio IA, essenziale in un contesto nel quale aggiornamenti del modello, modifiche del prompt di sistema, inserimento di nuovi tool o cambiamenti ai corpora RAG possono reintrodurre vulnerabilità già mitigate.
Raccomandazione: integrare il §5.6.2, oppure affiancare un sotto-paragrafo dedicato, prevedendo esplicitamente, in aggiunta a SAST e DAST: (a) il testing avversariale (ovvero, red-teaming) dei modelli e dei sistemi di IA come attività ricorrente, proporzionata al rischio e mirata almeno alle categorie di attacco richiamate al §5.5 e ai rischi specifici degli agenti al §5.4; (b) una suite di regressione di sicurezza specifica per il dominio IA, che raccolga in forma strutturata i test avversariali e i payload associati alle minacce identificate in sede di threat modeling, da rieseguire periodicamente e a ogni modifica significativa del sistema; (c) il testing end-to-end del sistema nel suo complesso lungo la catena input → modello → tool → sistemi di backend, anziché del solo modello isolato.
§5.7.1 Sviluppo sicuro, controllo “Validare e sanitizzare tutti gli input”
Il controllo è utile, ma, se letto isolatamente, può essere interpretato in termini troppo vicini alla sicurezza applicativa tradizionale, dove validazione e sanitizzazione su formati rigidamente strutturati sono efficaci. Nel caso generale dei modelli generativi, gli input in linguaggio naturale non ammettono una “sanitizzazione” deterministica paragonabile a quella di formati a grammatica chiusa. Lo stesso vale per gli input indiretti provenienti da documenti recuperati via RAG o dagli output di tool. Filtri di input e output, classificatori di prompt injection e policy engine possono costituire una difesa euristica in profondità, ma non dovrebbero essere letti come presidio sufficiente da soli contro prompt injection e manipolazione del contesto. Nel medesimo capitolo, peraltro, compaiono già controlli più strutturali, quali restrizioni sulle azioni, meccanismi esterni di fail-safe e principio del privilegio minimo.
Raccomandazione: riformulare il controllo chiarendo che: (a) per gli input in linguaggio naturale, filtri, classificatori di prompt injection e policy engine costituiscono una difesa euristica in profondità e non un controllo di sicurezza primario; (b) il controllo primario rispetto al prompt injection e al suo sfruttamento è anche architetturale, e consiste nel limitare le azioni consentite, applicare il principio del privilegio minimo e separare, per quanto possibile, i componenti esposti a input meno affidabili da quelli che dispongono di capability privilegiate; (c) analoghe considerazioni si applicano agli input indiretti provenienti da corpora RAG e da output di tool, che devono essere trattati come input non fidati a tutti gli effetti.
§5.3 Asset e §5.7 Buone pratiche per la PA
La classificazione degli asset al §5.3 è mutuata dalla tassonomia ENISA del 2020 e resta utile come quadro generale, ma non rende espliciti alcuni asset particolarmente rilevanti nei sistemi di IA generativa e agentici descritti al capitolo 3. In particolare, non sono nominati in modo espresso: (a) i corpora documentali, gli indici vettoriali e gli embedding utilizzati nelle architetture RAG; (b) i prompt di sistema, le configurazioni dell’orchestratore e le definizioni dei tool, che influenzano direttamente il comportamento del sistema; (c) le credenziali, i token e le chiavi API dei connettori e dei tool invocabili dal sistema; (d) i log di prompt, output e interazioni. Tali elementi possono in parte essere ricondotti alle categorie generali già presenti, ma la loro mancata esplicitazione ne riduce la visibilità come asset sensibili da proteggere e monitorare.
Raccomandazione: integrare il §5.3 estendendo, o almeno esemplificando in modo più puntuale, la categorizzazione degli asset con riferimento a corpora documentali, indici vettoriali ed embedding, prompt di sistema e configurazioni dell’orchestratore, definizioni dei tool e relative credenziali, log di prompt, output e interazioni. Integrare coerentemente il §5.7 prevedendo controlli specifici su tali asset, in particolare: protezione della riservatezza e dell’integrità degli indici vettoriali e degli embedding; versionamento e controllo di accesso ai prompt di sistema e alle configurazioni dell’orchestratore; gestione dedicata delle credenziali dei connettori e dei tool, con applicazione del principio del privilegio minimo anche alle capability esercitabili dal sistema di IA.
§5.7.3 Gestione e manutenzione sicura, controllo sui log
Il controllo tratta i log principalmente come strumento di detection. Nei sistemi di IA generativa, tuttavia, i log di prompt, output e interazioni costituiscono essi stessi un asset sensibile e una potenziale via di esfiltrazione: i prompt degli utenti possono contenere dati personali o informazioni riservate inserite inconsapevolmente; gli output del modello possono, in alcuni casi, contenere informazioni derivate da dati di addestramento, da contesti RAG o da documenti riservati recuperati in esecuzione. Una pipeline di logging non adeguatamente protetta può quindi trasformarsi in un canale di esposizione massiva di dati sensibili. Inoltre, proprio i log rappresentano la base informativa necessaria per il monitoraggio di anomalie AI-specifiche, quali pattern compatibili con prompt injection, model extraction, invocazione anomala di tool o esfiltrazione via output.
Raccomandazione: integrare il §5.7.3 prevedendo esplicitamente che i log di prompt, output e interazioni dei sistemi di IA siano trattati come asset sensibili, con almeno: (a) minimizzazione alla fonte e pseudonimizzazione ove compatibile con le finalità di sicurezza; (b) cifratura a riposo e in transito; (c) controllo di accesso stretto con principio del privilegio minimo, separazione dei ruoli tra gestione operativa e analisi di sicurezza, tracciamento degli accessi; (d) politiche di retention definite e coerenti con la normativa sulla protezione dei dati; (e) valutazione specifica della sicurezza delle pipeline di esportazione verso sistemi esterni di osservabilità; (f) uso dei log come base per il monitoraggio di anomalie specifiche dell’IA, integrato nei processi di gestione degli incidenti dell’Amministrazione.
§5.2 Gestione del rischio e §5.6 Obiettivi di sicurezza
Il capitolo 5 richiama già riferimenti rilevanti, tra cui NIST AI RMF, MITRE ATLAS, ENISA AI Cybersecurity Challenges, NIST AI 100-2 e le linee guida NCSC. Tuttavia, nei §5.2 e §5.6 i riferimenti guida espliciti nel corpo del testo sono soprattutto NIST AI RMF e NCSC, mentre altri riferimenti tecnico-metodologici rilevanti compaiono in nota o in paragrafi adiacenti e non risultano consolidati in un quadro unitario. Ne deriva una tracciabilità solo parziale delle prescrizioni e delle buone pratiche, specialmente per temi emersi con maggiore forza nei sistemi generativi e agentici, quali prompt injection, sicurezza del RAG, abuso di tool, model extraction via API e testing avversariale.
Raccomandazione: integrare il §5.2 e il §5.6 consolidando nel corpo del testo, oppure in un riquadro o sottoparagrafo dedicato ai riferimenti tecnico-metodologici, un insieme di fonti coerente con lo stato dell’arte, indicando almeno: NIST AI RMF 1.0, ossia NIST AI 100-1, e il relativo Generative AI Profile, NIST AI 600-1; NIST AI 100-2 come tassonomia di riferimento per gli attacchi adversarial; MITRE ATLAS come knowledge base di tattiche e tecniche avversarie; ENISA AI Cybersecurity Challenges e ENISA Multilayer Framework for Good Cybersecurity Practices for AI; OWASP Top 10 for Large Language Model Applications e OWASP AI Security and Privacy Guide; ISO/IEC 42001:2023 per il sistema di gestione dell’IA; ISO/IEC 23894:2023 per la gestione del rischio AI; ISO/IEC TR 24029-1:2021 per la valutazione della robustezza delle reti neurali. Il richiamo esplicito a tali fonti rafforzerebbe la tracciabilità delle prescrizioni e ne faciliterebbe la resa operativa da parte delle Amministrazioni.
Riferimento: Paragrafo 5.7 “Buone pratiche per la PA”, capoverso introduttivo e sotto-paragrafi 5.7.1 (Sviluppo sicuro), 5.7.2 (Deployment sicuro), 5.7.3 (Gestione e manutenzione sicura).
Brano di riferimento: “Si riportano di seguito alcune pratiche RACCOMANDATE per le fasi di sviluppo, deployment e manutenzione di un sistema IA.”
Osservazione: Il documento, fino al paragrafo 5.6 incluso, utilizza in modo pervasivo formulazioni con “DEVE” e “DEVONO” — coerentemente con l’uso che viene dichiarato al paragrafo 1.3.1 (“note di lettura”), dove si specifica che tali termini indicano un requisito obbligatorio. Improvvisamente, al paragrafo 5.7, il livello di obbligo viene declassato a “RACCOMANDATO”, e l’elenco che segue contiene pratiche di sicurezza che in qualunque framework cyber consolidato (ISO/IEC 27001, NIST SP 800-53, CIS Controls, OWASP ASVS) sono requisiti obbligatori, non raccomandazioni. In particolare, tra le pratiche declassate a RACCOMANDATO compaiono:
sotto 5.7.1: la gestione del codice in sistemi di controllo versione con controlli di accesso; la validazione e sanitizzazione di tutti gli input contro attacchi di tipo prompt injection; l’uso di firme digitali e checksum per l’integrità degli artefatti; l’adozione di sistemi di rollback automatici;
sotto 5.7.2: l’esecuzione in sandbox tramite container o VM; la cifratura dei dati a riposo; la protezione del traffico di rete con TLS; l’autenticazione multi-fattore (MFA) per tutti gli utenti; il controllo accessi basato su ruoli o attributi (RBAC/ABAC);
sotto 5.7.3: l’applicazione di patch di sicurezza; l’uso di sistemi di rilevamento e prevenzione delle intrusioni (IDS/IPS); la raccolta di log; l’esecuzione di penetration test e vulnerability assessment.
Il declassamento di questi controlli a “raccomandazione” è incoerente sotto tre profili. Primo profilo, normativo: l’art. 15 dell’AI Act — citato dal documento stesso al paragrafo 5.2 — impone che i sistemi di IA ad alto rischio garantiscano un “adeguato livello di accuratezza, robustezza e cibersicurezza”; declassare a raccomandazione l’autenticazione multi-fattore, la sanitizzazione degli input e la gestione delle patch è incompatibile con questo obbligo. Secondo profilo, di coerenza interna: il documento usa “DEVE” per prescrizioni di portata e plausibilità tecnica molto inferiori (ad esempio l’esecuzione su CPU-only di modelli di grandi dimensioni, o l’adozione di “standard di mercato aperti” per le interfacce di inferenza) e poi declassa a “raccomandazione” controlli di sicurezza la cui obbligatorietà è universalmente riconosciuta. Terzo profilo, operativo: un funzionario che redige un capitolato di gara basandosi sul documento potrebbe legittimamente non includere come requisito obbligatorio l’autenticazione MFA o la sanitizzazione degli input, generando esposizioni di sicurezza concrete sui sistemi IA della PA.
Proposta di modifica: Riformulare integralmente il paragrafo 5.7 distinguendo esplicitamente tra:
Pratiche obbligatorie (“DEVONO”) — da applicarsi a tutti i sistemi di IA della PA indipendentemente dal livello di rischio, includendo come minimo: gestione del codice in sistemi di controllo versione con controlli di accesso; sanitizzazione e validazione di tutti gli input (con specifico riferimento agli attacchi di prompt injection); cifratura dei dati a riposo e in transito; autenticazione multi-fattore per gli utenti amministrativi; controllo accessi RBAC o ABAC; raccolta e conservazione dei log di sicurezza; applicazione tempestiva delle patch; uso di protocolli di comunicazione sicuri.
Pratiche raccomandate (“DOVREBBERO”) — da valutare in funzione del livello di rischio del sistema, includendo ad esempio: penetration test periodici condotti da terze parti; uso di moduli di sicurezza hardware (HSM); implementazione di sistemi IDS/IPS dedicati; ingaggio di esperti di sicurezza esterni.
Pratiche specifiche per sistemi ad alto rischio ai sensi dell’AI Act — obbligatorie per la categoria di sistemi che ricadono nell’ambito dell’art. 6 e dell’Allegato III dell’AI Act.
La distinzione consentirebbe di mantenere il principio di proporzionalità (cui il documento aspira) senza declassare a “raccomandazione” controlli di sicurezza il cui carattere obbligatorio è universalmente riconosciuto in tutti gli standard di settore.
Riferimento: Paragrafo 5.5.2 “Poisoning attacks”, quarto elenco puntato (model poisoning), e paragrafo 5.5.3 “Privacy attacks”, nel suo complesso.
Brano di riferimento (5.5.2): “model poisoning: modificano direttamente il modello addestrato iniettandogli funzionalità malevole. Possono determinare una violazione sia dell’integrità che della disponibilità e avvengono generalmente nell’ambito del cosiddetto apprendimento federato in cui sistemi client inviano aggiornamenti locali del modello a un server che li aggrega in un modello globale.”
Osservazione: Il paragrafo 5.5.2 individua correttamente il Federated Learning come ambito specifico di vulnerabilità agli attacchi di model poisoning. Tuttavia, al paragrafo 3.4.1 e nella Tabella 4, il Federated Learning viene presentato come terza opzione di deploy per il training dei modelli, senza alcun riferimento alle vulnerabilità di sicurezza discusse cinquanta pagine più avanti nel capitolo 5. Lo stesso problema, in forma più sottile, riguarda il paragrafo 5.5.3 sui privacy attacks: la trattazione di membership inference, model extraction, data reconstruction e property inference non discute come questi attacchi si applichino in modo specifico ai modelli sottoposti a fine-tuning con tecniche PEFT e LoRA, citate al paragrafo 3.2.1 senza alcuna avvertenza sui rischi di estrazione di informazioni dagli adattatori. Gli adattatori LoRA, in particolare, sono di dimensioni ridotte e tecnicamente più esposti agli attacchi di model extraction rispetto a un modello completo. Il risultato è che il documento tratta separatamente argomenti che dovrebbero essere collegati, lasciando al lettore l’onere di mettere in relazione il capitolo che descrive una tecnica con il capitolo che ne discute i rischi di sicurezza.
Proposta di modifica: Inserire riferimenti incrociati espliciti in entrambe le direzioni:
Al paragrafo 3.4.1 (opzione 3 - Federated Learning), aggiungere una nota a piè di pagina o un breve inciso che richiami il paragrafo 5.5.2 per la trattazione delle vulnerabilità specifiche.
Al paragrafo 3.2.1 (descrizione delle tecniche PEFT e LoRA), aggiungere una nota analoga che richiami il paragrafo 5.5.3 per la discussione delle vulnerabilità ad attacchi di privacy applicate agli adattatori e ai modelli sottoposti a fine-tuning.
Specularmente, al paragrafo 5.5.2 inserire un riferimento al 3.4.1 e al paragrafo 5.5.3 inserire un riferimento al 3.2.1, in modo che chi legge il capitolo sulla sicurezza possa risalire alle sezioni del capitolo 3 che presentano le tecniche corrispondenti.
Più in generale, considerare l’opportunità di una revisione editoriale che assicuri la presenza sistematica di riferimenti incrociati tra il capitolo 3 (architettura) e il capitolo 5 (sicurezza), poiché ogni scelta architetturale ha implicazioni di sicurezza che il documento attualmente discute in modo non sinergico.
Riferimento: Paragrafo 5.1 “Ciclo di vita”, elenco delle fasi del ciclo di vita di un sistema di IA, in confronto con il capitolo 4 “Ciclo di vita dei sistemi di Intelligenza Artificiale e azioni per lo sviluppo e il procurement”, elenco delle fasi all’inizio del capitolo.
Brano di riferimento: Al paragrafo 5.1 il ciclo di vita è suddiviso in undici fasi: “definizione dell’obiettivo; raccolta dei dati; esplorazione dei dati; pre-elaborazione dei dati; selezione delle caratteristiche; selezione del modello; addestramento del modello; tuning del modello; trasferimento dell’apprendimento; distribuzione del modello; manutenzione del modello; valutazione del raggiungimento dell’obiettivo”. Al capitolo 4 il ciclo di vita è invece definito in sette fasi: “Pianificazione e design; Raccolta e trattamento dei dati; Costruzione e/o adattamento dei modelli; Testing, valutazione, verifica e validazione; Messa a disposizione per l’utilizzo; Operatività e monitoraggio; Ritiro / disattivazione”.
Osservazione: Il documento utilizza dunque due tassonomie diverse del ciclo di vita di un sistema di IA, in due capitoli distinti, senza che le due tassonomie siano mai messe in relazione esplicita. Non si tratta semplicemente di un livello di granularità differente: le due tassonomie hanno strutture concettuali diverse. Ad esempio, il paragrafo 5.1 include esplicitamente la fase di “trasferimento dell’apprendimento” (fine-tuning su modello pre-addestrato) come fase distinta, mentre il capitolo 4 la include implicitamente nella fase 3 “Costruzione e/o adattamento dei modelli”. Inoltre, il paragrafo 5.1 non contempla esplicitamente una fase di “ritiro/disattivazione”, che è invece la settima fase del capitolo 4. La conseguenza pratica è che gli obblighi di sicurezza identificati nel capitolo 5 — costruiti sulla tassonomia a undici fasi — non sono mappabili in modo univoco sulle azioni del capitolo 4, che è il capitolo operativo che il funzionario deve seguire per progettare, sviluppare e dismettere il sistema. Una PA che voglia tradurre gli obblighi di sicurezza del capitolo 5 in azioni concrete del proprio piano di sviluppo è costretta a effettuare in proprio l’operazione di mappatura tra le due tassonomie.
Proposta di modifica: Adottare nel documento una tassonomia unica del ciclo di vita dei sistemi di IA, applicata in modo coerente sia nel capitolo 4 (azioni per lo sviluppo) sia nel capitolo 5 (sicurezza). In alternativa, qualora si ritenga necessario mantenere due tassonomie distinte (ad esempio perché il capitolo 5 si appoggia esplicitamente al modello ENISA citato nella nota 3), inserire al paragrafo 5.1 una tabella di corrispondenza esplicita tra le undici fasi della tassonomia di sicurezza e le sette fasi della tassonomia operativa del capitolo 4. La tabella consentirebbe al funzionario di identificare immediatamente, per ciascuna fase del proprio piano di sviluppo, quali obblighi di sicurezza siano applicabili.
Confintesa FP — Federazione Funzione Pubblica (organizzazione sindacale maggiormente rappresentativa nel Comparto Funzioni Centrali) presenta le seguenti osservazioni nell’ambito della consultazione pubblica (Determinazione AgID n. 43 del 10 marzo 2026). Il testo integrale delle osservazioni sarà trasmesso formalmente ad AgID.
OSSERVAZIONE — Sistemi UEBA e controllo a distanza dei lavoratori (sez. 5)
La sez. 5 prevede sistemi di analisi comportamentale di utenti ed entità (User and Entity Behavior Analytics — UEBA) come misura di sicurezza informatica. Nella pratica amministrativa, i sistemi UEBA tracciano inevitabilmente il comportamento individuale dei dipendenti: tempi di lavorazione, frequenza d’uso delle funzioni, pattern di accesso diventano metriche individuali della prestazione, senza che le Linee Guida pongano alcun limite al loro utilizzo a fini valutativi o disciplinari.
I sistemi UEBA rientrano nelle fattispecie soggette all’art. 4 della L. 300/1970 (controllo a distanza della prestazione lavorativa) e agli obblighi informativi del D.Lgs. 104/2022 (Decreto Trasparenza). La Circolare INL n. 4/2022 ha chiarito che i sistemi di monitoraggio automatizzato della prestazione richiedono accordo sindacale o autorizzazione dell’Ispettorato Nazionale del Lavoro. Le Linee Guida non contengono alcun riferimento a questi vincoli.
Proposta di integrazione alla sez. 5:
– I dati raccolti dai sistemi UEBA che siano riconducibili, anche indirettamente, al comportamento individuale dei dipendenti NON DEVONO essere utilizzati per finalità di valutazione della prestazione senza previo accordo sindacale ai sensi dell’art. 4, co. 1, L. 300/1970 o autorizzazione INL, né per l’attivazione di procedimenti disciplinari.
– I sistemi UEBA NON DEVONO produrre profili individuali della prestazione lavorativa né alimentare processi decisionali automatizzati ai sensi dell’art. 22 GDPR. La PA DEVE adottare misure tecniche (pseudonimizzazione, aggregazione statistica) per impedire tale utilizzo.
– Prima del dispiegamento, la PA DEVE adempiere agli obblighi informativi del D.Lgs. 104/2022 e, ove applicabile, condurre valutazione di impatto sulla protezione dei dati ai sensi dell’art. 35 GDPR, comunicandone gli esiti alle organizzazioni sindacali.
Confintesa FP — Segretario Generale Claudia Ratti | www.confintesafp.it
Segnaliamo le nostre proposte.
Cordialmente
In riferimento all’intero capitolo, oltre ai rischi generali legati alla sicurezza dei sistemi IA, è necessario considerare specifiche minacce emergenti:
Di seguito alcune osservazioni puntuali
Paragrafo 5.2 - Pag 91
Si propone l’inserimento del seguente capoverso “Le metodologie strutturate di analisi del rischio, come quelle definite negli standard IEC 60812 e ISO 31010 (FMEA, analisi della criticalità, matrici di rischio), possono essere applicate anche ai sistemi di intelligenza artificiale per valutare in modo sistematico modalità di guasto, vulnerabilità e impatti operativi.”
Paragrafo 5.2 - Pag. 92
Le metodologie strutturate di analisi del rischio, come quelle definite negli standard IEC 60812 e ISO 31010 (FMEA - Failure Mode and Effects Analysis, analisi della criticalità, matrici di rischio), possono essere applicate anche ai sistemi di intelligenza artificiale per valutare in modo sistematico modalità di guasto, vulnerabilità e impatti operativi.
Paragrafo 5.3 pag 94
Si segnala un disallineamento di termini: quando si affronta il tema del ciclo di vita si utilizza il termine “manutenzione del ciclo di vita”, mentre qui si parla di “mantenimento del modello”. Si propone di utilizzare “mantenimento del modello” in entrambi i passaggi.
Paragrafo 5.6 - Pag 99
Per rendere ancora più esplicito che la sezione riguarda obiettivi di sicurezza lungo ciclo di vita e non solo sviluppo sarebbe opportuno chiarire che “In questa sezione sono enunciati gli obiettivi di sicurezza che devono guidare lo sviluppo e l’esercizio dei sistemi di IA da parte della Pubblica Amministrazione.”
Paragrafo 5.7
Manca un riferimento alla gestione comunicativa degli incidenti. Si propone di includere indicazioni per la comunicazione di crisi, in caso di malfunzionamenti, errori o impatti negativi dei sistemi IA.
Contributo a cura di Dedalus Italia S.p.A.
Nei sistemi di Intelligenza Artificiale utilizzati in ambiti ad alta criticità, come sanità e servizi pubblici essenziali, Dedalus adotta un approccio di sicurezza by design e by default integrato lungo l’intero ciclo di vita del sistema e allineato a pratiche riconosciute di secure development e security verification. In tale prospettiva, si propone che le Linee Guida richiamino in modo più esplicito framework e standard operativi di riferimento per la componente applicativa, così da fornire alle PA criteri concreti per definire requisiti minimi e verifiche (ad esempio framework OWASP per secure development e verification, quali OWASP SAMM e OWASP ASVS, oltre a pratiche consolidate di code review e security testing).
Per i sistemi basati su modelli generativi, LLM e architetture agentiche, si suggerisce inoltre di esplicitare le minacce specifiche e le superfici di attacco tipiche, quali: prompt injection, data exfiltration, jailbreaking, abuso di tool/plugin e integrazioni esterne, avvelenamento della supply chain e delle dipendenze, leakage di informazioni sensibili, nonché rischi legati a output non affidabili in contesti decisionali. Un richiamo esplicito a linee guida riconosciute (ad esempio OWASP per le applicazioni basate su LLM) contribuirebbe a mantenere le Linee Guida aggiornate rispetto all’evoluzione delle minacce e dei casi d’uso.
Infine, per rendere la sezione realmente utile alle PA come criterio operativo, si propone di indicare aspettative minime verificabili su:
(i) security testing e verifiche periodiche, includendo test specifici per sistemi generativi/agentici (adversarial testing/red teaming, test su prompt e guardrail, validazione dei tool invocati);
(ii) gestione delle dipendenze e della supply chain (inventario componenti e dipendenze, controllo vulnerabilità, policy di aggiornamento e patching);
(iii) monitoraggio e logging a supporto di detection e incident response, includendo tracciabilità delle decisioni dell’orchestrazione, delle chiamate a tool esterni e dei principali eventi di sicurezza;
(iv) validazione periodica dei modelli e dei controlli di sicurezza, per gestire regressioni, drift e cambiamenti di comportamento nel tempo.
Tali elementi renderebbero la sezione sicurezza non solo descrittiva, ma concretamente utilizzabile dalle PA per progettazione, verifica e procurement di sistemi di IA.
Contributo a cura di Traent Srl.
Si propone di integrare il §5.7.3 “Gestione e manutenzione sicura” con un requisito esplicito di valore probatorio dei log di sicurezza. L’attuale formulazione prescrive di «raccogliere log su comportamento, input, output ed errori del sistema» (pag. 105) con finalità di monitoraggio operativo, ma non specifica le proprietà necessarie affinché tali registrazioni possano essere prodotte come evidenze in procedimenti ispettivi o giudiziari. Si noti che il §5.6.5 “Documentare i dati, i modelli e le richieste” già menziona «gli hash e/o le firme crittografiche» (pag. 103) tra le informazioni da includere nella documentazione, ma tale indicazione resta confinata alla documentazione tecnica e non è estesa ai log operativi e di sicurezza. Si chiede che le Linee Guida prescrivano, per i log del §5.7.3, caratteristiche di integrità forense — catena di custodia digitale, non alterabilità, marcatura temporale opponibile — coerentemente con i requisiti della Direttiva NIS2 (art. 21 e art. 23 sugli obblighi di notifica) e con l’art. 15 dell’AI Act sulla robustezza e sicurezza. Un log modificabile dall’operatore non costituisce un’evidenza forense.
La sezione sulla sicurezza risulta complessivamente ben impostata, ma non copre adeguatamente le minacce specifiche dei sistemi basati su Large Language Model. In particolare, non viene fatto riferimento all’OWASP LLM Top 10, che rappresenta oggi lo standard di riferimento internazionale per la sicurezza dei sistemi GenAI. L’assenza di tali riferimenti espone le amministrazioni a rischi concreti, tra cui prompt injection, divulgazione di dati sensibili e abuso delle capacità agentiche dei modelli. Si propone quindi di integrare la sezione con un richiamo esplicito a tale framework, introducendo controlli obbligatori e test specifici in fase di collaudo e aggiornamento. Inoltre, si segnala la necessità di rafforzare i requisiti relativi alla supply chain dei modelli (model card, SBOM IA) e di rendere obbligatorio l’utilizzo di audit trail immutabili con retention definita, al fine di garantire tracciabilità e accountability.
Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.