La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 1. Ambito di applicazione.
I commenti dovranno includere il numero del paragrafo o sotto-paragrafo (se presente) e un riferimento puntuale al brano di testo al quale si riferiscono (ad esempio paragrafo 4.3, terzo capoverso).
non si dichiara chiaramente che il procurement non può mai acquisire sistemi che rientrano nei divieti previsti dal Reg. UE 2024/1689. Subito dopo il paragrafo “Principi generali del procurement”, inserire come nota di rafforzamento: “I procedimenti di gara devono includere l’esclusione e la non ammissibilità di soluzioni rientranti nei divieti dell’AI Act”.
marieva favoino - Forum Governo Aperto e FID
InnovUp accoglie positivamente lo spirito di questa bozza di Linee guida, che punta a trasformare il paradigma di collaborazione del settore privato e la Pubblica Amministrazione, allontanandosi dal tradizionale approccio al procurement pubblico, segnato da eccessive barriere all’ingresso.
Questo cambio di rotta risulta vitale per startup e PMI innovative, che fungono da vero volano di innovazione per il Paese. Per garantire che tali realtà non siano escluse dai processi di trasformazione digitale della PA, la normativa deve includere riferimenti espliciti a criteri di accesso semplificati.
Tuttavia, per rendere effettivo il principio dell’accesso al mercato ed evitare che la complessità dei nuovi parametri (come il monitoraggio continuo e il calcolo del LCOAI) diventi una barriera escludente, è necessario che queste linee guida includano un riferimento esplicito a criteri semplificati per startup, microimprese e PMI innovative.
A questo scopo, ribadiamo la necessità di adottare un approccio analogo a quello già concretizzato nel c.d. DDL Spazio, stabilendo criteri più flessibili e moderni per la valutazione dei requisiti di partecipazione. In particolare proponiamo la formalizzazione di quanto segue:
“Per le start-up, le microimprese e le piccole e medie imprese innovative, la solidità finanziaria e l’affidabilità tecnica devono essere valutate considerando non solo i parametri contabili tradizionali, ma anche la presenza di investitori istituzionali, il supporto di programmi di finanziamento pubblico o privato e la partecipazione a incubatori o acceleratori di impresa riconosciuti.”
Accanto alla semplificazione dei criteri di accesso, si ritiene necessario introdurre un riferimento esplicito alla fase pre-procurement. Nella prassi operativa, le soluzioni innovative vengono frequentemente intercettate attraverso interlocuzioni preliminari (incontri, presentazioni, comunicazioni via PEC), che tuttavia non dispongono di un inquadramento strutturato né di criteri di valutazione formalizzati.
In assenza di strumenti dedicati, anche in presenza di interesse da parte dell’amministrazione, tali proposte devono essere ricondotte esclusivamente a procedure competitive standard (bandi di gara), senza passaggi intermedi di validazione tecnica o sperimentazione controllata.
Si propone pertanto l’introduzione di meccanismi formali di valutazione preliminare dell’innovazione, quali sandbox regolatorie, programmi di sperimentazione pilota e/o elenchi di soluzioni qualificate, che consentano alle amministrazioni di analizzare e testare soluzioni innovative prima dell’avvio di una procedura di gara.
Tali strumenti permetterebbero di ridurre i tempi decisionali, migliorare l’allineamento tra fabbisogno pubblico e offerta tecnologica e favorire un accesso più efficace delle startup e PMI innovative ai processi di innovazione della PA.
Tali meccanismi potrebbero inoltre beneficiare di un coordinamento multilivello, prevedendo forme di validazione condivisa tra amministrazioni locali e livelli sovraordinati. Questo approccio consentirebbe di superare una valutazione esclusivamente locale, favorendo decisioni più coerenti e scalabili a livello territoriale e regionale, anche in integrazione con le piattaforme nazionali di procurement digitale già esistenti.
Lepida SCpA, società in-house di Regione Emilia-Romagna e delle Pubbliche Amministrazioni del territorio regionale, presenta le seguenti osservazioni alla consultazione sulle LGP. L’analisi è stata condotta applicando un modello strutturato di valutazione del rischio etico dei sistemi di IA, descritto nella sezione A.1, e si colloca in continuità con i commenti presentati alla consultazione sulle Linee Guida per l’introduzione dell’IA nella PA del marzo 2025.
Le presenti osservazioni adottano il modello dello “Spazio di Interazione Generativa” (SIG) come strumento di lettura delle LLG. È un modello “tridimensionale” per la valutazione del rischio nei sistemi di IA generativa sviluppato da Lepida. Il modello individua tre assi distinti nello spazio dell’interazione con modelli di Intelligenza Artificiale Generativa, le cui dinamiche possono influenzarsi reciprocamente: la Knowledge Base (Kb), cioè i dati e la conoscenza che alimentano il sistema; la Question (Q), cioè le interrogazioni e gli output che il sistema produce; la User Information (U), le informazioni che l’utente fornisce durante l’interazione.
La posizione nel SIG definito così determina il profilo di rischio (anche etico) e, di conseguenza, il tipo e l’intensità dei presidi necessari. Il modello è stato progettato per essere reso operativo all’interno di organizzazioni complesse, il che lo rende direttamente applicabile al contesto della Pubblica Amministrazione, come stazione appaltante.
L’applicazione del SIG alle Linee Guida per il Procurement (di seguito LGP) ha consentito di identificare con precisione dove il documento offre presidi adeguati e dove, invece, rischia di lasciare scoperte intere dimensioni di rischio.
Le presenti osservazioni si collocano in continuità con i commenti presentati da Lepida nel marzo 2025 alla consultazione sulle Linee Guida per l’introduzione dell’IA nella Pubblica Amministrazione (LGA). Quei commenti riguardavano, tra l’altro, la distinzione tra dati e modello e il rischio di scarico cognitivo — temi che restano aperti nelle LGP.
Un’analisi incrociata tra i cinque temi e il testo delle LGP ha prodotto un’evoluzione della chiave di lettura, che sintetizza lo stato attuale: alcuni temi sono stati risolti dalle LGP in modo più maturo rispetto alle LGA (in particolare la tassonomia dei sistemi di IA al par. 3.2), altri restano aperti e generano rischi specifici nel contesto del procurement. Le osservazioni che seguono si concentrano su questi ultimi.
L’analisi condotta attraverso il modello Kb-Q-U ha fatto emergere uno scenario di rischio che le LGP non identificano. Questo scenario è, a nostro avviso, la criticità più seria delle LGP nella loro formulazione attuale.
Lo scenario nasce dalla convergenza di tre fenomeni che le LGP trattano separatamente (quando li trattano) ma che nella realtà operativa si rinforzano reciprocamente.
Alla dismissione del contratto, il sistema contiene un patrimonio informativo derivato di cui nessuno ha piena contezza (gli asset informativi derivati non sono riconosciuti come categoria), la cui portata è stata sottovalutata per effetto dello scarico cognitivo e che include dati personali dei cittadini senza presidi di cancellazione. Le clausole di uscita previste dalle LGP dispongono la restituzione dei dati sorgente e la portabilità, ma non la distruzione certificata degli asset informativi derivati.
La tassonomia dei rischi del par. 3.6, quella che guida operativamente le scelte del RUP, identifica rischi tecnologici, economici, di lock-in e organizzativi. Non include una categoria autonoma di rischio etico e di equità, cioè il rischio che il sistema produca risultati sistematicamente distorti, che tratti in modo diseguale categorie di cittadini e di operatori economici, che operi con bias non rilevati. Il tema compare tra i principi generali e nel rimando alla Legge 132/2025, ma scompare esattamente nel punto dove dovrebbe tradursi in valutazione operativa. Il rischio ricade sull’asse Q del Modello.
Il modello del costo livellato dell’IA (LCOAI) al par. 4 è metodologicamente valido e rappresenta un contributo originale delle LGP. La sua applicabilità concreta, tuttavia, dipende dalla capacità delle PA di raccogliere dati economici granulari che oggi molte amministrazioni non possiedono e che i fornitori non sempre hanno interesse a rendere trasparenti. In assenza di benchmark di riferimento — proporzioni indicative CAPEX/OPEX per le diverse strategie di deployment, ordini di grandezza per casi d’uso tipici — il LCOAI rischia di restare un modello teorico che il funzionario non è in grado di popolare. Questo scenario è aggravato dal fatto che, non riconoscendo gli asset informativi derivati, il LCOAI non include i costi della loro dismissione sicura, sottostimando sistematicamente il costo reale di fine ciclo.
L’asse U dello scenario principale merita una declinazione autonoma sul piano operativo. Le LGP trattano la protezione dei dati personali come principio di conformità normativa (GDPR, AI Act), ma non traducono quel principio in requisiti specifici per il capitolato tecnico e per lo Strumento B (Guida al capitolato). Nei contesti tipici della PA (sportelli digitali, assistenti alla compilazione, sistemi di triage) il cittadino è spesso un soggetto vulnerabile che si rivolge a un’istituzione pubblica: il cittadino spesso non sa cosa il sistema registri della sua interazione e non ha motivo di saperlo. La mancanza di presidi contrattuali specifici su minimizzazione, informativa contestuale, limiti alla persistenza e audit trail delle interazioni lascia questa dimensione scoperta.
Il par. 3.4 (governance del dato) e il template contrattuale andrebbero integrati con il riconoscimento esplicito degli asset informativi derivati come categoria autonoma, distinta dai dati forniti dall’amministrazione e dai dati generati durante l’esercizio. La categoria comprende il database vettoriale (nei sistemi RAG, che contenga o non contenga i chunks di riferimento), i pesi del modello fine-tuned e qualsiasi altra rappresentazione trasformata dei dati della PA prodotta dal sistema durante il suo funzionamento. Per ciascun asset informativo derivato, il contratto dovrebbe disciplinare: titolarità, condizioni di accesso e portabilità, obbligo di distruzione certificata a fine contratto, applicazione del diritto all’oblio anche agli embeddings, divieto di utilizzo da parte del fornitore per finalità estranee al servizio.
Si propone di integrare il par. 3.8 (ciclo di vita) e i requisiti di capitolato con l’obbligo di meccanismi verificabili di mantenimento della supervisione umana effettiva. In concreto: verifiche periodiche mediante canary testing e audit incrociati tra operatori; rotazione del personale di supervisione; soglie minime di performance della supervisione come indicatore contrattuale.
Riconoscendo che la distruzione di un modello fine-tuned contenente informazioni della PA è un atto di sicurezza, non solo un adempimento contrattuale, il ciclo di vita e il LCOAI dovrebbero includere esplicitamente la dismissione sicura degli asset informativi derivati come fase del ciclo di vita del sistema. Questo comporta: obbligo di cancellazione certificata dei database vettoriali e dei modelli fine-tuned a fine contratto, con verifica indipendente; inclusione dei costi di dismissione sicura nel calcolo LCOAI; raccordo esplicito tra il framework di cybersecurity in cui opera ogni singola PA e le operazioni di dismissione.
Si propone di integrare la tassonomia dei rischi del par. 3.6 con una categoria autonoma di rischio etico e di equità, che includa: il rischio di output sistematicamente distorti o discriminatori, il rischio di trattamento diseguale di categorie di cittadini, il rischio di bias non rilevati nei dati di addestramento o negli asset informativi derivati. La categoria deve essere presente nella griglia operativa che orienta le scelte del RUP, non solo nei principi generali del documento.
Nello Strumento B (Guida al capitolato tecnico) mancano requisiti specifici per per la protezione delle informazioni fornite dall’utente durante l’interazione con il sistema. I requisiti dovrebbero riguardare, anche in coerenza con la recente modifica all’art. 50 del CAD con l’adozione del principio dell’Once Only disciplinato dall’art. 11 del DECRETO-LEGGE 19 febbraio 2026, n. 19 Ulteriori disposizioni urgenti per l’attuazione del Piano nazionale di ripresa e resilienza (PNRR),: la minimizzazione dei dati raccolti in sessione rispetto alla finalità del servizio, l’informativa contestuale all’utente su cosa il sistema registra e conserva, i limiti temporali alla persistenza delle informazioni di sessione, il divieto di confluenza automatica delle informazioni di interazione nel database vettoriale o nel fine-tuning senza valutazione e autorizzazione esplicita dell’amministrazione, la disponibilità di un audit trail delle interazioni, accessibile all’amministrazione.
Si propone di integrare il par. 4, anche in forma di allegato o di strumento dedicato, con casi d’uso di riferimento che offrano ordini di grandezza per l’applicazione del LCOAI. Per ciascun caso d’uso tipico (a titolo di esempio: sistema di triage documentale per ente di medie dimensioni, chatbot per servizi al cittadino, sistema di supporto decisionale per istruttorie), andrebbero indicati: proporzioni indicative tra CAPEX e OPEX per le principali strategie di dispiegamento (on-premises, cloud, ibrido), principali determinanti di costo, voci di costo frequentemente sottostimate. Senza questi riferimenti, il LCOAI resta uno strumento che molte PA non saranno in grado di utilizzare.
Le presenti osservazioni muovono dal riconoscimento che le LGP rappresentano un avanzamento significativo nella capacità della PA di governare il procurement di sistemi di IA, in particolare per la tassonomia delle famiglie di sistemi, l’architettura a macro-componenti e l’introduzione del LCOAI come strumento di analisi economica del ciclo di vita. Le criticità segnalate non riguardano l’impianto del documento ma le dimensioni di rischio che, a giudizio di chi scrive, restano da presidiare perché il documento possa tradursi in pratica operativa efficace. Lepida SCpA resta disponibile ad approfondire i temi sollevati e a contribuire all’eventuale sviluppo degli strumenti operativi previsti dalle LGP.
Il Comitato Scientifico dell’Osservatorio sull’Intelligenza Artificiale nelle Pubbliche Amministrazioni presenta le seguenti osservazioni:
Par 1.3 — Ambito oggettivo
Il documento dichiara di applicarsi a «tutte le componenti di applicazioni e infrastrutture tecnologiche che impiegano tecnologie di Intelligenza Artificiale, sia come componente integrata sia come supporto alle funzionalità principali».
La formula «come supporto alle funzionalità principali» non introduce alcuna soglia: qualsiasi componente accessoria vi ricade allo stesso modo di un sistema decisionale critico.
Questa assenza di distinzione tra integrazione principale e uso accessorio produrrà applicazione difforme tra le stazioni appaltanti e obblighi sproporzionati per forniture che non presentano profili di rischio elevato.
Si propone di introdurre un criterio di soglia esplicito, allineato alla logica dell’AI Act art. 6(3), che distingua tra sistemi in cui l’IA svolge funzione determinante e sistemi in cui il suo apporto è marginale o di supporto, con esempi pratici per individuare i casi d’uso più difficilmente attribuibili.
Contributo a cura di Traent Srl.
Si chiede di integrare il §1.3 (Ambito oggettivo) con una clausola di esclusione esplicita per i sistemi di IA classificati come a rischio inaccettabile ai sensi dell’Art. 5 del Regolamento (UE) 2024/1689 (AI Act). L’attuale formulazione, che include nel perimetro applicativo tutti i sistemi che «impiegano tecnologie di IA», non richiama il divieto di immissione e utilizzo dei sistemi vietati (social scoring, manipolazione subliminale, sfruttamento di vulnerabilità, riconoscimento emotivo sul luogo di lavoro) come limite esplicito del procurement. Si propone che i capitolati tecnici richiedano al fornitore evidenze tecniche verificabili di non appartenenza alle categorie vietate, accompagnate da meccanismi di monitoraggio continuo per i sistemi adattivi o generativi, il cui comportamento può evolvere nel tempo. Le verifiche periodiche dovrebbero essere registrate con garanzia crittografica di integrità e marcatura temporale, trasformando l’esclusione dei sistemi vietati da vincolo normativo statico a presidio operativo dinamico e verificabile.
Contributo a cura di Traent Srl.
Si propone di integrare il §2.1 — dove si elencano i riferimenti normativi delle Linee Guida (Regolamento UE 2024/1689, GDPR, CAD, L. 132/2025, norme ISO) — con il richiamo agli standard di trust e verificabilità rilevanti per il procurement di IA. In particolare: il Regolamento eIDAS 2.0 (UE 2024/1183), che introduce il concetto di Trust Service Provider e gli Attribute Statement verificabili; le specifiche W3C Verifiable Credentials e Decentralized Identifiers, per la verifica standardizzata dell’identità e delle credenziali dei fornitori; lo standard ISO/TC 307 per la notarizzazione su tecnologie a registro distribuito; e ETSI TS 119 per le firme elettroniche qualificate e i sigilli temporali. Il CAD stesso, all’art. 68, richiede la valutazione comparativa delle soluzioni ICT privilegiando standard aperti e interoperabilità — principio che dovrebbe estendersi anche agli strumenti di verifica della conformità nel procurement di IA.
Commenti di Monica Palmirani e Salvatore Sapienza, ALMA-AI Università di Bologna
Molte grazie per le linee guida.
Suggeriamo alcuni punti a cui prestare attenzione nella speranza che siano utili per un approfondimento.
Cordiali saluti,
Monica Palmirani, Professoressa Ordinaria di Informatica Giuridica, Dipartimento di Scienze Giuridiche, Centro interdisciplinare Alma Human Artificial Intelligence
Salvatore Sapienza, Ricercatore in Tenure Track L. 79/2022 di Informatica Giuridica, Dipartimento di Scienze Giuridiche, Centro interdisciplinare Alma Human Artificial Intelligence
Università di Bologna
===
1. Punto 2.2 Correlazione tra i principi per l’Adozione, lo Sviluppo e il Procurement di sistemi di IA nella Pubblica Amministrazione –
a. FRIA: La FRIA è vista in chiave procedurale e non come esercizio di bilanciamento sostanziale, necessario alla luce di una valutazione sui diritti fondamentali. Occorre inserire maggiore attenzione alla FRIA che è ora trascurata.
b. Responsabilità: sarebbe opportuno individuare scenari concreti, specie alla luce della possibilità di cambi di ruolo legati all’utilizzo del sistema di IA (ad es. fine tuning). Vi veda l’art. 25 dell’AIA che impone un cambio di ruolo in caso di contributo rilevante alla personalizzazione di sistemi IA forniti dal produttore.
c. Sovranità: Non vi è sufficiente attenzione alla sovranità delle infrastrutture e dei dati. Vi è attenzione per i dati personali, ma non per il valore che i dati della PA rappresentano per la tenuta democratica di un paese.
d. Informativa privacy: sarebbe opportuno valutare gli obblighi di informativa (para 7.2) inquadrando meglio l’art. 86 AI Act sul diritto alla spiegazione, nello specifico decisioni non automatizzate ma supportate da sistemi di IA.
2. Punto 2.4 Famiglie di sistemi di IA –
a. GPAI: In merito ai sistemi GPAI a rischio sistemico occorre approfondire. La PA, in genere, non li sviluppa, ma sarebbe opportuno valutare in che modo gli obblighi del fornitore di sistemi GPAI ad alto rischio si interfaccino con l’attività della PA. Nelle Linee Guida sul Procurement è previsto un meccanismo di verifica, ma nulla si dice sull’accesso ad elementi che caratterizzano il modello, anche tutelati dalla proprietà intellettuale. Ci sono obblighi di trasparenza della PA che potrebbero entrare in contrasto con la proprietà intellettuale.
b. Neuro-simboliche: Le famiglie di IA non includono la categoria di sistemi basati su tecnologie neuro-simboliche.
3. Punto 3.4 Ruolo del dato nello sviluppo dei sistemi di IA -
a. Confidenzialità dei dati della PA: Occorre pensare anche ai dati strategici e ai segreti d’ufficio. Occorre richiedere che tali dati siano on-prem o quanto meno in cloud entro i confini europei e sotto lo stretto controllo della PA. Vi sono segreti d’ufficio e dati confidenziali che devono richiedere necessariamente un trattamento particolare in caso vengano utilizzati modelli GPAI di vendor.
b. IPR: Non vi è sufficiente attenzione alla tutela della proprietà intellettuale dei dati della PA forniti ai modelli LLM o di GenAI quando questi contribuiscono al training o entrano a far parte del modello. Occorre maggiore attenzione su questo punto e spingere verso modelli on-prem, open source, add estrati con SML.
c. Contaminazione legal-concettuale. Alcuni modelli LLM pre-trained sono fortemente indirizzati a concetti giuridici non vicini alla tradizione legale italiana, con forte “contaminazione” linguistica specialistica di altre culture (specie quella inglese e di common law). Non vi è nulla su questo punto volto a mitigare la possibile contaminazione culturale che può avvenire nelle nostre PA.
4. Sicurezza della tenuta amministrativa - Applicazioni in ambito Giustizia e Banche dati giuridiche: sarebbe utile fare un approfondimento per le banche dati giuridiche e per i sistemi della giustizia. L’utilizzo di chatbot IA in questi contesti potrebbe essere particolarmente delicato. Studi rilevanti dimostrano come l’utilizzo di chatbot o agentic AI generalisti applicati in modo grossolano a task di information retrieval di banche dati giuridiche porti a confermare le richieste dell’utente che in questo modo troverebbe materiali parziali aderenti alle proprie ricerche senza un approccio controfattuale e critico. In sintesi, solitamente i chatbot sono assecondanti le richieste dell’utente e persuasivi della correttezza della risposta adeguandosi alla conversazione dell’utente. Esempio: dammi tutte le leggi che supportano gli impianti fotovoltaici. Questa richiesta se fornita ad un agente AI generalista o a un chatbot di GENAI generico fornisce solo le leggi a supporto e non quelle che forniscono le eccezioni, i limiti, le condizioni al contorno, illudendo così l’utente (se non addirittura persuadendolo) dell’esaustività della risposta. Questi fenomeni noti come mirroring, sycophancy, echo chamber, confirmation bias, user-assistant bias sono pericolosi, senza una adeguata valutazione e mitigazione dei rischi, se forniti in combinazione a banche dati giuridiche offerte alla PA o dalle PA ai cittadini o agli stessi impiegati dell’amministrazione.
Si propone di rafforzare la sezione relativa all’ambito di applicazione chiarendo in modo esplicito il perimetro dei sistemi oggetto delle Linee Guida anche dal punto di vista del procurement, al fine di evitare ambiguità interpretative nella fase di gara. L’attuale formulazione, pur corretta sul piano generale, non distingue in modo operativo tra sistemi di Intelligenza Artificiale ai sensi dell’AI Act e soluzioni software tradizionali, con il rischio di estendere obblighi non proporzionati o, al contrario, di non applicare adeguate garanzie a sistemi GPAI. Si suggerisce pertanto di introdurre l’obbligo per le stazioni appaltanti di classificare preventivamente ogni sistema secondo la tassonomia del Regolamento (UE) 2024/1689 e di documentare tale classificazione negli atti di gara, rendendola parte integrante del fascicolo tecnico e dei criteri di valutazione. Tale integrazione consentirebbe maggiore certezza giuridica, omogeneità tra amministrazioni e maggiore coerenza con il quadro normativo europeo.
Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.