La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 5. Strumenti di procurement e cooperazione tra PA.
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).
La presente osservazione è da leggersi nel contesto complessivo, argomentato nel seguente position paper: [ https://www.huandroid.com/wp-content/uploads/2026/03/PositionPaper_Linee_Guida_AGID.pdf ] (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.
Le Linee Guida per il Procurement pongono giustamente l’accento su sostenibilità, controllo e mitigazione del lock-in. Tuttavia, per tradurre questi principi in pratica, è necessario introdurre criteri premiali espliciti per le architetture che garantiscono sovranità del dato e neutralità infrastrutturale.
Riferimenti AgID:
Linee Guida Sviluppo: Cap. 6 (Neutralità hardware, acceleratori e portabilità dei sistemi di IA)
Linee Guida Procurement: Par. 3.5 (Impatti delle scelte architetturali su costi, controllo e rischio), Par. 5.3 (Gare per l’approvvigionamento)
Criticità rilevata:
Le Linee Guida per lo Sviluppo introducono encomiabilmente i principi di neutralità hardware, portabilità e ottimizzazione per CPU (Cap. 6). Viene riconosciuta la valenza strategica della riduzione del lock-in e della possibilità di esecuzione su infrastrutture eterogenee. Tuttavia, le Linee Guida per il Procurement non traducono ancora questi principi in criteri premiali espliciti nelle procedure di gara. Soluzioni che garantiscono ex ante la portabilità, l’efficienza energetica e la riduzione della dipendenza da cloud provider terzi (soluzioni local-first, on-premise ottimizzate, architetture a costo marginale decrescente) non vengono adeguatamente valorizzate.
Il concetto di Santuario Cognitivo (ambiente digitale protetto, local-first, sotto il pieno controllo dell’Architetto pubblico) è una risposta architetturale a questa esigenza, in piena coerenza con i principi di neutralità hardware già enunciati. Inoltre, le architetture local-first proposte (Santuario Cognitivo) trovano nella infrastruttura del Polo Strategico Nazionale il naturale alleato tecnologico. Le Linee Guida dovrebbero valorizzare il PSN non solo come cloud dei dati, ma come ecosistema abilitante per la Sovranità Cognitiva, premiando le soluzioni IA che ne utilizzano le potenzialità di controllo pubblico, neutralità hardware e sovranità del dato.
Proposta:
Inserire, nei criteri di aggiudicazione del procurement, elementi premiali espliciti per le soluzioni che dimostrano di aderire ai principi di neutralità hardware e portabilità, e che offrono garanzie di eseguibilità in ambienti on-premise o a controllo pubblico. L’integrazione può anche fare riferimento esplicito al Par. 3.5 di Procurement, dove si parla di “impatti delle scelte architetturali su costi, controllo e rischio”, per legare i criteri premiali all’analisi dei rischi (cfr. Par. 6.4 “esempi di clausole” come base per i criteri premiali).
Testo proposto per integrazione del punto elenco para 5.3 - Gare per l’approvvigionamento di sistemi IA (a pag.94):
“[…]
• il grado di trasparenza e spiegabilità della soluzione proposta;
• la facilità di integrazione con l’ecosistema digitale dell’amministrazione.
• la neutralità hardware e la portabilità, misurate dalla capacità della soluzione di operare su infrastrutture eterogenee;
• l’adozione di architetture local-first o ibride a controllo pubblico e realizzazione del principio del Santuario Cognitivo;”
Analisi ([cfr. Allegato, Cap.6]): Il Polo Strategico Nazionale (PSN) offre l’infrastruttura per realizzare “Santuari Cognitivi” sotto controllo pubblico. La neutralità hardware (Cap.6 LLGG Sviluppo) deve essere tradotta in criteri premiali nelle gare, in coerenza con l’obbligatorietà dei CAM.
Il CSIG (Centro studi di informatica giuridica di Ivrea e Torino, con riferimento agli obblighi di conformità alla NIS2 e ai provvedimenti di ACN suggerisce di prevedere che l’amministrazione, anche quando fa ricorso a servizi resi da terzi, deve assicurare una mappatura diretta tra le tassonomie di attacco e le “Buone pratiche” del paragrafo 5.7. A tal fine si indicano le seguenti azioni:
· Modellazione delle minacce (5.6.1): Identificazione dei punti di fallimento specifici negli input; validazione rigorosa dei vettori di attacco.
· Documentazione e Qualità dei Dati (5.6.5): Tracciabilità end-to-end della supply chain dei dati; audit sulla provenienza e integrità dei dataset di training.
· Analisi del Codice (5.6.2): Esecuzione di analisi statica e dinamica (SAST/DAST) focalizzata sulla prevenzione di data leakage via API.
· Security by Design (5.6.4): Implementazione di meccanismi di controllo degli accessi e segregazione dei ruoli lungo l’intero Stack.
· Approccio basato sul rischio (Principio 3 e Par. 5.2): deve tradursi in clausole contrattuali precise (Par. 6.4) prevedendo l’obbligo di esigere, in fase di gara, evidenze documentali su DPIA (valutazione d’impatto sulla protezione dei dati) e FRIA (valutazione d’impatto sui diritti fondamentali) per i sistemi ad alto rischio, evitando la coesistenza forzata tra dati pubblici e modelli proprietari opachi.
Infine, si segnala una lacuna riguardo agli obblighi di Notifica: la bozza non specifica la finestra di notifica di 72 ore (o i termini più stringenti per le pre-notifiche) prevista dal D.Lgs. 138/2024. Al riguardo si ritiene che le PA dovrebbero integrare autonomamente questo requisito nei protocolli di gestione incidenti per evitare sanzioni e garantire il coordinamento nazionale
5.4 Interoperabilità e cooperazione tra amministrazioni - Aggregazioni di acquisto e sistema a rete del procurement pubblico
Rif: “Le aggregazioni di acquisto tra amministrazioni, e in particolare le centrali regionali e provinciali, costituiscono una leva strategica per rafforzare l’efficienza del procurement pubblico e migliorare la sostenibilità della spesa, soprattutto in ambiti caratterizzati da elevata complessità tecnologica e da dinamiche di mercato in rapida evoluzione quali i sistemi di Intelligenza Artificiale“
L’aggregazione della domanda produce benefici solo quando sussistono contemporaneamente i seguenti presupposti:
· la prestazione è sufficientemente standardizzabile da poter essere definita in modo uniforme per più committenti (pertanto, i fabbisogni degli enti aggregati sono sufficientemente omogenei da non richiedere personalizzazioni sostanziali che annullino i vantaggi delle economie di scala);
· il mercato è maturo e concentrato in fornitori di grandi dimensioni.
Nel settore AI nessuna di tali condizioni si verifica pienamente, essendo ogni sistema AI contestuale, dipendente dai dati specifici dell’amministrazione, dall’architettura dei sistemi informativi preesistenti, dalle sue competenze interne, dal suo livello di maturità digitale.
In tale contesto, peraltro, aggregare la domanda rischia di avvantaggiare ulteriormente i pochissimi operatori che hanno la dimensione per rispondere a gare aggregate riducendo di fatto la concorrenza anziché aumentarla e creando concentrazioni di mercato.
5.3 Gare per l’approvvigionamento di sistemi di IA
Rif: “… la Pubblica Amministrazione è chiamata ad adottare un approccio evoluto alla predisposizione della documentazione di gara, superando modelli standardizzati mutuati da altre tipologie di forniture ICT” attraverso un “ripensamento delle modalità attraverso cui il fabbisogno viene tradotto in requisiti di gara“
Tali principi correttamente enunciati sono poi purtroppo quasi sconfessati quando di parla dei criteri di aggiudicazione e di valutazione della qualità (si ricade infatti nell’approccio precedentemente stigmatizzato di non valutare la prestazione ma solo aspetti tecnologici - qualità architetturale, sostenibilità economica, ciclo di vita, capacità evolutiva, ecc. - su cui difficilmente la PA ha competenze e soprattutto che molto spesso non sono in connessione diretta con la qualità effettivamente erogata).
In tale merceologia, l’IA, ove la definizione del fabbisogno deve essere orientata ai risultati e alle prestazioni attese anziché a specifiche tecnologiche rigide e prescrittive, la comparazione tra offerte in una gara pubblica non dovrebbe avere ad oggetto le tecnologie usate come mezzo ma la capacità di conseguire l’obiettivo della stazione appaltante e la misura in cui esso è raggiunto. In altre parole, non si valutano promesse non verificabili ma prestazioni concrete che possono essere disciplinate come livelli di servizio nel contratto e tutelate da penali.
Segnaliamo le nostre proposte, puntualmente riferite ad alcuni passaggi.
Cordialmente
Paragrafo 5.2 - Pag 81 TABELLA 9
Tabella 9, Riga 3 – Monitoraggio: è utile aggiungere un riferimento esplicito alle metriche di ‘Fairness’ e ‘Bias Detection’ come requisito tecnico da capitolato. Rafforzare il concetto con terminologia tecnica standard per garantire che la prevenzione dei bias sia misurabile e non solo dichiarativa.
Paragrafo 5.3 - Pag 82
Vale la pena ribadire che ogni fase del ciclo di vita di un sistema, inclusi quelli basati su IA, deve rispettare i vincoli previsti dal Codice dei Contratti Pubblici, dalle procedure di procurement tramite MEPA e dai relativi capitolati tecnici. Tali vincoli definiscono non solo cosa deve essere realizzato, ma anche come deve essere progettato, acquisito, gestito e dismesso, garantendo tracciabilità, trasparenza e conformità normativa lungo l’intero ciclo di vita. È utile citare detti vincoli dati dalla normativa nazionale ed europea: Codice dei Contratti Pubblici (D.Lgs. 36/2023), MEPA e strumenti Consip, ISO/IEC 42001, per i sistemi di IA, il quadro è completato dal Regolamento Europeo sull’Intelligenza Artificiale (AI Act), che stabilisce requisiti specifici per i sistemi ad alto rischio, e dagli standard internazionali ISO/IEC relativi a sicurezza, governance, qualità e sostenibilità. Infine, le norme sulla conservazione, migrazione e dismissione dei sistemi impongono alle amministrazioni di garantire la corretta gestione del patrimonio informativo pubblico lungo tutto il ciclo di vita, fino alla chiusura e alla cancellazione sicura dei dati.
Paragrafo 5.3 - Pag 87
In considerazione dell’importanza della normativa (AI Act) sui diritti fondamentali, le metriche di equità devono essere esplicitate nel monitoraggio delle prestazioni. Sarebbe quindi opportuno aggiungere anche le metriche di ‘Fairness’ (es. Disparate Impact, Equal Opportunity Difference) all’elenco dei parametri da monitorare.
Paragrafo 5.3 - Pag 88
Tra le “Clausole evolutive e gestione del cambiamento tecnologico” è opportuno aggiungere: ‘Clausole di exit strategy e reversibilità dei dati e dei modelli (ove di proprietà della PA)’ nell’elenco. La gestione del ‘cambiamento’ deve includere anche la fase di fine contratto per evitare il lock-in, non solo l’aggiornamento tecnologico.
Paragrafo 5.3 - Pag 92 TABELLA 10
Nella riga “Requisiti tecnici” casella “Favorire l’accesso al mercato e la neutralità tecnologica” è opportuno specificare “Richiedere, ove possibile, l’utilizzo di formati standard aperti per l’interscambio dei modelli (es. ONNX)”. La proposta intende rendere concreto il principio di neutralità tecnologica citando standard di fatto che facilitano la portabilità dei modelli.
Paragrafo 5.3 - Pag 96
Nell’ultimo capoverso, è utile aggiungere un riferimento alla qualificazione delle stazioni appaltanti (artt. 62-63 D.Lgs. 36/2023) necessaria per gestire gare ad alta complessità tecnologica. Ciò è fondamentale ricordare che per appalti complessi di IA è necessaria una stazione appaltante qualificata per livelli adeguati.
Paragrafo 5.4 – Pag 97
Accanto all’interoperabilità, anche il riuso rappresenta uno dei principi cardini del Codice dell’Amministrazione Digitale e della normativa a esso collegata. Le Pubbliche Amministrazioni sono tenute a privilegiare soluzioni già disponibili, condivise o riusabili, prima di procedere allo sviluppo o all’acquisizione di nuovi sistemi. Questo principio non è solo un orientamento strategico, ma un obbligo operativo che richiede di valutare, documentare e motivare le scelte tecnologiche. In tale prospettiva, nell’ambito di una gara pubblica il riuso dovrebbe essere esplicitamente dichiarato e verificato, indicando se esistono componenti, moduli, piattaforme o servizi già disponibili nel patrimonio pubblico o nel catalogo nazionale, e come essi possano essere integrati. Una corretta declinazione del principio di riuso contribuisce a ridurre costi, evitare duplicazioni, garantire coerenza architetturale e favorire la sostenibilità complessiva del sistema informativo pubblico.
Paragrafo 5.4 – Pag 103 TABELLA 11
Nello scenario “Mercati emergenti o poco maturi “- nella cella “Consultazioni di mercato congiunte” si propone di sostituire o integrare le consultazioni di mercato con il ‘Partenariato per l’innovazione’ (PPI) o ‘Appalti pre-commerciali’ (PCP). La consultazione di mercato é una fase preliminare, non uno strumento di affidamento. Per mercati immaturi, gli strumenti corretti per l’acquisto sono PCP o PPI.
Contributo a cura della Taskforce IA dell’Autorità Nazionale Anticorruzione (ANAC)
Il capitolo, pur rivestendo un ruolo centrale, appare ancora prevalentemente descrittivo e non fornisce un adeguato supporto operativo alle PA nella predisposizione delle procedure di gara per sistemi di IA.
Si rileva in particolare la carenza di strumenti pratici quali modelli di capitolato standard in base ai diversi modelli di deployment (API, Cloud-hosted, Self-hosted, Ibrido), esempi di criteri di valutazione e indicatori con range di riferimento. Tale carenza rischia di rendere difficoltosa l’applicazione concreta dei requisiti, soprattutto per le amministrazioni con minore maturità digitale.
Inoltre, si ritiene opportuno integrare nel set documentale di gara, accanto ai tradizionali indicatori di servizio (SLA) e di prestazione (KPI), una sezione dedicata ai Key Value Indicators (KVI). In particolare i KVI dovrebbero monitorare il valore pubblico generato, includendo parametri relativi alla fiducia, all’equità, alla riduzione dei bias e alla trasparenza verso il cittadino. L’adozione dei KVI permetterebbe anche di valutare l’impatto dell’IA come strumento conforme ai principi definiti dall’AI Act e dalla legge nazionale in materia di intelligenza artificiale.
Posizione dell’associazione InnovUp
A pag. 85 del documento (Paragrafo 5.3 Gare per l’approvvigionamento di sistemi di IA) si dice: “il capitolato non può essere concepito come un mero elenco di specifiche tecnologiche, ma deve configurarsi come uno strumento di governo della soluzione lungo l’intero ciclo di vita contrattuale. Una redazione inadeguata può infatti determinare rigidità incompatibili con l’evoluzione tecnologica oppure, al contrario, generare ambiguità che rendono difficoltosa la verifica dell’adempimento”; formulato così il concetto, esiste il rischio che il capitolato si trasformi da una descrizione puntuale dei servizi/forniture che la stazione appaltante si aspetta (e sul quale gli aspiranti appaltatori possono formulare un’offerta consapevole e gestibile) ad un “elenco aperto”, a disposizione dell’Amministrazione per ampliare indiscriminatamente l’ambito oggettivo del contratto e richiedere agli appaltatori prestazioni aggiuntive, non prevedibili e non prezzate.
Si tratta di un rischio da governare, anche consentendo interlocuzioni preventive con le stazioni appaltanti come è stato già proposto, o incentivando lo strumento del dialogo competitivo. Una eventuale flessibilità del capitolato dovrebbe inoltre essere accompagnata da idonei meccanismi di adeguamento del prezzo.
Inoltre, in più punti si sottolinea l’importanza della raccolta dei dati: a questo proposito, è auspicabile studiare meccanismi di data-pooling tra diverse amministrazioni, che consentano di condividere dati in maniera protetta e legale ed aiutino ad avere più materiale di qualità per addestrare i modelli (sul modello magari delle banche dati centralizzate quali la Piattaforma Digitale Nazionale Dati che nel settore degli appalti alimenta il Fascicolo Virtuale dell’Operatore Economico).
A pagina 99 (Paragrafo 5.4 Interoperabilità e cooperazione tra amministrazioni),le Linee Guida suggeriscono di valutare aggregazione di acquisto soprattutto per amministrazioni centrali regionali e provinciali. Questo approccio, tuttavia, pur assicurando una razionalizzazione della spesa pubblica potrebbe risultare meno coerente con quanto le stesse Linee Guida ripetono, in più punti, in merito alla necessità di procedere ad acquisti fondati sugli specifici fabbisogni dell’ente. Una soluzione mediana potrebbe allora essere quella di suggerire aggiudicazioni multi-operatore e con una successiva fase in cui le Amministrazioni trasmettono il proprio “progetto dei fabbisogni” e gli aggiudicatari (sulla base di quanto offerto in gara) propongono le loro soluzioni tecniche. In passato questo schema è stato seguito, ad esempio, per il sistema pubblico di connettività (SPC).
Infine, le Linee Guida si preoccupano di segnalare il rischio di lock-in. Le stesse preoccupazioni dovrebbero però condurre anche a disciplinare il rischio che - a prescindere dal lock-in tecnologico - il fornitore uscente possa acquisire un vantaggio competitivo irreplicabile in vista di una successiva gara. Anche questo è un rischio che nel settore ICT si è verificato spesso. Andrebbe, quindi, attentamente considerata anche la necessità di poter disporre, a conclusione dell’affidamento, l’accesso alle informazioni necessarie per la predisposizione della nuova gara e per assicurare la competitività delle gare successive.
Il Comitato Scientifico dell’Osservatorio sull’Intelligenza Artificiale nelle Pubbliche Amministrazioni presenta le seguenti osservazioni:
Par 5.3 — Gare per l’approvvigionamento di sistemi di IA
Il documento richiede clausole di adeguamento normativo senza fornire criteri operativi per distinguere adeguamenti ordinari — a carico del fornitore — da adeguamenti straordinari — soggetti a revisione economica. Nel contesto IA, dove il quadro normativo evolve rapidamente, questa indeterminatezza rende impossibile il pricing di contratti pluriennali e disincentiva i contratti lunghi che la PA stessa auspica per garantire continuità del servizio. Si propone di ancorare la distinzione ai meccanismi di revisione già previsti dal D.Lgs. 36/2023, con esempi orientativi che distinguano l’adeguamento ordinario (es. aggiornamento di formati o interfacce) dall’adeguamento straordinario (es. nuovi obblighi di certificazione introdotti da norme sopravvenute).
Si segnala infine che la strutturazione del capitolato per componenti del sistema di IA, con livelli di servizio e metriche di prestazione differenziati per ciascuna componente. può costituire un elemento di complessità che ostacola indirettamente la partecipazione alle gare, in particolare – ma non esclusivamente – per le imprese di minori dimensioni. Si raccomanda che le Linee Guida prevedano criteri di aggregazione e semplificazione del capitolato che non trasformino la granularità tecnica dei requisiti in una barriera all’ingresso de facto, in coerenza con il principio di proporzionalità già enunciato nel documento.
Contributo a cura di Traent Srl.
Si propone di integrare il Capitolo 5 “Strumenti di procurement e cooperazione tra PA” con la previsione di un’infrastruttura federata di fiducia per la cooperazione inter-amministrativa. Il §5.1 riconosce che «la capacità di selezionare strumenti di procurement adeguati rappresenta una condizione essenziale affinché l’adozione dell’Intelligenza Artificiale nella Pubblica Amministrazione avvenga in modo sostenibile, governabile e coerente con l’interesse pubblico» (pag. 77), ma non specifica quale infrastruttura possa abilitare la cooperazione in condizioni di fiducia reciproca. Si chiede l’istituzione di un Trust Registry nazionale dove le PA possano registrare e consultare certificazioni di conformità, esiti degli audit e evidenze di portabilità già verificate da altre amministrazioni, integrato con la PDND. Si propongono inoltre meccanismi di Conditioned Transparency per la condivisione selettiva delle evidenze con le sole PA autorizzate, tutelando le informazioni commercialmente sensibili.
Infine, si propone di integrare la Tabella 10 del §5.3 (pagg. 92-93), che individua 12 sezioni del capitolato tecnico con relative finalità e rischi mitigati, con una tredicesima sezione denominata «Infrastruttura di fiducia e verificabilità». Il §5.3 afferma che «il capitolato non può essere concepito come un mero elenco di specifiche tecnologiche, ma deve configurarsi come uno strumento di governo della soluzione lungo l’intero ciclo di vita contrattuale» (pag. 85). Nessuna delle 12 sezioni prevede un’infrastruttura indipendente per la certificazione della conformità. Si propone una sezione con: definizione dell’infrastruttura di notarizzazione crittografica, protocolli di verifica indipendente, marcatura temporale delle milestone contrattuali. La finalità è di rendere verificabile in modo non ripudiabile ogni elemento rilevante dell’esecuzione. Rischi mitigati: autoreferenzialità delle dichiarazioni, inefficacia degli audit manuali, costo del contenzioso. In alternativa, i contenuti potrebbero essere distribuiti nelle sezioni “Monitoraggio e reporting” e “Sicurezza e conformità normativa”.
Questo argomento è stato automaticamente chiuso dopo 26 giorni. Non sono permesse altre risposte.