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.
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.
Evidenzio 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, suggerisco 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.
Suggerisco 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
