Procurement IA nella PA: conclusa la consultazione pubblica delle Linee Guida AgID
Riflessioni in attesa del parere dell'Autorità Garante per la Protezione dei Dati Personali
01 — Le Linee Guida AgID sul procurement di IA nella PA
Il 19 marzo 2026 AgID ha aperto la consultazione pubblica sulla bozza di Linee Guida per il procurement di Intelligenza Artificiale nella Pubblica Amministrazione (Determinazione n. 43/2026), adottate ai sensi del D.P.C.M. 12 gennaio 2024 (Piano Triennale per l'Informatica 2024-2026). Il documento — 105 pagine, versione 1.0 — si rivolge a tutte le PA ex art. 2, co. 2 CAD e si applica a qualsiasi sistema IA impiegato come componente integrata o a supporto delle funzionalità istituzionali.
Il documento propone un framework di governance che copre l'intero ciclo contrattuale: programmazione, progettazione, affidamento, stipula, esecuzione.
Il quadro normativo all'interno del quale si inseriscono è piuttosto articolato: AI Act (Reg. UE 2024/1689), GDPR, Data Act (Reg. UE 2023/2854, applicabile dal 12 settembre 2025), Codice dei Contratti Pubblici (D.Lgs. 36/2023), L. 132/2025 (legge italiana sull'IA), NIS2, Cyber Resilience Act.
La struttura si articola in tre capitoli operativi:
- Cap. 3 — Come acquistare sistemi IA: famiglie tecnologiche (AI statistica, ML, Deep Learning, GenAI), architettura logica (orchestratore / modelli / dati / tool applicativi), ruolo del dato, cybersicurezza, gestione del rischio.
- Cap. 4 — Metriche, costi e monitoraggio (LCOAI): Costo Livellato dell'Intelligenza Artificiale — CAPEX + OPEX + costi organizzativi + costi di uscita e transizione. Comparabilità tra soluzioni API, cloud-hosted, self-hosted, ibride.
- Cap. 5 — Strumenti di gara e cooperazione tra PA: capitolato tecnico orientato ai risultati, criteri OEPV, clausole evolutive, portabilità dei dati, accordi quadro, aggregazioni di acquisto, interoperabilità.
02 — Il dato come asset giuridico autonomo nel procurement IA
Le LLGG dedicano un intero paragrafo al ruolo del dato (§ 3.4), qualificandolo come componente autonoma e qualificante del sistema di IA, distinta dai modelli e dagli strumenti applicativi. Secondo le LLGG, la gestione del dato non può essere implicitamente demandata al fornitore: deve essere oggetto di valutazione esplicita sin dalle fasi di programmazione e in tutte le successive fasi di procurement.
Le LLGG distinguono i dati in quattro macrocategorie:
| # | Categoria | Descrizione |
|---|---|---|
| 01 | Dati di titolarità della PA | Dati raccolti/elaborati dalla PA nell'esercizio di funzioni istituzionali |
| 02 | Dati personali e categorie particolari | Ex artt. 4 e 9 GDPR |
| 03 | Dati di terzi | Dataset commerciali, open data esterni |
| 04 | Dati generati dal sistema IA | Output, log di funzionamento, metadati, dati di tracciamento |
In tema di riutilizzo dei dati per finalità di addestramento, le LLGG sottolineano che gli SLA del fornitore dovrebbero disciplinare in modo puntuale le condizioni alle quali quest'ultimo possa impiegare i dati nella disponibilità della stazione appaltante per finalità ulteriori, includendo espressamente l'addestramento, il miglioramento e il riuso dei modelli.
In assenza di una clausola contrattuale dedicata, la PA si esporrebbe non solo a pratiche di valorizzazione privata del dato pubblico potenzialmente incompatibili con l'interesse generale, ma anche a profili di non compliance rispetto ai principi GDPR di liceità (per difetto di una valida base giuridica), minimizzazione e limitazione delle finalità, con conseguenti rischi di responsabilità e sanzioni — anche ai sensi degli artt. 82 e 83 GDPR — per il fornitore e per la stazione appaltante.
03 — Cybersicurezza come obbligo di procurement
Le LLGG recepiscono la tassonomia NIST degli attacchi specifici per sistemi IA (§ 3.6.2), qualificandoli come rischi da tradurre in obblighi contrattuali, criteri di gara e condizioni di accettazione — non come requisiti tecnici accessori.
| Categoria | Descrizione | Rilievo GDPR |
|---|---|---|
| Evasion Attacks | Perturbazioni degli input per alterare la classificazione del modello addestrato | Art. 32 — misure tecniche e organizzative adeguate |
| Poisoning Attacks | Corruzione dei dati di addestramento — degrada prestazioni o innesta backdoor nel modello | Art. 5.1.d — principio di esattezza dei dati |
| Privacy Attacks | Data reconstruction, Membership Inference, Model Extraction: ricostruzione di dati personali a partire dal modello addestrato | Art. 4 n. 12 — Data Breach. Obblighi di notifica artt. 33–34 GDPR |
| Abuse Attacks (GenAI) | Prompt injection, esfiltrazione dati tramite agenti IA, manipolazione del comportamento dei sistemi generativi | Art. 32 — risk assessment; presidi organizzativi sugli agenti IA |
Requisiti di sicurezza da tradurre in capitolato (§ 3.6.3)
- Sistema di gestione dei rischi documentato e mantenuto dal fornitore prima della consegna del sistema.
- Dataset di addestramento soggetti a politiche di governance adeguate al contesto di utilizzo e alle finalità previste.
- Logging automatico per l'intera durata del ciclo di vita del sistema IA.
- Supervisione umana garantita contrattualmente — interfacce HMI adeguate previste nella progettazione.
- Lista esaustiva delle operazioni autorizzate per agenti IA (allowlist esplicita — nessuna operazione non prevista).
- Controllo di emergenza e procedure documentate per il ripristino rapido in caso di comportamento anomalo.
- Audit periodici con piena collaborazione obbligatoria del fornitore.
04 — La questione aperta: il fornitore è ancora destinatario dei dati personali?
Come visto sopra, le LLGG auspicano l'adozione di clausole contrattuali e capitolati tecnici che limitino il riutilizzo dei dati per finalità ulteriori da parte del fornitore. Ma resta aperta una questione di fondo: in presenza di robuste misure di pseudonimizzazione, il fornitore continua ad essere destinatario di dati personali ai sensi del GDPR?
La svolta: CGUE C-413/23 P — «sentenza Deloitte» (4 settembre 2025)
La Corte introduce il principio di relatività nella qualificazione del dato come «personale»: tale qualifica non è una proprietà ontologica dell'informazione, ma una qualificazione relazionale — dipende da chi tratta il dato e dai mezzi che ha concretamente a disposizione per risalire all'identità dell'interessato.
Detiene la chiave di re-identificazione. L'obbligo informativo ex art. 13 GDPR persiste a prescindere dalla qualificazione in capo al destinatario.
Se non dispone — né può ragionevolmente disporre — dei mezzi per risalire all'identità, i dati possono non essere personali per quel soggetto specifico.
Le due condizioni cumulative
- Il destinatario non deve essere in grado di revocare le misure di pseudonimizzazione durante qualsiasi trattamento effettuato sotto il suo controllo.
- Le misure devono impedire concretamente l'attribuzione dei dati all'interessato, anche tramite controllo incrociato con altri mezzi di identificazione, in modo tale che per quel soggetto l'interessato non sia o non sia più identificabile.
Si segnala, tuttavia, che la CGUE ha confermato l'orientamento secondo cui il soggetto che riceve i dati — anche pseudonimizzati senza ragionevole possibilità di re-identificazione — debba comunque considerarsi «destinatario» ai sensi della normativa vigente, con tutte le conseguenze del caso, anche in termini di informativa agli interessati ex artt. 13 e 14 GDPR.
Digital Omnibus (COM(2025) 837) e risposta EDPB/EDPS — Joint Opinion 2/2026
La proposta di modifica del GDPR, parte del progetto di riforma noto come «Digital Omnibus», tenta di codificare questo approccio.
- Modifica art. 4.1 GDPR: dato non personale se il titolare non può ragionevolmente identificare l'interessato.
- Art. 41-bis: atti di esecuzione della Commissione per specificare i criteri di qualificazione.
- Nuovo art. 88c: legittimo interesse come base giuridica esplicita per addestramento IA.
- Contrarietà alla modifica dell'art. 4.1: rischio di architetture artificiosamente costruite per escludere il GDPR («punti di irresponsabilità»).
- Il titolare potrebbe condividere dati «relativamente non personali» confidando eccessivamente nelle misure di sicurezza.
- Suggerita l'adozione di ulteriori linee guida EDPB in luogo di una modifica legislativa strutturale sulla nozione di dato personale.
05 — Conclusioni e riflessioni in attesa del parere del Garante
La consultazione pubblica sulle LLGG AgID si è conclusa lo scorso 11 aprile. I temi toccati sono di estrema sensibilità e attualità; tuttavia, in alcuni versanti mancano indicazioni «chiare» agli operatori su come comportarsi di fronte all'esigenza di dotarsi di sistemi AI per l'esercizio delle proprie funzioni istituzionali.
Staremo a vedere se le osservazioni dei soggetti interessati — PA, operatori del mercato IA, DPO, CISO — abbiano contribuito a rendere il documento uno strumento di consapevolezza sull'integrazione sistematica tra procurement, protezione e governance dei dati.
Altrettanto interessanti saranno, in tale ottica, le osservazioni dell'Autorità Garante per la Protezione dei Dati Personali, chiamata ad esprimersi sulla bozza di Linee Guida aggiornate sulla base degli esiti della consultazione pubblica.
Avv. Massimo Caredda — MC Studio Legale, Cagliari · #PrivacyLaw #GDPR #AIAct #DPO #DigitalOmnibus
La tua PA o il tuo fornitore IA devono prepararsi al nuovo framework?
Tomato Blue affianca PA e operatori del mercato IA su capitolati, DPIA, governance del dato e cybersicurezza dei sistemi di intelligenza artificiale.
Contattaci