Sezione 9 – Predisponi tipologie di contratti e clausole contrattuali a salvaguardia dei principi e degli interessi rilevanti in un GDU

a cura di CNR-IFAC

Roberto Cippitani

GUIDA OPERATIVA: Dai principi normativi europei e nazionali alle clausole di bandi, capitolati e contratti

9.1 Scopo della guida e destinatari

Questa guida operativa accompagna il documento «Esempi di contenuti per regolare i rapporti tra Comuni e realizzatori di Gemelli Digitali Urbani (GDU)» e ne traduce i contenuti normativi in un percorso pratico, pensato per il personale degli enti pubblici che deve programmare, affidare e gestire la realizzazione di un Gemello Digitale Urbano.

Il documento di riferimento raccoglie formule per bandi, specifiche tecniche per capitolati e clausole contrattuali. La presente guida indica chi fa che cosa, in quale fase e con quali strumenti, affinché quei contenuti siano applicati correttamente e in modo coerente lungo l'intero ciclo dell'affidamento.

9.1.1 A chi si rivolge

Responsabile Unico del Progetto (RUP) e uffici gare/contratti, per la costruzione del bando e del capitolato.
Responsabile della Transizione Digitale (RTD) ex art. 17 CAD, per la classificazione dei sistemi automatizzati e la governance digitale.
Responsabile della Protezione dei Dati (DPO/RPD), per i profili di protezione dei dati personali.
Dirigenti e funzionari che utilizzeranno l'output del GDU a supporto delle decisioni amministrative.
Uffici tecnici e SIT (Sistemi Informativi Territoriali), per i profili di architettura, interoperabilità e dati geospaziali.

9.1.2 Come usare la guida

La guida segue le cinque fasi del ciclo di affidamento (programmazione, bando, capitolato, contratto, esecuzione). Per ciascuna fase indica gli adempimenti, i documenti da produrre e le clausole del documento-fonte da richiamare. La mappa concettuale allegata (Allegato A) offre una sintesi visiva dell'intero impianto e può essere usata come quadro d'insieme prima di entrare nel dettaglio.

In sintesi

Un GDU tratta dati personali e non personali e impiega tecnologie, spesso di intelligenza artificiale, che incidono su diritti dei cittadini e su interessi pubblici e privati.

L'obiettivo è bilanciare la protezione dei dati personali, la sicurezza e i segreti commerciali con l'apertura dei dati, la trasparenza, la ricerca e l'innovazione.

Lo strumento giuridico per ottenere questo equilibrio è la traduzione dei principi normativi in clausole esigibili e in specifiche tecniche misurabili.

9.2 Il quadro normativo essenziale

Prima di avviare il progetto, l'ente deve avere presente la cornice normativa che governa i GDU. Non è necessario conoscerla in dettaglio in questa fase: la guida richiama le norme rilevanti man mano che diventano operative. Di seguito una mappa di orientamento.

9.2.1 Diritto dell'Unione europea

Fonte	Rilievo per il GDU
GDPR — Reg. (UE) 2016/679	Trattamento dei dati personali: basi giuridiche, minimizzazione, sicurezza, responsabile del trattamento, decisioni automatizzate (art. 22).
Data Act — Reg. (UE) 2023/2854	Accesso e uso dei dati generati da prodotti connessi e servizi correlati (artt. 3–5); portabilità e passaggio fra servizi di trattamento dei dati (capo VI). Non attribuisce la titolarità dei dati, che va pattuita nel contratto.
AI Act — Reg. (UE) 2024/1689	Obblighi per i sistemi di IA, in particolare quelli ad alto rischio impiegati nella PA (Allegato III).
Open Data — Dir. (UE) 2019/1024	Riutilizzo dell'informazione del settore pubblico; principio «as open as possible, as closed as necessary».
Reg. di esecuzione (UE) 2023/138	Elenco dei dataset di elevato valore (HVD) da pubblicare in formato aperto.
NIS2 — Dir. (UE) 2022/2555	Misure di cibersicurezza e gestione degli incidenti.
INSPIRE — Dir. 2007/2/CE	Infrastruttura per l'informazione territoriale e i dati geospaziali.

9.2.2 Diritto nazionale italiano

Fonte	Rilievo per il GDU
L. 23 settembre 2025, n. 132 (art. 14)	Uso dell'IA nella PA: ruolo strumentale e di supporto, riserva di umanità della decisione, conoscibilità e tracciabilità.
L. 7 agosto 1990, n. 241	Procedimento amministrativo: principi generali (art. 1), motivazione (art. 3), telematica (art. 3-bis), partecipazione (artt. 7 ss.), accesso (artt. 22 ss.).
CAD — D. Lgs. 7 marzo 2005, n. 82	Uso delle tecnologie nell'azione amministrativa (art. 12) e Responsabile della Transizione Digitale (art. 17).
Codice contratti — D. Lgs. 36/2023	Procedure automatizzate (art. 30), specifiche tecniche (art. 79), disciplinare e capitolato speciale (art. 87).
D. Lgs. 27 gennaio 2010, n. 32	Recepimento INSPIRE per i dati territoriali.

9.2.3 Giurisprudenza di riferimento

La giurisprudenza amministrativa e quella europea hanno definito i limiti dell'automazione dell'azione amministrativa. Questi orientamenti, pur non riferiti ai GDU, si applicano ai sistemi del GDU che producono punteggi, classificazioni o raccomandazioni determinanti per le decisioni amministrative.

1.Cons. Stato, Sez. VI, n. 2270/2019 (caso docenti MIUR): l'algoritmo è «atto amministrativo informatico»; principi di conoscibilità e piena sindacabilità.
2.Cons. Stato, Sez. VI, nn. 8472, 8473, 8474/2019 («sentenze gemelle»): l'algoritmo si estende all'attività discrezionale; conoscibilità, non esclusività e non discriminazione.
3.Cons. Stato, Sez. VI, n. 881/2020: la «formula tecnica» va tradotta in «regola giuridica» intelligibile; la trasparenza prevale sulla riservatezza industriale.
4.Cons. Stato, Sez. III, n. 7891/2021: distinzione tra algoritmo deterministico e sistema di IA.
5.TAR Lazio, Sez. III bis, n. 10964/2019 e TAR Napoli, Sez. VII, n. 7003/2022: informazioni sulla logica del trattamento e obbligo di motivazione rafforzato.
6.CGUE, C-634/21 Schufa e C-203/22 Dun & Bradstreet: uno score automatizzato determinante è «decisione basata unicamente sul trattamento automatizzato»; bilanciamento tra trasparenza e segreti commerciali.

9.2.4 Predisponi tipologie di contratti e clausole contrattuali a salvaguardia dei principi ed interessi generali se il GDU è realizzato da imprese

Sia i dati che i software possono (o meglio devono, ricorrendone le condizioni) non essere necessariamente proprietari, come si ipotizza nel caso in cui, invece di un ente di ricerca/università, la progettazione del sistema sia affidata a un’impresa privata. In questo senso, invero, sono numerose le riflessioni dottrinali sul fatto che spesso le applicazioni apparentemente pubbliche sono spesso in realtà ibridi pubblico-privati che aprono delle riflessioni aggiuntive alle precedenti. Poiché le città collaborano con fornitori privati per creare e implementare sistemi di gestione per la mobilità intelligente, i servizi intelligenti o altre applicazioni urbane, queste (o meglio la politica) si trovano di fronte a un dilemma cruciale riguardo alle tecnologie intelligenti, ossia: da un lato, devono dare priorità alla salvaguardia dei residenti dallo sfruttamento dei dati privati; dall'altro, devono sfruttare le capacità dei dati fornite da entità commerciali per governare e fornire servizi in modo efficace.

Sebbene entrambi gli interessi siano importanti, l'attenzione sulla protezione delle informazioni personali e sulla prevenzione del c.d. capitalismo della sorveglianza ha giustamente guadagnato un'attenzione critica nel discorso che circonda le città intelligenti⁵⁵.

“Cities sit between two opposing interests when it comes to smart technologies. One is to safeguard municipal residents from private data exploitation. Another is to govern and provide services using the data capabilities created and run primarily by commercial entities. The first interest has received the most critical attention around smart cities. A rising body of literature argues that government involvement is necessary to stop the collection of personal information and surveillance capitalism.”⁵⁶

Pertanto, per evitare che le imprese private si approprino dei dati generati dai sistemi Smart City, è fondamentale predisporre strumenti giuridici e contrattuali che garantiscano il rispetto dei principi giuridici posti a tutela degli interessi generali sopra riportati.

9.3 Il percorso operativo in cinque fasi

Il rapporto tra l'ente e il realizzatore del GDU si articola in cinque fasi consecutive. Per ciascuna, la guida indica gli adempimenti, i documenti da produrre e i contenuti del documento-fonte da utilizzare.

9.3.1 Fase 1 — Programmazione e impostazione

Obiettivo: predisporre le condizioni giuridiche e organizzative prima di pubblicare la gara.

9.3.1.1 Adempimenti

1.Individuare il Responsabile della Transizione Digitale (RTD) quale soggetto competente alla classificazione dei sistemi automatizzati (art. 17 CAD).
2.Definire le finalità del GDU e le categorie di dati necessari, applicando da subito il principio di minimizzazione (art. 5(1)(c) GDPR).
3.Svolgere una valutazione d'impatto sulla protezione dei dati (DPIA) preliminare ove il trattamento presenti rischi elevati (art. 35 GDPR), con il coinvolgimento del DPO.
4.Impostare la bozza del Piano di Ricognizione e Gestione dei Dati (PdRGD) come strumento di pianificazione giuridica (cfr. Allegato B e clausola D.2, par. 9.10.4).
5.Valutare l'inserimento delle attività nel PIAO (Piano Integrato di Attività e Organizzazione), ai sensi dell'art. 6 del D.L. 80/2021.

9.3.2 Fase 2 — Bando di gara

Obiettivo: selezionare un fornitore qualificato e valutare l'offerta tecnica sulla gestione dei dati. Riferimento: par. 9.8.

9.3.2.1 Requisiti minimi del concorrente (criteri di selezione)

Nomina di un DPO (art. 37 GDPR).
Certificazione ISO/IEC 27001 in corso di validità o documentazione equivalente (art. 32 GDPR; NIS2).
Esperienza pregressa con trattamenti per enti pubblici conformi a GDPR, Reg. 2018/1807 e Dir. Open Data.
Presentazione di un Data Management Plan (DMP) conforme ai principi FAIR e alle linee guida AgID.
Accettazione espressa della riserva dei diritti d'uso in favore dell'ente su dati e risultati prodotti (modelli, algoritmi, software, elaborati), con dichiarazione dei componenti preesistenti e delle relative licenze.

9.3.2.2 Criteri di valutazione dell'offerta tecnica

Criterio	Punti max
Qualità del DMP e conformità FAIR	15
Anonimizzazione e pseudonimizzazione	15
Architettura privacy by design	10
Divieto di riutilizzo per IA proprietaria	10
Licenze Open Source/FAIR per software e dati	5

9.3.3 Fase 3 — Capitolato speciale

Obiettivo: tradurre gli obblighi giuridici in specifiche tecniche misurabili e verificabili. Riferimento: par. 9.9 (artt. 79 e 87 D. Lgs. 36/2023).

Il capitolato è il punto in cui la conformità normativa diventa concreta: senza specifiche tecniche misurabili, il controllo sulla conformità resta puramente formale. Le specifiche sono organizzate in cinque aree.

Specifica	Contenuto	Esempi di parametri
T.1 — Sensoristica IoT	Protocolli, identificazione, qualità del segnale, sicurezza dei dispositivi.	MQTT 5.0/CoAP; SLA 99%; mascheramento a bordo
T.2 — Data lake e metadati	Zone funzionali, data lineage, ontologie, catalogo dati.	DCAT-AP IT; PID; SSN/SOSA; CityGML 3.0
T.3 — Sicurezza e privacy	Crittografia, controllo accessi, anonimizzazione tecnica, incidenti.	AES-256; TLS 1.3; k-anonimato; notifica 24h
T.4 — Sistemi di IA	Documentazione, fairness testing, explainability, human oversight.	Model Card; Datasheet; SHAP/LIME; art. 14 AI Act
T.5 — Consegna ed escrow	Codice sorgente, documentazione, escrow, continuità.	EUPL v1.2; SBOM (SPDX); test coverage 80%

SLA e KPI da fissare nel capitolato (soglie minime)

Disponibilità della piattaforma ≥ 99,5% mensile; completezza dei dataset ≥ 98%.

Latenza < 60 s per dati IoT critici; tempo di risposta API p95 < 500 ms.

FAIR score ≥ 70%; fairness con differenziale < 5% tra sottogruppi sensibili.

Notifica incidenti < 24 h; copertura test di re-identificazione 100% dei dataset pubblicati.

9.3.4 Fase 4 — Contratto

Obiettivo: fissare gli obblighi giuridici puntuali tramite le clausole tipo. Riferimento: par. 9.10. Le clausole sono raggruppate in sei famiglie.

Gruppo	Clausole	Oggetto
A — Dati personali	A.1, A.2	Nomina del responsabile del trattamento; raccolta, finalità e base giuridica.
B — Anonimizzazione	B.1	Anonimizzazione e pseudonimizzazione; chiavi di re-identificazione al Titolare.
C — Sistemi di IA	C.0, C.1, C.2	Qualificazione IA/algoritmo; divieto di riuso per IA proprietaria; uso controllato.
D — Dati non personali e risultati	D.1, D.2	Titolarità pubblica di dati e risultati, diritti d'uso riservati all'ente, licenze e Open Data; processo del PdRGD a sei fasi.
E — Audit e penali	E.1, E.2	Diritti di audit del Comune; penali graduate per violazioni.
F — Qualità dei dati	F.1, F.2	Data Quality Assessment; Law Data Verification a supporto delle decisioni.

Tre clausole da non omettere mai

C.1 — Divieto di riuso per IA proprietaria: impedisce che i dati dei cittadini alimentino i modelli del fornitore. È il presidio contro l'appropriazione privata del patrimonio informativo pubblico.

D.1 — Titolarità dei dati e dei risultati, Open Data: garantisce che i dati non personali e tutti i risultati (modelli, algoritmi, software, elaborati) restino dell'ente, che si riserva i diritti d'uso per i propri scopi istituzionali e li rilascia in formato aperto, evitando il lock-in tecnologico.

C.0 — Qualificazione preliminare: distingue i sistemi di IA dagli algoritmi deterministici e determina quali obblighi dell'AI Act si applicano.

9.3.4.1 Di chi sono i dati e i risultati? La riserva dei diritti d'uso

È un punto da presidiare fin dal bando. In Italia non esiste una norma che attribuisca automaticamente all'amministrazione i diritti sui risultati di un appalto: la titolarità e le licenze dipendono da ciò che l'ente scrive nella lex specialis (bando, capitolato, contratto). Se l'ente non se ne occupa, rischia di non poter riutilizzare per i propri fini ciò che ha pagato con fondi pubblici.

La clausola D.1 risolve il problema su due livelli. Stabilisce la titolarità pubblica non solo dei dati non personali, ma di tutti i risultati prodotti dal fornitore (modelli, algoritmi, elaborati, software, banche dati). E riserva all'ente un diritto d'uso — perpetuo, irrevocabile, non esclusivo, gratuito e condivisibile con altre amministrazioni — per i propri scopi istituzionali: esercizio delle funzioni, valutazione delle politiche, ricerca e innovazione, pubblicazione come dati aperti.

Come riservarsi i diritti, in pratica

Nel bando: prevedere l'accettazione espressa della riserva dei diritti d'uso come requisito, con obbligo per il concorrente di dichiarare i componenti preesistenti (propri o di terzi) e le relative licenze.

Nel contratto (clausola D.1): affermare la titolarità pubblica di dati e risultati e il diritto d'uso dell'ente per scopi istituzionali; per i componenti di terzi, pretendere una licenza con perimetro equivalente, valida oltre la durata del contratto.

A garanzia: collegare il deposito in escrow (specifica T.5) di codice, credenziali e documentazione, così che la continuità d'uso non dipenda dalle vicende del fornitore (cessione, fusione, fallimento).

Riferimenti: art. 1 (principio del risultato) D. Lgs. 36/2023; artt. 50 e 52 D. Lgs. 82/2005 e D. Lgs. 36/2006 (disponibilità e riutilizzo dei dati delle PA); artt. 68-69 CAD (riuso e open source del software pubblico), in particolare art. 69, co. 2 (titolarità dei programmi sviluppati per l’amministrazione).

9.3.5 Fase 5 — Esecuzione, controlli e governance

Obiettivo: verificare nel tempo il rispetto degli obblighi e governare i dati anche dopo la conclusione del contratto. Riferimento: clausole E.1, E.2, D.2 e F.2.

1.Esercitare i diritti di audit (clausola E.1) con preavviso, verificando conformità a GDPR, Data Act e AI Act.
2.Acquisire il Compliance Report annuale del fornitore (accessi ai dati, sub-responsabili, data breach, stato delle misure di sicurezza).
3.Applicare le penali (clausola E.2) in caso di inadempimento, in misura proporzionata alla criticità.
4.Mantenere aggiornato il PdRGD (ogni sei mesi) e svolgere la Law Data Verification prima di usare i dati a supporto di atti amministrativi.
5.Pianificare la governance post-progetto: portabilità, conservazione, cancellazione dei dati personali, continuità del servizio.

9.4 Gli strumenti operativi chiave

9.4.1 Il Piano di Ricognizione e Gestione dei Dati (PdRGD)

Il PdRGD è lo strumento operativo che garantisce legalità, interoperabilità e sostenibilità dei dati del GDU. Classifica i dati, ne identifica fonti, licenze e diritti d'uso, e verifica l'applicazione delle normative rilevanti. Si articola in un processo a sei fasi (clausola D.2).

Fase	Attività
1 · Mappatura dati	Censimento di dataset primari e secondari, con provenienza, formato, modalità di acquisizione e natura (personali/non personali/misti).
2 · Analisi licenze	Identificazione delle licenze in formato SPDX e verifica di compatibilità per i mashup.
3 · Questionario FAIR	Qualificazione del grado di conformità FAIR con assegnazione di un FAIR score.
4 · Licenza di output	Scelta della licenza del dataset finale, coerente con gli input e con le clausole Share-Alike.
5 · Validazione (LDV)	Verifica etico-giuridica dell'affidabilità dei dati a supporto delle decisioni (clausola F.2).
6 · Governance post-progetto	Modalità di accesso, conservazione, condivisione e cancellazione dopo la fine del contratto.

9.4.2 La Law Data Verification (LDV)

La LDV è la verifica etico-giuridica della qualità del dato quando i risultati del GDU entrano nel processo decisionale della PA. Un dato di bassa qualità produce una decisione giuridicamente viziata: la LDV previene questo rischio e distribuisce correttamente le responsabilità. L'esito è un Data Quality Assessment (DQA) trasmesso al Comune e al DPO.

Accuratezza, completezza e attualità dei dati (art. 5(1)(d) GDPR).
Affidabilità metodologica e tracciabilità della fonte.
Assenza di bias sistematici che possano tradursi in discriminazioni.
Conformità normativa della fonte (GDPR, Reg. 2018/1807, Open Data, HVD).
Adeguatezza alla decisione amministrativa cui i dati sono posti a fondamento.

Il principio guida è la non-esclusività della decisione algoritmica (Cons. Stato, nn. 8472-8474/2019; Cons. Stato n. 881/2020): la decisione finale e la relativa responsabilità restano in capo al funzionario.

9.5 I sei principi per l'IA nell'azione amministrativa

Quando il GDU impiega sistemi di IA a supporto delle decisioni, l'ente e il fornitore devono assicurare il rispetto di sei principi cardine, che trovano traduzione tecnica nella clausola C.2.

Principio	Significato operativo	Riferimento
Legalità digitale	Il sistema opera entro i limiti delle norme e non deroga alle regole primarie dell'azione amministrativa.	art. 3-bis L. 241/1990
Human in the loop	L'output dell'IA è ausiliario; decisione e responsabilità restano al funzionario, che può accettare, modificare o rifiutare.	art. 14 L. 132/2025
Conoscibilità	Il cittadino ha diritto di conoscere l'esistenza di processi automatizzati e la logica utilizzata.	art. 14, co. 1, L. 132/2025; artt. 13-15 e 22 GDPR; Cons. Stato nn. 8472-8474/2019; nei contratti pubblici, art. 30, co. 3, lett. a), D. Lgs. 36/2023
Trasparenza rafforzata	Disponibilità di codice, documentazione e logiche di funzionamento; traduzione in regola giuridica intelligibile.	CGUE C-203/22
Non discriminazione	Il sistema è progettato e testato per impedire effetti discriminatori su categorie sensibili.	art. 30, co. 4, D. Lgs. 36/2023 (nei contratti pubblici); Cons. Stato nn. 8472-8474/2019
Buona fede e correttezza	L'impiego del sistema è reso palese e tracciabile nell'atto amministrativo.	art. 1, co. 2-bis, e art. 3 L. 241/1990; art. 14, co. 1, L. 132/2025

Attenzione: lo score automatizzato

Secondo la CGUE (Schufa, C-634/21), anche la sola produzione di un punteggio che un terzo utilizzi in modo determinante per una decisione costituisce «decisione basata unicamente sul trattamento automatizzato» ai sensi dell'art. 22 GDPR.

Se il GDU produce score, classificazioni o raccomandazioni determinanti, si applicano le garanzie dell'art. 22 GDPR e i sei principi sopra indicati.

ESEMPI DI CONTENUTI PER REGOLARE I

RAPPORTI TRA COMUNI E REALIZZATORI DI

GEMELLI DIGITALI URBANI (GDU)

Clausole di bandi pubblici e contratti — Raccolta e trattamento dei dati personali e non personali

9.6 Introduzione e obiettivo del documento

Il presente documento contiene una raccolta di contenuti quali le formule per bandi di enti pubblici, specifiche tecniche per i capitolati e clausole contrattuali, che sono destinati a regolare i rapporti tra i Comuni (o altri enti pubblici) che intendono costruire un Gemello Digitale Urbano (GDU) e le imprese o altri soggetti incaricati dello sviluppo.

In particolare, tali contenuti sono formulati tenendo conto della circostanza che la costruzione e il funzionamento di un GDU comporta l’uso e sviluppo di tecnologie, che trattano dati personali e non personali.

Dal trattamento dei dati possono derivare contrasti tra interessi quali la protezione dei dati personali, la tutela segreti commerciali o la sicurezza, la necessità di mettere a disposizione i dati per sviluppare l’economia, la trasparenza e la promozione della ricerca e dell’innovazione.

Il documento si articola su tre ambiti riguardanti l'intero ciclo degli atti amministrativi di affidamento:

Bandi di gara: requisiti di selezione e criteri di valutazione dell'offerta tecnica (par. 9.8);
Specifiche tecniche nei capitolati: requisiti tecnici misurabili, SLA e KPI per la fase di esecuzione (par. 9.9);
Clausole contrattuali: obblighi giuridici puntuali sul trattamento dei dati personali, sull'anonimizzazione, sul divieto di riutilizzo per IA, sulla qualità del dato e sul rilascio Open Data (par. 9.10).

9.7 Quadro giuridico di riferimento

9.7.1 La Strategia europea dei dati come cornice

La costruzione e il funzionamento dei GDU va inserita nel quadro politico e normativo europeo in materia di dati.

La Comunicazione della Commissione europea del 19 febbraio 2020 "Una strategia europea per i dati" (COM(2020) 66 final) stabilisce che la creazione di un mercato unico dei dati deve avvenire garantendo che le norme europee in materia di privacy e protezione dei dati, nonché il diritto della concorrenza e dei consumatori, siano pienamente rispettate. Lo spazio europeo dei dati deve essere costruito in modo trasparente, tenendo in considerazione l’attribuzione delle responsabilità e per assicurare il corretto equilibrio tra interessi dei singoli e interessi collettivi (cfr. per esempio Garante europeo della protezione dei dati, nel Parere n. 3/2020).

Il principio "as open as possible, as closed as necessary", contenuto nelle fonti dell’Unione (v. per esempio “considerando” 28 Direttiva 2019/1024) e consolidato nella politica europea dei dati, deve essere tradotto in clausole contrattuali concrete che vincolino il fornitore privato al rispetto di questi standard.

9.7.2 Il ruolo del Data Act nel rapporto comune-impresa

Il Regolamento (UE) 2023/2854 (Data Act), applicabile dal 12 settembre 2025, introduce disposizioni specifiche sui dati generati nell'uso di prodotti connessi e servizi correlati. In base agli artt. 3–5 del Data Act, gli utenti — tra cui gli enti pubblici — hanno il diritto di accedere ai dati generati dall’uso di prodotti connessi e servizi correlati e di utilizzarli. Il Data Act non attribuisce però la titolarità dei dati, che discende dal contratto: le clausole contrattuali per i GDU devono quindi stabilire che la titolarità dei dati e dei risultati generati nell’ambito del progetto spetta all’ente pubblico (per i programmi e i servizi sviluppati per l’ente anche ai sensi dell’art. 69, comma 2, D. Lgs. 82/2005), che il fornitore è tenuto a garantirne la portabilità e l’accessibilità e che l’ente esercita, quale utente, i diritti previsti dal Data Act ove il GDU impieghi prodotti connessi o servizi correlati.

9.7.3 L'AI Act e il divieto di riutilizzo per l'addestramento

Il Regolamento (UE) 2024/1689 (AI Act) introduce obblighi specifici per i deployer di sistemi di IA ad alto rischio utilizzati nella pubblica amministrazione. Nell'ambito dei GDU, i sistemi di IA impiegati per il supporto decisionale urbano possono rientrare nelle categorie di rischio elevato ex Allegato III dell'AI Act. Questo impone obblighi di trasparenza, human oversight e documentazione che devono essere riflessi nelle clausole contrattuali con i fornitori privati.

Le fonti giuridiche non stabiliscono un divieto di utilizzare i dati raccolti nell'ambito del GDU per l'addestramento di modelli di IA, ma comunque occorre tenere in considerazione i limiti derivanti da diverse disposizioni: (a) il principio di limitazione delle finalità ex art. 5(1)(b) GDPR; (b) il divieto di trattamento per finalità incompatibili ex art. 6(4) GDPR; (c) il principio di privacy by design ex art. 25 GDPR; (d) le disposizioni del Data Act sulla portabilità e l'accesso. Il divieto di trattamento dei dati per finalità incompatibili si estende al riutilizzo dei dati per l'addestramento di sistemi di IA del fornitore, potendo configurare una violazione degli artt. 5(1)(b) e 6(4) GDPR.

9.7.4 Il quadro nazionale italiano sull'uso dell'IA nella pubblica amministrazione

Al quadro europeo si aggiunge la normativa italiana specifica sull'utilizzo dell'intelligenza artificiale e degli strumenti automatizzati nell'azione amministrativa, particolarmente rilevante per il supporto decisionale prodotto da un GDU. Le fonti primarie sono:

l'art. 14 della Legge 23 settembre 2025, n. 132 (uso dell'IA nella pubblica amministrazione), che configura l'utilizzo dell'IA come strumentale e di supporto all'attività provvedimentale, lasciando la decisione finale e la responsabilità in capo al funzionario competente;
l'art. 3-bis della Legge 7 agosto 1990, n. 241, sull'uso della telematica nell'azione amministrativa;
l'art. 12, co. 2, del D. Lgs. 7 marzo 2005, n. 82 (Codice dell'Amministrazione Digitale — CAD), sull'uso delle tecnologie dell'informazione nei rapporti tra PA e privati;
l'art. 30 del D. Lgs. 31 marzo 2023, n. 36 (Codice dei Contratti Pubblici), sull'uso di procedure automatizzate nel ciclo di vita dei contratti pubblici.

A questo quadro legislativo si affiancano gli Orientamenti della Commissione europea sulla definizione di sistema di intelligenza artificiale (C(2025) 5053 final, 29 luglio 2025) e sulle pratiche di intelligenza artificiale vietate ai sensi del regolamento (UE) 2024/1689 (C(2025) 5052, 29 luglio 2025), nonché le Linee guida AgID per l’adozione dell’IA nella pubblica amministrazione, poste in consultazione come bozza con la determinazione n. 17/2025 (una versione rivista è stata notificata alla Commissione europea il 31 marzo 2026, procedura TRIS 2026/0166/IT), e le Linee guida AgID per lo sviluppo e per il procurement di sistemi di IA, poste in consultazione con la determinazione n. 43/2026 (12 marzo – 11 aprile 2026). Al 16 ottobre 2026 nessuno dei documenti AgID risulta adottato in via definitiva. Si tratta di documenti tutti di rilievo per la qualificazione dei sistemi di IA del GDU.

La giurisprudenza italiana ha progressivamente elaborato, anche in relazione a casi di automazione dell'azione amministrativa diversi dal GDU, sei principi cardine che devono orientare l'uso di sistemi automatizzati da parte della pubblica amministrazione: legalità digitale, human in the loop, conoscibilità, trasparenza rafforzata, non discriminazione, buona fede e correttezza. Tali principi configurano un sistema di garanzie che la PA è tenuta a rispettare nel momento in cui ricorre a strumenti di automazione per l'istruttoria o il supporto decisionale (v. sezione 7, par. 7.4.1.2).

Le pronunce di riferimento sono le seguenti:

La decisione-capostipite è Cons. Stato, Sez. VI, 8 aprile 2019, n. 2270 (caso docenti MIUR ex L. 107/2015), che qualifica l'algoritmo come "atto amministrativo informatico" e fissa i principi di conoscibilità del meccanismo decisionale e di piena sindacabilità giurisdizionale.
Le "sentenze gemelle" Cons. Stato, Sez. VI, 13 dicembre 2019, nn. 8472, 8473 e 8474 estendono l'impiego dell'algoritmo anche all'attività discrezionale, enucleando dal diritto sovranazionale (in particolare dal GDPR) tre principi cardine: conoscibilità, non esclusività della decisione algoritmica e non discriminazione algoritmica.
Cons. Stato, Sez. VI, 4 febbraio 2020, n. 881 precisa che la "formula tecnica" dell'algoritmo deve essere tradotta in "regola giuridica" intelligibile e che la riservatezza delle imprese produttrici non può prevalere sulla trasparenza.
Cons. Stato, Sez. III, 25 novembre 2021, n. 7891 affronta la distinzione tra algoritmo deterministico e sistema di IA. TAR Lazio, Roma, Sez. III bis, 13 settembre 2019, n. 10964 applica gli artt. 13-15 GDPR al diritto dell'interessato di ricevere informazioni significative sulla logica del trattamento automatizzato.
TAR Napoli, Sez. VII, 14 novembre 2022, n. 7003 precisa che il ricorso all'algoritmo non può comportare un abbassamento delle tutele procedimentali e rafforza l'obbligo di motivazione ex art. 3 L. 241/1990.

A livello europeo, la Corte di Giustizia UE ha interpretato per la prima volta l'art. 22 GDPR con la sentenza 7 dicembre 2023, Schufa Holding, C-634/21: lo score automatizzato che un terzo utilizzi in modo determinante per prendere una decisione costituisce essa stessa "decisione basata unicamente sul trattamento automatizzato" ai sensi dell'art. 22(1) GDPR. Il principio è stato precisato dalla CGUE, 27 febbraio 2025, Dun & Bradstreet Austria, C-203/22, che ha chiarito il bilanciamento tra il diritto all'informazione significativa sulla logica algoritmica ex art. 15(1)(h) GDPR e la tutela dei segreti commerciali (Dir. 2016/943).

Questi orientamenti sovranazionali — applicabili anche ai sistemi del GDU che producono punteggi, classificazioni o raccomandazioni determinanti per decisioni amministrative — si integrano con l'art. 3-bis e l’art. 3 (obbligo di motivazione) della L. 241/1990, e con gli artt. 7 ss. (partecipazione procedimentale) e 22 ss. (diritto di accesso) della medesima legge, nonché con l'art. 12, co. 2, e l'art. 17 del D. Lgs. 82/2005 (CAD) e con l'art. 14 della L. 23 settembre 2025, n. 132.

9.8 Contenuti normativi per bandi di gara pubblici

Questa sezione propone testi da inserire nei documenti di gara (capitolati, criteri di aggiudicazione, condizioni speciali) per l'affidamento dello sviluppo di un GDU a imprese private. I testi sono corredati delle fonti normative che ne giustificano l'inserimento.

9.8.1 Requisiti tecnici e giuridici minimi — Criteri di selezione

I seguenti requisiti sono proposti come criteri di selezione o come condizioni di partecipazione alla gara.

TESTO DA INSERIRE NEL BANDO — Requisiti minimi del concorrente

Il concorrente deve dimostrare il possesso dei seguenti requisiti tecnico-organizzativi in materia di protezione dei dati e conformità normativa:

1.Nomina di un Responsabile della Protezione dei Dati (DPO) nei casi previsti dall'art. 37 del Regolamento (UE) 2016/679 (GDPR).
2.Certificazione ISO/IEC 27001 (Sistemi di Gestione della Sicurezza delle Informazioni) in corso di validità o documentazione equivalente relativa alle misure di sicurezza tecnica e organizzativa adottate, ai sensi dell'art. 32 GDPR e della Direttiva (UE) 2022/2555 (NIS2).
3.Esperienza pregressa nella realizzazione di sistemi di trattamento dati per enti pubblici, con dimostrata conformità al GDPR, al Regolamento (UE) 2018/1807 (libera circolazione dei dati non personali) e alla Direttiva (UE) 2019/1024 (Dati Aperti).
4.Presentazione di un Piano di Gestione dei Dati (Data Management Plan — DMP) conforme ai principi FAIR (Findable, Accessible, Interoperable, Reusable) e alle linee guida AgID, che illustri le modalità di raccolta, trattamento, anonimizzazione, conservazione e rilascio dei dati generati nell'ambito del progetto.
5.Accettazione espressa della riserva, in favore della stazione appaltante, dei diritti d’uso sui dati e su tutti i risultati prodotti nell’esecuzione del contratto (modelli, algoritmi, elaborati, software, banche dati), per i propri scopi istituzionali, secondo quanto previsto dalla clausola D.1 del contratto. Il concorrente dichiara i componenti preesistenti di proprietà propria o di terzi e le relative licenze, garantendo che esse consentano al Comune l’esercizio di tali diritti anche oltre la durata del contratto.

Fonti: art. 37 e 32 GDPR; Direttiva (UE) 2022/2555 (NIS2), recepita con D. Lgs. n. 138/2024; Direttiva (UE) 2019/1024; art. 1 D. Lgs. 36/2023; artt. 50 e 52 D. Lgs. 82/2005 e D. Lgs. 36/2006 (disponibilità e riutilizzo dei dati delle PA); artt. 68-69 D. Lgs. 82/2005 (CAD); Linee guida AgID sulla valorizzazione del patrimonio informativo pubblico.

9.8.2 Criteri tecnici di valutazione relativi alla gestione dei dati

I seguenti criteri tecnici, da valutare in sede di offerta tecnica, attribuiscono punteggio proporzionale alla qualità delle soluzioni proposte per la gestione dei dati nel GDU.

Criterio	Descrizione	Punt. max
Qualità del DMP e conformità FAIR	Grado di implementazione dei principi Findable, Accessible, Interoperable, Reusable; conformità alle linee guida AgID e alla Direttiva Open Data (2019/1024).	15 punti
Anonimizzazione e pseudonimizzazione	Tecniche proposte per anonimizzare/pseudonimizzare i dati personali raccolti dai sensori IoT, con riferimento alle linee guida dell'EDPB e al Considerando 26 GDPR.	15 punti
Architettura privacy by design	Misure tecniche e organizzative di privacy by design e by default (art. 25 GDPR) integrate nell'architettura del GDU.	10 punti
Divieto di riutilizzo per IA proprietaria	Soluzioni contrattuali e tecniche per garantire l'impossibilità di utilizzo dei dati raccolti per l'addestramento di modelli di IA del fornitore o di terzi.	10 punti
Licenze Open Source/FAIR per software e dati	Utilizzo di licenze aperte (GPL, EUPL, MIT, CC-BY, CC0) per i software sviluppati e i dataset prodotti nell'ambito del progetto.	5 punti

Fonti per la costruzione dei criteri: GDPR artt. 5, 25, 32; Direttiva (UE) 2019/1024; Linee guida AgID.

9.9 Specifiche tecniche per il capitolato

Il capitolato speciale — v. artt. 79 (specifiche tecniche) e 87 (disciplinare di gara e capitolato speciale) del D. Lgs. 31 marzo 2023, n. 36 (Codice dei Contratti Pubblici) — costituisce il documento in cui l'ente pubblico traduce in requisiti tecnici misurabili i contenuti normativi dei bandi e delle clausole contrattuali. Nell'ambito di un GDU la elaborazione di tale documento è particolarmente critica: la conformità sostanziale alle norme UE sul trattamento dei dati attraverso sistemi di IA richiede che gli obblighi giuridici siano declinati in specifiche tecniche verificabili, in assenza delle quali il controllo sulla conformità rischia di essere meramente formale.

Le specifiche tecniche che seguono sono organizzate per aree funzionali del GDU e indicano, per ciascun requisito, lo standard di riferimento, i parametri misurabili e la modalità di verifica in sede di esecuzione contrattuale. Esse presuppongono l'architettura System-of-Systems (SoS) propria dei GDU, in cui il sistema complessivo integra sottosistemi eterogenei (sensoristica IoT, banche dati amministrative, piattaforme analitiche, sistemi informativi geografici).

9.9.1 Architettura del GDU: modularità, scalabilità, interoperabilità

L'architettura del GDU deve essere concepita secondo un approccio modulare e scalabile, tale da consentire: (a) l'integrazione incrementale di nuovi sottosistemi tematici (aria, mobilità, ambiente costruito, servizi ai cittadini); (b) l'interoperabilità orizzontale con altre piattaforme urbane della stessa città e verticale con infrastrutture europee (Citiverse, Local Digital Twin Toolbox, data.europa.eu); (c) la portabilità tra fornitori al termine del rapporto contrattuale, senza vincoli di lock-in tecnologico.

Requisito	Specifica tecnica	Standard / Verifica
Microservizi containerizzati	Deployment basato su container OCI-compliant (Docker, Podman) orchestrati con Kubernetes o equivalenti. Ogni servizio deve essere indipendentemente deployabile e versionabile.	OCI Runtime Spec; CNCF
API-first design	Ogni funzionalità del GDU deve essere esposta tramite API documentate. Specifica OpenAPI 3.0+ obbligatoria per ogni endpoint REST.	OpenAPI 3.0; JSON Schema
Interoperabilità geospaziale	Implementazione dei servizi OGC Web Services per la pubblicazione dei dati geospaziali: WMS (visualizzazione), WFS (feature), WCS (coverage), WMTS (tiling), SensorThings API per dati IoT.	OGC WMS 1.3, WFS 2.0, WCS 2.1, SensorThings API
Conformità INSPIRE	I dati territoriali devono rispettare i Data Specifications INSPIRE (Dir. 2007/2/CE) per le categorie di Annex I, II, III applicabili al GDU.	Dir. 2007/2/CE; D. Lgs. 32/2010
Portabilità e no lock-in	Assenza di formati proprietari non documentati. Codice sorgente fornito in escrow ai sensi della specifica T.5 (par. 9.9.7). Esportazione completa dei dati in formati aperti standard entro 30 giorni dalla richiesta.	Capo VI (artt. 23-31) Reg. (UE) 2023/2854, ove il Fornitore presti servizi di trattamento dei dati; negli altri casi obbligo contrattuale (T.5; D.2, fase 6)

9.9.2 Raccolta dati: sensoristica, protocolli IoT, qualità del segnale

Le specifiche del capitolato devono disciplinare analiticamente le modalità tecniche di raccolta dei dati: i dati del GDU non sono meramente osservati ma attivamente prodotti attraverso scelte tecniche che incidono sulla rappresentazione del reale. Specifiche insufficienti in questa fase producono criticità giuridiche a valle, nella fase di utilizzo dei dati per finalità decisionali.

Clausola T.1 — Requisiti tecnici della sensoristica IoT e dei dispositivi di raccolta

Ambito

La presente specifica disciplina i requisiti tecnici minimi dei sensori, dei gateway IoT e dei dispositivi di acquisizione dati integrati nel GDU.

Requisiti minimi

1.Protocolli di comunicazione ammessi: MQTT 5.0, CoAP (RFC 7252), AMQP 1.0, LoRaWAN 1.1, NB-IoT (3GPP Release 14+), per i sensori che richiedono connettività a basso consumo.

2.Ogni sensore deve essere identificato univocamente tramite URI persistente e deve esporre metadati conformi al vocabolario SSN/SOSA (Semantic Sensor Network Ontology, W3C Recommendation).

3.Per i sensori di qualità dell'aria (PM10, PM2.5, NO2, O3), conformità ai criteri di qualità dei dati indicativi ai sensi dell’allegato V (obiettivi di qualità dei dati) della Direttiva (UE) 2024/2881 (rifusione sulla qualità dell’aria, in vigore dal 10 dicembre 2024, che abroga la direttiva 2008/50/CE con effetto dal 12 dicembre 2026), con documentazione delle incertezze di misura ai sensi della norma tecnica UNI EN ISO 14956.

4.Per i sensori di traffico, telemetria di mobilità e conteggio: pre-elaborazione a bordo del dispositivo (edge processing) con mascheramento automatico di volti e targhe veicolari prima della trasmissione, salvo specifica autorizzazione scritta del Titolare.

5.Ogni gateway IoT deve implementare crittografia end-to-end del traffico dati con TLS 1.3 o DTLS 1.3 (per CoAP), autenticazione reciproca tramite certificati X.509 e gestione sicura delle chiavi.

6.SLA minima di disponibilità per sensore: 99,0 % su base mensile, con perdita massima ammissibile di dati del 2 % per sensore/mese. Le perdite devono essere documentate come metadato.

7.Sincronizzazione temporale: tutti i sensori devono essere sincronizzati via NTP o PTP (IEEE 1588) con precisione minima di 100 ms per dati urbani standard e 10 ms per dati di mobilità in tempo reale.

Fonti: Reg. (UE) 2024/1689 (AI Act), art. 10; Reg. (UE) 2016/679, art. 25; W3C SSN/SOSA Ontology; UNI EN ISO 14956; Dir. (UE) 2024/2881, allegato V; RFC 7252 (CoAP), MQTT v5.0 (OASIS).

9.9.3 Data layer: data lake, ontologie, metadati

L'architettura dei dati del GDU deve integrare un Data Lake di ingestion, un livello di ontology-aligned storage per i dataset strutturati, e un catalogo metadati conforme agli standard europei. La tracciabilità del ciclo di vita del dato è requisito funzionale del principio di accountability (art. 5(2) GDPR) e della Law Data Verification di cui alla clausola F.2.

Clausola T.2 — Specifiche del Data Lake e del catalogo dati

Architettura del Data Lake

1.Il Data Lake deve organizzare i dati in zone funzionali distinte: (a) Raw Zone — dati grezzi immutabili dal momento dell'ingestion; (b) Trusted Zone — dati validati, con qualità certificata secondo clausola F.1; (c) Refined Zone — dati trasformati per usi analitici specifici.

2.Le transizioni tra zone devono essere tracciate in un registro di data lineage immutabile, accessibile al Titolare, che documenta per ogni dato: origine, timestamp di acquisizione, trasformazioni applicate, autore tecnico, versione del modello.

3.Archiviazione dei dati in formati colonnari aperti per i dataset analitici: Apache Parquet o Apache ORC. Per i dati geospaziali vettoriali: GeoPackage (OGC) o GeoJSON. Per i dati tabellari di scambio: CSV on the Web (CSVW, W3C).

Ontologia e metadati

4.I dati strutturati del GDU devono essere allineati a ontologie standard: (a) SSN/SOSA per i dati sensoristici; (b) CityGML 3.0 e Smart Data Models (FIWARE) per i modelli urbani; (c) Transmodel (EN 12896) e GTFS per i dati di trasporto; (d) ISA Core Vocabularies per le entità amministrative.

5.Il catalogo dati deve essere conforme al profilo DCAT-AP IT (versione vigente) dell'AgID, con esposizione SPARQL endpoint e harvesting RDF/XML e JSON-LD verso dati.gov.it e data.europa.eu.

6.Ogni dataset deve disporre di: identificatore persistente (PID) — preferibilmente DOI o URN; licenza machine-readable (elemento dct:license); indicatore di qualità (scala FAIR); versioning semantico (MAJOR.MINOR.PATCH).

Fonti: DCAT-AP IT (AgID); W3C DCAT 3; CityGML 3.0 (OGC); SSN/SOSA (W3C); Transmodel (EN 12896); art. 5(2) GDPR.

9.9.4 Sicurezza tecnica, privacy by design e anonimizzazione

Le misure tecniche ex art. 32 GDPR, i requisiti di cybersicurezza della Direttiva NIS2 e gli obblighi di privacy by design dell'art. 25 GDPR devono essere tradotti nel capitolato in specifiche misurabili. Questo è particolarmente rilevante per l'implementazione del divieto di riutilizzo dei dati per finalità di IA proprietaria (clausola C.1, par. 9.10.3), che richiede misure tecniche di enforcement e non solo obblighi contrattuali.

Clausola T.3 — Specifiche tecniche di sicurezza e privacy

Crittografia e gestione delle chiavi

1.Dati a riposo: crittografia AES-256 (GCM o XTS mode) con chiavi gestite tramite HSM (Hardware Security Module) certificato FIPS 140-3 Level 3 o Common Criteria EAL 4+ o certificazione equivalente.

2.Dati in transito: TLS 1.3 obbligatorio; TLS 1.2 ammesso solo per retrocompatibilità con sensori legacy e solo con cipher suite forward-secrecy.

3.Rotazione periodica delle chiavi crittografiche con periodicità massima di 12 mesi per chiavi master e 90 giorni per chiavi di sessione.

Access control e logging

4.Implementazione del modello di autorizzazione RBAC (Role-Based Access Control) o ABAC (Attribute-Based), con principio del minimo privilegio e separazione degli ambienti (sviluppo, test, produzione).

5.Autenticazione forte a più fattori (MFA) obbligatoria per tutti gli accessi privilegiati. Supporto SPID/CIE per gli accessi dei cittadini a front-end informativi del GDU.

6.Logging centralizzato conforme a OWASP Logging Cheat Sheet: ogni accesso ai dataset del GDU è tracciato con chi, cosa, quando, da dove. Retention minima dei log: 24 mesi. I log sono immutabili e indirizzati a un sistema SIEM del Titolare.

Anonimizzazione e pseudonimizzazione — tecniche

7.Pseudonimizzazione: uso di algoritmi crittograficamente sicuri (HMAC-SHA256 con salt o equivalenti) per la generazione di identificatori pseudonimi. Le tabelle di mappatura sono conservate in ambiente isolato sotto controllo esclusivo del Titolare.

8.Anonimizzazione: applicazione di tecniche quantitativamente verificabili — k-anonimato (k >= 5), l-diversità (l >= 2), differential privacy (epsilon <= 1 per dataset pubblicati) — con certificazione documentale del risultato e test di re-identificazione conforme al parere 05/2014 del Gruppo di lavoro Articolo 29 sulle tecniche di anonimizzazione (WP216), tenendo conto dei successivi orientamenti dell’EDPB.

NIS2 e incident management

9.Conformità agli obblighi di gestione degli incidenti ai sensi dell'art. 21 Direttiva (UE) 2022/2555, con Incident Response Plan documentato e testato annualmente.

10.Notifica degli incidenti significativi all'ACN (Agenzia per la Cybersicurezza Nazionale) entro 24 ore tramite early warning, ai sensi del D. Lgs. 138/2024.

Fonti: Art. 25, 32, 33 GDPR; Direttiva (UE) 2022/2555 (NIS2); D. Lgs. 138/2024; NIST SP 800-57 (Key Management); FIPS 140-3; Gruppo di lavoro Articolo 29, Parere 05/2014 sulle tecniche di anonimizzazione (WP216); OWASP.

9.9.5 Sistemi di IA: documentazione, fairness, explainability

Gli obblighi dell'AI Act (artt. 9-15, 26) richiedono che i sistemi di IA del GDU siano corredati di una documentazione tecnica specifica. La conformità sostanziale a tali obblighi esige che i requisiti dell'AI Act siano tradotti in artefatti documentali tecnici verificabili, e non in dichiarazioni di conformità generiche.

Clausola T.4 — Documentazione tecnica, fairness testing e explainability dei sistemi di IA

Documentazione tecnica obbligatoria

1.Per ciascun sistema di IA del GDU il Fornitore consegna una Model Card conforme al framework Mitchell et al. (2019) che documenta: architettura del modello; dataset di training, validazione e test; metriche di performance globali e per sottogruppi demografici; limiti noti; controindicazioni di utilizzo.

2.Per ciascun dataset di addestramento, il Fornitore consegna una Datasheet for Datasets (Gebru et al., 2021) che documenta: motivazione della raccolta; composizione; processo di raccolta; preprocessing; usi consentiti e non consentiti; aspetti etici.

3.Log tecnici automatici ai sensi dell'art. 12 AI Act con retention minima di 6 mesi, tracciando input, output, intervallo temporale e componenti coinvolti, per la ricostruibilità delle decisioni algoritmiche.

Fairness testing — requisiti misurabili

4.Per i sistemi di IA che producono raccomandazioni relative a servizi ai cittadini, valutazione di fairness pre-deployment con almeno tre metriche quantitative tra: demographic parity, equalized odds, predictive parity, calibration within groups.

5.I risultati del fairness testing sono documentati con stratificazione per categorie sensibili rilevanti nel contesto del Comune (genere, classe di età, nazionalità, quartiere di residenza), segnalando eventuali disparità superiori al 5% tra sottogruppi.

6.Pipeline di monitoraggio post-deployment (model drift e fairness drift) con alert automatici al superamento di soglie concordate.

Explainability e human oversight

7.Implementazione di strumenti di explainability locale per ogni raccomandazione significativa del GDU: LIME, SHAP, counterfactual explanation o equivalenti. L'output deve essere comprensibile al funzionario pubblico che utilizza il sistema.

8.Interfaccia di human oversight conforme all'art. 14 AI Act che consente al funzionario di: (a) visualizzare la raccomandazione; (b) accedere alla spiegazione; (c) accettare, modificare o rifiutare motivando la decisione; (d) generare automaticamente la motivazione del provvedimento amministrativo ai sensi dell'art. 3 L. 241/1990.

Fonti: Reg. (UE) 2024/1689 (AI Act), artt. 9-15, 26; Mitchell et al. (2019), Model Cards for Model Reporting; Gebru et al. (2021), Datasheets for Datasets; L. 241/1990, art. 3.

9.9.6 SLA e indicatori di qualità misurabili

Le specifiche tecniche del capitolato devono fissare Service Level Agreement (SLA) e Key Performance Indicator (KPI) quantitativi che consentano la verifica oggettiva degli obblighi sostanziali in materia di qualità dei dati (clausola F.1, par. 9.10.6) e sicurezza. I valori indicati sono soglie minime di riferimento, modulabili in funzione della criticità del sottodominio applicativo.

Indicatore (KPI)	Soglia minima	Metodo di misurazione
Disponibilità della piattaforma	>= 99,5 % su base mensile	Monitoring automatizzato 24/7; esclusione manutenzioni programmate notificate
Completezza dei dataset	>= 98 % dei record attesi per periodo	Confronto con piano di campionamento atteso; anomalie > 2 % segnalate
Accuratezza dei dati di sensore	Entro tolleranze indicate dal costruttore	Calibrazione periodica e audit campionario trimestrale
Freschezza dei dati in tempo reale	Latenza < 60 s per dati IoT critici	Intervallo tra timestamp e disponibilità, misurato all'endpoint API
Tempo di risposta API	p95 < 500 ms; p99 < 2 s	Monitoring endpoint, reportistica mensile
Copertura dei metadati	100 % dataset con metadati DCAT-AP IT completi	Audit del catalogo dati con validatore DCAT-AP IT
FAIR score minimo	>= 70 % (scala FAIRsFAIR o equivalente)	Valutazione automatica tramite tool FAIR-Checker o F-UJI
Fairness dei sistemi di IA (disparità)	Differenziale < 5 % tra sottogruppi sensibili	Testing con almeno 3 metriche (demographic parity, equalized odds, calibration)
Tempo di notifica incidenti di sicurezza	< 24 h al Titolare e ACN	Registro incidenti audit dal Titolare
Copertura test di re-identificazione	100 % dei dataset anonimizzati pubblicati	Log del processo di anonimizzazione; test indipendente semestrale

Il mancato raggiungimento degli SLA e delle soglie di KPI costituisce inadempimento contrattuale e dà luogo all'applicazione delle penali di cui alla clausola E.2 (par. 9.10.5), in misura proporzionata alla criticità dell'indicatore e alla durata dello scostamento.

9.9.7 Consegna del codice sorgente, documentazione e continuità del servizio

Clausola T.5 — Requisiti di consegna e deposito in escrow

Consegna del codice sorgente

1.Al termine di ciascuna release, il Fornitore consegna al Titolare il codice sorgente completo del software sviluppato nell'ambito del contratto, ivi inclusi: (a) codice applicativo; (b) script di build e deploy (Infrastructure as Code — Terraform, Ansible, Helm chart); (c) schemi di database e migration script; (d) test unitari e di integrazione; (e) configurazioni di CI/CD.

2.Il codice è fornito sotto licenza aperta EUPL v1.2 o, in alternativa motivata, con licenza compatibile secondo il criterio di preferenza indicato nella clausola D.1 (par. 9.10.4).

3.Deposito in escrow presso notaio o soggetto fiduciario indipendente del codice, delle credenziali di infrastruttura e della documentazione, con attivazione automatica in favore del Titolare in caso di: (a) fallimento o liquidazione del Fornitore; (b) inadempimento grave non sanato; (c) termine del contratto senza rinnovo.

Documentazione tecnica

4.Consegna di documentazione tecnica comprensiva di: architettura di sistema; manuale di installazione; manuale di amministrazione; manuale d'uso per operatori; documentazione API (OpenAPI 3.0); diagrammi di flusso dati; mappa delle dipendenze di terze parti con relative licenze (SBOM — Software Bill of Materials in formato SPDX o CycloneDX).

5.Documentazione aggiornata ad ogni release e versionata nello stesso repository del codice sorgente.

6.Formazione al personale del Comune: almeno [40] ore per amministratori tecnici e [16] ore per utenti funzionali, con materiali di formazione consegnati in formato aperto al Titolare.

Copertura dei test

7.Test coverage minima del codice applicativo: 80 % per unit test, 60 % per integration test. Reportistica di copertura consegnata ad ogni release.

8.Esecuzione di test di sicurezza applicativa prima di ogni rilascio in produzione: SAST (Static Application Security Testing), DAST (Dynamic), SCA (Software Composition Analysis) per le dipendenze. Report dei test consegnati al Titolare.

Fonti: Reg. (UE) 2023/2854 (Data Act), capo VI, artt. 23-31 (portabilità e switching), ove il Fornitore presti servizi di trattamento dei dati; ISO/IEC 5962 (SPDX); OWASP Software Assurance; art. 30, co. 2, lett. a), D. Lgs. 36/2023 (disponibilità del codice sorgente); artt. 68-69 D. Lgs. 82/2005

9.10 Clausole contrattuali tipo

Le seguenti clausole sono progettate per essere inserite nel contratto stipulato tra il Comune (o altro ente pubblico) e l'impresa privata incaricata dello sviluppo del GDU. Esse sono elaborate con riferimento diretto alle fonti normative europee e nazionali applicabili.

9.10.1 A. Dati personali: raccolta e base giuridica

Clausola A.1 — Nomina del Responsabile del Trattamento

Contesto normativo e ratio

Nell'ambito del progetto di sviluppo del Gemello Digitale Urbano di [Nome Comune], il Fornitore tratterà dati personali per conto del Comune. Ai sensi dell'art. 28 del Regolamento (UE) 2016/679 (GDPR), il trattamento da parte di un responsabile deve essere disciplinato da un contratto che preveda la materia disciplinata e la durata del trattamento, la natura e le finalità del trattamento, il tipo di dati personali, le categorie di interessati e gli obblighi e i diritti del titolare del trattamento.

Testo della clausola

1.Il Comune di [Nome] agisce in qualità di Titolare del trattamento dei dati personali ai sensi dell'art. 4(7) GDPR.

2.Il Fornitore è nominato Responsabile del trattamento ai sensi dell'art. 28 GDPR per le operazioni di trattamento dati strettamente necessarie all'esecuzione del presente contratto.

3.Il Fornitore tratta i dati personali esclusivamente su documentata istruzione del Titolare, anche per quanto riguarda il trasferimento di dati personali verso un Paese terzo o un'organizzazione internazionale.

4.Il Fornitore garantisce che le persone autorizzate al trattamento si siano impegnate alla riservatezza o abbiano un adeguato obbligo legale di riservatezza.

5.Il Fornitore non ricorre a un altro responsabile del trattamento (sub-responsabile) senza previa autorizzazione scritta specifica o generale del Titolare.

6.In caso di violazione dei dati personali (data breach), il Fornitore notifica la violazione al Titolare entro 24 ore dalla scoperta, fornendo le informazioni necessarie ai sensi dell'art. 33 GDPR, affinché il Titolare possa adempiere all'obbligo di notifica all'autorità di controllo entro 72 ore.

Fonti: Art. 4(7), art. 28, art. 33 GDPR; D. Lgs. 10 agosto 2018, n. 101

Clausola A.2 — Raccolta dei dati personali: finalità, minimizzazione e base giuridica

Contesto normativo e ratio

I GDU raccolgono dati urbani da molteplici fonti (sensori IoT, telecamere, dispositivi mobili, banche dati amministrative) che possono contenere dati personali dei cittadini. Secondo la dottrina "capta" elaborata nell'ambito del progetto UISH (Colcelli, 2025), questi dati sono attivamente catturati e non meramente raccolti, il che richiede una maggiore attenzione alla fase di raccolta. Il GDPR impone che la raccolta sia limitata a quanto necessario rispetto alle finalità (art. 5(1)(c)) e che esista una base giuridica legittima (art. 6).

Testo della clausola

1.Il Fornitore raccoglie dati personali nell'ambito del GDU esclusivamente per le finalità specificate nell'Allegato [X] al presente contratto, che costituisce parte integrante dello stesso.

2.La raccolta di dati personali è limitata a quanto strettamente necessario per le finalità del GDU (principio di minimizzazione dei dati, art. 5(1)(c) GDPR). È vietata la raccolta di dati personali eccedenti o non pertinenti rispetto alle finalità dichiarate.

3.Le basi giuridiche per il trattamento dei dati personali sono quelle indicate nell'informativa privacy predisposta dal Comune, ai sensi dell'art. 6 GDPR. Il Fornitore non può invocare basi giuridiche ulteriori rispetto a quelle autorizzate dal Titolare.

4.Prima dell'avvio di qualsiasi attività di raccolta dati, il Fornitore fornisce al Comune un documento di "Analisi di Impatto sui Dati" che descrive: (a) le categorie di dati personali raccolti; (b) le modalità di raccolta (sensori, API, integrazione con banche dati); (c) le misure tecniche di minimizzazione implementate; (d) i tempi di conservazione dei dati.

5.Per i dati personali raccolti tramite sistemi di videosorveglianza, riconoscimento immagini o telemetria IoT, il Fornitore implementa meccanismi tecnici di blurring automatico o mascheramento dei dati identificativi prima di qualsiasi elaborazione, salvo specifica e motivata autorizzazione scritta del Titolare.

6.Il Fornitore conduce, prima dell'avvio del trattamento che presenti un rischio elevato, una Valutazione d'Impatto sulla Protezione dei Dati (DPIA) ai sensi dell'art. 35 GDPR, da sottoporre all'approvazione del Comune e del DPO.

Fonti: Art. 5(1)(b)(c)(e), art. 6, art. 25, art. 35 GDPR; Considerando 39 e 78 GDPR.

9.10.2 B. Anonimizzazione e pseudonimizzazione dei dati personali

Clausola B.1 — Obblighi di anonimizzazione e pseudonimizzazione

Contesto normativo e ratio

I dati raccolti nell'ambito di un GDU provengono spesso da sensori e dispositivi IoT che captano movimenti, comportamenti e preferenze di cittadini identificabili. Il GDPR, al Considerando 26, precisa che i dati anonimizzati non costituiscono dati personali e pertanto non rientrano nel suo ambito di applicazione. Tuttavia, l'anonimizzazione è irreversibile e spesso incompatibile con le esigenze operative del GDU; la pseudonimizzazione (art. 4(5) GDPR) rappresenta una misura tecnica di mitigazione del rischio che, pur non escludendo il regime GDPR, riduce significativamente i rischi per gli interessati.

Testo della clausola

1.Il Fornitore implementa, come misura tecnica e organizzativa di default ai sensi dell'art. 25(2) GDPR, la pseudonimizzazione sistematica dei dati personali raccolti prima di qualsiasi operazione di trattamento analitico o di machine learning.

2.Per le finalità di analisi statistica aggregata, simulazione e supporto decisionale del GDU che non richiedano l'identificazione degli interessati, il Fornitore applica tecniche di anonimizzazione robusta (k-anonimato, l-diversità o tecniche equivalenti conformi al parere 05/2014 del Gruppo di lavoro Articolo 29 sulle tecniche di anonimizzazione (WP216), tenendo conto dei successivi orientamenti dell’EDPB).

3.Le chiavi di re-identificazione dei dati pseudonimizzati sono conservate esclusivamente dal Titolare (Comune) in un ambiente sicuro e separato dai dataset trattati dal Fornitore.

4.Il Fornitore documenta in un apposito registro le tecniche di anonimizzazione/pseudonimizzazione utilizzate, i risultati delle verifiche di robustezza effettuate, e i dataset a cui tali tecniche sono applicate. Il registro è messo a disposizione del Comune su richiesta e comunque con cadenza semestrale.

5.Prima del rilascio di qualsiasi dataset derivante dall'elaborazione di dati personali, il Fornitore esegue un test di re-identificazione e certifica per iscritto l'adeguatezza del processo di anonimizzazione, in conformità con il Parere 05/2014 sulle tecniche di anonimizzazione del Gruppo di lavoro Articolo 29 (WP216).

6.I dati anonimizzati prodotti nell'ambito del GDU, una volta superati i test di cui al punto 5, sono qualificati come dati non personali, per i soggetti che non dispongono di mezzi ragionevolmente utilizzabili per la reidentificazione, ai sensi del Considerando 26 GDPR e sono soggetti al regime del Regolamento (UE) 2018/1807 (libera circolazione dei dati non personali).

Fonti: Art. 4(5), art. 25(2), art. 32, Considerando 26 GDPR; Reg. (UE) 2018/1807; Gruppo di lavoro Articolo 29, Parere 05/2014 sulle tecniche di anonimizzazione (WP216); CGUE, 4 settembre 2025, C-413/23 P, EDPS c. SRB

9.10.3 C. Divieto di riutilizzo dei dati personali per l'addestramento di sistemi di IA

Clausola C.0 — Qualificazione preliminare del sistema: IA o algoritmo deterministico

Contesto normativo e ratio

Prima dell'applicazione di qualsiasi disciplina sull'IA al GDU, è condizione preliminare che il Fornitore qualifichi espressamente e motivatamente i sistemi automatizzati impiegati, distinguendo tra sistemi di intelligenza artificiale ai sensi dell'art. 3 del Reg. (UE) 2024/1689 e algoritmi deterministici (sequenze di regole predefinite che producono un risultato prevedibile e ripetibile a parità di input). Tale qualificazione determina l'applicabilità dell'intera disciplina dell'AI Act. Gli Orientamenti della Commissione europea sulla definizione di sistema di IA (C(2025) 5053 final, 29 luglio 2025) e la consolidata giurisprudenza amministrativa italiana (Cons. Stato, Sez. III, 25 novembre 2021, n. 7891, sulla definizione di algoritmo; Cons. Stato, Sez. VI, 8 aprile 2019, n. 2270 e sentenze gemelle nn. 8472-8474/2019, sull'atto amministrativo informatico) richiedono che la classificazione risulti da atto motivato espressamente, la cui adozione compete nella PA al Responsabile della Transizione Digitale (RTD) ex art. 17 CAD.

Testo della clausola

1.Per ciascun modulo software integrato nel GDU che produca previsioni, raccomandazioni, classificazioni o decisioni rilevanti per l'azione amministrativa, il Fornitore fornisce al Comune, prima della messa in servizio, una Scheda di qualificazione tecnico-giuridica che indica: (a) se il modulo costituisce sistema di IA ai sensi dell'art. 3 del Reg. (UE) 2024/1689 o algoritmo deterministico; (b) la motivazione della qualificazione con riferimento ai sette elementi costitutivi indicati dagli Orientamenti della Commissione sulla definizione di sistema di IA, C(2025) 5053 final, del 29 luglio 2025 (sistema basato su macchina, autonomia, adattabilità, obiettivi, capacità di inferenza, output, influenza); (c) in caso di qualificazione come IA, la classe di rischio ai sensi degli artt. 5, 6 e Allegato III dell'AI Act.

2.La Scheda di qualificazione costituisce base istruttoria per l'atto motivato di classificazione del Responsabile della Transizione Digitale del Comune (art. 17 CAD), che potrà confermare, integrare o difformemente motivare la classificazione. In caso di difformità, prevale la qualificazione dell'Amministrazione.

3.La Scheda è aggiornata tempestivamente dal Fornitore in caso di: (a) modifica sostanziale del modulo (architettura, dataset di addestramento, finalità di impiego); (b) evoluzione degli orientamenti interpretativi dell'AI Office della Commissione europea o dell'AgID.

4.I moduli qualificati come sistemi di IA sono soggetti alle clausole C.1 e C.2; i moduli qualificati come algoritmi deterministici restano comunque soggetti agli obblighi di conoscibilità, motivazione e non discriminazione derivanti dagli artt. 3 e 3-bis della L. 241/1990 e dalla giurisprudenza amministrativa (Cons. Stato, Sez. VI, n. 2270/2019; nn. 8472–8474/2019; n. 881/2020) e, nelle procedure di affidamento, dall’art. 30 del D. Lgs. 36/2023.

5.Le specifiche tecniche di classificazione possono essere ricomprese nel PIAO (Piano Integrato di Attività e Organizzazione) del Comune ai sensi dell'art. 6, co. 1, del D.L. 9 giugno 2021, n. 80, nell'ambito della reingegnerizzazione dei procedimenti amministrativi.

Fonti: Art. 3, artt. 5-6, Allegato III Reg. (UE) 2024/1689 (AI Act); Orientamenti della Commissione sulla definizione di sistema di IA, C(2025) 5053 final, del 29.07.2025; Linee guida AgID per l’adozione dell’IA nella PA (bozza in consultazione, det. n. 17/2025); art. 17 D. Lgs. 82/2005 (CAD); art. 6, co. 1, D.L. 80/2021; art. 30 D. Lgs. 36/2023; art. 1, art. 3, art. 3-bis L. 241/1990; L. 23 settembre 2025, n. 132, art. 14; Cons. Stato, Sez. VI, 8 aprile 2019, n. 2270; Cons. Stato, Sez. VI, 13 dicembre 2019, nn. 8472, 8473, 8474; Cons. Stato, Sez. III, 25 novembre 2021, n. 7891

Clausola C.1 — Divieto assoluto di riutilizzo dei dati personali per finalità di IA proprietaria

Contesto normativo e ratio

Una delle questioni più critiche nel rapporto tra enti pubblici e fornitori privati di GDU riguarda il rischio che i dati personali dei cittadini raccolti nell'ambito del progetto pubblico vengano utilizzati dal fornitore per addestrare i propri sistemi di IA proprietari, creando un vantaggio competitivo privato a spese del patrimonio informativo pubblico. Tale pratica configurerebbe una violazione del principio di limitazione delle finalità (art. 5(1)(b) GDPR) e si inserisce nel fenomeno del capitalismo della sorveglianza oggetto di crescente attenzione nella letteratura sulle smart city.

Testo della clausola

1. È fatto assoluto divieto al Fornitore di utilizzare, direttamente o tramite soggetti terzi, i dati personali raccolti o trattati nell'ambito del presente contratto per qualsiasi finalità diversa dall'esecuzione del contratto stesso, ivi inclusa a titolo esemplificativo e non esaustivo:

l'addestramento, il fine-tuning, l'aggiornamento o la validazione di modelli di intelligenza artificiale di titolarità del Fornitore o di terzi;
la profilazione degli interessati a fini commerciali;
la creazione di dataset derivati da cedere o vendere a terzi;
l'utilizzo per la partecipazione a gare d'appalto o per finalità commerciali proprie.

2.Il divieto di cui al punto 1 si applica anche ai dati personali pseudonimizzati e ai dati anonimizzati qualora il Fornitore disponga di informazioni aggiuntive che consentano la re-identificazione degli interessati.

3.Il Fornitore implementa misure tecniche di controllo degli accessi (access control) che impediscano al proprio personale tecnico di accedere ai dataset del GDU al di fuori delle operazioni strettamente necessarie all'esecuzione del contratto. Tali misure includono: (a) sistemi di logging e auditing degli accessi ai dati; (b) separazione tecnica degli ambienti di produzione del GDU dagli ambienti di sviluppo interno del Fornitore; (c) divieto di copia o esportazione dei dataset verso sistemi del Fornitore non espressamente autorizzati.

4.Il Fornitore si obbliga a inserire clausole contrattuali equivalenti in tutti i contratti con eventuali sub-responsabili del trattamento.

5.La violazione del divieto di cui ai punti precedenti costituisce inadempimento contrattuale grave e legittima il Comune alla risoluzione immediata del contratto ai sensi dell'art. 1456 c.c., salvo il risarcimento del maggior danno e l'applicazione delle penali previste dalla clausola E.2 del presente contratto.

Fonti: Art. 5(1)(b), art. 6(4), art. 25, art. 28(3)(a) GDPR; Reg. (UE) 2024/1689 (AI Act), artt. 9 e 10; Reg. (UE) 2023/2854 (Data Act), art. 4.

Clausola C.2 — Utilizzo controllato di sistemi di IA nel GDU: obblighi dell'AI Act e principi per la PA

Contesto normativo e ratio

I sistemi di IA integrati nel GDU che producono raccomandazioni per la pubblica amministrazione possono qualificarsi come sistemi di IA ad alto rischio ai sensi dell'Allegato III dell'AI Act, in particolare quando sono usati come componenti di sicurezza nella gestione del traffico stradale o di infrastrutture critiche (All. III, punto 2) o per valutare l’ammissibilità a prestazioni e servizi pubblici essenziali (All. III, punto 5, lett. a)). Il deployer (il Comune) ha obblighi specifici ex art. 26 AI Act; il fornitore (provider) risponde degli obblighi ex artt. 16-22 AI Act e delle procedure degli artt. 43 e 47-49 per i sistemi che immette sul mercato o mette in servizio. Il quadro nazionale italiano (art. 14 L. 132/2025; art. 30 D. Lgs. 36/2023; art. 3-bis L. 241/1990) impone inoltre il rispetto di sei principi cardine — legalità digitale, human in the loop, conoscibilità, trasparenza rafforzata, non discriminazione, buona fede e correttezza — che devono trovare traduzione tecnica nel sistema fornito. Tali obblighi includono requisiti stringenti sulla qualità e rappresentatività dei dataset di addestramento.

Testo della clausola — obblighi di conformità AI Act

1. Il Fornitore dichiara e garantisce che i sistemi di IA forniti nell'ambito del GDU sono stati sottoposti alle procedure di valutazione della conformità previste dal Regolamento (UE) 2024/1689 (AI Act) e che, ove applicabile, è stata redatta la documentazione tecnica richiesta dall'art. 11 AI Act.

1-bis. Il contratto indica se il sistema è immesso sul mercato o messo in servizio con il nome o il marchio del Fornitore o del Comune. Nel secondo caso il Fornitore consegna la documentazione e presta l’assistenza necessaria perché il Comune adempia agli obblighi degli artt. 16–22 e 43–49 AI Act.

2.Per i sistemi di IA classificati come ad alto rischio ai sensi dell'Allegato III dell'AI Act, il Fornitore consegna al Comune: (a) la documentazione tecnica completa ex art. 11 AI Act; (b) le istruzioni per l'uso ex art. 13 AI Act; (c) il sistema di governance dei dati di addestramento, verifica e test ex art. 10 AI Act, con specifica indicazione che i dataset di addestramento non includono dati personali raccolti nell'ambito del presente contratto; (d) la dichiarazione di conformità UE ex art. 47 AI Act con le informazioni dell'Allegato V; (e) prova dell'apposizione della marcatura CE ex art. 48 AI Act all'esito della procedura di valutazione della conformità applicabile ai sensi dell'art. 43 AI Act.

3.Il Fornitore supporta il Comune nell'adempimento dell'obbligo di registrazione del sistema nella banca dati dell'UE ex art. 49 AI Act prima della messa in servizio, fornendo tutte le informazioni tecniche richieste.

4.Per i sistemi di IA ad alto rischio immessi sul mercato o messi in servizio prima della data di applicazione del capo III del Reg. (UE) 2024/1689 e destinati a essere usati da autorità pubbliche, il Fornitore predispone un piano di adeguamento che assicuri la conformità entro il 2 agosto 2030 (art. 111, par. 2) o, se anteriore, dal momento di una modifica significativa della progettazione.

5.Il Fornitore implementa sistemi di log automatici ex art. 12 AI Act che consentono la tracciabilità delle operazioni del sistema di IA, accessibili al Comune per un periodo minimo di [5] anni.

Traduzione tecnica dei sei principi previsti dalla legge italiana

6.Legalità digitale: il sistema opera entro i limiti delle disposizioni vigenti e non può derogare alle regole primarie dell'azione amministrativa (art. 3-bis L. 241/1990; art. 14 L. 132/2025).

7.Human in the loop: l'output del sistema di IA ha valore ausiliario e strumentale; la decisione finale e la relativa responsabilità restano in capo al funzionario competente (art. 14, co. 2, L. 132/2025; nei contratti pubblici, art. 30, co. 3, lett. b), D. Lgs. 36/2023). L'interfaccia del sistema consente esplicitamente al funzionario di accettare, modificare o rifiutare motivando la raccomandazione.

8.Conoscibilità: il cittadino ha diritto di conoscere l'esistenza di processi decisionali automatizzati che lo riguardano; il sistema produce, per ciascuna raccomandazione, informazioni significative sulla logica utilizzata (art. 14, co. 1, L. 132/2025; artt. 13-15 e 22 GDPR; Cons. Stato, Sez. VI, nn. 8472-8474/2019; nei contratti pubblici, art. 30, co. 3, lett. a), D. Lgs. 36/2023).

9.Trasparenza rafforzata: il Fornitore assicura la disponibilità del codice sorgente, della documentazione e di ogni elemento utile a comprenderne le logiche di funzionamento (art. 30, co. 2, lett. a), D. Lgs. 36/2023), con traduzione della formula tecnica in regola giuridica intelligibile.

10.Non discriminazione: il sistema è progettato e testato per impedire effetti discriminatori basati su nazionalità, origine etnica, opinioni politiche, religione, convinzioni personali, appartenenza sindacale, caratteri somatici, status genetico, stato di salute, genere, orientamento sessuale (Cons. Stato, Sez. VI, nn. 8472-8474/2019; nei contratti pubblici, art. 30, co. 3, lett. c) e co. 4, D. Lgs. 36/2023).

11.Buona fede e correttezza: l'impiego del sistema è reso palese e tracciabile; nell'atto amministrativo sono indicati sia l'impiego del sistema, sia l'iter logico di validazione o smentita della decisione automatizzata (art. 1, co. 2-bis, L. 241/1990; obbligo di motivazione, art. 3 L. 241/1990; art. 14, co. 1, L. 132/2025; Cons. Stato, Sez. VI, nn. 8472-8474/2019; TAR Napoli, Sez. VII, n. 7003/2022).

Fonti: Reg. (UE) 2024/1689 (AI Act), come modificato dal Reg. (UE) 2026/1744, artt. 3, punto 3, 9-22, 25, 26, 43, 47, 48, 49 e 111, par. 2, Allegati III e V; L. 23 settembre 2025, n. 132, art. 14; art. 30 D. Lgs. 36/2023; L. 241/1990, art. 1, co. 2-bis, art. 3, art. 3-bis, artt. 7 ss. e 22 ss.; art. 12, co. 2, D. Lgs. 82/2005 (CAD); Orientamenti della Commissione sulla definizione di sistema di IA, C(2025) 5053 final, e sulle pratiche di IA vietate, C(2025) 5052, del 29.07.2025; Linee guida AgID per l’adozione dell’IA nella PA (bozza, det. n. 17/2025) e per lo sviluppo e il procurement di sistemi di IA (det. n. 43/2026); Cons. Stato, Sez. VI, nn. 2270/2019, 8472-8474/2019, 881/2020; TAR Napoli, Sez. VII, n. 7003/2022; TAR Lazio, Sez. III bis, n. 10964/2019; CGUE, 7 dicembre 2023, Schufa, C-634/21; CGUE, 27 febbraio 2025, Dun & Bradstreet Austria, C-203/22.

9.10.4 D. Dati non personali: raccolta, disponibilità e rilascio FAIR/Open Data

Clausola D.1 — Titolarità, accessibilità e licenze dei dati non personali generati dal GDU

Contesto normativo e ratio

Il Regolamento (UE) 2023/2854 (Data Act) e il Regolamento (UE) 2018/1807 (libera circolazione dei dati non personali) stabiliscono il quadro per l'accesso e la condivisione dei dati non personali. In un GDU la grande maggioranza dei dati operativi (infrastrutture, sensori ambientali, traffico aggregato) è costituita da dati non personali o da dati precedentemente anonimizzati. La Direttiva (UE) 2019/1024 (Open Data), recepita in Italia con D. Lgs. 8 novembre 2021, n. 200, che ha modificato il D. Lgs. 36/2006, impone alle pubbliche amministrazioni di rendere disponibili i dati pubblici in formato aperto, in linea con il principio "as open as possible, as closed as necessary" consolidato nella politica europea dei dati. Un aspetto tecnico-giuridico particolarmente delicato, ai fini della sostenibilità post-progetto e del riutilizzo, riguarda la compatibilità tra licenze di dataset provenienti da fonti diverse (mashup): le licenze aperte non presentano un grado uniforme di apertura, e le incompatibilità giuridiche possono impedire la pubblicazione o l'impiego dell'opera derivata.

Titolarità e accessibilità

1. Tutti i dati non personali generati nell’ambito del GDU — ivi inclusi dati di sensori aggregati, dati geospaziali, modelli urbani, dataset analitici, output simulativi — nonché tutti i risultati, gli elaborati, le banche dati, i modelli (anche di intelligenza artificiale), gli algoritmi, la documentazione e le opere dell’ingegno comunque prodotti dal Fornitore o da suoi subcontraenti nell’esecuzione del contratto, sono di esclusiva titolarità del Comune, che li acquisisce per effetto del presente contratto, anche ai sensi dell’art. 69, comma 2, del d.lgs. 7 marzo 2005, n. 82, per i programmi e i servizi sviluppati per il Comune, e degli artt. 107 ss. della l. 22 aprile 1941, n. 633, per le opere dell’ingegno, in coerenza con il principio del risultato (art. 1 D. Lgs. 36/2023) e con il principio di riuso del dato pubblico (artt. 50 e 52 D. Lgs. 82/2005; D. Lgs. 36/2006; artt. 68-69 D. Lgs. 82/2005). Ove il GDU impieghi prodotti connessi o servizi correlati, il Comune esercita inoltre, quale utente, i diritti di accesso e di uso dei dati previsti dagli artt. 3–5 del Reg. (UE) 2023/2854. Il Fornitore non acquisisce alcun diritto di proprietà, di licenza esclusiva o di sfruttamento commerciale su tali dati e risultati.

1-bis. Il Comune si riserva il diritto, perpetuo, irrevocabile, non esclusivo, gratuito e trasferibile ad altre pubbliche amministrazioni, di utilizzare, riprodurre, modificare, elaborare, aggregare, pubblicare e rendere disponibili i dati e tutti i risultati di cui al punto 1 per i propri scopi istituzionali, ivi compresi: l’esercizio delle funzioni amministrative; la programmazione e la valutazione delle politiche pubbliche; la ricerca, lo sviluppo e l’innovazione; la condivisione con altre amministrazioni nel rispetto del principio dell’unicità dell’invio e del riuso del dato pubblico; la pubblicazione come dati aperti. Qualora i risultati incorporino diritti di proprietà intellettuale di titolarità del Fornitore o di terzi (componenti preesistenti, software di base, librerie), il Fornitore concede o procura al Comune una licenza d’uso con il medesimo perimetro funzionale, idonea a garantire l’esercizio degli scopi istituzionali e la continuità d’uso oltre la durata del contratto, dichiarando espressamente tali componenti e le relative licenze.

1-ter. I diritti d’uso riservati al Comune ai sensi del punto 1-bis permangono in capo all’ente anche dopo la cessazione, la risoluzione o la scadenza del contratto e non sono pregiudicati da eventuali vicende soggettive del Fornitore (cessione d’azienda, fusione, fallimento, liquidazione). Resta fermo il deposito in escrow di cui alla specifica T.5 a garanzia della continuità d’uso.

Licenze — scelta e compatibilità

2.I dataset di dati non personali prodotti nell'ambito del GDU sono rilasciati con licenza aperta compatibile con il riutilizzo commerciale e non commerciale. Le licenze da utilizzare, in ordine di preferenza, sono: (a) CC0 (dominio pubblico); (b) CC-BY 4.0 (attribuzione); (c) EUPL v1.2 per il software. L'utilizzo di licenze più restrittive deve essere espressamente motivato dal Comune in base a specifici obblighi di riservatezza.

3.Per ciascun dataset il Fornitore riporta l'identificatore di licenza nel formato standard SPDX short-form (riferimento: spdx.dev), sia per le licenze in input (inbound) sia per quelle in output (outbound), al fine di garantire la tracciabilità giuridica automatizzabile.

4.Prima di ogni operazione di mashup (combinazione di dataset da fonti diverse), il Fornitore esegue una verifica formale di compatibilità tra le licenze dei dataset di input e la licenza prevista per l'output, documentandola in apposito registro. La verifica utilizza strumenti riconosciuti a livello europeo, inclusi l'EUPL Compatibility Checker della Commissione europea e la matrice di compatibilità delle Creative Commons.

5.Trattamento delle licenze Share-Alike (copyleft): qualora un dataset di input sia rilasciato con licenza Share-Alike (es. CC-BY-SA, ODbL), il dataset di output derivante dal mashup deve essere rilasciato con la medesima licenza o con licenza ufficialmente riconosciuta come equivalente. L'opera derivata indica espressamente le modifiche apportate rispetto all'originale. Qualora la compatibilità non sia realizzabile, il Fornitore segnala il conflitto al Comune prima di procedere al mashup.

6.Pubblicazione: il Fornitore pubblica i dataset non personali del GDU sul portale istituzionale Open Data del Comune e, ove applicabile, su dati.gov.it e data.europa.eu entro [30] giorni dalla produzione, corredandoli di metadati conformi al profilo DCAT-AP IT.

7.Conformemente ai principi FAIR, il Fornitore assegna a ciascun dataset un identificatore persistente (PID), una licenza machine-readable (elemento dct:license valorizzato con URI SPDX), e la documentazione necessaria per la riproducibilità dei dati.

Fonti: Reg. (UE) 2023/2854 (Data Act), artt. 3-5; Reg. (UE) 2018/1807; Direttiva (UE) 2019/1024 (Open Data), recepita con D. Lgs. 36/2006 e D. Lgs. 200/2021; art. 1 (principio del risultato) D. Lgs. 36/2023; artt. 50, 52 e 69, co. 2, D. Lgs. 82/2005 e D. Lgs. 36/2006 (disponibilità e riutilizzo dei dati delle PA; titolarità dei programmi sviluppati per l’amministrazione); artt. 107 ss. L. 633/1941; artt. 68-69 D. Lgs. 82/2005 (CAD; riuso e open source del software pubblico); DCAT-AP IT (AgID); Dir. 2007/2/CE (INSPIRE); SPDX License List (spdx.dev); EUPL Compatibility Checker (Commissione europea, Joinup / ISA Programme).

Clausola D.2 — Piano di Ricognizione e Gestione dei Dati (PdRGD): processo operativo

Contesto normativo e ratio

Il Piano di Ricognizione e Gestione dei Dati (PdRGD) è uno strumento operativo per garantire legalità, interoperabilità e sostenibilità dei dati del GDU. Il PdRGD deve classificare i dati in: personali / non personali / misti / primari / secondari; identificare le fonti, le licenze, la provenienza e i diritti d'uso; verificare l'applicazione delle normative rilevanti ai sensi del GDPR, del Data Act e della Direttiva Open Data. Il PdRGD si articola in un processo operativo a sei fasi consecutive che il Fornitore è tenuto a documentare e mantenere aggiornato.

Processo operativo a sei fasi

1.Fase 1 — Mappatura Dati: censimento completo di tutti i dataset primari (rilevamenti diretti, sensoristica, dati qualitativi e quantitativi) e secondari (cartografie, dataset acquisiti da terzi, dati derivati ed elaborati), con indicazione di denominazione, descrizione, formato, provenienza (creatore, data, fonte), modalità di acquisizione (titolo oneroso/gratuito), natura (dati personali / non personali / misti).

2.Fase 2 — Analisi delle licenze: identificazione per ciascun dataset della licenza di input nel formato SPDX short-form; verifica della compatibilità tra le licenze dei dataset da combinare (mashup) mediante gli strumenti di cui alla clausola D.1; documentazione delle eventuali restrizioni al riutilizzo e all'opera derivata.

3.Fase 3 — Questionario FAIR: qualificazione del grado di conformità ai principi FAIR (Findable, Accessible, Interoperable, Reusable) di ciascun dataset in output, con assegnazione di un FAIR score secondo metodologia FAIRsFAIR, F-UJI o equivalente.

4.Fase 4 — Scelta della licenza di output: selezione della licenza del dataset finale coerente con tutti gli input, nel rispetto delle condizioni di ridistribuzione e delle clausole Share-Alike, secondo il criterio di preferenza della clausola D.1.

5.Fase 5 — Validazione (Law Data Verification): verifica etico-giuridica dell'affidabilità dei dati a supporto delle decisioni amministrative, secondo le modalità della clausola F.2. La FAIRificazione è obbligatoria anche per database non aperti, ai fini della trasparenza e operatività del GDU.

6.Fase 6 — Governance post-progetto: definizione delle modalità di accesso, conservazione, condivisione e disposizione dei dati dopo la conclusione del contratto, comprese le disposizioni per la cancellazione dei dati personali, in linea con il principio di sostenibilità del GDU e con gli obblighi di portabilità previsti dal contratto e, ove il Fornitore presti servizi di trattamento dei dati, dal capo VI del Data Act.

Documentazione e aggiornamento

7.Il PdRGD viene redatto entro [30] giorni dalla firma del contratto, aggiornato ogni sei mesi e ogniqualvolta intervengano modifiche sostanziali nell'architettura dei dati del GDU.

8.La mancata consegna del PdRGD entro i termini o la consegna di un PdRGD incompleto o non conforme costituisce inadempimento parziale del contratto e dà luogo all'applicazione delle penali di cui alla clausola E.2.

Fonti: Direttiva (UE) 2019/1024; Reg. (UE) 2016/679, art. 30 (Registro dei trattamenti); Reg. (UE) 2023/2854 (Data Act), artt. 3-4 e, ove il Fornitore presti servizi di trattamento dei dati, capo VI (artt. 23-31); Linee guida AgID sul DMP; SPDX License List (spdx.dev); EUPL Compatibility Checker; Quadro europeo di interoperabilità ISA/ISA2.

9.10.5 E. Audit, controlli e penali

Clausola E.1 — Diritti di audit del Comune e obblighi di trasparenza del Fornitore

Testo della clausola

1.Il Comune ha il diritto di effettuare o fare effettuare, in qualsiasi momento e con preavviso di almeno [5] giorni lavorativi, audit tecnici e giuridici presso il Fornitore al fine di verificare: (a) il rispetto delle clausole contrattuali in materia di dati; (b) la conformità al GDPR, al Data Act, all'AI Act e alle altre normative applicabili; (c) la correttezza delle misure di sicurezza implementate; (d) il rispetto del divieto di riutilizzo dei dati per finalità di IA proprietaria.

2.Il Fornitore è tenuto a fornire al Comune, su richiesta e in ogni caso con cadenza annuale, un report di conformità (Compliance Report) che attesti: (a) il numero e la tipologia di accessi ai dataset del GDU effettuati dal proprio personale; (b) l'elenco dei sub-responsabili del trattamento eventualmente nominati; (c) gli eventuali data breach rilevati e le misure adottate; (d) lo stato di implementazione delle misure di sicurezza ex art. 32 GDPR e Direttiva NIS2.

3.In caso di ispezione da parte dell'Autorità Garante per la Protezione dei Dati Personali o di altra autorità competente, il Fornitore informa immediatamente il Comune e coopera pienamente con le autorità di controllo.

4.Il Comune ha diritto di accesso, in qualsiasi momento, ai sistemi di log e auditing previsti dall'art. 12 AI Act per i sistemi di IA del GDU.

Fonti: Art. 28(3)(h) GDPR; artt. 12, 19 e 26, par. 6, AI Act; Direttiva (UE) 2022/2555 (NIS2), art. 21; il contratto

Clausola E.2 — Penali per violazione degli obblighi in materia di dati

Testo della clausola

1. In caso di violazione da parte del Fornitore degli obblighi previsti dalle clausole [A.1], [A.2], [B.1], [C.0], [C.1], [C.2], [D.1], [D.2], [F.1], [F.2] del presente contratto e dalle specifiche tecniche T.1-T.5 di cui al par. 9.9, si applicano le seguenti penali:

Per ogni giorno di ritardo nella consegna del PdRGD o del Compliance Report rispetto ai termini contrattualmente previsti: penale pari al [0,5–1,5] per mille dell'ammontare netto contrattuale per ogni giorno di ritardo, nel limite complessivo del 10% di cui all'art. 126, co. 1, D. Lgs. 36/2023.
Per ogni violazione documentata del divieto di riutilizzo dei dati personali per finalità di IA: penale pari al [5%] del valore contrattuale complessivo, fermo il diritto al risarcimento del maggior danno.
Per ogni data breach non notificato entro i termini previsti dalla clausola A.1: penale pari a [€ 10.000] per ogni giorno di ritardo nella notifica, fino a un massimo di [€ 100.000].
Per ogni violazione dell'obbligo di anonimizzazione o pseudonimizzazione previsto dalla clausola B.1: penale pari al [2%] del valore contrattuale complessivo.

2.Le penali di cui al punto 1 sono cumulabili e non escludono il diritto del Comune al risarcimento del maggior danno, ai sensi dell'art. 1382 c.c.

3.In caso di violazione grave o reiterata degli obblighi in materia di dati, il Comune può risolvere il contratto ai sensi dell'art. 122 del D. Lgs. 36/2023. La violazione del divieto di cui alla clausola C.1 è causa di risoluzione di diritto ai sensi dell’art. 1456 c.c.

4.Il Comune segnala le violazioni rilevanti all'Autorità Garante per la Protezione dei Dati Personali e, ove applicabile, all'Agenzia per la Cybersicurezza Nazionale (ACN).

Fonti: Artt. 1382, 1454, 1456 c.c.; art. 83 GDPR (sanzioni amministrative); art. 32 e 33 GDPR; D. Lgs. 36/2023 (Codice dei Contratti Pubblici), artt. 122 e 126, come modificato dal D. Lgs. 209/2024

9.10.6 F. Qualità dei dati

La qualità dei dati è un presupposto tecnico e giuridico fondamentale per il corretto funzionamento di un GDU. Dati inaccurati, incompleti o obsoleti non solo compromettono l’affidabilità delle simulazioni e delle raccomandazioni del sistema, ma producono conseguenze giuridicamente rilevanti quando i risultati del GDU entrano nel processo decisionale della pubblica amministrazione. Nel diritto dell'UE il trattamento dei dati attraverso sistemi di IA impone obblighi che si estendono all'intera catena di produzione dell'informazione: un dato di bassa qualità produce una decisione giuridicamente viziata, e la responsabilità si distribuisce tra tutti i soggetti che hanno concorso alla sua produzione.

Il concetto di Law Data Verification (LDV) indica una verifica etico-giuridica dell'affidabilità delle fonti e dei dati, distinta dalla mera validazione tecnica: essa si colloca tra il momento della raccolta (capta) e quello dell'integrazione nei processi decisionali della PA. La LDV è lo strumento operativo attraverso cui il principio di accuratezza dei dati personali ex art. 5(1)(d) GDPR si estende, per analogia funzionale, all'intero ecosistema dei dati del GDU, compresi quelli non personali.

Le clausole che seguono traducono in obblighi contrattuali concreti questa architettura normativa, integrando i requisiti del GDPR per i dati personali, i requisiti dell'AI Act per i dataset di addestramento e validazione dei sistemi di IA (art. 10), e i principi FAIR per i dati aperti della pubblica amministrazione.

Clausola F.1 — Standard minimi di qualità: accuratezza, completezza, aggiornamento

Contesto normativo e ratio

Il principio di accuratezza dei dati personali è sancito dall'art. 5(1)(d) GDPR, che impone che i dati siano esatti e, se necessario, aggiornati, con obbligo di adottare tutte le misure ragionevoli per cancellare o rettificare tempestivamente i dati inesatti. Il Regolamento (UE) 2024/1689 (AI Act), all'art. 10, estende esplicitamente i requisiti di qualità ai dataset utilizzati per l’addestramento, la validazione e il test dei sistemi di IA: essi devono rispettare adeguate pratiche di governance e gestione dei dati, essere pertinenti, sufficientemente rappresentativi e per quanto possibile privi di errori e completi. Per i dati non personali del GDU, la qualità è inoltre un requisito funzionale dei principi FAIR (in particolare la componente Reusable, che richiede metadati accurati e standard di qualità documentati). Occorre considerare che il principio di proporzionalità — cardine del diritto dell'Unione europea — imponga che la qualità degli strumenti informativi sia adeguata alle decisioni cui essi sono posti a fondamento, con conseguente responsabilità distribuita tra produttori e utilizzatori del dato.

Testo della clausola

1. Il Fornitore garantisce che tutti i dati raccolti, prodotti o integrati nell'ambito del GDU rispettino i seguenti standard minimi di qualità:

Accuratezza: i dati riflettono fedelmente i fenomeni urbani che intendono descrivere; le fonti sono verificate e documentate; è assente ogni dato noto come errato o fuorviante.
Completezza: i dataset non presentano lacune sistematiche che possano distorcere i risultati delle analisi o delle simulazioni; le eventuali lacune sono documentate e segnalate come metadato.
Attualità: i dati sono aggiornati con la frequenza minima indicata nell'Allegato [Z] al presente contratto, distinta per tipologia di dato (es. dati in tempo reale da sensori IoT: aggiornamento continuo; dati catastali: aggiornamento mensile; dati demografici: aggiornamento annuale).
Coerenza: i dati provenienti da fonti diverse che descrivono il medesimo fenomeno sono riconciliati e armonizzati; le discrepanze non riconciliabili sono documentate.
Tracciabilità: per ciascun dataset è documentata la catena di custodia (data lineage), comprendente origine, trasformazioni subite, versioni successive e responsabile di ciascuna operazione.

2.Il Fornitore adotta e mantiene un sistema di gestione della qualità dei dati (Data Quality Management System — DQMS) che include: (a) procedure di validazione automatica all'ingresso dei dati; (b) monitoraggio continuo degli indicatori di qualità (completezza, unicità, consistenza, validità dei valori); (c) procedure di segnalazione e correzione delle anomalie rilevate.

3.Prima dell'avvio operativo di ciascun modulo del GDU, il Fornitore esegue e documenta una valutazione della qualità dei dati di input (Data Quality Assessment — DQA), con esplicitazione dei limiti di qualità che possono influenzare l’affidabilità dei risultati. Il DQA è trasmesso al Comune e al DPO per i dati personali.

4.Il Fornitore applica ai dataset di addestramento e validazione dei sistemi di IA integrati nel GDU le pratiche di governance previste dall'art. 10 AI Act, garantendo: (a) la pertinenza e rappresentatività dei dataset rispetto ai fenomeni urbani del territorio del Comune; (b) l’assenza di bias sistematici che possano produrre risultati discriminatori per specifiche categorie di residenti; (c) la documentazione delle tecniche di esame dei dataset per possibili bias.

5.I dataset di addestramento di cui al punto 4 non possono contenere dati personali raccolti nell'ambito del presente contratto, salvo specifica autorizzazione scritta del Titolare e previo completamento delle procedure di anonimizzazione di cui alla clausola B.1.

Fonti: Art. 5(1)(d), art. 25 GDPR; Reg. (UE) 2024/1689 (AI Act), art. 10; Wilkinson et al. (2016), Nature Scientific Data 3:160018; ISO 8000 (Data Quality).

Clausola F.2 — Law Data Verification (LDV): verifica etico-giuridica delle fonti e dell'affidabilità dei dati

Contesto normativo e ratio

Il concetto di Law Data Verification (LDV) indica uno strumento di verifica specifico che va oltre la tradizionale validazione tecnica: si tratta di una verifica che integra dimensioni giuridiche (conformità normativa delle fonti), etiche (assenza di bias, rappresentatività dei gruppi sociali) ed epistemologiche (affidabilità dei metodi di raccolta). Il diritto dell'UE — attraverso il GDPR, il Data Act e l'AI Act — sta costruendo un sistema di obblighi di qualità e tracciabilità dei dati quale condizione per la loro circolazione nel mercato unico digitale. Il principio di proporzionalità esige che la qualità dell'informazione su cui si fonda una decisione pubblica sia adeguata alla portata degli effetti giuridici di quella decisione.

Testo della clausola

1. Il Fornitore esegue, per ciascun dataset primario utilizzato nel GDU, una Law Data Verification (LDV) che comprende le seguenti verifiche documentate:

Conformità normativa della fonte: il dataset è prodotto o messo a disposizione in conformità con le normative applicabili (GDPR per i dati personali; Reg. 2018/1807 e Dir. 2019/1024 per i dati non personali; Regolamento di esecuzione (UE) 2023/138 per i dataset di elevato valore (HVD)).
Affidabilità metodologica: il metodo di raccolta è documentato, riproducibile e coerente con gli standard scientifici applicabili al dominio urbano di riferimento (mobilità, qualità dell'aria, ambiente costruito ecc.).
Rappresentatività sociale: il dataset non esclude sistematicamente categorie di residenti (anziani, stranieri, persone con disabilità, residenti di specifici quartieri) che potrebbero risultare invisibili ai sistemi di raccolta digitale, producendo bias algoritmici nelle decisioni amministrative.
Provenienza e diritti d'uso: la fonte è tracciabile, i diritti di utilizzo per le finalità del GDU sono verificati (licenza, accordo, base giuridica), l'utilizzo non viola diritti di proprietà intellettuale o segreti industriali.

2.I risultati della LDV sono documentati in un apposito Registro LDV aggiornato dal Fornitore. Per ciascun dataset il Registro indica: esito della verifica (conforme / non conforme / condizionatamente conforme); criticità rilevate; misure di mitigazione adottate; responsabile della verifica.

3.I dataset che non superano la LDV non possono essere integrati nel GDU senza autorizzazione scritta del Comune, accompagnata da una valutazione motivata dei rischi giuridici e operativi da parte del DPO e del responsabile tecnico del progetto.

4.La LDV è ripetuta ogniqualvolta: (a) un dataset subisca aggiornamenti sostanziali di metodo o fonte; (b) cambino le finalità di utilizzo del dataset nell'ambito del GDU; (c) sopravvengano modifiche normative che incidano sulla conformità della fonte.

5.Nel caso in cui i risultati del GDU siano utilizzati a supporto di atti amministrativi, il Fornitore certifica per iscritto, prima dell'utilizzo, che i dati sottostanti hanno superato la LDV e che il loro livello di qualità è adeguato alla tipologia di decisione amministrativa cui sono posti a fondamento, in coerenza con il principio di non-esclusività della decisione algoritmica elaborato dal Consiglio di Stato, Sez. VI, nelle sentenze nn. 8472, 8473 e 8474 del 13 dicembre 2019 e ribadito da Cons. Stato n. 881/2020.

Fonti: Art. 5(1)(d) GDPR; Reg. (UE) 2024/1689 (AI Act), art. 10; art. 41 Carta dei Diritti Fondamentali UE; L. 241/1990, art. 3-bis.

9.11 Conclusioni e raccomandazioni operative

Il presente documento riguarda alcuni contenuti normativi — requisiti di gara e clausole contrattuali — per regolare i rapporti tra enti pubblici e imprese private nella realizzazione di Gemelli Digitali Urbani. Come emerge dall'analisi della letteratura scientifica e del quadro normativo europeo, la sfida giuridica dei GDU non è riducibile alla mera applicazione del GDPR, ma richiede un approccio multidisciplinare che integri diritto dei dati, diritto dell'IA, diritto amministrativo e diritto contrattuale.

Le clausole proposte si fondano su tre principi fondamentali:

1.Il principio di ethics and legal compliance by design: la conformità normativa non è una verifica ex post ma deve essere integrata fin dall’inizio nell'architettura tecnica e contrattuale del GDU. Il trattamento dei dati attraverso sistemi di IA nell'ordinamento europeo impone obblighi di conformità che si estendono all'intera catena di produzione dell'informazione.
2.Il principio di titolarità pubblica dei dati e dei risultati: i dati e tutti i risultati (modelli, algoritmi, elaborati, software, banche dati) generati nell’ambito di un GDU finanziato con fondi pubblici sono un patrimonio collettivo della comunità urbana e non possono essere appropriati dai fornitori privati. L’ente pubblico deve riservarsi espressamente, già nel bando e nel contratto, i diritti d’uso su tali dati e risultati per i propri scopi istituzionali — incluse la ricerca, l’innovazione e la condivisione tra amministrazioni — in linea con il Regolamento (UE) 2023/2854 (Data Act), con il principio del risultato e di riuso del dato pubblico (art. 1 D. Lgs. 36/2023; artt. 50 e 52 D. Lgs. 82/2005; D. Lgs. 36/2006; artt. 68-69 D. Lgs. 82/2005) e con le raccomandazioni del Garante europeo della protezione dei dati nel Parere n. 3/2020.
3.Il principio di proporzionalità e minimizzazione: la raccolta di dati — personali e non — deve essere limitata a quanto strettamente necessario per le finalità del GDU, in applicazione del principio di minimizzazione ex art. 5(1)(c) GDPR. Tale principio, applicato al trattamento dei dati attraverso sistemi di IA, implica obblighi specifici di selezione e qualità dei dataset che il contratto con il fornitore deve tradurre in clausole esigibili.

Si raccomanda agli enti pubblici che intendono sviluppare un GDU di:

Inserire le clausole proposte come requisiti minimi inderogabili nei contratti con i fornitori privati, verificandone la coerenza con le Linee Guida Applicative (LGA) di futura elaborazione.
Riservarsi espressamente, già nel bando e nel contratto, i diritti d’uso sui dati e su tutti i risultati prodotti dall’operatore economico (modelli, algoritmi, elaborati, software, banche dati), per i propri scopi istituzionali — comprese la ricerca, l’innovazione e la condivisione tra amministrazioni — assicurando che tali diritti permangano oltre la durata del contratto e siano garantiti dal deposito in escrow.
Redigere prima dell'avvio del progetto un Piano di Ricognizione e Gestione dei Dati (PdRGD) come strumento di pianificazione giuridica, conformemente ai requisiti del GDPR, del Data Act e della Direttiva Open Data.
Considerare la partecipazione alle iniziative europee sui gemelli digitali locali (EDIC «Networked Local Digital Twins towards the CitiVERSE») e agli impegni comuni di Living-in.EU in materia di appalti, per condividere specifiche e pratiche contrattuali con altri enti.
Aggiornare le clausole contrattuali man mano che si consolida la prassi dell'EDPB e delle autorità nazionali di supervisione in materia di AI Act, Data Act e GDPR applicati ai sistemi di GDU.

9.12 Checklist operativa di sintesi

La checklist riepiloga gli adempimenti minimi per ciascuna fase. Può essere usata come strumento di autocontrollo dal RUP e dal RTD.

Fase	Adempimento minimo	Fatto
Programmazione	RTD individuato; finalità e dati definiti; DPIA preliminare; bozza PdRGD	☐
Bando	Requisiti minimi (DPO, ISO 27001, DMP FAIR); criteri di valutazione inseriti	☐
Capitolato	Specifiche T.1-T.5 e SLA/KPI misurabili recepiti	☐
Contratto	Clausole A-F inserite; in particolare C.0, C.1, D.1	☐
Diritti d'uso	Riserva dei diritti su dati e risultati per scopi istituzionali (D.1); escrow collegato	☐
Esecuzione	Audit programmati; Compliance Report; PdRGD aggiornato; LDV svolta	☐
IA (se presente)	Sei principi tradotti tecnicamente; Model Card e Datasheet acquisite	☐
Open Data	Dataset non personali pubblicati con licenza aperta e metadati DCAT-AP IT	☐

Note

B.F.G. Fabrègue, A. Bogoni, Privacy and Security Concerns in the Smart City, in Smart Cities 2023,6, p. 586-613. ↩︎
Ellen P Goodman., Smart City Ethics: How “Smart” Challenges Democratic Governance, in Markus D. Dubber, Frank Pasquale, and Sunit Das (eds), The Oxford Handbook of Ethics of AI (2020; online edn, Oxford Academic, 9 July 2020),pp. 823–839 https://doi.org/10.1093/oxfordhb/9780190067397.013.53, accesso alla data del 10 Sept. 2024 ↩︎