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.
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.
Rilevo 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.
Ritengo 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.