2 ‒ Riferimenti e sigle

Bozza di linee guida per il procurement di IA nella Pubblica Amministrazione

La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.

Questo argomento accoglie i commenti relativi al capitolo 2. Riferimenti e sigle.

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).

Leggi il documento in consultazione.

Capitolo 2 “Riferimenti e sigle”: assenza di una sottosezione dedicata ai riferimenti tecnico-metodologici sulla sicurezza dei sistemi di IA

Citazione: §2.2 “Riferimenti normativi”, §2.3 “Linee guida di riferimento”, §2.4 “Definizioni e acronimi”.

Il Capitolo 2 del documento procurement organizza i riferimenti principalmente in termini di atti normativi, linee guida e definizioni. Tuttavia, non prevede una sottosezione dedicata ai riferimenti tecnico-metodologici internazionali sulla sicurezza dei sistemi di IA, pur trattandosi di un corpus oggi ampiamente riconosciuto e necessario per dare contenuto operativo a nozioni come gestione del rischio cyber, tassonomie di attacco, testing avversariale e verifica della robustezza. La lacuna è particolarmente evidente se si considera che il capitolo 3 entra già nel merito della cybersicurezza per il procurement, fino a richiamare nel §3.6.2 una tassonomia di attacco NIST, ma senza che tali riferimenti siano raccolti e dichiarati in modo sistematico nel quadro iniziale dei riferimenti.

L’effetto è duplice. Da un lato, le Amministrazioni che intendano tradurre i requisiti di sicurezza in clausole verificabili non dispongono di un elenco esplicito e unitario di framework a cui ancorarsi. Dall’altro, contenuti tecnicamente sensibili, come il testing avversariale e il red-teaming dei sistemi di IA, restano privi di un ancoraggio metodologico formale nel capitolo dedicato al procurement, pur essendo oggetto di documenti pubblici riconosciuti e ampiamente utilizzati. Questo punto è particolarmente rilevante rispetto ai commenti proposti ai §3.6.3 e §3.7 sul red-teaming (vedi thread appositi), perché senza riferimenti tecnico-metodologici dichiarati il rischio è che tali obblighi restino formulati in modo dichiarativo e non facilmente traducibili in requisiti tecnici esigibili.

Raccomandazione: integrare il Capitolo 2 con una sottosezione autonoma, ad esempio un nuovo §2.3-bis “Riferimenti tecnico-metodologici internazionali sulla sicurezza dei sistemi di IA”, oppure, in alternativa, con un rinvio espresso al corrispondente quadro tecnico-metodologico del corpus AgID, così da raccogliere in forma strutturata i principali documenti di riferimento a cui il capitolo 3 possa rinviare in modo sintetico. Tale sottosezione dovrebbe includere almeno:

(a) NIST AI Risk Management Framework 1.0 e relativo Generative AI Profile (NIST AI 600-1), per il quadro generale di gestione del rischio dei sistemi di IA, con particolare riferimento ai sistemi generativi;

(b) NIST AI 100-2 “Adversarial Machine Learning - A Taxonomy and Terminology of Attacks and Mitigations”, come tassonomia di riferimento degli attacchi avversari, già implicitamente richiamata nel corpo delle Linee guida al §3.6.2, senza però essere consolidata nel quadro dei riferimenti del Capitolo 2;

(c) MITRE ATLAS, come knowledge base delle tattiche e tecniche avversarie verso i sistemi di IA;

(d) OWASP Top 10 for Large Language Model Applications e OWASP GenAI Red Teaming Guide, come riferimenti metodologici riconosciuti per la sicurezza delle applicazioni basate su LLM e per la conduzione strutturata di attività di red-teaming sui sistemi di IA generativa;

(e) ENISA “Artificial Intelligence Cybersecurity Challenges” ed ENISA “Multilayer Framework for Good Cybersecurity Practices for AI”, come riferimenti europei sulla sicurezza dei sistemi di IA.

L’inclusione di tali riferimenti nel Capitolo 2 consentirebbe al capitolo 3 di rinviarvi in forma sintetica, senza ripetere citazioni estese, e fornirebbe alle Amministrazioni un insieme dichiarato di documenti su cui ancorare i requisiti tecnici di sicurezza, inclusi quelli relativi al testing avversariale e al red-teaming dei sistemi di IA.

Il Comitato Scientifico dell’Osservatorio sull’Intelligenza Artificiale nelle Pubbliche Amministrazioni presenta le seguenti osservazioni:

  1. Par. 2.1 Struttura del documento; Rendere più operativo il richiamo agli Strumenti: “Gli Strumenti includono almeno: checklist di avvio, matrice rischio-adempimenti, capitolato-tipo modulare, questionario-tipo per il sourçage, clausole-tipo su dati/log/portabilità e piano di uscita, nonché schemi semplificati e rafforzati in funzione del rischio.”
  2. Par. 2.1 Struttura del documento; Prevedere assistenza centralizzata e una repository di buone pratiche a supporto delle amministrazioni: “Gli Strumenti e le misure di supporto alle Linee guida possono includere, oltre alla documentazione operativa, forme di assistenza centralizzata, servizi di accompagnamento per le amministrazioni, una repository di buone pratiche, casi d’uso, e soluzioni riutilizzabili, al fine di ridurre le asimmetrie applicative e favorire un’attuazione omogenea sul territorio.”

La sezione 2 delle Linee Guida non annovera tra i riferimenti normativi il Regolamento (UE) 2017/745 (MDR) né il Regolamento (UE) 2017/746 (IVDR). I sistemi di intelligenza artificiale con finalità medicali (ad es. diagnosi, prevenzione di malattie o di supporto decisionale clinico) possono contestualmente qualificarsi come dispositivi medici o dispositivi medico-diagnostici in vitro ai sensi dei rispettivi regolamenti. In tali fattispecie, l’art. 6(1) del Regolamento (UE) 2024/1689 (AI Act) determina l’applicazione cumulativa dei due framework normativi, con obblighi aggiuntivi in materia di valutazione della conformità, documentazione tecnica e sorveglianza post-market.

Un’amministrazione pubblica che orientasse le proprie attività di procurement o sviluppo di sistemi di IA in ambito clinico potrebbe non avere piena consapevolezza del quadro regolatorio complessivamente applicabile, con conseguente rischio di non conformità e potenziale esposizione a responsabilità in caso di eventi avversi a danno del paziente.

Proposte:

  1. Inserire il Reg. (UE) 2017/745 (MDR) e il Reg. (UE) 2017/746 (IVDR) tra i riferimenti normativi della sezione 2, corredandoli di una nota esplicativa che evidenzi la loro rilevanza per i sistemi di IA destinati a finalità medicali e la necessità di verificare, caso per caso, se il sistema ricada nel relativo perimetro di applicazione.

  2. Introdurre un capitolo dedicato ai sistemi di IA con finalità medicali utilizzati all’interno del Sistema Sanitario Nazionale o prevedere un documento apposito per questi sistemi che hanno impatti clinici diretti o indiretti sul paziente, in maniera tale da affrontare in modo organico le responsabilità del fabbricante e del deployer pubblico.

Si evidenzia la necessità di ampliare e aggiornare la sezione relativa ai riferimenti e alle sigle, includendo esplicitamente i principali framework tecnici e di sicurezza rilevanti per i sistemi di Intelligenza Artificiale, in particolare quelli basati su modelli generativi. In assenza di tali riferimenti, le amministrazioni rischiano di operare senza un quadro metodologico condiviso, con conseguenti disallineamenti nelle gare e nei controlli. Si propone quindi di integrare la sezione con riferimenti a standard internazionali quali NIST AI Risk Management Framework, NIST SP 800-207 (Zero Trust), OWASP LLM Top 10 per la sicurezza dei modelli generativi, nonché standard emergenti relativi alla supply chain dei modelli (model card, SBOM IA). Tale aggiornamento consentirebbe di rendere le Linee Guida più aderenti allo stato dell’arte tecnologico e di fornire alle PA un set minimo di riferimenti operativi condivisi e verificabili.

Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.