La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 1. Ambito di applicazione.
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).
Al paragrafo 1.3.4 il collegamento associato al Linee Guida | Agid è errato.
Il capitolo definisce l’ambito soggettivo e oggettivo delle Linee Guida, includendo l’insieme delle Pubbliche Amministrazioni e tutte le componenti dei sistemi di Intelligenza Artificiale. Questa impostazione garantisce coerenza e completezza del perimetro di applicazione. Tuttavia, proprio tale ampiezza rischia di risultare eccessivamente generalista, in quanto non tiene adeguatamente conto delle profonde differenze esistenti tra le diverse tipologie di amministrazioni.
In particolare, non emerge una distinzione esplicita tra amministrazioni centrali e amministrazioni locali, né tra enti caratterizzati da differenti livelli di maturità digitale, capacità organizzativa e dotazione tecnologica. Questo aspetto può comportare un’applicazione non omogenea delle Linee Guida, con il rischio che i requisiti risultino troppo complessi per le realtà meno strutturate o, al contrario, poco sfidanti per le amministrazioni più avanzate.
In tale prospettiva, ritengo opportuno che venga valutata l’introduzione di una classificazione delle amministrazioni basata su livelli di maturità (ad esempio: base, intermedio, avanzato), al fine di modulare obblighi e requisiti in modo proporzionato. Una simile articolazione consentirebbe di rendere le Linee Guida più efficaci e concretamente applicabili, differenziando le indicazioni in funzione della dimensione dell’ente, delle competenze disponibili e del grado di evoluzione digitale.
in principio 1, par. 2, aggiungere: Legge n. 132/2025 (“Disposizioni e deleghe al Governo in materia di intelligenza artificiale”)
marieva favoino - in rappresentanza del Forum per il Governo Aperto e Fondazione Italia Digitale
Le Linee Guida sviluppo IA nella PA qui proposte parlano di trasparenza, qualità del dato, sicurezza, ma non collegano questi elementi alla tutela dei diritti fondamentali, che è l’architrave dell’intero impianto europeo sull’IA. A mio avviso questo collegamento è essenziale per giustificare verifiche su bias, supervisione umana, audit etici e di equità, requisiti su dataset non discriminatori.
Nel paragrafo introduttivo o nel capitolo “Ambito e finalità”, aggiungerei:
“Le presenti Linee Guida si collocano nel quadro europeo volto a garantire l’uso dell’IA rispettoso dei diritti fondamentali, della non discriminazione e dell’inclusione sociale”.
marieva favoino - Forum Governo Aperto e FID
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino) segnala che tra i riferimenti normativi non si rinviene alcun richiamo del New Legislative Framework (NLF), che influisce sui livelli di rischio, quadro legislativo che mira a migliorare il mercato interno dei prodotti e a rafforzare le condizioni per l’immissione sul mercato dell’UE di un’ampia gamma di prodotti. Si tratta di un insieme di misure volte a migliorare la sorveglianza del mercato e a incrementare la qualità delle valutazioni di conformità. Chiarisce inoltre l’utilizzo della marcatura CE e crea una serie di strumenti da impiegare nella legislazione sui prodotti. (cfr. https://single-market-economy.ec.europa.eu/single-market/goods/new-legislative-framework_en )
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino) segnala che tra i riferimenti normativi non si rinviene alcun richiamo all’art 4 dello Statuto dei lavoratori**,** che assume particolare rilevanza perché se l’analisi predittiva (sez. 3.2) viene applicata ai flussi di lavoro senza un accordo sindacale o autorizzazione dell’Ispettorato del Lavoro, si può configurare una violazione diretta del divieto di controllo a distanza dei lavoratori.
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino), segnala la mancanza di protocolli per la minimizzazione del dato nelle fasi di testing e validazione. Si suggerisce di imporre la separazione fisica e logica tra dati di training e dati operativi, privilegiando dati sintetici o anonimizzati per il fine-tuning.
Contributo a cura dell’Avv. Marco Cappa - Counsel, Practice Digital, ADVANT Nctm Studio Legale
Ringrazio AgID per l’opportunità offerta dalla consultazione e condivido l’obiettivo complessivo di rendere governabili, sostenibili e trasparenti i sistemi di Intelligenza Artificiale (IA) lungo il loro intero ciclo di vita nella Pubblica Amministrazione ¶. Apprezzo in particolare l’enfasi su architetture modulari, disaccoppiamento dei componenti, neutralità hardware e capacità di rollback: elementi che presiedono in modo adeguato alla continuità operativa e all’autonomia tecnologica delle amministrazioni.
Occorre tuttavia segnalare alcune criticità sistematiche che rischiano di compromettere l’efficacia pratica del documento rispetto alle applicazioni di IA da parte delle PA. L’uso pervasivo di prescrizioni formulate come “DEVE/DEVONO”, ove interpretato in modo estensivo e uniforme, rischia di trasformare le Linee Guida in un corpus di adempimenti eccessivamente gravoso anche per casi d’uso a basso impatto e ridotta complessità. Non si tratta di una questione di principio o di formalismi, bensì di proporzionalità applicativa ed effettiva.
Il punto diventa particolarmente critico in relazione al regime di classificazione del rischio. In assenza di strumenti operativi di triage chiari e agili per la classificazione iniziale, sussiste il rischio concreto che la valutazione venga estesa in via cautelativa oltre il necessario, generando oneri documentali e procedurali aggiuntivi anche laddove ciò non sarebbe oggettivamente richiesto. Senza una guida semplificata, la classificazione diventa essa stessa un adempimento oneroso, ancor prima di giungere alle misure di compliance sostanziale.
Lo stesso documento riconosce che la maggioranza delle amministrazioni opererà come “Operatore base”, con controllo limitato sullo stack tecnologico e ricorso prevalente a soluzioni as-a-service. Imporre indistintamente oneri concepiti per livelli di maturità più elevati – fino all’“Operatore controllore” – rischia di produrre effetti controintuitivi: un freno all’adozione, lo spostamento di risorse verso una compliance meramente formale e l’esclusione di fatto delle PA meno strutturate.
Suggerisco pertanto di rafforzare, in modo ancora più esplicito, un criterio di proporzionalità articolato per livelli – rischio, contesto d’uso e maturità dell’amministrazione – con particolare riguardo agli obblighi di trasparenza, spiegabilità e documentazione. Analogamente, logging e auditabilità sono obiettivi pienamente condivisibili, ma occorrerebbe definire un contenuto minimo modulare, incrementalmente estendibile, evitando che l’obbligo di log “strutturati e verificabili” si traduca in un requisito uniforme e oneroso indipendentemente dalla tipologia di sistema.
Infine, la spinta verso la neutralità hardware e la portabilità è strategicamente corretta – e giustamente orientata a prevenire situazioni di lock-in – ma va accompagnata da indicazioni applicative che consentano compromessi ragionevoli in termini di performance e costi, senza che il principio hardware-agnostic si trasformi in un vincolo assoluto difficilmente rispettabile. Le stesse Linee Guida riconoscono che tecniche di ottimizzazione possono abilitare l’esecuzione su CPU, riducendo costi energetici e operativi: è opportuno valorizzare questo aspetto come leva di semplificazione, anziché come ulteriore livello prescrittivo.
Una seconda criticità, di carattere definitorio, merita attenzione: la nozione di “dato sensibile” utilizzata nelle Linee Guida non appare allineata alla tassonomia adottata dall’Agenzia per la Cybersicurezza Nazionale (ACN), che distingue tra dati ordinari, critici e strategici secondo criteri legati all’impatto sulla sicurezza nazionale e alla rilevanza sistemica. L’impiego di una categoria autonoma, non raccordata con tale classificazione, rischia di generare disallineamenti applicativi significativi, soprattutto per le amministrazioni che devono già orientarsi nel quadro della Strategia Cloud Italia e dei requisiti ACN per la qualificazione dei servizi cloud. Sarebbe pertanto opportuno armonizzare le definizioni adottate nelle Linee Guida con la tassonomia ACN o, quantomeno, introdurre un esplicito raccordo tra i due sistemi classificatori, al fine di garantire coerenza e certezza operativa.
Una criticità di particolare rilievo riguarda le previsioni in materia di neutralità hardware e portabilità. La direzione strategica è corretta e condivisibile: prevenire situazioni di dipendenza tecnologica costituisce un obiettivo legittimo. Tuttavia, nella formulazione attuale, tali previsioni rischiano concretamente di escludere dalla disponibilità delle PA tutte le soluzioni di intelligenza artificiale ottimizzate sullo stack tecnologico di un Cloud Service Provider, senza alcuna gradualità né una previa valutazione proporzionata dell’effettivo rischio di lock-in nel caso concreto. Un principio hardware-agnostic applicato in modo indifferenziato può di fatto precludere l’accesso a soluzioni che, proprio grazie all’integrazione nativa con l’infrastruttura del fornitore, offrono livelli significativamente superiori di performance, affidabilità e sicurezza. L’esito sarebbe paradossale: nella misura in cui l’obiettivo delle Linee Guida è favorire l’adozione responsabile dell’IA nella PA, escludere a priori intere categorie di soluzioni ottimizzate – in assenza di una reale analisi del rischio di dipendenza – condurrebbe in direzione opposta. Sarebbe preferibile introdurre un meccanismo di valutazione proporzionata del lock-in, modulato in funzione della criticità del sistema, della sostituibilità della soluzione e della reversibilità dei dati, consentendo alle amministrazioni di accedere anche a soluzioni cloud-native o CSP-ottimizzate laddove il bilanciamento costi-benefici lo giustifichi.
In sintesi, il perimetro è corretto e la direzione condivisibile. Occorre però che l’attuazione resti realmente proporzionata – in linea con l’approccio assunto negli ultimi mesi dal legislatore europeo con il Digital Omnibus – per non trasformare la governance dell’IA in un onere classificatorio e burocratico che, paradossalmente, rallenti proprio quell’adozione responsabile di soluzioni utili che le Linee Guida si propongono di promuovere.
§1.2 Ambito oggettivo
Il §1.2 definisce l’ambito come insieme di componenti applicative e infrastrutturali, ma non richiama espressamente i principali data plane dei sistemi di IA moderni, quali corpora e indici RAG, vector store ed embedding, pipeline di training e fine-tuning, log di prompt, output e interazioni, nonché pipeline di analytics sui dati conversazionali. Poiché tali elementi sono poi effettivamente trattati in altre parti del documento e negli Strumenti, sarebbe utile ricomprenderli in modo esplicito già nell’ambito oggettivo iniziale, così da evitare ambiguità sul loro inquadramento come asset da governare e proteggere.
Raccomandazione: includere espressamente nell’ambito oggettivo anche i data plane associati ai sistemi di IA, in particolare vector store ed embedding, corpora RAG, pipeline di training e fine-tuning, logging dei prompt e degli output, sistemi di monitoring e analytics correlati.
§1.2 Ambito oggettivo, secondo capoverso
Il §1.2 definisce l’ambito oggettivo in termini ampi e uniformi, senza richiamare sin dall’apertura un criterio di proporzionalità basato sul livello di autonomia, sull’uso di tool e sul perimetro d’azione effettivamente raggiungibile dal sistema. Questa precisazione è opportuna perché il documento, nei capitoli successivi, distingue già architetture agentiche, livelli di autonomia, orchestratore e tool, inclusi casi in cui i tool possono invocare API, eseguire codice o orchestrare flussi operativi.
Raccomandazione: integrare il §1.2 precisando che, ai fini della sicurezza, i requisiti devono essere commisurati almeno al livello di autonomia operativa del sistema, alla capacità di interagire con sistemi esterni, alla presenza di tool o funzioni invocabili dal modello e all’integrazione di componenti di terze parti, quali modelli di fondazione, API esterne o basi di conoscenza collegate tramite orchestrazione.
§1.3.3 Riferimenti normativi
Il quadro iniziale dei riferimenti è solido sul piano normativo, ma non include una sezione dedicata ai principali riferimenti tecnici e metodologici internazionali richiamati o comunque coerenti con il contenuto del documento. Ciò produce una discontinuità interna, perché nel capitolo 5 sono già richiamati MITRE ATLAS, ENISA AI Cybersecurity Challenges e il NIST AI Risk Management Framework, senza che tali riferimenti compaiano nel quadro iniziale del capitolo 1. Inoltre, alcuni standard ISO/IEC rilevanti per la gestione del rischio e dei sistemi di IA compaiono già nello Strumento A, ma non sono valorizzati nel quadro introduttivo generale.
Raccomandazione: mantenere il §1.3.3 come sezione dei riferimenti normativi e aggiungere una distinta sezione dedicata ai “Riferimenti tecnici e metodologici”, includendo almeno i riferimenti già richiamati nel testo, quali NIST AI RMF, NIST AI 100-2, MITRE ATLAS ed ENISA AI Cybersecurity Challenges, nonché standard e framework coerenti con l’impostazione del documento, quali ISO/IEC 42001, ISO/IEC 23894, ENISA Multilayer Framework for Good Cybersecurity Practices for AI e i principali riferimenti OWASP per la sicurezza delle applicazioni basate su LLM e ML.