La consultazione pubblica è attiva dal 12/03/2026 al 11/04/2026.
Questo argomento accoglie i commenti relativi al capitolo 3. Come acquisire 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).
Nel paragrafo 3.8 “Gestione del rischio”, aggiungere un inciso su:
“la gestione del rischio deve includere la valutazione dell’impatto su gruppi vulnerabili e rischi discriminatori, in coerenza con l’AI Act”. (non viene esplicitato nel documento in consultazione, ub riferimento alla classificazione del rischio dell’AI Act, che ha come obiettivo primario la tutela dei diritti fondamentali e delle persone vulnerabili. Questo punto è cruciale perché l’inclusività non è solo un “valore etico”, ma un obbligo regolatorio derivante dalla norma UE)
marieva favoino - Forum Governo Aperto e FID
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 par.3.5 (impatti delle scelte architetturali…pag 31):
**
"[…] Al contrario, soluzioni monolitiche o opache riducono significativamente la capacità di controllo pubblico e possono compromettere la possibilità di garantire trasparenza e rendicontabilità dell’azione amministrativa.
In coerenza con i principi di neutralità hardware e portabilità enunciati nel Capitolo 6 delle Linee Guida per lo Sviluppo, le scelte architetturali devono essere valutate anche in funzione della loro capacità di tradurre tali principi in criteri operativi per il procurement. In particolare, nei criteri di aggiudicazione (cfr. Par. 5.3) dovrebbero essere previsti elementi premiali per le soluzioni che:
- garantiscano l’eseguibilità su infrastrutture hardware eterogenee senza perdita di funzionalità essenziali (fallback);
- adottino architetture local-first o ibride a controllo pubblico, riducendo la dipendenza da singoli fornitori cloud e minimizzando i rischi di lock-in economico e tecnologico (principio del Santuario Cognitivo);
- documentino l’efficienza energetica e l’ottimizzazione dei consumi in relazione ai carichi di lavoro previsti.
Tali requisiti, che realizzano il principio di sovranità del dato e controllo pubblico sull’infrastruttura, dovrebbero essere valutati nell’ambito
dell’offerta economicamente più vantaggiosa, contribuendo alla sostenibilità di lungo periodo dell’investimento pubblico."
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 al punto 3.4 Ruolo del dato nel procurement, suggerisce di integrare il principio di protezione dei dati personali prevedendo:
· Lo sviluppo DEVE includere la Privacy by Design specifica per il contesto lavorativo. È fatto assoluto divieto di implementare funzionalità di monitoraggio costante e personalizzato. I dati identificativi dei lavoratori DEVONO essere pseudonimizzati nei log di sistema, rendendoli accessibili solo per motivate esigenze di sicurezza informatica.
Inoltre, segnala che la specificità normativa italiana (Artt. 4 e 8 L. 300/1970) richiederebbe i seguenti interventi correttivi:
· Definizione restrittiva di “Dati in Esercizio” (sez. 3.4.2) per escludere dati individuali
· Obbligo di coinvolgimento sindacale nella validazione (sez. 4.4)
· Divieto contrattuale di analisi predittiva della performance individuale
· Trasparenza sulla logica algoritmica dell’Orchestratore
Osservazioni al par. 3.1 – Avvocatura ACER Campania
Contribuisco alla consultazione dalla prospettiva dell’avvocatura interna di un ente pubblico che gestisce edilizia residenziale pubblica e che attraversa quotidianamente tutte le fasi del ciclo contrattuale, dalla programmazione al contenzioso. Il par. 3.1 costruisce un impianto principiologico coerente, ma presenta a mio avviso un limite ricorrente: i principi enunciati non trovano, nel documento, sufficiente traduzione operativa. Segnalo quattro punti specifici.
1. Responsabilità amministrativa e Corte dei conti (par. 3.1, principio di responsabilità)
Il documento afferma correttamente che la PA mantiene la titolarità delle decisioni e non può delegarla al sistema di IA. Ma non dice nulla su come questa titolarità si raccordi con il regime della responsabilità contabile. Quando un sistema di IA partecipa — anche solo a supporto — a un procedimento con effetti patrimoniali, il perimetro della colpa grave del funzionario è tutt’altro che definito. Le linee guida dovrebbero indicare almeno come documentare il processo decisionale assistito dall’IA, in modo da rendere verificabile ex post il rispetto della supervisione umana. Non si tratta di un’esigenza teorica: è il presupposto pratico della responsabilità, specie in sede di sindacato contabile.
Proposta: integrare il principio con un richiamo alla necessità di adottare, già in fase di procurement, strumenti di documentazione del processo decisionale che consentano di dimostrare che il sistema è stato usato come ausilio e non come sostituto della volontà amministrativa.
2. Tracciabilità del fornitore senza conseguenze contrattuali (par. 3.1, principio di trasparenza)
Il documento afferma che la tracciabilità deve consentire all’amministrazione di comprendere e verificare il comportamento del sistema. Condivisibile. Ma non dice cosa succede quando il fornitore non garantisce questa tracciabilità. Nessuna indicazione su risoluzione, penali, obbligo di integrazione tecnica. E nessun rinvio puntuale allo Strumento B che indichi dove questa materia viene disciplinata. L’esperienza dell’avvocatura interna insegna che i principi delle linee guida di settore, senza traduzione in clausole azionabili, restano privi di effettività.
Proposta: indicare esplicitamente nel par. 3.1 che i principi trovano traduzione obbligatoria in clausole tipizzate, con rinvio preciso allo Strumento B, e integrare quest’ultimo con una casistica minima di inadempimento differenziata per tipologia di sistema.
3. Meccanismi di fallback e continuità del servizio pubblico (par. 3.1, principio di controllo)
Il fallback è trattato come opzione tecnica. Per le amministrazioni che gestiscono servizi essenziali — tra cui l’edilizia residenziale pubblica, che eroga prestazioni a soggetti in condizione di fragilità — non è una scelta opzionale: incide sugli obblighi di servizio universale e sulle responsabilità da interruzione del servizio. Il documento non chiarisce se la previsione contrattuale del fallback sia clausola essenziale o elemento migliorativo, lasciando alle stazioni appaltanti un margine che rischia di produrre soluzioni disomogenee.
Proposta: introdurre una distinzione esplicita tra servizi ad elevato impatto sociale e servizi a impatto ordinario, stabilendo che per i primi il fallback contrattuale adeguato è requisito minimo, non elemento opzionale.
4. Proporzionalità senza strumento documentale (par. 3.1, principio di proporzionalità)
Il documento dice che sistemi ad alta complessità e bassa spiegabilità richiedono benefici chiaramente motivati. Giusto — ma non indica in quale atto formale questa motivazione debba essere documentata. Nell’ordinamento dei contratti pubblici la motivazione delle scelte tecniche è già presidio di legittimità, sindacabile in sede giurisdizionale. La scelta di un sistema opaco dovrebbe trovare traccia in un atto preciso — ad esempio nel documento di analisi preliminare ex art. 15 D.Lgs. 36/2023 — che renda tracciabile la valutazione di proporzionalità.
Proposta: prevedere che la valutazione di proporzionalità per sistemi ad elevata complessità sia documentata in atto formale integrabile nell’analisi preliminare ex art. 15 D.Lgs. 36/2023, con indicazione della comparazione tra alternative, del livello di rischio atteso e dei benefici pubblici attesi.
Il limite principale del par. 3.1 non è nell’impianto — che è coerente — ma nel suo grado di azionabilità. I principi enunciati rischiano di produrre un effetto di legittimazione formale delle scelte, qualunque esse siano, se non trovano negli strumenti allegati una traduzione procedurale e contrattuale sufficientemente dettagliata. Il punto critico è la tenuta dei principi nel corso del ciclo contrattuale: nell’esecuzione, nel contenzioso, nel sindacato degli organi di controllo.
Avvocatura ACER – Agenzia Campana per l’Edilizia Residenziale Avv. Francesco Russo – Avvocato cassazionista
Contributo alla consultazione pubblica – Sezione 3.1 - Paragrafo Cybersecurity nel Procurement di IA nella PA - Centro Studi Paul H. Appleby per l’etica e l’amministrazione democratica
Contributo di: Mauro Alovisio, Alberto Culatina e Massimo Poletti
Nel complimentarci per l’iniziativa, si riportano alcune osservazioni in ambito cybersicurezza
Il capitolo 3.1 offre un inquadramento tassonomico accurato delle minacce ai sistemi IA, ma non colma il divario operativo che separa le stazioni appaltanti, in particolare quelle prive di CISO o strutture tecniche dedicate (cfr. art. 8 D.Lgs. 138/2024), dalla capacità effettiva di tradurre tali indicazioni in requisiti di gara e clausole contrattuali.
Si suggerisce nell’ottica migliorativa di prevedere: (i) una checklist pre-audit articolata per fase del ciclo di vita del sistema IA (progettazione, addestramento, deployment, dismissione), coerente con l’approccio risk-based del Reg. UE 2024/1689, artt. 9-15; (ii) un set minimo di clausole contrattuali di sicurezza in formato editabile, allineato agli obblighi di gestione del rischio della catena di approvvigionamento ex art. 21 Dir. NIS2; (iii) una matrice di mappatura rischio/requisito contrattuale collegata agli obiettivi di cui alla sezione 3.1.3, che consenta ai RUP di verificare la completezza dei capitolati tecnici.
Si propone di integrare il capitolo con almeno un allegato tecnico-operativo, sul modello dei playbook NIST AI RMF o delle schede operative ENISA, calibrato sulla capacità amministrativa media degli enti pubblici italiani e coerente con gli obblighi di sicurezza già previsti dal CAD (artt. 50-bis e 51) e dalle Misure Minime di Sicurezza AgID: si tratta di strumenti operativi pronti all’uso che sarebbero apprezzati anche dalle medie e piccole amministrazioni.
Si propone di richiamare l’attenzione sull’obbligo di prevedere nei bandi articoli sugli obblighi di segnalazione degli incidenti AI alle autorità di riferimento e nel caso di trattamenti di dati anche all’autorità Garante per la protezione dei dati personali, nonché l’obbligo di documentare gli incidenti ivi comprese le cause, i rimedi adottati, le lezioni apprese e le conseguenti misure a lunga scadenza.
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 — Clausole sociali e valutazione dell’impatto occupazionale negli appalti di IA
Le Linee Guida per il procurement disciplinano con rigore i criteri tecnici ed economici degli appalti di sistemi di IA, ma non contengono clausole sociali né una valutazione preventiva dell’impatto occupazionale. Le PA che esternalizzano lo sviluppo di sistemi di IA possono così acquisire sistemi che modificano strutturalmente le mansioni senza che l’impatto sia stato valutato né in fase di gara né durante l’esecuzione contrattuale.
L’art. 57 del D.Lgs. 36/2023 prevede l’inserimento di clausole sociali negli appalti. L’art. 108, co. 7, del medesimo Codice consente di includere criteri di sostenibilità sociale tra i criteri di aggiudicazione. L’art. 26, par. 7, del Reg. (UE) 2024/1689 impone l’informazione preventiva a lavoratori e organizzazioni sindacali prima dell’uso di sistemi di IA ad alto rischio: questo obbligo deve riflettersi nel capitolato e nella fase di esecuzione contrattuale.
Proposta di integrazione al cap. 3:
– a) VALUTAZIONE PREVENTIVA DELL’IMPATTO OCCUPAZIONALE: prima dell’avvio della gara per sistemi di IA che incidano sull’organizzazione del lavoro, la PA DEVE produrre una valutazione che analizzi le mansioni interessate, il fabbisogno formativo generato e le ricadute sull’organizzazione del lavoro. La valutazione DEVE essere comunicata alle organizzazioni sindacali prima dell’aggiudicazione.
– b) CLAUSOLA SOCIALE NEL CAPITOLATO: i capitolati DEVONO imporre al fornitore di: fornire documentazione sulle mansioni impattate, aggiornata in caso di modifiche sostanziali; garantire il trasferimento di conoscenze tramite formazione congiunta del personale PA; non raccogliere né trasferire a terzi dati comportamentali dei dipendenti PA.
– c) CRITERI DI AGGIUDICAZIONE: nell’offerta economicamente più vantaggiosa DEVE essere attribuito punteggio premiante alle offerte che includono piani formativi per il personale e meccanismi di supervisione umana (art. 108, co. 7, D.Lgs. 36/2023).
Confintesa FP — Segretario Generale Claudia Ratti | www.confintesafp.it
§3.6.3 “Requisiti di sicurezza per l’acquisizione”, inserimento del red-teaming come voce autonoma
L’elenco dei requisiti di sicurezza per l’acquisizione copre gestione del rischio, governance dei dati, documentazione, log, trasparenza, supervisione umana, accuratezza, robustezza e cybersecurity, lista delle operazioni autorizzate per gli agenti e controllo di emergenza. Non è però previsto, come voce autonoma, il red-teaming dei sistemi di IA. Questa assenza è rilevante, perché il red-teaming costituisce oggi la modalità di verifica specificamente progettata per intercettare le vulnerabilità peculiari dei sistemi di IA generativa e agentica, e non è sostituibile dalla sola enunciazione generale di accuratezza, robustezza e cybersecurity. La stessa OWASP GenAI Red Teaming Guide descrive il red-teaming come valutazione strutturata del sistema su quattro aspetti distinti, cioè model evaluation, implementation testing, system evaluation e runtime analysis, e non come semplice controllo astratto di robustezza.
La formulazione attuale del §3.6.3 lascia quindi il red-teaming alla discrezionalità del fornitore o della singola amministrazione, senza trasformarlo in attività esigibile in fase di collaudo o durante l’esecuzione. L’effetto pratico è che sistemi di IA, anche generativi o agentici, possono essere acquisiti senza una verifica avversariale strutturata della loro resistenza a prompt injection, guardrail bypass, abuso dei tool, data leakage, model extraction o vulnerabilità RAG.
Raccomandazione: integrare i “Requisiti di sicurezza per l’acquisizione” del §3.6.3 con una voce autonoma dedicata al red-teaming dei sistemi di IA, formulata in modo proporzionato al rischio e almeno nei seguenti termini:
(a) Red-teaming pre-collaudo, come condizione di accettazione per i sistemi di IA generativa, agentica, RAG, o comunque per sistemi che incidono su procedimenti amministrativi sensibili, diritti o dati critici. L’attività deve essere eseguita prima della messa in esercizio da un soggetto terzo qualificato, selezionato secondo requisiti di indipendenza, competenza specialistica, metodologia documentata e assenza di conflitti di interesse, da disciplinare nel paragrafo dedicato ai fornitori di servizi di red-teaming. Il collaudo positivo dovrebbe essere subordinato almeno all’assenza di vulnerabilità critiche non mitigate e alla definizione di un piano vincolante di rimedio per le vulnerabilità di severità elevata.
(b) Red-teaming periodico in esercizio, con cadenza definita contrattualmente e proporzionata al livello di rischio del sistema.
(c) Red-teaming a evento, da condursi a ogni modifica significativa del sistema, intendendo per tale almeno: aggiornamento del modello di base, modifica del prompt di sistema o delle configurazioni dell’orchestratore, aggiunta o modifica di tool e connettori invocabili dal sistema, modifica significativa del corpus indicizzato in architetture RAG, fine-tuning del modello su nuovi dati.
(d) Ambito del red-teaming, esteso ai quattro aspetti indicati dall’OWASP GenAI Red Teaming Guide, cioè model evaluation, implementation testing, system evaluation e runtime analysis, e non limitato al solo modello isolato.
(e) Produzione di test riutilizzabili, sotto forma di suite di regressione di sicurezza o insieme strutturato di scenari e payload riproducibili, consegnati all’amministrazione e rieseguibili nelle verifiche successive.
(f) Valorizzazione economica esplicita, prevedendo il red-teaming come voce di costo dedicata lungo il ciclo di vita del contratto, coerentemente con la logica TCO/LCOAI già richiamata dal documento, così da evitare che venga compresso o eliminato in fase di gara per sole ragioni di prezzo.
§3.6.3, nuovo sottoparagrafo “Requisiti per i fornitori di servizi di red-teaming dei sistemi di IA”
La qualità del red-teaming dipende in modo critico dalla qualifica e dall’indipendenza del soggetto che lo conduce. L’OWASP GenAI Red Teaming Guide afferma espressamente che il red team identifica le vulnerabilità, mentre la remediation ricade tipicamente su blue o purple team. Questo principio supporta con chiarezza la necessità di una separazione funzionale tra identificazione dei problemi e loro rimedio. Il procurement, però, non traduce oggi questa separazione in requisiti minimi di selezione del fornitore del red-teaming.
In assenza di una disciplina dedicata, restano aperti almeno tre rischi: che il red-teaming sia svolto dal medesimo fornitore del sistema testato; che sia svolto da operatori privi di competenze specifiche in AI security; che sia affidato a soggetti la cui indipendenza di giudizio risulti compromessa da interessi economici diretti sulla remediation o sulla vendita di componenti difensive applicate al medesimo sistema. Tuttavia, una clausola che escluda in via generale tutti i fornitori che, in altri contesti, offrano anche servizi blue-team o prodotti difensivi rischierebbe di risultare eccessivamente restrittiva rispetto ai principi di accesso al mercato, approccio funzionale e neutralità richiamati nelle linee guida procurement. La soluzione più robusta è quindi imporre una forte indipendenza sull’engagement e sui conflitti di interesse, e riservare eventuali preferenze verso operatori specializzati in via esclusiva o prevalente al piano dei criteri premiali, non dei requisiti assoluti di ammissione.
Raccomandazione: inserire al §3.6.3 un sottoparagrafo dedicato ai “Requisiti per i fornitori di servizi di red-teaming dei sistemi di IA”, contenente almeno i seguenti requisiti minimi:
(a) Indipendenza dal fornitore del sistema di IA testato. Il fornitore del red-teaming deve essere giuridicamente, economicamente e organizzativamente distinto dal fornitore del sistema di IA testato e dai suoi subappaltatori. Deve essere escluso il subappalto del red-teaming al fornitore del sistema testato.
b) Assenza di conflitti di interesse sull’engagement. Il fornitore del red-teaming non deve partecipare, per il medesimo sistema e nel medesimo ciclo contrattuale, alle attività di progettazione, sviluppo, implementazione delle contromisure o fornitura dei prodotti di remediation conseguenti al test, salvo separata procedura e adeguate garanzie di incompatibilità.
(c) Competenze specifiche e documentate in AI security, distinte dalle sole competenze di cybersecurity tradizionale. Il fornitore deve dimostrare esperienza documentata su prompt injection diretta e indiretta, jailbreak, model extraction, abuso dei tool e function calling, attacchi a sistemi RAG e architetture agentiche, oltre che sui riferimenti pubblici di settore.
(d) Metodologia documentata, versionata e tracciabile, riconducibile a un framework pubblico riconosciuto. Si raccomanda l’adozione della OWASP GenAI Red Teaming Guide come riferimento metodologico, includendo almeno threat modeling AI-specifico, model reconnaissance, adversarial scenario development, prompt injection, guardrail bypass, domain-specific risk testing, knowledge/RAG testing, impact analysis e reporting.
(e) Capacità di test estesa ai quattro aspetti dell’OWASP GenAI Red Teaming Guide: model evaluation, implementation testing, system evaluation e runtime analysis.
(f) Deliverable strutturati e riproducibili, comprendenti almeno scope, threat model, scenari e payload utilizzati, risultati riferiti alla versione del sistema testato, raccomandazioni di mitigazione e set di test riutilizzabili.
(g) Gestione responsabile delle vulnerabilità rilevate, con policy documentate su riservatezza, disclosure verso l’amministrazione e il fornitore del sistema, ritenzione e cancellazione dei dati di test.
(h) Dichiarazione di assenza di conflitto di interesse, da rendere all’amministrazione contestualmente all’offerta.
Si può inoltre prevedere, come criterio premiale, la preferenza per operatori con focus specialistico esclusivo o prevalente nel red-teaming dei sistemi di IA, purché tale preferenza non si traduca in un’esclusione generalizzata e non proporzionata degli altri operatori.
N.B. Il seguente commento si colloca nel solco delle osservazioni già formulate da altri utenti nel forum sull’esigenza di rendere azionabili i principi del procurement, ma le declina specificamente sul red-teaming dei sistemi di IA.
§3.7 “Buone pratiche per il procurement lungo il ciclo di vita del contratto”, inserimento del red-teaming lungo le fasi del contratto
Le buone pratiche del §3.7 declinano il procurement dell’IA lungo le fasi del ciclo di vita del contratto, ma non prevedono in alcuna fase un riferimento esplicito al red-teaming. Questa assenza fa sì che, anche qualora il §3.6.3 venisse integrato con una previsione specifica sul red-teaming, l’obbligo resterebbe privo di un meccanismo operativo stabile nelle fasi del contratto. Per essere realmente esigibile, il requisito deve essere agganciato alla progettazione del fabbisogno, alla valutazione dell’offerta, alle clausole contrattuali, alle verifiche di collaudo e alle attività di monitoraggio in esercizio. In assenza di tale aggancio, una previsione sul red-teaming introdotta al §3.6.3 rimarrebbe dichiarativa e non darebbe alle amministrazioni strumenti azionabili lungo le fasi previste dal Codice dei contratti pubblici.
Raccomandazione: integrare il §3.7 prevedendo, per ciascuna fase del ciclo di vita del contratto, un riferimento esplicito al red-teaming, almeno nei termini seguenti:
(a) Programmazione: includere il fabbisogno di red-teaming tra i fabbisogni preliminari del sistema di IA, distinguendo tra attività pre-collaudo, periodiche e a evento, e considerarne il costo nella valutazione di sostenibilità economica della soluzione.
(b) Progettazione: tradurre i requisiti di red-teaming in requisiti tecnico-funzionali del fabbisogno, comprensivi dell’ambito del test, della periodicità, dei trigger a evento, dei deliverable attesi e dei requisiti minimi del soggetto terzo incaricato. Tali elementi dovrebbero trovare collocazione nello Strumento B – Schema di Capitolato Tecnico, almeno negli Articoli 12, 16 e 19 e, ove necessario, negli allegati tecnici.
(c) Affidamento: prevedere, nei criteri di valutazione dell’offerta tecnica, elementi relativi al piano di red-teaming proposto, alla sua aderenza a framework pubblici riconosciuti, alla qualificazione del soggetto terzo incaricato e alla qualità dei deliverable attesi.
(d) Stipula: inserire clausole contrattuali specifiche che rendano esigibili il red-teaming pre-collaudo, quello periodico e quello a evento, la collaborazione del fornitore del sistema con il soggetto terzo incaricato, la gestione delle vulnerabilità rilevate e la riesecuzione dei test dopo le mitigazioni. Tali clausole dovrebbero essere riflesse nello Strumento B – Schema di Capitolato Tecnico, in particolare negli Articoli 12, 19 e 20.
(e) Esecuzione: includere il rispetto degli obblighi di red-teaming tra le verifiche sistematiche dell’amministrazione durante l’esecuzione del contratto, prevedendo misure conseguenti in caso di inadempimento, inclusa la sospensione del collaudo delle modifiche significative o di quote di corrispettivo ricorrente quando non siano state completate le verifiche richieste dopo aggiornamenti rilevanti del sistema.
Per il riflesso operativo di quanto sopra negli strumenti allegati si vedano i commenti dedicati nei rispettivi thread: nel thread dello Strumento B – Schema di Capitolato Tecnico, per l’integrazione degli Articoli 12, 16, 19 e 20 e degli Allegati D, F e G; nel thread dello Strumento C – Esempio LCOAI, per l’inclusione del red-teaming tra le voci di costo del ciclo di vita del sistema.
§3.1
Il D.Lgs. 36/2023 ha elevato i principi di risultato, fiducia e accesso al mercato a criteri ordinatori dell’intera attività di progettazione della procedura di affidamento. Non si tratta, come invece la bozza di Linee Guida sembrerebbe suggerire, di semplici parametri per calibrare i requisiti dell’appalto. Ciascuno di essi ha una portata sistematica ben precisa, ad esempio:
La bozza di Linee Guida declina questi principi in chiave atipica circoscrivendoli ai soli requisiti dell’appalto e svuotandoli della loro valenza ordinamentale: il principio di risultato diventa sinonimo di obiettivi chiari e prestazioni misurabili; il principio della fiducia si traduce in responsabilizzazione delle amministrazioni e valorizzazione delle competenze interne; il principio dell’accesso al mercato si riduce alla promozione di standard aperti, architetture modulari e interoperabilità. Anche i principi di responsabilità, proporzionalità, controllo e sostenibilità sembrano applicati esclusivamente alla definizione dei requisiti dell’appalto anziché all’intera progettazione della procedura di affidamento.
Il legislatore ha introdotto quei principi proprio per abilitare le stazioni appaltanti a compiere scelte procedurali coraggiose e appropriate: ricorrere a strumenti negoziali più adatti al contesto — es. dialogo competitivo, procedura competitiva con negoziazione, procedura negoziata —, evitare la deriva del massimo ribasso, gestire con flessibilità le modifiche contrattuali in corso di esecuzione. Il documento dovrebbe contemplare queste opportunità.
In particolare, la logica sottesa al principio di accesso al mercato dovrebbe indurre particolare prudenza nel ricorso a convenzioni e accordi quadro per l’acquisizione di soluzioni di intelligenza artificiale poiché si tratta di strumenti concepiti per merceologie standardizzate, in mercati consolidati e dominati da grandi player, con fabbisogni omogenei e prevedibili. Applicarli a un mercato ancora frammentato e in rapida evoluzione come quello dell’AI rischia di generare effetti distorsivi della concorrenza, favorendo i soggetti già presenti sul mercato pubblico in altre iniziative di acquisto centralizzato che presentano affinità o punti di contatto a scapito di operatori più specializzati, PMI e operatori innovativi.
Concordiamo con il quadro strategico del documento volto a prevenire la dipendenza strutturale da specifici fornitori o tecnologie. Tuttavia, riteniamo necessario introdurre elementi di flessibilità per evitare che questo principio si trasformi in un vincolo assoluto e controproducente.
1. Neutralità dell’hardware vs. Interoperabilità dei dati
Le Linee Guida richiedono di evitare “dipendenze strutturali da specifiche architetture, acceleratori o tecnologie proprietarie”. Pur sostenendo lo spirito di questa norma, l’attuale approccio alla “neutralità dell’hardware” risulta eccessivamente rigido. L’attenzione dovrebbe spostarsi dal forzare l’intercambiabilità dell’hardware alla garanzia dell’interoperabilità dei dati e dei carichi di lavoro. Il lock-in può essere efficacemente evitato attraverso API standard, formati di dati aperti e robuste capacità di esportazione dei dati.
Una rigorosa neutralità dell’hardware dovrebbe applicarsi principalmente all’approvvigionamento di infrastrutture computazionali grezze o di modelli personalizzati ospitati autonomamente (self-hosted). Per le funzionalità di IA acquistate come Servizi Gestiti (PaaS/SaaS) tramite API, l’hardware sottostante è astratto. Proibire rigidamente soluzioni gestite che sono nativamente ottimizzate per lo stack di un Cloud Service Provider (CSP), senza una valutazione proporzionale dell’effettivo rischio di lock-in, priva la Pubblica Amministrazione di soluzioni ad alta efficienza e prestazioni elevate.
2. Sostenibilità ambientale
I CSP utilizzano spesso hardware specializzato (ad esempio, TPU proprietarie) che offre prestazioni significativamente superiori e costi di inferenza inferiori rispetto all’hardware generico. L’utilizzo di questi acceleratori specializzati dovrebbe essere consentito e attivamente incoraggiato per ragioni di sostenibilità. Le TPU, ad esempio, sono esponenzialmente più efficienti dal punto di vista energetico rispetto alle CPU in termini di rapporto prestazioni/watt per i carichi di lavoro di addestramento e inferenza. Forzare l’uso di architetture generiche e non ottimizzate per garantire la flessibilità dell’hardware aumenterà inevitabilmente il consumo energetico e le emissioni di carbonio.
3. Approcci articolati al fallback su CPU
Le linee guida pongono l’accento su tecniche di ottimizzazione dei modelli per consentire l’esecuzione su infrastrutture esclusivamente CPU. Dovrebbe essere adottato un approccio ibrido più sfumato, basato sulla specifica architettura acquistata:
On-Premise: Per l’uso on-premise, il fallback su CPU è estremamente logico. Le amministrazioni devono eseguire i carichi di lavoro su hardware diversificato, e modelli correttamente dimensionati sono perfettamente adatti a rispondere a queste esigenze di sovranità dei dati on-premise.
Cloud: Per l’uso in cloud con dati non sensibili, l’obiettivo primario dovrebbe rimanere la portabilità dei dati piuttosto che l’imposizione del fallback su CPU.
4. Feedback specifico sulle clausole contrattuali:
Per riflettere queste realtà, suggeriamo le seguenti revisioni specifiche alle clausole contrattuali proposte nella sezione 3.5.1:
Portabilità e Reversibilità: Richiediamo chiarimenti sulla definizione specifica e sulle aspettative operative di “reversibilità” in questo contesto, poiché la sua attuale inclusione risulta ambigua.
Efficienza e Fallback su CPU: Proponiamo di sostituire il rigido requisito di fallback su CPU con la seguente clausola, più equilibrata:
"Il sistema dovrebbe, laddove tecnicamente fattibile e proporzionato al caso d’uso, fornire modalità di esecuzione alternative. Per sistemi di IA altamente complessi o servizi gestiti che richiedono hardware specializzato per soddisfare i requisiti di prestazioni e gli SLA (Service Level Agreement), i fornitori dovrebbero invece dimostrare la continuità operativa attraverso infrastrutture ad alta disponibilità e impegni di disaster recovery.
Proposta di integrazione al paragrafo 3.1 (Principi generali del procurement), in particolare nella sezione dedicata ai principi di responsabilità e controllo:
Stato attuale: Nel paragrafo 3.1, le Linee guida richiamano correttamente la necessità di garantire ruoli chiari, supervisione umana, presidio pubblico effettivo e governance lungo l’intero ciclo di vita dei sistemi di IA. Tuttavia, pur evidenziando l’importanza di tali funzioni, il documento non individua alcuna figura o presidio organizzativo minimo incaricato di assicurarle. Questa assenza può determinare un’applicazione disomogenea tra amministrazioni, soprattutto quelle di dimensioni medio‑piccole, e rischia di indebolire la capacità della PA di mantenere un controllo effettivo sui sistemi, con possibili ricadute anche sugli aspetti etici, quali trasparenza, non discriminazione e tutela dei diritti fondamentali.
Proposta di integrazione: Si propone di integrare il paragrafo 3.1 introducendo un presidio organizzativo minimo attraverso la designazione di un “Referente IA”, figura interna all’amministrazione con competenze tecniche, organizzative ed etiche. Tale referente garantirebbe coerenza tra progettazione, acquisizione, supervisione e monitoraggio dei sistemi di IA, assicurando il raccordo con il RTD, il DPO e la struttura CED/ICT dell’ente. La figura contribuirebbe inoltre al presidio etico, verificando la conformità ai principi dell’AI Act e alla tutela dei diritti fondamentali, rimanendo a disposizione quale punto di riferimento per i colleghi. L’introduzione del referente non limita l’autonomia organizzativa delle amministrazioni, che restano libere di collocarlo nelle strutture più adeguate alle proprie dimensioni e capacità.
Intervento presentato a titolo personale, in qualità di studente del Master in Etica e Intelligenza Artificiale (UniTo)
In merito alla previsione contenuta nel paragrafo 3.6.3 relativa agli Obiettivi di sicurezza, si ritiene che l’obbligo di consegna dei dataset su richiesta della Pubblica Amministrazione presenti tre criticità sostanziali e cumulative:
Tutela del segreto industriale: i dataset utilizzati per l’addestramento rappresentano uno dei principali asset competitivi e proprietà intellettuali del fornitore.
Fattibilità tecnica e diritti di terzi: nel caso di servizi basati su modelli fondazionali di terze parti, il fornitore non dispone dei diritti di redistribuzione sui dati di training; di conseguenza, l’obbligo risulta strutturalmente inadempibile.
Sicurezza e vulnerabilità: il trasferimento di dataset potenzialmente sensibili imporrebbe alla PA un onere di custodia per il quale potrebbe non disporre di infrastrutture adeguate, creando di fatto un nuovo e significativo vettore di vulnerabilità cyber.
Alla luce di tali considerazioni, si propone di sostituire l’obbligo di consegna con un modello di accesso controllato in ambiente del fornitore, limitatamente ai casi di comprovata criticità.
Segnaliamo le nostre proposte, puntualmente riferite ad alcuni passaggi.
Cordialmente
Paragrafo 3.4 - Pag. 26
Nel documento si afferma che “Nel procurement, le decisioni sulla localizzazione dei dati devono essere coerenti con il livello di rischio associato al contesto applicativo e con la natura dei dati trattati.”, sarebbe opportuno specificare che secondo le attuali indicazioni sono da preferire le infrastrutture residenti nel territorio dell’UE e che in tema di gestione i dati devono essere conformi al GDPR – Regolamento (UE) 2016/679, e conformi al Data Act (Regolamento UE 2023/2854) e EHDS – European Health Data Space.
Paragrafo 3.4 - Pag. 26
In riferimento al quarto profilo, è utile inserire il ciclo di vita del dato: il ciclo di vita del dato comprende l’insieme delle fasi attraverso cui un dato viene generato, gestito e reso disponibile per il riutilizzo. Una corretta gestione di ogni fase è essenziale per garantire qualità, affidabilità e valore informativo.
1. Raccolta ed estrazione:
Il dato viene acquisito da sistemi operativi, sensori, applicazioni o fonti esterne. In questa fase è fondamentale garantire accuratezza, completezza e corretto tracciamento della provenienza.
2. Ingestione e trasformazione:
I dati vengono normalizzati, puliti, arricchiti e convertiti nei formati necessari ai sistemi di analisi e ai modelli di IA. Una cattiva trasformazione compromette la qualità dell’intero processo.
3. Conservazione e gestione:
I dati sono archiviati in database, data lake o basi di conoscenza, secondo criteri di sicurezza, integrità, versioning e governance. La conservazione deve garantire accessibilità, protezione e conformità normativa.
4. Utilizzo e analisi:
I dati vengono interrogati, analizzati o utilizzati da modelli di Intelligenza Artificiale, sistemi decisionali o servizi applicativi. La qualità del risultato dipende direttamente dalla qualità delle fasi precedenti.
5. Riutilizzo e condivisione:
I dati possono essere messi a disposizione di altri sistemi, amministrazioni o processi, nel rispetto dei principi di interoperabilità, minimizzazione e sicurezza.
6. Archiviazione o dismissione:
Al termine del loro ciclo utile, i dati vengono archiviati secondo le regole di conservazione oppure eliminati in modo sicuro, garantendo tracciabilità e conformità normativa.
Paragrafo 3.6.2 - Pag 41
In riferimento al paragrafo sulle tassonomie di attacco, è utile segnalare lo spoofing. Lo spoofing, nel contesto dell’intelligenza artificiale, indica l’insieme di tecniche con cui un attaccante manipola o falsifica un input (come volto, voce o dati biometrici) per ingannare un sistema automatizzato. L’obiettivo è far riconoscere come autentico un segnale artificiale, sfruttando le vulnerabilità dei modelli nel distinguere tra dati reali e dati contraffatti.
Paragrafo 3.7 - Pag 50 – TABELLA 5
Ogni sistema informativo ha un proprio ciclo di vita. Tuttavia, sia per ragioni ambientali sia per la gestione responsabile dei dati, la fase di dismissione è spesso assente o non adeguatamente pianificata. In questa prospettiva, sarebbe opportuno prevedere nella tabella anche un piano di dismissione che riguardi non solo l’infrastruttura ma anche il dato. Troppo spesso, infatti, un sistema viene chiuso senza considerare il destino delle informazioni contenute che rischiano così di essere abbandonate, riutilizzate impropriamente o finire in mani non autorizzate.
Paragrafo 3.8- Pag 53 TABELLA 6
Nella tabella si parla di rischio organizzativo, economico, tecnologico, etc. ma viene spesso sottaciuto il rischio legato all’energia. Infatti, il crescente impiego di sistemi di intelligenza artificiale sta aumentando in modo significativo il fabbisogno energetico globale: secondo le stime più recenti, i soli carichi legati all’IA nei data center consumano già circa 20 TWh l’anno e potrebbero crescere di ulteriori 90 TWh entro il 2026, contribuendo in modo rilevante all’impatto ambientale delle infrastrutture digitali.
Contributo a cura della Taskforce IA dell’Autorità Nazionale Anticorruzione (ANAC)
Il capitolo presenta un impianto metodologico solido e coerente con il quadro normativo, ma risulta caratterizzato da un livello di astrazione elevato che ne limita l’applicabilità operativa da parte delle PA.
In particolare, i principi individuati (trasparenza, controllo, responsabilità, sostenibilità) sono correttamente formulati, ma non sempre tradotti in indicazioni concrete, requisiti tecnici o clausole contrattuali direttamente utilizzabili nei procedimenti di gara. Analogamente, la classificazione delle tipologie di sistemi di IA, pur chiara, non è sufficientemente collegata a casi d’uso reali della PA né ai livelli di rischio previsti dalla normativa europea.
Inoltre, l’attuale formulazione delle Linee Guida trarrebbe significativo beneficio da un approfondimento metodologico sulle modalità con cui le stazioni appaltanti conducono i c.d. Proof of Concept (PoC). A tal riguardo, sarebbe necessario definire criteri per validare non solo la fattibilità tecnica, ma anche la sostenibilità economica e organizzativa delle soluzioni prima del loro dispiegamento su larga scala.
Si suggerisce pertanto di rafforzare il capitolo introducendo elementi operativi quali checklist, esempi applicativi e criteri decisionali, in modo da supportare concretamente le PA nelle scelte di procurement, soprattutto in presenza di trade-off tra costo, controllo e prestazioni.
Il Comitato Scientifico dell’Osservatorio sull’Intelligenza Artificiale nelle Pubbliche Amministrazioni presenta le seguenti osservazioni:
Contributo a cura di Dedalus Italia S.p.A.
Dedalus propone che, nella sezione dedicata a “come acquisire” e in particolare nei passaggi relativi a requisiti minimi e criteri di valutazione, le Linee Guida esplicitino alcuni presìdi operativi che rendono una soluzione di IA realmente governabile nel tempo, evitando dipendenze strutturali da singole tecnologie o fornitori. In concreto, si suggerisce di valorizzare requisiti quali: modularità architetturale (separazione tra dati, modelli, orchestrazione e logica applicativa), sostituibilità delle componenti (inclusi modelli e servizi esterni), e disponibilità di meccanismi di fallback, con indicazione chiara di come tali requisiti debbano essere verificati e rendicontati.
Per rendere tali requisiti misurabili e “procurabili”, si propone inoltre di richiedere esplicitamente, già in fase di gara e poi in esercizio, deliverable/evidenze documentali e tecniche. A titolo esemplificativo: documentazione del sistema e delle dipendenze (incluso inventario/SBOM dove applicabile), descrizione delle responsabilità tra i diversi attori della catena del valore (provider/deployer e soggetti terzi), schede descrittive dei modelli e dei dati (model card/datasheet o documenti equivalenti), descrizione dei controlli di trasparenza e tracciabilità (logging, audit trail, criteri di conservazione), gestione delle versioni e del cambiamento, e un piano di portabilità e reversibilità (exit strategy) per componenti critiche.
Infine, nei passaggi relativi a rischio e sicurezza, Dedalus suggerisce di esplicitare che l’amministrazione debba poter valutare anche la supply chain dell’IA: provider esterni, strumenti e servizi di terze parti, dipendenze e subfornitori. Ciò abilita un procurement “responsabile” in modo concreto, permettendo alla PA di definire limiti e condizioni d’uso dei provider e degli strumenti di AI integrati, nonché presìdi di controllo sull’evoluzione del sistema nel tempo, coerentemente con trasparenza e accountability pubblica.
Par 3.1 — Principi generali del procurement
Il principio di accesso al mercato, esplicitato nel testo attraverso il riferimento a standard aperti, non discriminazione e assenza di requisiti restrittivi, convive nel documento con richiami allo sviluppo della filiera nazionale. L’obiettivo di rafforzare un ecosistema tecnologico nazionale è, come già osservato, pienamente condivisibile.
Riteniamo tuttavia utile che le Linee Guida chiariscano come i due principi si raccordino, in modo che il perseguimento del primo non si traduca, in sede applicativa, in criteri preferenziali negli atti di gara, se non legati a caratteristiche tecniche oggettive e verificabili valide per tutti, che potrebbero porsi eventualmente in tensione con il principio di non discriminatorietà enunciato dallo stesso documento, oltre che con la Direttiva 2014/24/UE art. 67 nel recepimento del D.Lgs. 36/2023.
A tal fine, suggeriamo di distinguere esplicitamente i due piani: gli obiettivi di sviluppo della filiera nazionale troverebbero sede più appropriata in strumenti di policy dedicati, quali requisiti di presenza operativa locale, obblighi di trasferimento di competenze, programmi con il sistema universitario; mantenendo parimenti le procedure di gara ancorate ai principi di apertura e parità di trattamento, limitando eventuali criteri preferenziali alla sussistenza di caratteristiche tecniche oggettive, verificabili e adeguate ai singoli casi d’uso o contesti: quali la localizzazione certificata ACN QI2/QC2 o la disponibilità di deployment on premise; senza quindi riguardare la nazionalità del fornitore.
Si segnala, infine, un refuso redazionale che inverte il senso del principio: il testo dispone che le amministrazioni devono evitare «requisiti non discriminatori o ingiustificatamente restrittivi». La negazione trasforma la prescrizione nel suo contrario: i requisiti da evitare sarebbero quelli non discriminatori, l’opposto di quanto evidentemente inteso. Si chiede la correzione formale in «requisiti discriminatori o ingiustificatamente restrittivi».
Par. 3.3 — Architettura logica di riferimento: implicazioni per il procurement
Le clausole di configurabilità dell’orchestratore, documentazione dei modelli e sostituibilità delle componenti sono condivisibili come obiettivo di governance.
In tema di portabilità, il documento prevede che essa avvenga «senza oneri non giustificati», senza definire alcun criterio per distinguere un onere giustificato da uno ingiustificato. La formula è indeterminata, genera rischio di contenzioso illimitato e rende impossibile il pricing per i fornitori. Si propone di sostituirla con un obbligo di trasparenza documentata: il fornitore dichiara in sede di offerta le procedure di portabilità disponibili e i relativi costi di migrazione, con riferimento esplicito al Data Act (Reg. UE 2023/2854) quale quadro già direttamente applicabile.
Si raccomanda inoltre di definire operativamente il concetto di «reversibilità», distinguendolo dalla portabilità: la reversibilità riguarda le condizioni di uscita contrattuale e la continuità operativa durante la transizione verso un fornitore alternativo, e non può essere intesa come ripristino di uno stato precedente all’adozione del sistema.
Par. 3.4 — Ruolo del dato nel procurement
Il capitolo presuppone che la PA sia titolare attiva del ciclo di vita del dato nel sistema di IA, con accesso e controllo sulla pipeline. Tuttavia, si osserva, che nella grande maggioranza degli acquisti la PA è invece utente di un servizio preconfigurato, con accesso e controllo limitati.
Si propone di distinguere tra:
Si segnala inoltre una discrasia terminologica con il quadro normativo vigente: le Linee Guida categorizzano i dati in «non sensibili», «personali » e «sensibili», nomenclatura che diverge dalla tassonomia ufficiale stabilita dall’art. 3 del Regolamento Cloud ACN, il quale classifica i dati esclusivamente in «ordinari», «critici» e «strategici» in base all’impatto di un’eventuale compromissione. L’adozione di una nomenclatura parallela nelle Linee Guida sull’IA rischia di generare incertezza operativa tra le amministrazioni nelle procedure di adeguamento e conformità. Si raccomanda di allineare la terminologia alla classificazione ACN, già recepita dalla PA e dotata di piena efficacia normativa.
In tema di localizzazione dei dati, suggeriamo che le Linee Guida valorizzino il sistema di qualificazione ACN come riferimento principale per le scelte architetturali delle PA. Questo sistema, articolato in livelli progressivi di sicurezza e controllo, è stato concepito proprio per consentire alle amministrazioni di selezionare l’infrastruttura più adeguata in funzione della sensibilità del dato trattato, indipendentemente dalla modalità di deployment. Un ancoraggio esplicito a questo quadro consentirebbe alle PA di accedere con fiducia all’intera gamma di soluzioni disponibili sul mercato — incluse quelle cloud qualificate ai livelli più elevati — sulla base di criteri oggettivi e già normativizzati, rafforzando al contempo la coerenza del documento con il principio di accesso al mercato che esso stesso enuncia.
In questa prospettiva, il testo attuale appare eccessivamente restrittivo laddove richiama quasi esclusivamente il modello on-premise per il trattamento di dati sensibili e le attività di training e fine-tuning. Il requisito di protezione può essere soddisfatto anche attraverso ambienti cloud che garantiscano la localizzazione in Europa dei dati.
Par. 3.5.1 — Neutralità hardware, acceleratori e portabilità dei sistemi di IA
Il requisito di esecuzione in modalità CPU-only come fallback obbligatorio potrebbe essere tecnicamente infondato per sistemi in produzione su grandi volumi di dati .
Altresì per molti use case “non-core” e “non-real time” modelli di taglia adeguata (es. Small Language Models) o caratterizzati da architetture particolarmente efficienti (es. basate su Mixture of Experts possono essere eseguiti anche su architettura CPU.
In definitiva raccomandiamo di non applicare generalmente il requisito del fallback CPU ma di considerarne vantaggi e svantaggi a seconda del caso d’uso e del contesto della singola Pubblica Amministrazione. In generale si evidenzia come il fallback CPU sia più adeguato per contesti di deployment on-premises che per deployment in cloud.
Par 3.6.3 — Obiettivi di sicurezza
L’insieme dei requisiti indicati nella sezione, sistema di gestione dei rischi, documentazione tecnica completa, logging automatico per l’intero ciclo di vita, supervisione umana, accuratezza e robustezza, corrisponde sostanzialmente ai requisiti dell’AI Act per i sistemi ad alto rischio (artt. 9 ss.).
La loro applicazione uniforme a qualsiasi acquisto IA della PA introduce de facto un regime high risk generalizzato non previsto dall’AI Act, con tre conseguenze: oneri sproporzionati per acquisti a basso impatto, barriere all’ingresso per le PMI, rischio di compliance formale sui sistemi critici in luogo di presidio sostanziale. In coerenza con la L. 132/2025, si propone di esplicitare che i requisiti corrispondenti al regime AI Act si applicano esclusivamente ai sistemi che rientrano nelle categorie ad alto rischio definite dal Regolamento, con regime proporzionato per le categorie inferiori.
Gli obblighi contrattuali per i fornitori replicano il medesimo regime su tutta la fornitura IA della PA. Oltre al problema di proporzionalità, alcuni obblighi non sono tecnicamente esigibili per modelli fondazionali di terzi: la spiegazione del processo decisionale non può essere imposta al fornitore di sistema per decisioni prese dal modello sottostante.
La responsabilità contrattuale rimane in capo al fornitore, che la esercita anche tramite accordi con il subprocessor; tuttavia, perché questa responsabilità sia esercitabile in concreto, gli obblighi devono essere definiti in termini tecnicamente azionabili a ciascun livello della catena.
Infine, l’obbligo di consegna dei dataset su richiesta della PA presenta tre criticità cumulative. Sul piano del segreto industriale: i dataset di addestramento sono tra gli asset competitivi principali del fornitore, sul piano della fattibilità tecnica: per servizi basati su modelli fondazionali di terzi, il fornitore non ha diritti di redistribuzione sui dati di training e l’obbligo è strutturalmente inadempibile. Sul piano della cybersicurezza: la PA diventerebbe custode di dataset potenzialmente sensibili senza infrastrutture adeguate, generando un nuovo vettore di vulnerabilità.
Per i sistemi ad alto rischio ai sensi dell’AI Act, il quadro normativo già applicabile — in particolare gli artt. 9 ss. del Regolamento — prescrive requisiti di qualità e robustezza dei dati di addestramento direttamente in capo al fornitore o allo sviluppatore del sistema: le Linee Guida dovrebbero valorizzare questo meccanismo come strumento principale di garanzia, evitando di duplicarlo con obblighi contrattuali distinti.
Par 3.7 — Buone pratiche per il procurement lungo il ciclo di vita del contratto
Il documento tratta sistematicamente l’IA come tecnologia da innestare su processi esistenti. In questo senso, le LG potrebbero essere arricchite inserendo la possibilità del redesign del processo abilitato dall’IA: la PA dovrebbe chiedersi non solo se una funzione può essere supportata dall’IA, ma se, potendo disporre dell’IA sin dall’inizio, quel processo sarebbe stato progettato diversamente. Si propone di inserire nella fase di programmazione un passaggio esplicito di valutazione del processo come candidato alla reingegnerizzazione, non solo all’automazione. Questa prospettiva è coerente con le raccomandazioni contenute in Business Perspectives on Advancing Artificial Intelligence. Business Recommendations to the OECD (Business at OECD – BIAC, febbraio 2026) sull’adozione di approcci AI-first per la trasformazione della pubblica amministrazione.
In tema di criteri di aggiudicazione, l’OEPV rappresenta un miglioramento rispetto al massimo ribasso, tuttavia, ci preme sottolineare come per sistemi di IA le cui prestazioni variano nel tempo e dipendono dall’integrazione operativa. In questo senso un approccio outcome-based — con una componente di corrispettivo legata a risultati misurabili — sarebbe più coerente con la natura della prestazione. Il documento BIAC/OCSE, ad esempio, è diretto su questo punto: l’efficacia dell’IA nella PA non si misura al momento dell’aggiudicazione, ma in esercizio, e i contratti dovrebbero strutturarsi di conseguenza, con indicatori di performance definiti ex ante e misurati nel tempo.
Contributo a cura di Traent Srl.
Si propone di integrare il Capitolo 2 — in particolare a valle del §2.2 “Livelli tecnologici dell’IA” e del §2.4 “Implicazioni per il procurement” (Tabella 2) — con un paragrafo dedicato ai framework tecnico-metodologici di sicurezza IA. La Tabella 2 delinea le implicazioni dei livelli tecnologici (Machine Learning, Deep Learning, Generative AI) in termini di governance, trasparenza e rischi di lock-in, ma non correda tali indicazioni con riferimenti ai principali standard internazionali: NIST AI RMF 1.0, NIST AI 100-2 (Adversarial Machine Learning), MITRE ATLAS, OWASP Top 10 for LLM Applications e ENISA AI Cybersecurity Challenges. Si chiede che per ciascun framework applicabile sia previsto l’obbligo di audit periodici di conformità, i cui esiti siano registrati con garanzia crittografica di integrità e marcatura temporale certificata su infrastruttura indipendente, consentendo alla PA di verificare se il fornitore ha aggiornato le proprie misure di mitigazione in coerenza con l’evoluzione degli standard, trasformando la conformità da requisito puntuale a processo continuo e verificabile.
Contributo a cura di Traent Srl.
Si propone di integrare il §3.5.1 “Neutralità hardware, acceleratori e portabilità” con il principio di Sovranità Verificabile. Il §3.5 afferma che le scelte architetturali «incidono in modo diretto e significativo sui costi complessivi del sistema, sul grado di controllo esercitabile dalla Pubblica Amministrazione e sull’esposizione a rischi tecnologici, economici e organizzativi» (pag. 30), ma la localizzazione fisica delle infrastrutture — anche su Polo Strategico Nazionale — è condizione necessaria ma non sufficiente per la sovranità effettiva. Un sistema eseguito in locale su hardware a controllo pubblico resta opaco se non è accompagnato da meccanismi di verifica indipendente. Si chiede che la neutralità hardware e la portabilità siano accompagnate da un requisito di certificazione crittografica delle operazioni di elaborazione, indipendentemente dal modello di deployment, trasformando il concetto di sovranità da localizzazione geografica a governo verificabile.
Inoltre, si propone di affiancare alle misure contrattuali anti-lock-in previste dal §3.5 e dal §3.8 un presidio infrastrutturale di verificabilità. Il §3.5 individua correttamente che il rischio di lock-in è «spesso associato all’utilizzo di orchestratori proprietari non sostituibili, di modelli strettamente integrati con l’infrastruttura del fornitore o di formati di dati non portabili» (pag. 32), ma le misure di mitigazione sono prevalentemente contrattuali. Si chiede che ogni deliverable contrattuale sia accompagnato da un certificato crittografico di portabilità registrato su infrastruttura indipendente, e che siano previsti test periodici di portabilità effettiva (migration drills) i cui esiti siano notarizzati con marcatura temporale. Si propone inoltre l’istituzione di un registro federato delle componenti IA certificate come portabili, consultabile da tutte le PA, per ridurre il costo di verifica individuale e rendere il lock-in misurabile e contestabile su base oggettiva.