Di Gianluca Sivieri
Nessuno stop all’impiego da parte degli operatori di Polizia Locale, ma la necessità di un percorso di compliance adeguato.
La questione è tornata a far discutere, a volte anche a sproposito, dopo i provvedimenti del Garante sulle bodycam di Pescara, Cogoleto, Venezia, Bergamo e Brescia.
Finalità, base giuridica, consultazione preventiva sì o no, trasferimento di dati in Paesi terzi: un’analisi dello stato dell’arte dal punto di vista giuridico e tecnico.
Ci si ritrova di nuovo ad affrontare il tema delle telecamere indossabili per gli agenti di Polizia Locale. E sembra sempre una partita che si gioca sul tema “chi fa cosa” e l’eterna contrapposizione tra il ruolo della Polizia Locale e quello delle Forze di polizia dello Stato.
Non solo.
Come da consuetudine tutta italiana, fioccano gli schieramenti “bodycam sì” o “bodycam no”. Oltre a chi è perentorio “si deve fare così”.
In realtà, come per qualsiasi altro trattamento di dati personali, le regole sono “semplici”: il rispetto del perimetro delineato dai principi in materia di protezione dei dati e la “costruzione” di una governance solida. Perché – nemmeno tanto in fondo – questa è la sostanza dell’accountability.
Il decennio delle bodycam: tra entusiasmo e accountability
Come si diceva, non si tratta di un discorso nuovo. È, però, una questione sulla quale sono state molte le evoluzioni, i punti di vista e, a volte, anche le prese di posizione.
Si è passati da una disinvoltura preoccupante, alla necessità di un maniacale livello di dettaglio nella definizione degli aspetti giuridici e tecnici.
Il panorama risulta quindi pericolosamente eterogeneo. Alcuni comandi si sono dati da fare nel sistemare, al meglio del possibile, anche la questione privacy, altri hanno liquidato la protezione dei dati in favore di un “interesse superiore”, infine quelli che, per non saper né leggere né scrivere, hanno preferito scongiurare qualsiasi preoccupazione evitando proprio l’acquisto delle bodycam.
In passato, vigeva indiscussa la logica secondo cui la tutela della sicurezza dell’operatore superava qualsiasi dubbio, anche a costo di lasciare gli agenti acquistare autonomamente dei dispositivi di videoripresa. Circostanza che capita – come abbiamo visto di recente – in tutte le polizie italiane.
La realtà oggi è però cambiata, ma non ovunque. Il tema è tornato all’ordine del giorno in più occasioni: se nel decennio scorso la dottrina e i precedenti erano decisamente scarsi, lo scenario si è via, via popolato di nuove indicazioni e nuovi punti di vista, ma anche di una disciplina in materia di protezione dei dati personali decisamente più profonda.
Ora, però, letture troppo superficiali e a volte poco pragmatiche, rischiano nuovamente di far perdere l’occasione di dotare la Polizia Locale di questi preziosi strumenti.
I provvedimenti “gemelli” del 2021: GDPR vs. D.Lgs. 51/2018
Una frenata decisa è arrivata a luglio 2021. O, almeno, tanti così l’hanno interpretata.
Il 22 luglio 2021 il Garante per la protezione dei dati personali ha adottato due provvedimenti distinti, ma speculari – il n. 290 e il n. 291 – relativi, rispettivamente, alla valutazione di impatto (DPIA) elaborata dal Ministero dell’Interno per un sistema di bodycam da assegnare ai reparti mobili della Polizia di Stato per la documentazione audio e video di situazioni critiche per l’ordine e la sicurezza in occasione di eventi o manifestazioni pubbliche, e all’analogo sistema progettato dal Comando Generale dell’Arma dei Carabinieri. La prima “sperimentazione” era stata avviata nel 2014.
In entrambi i casi il Garante ha espresso un parere favorevole, imponendo tuttavia un insieme di prescrizioni operative: in particolare, l’attivazione delle telecamere indossabili può avvenire solo qualora sussista un pericolo di turbamento dell’ordine pubblico o in presenza di fatti di reato, non è ammessa la registrazione continua delle immagini, né quella di episodi non critici e i dati raccolti possono essere conservati per un periodo di sei mesi. Centrale, in entrambi i provvedimenti, è poi l’esplicito divieto di ricorso al riconoscimento facciale: l’Autorità ha chiesto espressamente di specificare che il sistema non lo consentisse.
Sul piano della quantificazione e qualificazione del rischio, il Garante ha ritenuto che i trattamenti in esame ricadessero nell’alveo dell’art. 24 del D.Lgs. 51/2018, con conseguente obbligo di consultazione preventiva dell’Autorità.
La motivazione ruota attorno alla natura dell’ambito operativo: il contesto sociale di utilizzo del sistema, costituito da manifestazioni pubbliche, rende estremamente probabile il trattamento di categorie particolari di dati personali – quali quelli che rivelino l’origine razziale o etnica, le opinioni politiche, le convinzioni religiose o filosofiche, l’appartenenza sindacale ovvero l’orientamento sessuale della persona – a seconda della motivazione della manifestazione; pertanto l’attività di trattamento va considerata ad elevato rischio per gli interessati.
A ciò si aggiunge, secondo l’Autorità, la concreta probabilità di rischi quali discriminazione, sostituzione d’identità, pregiudizio per la reputazione e ingiusta privazione di diritti e libertà per le persone riprese.
I due provvedimenti costituiscono dunque il primo e più strutturato riferimento regolatorio sull’uso delle bodycam nel contesto delle Forze dell’Ordine italiane, definendo un modello che, se da un lato ha guidato le esperienze successive, dall’altro ha destato preoccupazione soprattutto nella Polizia Locale.
Il caso di Torino: uno spunto sulla base giuridica e sulla consultazione preventiva
Con una nota del 22 marzo 2023, il Garante per la protezione dei dati personali si è pronunciato sull’istanza di consultazione preventiva presentata dal Comune di Torino ai sensi dell’art. 36 del GDPR, relativa al progetto del Corpo di Polizia Locale relativo all’utilizzo – in determinate situazioni operative – delle cosiddette bodycam.
Sono due gli aspetti interessanti di questo parere, non un provvedimento, ma un riscontro diretto. L’Autorità, da un lato, ha dichiarato l’istanza improcedibile per difetto dei presupposti di legge, quindi senza entrare nel merito della valutazione d’impatto presentata. Ma su questo ci torneremo a breve.
Dall’altro lato, ha comunque colto l’occasione per rilevare alcune criticità, offrendo indicazioni operative destinate a orientare l’attività dei Comandi di Polizia Locale che si dovessero accingere a introdurre questo tipo di dispositivi. Tra i profili più significativi emergono l’individuazione della corretta base giuridica del trattamento e i confini stessi dell’obbligo di consultazione preventiva.
Un profilo di particolare interesse riguarda l’individuazione della corretta base giuridica per l’impiego delle bodycam. Il Garante chiarisce che i Decreti-legge n. 11/2009 e n. 14/2017, richiamati dal Comune di Torino come fondamento del trattamento, non potevano essere invocati: tali norme disciplinano esclusivamente la videosorveglianza in luogo pubblico per finalità di sicurezza urbana e prevenzione della criminalità diffusa e predatoria, presupponendo peraltro – a detta del Garante – la stipula di appositi accordi con la Prefettura.
Secondo l’Autorità – ed è condivisibile – le bodycam, per loro natura, non costituiscono una “particolare forma” di tale videosorveglianza e non possono quindi fondarsi su questo presupposto normativo. La base giuridica corretta va invece individuata, caso per caso, nell’art. 4 della legge n. 300/1970 (Statuto dei Lavoratori), che consente l’impiego di impianti audiovisivi e di altri strumenti da cui derivi anche la possibilità di controllo a distanza dell’attività dei lavoratori, esclusivamente per esigenze organizzative e produttive, per la sicurezza del lavoro e per la tutela del patrimonio aziendale: nel caso delle bodycam, il loro impiego è sicuramente riconducibile a esigenze di tutela dell’incolumità degli operatori di Polizia Locale in situazioni di pericolo, ma anche a esigenze organizzative connesse alla documentazione di specifiche operazioni. Ne consegue l’applicazione delle relative garanzie procedurali (accordo sindacale o autorizzazione dell’Ispettorato del lavoro).
Sul piano procedurale, il Garante ha invece dichiarato l’istanza di consultazione preventiva improcedibile per difetto dei presupposti ex art. 36 del GDPR. Secondo il Regolamento, infatti, la consultazione preventiva è dovuta solo quando la DPIA rilevi un rischio elevato che il titolare non è in grado di ridurre a un livello accettabile con le misure adottate (rischio residuo comunque elevato).
Nel caso di specie, la valutazione d’impatto presentata dal Comune di Torino attestava valori di rischio residuo di “piena accettabilità”, tali da giustificare e legittimare l’avvio del trattamento senza necessità di interpellare l’Autorità: mancando quindi in radice il presupposto che attiva l’obbligo di consultazione, quest’ultima non è prevista e l’istanza non poteva essere esaminata nel merito.
Bodycam alla Polizia Locale: l’art. 4 dello Statuto dei Lavoratori supera il test, ma la trasparenza resta il vero banco di prova
Non solo con il parere riservato al Comune di Torino, ma anche dalla conferma in altri due provvedimenti (sanzionatori) del Garante, si rileva la bontà della stessa base giuridica e delle medesime finalità perseguite da altre Polizie locali. Insomma, l’accordo sindacale previsto dallo Statuto dei Lavoratori costituisce fondamenta solide, ma la casa va costruita con pareti trasparenti.
Le bodycam della Polizia Locale al banco di prova del GDPR: il caso di Cogoleto
Con il provvedimento n. 271 del 17 aprile 2026, il Garante ha sanzionato il Comune di Cogoleto per aver dotato gli agenti di Polizia Locale di bodycam – in via sperimentale – senza rispettare le prescrizioni della normativa in materia di protezione dei dati personali.
L’istruttoria in questo caso è partita da una segnalazione, secondo cui il Comune aveva acquistato quattro dispositivi indossabili, da impiegare con funzioni di deterrenza e per documentare situazioni di rischio per l’incolumità degli agenti, come nei casi di aggressione fisica o frasi gravemente oltraggiose o minacciose.
Al di là di ciò, il provvedimento fornisce un’articolata ricostruzione della base giuridica applicabile e lucide considerazioni svolte in materia di consenso dei lavoratori, che meritano un’analisi separata.
Sul piano delle finalità e della base giuridica, il Garante ha chiarito con nettezza il quadro normativo di riferimento per i Comuni che intendano dotare la propria Polizia Locale di bodycam. Qualora le bodycam siano impiegate al fine di prevenire e documentare eventuali situazioni di pericolo per chi le indossa, specialmente nei casi di aggressione fisica o verbale, trovano applicazione le norme che disciplinano l’impiego di dispositivi di audio-video ripresa negli ambiti in cui si svolge l’attività lavorativa, stante l’idoneità di questi strumenti a tracciare, seppur in via indiretta e preterintenzionale, l’attività dei lavoratori.
La base giuridica del trattamento richiede il rispetto della disciplina di settore: i trattamenti conseguenti all’impiego degli strumenti tecnologici nei luoghi di lavoro trovano la propria base giuridica nell’art. 4 della Legge 300/1970 (Statuto dei Lavoratori), il cui comma 1, prevede che gli impianti audiovisivi e gli altri strumenti dai quali possa derivare anche la possibilità di controllo a distanza dell’attività dei lavoratori possano essere impiegati esclusivamente per esigenze organizzative e produttive, per la sicurezza del lavoro e per la tutela del patrimonio aziendale, e possano essere installati previo accordo sindacale o, in mancanza dell’autorizzazione della sede territorialmente competente dell’Ispettorato nazionale del lavoro.
Il Comune censurato dal Garante, in realtà, aveva prodotto un accordo sindacale risalente al 2017 in materia di videosorveglianza, ma l’Autorità l’ha ritenuto del tutto inidoneo: tale accordo si riferiva all’installazione delle apparecchiature di videosorveglianza nel contesto della sede municipale e in altre postazioni del territorio comunale, non riguardando pertanto l’impiego delle bodycam.
La questione più rilevante sul piano sistematico riguarda tuttavia il consenso dei lavoratori, che nel caso in esame erano stati essi stessi a richiedere insistentemente la dotazione delle bodycam e ad acconsentire espressamente al loro utilizzo.
Il Garante ha escluso con fermezza che tale circostanza potesse costituire un’idonea base giuridica del trattamento. Stante la asimmetria contrattuale connaturata dal rapporto di lavoro, il consenso dei lavoratori non costituisce, di regola, un’idonea base giuridica per i trattamenti di dati personali in ambito lavorativo.
Questa valutazione vale, precisa l’Autorità, anche quando il titolare del trattamento è un soggetto pubblico, richiamando il considerando 43 del GDPR, secondo il quale lo squilibrio tra titolare e interessato sussiste specie quando il titolare del trattamento è un’autorità pubblica e ciò rende pertanto improbabile che il consenso sia stato espresso liberamente in tutte le circostanze di tale situazione specifica.
Ma il punto più dirompente è un altro: il consenso dei lavoratori, anche se espresso in forma scritta, non è idoneo a esonerare il datore di lavoro dall’obbligo di esperire le procedure di garanzia previste dall’articolo 4, della Legge 300/1970, poiché – come richiamato anche dall’Ispettorato nazionale del lavoro – il bene giuridico tutelato da quella disposizione ha natura collettiva e non individuale, e la sua carenza non può essere supplita dall’assenso dei singoli.
Al di là della sanzione irrogata al Comune, il provvedimento ha un importante valore orientativo per tutti i Comuni italiani: le bodycam per la Polizia Locale richiedono un accordo sindacale specifico, non generico, e il consenso degli agenti – per quanto sincero – non vale nulla ai fini della liceità del trattamento.
Il caso di Venezia lo conferma: fondamentali le informative
Nell’agenda del Garante, subito dopo il caso di Cogoleto, viene quello di Venezia. Infatti è con il provvedimento immediatamente successivo, il n. 272 del 17 aprile 2026, che l’Autorità ha dichiarato illecito il trattamento effettuato dal Comune di Venezia mediante le bodycam in dotazione ad alcuni agenti del Corpo di Polizia Locale, attivate automaticamente all’estrazione della pistola a impulsi elettrici (“Taser”), per documentare le situazioni di rischio per l’incolumità dell’operatore.
L’istruttoria, avviata dopo notizie di stampa, si è conclusa con un esito duplice: da un lato l’archiviazione del profilo relativo alla valutazione d’impatto, avendo il Comune dimostrato di aver svolto una DPIA già nel luglio 2022, prima della consegna effettiva dei dispositivi; dall’altro la conferma della violazione del principio di trasparenza.
Il punto di maggiore interesse per gli operatori del settore riguarda proprio quest’ultimo profilo. Il Comune di Venezia infatti aveva individuato correttamente la base giuridica del trattamento in un accordo sindacale stipulato ai sensi dell’articolo 4 dello Statuto dei Lavoratori e riteneva di aver assolto l’obbligo informativo attraverso l’invio agli agenti di delibere, disposizioni di servizio, DPIA e manuale operativo, oltre a specifiche attività formative.
Il Garante ha invece censurato questa impostazione, chiarendo che tali atti – comunque necessari e correttamente redatti nel rispetto delle esigenze amministrative e organizzative – non possono sostituire un’informativa specifica e scritta, e che nemmeno la formazione può colmare questa lacuna se non è comprovato che abbia coperto tutti gli elementi richiesti dall’articolo 13.
Ha inoltre ritenuto inadeguata l’informativa pubblicata sul sito istituzionale, in quanto rivolta ai cittadini eventualmente ripresi e priva di ogni riferimento all’accordo sindacale o alla base giuridica specifica del rapporto di lavoro.
Ne emerge un principio di portata generale, già in passato indicato e destinato a orientare la prassi di molti enti locali: liceità e trasparenza sono requisiti autonomi e cumulativi, e la correttezza della base giuridica non esime il titolare dal predisporre un’informativa specifica per i lavoratori.
Brescia, Bergamo, Pescara: tre pareri sfavorevoli, una lezione comune
Ci sono provvedimenti del Garante che si leggono come sentenze e altri che si leggono come cronache. Questi tre appartengono alla seconda categoria: raccontano, con dovizia di dettagli quasi romanzeschi, la stessa storia raccontata tre volte da tre protagonisti diversi: un Comune convinto di aver fatto i compiti, un’Autorità che ricontrolla riga per riga e un fornitore tecnologico che, puntualmente, si scopre custode di una chiave che non dovrebbe avere.
Tutti e tre i capoluoghi di provincia, nell’ottica di avviare il trattamento di dati personali mediante bodycam in uso alla Polizia Locale, hanno avviato una consultazione preventiva ai sensi dell’art. 24 del D.Lgs. 51/2018. Tutte e tre hanno avuto esito negativo.
Il provvedimento n. 425/2026 relativo al Comune di Brescia, ultimo in ordine cronologico, si inserisce in una linea che il Garante ha già tracciato con nettezza nei confronti di Bergamo (n. 191/2026) e Pescara (n. 743/2025), pur muovendo da angolazioni tecniche distinte.
Brescia: quando il contratto dice troppo poco per dire abbastanza
Il fascicolo bresciano parte da una prima DPIA che dimostra un lavoro decisamente ben condotto sia sul piano tecnico che giuridico. Nonostante questo, il Garante ha sollevato un elenco di criticità che hanno portato il Comune a presentare una seconda versione il un paio di mesi più tardi.
Ne passano altri otto circa, quando con il parere sfavorevole del 11 giugno 2026, il Garante chiude l’istruttoria.
Sul piano tecnico l’impianto non è male: bodycam con crittografia integrata su memoria non accessibile, un cloud europeo con data center in Europa, retention di sette giorni prorogabile – valutata caso per caso – fino a un massimo di sei mesi per attività investigativa. E ancora, le funzioni di intelligenza artificiale (redaction, che oscura automaticamente informazioni sensibili, e Automated People Detection, che segnala la presenza di persone senza attribuire identità né effettuare riconoscimento facciale) sono descritte con una trasparenza che il Garante non contesta.
Ecco. Il problema non è cosa fa il sistema, ma chi lo controlla. Le chiavi crittografiche – sia quelle delle bodycam sia quelle del cloud – restano “conosciute esclusivamente dal produttore”: formula innocua in apparenza, che il Garante legge come una vera e propria cessione di sovranità digitale, in violazione degli artt. 5, comma 1, e 25 del D.Lgs. 51/2018.
A questo si aggiungono altre quattro criticità puntuali. L’informativa del fornitore cloud, richiamata via link nella DPIA, ammette che i “non-content data” possono finire fuori SEE e che il fornitore può condividerli con controllate e terze parti per finalità di sviluppo prodotto e “security monitoring”. Qui il Garante coglie l’occasione per una precisazione tecnico-giuridica non scontata: le clausole contrattuali standard, lo strumento principe del GDPR, non sono contemplate dalla Direttiva 2016/680 né dal decreto di attuazione, quindi “inconferenti” in questo perimetro.
La clausola sui “non-content data”, secondo l’Autorità, è poi scritta in modo particolarmente ambiguo: qualifica quei dati come personali solo “nella misura in cui… siano considerati” tali – una formula che non impegna a nulla.
Il sub-responsabile, infine, viene individuato con una tabella di due righe – nome e ubicazione dei data center – invece che con la verifica approfondita che l’art. 18, comma 1, del Decreto (e il parere EDPB 22/2024, richiamato esplicitamente) avrebbero richiesto per un trattamento ad alto rischio e il link alla privacy notice di quel sub-responsabile rivela data center in una ventina di giurisdizioni, anche extra-UE.
In realtà, il Garante fornisce un ragionamento più fine. Indipendentemente da dove si trovano fisicamente i dati, con tutta probabilità in Europa, il trasferimento in paesi terzi si concretizza anche quando i data center, siano sotto il controllo – più o meno diretto – di un fornitore stabilito in un paese terzo quando – come nel caso di Brescia – questo ha la disponibilità esclusiva delle chiavi crittografiche utilizzate per conservare i dati in modo “sicuro”: secondo l’Autorità questo implica l’impossibilità per il titolare di escludere un accesso ai dati da parte del fornitore extra-UE e di conseguenza un trasferimento di dati.
Il colpo di grazia arriva da un dettaglio che il Garante scova, sembra quasi per caso, in fondo all’Accordo di designazione: il Comune aveva già acquistato trentacinque licenze del sistema nel giugno 2022, ben prima di chiedere la consultazione preventiva.
Bergamo: la geografia che non basta
Bergamo è il caso più lungo e il più istruttivo sul piano tecnico: tre versioni della DPIA tra marzo 2024 e marzo 2026, con un Garante che entra nei dettagli con una precisione quasi da collaudatore.
Il sistema, sei bodycam con applicativo dedicato, ha una caratteristica tecnica che vale la pena notare: registra in continuo su una memoria locale a rotazione di 30 secondi, e quando l’agente attiva la ripresa il dispositivo salva anche i 30 secondi precedenti l’attivazione – il che significa che la bodycam “vede” anche quando sembra spenta.
La prima versione della DPIA contiene però un errore da manuale: il server che ospita le registrazioni – fornito da una società stabilita al di fuori dell’Unione Europea e gestito su infrastruttura di un partner anch’esso extra-UE.
Trasferimento verso un Paese terzo, contesta l’Ufficio, senza nessuna delle condizioni che l’art. 31, comma 1, lett. b) del D.Lgs. 51/2018 richiede per renderlo lecito (il destinatario dovrebbe essere un’autorità di law enforcement, non un fornitore commerciale).
Il Comune corre ai ripari e, nella seconda versione, sposta dichiaratamente il server dentro il territorio SEE, aggiungendo dettagli su disattivazione GPS/WiFi e autenticazione multifattore. Correzione apparentemente risolutiva: ed è qui che il caso diventa davvero interessante, perché il Garante non si accontenta della geografia. Nelle osservazioni formulate chiede dettagli tecnici più fini sulla componente cloud, richiamando espressamente l’art. 16 del Decreto (protezione fin dalla progettazione) e l’art. 18, comma 3, lett. e) (obbligo di verificare che il fornitore documenti l’adeguatezza delle proprie misure).
Nella terza versione emerge, dalla stessa documentazione tecnica del fornitore, una frase che vale da sola l’intero provvedimento: una volta arrivati al server, “i dati sono decifrati e trasferiti in un ambiente di stoccaggio sicuro”. Tradotto: le chiavi non sono del Comune, sono del fornitore e il fornitore è extra-UE.
Da qui il principio che rende Bergamo il precedente più citabile dei tre. Spostare il server non serve a nulla se l’accesso resta nelle mani di chi sta fuori dall’Unione: “l’accesso remoto… da parte di soggetti stabiliti al di fuori dell’Unione Europea configura, comunque, un trasferimento di dati verso Paesi terzi”, indipendentemente da dove si trovi fisicamente il disco.
Il Garante chiude notando che la soluzione tecnica era stata scelta “come un presupposto” fin dall’inizio, non come esito di una comparazione, identica, quasi testualmente, alla critica di metodo mossa a Brescia.
Pescara: tre anni per arrivare al no
Se Brescia e Bergamo raccontano un’istruttoria serrata, Pescara racconta una maratona: prima versione della DPIA ad ottobre 2022, e un botta e risposta proseguito fino al parere finale del 4 dicembre 2025.
Oltre tre anni, quattro round completi. Un dato che da solo racconta la distanza tra l’entusiasmo tecnologico iniziale dei Comuni e la complessità reale di una DPIA per trattamenti di polizia giudiziaria.
Il Comune corregge alcune cose e ne lascia intatte altre con una certa ostinazione. Continua a citare, ad esempio, il D.P.R. 15/2018 come base giuridica, nonostante il Garante avesse già segnalato – fin dalla prima nota – che dall’applicazione di quel regolamento la Polizia Locale rimane esclusa. Esclusione ormai pacifica. Il riferimento rimane “senza alcuna motivazione” anche nella quarta versione (un’incongruenza che, va detto, a Bergamo il Garante non solleva con la stessa fonte normativa, segno che il vaglio non è sempre uniforme).
Restano irrisolti però anche dettagli minori, ma rivelatori: la presenza di SIM nelle bodycam, mai giustificata nonostante la richiesta esplicita; la durata di conservazione dei log, mai precisata con termine certo; un’antinomia tra la DPIA (che prevede cloud “certificato e qualificato AGID”) e il Disciplinare operativo (che all’art. 8 ammette, in alternativa, un generico “server dedicato dell’amministrazione comunale… con password individuali”), da cui il Garante trae un principio metodologico netto: la scelta della modalità di conservazione deve precedere, non seguire, la DPIA, perché è la DPIA a dover descrivere il sistema effettivamente adottato, non uno tra due scenari alternativi.
Ma il punto che rende Pescara il caso più utile per chi lavora con fornitori certificati è un altro. Il sistema in questione – di un’azienda extra UE – risulta effettivamente censito nel marketplace ACN come servizio cloud qualificato di livello 2 (QC2). Il Garante lo riconosce senza ironia: tali elementi “certamente concorrono ad aumentare la fiducia sulla robustezza del sistema… nei confronti di eventuali attacchi esterni provenienti da cybercriminali”. Ma nella frase immediatamente successiva arriva la doccia fredda: restano “non… disponibili sufficienti dettagli tecnici sul processo di gestione delle chiavi crittografiche che consentano di escludere” l’accesso del fornitore ai dati in chiaro.
È la conferma, dalla fonte più autorevole possibile, che una qualificazione di sicurezza informatica non è una certificazione di sovranità sui dati: rispondono a due domande diverse – resistenza agli attacchi esterni, la prima; controllo delle chiavi e liceità del trasferimento, la seconda – e superare la prima non dice nulla sulla seconda. Il parere finale richiama lo stesso principio sull’accesso remoto visto poi a Bergamo, specificando che il fornitore al di fuori dell’Unione Europea non è “un’autorità competente per finalità di law enforcement”, condizione che l’art. 31, comma 1, lett. b) del D.Lgs. 51/2018 pone come presupposto imprescindibile.
Il filo conduttore dei tre pareri
In tutte e tre le consultazioni il vizio non è mai l’uso della bodycam in sé, né la finalità di polizia giudiziaria: la base giuridica non viene mai seriamente contestata.
Spogliati dei dettagli tecnici, i tre casi raccontano lo stesso equivoco di fondo, ripetuto con variazioni minime: i Comuni scelgono un fornitore per reputazione, certificazioni, presenza (dichiarata) in Europa – e si fermano lì, convinti che basti. Il Garante, con la pazienza di chi ha già visto la stessa scena tre volte, chiede sempre la stessa cosa: non dove sta il server, ma chi ha in mano la chiave.
È una domanda semplice, quasi banale a dirla così, ma è quella che nessuno dei tre Comuni ha saputo rispondere con la documentazione tecnica alla mano. Per chi oggi deve costruire una DPIA su bodycam, la lezione cumulata di Pescara, Bergamo e Brescia si riduce, in fondo, a una sola (o quasi) accortezza: prima di firmare il contratto con il fornitore, chiedersi chi può decifrare quei dati – e pretendere che la risposta sia scritta nero su bianco nell’accordo, non lasciata a una nota a piè di pagina della privacy policy.
Il nodo è sempre lo stesso, riproposto in tre salse: la sovranità sulle chiavi crittografiche e il conseguente rischio di trasferimento extra-UE, aggravato dal fatto che in tutti e tre i casi la scelta del fornitore/piattaforma risulta cronologicamente anteriore, e quindi condizionante, rispetto alla valutazione d’impatto. Un ordine logico invertito che il Garante segnala esplicitamente come sintomo di un approccio non by design: un pilastro della normativa UE in materia di protezione dei dati personali, ancora lontano dalle abitudini italiane. A volte per cultura, a volte per oggettiva difficoltà operativa.
Prima si compra, poi si valuta: è il peccato originale che accomuna tutti e tre i casi: questo è il monito che arriva dal Garante. L’inversione di questo percorso è invece la risposta a tutte le domande.
I “no” tecnici: problemi e (possibili) soluzioni
Per un ente che debba redigere oggi una DPIA su bodycam, la lezione cumulata dai tre provvedimenti è che la richiesta, neanche troppo implicita, del Garante è ormai uno standard minimo: controllo esclusivo (o quantomeno documentato e verificabile) delle chiavi da parte del titolare, mappatura granulare di ogni sub-responsabile con relativa ubicazione dei data center, ed esclusione contrattualmente comprovata – non solo dichiarata – di ogni trasferimento verso Paesi terzi, “content” e “non-content data” inclusi.
Il trasferimento extra-SEE: due regimi giuridici, non uno
Il punto di contatto tra normativa e aspetti tecnici, a volte richiede approfondimenti particolarmente complessi.
Il GDPR disciplina i trasferimenti verso Paesi terzi al Capo V: in assenza di una decisione di adeguatezza – che esistono rispetto a diversi paesi terzi – il titolare può fare ricorso a garanzie adeguate – tipicamente le clausole contrattuali standard – integrate da una Transfer Impact Assessment che valuti se la legislazione del Paese terzo consenta un accesso pubblico ai dati che svuoterebbe di efficacia le clausole standard, e da eventuali misure ulteriori (supplementary measures).
Il D.Lgs. 51/2018, che attua la Direttiva UE 2016/680 e disciplina i trattamenti di law enforcement, segue una logica strutturalmente diversa e più rigida: il trasferimento è ammesso solo verso un’autorità competente di un Paese terzo per le medesime finalità di prevenzione/accertamento/perseguimento di reati (art. 31, c. 1, lett. b), la disposizione che ricorre, identica nella sostanza, in tutti e tre i dispositivi finali di Brescia, Bergamo e Pescara), oppure verso singoli destinatari diversi in casi individuali e non sistematici (art. 35), con garanzie valutate caso per caso o tramite uno strumento giuridicamente vincolante.
Il vero game changer tecnico-giuridico, è che le SCC della Commissione, lo strumento principe nel mondo GDPR, non sono contemplate dalla Direttiva UE 2016/680, né dal D.Lgs. 51/2018: lo dice testualmente il Garante nel caso Brescia (“il meccanismo delle clausole contrattuali-tipo non è contemplato dalla Direttiva 680/2016 e dal Decreto, onde è inconferente”).
Una soluzione contrattuale praticabile nel perimetro GDPR non è automaticamente utilizzabile in quello del D.Lgs. 51/2018, nel quale il trasferimento di dati verso Paesi terzi è assoggettato a presupposti e garanzie differenti e, in via generale, più restrittivi.
Le qualificazioni ACN, di nuovo
Il caso Pescara offre la conferma empirica più netta di quanto osservato in astratto: il fornitore (extra-UE) del sistema di gestione dati risulta effettivamente censito nel catalogo ACN come servizio SaaS di livello QC2. Il Garante lo riconosce esplicitamente – tali elementi “certamente concorrono ad aumentare la fiducia sulla robustezza del sistema… nei confronti di eventuali attacchi esterni provenienti da cybercriminali” – per poi, nella frase immediatamente successiva, circoscriverne il perimetro: restano “non… disponibili sufficienti dettagli tecnici sul processo di gestione delle chiavi crittografiche che consentano di escludere” l’accesso del fornitore ai dati in chiaro. È la dimostrazione dalla fonte primaria che QC1/QC2 certificano resilienza a minacce esterne (art. 32 GDPR e, in questo caso per analogia, art. 25 del D.Lgs. 51/2018: sicurezza in senso tecnico-perimetrale), ma non sono sufficienti a garantire la liceità del trasferimento, né la sovranità sulle chiavi: sono piani distinti, e un ente che si fermasse alla qualificazione ACN commetterebbe lo stesso errore di metodo sanzionato in tutti e tre i provvedimenti.
Un fornitore QC2 con data center in Europa può comunque essere soggetto, in quanto controllato da una casa madre al di fuori dell’Unione, a normative extraterritoriali che rendono il dato aggredibile indipendentemente dalla sua ubicazione fisica: è esattamente il rilievo che il Garante muove a Brescia, richiamando la “natura globale delle infrastrutture” come fattore che impedisce di escludere richieste di autorità di Paesi terzi.
Come si prova (davvero) il mancato trasferimento extra-SEE
Non basta una dichiarazione nella DPIA secondo cui “i dati non lasciano l’UE”: il Garante, in tutti e tre i casi, ha preteso evidenza documentale e tecnica. Gli elementi che reggono in sede istruttoria sono:
- una mappa dei flussi dati aggiornata e verificabile, con indicazione contrattualmente vincolante (non solo dichiarativa) dell’ubicazione di ogni componente infrastrutturale, inclusi i sub-responsabili;
- l’esclusione contrattuale di accesso remoto da personale o entità stabilite fuori UE. Il principio-cardine di Bergamo: l’accesso remoto da un Paese terzo costituisce trasferimento, a prescindere dalla localizzazione fisica del server;
- un’analisi – per quanto non formalmente imposta dal D.Lgs. 51/2018 come lo è la TIA in ambito GDPR – dell’esposizione giuridica del fornitore a normative extraterritoriali;
- e infine, elemento decisivo, il controllo effettivo sulle chiavi crittografiche.
Il nodo crittografia: cos’è, come funziona, perché decide tutto
La crittografia è la trasformazione di un dato leggibile in una forma illeggibile mediante un algoritmo e una chiave. Solo chi possiede la chiave corretta può invertire il processo. Si distingue tra crittografia simmetrica (stessa chiave per cifrare e decifrare, tipicamente AES-256, efficiente, ma con il problema della distribuzione sicura della chiave) e asimmetrica (coppia chiave pubblica/privata, più onerosa ma priva di quel problema); e tra crittografia at rest (quando i dati sono archiviati su disco), in transit (dati in trasmissione) ed end-to-end, dove nemmeno gli intermediari infrastrutturali possono accedere al contenuto in chiaro.
Il punto che sposta l’ago della bilancia non è però l’algoritmo, ma la gestione del ciclo di vita della chiave: dove viene generata, dove viene custodita, chi vi ha accesso. Qui si collocano tre modelli con implicazioni giuridiche molto diverse: provider-managed keys, dove il fornitore genera e detiene le chiavi (la situazione fotografata identicamente in Brescia, Bergamo e Pescara: “conosciute esclusivamente dal produttore”); BYOK (Bring Your Own Key), dove il cliente genera la chiave, ma la affida comunque all’infrastruttura del provider, che quindi potrebbe utilizzarla; e HYOK (Hold Your Own Key), dove il titolare mantiene il controllo esclusivo della chiave in un proprio HSM (Hardware Security Module), sottratto per costruzione a qualunque accesso del fornitore.
Nel primo scenario – quello censurato in tutti e tre i provvedimenti – un fornitore extra-UE (o controllato da soggetto extra-UE) può essere legalmente costretto a decifrare i dati anche se questi risiedono fisicamente su server europei: la localizzazione geografica diventa, in questi termini, un dato sostanzialmente decorativo rispetto al controllo giuridico-tecnico effettivo.
È la ragione per cui le Raccomandazioni EDPB 01/2020 individuano nella cifratura con chiavi detenute esclusivamente dall’esportatore una delle poche supplementary measures davvero efficaci contro l’accesso extraterritoriale.
Le criticità del Garante, ricondotte a sistema
Riletti tra le righe, i tre pareri contestano tutti la medesima cosa con parole diverse: l’assenza di controllo esclusivo del titolare sulle chiavi crittografiche impedisce di escludere che il fornitore – soggetto, direttamente o tramite la casa madre, a giurisdizioni terze – possa accedere ai dati in chiaro, e ciò a prescindere da dove siano fisicamente collocati i server. È un rilievo che unifica il vizio “contrattuale” di Brescia (accordo di responsabile generico sulle modalità di trattamento) e quello “tecnico” di Bergamo (descrizione insufficiente delle misure di sicurezza della componente cloud): entrambi, alla radice, sono manifestazioni dello stesso deficit di governance delle chiavi.
Come superare il rilievo
La strada che i tre provvedimenti, letti insieme, tracciano implicitamente per gli enti che intendono impiegare un sistema in cloud porta a ritenere che una delle architetture tecniche più efficaci sia l’adozione di un modello HYOK, in cui il modulo di sicurezza è sotto il controllo esclusivo del titolare o di un soggetto terzo stabilito in UE e (certamente) non soggetto a normative extraterritoriali.
Non basta, nella DPIA dovrà essere documentato, con dettaglio tecnico verificabile e non genericamente descrittivo, l’algoritmo, la lunghezza della chiave, il ciclo di vita (generazione, rotazione, distruzione) e il luogo di custodia; ancora, dovrà essere negoziata e contrattualizzata esplicitamente, nell’atto di designazione del responsabile, la clausola per cui il fornitore non ha, né può avere accesso alle chiavi; e, soprattutto per i trattamenti rientranti nel D.Lgs. 51/2018 – dove, va ribadito, le SCC non sono spendibili – orientarsi con decisione verso fornitori europei privi di esposizione a giurisdizioni terze, piuttosto che tentare di rattoppare con clausole contrattuali un modello architetturale che resta, alla radice, strutturalmente incompatibile con il regime del law enforcement.
L’ipotesi on-premise: percorribile, ma non risolutiva di per sé
C’è un’alternativa architetturale, l’unica che può eliminare il problema alla radice, ed è tanto ovvia quanto trascurata nel dibattito corrente: portare tutto in casa. Purché l’intera catena infrastrutturale sia effettivamente sotto il controllo del titolare.
Un server on-premise, con le chiavi custodite in un modulo hardware dedicato sotto il controllo esclusivo del Comune, interrompe la catena prima ancora che possa formarsi. Se nessun soggetto extra-UE compare nell’infrastruttura, nessun soggetto extra-UE può essere costretto a fornire l’accesso.
Non è un’intuizione peregrina: lo stesso Disciplinare di Pescara la contemplava, in alternativa al cloud, come ipotesi di “server dedicato dell’amministrazione comunale”. Il problema, lì, non era l’idea, ma l’esecuzione: descritta in modo superficiale con indicazioni tipo “password individuali” e “soggetti autorizzati”, che non hanno retto comunque il vaglio del Garante. Il che dice qualcosa di importante, e vale la pena scriverlo esplicitamente: l’architettura, da sola, non basta. Conta anche il dettaglio tecnico con cui viene documentata, cloud o no.
E prima di consigliare l’on-premise come panacea agli enti locali che leggessero questa soluzione come una via d’uscita facile, è onesto elencarne il conto.
Prima di tutto, se l’ente rientra nel perimetro della Strategia Cloud Italia per altri servizi, un ritorno all’on-premise per uno specifico trattamento va comunque motivato nella DPIA in termini di proporzionalità e non esonera dall’applicazione delle misure minime AGID/ACN in materia di sicurezza informatica, che restano trasversali a prescindere dal modello architetturale.
Portare il server in casa significa portare in casa anche l’intera responsabilità della sicurezza – patching, monitoraggio, continuità operativa,… – compiti che un hyperscaler certificato svolge di mestiere e che un modesto ufficio IT comunale rischia di gestire peggio, sostituendo il rischio “trasferimento illecito” con il rischio, non meno grave agli occhi del Garante, di misure di sicurezza inadeguate.
Significa anche dover gestire in proprio il ciclo di vita delle chiavi crittografiche – generazione, rotazione, backup – competenze che raramente un Comando di Polizia locale possiede internamente, il che spesso porta a esternalizzare proprio quella componente a un integratore terzo, riaprendo dalla finestra il problema del sub-responsabile appena chiuso dalla porta.
E significa, infine, che se quel server “locale” viene amministrato in remoto da una software house esterna con credenziali privilegiate – pratica tutt’altro che rara – il rischio di accesso da un soggetto terzo si ripresenta identico, semplicemente spostato da “dove sta il cloud” a “chi ha le chiavi dell’armadio del server”.
L’on-premise, insomma, non è la scorciatoia che sembra: è un’architettura diversa che chiede, per essere tecnicamente difendibile, lo stesso livello di dettaglio tecnico di una soluzione cloud. La domanda che decide l’esito, in un caso come nell’altro, resta sempre la stessa: chi ha davvero in mano la chiave, e come lo si dimostra sulla carta.
La consultazione preventiva: un istituto, due discipline
Altra questione particolarmente interessante è la consultazione preventiva. Dopo che il Garante nel 2021 ha affermato, nei provvedimenti rivolti a Polizia di Stato e Carabinieri, la necessità della consultazione preventiva per il trattamento da loro effettuato mediante bodycam, è diventata la “bestia nera” della Polizia Locale: troppo impegnativo per i comuni rivolgersi al Garante.
Forse sì, e i casi di Brescia, Bergamo e Pescara lo confermano, ma la scelta non è – e non deve essere – di mera opportunità.
La consultazione preventiva è, in entrambi i “regimi privacy”, ossia in quello regolato dal GDPR sia in quello specifico della LED, il meccanismo attraverso cui l’autorità di controllo interviene – prima che il trattamento abbia inizio – quando la valutazione d’impatto rivela un rischio residuo che il titolare non è in grado di mitigare con le proprie misure.
È l’anello che salda la DPIA, strumento di accountability interna, al controllo esterno e preventivo dell’Autorità: la DPIA da sola resta un atto di autovalutazione. La consultazione preventiva la sottopone a un vaglio terzo con effetti potenzialmente vincolanti sull’avvio del trattamento.
Vi sono però alcune differenze significative nell’approccio alla consultazione preventiva nei due ambiti. Al di là degli aspetti procedurali e della fisiologia del dialogo istruttorio, il più rilevante è il punto di partenza.
Nel GDPR, l’art. 36 configura la consultazione come extrema ratio, condizionata a una soglia elevata: il titolare vi ricorre solo se, nonostante le misure di mitigazione individuate nella DPIA ex art. 35, permane un rischio residuo elevato.
In questo caso, il titolare trasmette la DPIA al Garante che, all’esito dell’istruttoria, qualora ravvisasse che il trattamento, per come descritto, violi il Regolamento o comunque non possa essere ritenuto conforme, potrà esercitare i poteri correttivi, fino al divieto di trattamento.
È un meccanismo, in altre parole, ancora una volta costruito sulla responsabilizzazione del titolare più che su un’autorizzazione preventiva in senso proprio.
Nel D.Lgs. 51/2018, l’art. 24 capovolge questa impostazione. La soglia di attivazione è più bassa e oggettiva: la consultazione preventiva è obbligatoria non solo quando la DPIA indica un rischio elevato residuo (comma 1, lett. a), ma anche – e indipendentemente dall’esito della DPIA – quando il tipo di trattamento presenta di per sé un rischio elevato “in ragione dell’utilizzo di tecnologie, procedure o meccanismi nuovi ovvero di dati genetici o biometrici” (lett. b).
È esattamente questa la base su cui il Garante ha ricondotto Brescia, Bergamo e Pescara all’obbligo consultivo e, prima ancora, Carabinieri e Polizia di Stato: l’impiego di bodycam – dispositivo “nuovo” nella prassi di Polizia e potenzialmente idoneo a intercettare dati particolari (art. 9 del GDPR) nel perseguimento delle finalità individuate in questi casi, attiva la soglia della consultazione preventiva indipendentemente da quanto il titolare ritenga già mitigato il rischio.
GDPR o Direttiva polizia? Finalità e base giuridica guidano la scelta
Ma allora, meglio ancorare l’uso delle bodycam al GDPR o al D.Lgs. 51/2018? Domanda sbagliata. E la risposta sicuramente stupida.
Come già detto prima, la scelta non può essere di opportunità: gli escamotage non valgono. La decisione è sulle finalità e sulla base giuridica che consente di perseguirle, il resto viene da sé.
Dall’esame dei provvedimenti resi dal Garante in materia di bodycam emergono, con una certa nettezza, due distinte ipotesi di base giuridica per l’impiego di questi dispositivi da parte della Polizia Locale, non alternative in astratto, ma applicabili a seconda della finalità concretamente perseguita dal trattamento, con conseguenze dirette sulla disciplina normativa di riferimento.
La tutela del lavoratore. Quando la bodycam è impiegata in via prioritaria a tutelare l’incolumità del lavoratore – per prevenire e documentare situazioni di pericolo, infortuni anche accidentali, aggressioni fisiche o verbali nel corso del servizio ordinario – a tutelare il patrimonio dell’ente – rispetto ad esempio a danneggiamenti, anche accidentali, o sottrazione di dotazioni, veicoli,… – nonché a perseguire altre esigenze organizzative, la base giuridica va individuata nell’art. 4, comma 1, della Legge 300/1970 (Statuto dei Lavoratori), richiamato anche dagli artt. 114 e 171 del Codice privacy quale disciplina di settore più specifica rispetto all’art. 88 del GDPR (così anche il parere reso al Comune di Torino nel 2023 e, più di recente, i provvedimenti su Cogoleto e Venezia, nn. 271 e 272/2026).
In questa prospettiva il trattamento si colloca nell’alveo della sicurezza del lavoro e del controllo – indiretto e potenziale – dell’attività lavorativa: ne discende l’applicazione delle garanzie procedurali proprie dello Statuto (accordo sindacale o, in mancanza, autorizzazione dell’Ispettorato del lavoro) e, sul piano sostanziale, della disciplina generale del Regolamento (UE) 2016/679.
Presupposto di questa ipotesi è che la finalità primaria del trattamento non sia investigativa in senso proprio, ma organizzativa e di protezione della persona che indossa il dispositivo: sicché anche i soggetti eventualmente ripresi restano, in questa cornice, “terzi” rispetto a un trattamento che nasce e si giustifica nel rapporto di lavoro.
Quando, viceversa, la bodycam è impiegata in via prioritaria e specifica per finalità di assicurazione della prova nell’ambito di specifiche operazioni di polizia giudiziaria – accertamenti e rilievi ex art. 354 c.p.p., gestione della flagranza di reato (e “arresto in flagranza differita”), documentazione di situazioni di concreto pericolo penalmente rilevante, tutela dell’ordine pubblico – la base giuridica si sposta sulle funzioni di polizia giudiziaria riconosciute alla Polizia Locale dalla Legge 65/1986 (in particolare l’art. 5 e dagli artt. 55 e 57 c.p.p., che qualificano gli appartenenti al Corpo come ufficiali/agenti di polizia giudiziaria nell’esercizio delle relative attribuzioni (così i provvedimenti su Pescara, Bergamo e Brescia).
In questo caso muta radicalmente anche la finalità del trattamento – non più la sicurezza del lavoro in senso stretto – ma prevenzione, accertamento e repressione di reati. E con essa muta la disciplina applicabile: non più il GDPR, ma il D.Lgs. n. 51/2018, di attuazione della Direttiva (UE) 2016/680, con il suo autonomo apparato di principi, garanzie per l’interessato e regime dei trasferimenti verso Paesi terzi, sensibilmente diverso da quello del Regolamento generale, a tratti più lasco, a tratti più rigido.
Quindi, come scegliere?
La distinzione non è meramente nominalistica. Individuare correttamente quale delle due finalità sia prevalente – o, anche, distinguere quali specifiche situazioni operative del Disciplinare operativo ricadano nell’una o nell’altra ipotesi – non è un esercizio di stile, ma condiziona a monte l’intero impianto di compliance: la base giuridica da richiamare, il contenuto delle informative – quella per i lavoratori e quella per gli utenti potenzialmente ripresi – che dovranno essere diverse per un trattamento fondato esclusivamente sullo Statuto dei Lavoratori rispetto a uno fondato sulle norme processual-penalistiche – e persino la stessa struttura della valutazione d’impatto, che – come il Garante aveva già osservato a proposito del caso Torino – non può essere unica e indifferenziata quando sottende trattamenti governati da basi giuridiche e finalità eterogenee.
Un Comune che intenda dotare il proprio Corpo di Polizia Locale di bodycam deve dunque, prima ancora di redigere la DPIA, innanzitutto sciogliere a monte questo nodo qualificatorio: se lo strumento serve a proteggere l’operatore, la strada è quella dello Statuto dei Lavoratori e del GDPR. Se invece serve a documentare un’attività di polizia giudiziaria, la strada è quella del D.Lgs. 51/2018 e, quando entrambe le finalità coesistono nello stesso dispositivo a seconda del contesto di attivazione, occorre tenerle separate, con basi giuridiche e trattamenti documentati autonomamente, anziché sovrapporli in un unico regime indifferenziato.
Attenzione. Anche quando non ricorre l’obbligo di consultazione preventiva, la DPIA – che comunque richiede la consultazione del DPO – non potrà nascondere le criticità tecniche evidenziate: un controllo successivo del Garante (ad esempio a causa di un data breach) potrebbe comunque rivelare delle lacune, esponendo il titolare alle responsabilità conseguenti.
Prima di acquistare una bodycam il Comune deve decidere quale trattamento intende effettuare, quale finalità persegue, quale disciplina trova applicazione, chi può accedere ai dati e chi controlla effettivamente le chiavi crittografiche. Solo dopo queste scelte, la tecnologia può essere individuata e la DPIA può valutare il sistema.
