La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 2. Come sviluppare sistemi di Intelligenza Artificiale.
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).
Continua la discussione da 2 - Come sviluppare sistemi di Intelligenza Artificiale:
In relazione ai contenuti della bozza, e in particolare ai capitoli 2 “Come sviluppare sistemi di Intelligenza Artificiale”, 3 “Architettura logica di riferimento: orchestratore, modelli, dati e tool”, 4 “Ciclo di vita dei sistemi di Intelligenza Artificiale”, 5 “Sicurezza cibernetica” e 6 “Neutralità hardware, acceleratori e portabilità dei sistemi di IA”, si propone di valorizzare in modo più esplicito, nel documento, il ruolo delle architetture locali, modulari e basate su software libero come modello di particolare interesse per la Pubblica Amministrazione.
Una soluzione di questo tipo, basata ad esempio su server Ubuntu LTS, su LLM locali leggeri, su applicazioni sviluppate in Python e distribuite tramite Flask, con integrazione con strumenti open source come LibreOffice, rappresenta una modalità concreta di sviluppo di sistemi di IA coerente con molti dei principi richiamati nella bozza. In particolare, tale impostazione risponde bene ai temi della trasparenza, della qualità dei processi, della centralità dell’uomo, della cybersicurezza, della resilienza, dell’accessibilità universale, della portabilità e della riduzione del lock-in tecnologico.
Sotto il profilo del ruolo del dato, sarebbe utile evidenziare con maggiore forza il valore delle soluzioni nelle quali i dati restano in
teramente all’interno dell’infrastruttura dell’amministrazione oppure in ambienti comunque pienamente governati dall’ente. Questo approccio offre vantaggi rilevanti in termini di privacy, protezione delle informazioni, controllo sul trattamento, riduzione dell’esposizione verso servizi esterni e maggiore coerenza con i principi di responsabilità pubblica nella gestione del patrimonio informativo. Per molte amministrazioni, la possibilità di sviluppare sistemi di IA senza dover trasferire dati, documenti o contenuti operativi su piattaforme esterne costituisce un elemento di forte valore strategico.
In relazione al tema della classificazione dei ruoli e dei livelli di autonomia delle Pubbliche Amministrazioni, si ritiene inoltre utile sottolineare che architetture di questo tipo favoriscono una maggiore autonomia di sviluppo, configurazione e governo tecnico. L’uso di componenti aperti e modulari consente infatti all’amministrazione di adattare progressivamente la soluzione ai propri bisogni, di sostituire singoli moduli, di integrare nuovi tool e di mantenere nel tempo la possibilità di evolvere il sistema senza dipendere in modo rigido da un singolo fornitore o da un unico ecosistema proprietario.
Un ulteriore aspetto meritevole di valorizzazione riguarda la sostenibilità economica. L’impiego di software libero, di prodotti gratuiti o comunque privi di abbonamenti ricorrenti obbligatori, e di modelli leggeri in grado di funzionare anche su infrastrutture meno onerose, può aiutare concretamente la PA a contenere i costi iniziali e soprattutto a ridurre il rischio di rincari futuri, di modifiche unilaterali delle condizioni di licenza o di spese crescenti legate all’utilizzo di servizi di mercato. Questo punto appare strettamente connesso non solo al tema della economicità, ma anche a quello della continuità operativa, della portabilità e della reversibilità delle soluzioni adottate.
In relazione al capitolo dedicato alla neutralità hardware, agli acceleratori e alla portabilità, appare particolarmente utile richiamare anche il valore di modelli ottimizzati per il funzionamento su CPU o comunque in ambienti non altamente specializzati, così da rendere l’adozione più sostenibile per un numero maggiore di amministrazioni. L’utilizzo di LLM locali leggeri consente infatti di conciliare innovazione e contenimento dei consumi, rafforzando anche il collegamento con il livello energetico richiamato nella bozza.
Particolarmente rilevante appare poi l’integrazione di questi sistemi con strumenti documentali open source e di largo utilizzo, come LibreOffice. In tale contesto, un sistema di IA locale non si limiterebbe a svolgere la funzione di chatbot, ma potrebbe diventare un ambiente flessibile di supporto operativo, capace di assistere la redazione dei documenti, generare contenuti su richiesta, supportare attività ripetitive, utilizzare dati forniti direttamente dall’utente, interagire con modelli documentali e contribuire alla standardizzazione dei flussi interni.
Questo punto assume un valore ancora maggiore se collegato al principio di accessibilità universale e inclusione. L’integrazione con LibreOffice e con strumenti di automazione come macro e script Python può consentire di predisporre modelli accessibili di default, di effettuare controlli automatici su struttura e leggibilità dei documenti e di migliorare complessivamente la qualità dei contenuti amministrativi prodotti. In questo senso, l’IA non sarebbe solo uno strumento di produttività, ma anche una leva concreta per favorire documenti più accessibili, più uniformi e più aderenti agli standard qualitativi richiesti.
Sempre in quest’ottica, si ritiene utile che il documento richiami con maggiore evidenza il tema del riuso. Soluzioni costruite con componenti aperti, modulari e ampiamente diffusi possono essere più facilmente riutilizzate, adattate e replicate in altre amministrazioni, favorendo economie di scala, circolazione delle buone pratiche e sviluppo progressivo di un patrimonio applicativo comune. La valorizzazione del riuso del software e, ove possibile, dell’integrazione con basi informative e open data, può rendere queste architetture ancora più coerenti con la logica di interoperabilità e con il perseguimento del valore pubblico.
Sotto il profilo della sicurezza cibernetica, infine, appare importante evidenziare che una soluzione locale, costruita su infrastrutture controllate, componenti documentabili e software verificabile, può agevolare una gestione più consapevole del rischio lungo il ciclo di vita del sistema. La possibilità di documentare i modelli, i dati, le richieste, i tool integrati e i processi applicativi rafforza infatti la capacità dell’amministrazione di presidiare gli aspetti di sicurezza, manutenzione e monitoraggio.
Si propone quindi di rafforzare nel documento il riferimento a soluzioni locali, open source, modulari, accessibili, economiche e riusabili, capaci di mantenere i dati all’interno, aumentare l’autonomia di sviluppo della Pubblica Amministrazione, ridurre il rischio di dipendenza economica e tecnologica dal mercato e offrire un modello di innovazione più sostenibile, replicabile e coerente con i principi generali delle linee guida.
Versione sintetica riassuntiva
Si propone di valorizzare maggiormente, nelle Linee guida, il ruolo delle architetture locali, modulari e basate su software libero per lo sviluppo di sistemi di IA nella PA. Soluzioni costruite su server Ubuntu LTS, LLM locali leggeri, applicazioni in Python/Flask e integrazione con strumenti open source come LibreOffice consentono di mantenere i dati interamente all’interno dell’amministrazione, rafforzando privacy, sicurezza, controllo del trattamento e autonomia tecnologica.
Tale modello appare coerente con i principi di trasparenza, qualità dei processi, centralità dell’uomo, accessibilità, resilienza, portabilità e riduzione del lock-in. Inoltre, l’uso di componenti gratuiti o non basati su abbonamenti ricorrenti riduce il rischio di rincari futuri, cambi di licenza e dipendenza da soluzioni di mercato troppo costose, migliorando la sostenibilità economica nel tempo.
L’integrazione con LibreOffice, macro e script Python può rendere questi sistemi strumenti concreti per la redazione assistita, il controllo dei documenti, la predisposizione di modelli accessibili, il riuso del software e l’utilizzo di dati locali o open data. Si tratta quindi di un modello flessibile e replicabile, che merita maggiore evidenza nel documento come opzione concreta per una IA pubblica più governabile, sostenibile e orientata al valore pubblico.
Contributo a cura della Taskforce IA dell’Autorità Nazionale Anticorruzione (ANAC)
Emergono alcune criticità che potrebbero incidere sull’effettiva applicabilità dei principi delineati. In primo luogo, si rileva un’eccessiva prescrittività, evidenziata dall’uso sistematico di formulazioni vincolanti quali “DEVE” e “DEVONO”. Sebbene tale scelta sia coerente con l’impostazione normativa del documento, in diversi casi i requisiti risultano difficilmente sostenibili per tutte le amministrazioni, in particolare per quelle con minore maturità tecnologica e organizzativa.
Un ulteriore elemento di criticità riguarda la mancanza di una chiara prioritizzazione dei principi. I venti principi individuati vengono presentati con lo stesso livello di rilevanza, senza distinguere tra requisiti fondamentali e indicazioni più avanzate. L’assenza di una gerarchia rende più complesso per le amministrazioni comprendere su quali aspetti concentrare prioritariamente gli sforzi, soprattutto nelle fasi iniziali di adozione.
Evidenziamo inoltre un forte orientamento verso modelli architetturali avanzati, in particolare verso architetture agentiche e sistemi caratterizzati da orchestrazione complessa. Pur trattandosi di approcci tecnologicamente evoluti e coerenti con le tendenze più recenti, essi non risultano sempre applicabili nei contesti operativi di tutte le Pubbliche Amministrazioni e rischiano di introdurre livelli di complessità non necessari in molte situazioni d’uso.
Alla luce di tali considerazioni, suggeriamo di articolare i principi secondo diversi livelli di applicabilità, distinguendo ad esempio tra principi minimi obbligatori, principi raccomandati e principi avanzati. Ciò consentirebbe di rendere il quadro più flessibile e progressivo, facilitando l’adozione anche da parte delle amministrazioni meno strutturate.
Suggeriamo inoltre di integrare il capitolo con esempi concreti di applicazione dei principi, riferiti a casi d’uso differenziati, come ad esempio soluzioni semplici (quali chatbot informativi) e sistemi più complessi (quali strumenti di supporto alle decisioni). Infine, si ritiene opportuno ridurre il bias verso specifici modelli architetturali, mantenendo un approccio tecnologicamente neutrale che consenta alle amministrazioni di adottare soluzioni proporzionate alle proprie esigenze e capacità.
Concordo con Claudio Biancalana su tutti i punti. In particolare sui molti DEVE/DEVONO che prescindono dalla classificazione dei sistemi prevista dall’AI Act.
Prendendo, ad esempio, il principio P.6, ovviamente condivisibile, è noto come studi recenti dimostrino che la maggior parte degli LLM comunemente in uso siano addestrati secondo modelli di linguaggio di ambienti cosiddetti WEIRD (Western, Educated, Industrialized,Rich,Democratic) non sempre adatti a ambiti culturali diversi (per i giapponesi, ad esempio, molti di questi modelli sono poco ossequiosi).
L’adozione di questi modelli potrebbe dunque risultare discriminatorio, ecco perché un DOVREBBE, con le dovute raccomandazioni, sarebbe più opportuno di un DEVE.
Lo stesso principio potrebbe essere attuato ai principi P.7 e P.8, ben sapendo che la spiegabilità non può essere sempre garantita, né si comprende perché dovrebbe esserlo in assoluto. Non potrebbe dipendere dal contesto? Classificazione del sistema e modello di processo e controllo (ad esempio, sistema a basso impatto e modello Man In the Loop) potrebbero essere sufficienti a garantire una corretta applicazione dello strumento rispettosa di tanti altri principi, seppur non completamente “spiegabile”.
Continuando l’analisi, ritengo che anche il principio P.11 debba essere rimodulato con DOVREBBERO anziché DEVONO, lasciando le considerazioni sul “livello di robustezza” adeguato alla responsabilità dell’Amministrazione, come avviene per ogni altro sistema in uso. Perché i sistemi basati su AI dovrebbe essere più robusti degli altri?
P.15, P16, P.17, P.19 e P.20 dovrebbero essere impostati con la stessa logica di accountability in capo all’Amministrazione e, pertanto, con i dovuti DOVREBBE/DOVREBBERO al posto dei DEVE/DEVONO.
Sul P.18 ho dei dubbi sulla correlazione tra sostenibilità ambientale e le architetture agentiche. Anche qui, comunque, l’uso del condizionale del verbo modale potrebbe essere più opportuna.
Grazie, osservazioni condivisibili. Il punto che volevo evidenziare, però, è che per la PA le architetture locali, modulari e open source meritano maggiore attenzione.
Oggi molte soluzioni di IA esterne cambiano continuamente nei modelli, nei costi e nelle condizioni d’uso, con margini di controllo limitati. Una soluzione locale, invece, una volta configurata e governata internamente, offre maggiore stabilità, controllo sui dati, prevedibilità economica e minore dipendenza dal fornitore.
Grazie, osservazione utile. Condivido il tema della proporzionalità e il fatto che molti principi vadano applicati in relazione al contesto, al livello di rischio e al tipo di sistema.
Il punto che volevo evidenziare, però, è che proprio questa variabilità rende ancora più importante, per la PA, poter disporre di soluzioni locali e governabili. Un modello generale può certamente avere limiti culturali o impostazioni di partenza non sempre adatte a ogni contesto; tuttavia, se viene eseguito in locale e configurato con script, regole di risposta, dati propri e controlli definiti dall’amministrazione, il suo comportamento diventa molto più controllabile, coerente e aderente alle esigenze operative.
In questo senso, non sostengo che il modello di base diventi perfetto, ma che un’architettura locale, modulare e open source consenta alla PA di ridurre la dipendenza da sistemi esterni che cambiano continuamente, di mantenere maggiore stabilità nel tempo e di esercitare un controllo più concreto su dati, costi, configurazioni e processi. Proprio per questo ritengo che queste soluzioni meritino una valorizzazione più esplicita nelle Linee guida.
La presente osservazione è da leggersi nel contesto complessivo, argomentato nel position paper che provvedo a trasmettervi anche via PEC.
L’architettura giuridica delle Linee Guida AgID poggia su due pilastri: l’AI Act europeo (classificazione per rischio, obblighi per i sistemi ad alto rischio) e la Legge italiana 132/2025, che pone al centro l’intervento umano e la protezione della dignità della persona. L’articolo 3 di quest’ultima impone, in ogni fase del ciclo di vita dell’IA, sorveglianza e intervento umano, trasparenza e spiegabilità, principi già recepiti nel Principio 13 delle Linee Guida Sviluppo.
Una criticità dell’attuale impianto è la declinazione del controllo umano come mero monitoraggio a valle (Human-in-the-loop), modello fragile per il rischio di automation bias (fiducia eccessiva nell’algoritmo). Per superare questo limite, è necessario adottare il paradigma Human-in-Command (HIC), in cui l’umano non si limita a correggere output, ma mantiene il controllo strategico sul sistema, definendone a monte obiettivi, vincoli e regole etico-logiche. Questo approccio è coerente con il Regolamento (UE) 2024/1689, che per i sistemi ad alto rischio richiede un controllo effettivo da parte di persone fisiche durante l’uso.
Riferimenti AgID:
Linee Guida Sviluppo: Cap. 2 (Principi generali), Principio 13 – Sorveglianza umana
Linee Guida Procurement: Par. 3.1 (Principi generali), Tabella 1 (Principio di controllo)
Criticità rilevata:
Il quadro attuale declina il controllo umano prevalentemente in ottica reattiva (Human-in-the-loop): l’operatore supervisiona output, corregge errori, interviene a valle. Questo modello, pur necessario, non è sufficiente per i sistemi ad alto impatto procedimentale. Esso rischia di ridurre l’umano a “controllore di bozze” in contesti in cui le derive sistemiche possono manifestarsi solo dopo iterazioni massive.
Proposta:
Si suggerisce di integrare nel Principio 13 (Sorveglianza umana) in Tabella 1 (pag. 24-25) e nel Par. 3.5.4 (Operatore controllore), accanto al concetto di supervisione, quello di progettazione costituzionale del sistema, riconoscendo la figura dell’Architetto Cognitivo come ruolo istituzionale (cfr. Operatore controllore in Sviluppo, Par. 3.5.4).
Tale figura:
Definisce a monte i guardrail etico-logici (Costituzioni degli Agenti) entro cui i modelli operano;
Non valida output caso per caso, ma ricalibra il sistema in caso di derive strutturali;
Garantisce che la responsabilità decisionale rimanga in capo alla PA (Principio 5 – Responsabilità).
Testo integrato nel para 2.2, integrare nel Principio 13 – Sorveglianza umana (pag 20), e in Tabella (pag.25), come segue :
"Secondo il principio di sorveglianza umana, le PA garantiscono un adeguato livello di supervisione umana dei sistemi di IA, assicurando la possibilità di verifica, correzione o sostituzione delle decisioni automatizzate (cfr. art. 14 AI Act). Per i sistemi classificati ad alto rischio o che incidono su procedimenti amministrativi sensibili, la PA deve assicurarsi di operare secondo un paradigma Human-in-Command.
In fase di sviluppo, i sistemi DEVONO consentire un intervento umano effettivo, tempestivo e
documentabile, anche a livello di orchestrazione dei servizi e degli agenti di IA. Lo sviluppo DEVE inoltre prevedere punti di controllo, modalità di override e meccanismi di arresto o riconfigurazione del sistema. L’operatore pubblico non si limita a supervisionare output, ma progetta a monte le regole costituzionali del sistema (Costituzioni degli Agenti). La figura dell’Architetto Cognitivo interviene sull’architettura e sui pesi del modello in caso di derive sistemiche, preservando la piena titolarità delle decisioni amministrative.
Il procurement DEVE escludere soluzioni che impediscano il controllo umano sostanziale o che rendano l’intervento umano solo formale. I contratti DEVONO garantire accesso operativo agli strumenti di supervisione, senza dipendenze esclusive dal fornitore. Per i sistemi ad alto rischio, le procedure di gara devono valorizzare soluzioni che implementino il paradigma Human-in-Command, prevedendo: i) la definizione contrattuale delle ‘Costituzioni degli Agenti’ (guardrail etico-logici progettati a monte); ii) la possibilità per la PA di ricalibrare il sistema in caso di derive sistemiche; iii) il trasferimento di competenze per la formazione della figura dell’Architetto Cognitivo all’interno dell’amministrazione."
Commenti per le Linee guida sullo sviluppo
1. Rafforzare il passaggio dai principi alle prescrizioni operative.
La bozza sullo sviluppo è molto ricca sul piano dei principi e delle architetture di riferimento, e ha il merito di affrontare esplicitamente stack tecnologico, orchestratore, modelli, dati, tool, ciclo di vita e sicurezza. Sarebbe però utile tradurre alcuni principi in requisiti operativi minimi ancora più concreti, soprattutto nelle sezioni dedicate a pianificazione, testing, monitoraggio e ritiro/disattivazione, così da aiutare le PA meno mature a passare dal quadro concettuale all’implementazione effettiva.
2. Molto utile il collegamento tra sviluppo e procurement, ma andrebbe reso ancora più immediato.
È un punto di forza della bozza il fatto che essa espliciti la correlazione tra adozione, sviluppo e procurement e che assuma il ciclo di vita come riferimento comune. Si potrebbe però rendere ancora più fruibile questo raccordo con una tabella sintetica iniziale che, per ogni fase del ciclo di vita, distingua chiaramente quali obblighi gravano sullo sviluppo e quali sul procurement. Questo aiuterebbe la lettura operativa da parte delle amministrazioni.
3. Molto positiva l’attenzione a portabilità, reversibilità e separazione tra dati, modelli e servizi.
La previsione secondo cui lo sviluppo deve garantire una netta separazione tra dati, modelli e servizi è particolarmente condivisibile, perché costituisce una base tecnica importante per ridurre il lock-in e preservare il controllo pubblico. Sarebbe utile esplicitare meglio, anche con esempi pratici o checklist tecniche, come questa separazione debba essere verificata in progetti reali, specie nei casi di sistemi basati su componenti eterogenei, modelli esterni o architetture agentiche.
4. Opportuno valorizzare maggiormente i casi d’uso RAG e i sistemi composti.
Il fatto che il documento richiami, tra gli strumenti, training, validazione, fine-tuning e RAG è molto utile. Tuttavia, considerato che molte future applicazioni pubbliche saranno sistemi composti, basati su orchestratore, modelli, basi documentali e tool, sarebbe opportuno dedicare maggiore spazio ai requisiti minimi di qualità documentale, versionamento delle fonti, tracciabilità del retrieval, governance degli indici e distinzione tra errore del modello ed errore del sistema di recupero della conoscenza.
5. Bene la parte sulla documentazione, ma sarebbe utile precisarne il contenuto minimo.
La bozza afferma correttamente che dati, modelli, input e richieste devono essere documentati lungo il ciclo di vita e che la documentazione deve includere origine dei dati, limiti del sistema, hash o firme, conservazione dei dati e modalità note di errore. Sarebbe utile rendere questo punto ancora più forte indicando un set minimo standard di artefatti documentali che la PA dovrebbe sempre possedere o richiedere: data sheet, model card, logiche di orchestrazione, changelog, registro incidenti, policy di aggiornamento e piano di dismissione.
6. Molto buona la sezione di cybersicurezza, ma sarebbe utile un raccordo più diretto con le capacità interne della PA.
La bozza dedica giustamente ampio spazio a sicurezza, threat modeling, analisi del codice, deployment sicuro, manutenzione e buone pratiche. Un possibile rafforzamento potrebbe consistere nell’esplicitare meglio quali competenze minime interne la PA debba possedere per poter realmente governare questi obblighi, evitando che le prescrizioni restino difficili da esercitare in assenza di un presidio tecnico-organizzativo adeguato.
7. Apprezzabile il riferimento a neutralità hardware e fallback CPU, da rendere più centrale.
La presenza di un intero capitolo su neutralità hardware, portabilità e fallback CPU è molto interessante e innovativa. Proprio per questo varrebbe la pena rafforzarne il rilievo nel testo principale, chiarendo che non si tratta di un tema meramente infrastrutturale, ma di una leva di autonomia strategica, continuità operativa e riduzione del rischio di dipendenza tecnologica.
8. Da correggere alcuni aspetti redazionali e formali.
Anche nella bozza sullo sviluppo compare il rinvio agli “Strumenti” con link ancora da definire. Inoltre, il testo potrebbe beneficiare di una revisione finale di uniformazione redazionale e terminologica, così da aumentarne l’autorevolezza e l’immediata usabilità nella consultazione pubblica
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino)suggerisce l’adozione delle seguenti buone pratiche per la PA:
1. Sanificazione continua dei Dataset: Implementazione di pipeline di validazione per prevenire l’iniezione di dati malevoli.
2. Stress Testing di Accuratezza: Verifiche periodiche per misurare il degrado delle prestazioni in condizioni avverse.
3. Segregazione degli Agenti: Nelle architetture orchestrate, ogni agente software deve operare secondo il principio del minor privilegio.
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino) suggerisce di prevedere le seguenti Action Items ad Alto Impatto:
Emanazione di una Matrice di Responsabilità (RACI): Definire uno schema standardizzato che ripartisca i compiti tra “Fornitore” (sviluppo/manutenzione) e “Utilizzatore” (gestione operativa), allineandolo ai ruoli previsti dall’AI Act per eliminare incertezze legali.
Template Standardizzato del Technical File: Produrre un modello di documentazione tecnica conforme agli allegati dell’AI Act, per facilitare le PA negli oneri di trasparenza e nelle attività di audit.
Mandato di Efficienza Energetica e Fallback: Inserire nei capitolati d’appalto KPI vincolanti sulla sostenibilità (Energy Layer) e l’obbligo tecnico di procedure di fallback su CPU, per garantire la resilienza nazionale di fronte a crisi di mercato o tecnologiche.
§2.1 Principi generali per lo sviluppo di sistemi di Intelligenza Artificiale
Il §2.1 individua nelle architetture agentiche e a servizi, supportate da un orchestratore, l’opzione architetturale da privilegiare per lo sviluppo dei sistemi di IA nella Pubblica Amministrazione. Questa impostazione è coerente con l’obiettivo di modularità, governabilità e sostituibilità dei componenti, ma non è accompagnata, nello stesso paragrafo, da un richiamo esplicito al corrispondente impatto in termini di sicurezza. Nelle architetture agentiche, infatti, il perimetro di rischio non dipende solo dal modello, ma anche dall’insieme di tool, connettori, basi dati e sistemi esterni che il modello può raggiungere tramite orchestrazione. In architetture non adeguatamente mediate o segregate, contenuti non fidati provenienti da prompt, documenti, e-mail, pagine web o basi di conoscenza collegate possono influenzare il comportamento del sistema e propagarsi verso azioni operative o accessi a risorse sensibili.
Raccomandazione: integrare il §2.1 chiarendo che l’adozione di architetture agentiche comporta un’espansione del perimetro di sicurezza proporzionale al numero, al tipo e alla criticità dei tool, dei connettori e delle fonti dati accessibili al modello, e che tale espansione deve essere accompagnata da misure specifiche, quali mediazione dell’invocazione dei tool, allow-list esplicite, approvazioni rafforzate per le azioni sensibili e separazione tra input non fidati e capability privilegiate, con rinvio al capitolo dedicato alla cybersicurezza.
§2.2, Principio 11. Robustezza
Il Principio 11 utilizza il termine “robustezza” in un’accezione prevalentemente coincidente con la continuità operativa e la resilienza infrastrutturale, richiamando architetture modulari, degradazione graduale del servizio, fallback e riallocazione dinamica dei componenti. Nel contesto dei sistemi di IA, tuttavia, la robustezza ha una portata più ampia, coerente anche con il richiamo all’art. 15 AI Act, e include la capacità del sistema di resistere a tentativi di manipolazione, a perturbazioni intenzionali degli input e ad altre forme di attacco che incidono sul comportamento del modello. La formulazione attuale rischia quindi di essere interpretata, nei capitolati e nelle verifiche, come un requisito riferito soprattutto alla disponibilità del servizio, lasciando in secondo piano la robustezza avversariale.
Raccomandazione: distinguere esplicitamente nel Principio 11 due componenti della robustezza:
(a) robustezza operativa, relativa a continuità del servizio, fallback, degradazione controllata e resilienza infrastrutturale;
(b) robustezza avversariale, intesa come capacità del sistema di resistere ad attacchi e manipolazioni quali, almeno, data poisoning, model poisoning, adversarial examples e, per i sistemi generativi e agentici, prompt injection e manipolazione del contesto. Entrambe le componenti dovrebbero essere oggetto di metriche, test e monitoraggio.
§2.2, Principio 12. Sicurezza cibernetica
Il Principio 12 formula la sicurezza cibernetica dei sistemi di IA in termini corretti ma ancora molto generali, richiamando controllo degli accessi, segregazione dei ruoli, protezione delle pipeline di dati, gestione degli incidenti e isolamento dei componenti compromessi. Per i sistemi di IA, in particolare quelli generativi, agentici o con componenti RAG, mancano però nel principio tre elementi che renderebbero il requisito più specifico e verificabile.
Primo, manca un richiamo esplicito alla necessità di separare gli input non fidati dalle capability ad alto privilegio. Nei sistemi di IA il rischio non dipende solo dall’identità dell’utente o dal ruolo applicativo, ma anche dal livello di fiducia dei contenuti che entrano nel contesto del modello. Per questo, i componenti che elaborano input non fidati non dovrebbero poter guidare direttamente azioni sensibili o accedere senza mediazione a strumenti e sistemi privilegiati.
Secondo, manca un riferimento esplicito al testing avversariale continuo e al red-teaming dei modelli e dei sistemi di IA come attività ricorrenti lungo il ciclo di vita, non limitate al collaudo iniziale ma da ripetere a ogni modifica significativa di modelli, prompt, tool, dati o connettori.
Terzo, il principio non richiama nemmeno a titolo esemplificativo le principali categorie di attacco specifiche dei sistemi di IA, già sviluppate nel capitolo 5, quali evasion, poisoning, prompt injection, attacchi alla riservatezza e abuso dei sistemi generativi. In assenza di tale richiamo, il principio rischia di restare troppo astratto per essere tradotto in requisiti tecnici verificabili.
Raccomandazione: integrare il Principio 12 chiarendo che la sicurezza cibernetica dei sistemi di IA comprende anche:
(a) la separazione architetturale tra componenti che elaborano input non fidati e capability o sistemi ad alto privilegio;
(b) il testing avversariale continuo e il red-teaming dei modelli e dei sistemi di IA come parte della regressione di sicurezza lungo il ciclo di vita;
(c) il riferimento, almeno esemplificativo, alle principali categorie di attacco AI-specifiche, con rinvio alle tassonomie e ai framework tecnici già richiamati nel capitolo 5.
§2.2, Principio 14. Registrazioni (logging)
Il Principio 14 tratta correttamente i log come strumento di tracciabilità, audit, accountability e portabilità, ma non ne riconosce in modo esplicito la natura di asset sensibili nei sistemi di IA. Nei sistemi generativi e conversazionali, infatti, i log di prompt, output, interazioni tra agenti e pipeline di analytics possono contenere con elevata frequenza dati personali, informazioni riservate, segreti operativi o porzioni di documenti interni richiamati tramite basi di conoscenza e meccanismi di retrieval. Per questa ragione, tali log non sono solo un presidio difensivo, ma costituiscono essi stessi un potenziale vettore di esposizione o esfiltrazione, al pari di altri archivi applicativi.
Raccomandazione: integrare il Principio 14 precisando che i log di prompt, output, interazioni e le pipeline di analytics correlate devono essere trattati come asset sensibili ai fini della sicurezza e della protezione dei dati, con requisiti espliciti di minimizzazione, redazione dei dati personali, retention limitata, segregazione rispetto ai dati operativi e disciplina contrattuale espressa per ogni eventuale riuso da parte del fornitore a fini di training, fine-tuning o miglioramento del servizio, subordinato ad autorizzazione esplicita dell’Amministrazione.
§2.3.6 Principio 6. Cybersicurezza e resilienza lungo il ciclo di vita
Il §2.3.6, dedicato al Principio 6 della Legge 132/2025 sulla cybersicurezza e resilienza lungo il ciclo di vita, è formulato in modo molto sintetico e ad un livello di astrazione elevato. La previsione che i sistemi debbano essere resilienti ad attacchi e manipolazioni e che debbano essere condotti test di sicurezza lungo l’intero ciclo di vita è certamente condivisibile, ma, così come formulata, non offre elementi sufficientemente operativi per distinguere il contesto dei sistemi di IA da quello di altri sistemi informativi. La sintesi del paragrafo risulta inoltre sproporzionata rispetto alla rilevanza del tema e rispetto al maggiore dettaglio che il documento sviluppa successivamente nel capitolo 5.
Raccomandazione: espandere il §2.3.6, oppure almeno integrarlo con un rinvio esplicito ai contenuti del capitolo 5, chiarendo nel contesto specifico dei sistemi di IA:
(a) quali categorie di attacchi AI-specifici devono essere considerate, almeno a titolo esemplificativo, quali prompt injection diretta e indiretta, evasion, poisoning, attacchi alla riservatezza e abuso dei sistemi generativi;
(b) che cosa si intenda per test di sicurezza lungo il ciclo di vita nel dominio IA, con riferimento al testing avversariale ricorrente, alle suite di regressione di sicurezza e alla ripetizione dei test a ogni modifica significativa di modelli, prompt, dati, tool o connettori.
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 1 — Trasparenza algoritmica nelle decisioni che incidono sul rapporto di lavoro (sez. 2.3.1 e 2.3.3)
I principi di trasparenza e spiegabilità sono declinati esclusivamente in relazione ai cittadini-utenti. Non è considerato il caso — già tecnicamente in atto in alcune amministrazioni — in cui il sistema di IA supporta decisioni che riguardano i dipendenti stessi: assegnazione di carichi di lavoro, distribuzione delle pratiche, valutazione della performance, selezione per progressioni economiche, rilevazione di anomalie comportamentali a fini disciplinari.
L’art. 86 del Regolamento (UE) 2024/1689 riconosce il diritto alla spiegazione delle singole decisioni per le persone fisiche soggette a sistemi di IA ad alto rischio, inclusi quelli di gestione delle risorse umane (Allegato III, punto 4). L’art. 1-bis del D.Lgs. 152/1997 (inserito dal D.Lgs. 104/2022) impone specifici obblighi informativi sui sistemi decisionali automatizzati che incidono sulla gestione del rapporto di lavoro. Nessuno dei due è richiamato nelle Linee Guida.
Proposta di integrazione alla sez. 2.3.3:
Aggiungere un paragrafo sulla trasparenza algoritmica nei confronti del personale:
– Per le decisioni amministrative che incidono sul rapporto di lavoro (assegnazione di mansioni, distribuzione dei carichi, valutazione della performance, procedimenti disciplinari) adottate con il supporto di sistemi di IA, la pubblica amministrazione DEVE: (i) informare il dipendente dell’utilizzo del sistema e del peso attribuito al suo output nella decisione; (ii) garantire il diritto del dipendente a richiedere revisione umana della decisione (art. 22 GDPR; art. 86 Reg. UE 2024/1689); (iii) documentare in forma scritta la motivazione, distinguendo la componente algoritmica da quella umana.
– I sistemi di IA di cui all’Allegato III, punto 4, del Reg. (UE) 2024/1689 DEVONO essere sottoposti a valutazione di impatto ex art. 9 del medesimo Regolamento.
– La pubblica amministrazione DEVE condurre un audit periodico dei pregiudizi discriminatori (genere, età, disabilità, anzianità di servizio) nei sistemi di IA usati per decisioni sul personale, con documentazione agli atti e coinvolgimento delle organizzazioni sindacali.
OSSERVAZIONE 2 — Accessibilità degli strumenti di IA ad uso interno del personale (sez. 2.3.7)
Il Principio 7 richiama i requisiti di accessibilità esclusivamente nella prospettiva dei cittadini-utenti. Non vi è alcun riferimento all’accessibilità degli strumenti di IA ad uso interno del personale. Nel Comparto Funzioni Centrali una quota significativa dei dipendenti è titolare di tutele ai sensi della L. 104/1992: per questi lavoratori, strumenti non accessibili producono discriminazione indiretta e ostacoli concreti alla progressione di carriera. La L. 4/2004 (Legge Stanca) e le Linee Guida AgID sull’accessibilità si applicano a tutti gli strumenti informatici della PA, compresi quelli ad uso interno.
Proposta di integrazione alla sez. 2.3.7:
– I sistemi di IA ad uso interno del personale DEVONO rispettare i requisiti della L. 4/2004 e delle Linee Guida AgID sull’accessibilità, indipendentemente dal fatto che siano destinati ai cittadini o ai dipendenti.
– In fase di test (sez. 4.4), la pubblica amministrazione DEVE effettuare verifica di accessibilità degli strumenti di IA ad uso interno, coinvolgendo almeno un esperto di accessibilità.
– In caso di impossibilità tecnica, la pubblica amministrazione DEVE predisporre alternative equivalenti per i dipendenti con disabilità, documentando le misure di accomodamento ragionevole ai sensi della L. 104/1992 e del D.Lgs. 216/2003.
Confintesa FP — Segretario Generale Claudia Ratti | www.confintesafp.it
Segnaliamo le nostre proposte,
cordialmente
Paragrafo 2.2
È bene rimarcare che se i principi di sviluppo non fossero allineati con quelli del procurement si rischierebbe di frammentare la governance. La PA potrebbe acquistare soluzioni “chiuse” che rendono impossibile rispettare i requisiti di trasparenza e monitoraggio richiesti nella fase di sviluppo. Il disallineamento non è solo informativo, ma architetturale. Un acquisto che non prevede l’interoperabilità dei dati rende vano ogni principio di sviluppo agile o incrementale previsto dalle linee guida AgID. La correlazione richiede che chi sviluppa verifichi costantemente la coerenza con le linee guida di adozione. Per una PA, l’onere di verifica può significare l’istituzione di processi di audit incrociato che aumentano significativamente la complessità burocratica.
Principi generali
Si suggerisce l’introduzione di un principio trasversale dedicato “Comunicazione, fiducia e accountability pubblica”, finalizzato a:
Nello specifico:
Principi 7 e 8 - I principi di trasparenza e informazione risultano declinati prevalentemente in chiave tecnica. Si suggerisce di integrare con un esplicito riferimento alla trasparenza comunicativa, intesa come capacità di rendere comprensibili ai cittadini:
In particolare:
Principio 3 – Gestione del rischio: si propone di precisare meglio il seguente passaggio “Secondo il principio di gestione del rischio, le PA adottano adeguate politiche di gestione del rischio conducendo un’analisi approfondita dei rischi associati all’impiego di sistemi di IA.” in quanto l’analisi del rischio riveste un aspetto cruciale e quindi può essere opportuno collegarla a fonti
Proposta: Secondo il principio di gestione del rischio di cui gli standard di AI governance (ISO/IEC 42001, ISO/IEC 23894, EU AI Act) le PA adottano adeguate politiche di gestione del rischio conducendo un’analisi approfondita dei rischi associati all’impiego di sistemi di IA
Principio 7 – Trasparenza, spiegabilità e documentazione - si propone specificare che l’accesso deve essere garantito anche successivamente alla cessazione del contratto, per il periodo necessario a continuità operativa, verifica e audit.
Principio 8 - Trasparenza e informazione - può essere opportuno distinguere (i) informazione all’utente finale; (ii) trasparenza amministrativa/documentale interna per evitare confusione tra obblighi comunicativi e auditabilità.
Principio 9 – Qualità dei dati - si propone di precisare meglio il seguente passaggio: “Secondo il principio di qualità dei dati,” con il seguente “Secondo il principio di qualità dei dati ISO/IEC 5259 (2024–2025)”
Principio 10 – Accuratezza- si propone di aggiungere degli esempi di metriche coerenti col caso d’uso (precision/recall/F1, MAE/MSE, top-k, tasso allucinazioni, ecc.) al fine di rendere il principio misurabile e verificabile.
Principio 11 – Robustezza - si propone di modificare “In fase di sviluppo i sistemi DEVONO essere progettati con architetture modulari, resilienti e degradabili, in grado di mantenere livelli di servizio proporzionati anche in condizioni non ottimali.” con “In fase di sviluppo i sistemi DEVONO essere progettati con architetture architetture resilienti e capaci di degradazione controllata del servizio, in grado di mantenere livelli di servizio proporzionati anche in condizioni non ottimali” per una migliore delimitazione tecnica e conseguente riduzione dell’ambiguità.
Principio 15 – Adozione di standard tecnici - si propone di precisare meglio il seguente passaggio: “Lo sviluppo DEVE basarsi su standard aperti e riconosciuti a livello UE e internazionale” con il seguente “Lo sviluppo DEVE basarsi su standard aperti conformi all’AI Act”
Principio 18 – Sostenibilità ambientale - secondo il principio di sostenibilità ambientale, le PA adottano sistemi di IA secondo un approccio sostenibile, attento alla tutela ambientale e coerente con i principi di sostenibilità energetica. [La PA, come grande acquirente di tecnologia, ha il potere di orientare il mercato, imponendo criteri di sostenibilità nelle gare d’appalto, spingendo le aziende fornitrici a innovare in chiave “green”. Il richiamo a modelli proporzionati è un invito a non usare sempre la tecnologia più complessa ed energivora se una soluzione più snella può raggiungere lo stesso scopo.]
Principio 18 - Sostenibilità ambientale- si propone di precisare meglio il seguente passaggio: “Il procurement, inoltre, DEVE favorire soluzioni che dimostrino misurabilità e riduzione dell’impatto ambientale nel tempo.” con il seguente “Il procurement, inoltre, DEVE favorire soluzioni che certifichino DNSH o che abbiano la certificazione ESG”.
Principio 19 – Formazione e sviluppo delle competenze - secondo il principio di formazione e sviluppo delle competenze, le PA investono nella formazione del proprio personale e promuovono iniziative di alfabetizzazione digitale per cittadini e imprese, al fine di garantire un’adozione dell’IA consapevole, inclusiva e responsabile, [anche dal punto di vista della sostenibilità ambientale.]
Paragrafo 2.4 - Pag. 30
Nella classificazione:
Contributo a cura di Dedalus Italia S.p.A.
Sulla base delle progettualità sviluppate da Dedalus in ambito sanitario e nella PA, emerge l’importanza di adottare pratiche di sviluppo dei sistemi di Intelligenza Artificiale orientate al dominio applicativo e basate sul rischio. In particolare, l’utilizzo di architetture agentiche e di orchestratori consente di integrare modelli differenti, mantenendo una netta separazione tra dati, modelli e logica applicativa. Tale approccio favorisce la conformità normativa (AI Act, GDPR), la governabilità del sistema e l’evoluzione controllata delle soluzioni nel tempo.
Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione
Accountability algoritmica e diritti dei cittadini nel procedimento amministrativo digitale
Spiegabilità, trasparenza, equità algoritmica, supervisione umana, governance interna, gestione degli incidenti
Indice delle proposte
| Riferimento | Oggetto della proposta | Posizione nel documento |
|---|---|---|
| PARTE 0 | Premessa e perimetro del contributo | — |
| PARTE 1 — LACUNE STRUTTURALI (argomenti assenti) | ||
| Proposta 1.1 | Responsabilità della PA verso il cittadino | § 2.2 Principio 5 + nuovo Principio 5-bis |
| Proposta 1.2 | Spiegabilità verso il cittadino | § 2.2 Principio 7 + § 4.5 |
| Proposta 1.3 | Diritto di contestazione e ricorso | Nuovo Principio 5-ter + § 4.6 |
| Proposta 1.4 | Registro pubblico degli algoritmi | Nuovo § 2.5 + Strumento C |
| Proposta 1.5 | Responsabile dei sistemi di IA (RSIA) | Nuovo § 2.6 |
| Proposta 1.6 | FRIA, processo strutturato | Nuovo § 2.7 + § 4.1 + Strumento D |
| Proposta 1.7 | Gestione incidenti con impatto sui diritti | Nuovo § 2.8 + § 4.6 + § 5.7.3 |
| Proposta 1.8 | Documentazione pubblica dei modelli (Model Card) | § 3.1.4 + § 5.6.5 + Strumento C |
| PARTE 2 — LACUNE PER INSUFFICIENZA (argomenti incompleti) | ||
| Proposta 2.1 | Spiegabilità, metodologia, metriche, differenziazione per famiglia di sistema | § 2.2 P.7 + § 4.4 + § 3.1.4 |
| Proposta 2.3 | Responsabilità in architetture multi-fornitore e sistemi as-a-service | § 2.2 P.5 + § 3.5.1 + § 4.1 |
| Proposta 2.4 | Logging, contenuto minimo, retention, accesso, tensione GDPR | § 2.2 P.14 + § 4.6 + § 5.7.3 |
| Proposta 2.5 | Test su bias, definizione, metodologie, metriche, monitoring, pubblicazione | § 2.2 P.6 + §§ 3.4.1, 4.4, 4.6 |
| Proposta 2.6 | Sorveglianza umana, livelli minimi, effettività, competenze, escalation | § 2.2 P.13 + §§ 3.2, 4.5 |
| Proposta 2.7 | Gestione incidenti, tassonomia, soglie, framework notifiche integrato | § 2.8 + §§ 4.6, 5.7.3 |
| PARTE 3 | Riferimenti normativi e tecnici del contributo | — |
0.1 Natura del contributo
Il presente documento costituisce un contributo tecnico-giuridico alla consultazione pubblica sulla Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione, pubblicata da AgID ai sensi del D.P.C.M. 12 gennaio 2024.
Il contributo ha natura costruttiva. Riconosce il valore del documento posto in consultazione, in particolare la solidità dell’impostazione architetturale, la coerenza del raccordo con l’AI Act e la profondità del capitolo sulla sicurezza cibernetica, e propone integrazioni specifiche nelle aree in cui il testo presenta lacune strutturali o sviluppo insufficiente rispetto al quadro normativo vigente.
Ogni proposta è corredata da: riferimento puntuale al testo esistente; identificazione della lacuna specifica; ancoraggio normativo alle fonti cogenti o di standard tecnico riconosciuto; testo pronto all’inserimento nel registro linguistico del documento originale.
0.2 Area tematica
Il contributo si concentra sull’area dell’accountability algoritmica e dei diritti dei cittadini nel procedimento amministrativo digitale. Questa area comprende:
la responsabilità della PA verso i soggetti interessati dalle decisioni adottate o supportate da sistemi di IA;
il diritto dei cittadini a ricevere una spiegazione comprensibile e a contestare le decisioni algoritmiche;
la trasparenza pubblica sull’uso di sistemi di IA nei procedimenti amministrativi;
la governance interna della PA per i sistemi di IA;
le metodologie di valutazione dell’equità algoritmica;
la gestione degli incidenti con impatto sui diritti dei cittadini.
La scelta di concentrare il contributo su questa area risponde alla constatazione che il documento posto in consultazione è tecnicamente solido ma sistematicamente orientato alla dimensione interna della PA (architettura, sicurezza, governance tecnologica), trascurando la dimensione esterna, ovvero il rapporto tra il sistema di IA e il cittadino che ne subisce gli effetti.
0.3 Metodo
Il contributo è stato sviluppato secondo la seguente sequenza metodologica:
Mappatura puntuale delle lacune, con riferimento al paragrafo e alla citazione testuale del documento originale;
Classificazione delle lacune in strutturali (argomenti assenti) e per insufficienza (argomenti presenti ma non sviluppati);
Ancoraggio normativo per ciascuna lacuna, con indicazione della fonte, della disposizione specifica e del tipo di obbligo;
Redazione degli statement integrativi nel registro linguistico del documento originale (DEVE / DEVONO / DOVREBBE / PUÒ).
0.4 Priorità delle proposte
| Priorità | Criterio | Proposte |
|---|---|---|
| ALTA | Obblighi direttamente cogenti derivanti da AI Act, GDPR o L. 241/90, non recepiti nel testo | 1.1, 1.2, 1.3, 1.6, 1.7, 2.4 |
| MEDIA | Best practice consolidate e obblighi cogenti nazionali sistematicamente ignorati | 1.4, 1.5, 2.1, 2.5, 2.6, 2.7 |
| INTEGRATIVA | Strumenti operativi che completano senza modificare la struttura del documento | 1.8, 2.3 |
Le seguenti proposte riguardano argomenti completamente assenti nel documento, che richiedono l’introduzione di nuove sezioni, paragrafi o strumenti operativi.
Proposta 1.1 — Responsabilità della PA verso il cittadino
Mappatura della lacuna
Il Principio 5 (§ 2.2) declina la responsabilità come requisito tecnico interno al sistema. La dimensione esterna, ovvero gli obblighi della PA verso il soggetto interessato dalla decisione, è completamente assente. Mancano: il soggetto responsabile nominativamente identificato all’interno della PA; la procedura attraverso cui la responsabilità è esercitabile dal cittadino; la distinzione tra responsabilità per progettazione, per deployment e per singola decisione.
Ancoraggio normativo
| Fonte | Disposizione | Contenuto rilevante | Tipo |
|---|---|---|---|
| AI Act | Art. 26 c.1 | Il deployer garantisce supervisione umana, usa il sistema secondo le istruzioni, monitora il funzionamento | Cogente dal 2/8/2026 |
| AI Act | Art. 86 | Diritto a spiegazione per decisioni individuali significative adottate con sistemi ad alto rischio | Cogente |
| GDPR | Art. 22 c.3 | Obbligo di garantire intervento umano, diritto di esprimere opinione, di contestare la decisione | Cogente |
| L. 241/90 | Art. 3, 10-bis | Obbligo di motivazione del provvedimento; preavviso di rigetto | Cogente nazionale |
| Cons. Stato | Sent. 2270/2019 | Principi di conoscibilità, comprensibilità e non esclusività dell’algoritmo | Giurisprudenza vincolante |
Testo proposto
PROPOSTA P5-INT — Integrazione Principio 5, colonna Sviluppo
Posizione nel documento: § 2.2, Principio 5, colonna Sviluppo
Per ogni sistema di IA che produce effetti giuridici o incide in modo significativo su persone fisiche, la PA DEVE individuare e designare formalmente un responsabile del sistema, distinto dal responsabile tecnico del progetto, con funzioni di supervisione sull’uso del sistema, verifica della correttezza delle decisioni prodotte o supportate dallo stesso, e punto di contatto verso i soggetti interessati.
Il responsabile del sistema DEVE essere identificato nella documentazione pubblica del sistema medesimo e deve essere raggiungibile dagli interessati attraverso canali istituzionali.
Le PA DEVONO documentare, per ogni sistema che produce decisioni o raccomandazioni con effetti sui cittadini, la catena di responsabilità dalla progettazione all’uso operativo, specificando per ciascuna fase il soggetto responsabile, interno o esterno all’amministrazione.
PROPOSTA 1.1 — Principio 5-bis: Responsabilità esterna e tutela del soggetto interessato
Posizione nel documento: § 2.2, dopo il Principio 5
La responsabilità della PA verso il soggetto interessato dalla decisione adottata o supportata da un sistema di IA costituisce un obbligo autonomo rispetto ai requisiti tecnici di progettazione del sistema.
Le PA DEVONO garantire che ogni soggetto persona fisica destinatario di una decisione amministrativa adottata con il supporto o mediante l’uso di un sistema di IA:
sia informato del fatto che la decisione è stata adottata con il supporto di un sistema di IA, con indicazione della sua natura e finalità;
riceva, su richiesta, una spiegazione comprensibile dei fattori che hanno influito sulla decisione;
possa esercitare il diritto di contestazione e ottenere la revisione della decisione da parte di un soggetto umano competente;
sia informato delle modalità per esercitare tali diritti.
Le PA NON DEVONO adottare decisioni che producono effetti giuridici negativi su persone fisiche basandosi esclusivamente sull’output di un sistema di IA, senza che sia garantita una valutazione umana effettiva e documentabile.
Proposta 1.2 — Spiegabilità verso il cittadino
Mappatura della lacuna
Il Principio 7 tratta la spiegabilità esclusivamente come requisito tecnico-architetturale e strumento di audit interno. Sono assenti: il diritto soggettivo del cittadino a ricevere una spiegazione comprensibile; i requisiti minimi di contenuto; la distinzione tra spiegabilità tecnica (per auditor) e spiegabilità intelligibile (per il cittadino); i formati e le tempistiche.
Ancoraggio normativo
| Fonte | Disposizione | Contenuto rilevante | Tipo |
|---|---|---|---|
| AI Act | Art. 13 + Art. 86 | Trasparenza verso gli utenti; diritto a spiegazione per decisioni individuali significative | Cogente |
| GDPR | Art. 22 c.3 | Informazioni significative sulla logica utilizzata e sulle conseguenze previste | Cogente |
| L. 241/90 | Art. 3 | La motivazione deve rendere comprensibili le ragioni della decisione, applicabile alla componente algoritmica | Cogente nazionale |
| IEEE 7001-2021 | Standard | Requisiti di comprensibilità per diversi stakeholder (operatori, utenti, pubblico) | Standard tecnico |
Testo proposto
PROPOSTA 1.2 — Integrazione Principio 7: Spiegabilità intelligibile
Posizione nel documento: § 2.2, Principio 7, colonna Sviluppo
I sistemi DEVONO essere sviluppati con meccanismi di spiegabilità proporzionati al rischio e al contesto d’uso, distinguendo tra:
Spiegabilità tecnica: destinata agli auditor, ai responsabili del sistema e alle autorità di controllo, che DEVE rendere accessibile la logica del modello, i pesi dei fattori, le metriche di performance e le limitazioni note del sistema.
Spiegabilità intelligibile: destinata al soggetto interessato dalla decisione, che DEVE essere espressa in linguaggio non tecnico, indicare i principali fattori che hanno influito sulla decisione specifica, la loro direzione e, ove tecnicamente possibile, il loro peso relativo, nonché le informazioni o i dati che hanno prodotto l’esito.
I sistemi DEVONO essere progettati in modo da consentire la generazione della spiegabilità intelligibile in forma contestuale alla decisione, senza richiedere l’intervento manuale del personale tecnico per ogni singolo caso.
Per i sistemi classificati ad alto rischio ai sensi dell’AI Act, la spiegabilità intelligibile verso il soggetto interessato NON DEVE essere considerata opzionale, ma costituisce requisito obbligatorio di progettazione.
Proposta 1.3 — Diritto di contestazione e ricorso
Mappatura della lacuna
Il tema è completamente assente nel documento. La sorveglianza umana (P.13) è trattata come requisito tecnico del sistema, non come diritto del cittadino. Il raccordo con la L. 241/90 e con la giurisprudenza del Consiglio di Stato (sent. 2270/2019) è inesistente.
Ancoraggio normativo
| Fonte | Disposizione | Contenuto rilevante | Tipo |
|---|---|---|---|
| AI Act | Art. 86 | Diritto a revisione umana; il deployer deve informare su come esercitarlo | Cogente |
| GDPR | Art. 22 c.3 | Diritto di contestare la decisione automatizzata e ottenere intervento umano | Cogente |
| L. 241/90 | Art. 7, 10, 10-bis | Diritto di partecipazione, memorie e documenti; preavviso di rigetto | Cogente nazionale |
| Cons. Stato | Sent. 2270/2019 | Il ricorrente ha diritto a conoscere il meccanismo algoritmico e sindacarne la correttezza in giudizio | Giurisprudenza vincolante |
Testo proposto
PROPOSTA 1.3 — Principio 5-ter: Diritto di contestazione e revisione umana
Posizione nel documento: § 2.2, dopo il Principio 5-bis
Le PA DEVONO garantire che ogni soggetto destinatario di una decisione adottata o significativamente supportata da un sistema di IA abbia il diritto di:
richiedere la revisione della decisione da parte di un soggetto umano competente, che DEVE effettuare una valutazione autonoma e non limitarsi alla verifica formale dell’output del sistema;
presentare osservazioni, memorie e documenti utili alla revisione, secondo quanto previsto dagli artt. 7 e 10 della L. 241/90;
ottenere un provvedimento motivato che dia conto dell’esito della revisione e del peso attribuito alla componente algoritmica nella decisione finale.
Le PA NON DEVONO configurare la revisione umana come mero adempimento formale. La valutazione umana DEVE essere effettiva, documentata e indipendente dall’output del sistema oggetto di contestazione.
Nei procedimenti che si concludono con un atto di diniego, rigetto o limitazione di diritti, le PA DEVONO dare attuazione al preavviso di rigetto di cui all’art. 10-bis della L. 241/90 anche quando la proposta di diniego è generata o supportata da un sistema di IA.
Le PA DEVONO rendere pubbliche e facilmente accessibili le procedure per l’esercizio del diritto di contestazione, con indicazione dei termini, del soggetto competente e delle modalità di presentazione delle osservazioni.
I sistemi di IA DEVONO essere progettati in modo da consentire tecnicamente la revisione della singola decisione, rendendo accessibili al soggetto umano incaricato della revisione i dati di input, i fattori rilevanti e la logica applicata dal sistema nel caso specifico.
Proposta 1.4 — Registro pubblico degli algoritmi
Mappatura della lacuna
Nessuna disposizione prevede che la PA renda pubblico l’uso di sistemi di IA nei propri procedimenti. La documentazione è trattata esclusivamente come requisito interno (§ 5.6.5) senza mai aprire una dimensione pubblica. Mancano: l’obbligo di notifica pubblica dell’adozione di un sistema di IA; il contenuto minimo della scheda algoritmo; il formato e il canale di pubblicazione; la frequenza di aggiornamento.
Ancoraggio normativo
| Fonte | Disposizione | Tipo |
|---|---|---|
| AI Act | Art. 49 — Registrazione sistemi ad alto rischio nella banca dati UE | Cogente |
| AI Act | Art. 50 — Obblighi di trasparenza per sistemi che interagiscono con persone fisiche | Cogente |
| D.Lgs. 33/2013 | Art. 1, 29 — Principio di trasparenza e obblighi di pubblicazione | Cogente nazionale |
| L. 132/2025 | Art. 3 c.1 — Principio di trasparenza | Cogente nazionale |
| Loi République numérique (FR) | Art. 4, 2016 — Obbligo di pubblicare le regole algoritmiche usate nelle decisioni individuali | Modello comparato |
Testo proposto
PROPOSTA 1.4 — Nuovo § 2.5: Registro pubblico degli algoritmi
Posizione nel documento: Nuovo § 2.5, dopo i principi generali
Le PA DEVONO tenere e mantenere aggiornato un registro dei sistemi di IA in uso che producono effetti su persone fisiche o che incidono su procedimenti amministrativi. Il registro costituisce adempimento degli obblighi di trasparenza di cui al D.Lgs. 33/2013 e degli obblighi di informazione verso gli utenti di cui agli artt. 13 e 50 del Regolamento (UE) 2024/1689 (AI Act).
Il registro DEVE essere pubblicato nella sezione “Amministrazione Trasparente” del sito istituzionale della PA e DEVE essere accessibile senza necessità di autenticazione.
Per ogni sistema di IA iscritto nel registro, la PA DEVE pubblicare una scheda contenente almeno le seguenti informazioni:
denominazione, versione e finalità del sistema;
ambito di utilizzo nel procedimento amministrativo e livello di rischio attribuito ai sensi dell’AI Act;
indicazione se il sistema adotta decisioni in modo autonomo, le supporta o le produce come raccomandazione;
nome e contatti del responsabile del sistema (RSIA);
data di entrata in esercizio e data dell’ultima valutazione;
riferimento alla documentazione FRIA ove condotto;
modalità per l’esercizio dei diritti di spiegazione e contestazione.
Le PA DEVONO aggiornare il registro entro 30 giorni dall’entrata in esercizio di un nuovo sistema, da ogni modifica significativa e dalla sua dismissione.
Lo schema minimo della scheda algoritmo è definito nello Strumento C delle presenti Linee guida.
Proposta 1.5 — Responsabile dei sistemi di IA (RSIA)
Mappatura della lacuna
Il documento attribuisce la responsabilità genericamente alla PA come soggetto istituzionale, senza mai identificare una figura interna responsabile della governance algoritmica. Il P.5 afferma che “le PA identificano chiaramente le responsabilità” senza specificare chi debba essere identificato e con quali competenze.
Ancoraggio normativo
| Fonte | Disposizione | Tipo |
|---|---|---|
| AI Act | Art. 26 — Obblighi del deployer, che implica una struttura interna di governo | Cogente |
| GDPR | Artt. 37-39 — Modello del DPO: nomina, requisiti di competenza, indipendenza, funzioni | Modello strutturale |
| CAD | Art. 17 — Responsabile per la transizione digitale: punto di raccordo esistente | Cogente nazionale |
| ISO/IEC 42001 | § 5.3 — Ruoli, responsabilità e autorità nell’AI Management System | Standard tecnico |
Testo proposto
PROPOSTA 1.5 — Nuovo § 2.6: Governance interna: il Responsabile dei sistemi di IA (RSIA)
Posizione nel documento: Nuovo § 2.6
Le PA che adottano sistemi di IA classificati ad alto rischio ai sensi dell’AI Act, ovvero sistemi che producono effetti giuridici o incidono in modo significativo su persone fisiche indipendentemente dalla classificazione formale, DEVONO designare formalmente un Responsabile dei sistemi di IA (RSIA).
Il RSIA può coincidere con il Responsabile per la Transizione al Digitale di cui all’art. 17 del CAD, purché disponga delle competenze specifiche indicate nel presente paragrafo.
Funzioni del RSIA
Il RSIA DEVE:
supervisionare l’adozione e l’uso dei sistemi di IA, verificandone la conformità alle presenti Linee guida e al quadro normativo applicabile;
condurre o coordinare la conduzione del FRIA di cui al § 2.7 per ogni sistema ad alto rischio;
tenere aggiornato il Registro pubblico degli algoritmi di cui al § 2.5;
costituire il punto di contatto istituzionale per i soggetti interessati che esercitano i diritti di spiegazione e contestazione;
coordinarsi con il RPD/DPO per gli aspetti relativi alla protezione dei dati personali;
riferire periodicamente all’organo di vertice sullo stato dei sistemi di IA in uso, sugli incidenti registrati e sulle misure adottate;
coordinare la gestione degli incidenti con impatto sui diritti di cui al § 2.8.
Le PA di minori dimensioni POSSONO condividere la funzione di RSIA mediante accordi tra amministrazioni, ferma restando la responsabilità individuale di ciascuna PA per i propri sistemi.
Proposta 1.6 — FRIA: processo strutturato
Mappatura della lacuna
Il FRIA è citato in una sola riga al § 2.3.1: “DEVONO essere effettuate valutazioni preventive come DPIA o FRIA (in caso di sistemi ad alto rischio)”. Non viene mai definito, strutturato né raccordato con il ciclo di vita del sistema. In tutto il documento (109 pagine) non compare mai una procedura, un template né un riferimento alle linee guida CE sul FRIA.
Ancoraggio normativo
| Fonte | Disposizione | Tipo |
|---|---|---|
| AI Act | Art. 27 — Obbligo per deployer che sono autorità pubbliche di condurre FRIA prima della messa in uso di sistemi ad alto rischio | Cogente |
| AI Act | Art. 27 c.2 — Contenuto del FRIA: descrizione del sistema, finalità, rischi per i diritti, misure adottate | Cogente |
| CE — Linee guida FRIA 2023 | Template e metodologia per la conduzione del FRIA in 6 fasi | Soft law CE |
| GDPR | Art. 35 — DPIA: modello procedurale consolidato da cui derivare la struttura del FRIA | Cogente (modello) |
Testo proposto
PROPOSTA 1.6 — Nuovo § 2.7: Valutazione d’impatto sui diritti fondamentali (FRIA)
Posizione nel documento: Nuovo § 2.7 + integrazione § 4.1 + Strumento D
Le PA che intendono mettere in uso sistemi di IA classificati ad alto rischio DEVONO condurre una Valutazione d’impatto sui diritti fondamentali (FRIA) prima della messa in esercizio del sistema, in conformità all’art. 27 del Regolamento (UE) 2024/1689.
Le PA DOVREBBERO condurre il FRIA anche per sistemi non classificati formalmente ad alto rischio, qualora il sistema produca effetti significativi su persone fisiche, tratti categorie particolari di dati ai sensi dell’art. 9 del GDPR, o incida su procedimenti che riguardano diritti fondamentali.
Processo
Il FRIA DEVE essere condotto nelle seguenti fasi, descritte nel dettaglio nello Strumento D:
descrizione del sistema e del suo contesto d’uso nel procedimento amministrativo;
identificazione dei soggetti interessati e delle categorie potenzialmente vulnerabili;
identificazione dei diritti fondamentali potenzialmente impattati (con riferimento alla CDFUE, artt. 7, 8, 21, 41, 47);
valutazione della probabilità e della gravità dell’impatto per ciascun diritto identificato;
individuazione delle misure di mitigazione adottate o da adottare;
valutazione del rischio residuo e decisione motivata sulla messa in uso.
Il FRIA DEVE essere condotto prima della fase di messa a disposizione per l’esercizio di cui al § 4.5 e DEVE essere aggiornato in caso di modifiche significative al sistema. Una sintesi non riservata del FRIA DEVE essere pubblicata nel Registro pubblico degli algoritmi di cui al § 2.5.
Proposta 1.7 — Gestione degli incidenti con impatto sui diritti
Mappatura della lacuna
La gestione degli incidenti è trattata esclusivamente come problema di continuità operativa e sicurezza cibernetica. Manca completamente la dimensione degli incidenti come eventi che producono effetti sui diritti dei cittadini: notifica agli interessati, comunicazione pubblica, raccordo con le autorità di vigilanza, revisione retroattiva delle decisioni adottate durante il malfunzionamento.
Ancoraggio normativo
| Fonte | Disposizione | Tipo |
|---|---|---|
| AI Act | Art. 73-74 — Segnalazione di incidenti gravi; 15 giorni per incidenti gravi | Cogente |
| GDPR | Art. 33-34 — Notifica violazioni: termini, contenuto, comunicazione agli interessati | Cogente |
| L. 241/90 | Art. 21-octies — Annullabilità del provvedimento viziato: base per revisione retroattiva | Cogente nazionale |
| NIS2 / D.Lgs. 138/2024 | Art. 23 — Notifica incidenti significativi ad ACN | Cogente nazionale |
Testo proposto
PROPOSTA 1.7 — Nuovo § 2.8: Gestione degli incidenti con impatto sui diritti
Posizione nel documento: Nuovo § 2.8 + integrazioni §§ 4.6, 5.7.3
Costituisce incidente rilevante qualsiasi malfunzionamento, comportamento non conforme alle specifiche, violazione della sicurezza o uso improprio di un sistema di IA che abbia prodotto o possa aver prodotto: decisioni errate o discriminatorie con effetti su persone fisiche; trattamento non conforme dei dati personali; interruzione del servizio con impatto sui diritti degli utenti.
Procedura di gestione — fasi obbligatorie:
Rilevazione e contenimento (entro 24 ore): attivare misure di contenimento, sospendere o limitare l’uso del sistema ove necessario;
Valutazione degli effetti (entro 72 ore): determinare il numero e le categorie di soggetti potenzialmente interessati;
Notifica alle autorità nei termini di legge (AI Act art. 73, GDPR art. 33, D.Lgs. 138/2024 art. 23);
Comunicazione agli interessati ove l’incidente abbia prodotto effetti pregiudizievoli su persone fisiche identificabili;
Revisione retroattiva: verificare le decisioni adottate nel periodo di malfunzionamento e procedere alla loro revisione d’ufficio ai sensi dell’art. 21-octies della L. 241/90;
Analisi della causa radice e misure correttive documentate prima della rimessa in esercizio.
Proposta 1.8 — Documentazione pubblica dei modelli (Model Card)
Mappatura della lacuna
La documentazione dei modelli è concepita esclusivamente come requisito tecnico interno (§ 5.6.5 e § 3.1.4). Non è mai prevista una dimensione pubblica. Mancano: l’obbligo di produrre una scheda pubblica del modello; il contenuto minimo; la distinzione tra documentazione tecnica (per auditor) e documentazione pubblica (per cittadini).
Testo proposto
PROPOSTA 1.8 — Integrazione § 3.1.4: Documentazione pubblica dei modelli
Posizione nel documento: § 3.1.4 + § 5.6.5 + Strumento C
Per ogni modello di IA messo in uso dalla PA in procedimenti che producono effetti su persone fisiche, la PA DEVE produrre e mantenere aggiornata una scheda pubblica del modello, distinta dalla documentazione tecnica interna.
La scheda pubblica del modello DEVE contenere almeno: denominazione, versione e data di rilascio; finalità in linguaggio comprensibile al cittadino; tipologia e provenienza dei dati di addestramento; prestazioni sui principali indicatori di accuratezza; limitazioni note e bias identificati con relative misure di mitigazione; livello di supervisione umana previsto nell’uso operativo.
La scheda pubblica costituisce parte integrante della scheda algoritmo nel Registro pubblico degli algoritmi di cui al § 2.5 e DEVE essere redatta in linguaggio accessibile, in formato aperto e riutilizzabile.
Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione
Le seguenti proposte riguardano argomenti già presenti nel documento ma trattati in forma insufficiente, priva di metodologia operativa o di meccanismi attuativi.
Proposta 2.1 — Spiegabilità: metodologia, metriche e differenziazione per famiglia di sistema
Lacuna residua
Il Principio 7 prescrive la spiegabilità senza fornire alcun orientamento metodologico. La Proposta 1.2 ha affrontato il diritto soggettivo del cittadino. Rimangono assenti: distinzione delle tecniche per famiglia di sistema (ML predittivo / reti neurali profonde / IA Generativa); requisiti di verifica della fedeltà delle spiegazioni; soglie di accettabilità differenziate per livello di rischio.
Testo proposto
PROPOSTA 2.1 — Integrazione metodologica al Principio 7 + § 4.4 + § 3.1.4
Posizione nel documento: § 2.2 P.7 + § 4.4 (testing) + § 3.1.4 (AI Model Layer)
Per sistemi di IA predittiva e Machine Learning: privilegiare tecniche di spiegabilità locale che attribuiscano peso relativo ai fattori della singola decisione. Per modelli intrinsecamente interpretabili, la spiegabilità DEVE essere documentata attraverso la struttura del modello stesso.
Per sistemi basati su reti neurali profonde e Deep Learning: riconoscere i limiti della spiegabilità post-hoc e adottare approcci per identificare le caratteristiche dell’input maggiormente determinanti per l’output, documentando le limitazioni note.
Per sistemi di IA Generativa e LLM: adottare documentazione del sistema di prompt; meccanismi di tracciamento delle fonti ove tecnicamente disponibili; indicazione esplicita all’utente dei limiti dell’output generativo. La spiegabilità a livello di processo interno NON DEVE essere presentata come garantibile allo stato attuale della ricerca.
I sistemi DEVONO essere progettati in modo che le tecniche di spiegabilità producano spiegazioni fedeli al processo decisionale effettivo, e non razionalizzazioni post-hoc. Le PA DEVONO documentare come verificano la fedeltà delle spiegazioni prodotte.
In fase di testing, per sistemi ad alto rischio: le spiegazioni DEVONO essere sottoposte a valutazione di fedeltà documentata; DEVONO essere condotti test di comprensibilità su un campione rappresentativo dei destinatari; i risultati DEVONO essere inclusi nella documentazione pubblica del modello.
Proposta 2.3 — Responsabilità in architetture multi-fornitore e sistemi as-a-service
Lacuna residua
Il Principio 5 afferma la responsabilità della PA senza affrontare come essa si articola nelle architetture multi-fornitore promosse dal documento, né nel caso dell’Operatore base che usa sistemi as-a-service (il caso più frequente). Mancano: matrice di responsabilità per componente; obblighi contrattuali specifici per la supply chain dei dati di training; requisiti minimi per sistemi as-a-service.
Testo proposto
PROPOSTA 2.3 — Integrazione Principio 5: Responsabilità multi-fornitore + § 3.5.1
Posizione nel documento: § 2.2 P.5 colonne Sviluppo e Procurement + § 3.5.1 (Operatore base)
In fase di sviluppo, per i sistemi che integrano componenti di fornitori multipli, le PA DEVONO definire preventivamente la matrice di responsabilità dell’intero sistema, identificando per ciascun componente il soggetto responsabile in caso di malfunzionamento e la procedura di attribuzione della responsabilità in caso di malfunzionamenti originati dall’interazione tra componenti di fornitori diversi.
Per i sistemi che utilizzano dati di training acquisiti da fornitori esterni, le PA DEVONO verificare e documentare qualità, rappresentatività e assenza di bias nei dati acquisiti. I contratti di acquisizione dei dati DEVONO prevedere garanzie documentate sulla provenienza, la qualità e l’assenza di bias, nonché obblighi di cooperazione in caso di identificazione successiva di problemi.
Le PA classificate come Operatori base DEVONO verificare, prima di adottare un sistema as-a-service per procedimenti che producono effetti su persone fisiche, che il fornitore metta a disposizione: documentazione sulla logica del sistema; accesso ai log per le singole decisioni; procedure di supporto per le contestazioni. Ove il fornitore non garantisca tali requisiti, la PA NON DEVE adottare il sistema per procedimenti con effetti giuridici su persone fisiche.
Proposta 2.4 — Logging: contenuto minimo, retention, accesso e tensione con il GDPR
Lacuna residua
Il Principio 14 prescrive un’attività di logging orientato all’audit interno senza definire: il contenuto minimo per singola decisione individuale; i periodi di retention differenziati per livello di rischio; le procedure di accesso strutturato per gli interessati; la soluzione della tensione tra obbligo di logging completo (AI Act) e principio di minimizzazione (GDPR).
Ancoraggio normativo
| Fonte | Disposizione | Tipo |
|---|---|---|
| AI Act | Art. 12 c.1 — Logging automatico per sistemi ad alto rischio: contenuto minimo dei log | Cogente |
| AI Act | Art. 26 c.5 — Il deployer conserva i log per almeno 6 mesi | Cogente |
| GDPR | Art. 5 c.1 b) e e) — Minimizzazione e limitazione della conservazione: tensione da risolvere | Cogente |
| L. 241/90 | Art. 22-25 — Diritto di accesso agli atti: applicabile alla documentazione del procedimento algoritmico | Cogente nazionale |
Testo proposto
PROPOSTA 2.4 — Ampliamento Principio 14: Contenuto minimo, retention, accesso
Posizione nel documento: § 2.2 P.14 + § 4.6 + § 5.7.3
Per ogni decisione o raccomandazione prodotta dal sistema che produce effetti su persone fisiche, il log DEVE registrare almeno: identificativo univoco della decisione; data e ora; versione del modello attiva al momento; tipologia degli input ricevuti; fattori principali estratti dal sistema come rilevanti, con direzione e peso relativo ove disponibile; output prodotto; indicazione dell’eventuale supervisione umana con riferimento all’identità del supervisore e all’esito della sua valutazione.
I log DEVONO essere progettati secondo il principio di pseudonimizzazione strutturale: i dati che consentono di ricondurre il log alla persona fisica DEVONO essere conservati separatamente, con accesso controllato e distinto. Questa soluzione consente di soddisfare simultaneamente l’obbligo di logging completo ai sensi dell’AI Act e il principio di minimizzazione del GDPR.
Periodi di retention differenziati:
per sistemi ad alto rischio: non meno di 6 mesi e comunque non inferiore ai termini di prescrizione dei diritti applicabili al procedimento;
per sistemi a rischio limitato: non meno di 3 mesi;
per log relativi a incidenti rilevanti: non meno di 5 anni dalla chiusura dell’incidente.
Per architetture agentiche multi-componente, i log dei singoli agenti DEVONO essere correlabili mediante un identificativo comune di sessione o decisione, consentendo la ricostruzione end-to-end del processo.
Proposta 2.5 — Test su bias: definizione, metodologie, metriche, monitoring e pubblicazione
Lacuna residua
Il Principio 6 prescrive test sistematici senza fornire: definizione operativa di bias; metodologie di riferimento; metriche e soglie di accettabilità; definizione delle caratteristiche protette da testare; obblighi di monitoring continuativo durante l’esercizio; obblighi di pubblicazione dei risultati.
Ancoraggio normativo
| Fonte | Disposizione | Tipo |
|---|---|---|
| AI Act | Art. 10 c.2-3 — Esame dei dati di training per bias; misure adeguate di rilevazione e mitigazione | Cogente |
| ISO/IEC 24027 | Bias in AI systems and AI-aided decision making: definizioni, metriche, metodologie | Standard tecnico |
| IEEE 7003-2023 | Algorithmic Bias Considerations: processo di identificazione e mitigazione | Standard tecnico |
| NIST SP 1270 | Towards a Standard for Identifying and Managing Bias in AI | Best practice NIST |
Testo proposto
PROPOSTA 2.5 — Ampliamento Principio 6 + §§ 3.4.1, 4.4, 4.6: Test su bias
Posizione nel documento: § 2.2 P.6 + § 3.4.1 + § 4.4 + § 4.6
Per bias algoritmico si intende qualsiasi sistematica disparità nelle prestazioni del sistema o negli esiti delle sue decisioni che produce trattamenti differenziati ingiustificati tra gruppi di persone definiti da caratteristiche protette, ovvero qualsiasi sistematica tendenza del sistema a riflettere discriminazioni storiche presenti nei dati di addestramento.
Le PA DEVONO condurre test su bias distinguendo: bias nei dati di addestramento (rappresentatività); bias nelle prestazioni (accuratezza differenziata per gruppi); bias negli esiti (distribuzione differenziata delle decisioni tra gruppi protetti).
Le caratteristiche protette rispetto alle quali condurre i test DEVONO includere almeno quelle indicate all’art. 21 della CDFUE, adattate al contesto del procedimento. Le PA DEVONO documentare le caratteristiche selezionate e motivare l’eventuale esclusione.
Le PA DEVONO definire preventivamente le soglie di accettabilità delle disparità rilevate. Il superamento delle soglie DEVE determinare obbligatoriamente misure correttive prima della messa in esercizio.
In fase di operatività, le PA DEVONO estendere il monitoring di data drift e concept drift alla dimensione dell’equità, con indicatori di allerta precoce e procedure di risposta che attivino la rivalutazione del sistema al superamento delle soglie. I risultati del monitoring DEVONO essere inclusi nella reportistica periodica del RSIA.
Proposta 2.6 — Sorveglianza umana: livelli minimi, effettività, competenze supervisore, escalation
Lacuna residua
Il Principio 13 prescrive la sorveglianza umana senza definire: livelli minimi vincolanti per categoria di rischio; quando un intervento è “effettivo” e non meramente formale; requisiti di competenza del supervisore; raccordo con i livelli di autonomia L0-L5; procedure di escalation.
Ancoraggio normativo
| Fonte | Disposizione | Tipo |
|---|---|---|
| AI Act | Art. 14 — Supervisione umana: requisiti specifici, misure tecniche e organizzative, competenza del supervisore | Cogente |
| AI Act | Art. 14 c.4 — Il supervisore non deve affidarsi eccessivamente all’output (automation bias) | Cogente |
| AI Act | Art. 26 c.1 — Il deployer garantisce supervisione da parte di persone con le competenze necessarie | Cogente |
| L. 241/90 | Art. 6 — Il responsabile del procedimento valuta ai fini istruttori: obbligo di valutazione umana | Cogente nazionale |
Testo proposto
PROPOSTA 2.6 — Ampliamento Principio 13 + §§ 3.2, 4.5: Supervisione umana effettiva
Posizione nel documento: § 2.2 P.13 + § 3.2 + § 4.5
Le PA DEVONO classificare la supervisione umana in tre livelli, selezionati in relazione alla classificazione di rischio:
Livello A — Supervisione continua: il soggetto umano supervisiona in tempo reale ogni output prima che produca effetti. Obbligatorio per sistemi ad alto rischio che producono decisioni in procedimenti che incidono su diritti fondamentali.
Livello B — Supervisione per eccezione: il soggetto umano supervisiona gli output che superano soglie di incertezza o anomalia definite, con revisione periodica di un campione statisticamente rappresentativo.
Livello C — Supervisione su richiesta: il soggetto umano interviene su richiesta dell’interessato o al verificarsi di condizioni di allerta. Applicabile a sistemi a rischio limitato.
La supervisione è effettiva quando il soggetto incaricato:
comprende i limiti del sistema e i bias identificati;
ha accesso alle informazioni necessarie per valutare in modo indipendente il caso;
effettua una valutazione autonoma e non si limita a verificare la coerenza formale dell’output;
documenta la propria valutazione e le eventuali divergenze dall’output del sistema;
è consapevole del rischio di automation bias e ha ricevuto formazione specifica.
Il livello di autonomia agentica L4 (agenti semi-autonomi) NON DEVE essere adottato per sistemi ad alto rischio senza valutazione documentata approvata dal RSIA. Il livello L5 (agenti completamente autonomi) NON DEVE essere adottato per procedimenti che producono effetti su persone fisiche.
Proposta 2.7 — Gestione degli incidenti: tassonomia, soglie e framework integrato di notifica
Lacuna residua
La Proposta 1.7 ha sviluppato la dimensione dei diritti dei cittadini. Rimangono: assenza di tassonomia degli incidenti; assenza di soglie di attivazione; frammentazione delle notifiche verso Garante, ACN e autorità AI Act in tre regimi separati senza framework integrato; assenza di raccordo tra incidenti significativi e revisione del FRIA.
Testo proposto
PROPOSTA 2.7-TAX — Tassonomia degli incidenti nei sistemi di IA
Posizione nel documento: § 2.8, paragrafo di classificazione
Categoria A — Incidente di sicurezza cibernetica: compromissione dell’integrità, disponibilità o riservatezza del sistema. Attiva notifica ad ACN ai sensi del D.Lgs. 138/2024.
Categoria B — Violazione dei dati personali: accesso non autorizzato. Attiva notifica al Garante entro 72 ore (GDPR art. 33) e comunicazione agli interessati (art. 34) ove applicabile.
Categoria C — Malfunzionamento tecnico: comportamento difforme dalle specifiche, output errati. Attiva contenimento e valutazione degli effetti sulle decisioni adottate nel periodo.
Categoria D — Bias o discriminazione sistematica rilevata in fase operativa. Attiva rivalutazione del sistema e verifica delle decisioni adottate nel periodo.
Categoria E — Incidente grave ai sensi dell’AI Act: morte, danno grave alla salute, violazione grave di diritti fondamentali. Attiva notifica all’autorità AI Act entro 15 giorni (art. 73).
Le categorie non sono mutualmente esclusive. Quando un incidente attiva più categorie, il RSIA coordina le notifiche verso le diverse autorità garantendo coerenza delle informazioni fornite.
Framework integrato di notifica
| Categoria | Autorità | Termine | Riferimento normativo |
|---|---|---|---|
| A | ACN | Secondo severità NIS2 | D.Lgs. 138/2024 art. 23 |
| B | Garante Privacy | 72 ore dalla rilevazione | GDPR art. 33 |
| B (rischio elevato) | Interessati | Senza indebito ritardo | GDPR art. 34 |
| C con effetti su diritti | Interessati | Compatibile con termini del procedimento | L. 241/90 art. 21-octies |
| D | RSIA + organo di vertice | Notifica interna immediata | Presenti Linee Guida § 2.6 |
| E | Autorità nazionale AI Act | 15 giorni (incidenti gravi) | AI Act art. 73 |
Il verificarsi di un incidente di Categoria D o E DEVE attivare una revisione del FRIA condotto ai sensi del § 2.7, da completarsi entro 60 giorni dalla chiusura dell’incidente.
Bozza di Linee Guida per lo sviluppo di sistemi di Intelligenza Artificiale nella Pubblica Amministrazione
3.1 Fonti normative cogenti
| Fonte | Riferimento | Proposte che la utilizzano |
|---|---|---|
| AI Act, Reg. (UE) 2024/1689 | Artt. 13, 14, 25, 26, 27, 28, 49, 50, 73, 74, 86; All. IV | 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 2.3, 2.4, 2.5, 2.6, 2.7 |
| GDPR, Reg. (UE) 2016/679 | Artt. 5, 13, 14, 15, 22, 33, 34, 35, 36 | 1.1, 1.2, 1.3, 1.7, 2.4, 2.7 |
| L. 241/90 | Artt. 3, 6, 7, 10, 10-bis, 21-octies, 22-25 | 1.1, 1.3, 1.7, 2.6, 2.7 |
| D.Lgs. 33/2013 | Artt. 1, 5, 29 | 1.4, 1.8 |
| L. 132/2025 | Art. 3 | 1.1, 1.4 |
| D.Lgs. 82/2005 (CAD) | Art. 17 | 1.5 |
| D.Lgs. 138/2024 (NIS2) | Art. 23 | 1.7, 2.7 |
| D.Lgs. 104/2010 (CPA) | Art. 31 | 1.3 |
| Dir. (UE) 2024/2853 (Prodotti) | Responsabilità prodotti difettosi applicabile a sistemi IA | 2.3 |
| Carta CDFUE | Artt. 7, 8, 21, 41, 47 | 1.6, 2.5 |
3.2 Giurisprudenza amministrativa
| Fonte | Estremi | Principio rilevante |
|---|---|---|
| Consiglio di Stato | Sent. 2270/2019 | Principi di conoscibilità, comprensibilità e non esclusività dell’algoritmo |
| Consiglio di Stato | Parere 1940/2020 | L’algoritmo non può sostituire la valutazione umana; obbligo di conoscibilità e sindacabilità |
3.3 Standard tecnici
| Standard | Titolo | Proposte |
|---|---|---|
| ISO/IEC 42001:2023 | AI Management System, ruoli, responsabilità, gestione del rischio | 1.5, 1.7, 2.3 |
| ISO/IEC 24027:2021 | Bias in AI systems and AI-aided decision making | 2.5 |
| ISO/IEC 24029-1 | Assessment of robustness of neural networks | 2.5 |
| ISO/IEC 22989:2022 | AI concepts and terminology, interpretabilità e spiegabilità | 2.1 |
| ISO/IEC 27035 | Information security incident management | 2.7 |
| IEEE 7001-2021 | Transparency of Autonomous Systems | 1.2, 2.1 |
| IEEE 7003-2023 | Algorithmic Bias Considerations | 2.5 |
| NIST AI RMF (2023) | AI Risk Management Framework, GOVERN, MAP, MEASURE, MANAGE | 1.5, 1.7, 2.1 |
| NIST SP 1270 | Towards a Standard for Identifying and Managing Bias in AI | 2.5 |
| Mitchell et al. (2019) | Model Cards for Model Reporting, standard de facto CE e NIST | 1.8 |
3.4 Modelli comparati e soft law
| Fonte | Tipo | Pertinenza |
|---|---|---|
| CE, Linee guida FRIA (2023) | Soft law CE | Template e metodologia FRIA: Proposta 1.6 |
| CE, Guidelines on XAI (2019) | Soft law CE | Tassonomia approcci XAI: Proposta 2.1 |
| CE, AI Office Guidance (2024) | Soft law CE | Strutture interne di governance per deployer: Proposta 1.5 |
| Loi pour une République numérique, FR (2016) | Modello comparato | Registro algoritmi PA: Proposta 1.4 |
| IAMA, Olanda (2021) | Best practice | Impact Assessment su diritti e algoritmi: Proposte 1.4, 1.6 |
| NCSC UK, Guidelines for secure AI (2023) | Best practice (già citata nel documento) | Raccordo con cap. 5: Proposta 2.7 |
| Open Government Partnership | Framework internazionale | Trasparenza algoritmica: Proposte 1.4, 1.8 |
| # | Oggetto | Posizione | Tipo | Priorità |
|---|---|---|---|---|
| 1.1 | Responsabilità esterna verso il cittadino | § 2.2 P.5 + nuovo P.5-bis | Ampliamento + nuovo principio | ALTA |
| 1.2 | Spiegabilità intelligibile (diritto soggettivo) | § 2.2 P.7 + § 4.5 | Ampliamento + requisito operativo | ALTA |
| 1.3 | Diritto di contestazione e ricorso | Nuovo P.5-ter + § 4.6 | Nuovo principio + richiamo operativo | ALTA |
| 1.4 | Registro pubblico degli algoritmi | Nuovo § 2.5 + Strumento C | Nuova sezione + nuovo strumento | MEDIA |
| 1.5 | Responsabile dei sistemi di IA (RSIA) | Nuovo § 2.6 | Nuova sezione | MEDIA |
| 1.6 | FRIA, processo strutturato | Nuovo § 2.7 + § 4.1 + Strumento D | Nuova sezione + integrazione + nuovo strumento | ALTA |
| 1.7 | Gestione incidenti con impatto sui diritti | Nuovo § 2.8 + §§ 4.6, 5.7.3 | Nuova sezione + integrazioni | ALTA |
| 1.8 | Documentazione pubblica dei modelli (Model Card) | § 3.1.4 + § 5.6.5 + Strumento C | Ampliamenti | INTEGRATIVA |
| 2.1 | Spiegabilità, metodologia per famiglia di sistema | § 2.2 P.7 + §§ 4.4, 3.1.4 | Ampliamento tecnico-metodologico | MEDIA |
| 2.3 | Responsabilità multi-fornitore e as-a-service | § 2.2 P.5 + §§ 3.5.1, 4.1 | Ampliamento + integrazione | INTEGRATIVA |
| 2.4 | Logging, contenuto, retention, accesso, GDPR | § 2.2 P.14 + §§ 4.6, 5.7.3 | Ampliamento sostanziale | ALTA |
| 2.5 | Test su bias, metodologie e monitoring | § 2.2 P.6 + §§ 3.4.1, 4.4, 4.6 | Ampliamento + paragrafi operativi | MEDIA |
| 2.6 | Sorveglianza umana, livelli minimi ed effettività | § 2.2 P.13 + §§ 3.2, 4.5 | Ampliamento + paragrafi operativi | MEDIA |
| 2.7 | Gestione incidenti, tassonomia e notifiche | § 2.8 + §§ 4.6, 5.7.3 | Integrazione strutturale | MEDIA |
Par 2.2 Correlazione tra i principi per l’Adozione, lo Sviluppo e il Procurement di sistemi di IA nella Pubblica Amministrazione - Principio 17 : Innovazione e miglioramento continuo
Il documento prescrive che il procurement «debba incoraggiare l’utilizzo di componenti aperte, riusabili e, ove appropriato, open source e open weights».
Si propone di valutare l’orientamento open source/open weights, ancorandolo anche a caratteristiche dimostrabili piuttosto che alla natura della licenza, e di orientare i requisiti prescrittivi anche verso API standard e documentate. Per i sistemi ad alto rischio ai sensi dell’AI Act, la trasparenza del processo di addestramento riveste particolare rilevanza ai fini della governance e del controllo pubblico: in tali casi, si raccomanda che le stazioni appaltanti valutino positivamente la disponibilità di documentazione tecnica sull’addestramento equiparabile agli obblighi già previsti dall’AI Act, indipendentemente dalla natura open o proprietaria del modello.
La Pubblica Amministrazione dovrebbe essere messa nelle condizioni di poter valutare caso per caso vantaggi e svantaggi delle licenze open, closed, o open weights associate ai modelli. Tenendo conto dei principi di right-sizing, dei risultati di performance in benchmark internazionali, e della capacità di controllo e trasparenza e accessibilità del modello.
Contributo a cura di Traent Srl.
Si propone di integrare il Principio 14 “Registrazioni (logging)” (§2.2, pag. 25) specificando le proprietà tecniche minime che i «meccanismi di logging interoperabili, strutturati e verificabili mediante audit» devono possedere affinché la verificabilità sia effettiva e non nominale. In assenza di requisiti di non ripudiabilità e integrità dimostrabile — quali hash crittografici, firme digitali e marcature temporali opponibili — l’espressione “verificabili mediante audit” resta priva di contenuto tecnico: un log che può essere modificato dall’operatore dopo la sua creazione non costituisce una base affidabile per l’audit. Si chiede che le Linee Guida qualifichino i requisiti del logging affinché l’accountability, già enunciata tra i principi che mirano a «garantire controllo, sostenibilità, interoperabilità e autonomia operativa» (§2.1, pag. 16), passi da obbligo dichiarativo a proprietà tecnicamente accertabile, coerentemente con l’art. 12 e l’art. 17 del Regolamento (UE) 2024/1689 (AI Act).
Si evidenzia che la sezione dedicata allo sviluppo dei sistemi di IA, pur solida sul piano concettuale, presenta una criticità rilevante sotto il profilo operativo: i principi sono formulati in modo narrativo e non risultano verificabili né contrattualizzabili. In assenza di KPI, soglie e evidenze richieste, le amministrazioni non dispongono di strumenti concreti per dimostrare la conformità né per effettuare audit. Si propone quindi di integrare le Linee Guida con una matrice di attuazione dei principi, che associ a ciascun requisito una metrica, una evidenza documentale e una frequenza di verifica. Inoltre, per i sistemi di Generative AI e LLM, è necessario introdurre requisiti specifici, quali meccanismi di validazione degli input e degli output, tecniche di grounding per ridurre le allucinazioni e controlli contro la prompt injection, al fine di garantire un livello di sicurezza e affidabilità adeguato al contesto pubblico.
