GDPR dati sovranità definizioni

Il GDPR non è uno scudo di sovranità

Si invoca il GDPR come prova di indipendenza digitale. Ciò significa confondere un diritto delle persone con una politica industriale. Due domande, due risposte e un nodo da sciogliere.

·6 min di lettura

Nei comitati, questo ragionamento ricorre come un riflesso condizionato. Siamo conformi al GDPR, quindi siamo sovrani. La frase rassicura, ma è falsa. Il GDPR tutela le persone dagli abusi nel trattamento dei loro dati. Non dice nulla sulla vostra dipendenza da un fornitore, nulla sull’origine della vostra infrastruttura, nulla sul diritto straniero che può prevalere su quello europeo. Si tratta di due questioni distinte. Le si confondono perché condividono una parola, «dati», e perché il termine «sovranità» ha iniziato a fungere da involucro per tutto ciò che riguarda il digitale europeo.

Mettiamo i due argomenti fianco a fianco, senza caricarne uno per salvare l’altro.

Cosa fa esattamente il GDPR

Il regolamento (UE) 2016/679, entrato in vigore nel maggio 2018, ha un obiettivo preciso: proteggere le persone fisiche in relazione al trattamento dei loro dati personali. Non si tratta né di un testo sulle infrastrutture né di una politica industriale. È un diritto delle persone, accompagnato da obblighi per chi tratta i loro dati.

Per quanto riguarda le persone, il regolamento sancisce diritti opponibili: accesso, rettifica, cancellazione, portabilità, opposizione, limitazione. È possibile esigere di sapere quali dati si possiedono su di voi, che vengano corretti, cancellati o restituiti in un formato riutilizzabile. Per quanto riguarda le organizzazioni, il regolamento impone obblighi al titolare del trattamento, ovvero chi decide le finalità, e al responsabile del trattamento, ovvero chi tratta per conto del titolare. Ogni trattamento deve fondarsi su una delle sei basi giuridiche: il consenso, l’esecuzione di un contratto, un obbligo legale, la tutela di interessi vitali, una missione di interesse pubblico o l’interesse legittimo. Al di fuori di queste sei categorie, il trattamento è illecito.

Due principi ne strutturano il resto. La minimizzazione: si raccolgono solo i dati necessari alla finalità dichiarata, non di più, per ogni evenienza. La limitazione delle finalità: un dato raccolto per un uso non può essere utilizzato liberamente per un altro. A ciò si aggiungono l’obbligo di sicurezza, la notifica delle violazioni entro settantadue ore e la valutazione d’impatto per i trattamenti a rischio. Ecco l’ambito di applicazione. È coerente, rigoroso e interamente orientato alla protezione dell’individuo.

Cosa non prevede

Nulla in questo ambito riguarda la sovranità industriale o tecnologica. Il GDPR non vieta AWS, Azure o Google Cloud. Regola il modo in cui vi vengono trattati i dati personali, richiede garanzie, ma non stabilisce da chi acquistare la propria infrastruttura. Un’azienda può ospitare l’intera infrastruttura presso un hyperscaler statunitense e rimanere perfettamente conforme, purché rispetti le basi giuridiche, il principio di minimizzazione e gli obblighi di sicurezza.

Il regolamento non crea alcuna offerta locale. Non finanzia alcun centro dati, non favorisce l’emergere di fornitori europei, non riduce in alcun modo la dipendenza del continente da una manciata di attori stranieri. Non è questo il suo ruolo, e attribuirgli tale intenzione significa fraintendere il testo.

Non vieta nemmeno i trasferimenti di dati al di fuori dell’Unione. Li disciplina. Un trasferimento verso un paese terzo è lecito se si basa su una decisione di adeguatezza, su clausole contrattuali tipo o su norme aziendali vincolanti. Regolamentare non significa impedire. I dati europei circolano, legalmente, verso giurisdizioni in cui il diritto locale diverge dal nostro.

E non risolve la questione del CLOUD Act. Questo testo statunitense del 2018 autorizza le autorità degli Stati Uniti a richiedere i dati detenuti da un’impresa soggetta alla loro giurisdizione, indipendentemente dal luogo in cui siano archiviati. Il GDPR contrappone i propri requisiti a tale richiesta, ma non neutralizza il collegamento giuridico dell’operatore. Il conflitto di leggi rimane intatto. La conformità al regolamento non fa scomparire l’applicazione di una normativa straniera nei confronti del proprio fornitore.

Da dove nasce la confusione e perché persiste

La confusione ha un’origine logica. Il GDPR è il testo europeo in materia digitale più conosciuto, più mediatizzato, l’unico che i dirigenti citano a memoria. Quando si cerca un simbolo dell’autonomia digitale del continente, è proprio questo che viene in mente, in mancanza di altri punti di riferimento altrettanto visibili. L’Europa ha legiferato laddove gli altri si accontentavano di condizioni generali: questo vantaggio normativo è stato scambiato per un vantaggio in termini di potere.

Questo scivolamento è stato alimentato dal vocabolario. A forza di definire «sovranità dei dati» il controllo sul loro trattamento, si è lasciato intendere che proteggere i dati equivalesse a sottrarli a qualsiasi influenza estranea. Il marketing ha fatto il resto. Dimostrare la conformità al GDPR è diventato un argomento rassicurante, e la rassicurazione si è trasformata in una promessa implicita di indipendenza. La confusione persiste perché fa comodo: permette di spuntare una casella di sovranità senza cambiare nulla della propria infrastruttura.

Le due questioni da tenere separate

Occorre seguire due filoni distinti e accettare che non si sovrappongano. La conformità al GDPR è una questione di tutela delle persone: i loro dati vengono trattati in modo lecito, leale, con le giuste basi giuridiche e le giuste garanzie? La dipendenza dall’infrastruttura è una questione di sovranità industriale: da chi si dipende per far funzionare i propri sistemi, a quale giurisdizione è soggetto tale fornitore, è possibile cambiarlo senza dover riscrivere tutto da capo.

Questi due assi sono ortogonali, e nella realtà esistono tutte e quattro le combinazioni. Si può essere conformi e dipendenti: una PMI perfettamente in regola, interamente ospitata presso un hyperscaler soggetto al CLOUD Act. Si può essere non conformi e sovrani: un’amministrazione che ospita i propri dati su un’infrastruttura certificata SecNumCloud ma raccoglie dati senza una base giuridica e trascura i diritti delle persone. Si può essere entrambe le cose, oppure nessuna delle due. L’unico caso impossibile è quello che il discorso dominante dà per scontato: che la conformità comporti la sovranità. Non è così.

Il caso Schrems II lo ha dimostrato senza ambiguità. Nel 2020, la Corte di giustizia dell’Unione europea ha invalidato il Privacy Shield, l’accordo che disciplinava i trasferimenti verso gli Stati Uniti, in quanto la normativa statunitense in materia di sorveglianza non garantiva una protezione equivalente. La conformità formale non era più sufficiente, perché il diritto straniero influiva sui dati nonostante tutte le garanzie contrattuali. Il problema messo in luce non era un difetto di trattamento: era una questione di giurisdizione e di dipendenza. Il GDPR è servito a mettere in luce il problema della sovranità. Non è mai stato lo strumento in grado di risolverlo.

Per il dirigente, la conclusione è chiara. La conformità al GDPR è necessaria e non è negoziabile. Ma spuntare quella casella non dice nulla della vostra dipendenza dall’infrastruttura, né del diritto che può imporsi al vostro fornitore. Si tratta di due fronti, due budget, due decisioni. Confonderli significa credere che uno sia risolto occupandosi solo dell’altro.

Fonti

  • Regolamento (UE) 2016/679 (GDPR), testo ufficiale
  • CNIL, schede informative sulle basi giuridiche, la minimizzazione e i trasferimenti al di fuori dell’UE, cnil.fr
  • Corte di giustizia dell’Unione europea (CGUE), sentenza Schrems II, causa C-311/18, 16 luglio 2020
  • CLOUD Act (Stati Uniti, 2018)
  • Comitato europeo per la protezione dei dati (CEPD), raccomandazioni sui trasferimenti internazionali