Il capitolo conclusivo dell’esalogia dedicata al GDPR, lingua della responsabilità coniugata al futuro, propone la sintesi operativa dell’intero percorso: la distinzione tra organizzazioni “buone” – che rispettano le regole già definite da altri – e organizzazioni “brave” – che comprendono i trattamenti, valutano i rischi e trasformano gli adempimenti in strumenti di governo.
La distinzione viene messa alla prova sugli strumenti quotidiani (registro, informativa, data breach) e trova il suo compimento normativo nell’articolo 25 (protezione dei dati fin dalla progettazione e per impostazione predefinita) e nell’articolo 35 (valutazione d’impatto): le norme con cui il GDPR mostra di essere “diritto della progettualità”.
Riannodando il filo linguistico della serie, vediamo come le lingue costruiscono il futuro dal dovere e dalla volontà, così la conformità autentica nasce dall’incontro tra lo shall e il will.
Indice degli argomenti
Il bilancio
L’esalogia è partita da una constatazione – il GDPR non ha abolito il diritto dell’obbedienza, lo ha reso insufficiente. Dunque ne ha seguito le tracce nei verbi del Regolamento (lo shall del debito, il will della volontà dimostrabile) e nei suoi nomi: prima quelli del peso – responsibility e liability, la promessa che guarda in avanti e il vincolo che risponde all’indietro, fusi dall’italiano nella “responsabilità generale” – poi quelli di chi lo porta: il controller che governa senza possedere, il processor che esegue senza poter essere cieco.
È il momento di tirare le fila nel modo più concreto possibile: sugli adempimenti di ogni giorno del GDPR.
Buoni e bravi: un test immediato
La sintesi sta in una distinzione che chiunque lavori con il GDPR può usare come test.
Nel modello dell’obbedienza basta essere “buoni”: rispettare una regola già definita da altri; quindi, seguire una strada tracciata.
Nel modello della responsabilizzazione bisogna essere “bravi”: comprendere il trattamento, riconoscere i rischi, interpretare i principi, scegliere le misure, documentare il ragionamento, verificarne i risultati.
Essere bravi significa saper costruire la strada senza perdere di vista la destinazione indicata dalla norma.
Occorre precisare che il passaggio richiesto non è dall’essere buoni all’essere bravi, come se la disciplina non servisse più: quando il Regolamento fissa un obbligo determinato, quello si rispetta e basta.
Per esempio, le 72 ore dell’articolo 33 per notificare un data breach non si interpretano.
Il passaggio è dall’essere soltanto buoni al dover essere anche bravi.
Ma il fondamento normativo di questa doppia pretesa è la coppia già incontrata negli articoli precedenti: l’articolo 5, paragrafo 2 (rispettare i principi ed essere in grado di comprovarlo) el’articolo 24 (misure adeguate al rischio, riesaminate e aggiornate).
La prova degli strumenti quotidiani
La differenza si tocca con mano su ogni strumento del mestiere.
Partiamo dal registro delle attività di trattamento. Un’organizzazione “buona” lo redige perché l’articolo 30 lo richiede. Invecev un’organizzazione “brava” lo usa per conoscere i propri flussi informativi, individuare le criticità, attribuire le responsabilità, decidere gli interventi: trasforma un adempimento in uno strumento di governo.
L’informativa. Un’organizzazione “buona” la pubblica, rispettando gli articoli 13 e 14. Un’organizzazione “brava” progetta il processo perché i dati raccolti siano realmente necessari, esatti, protetti e conservati per il tempo giusto – e verifica che le persone comprendano davvero come verranno utilizzati, come richiede il principio di trasparenza dell’articolo 12.
Il data breach. Un’organizzazione “buona” adotta una procedura.
Un’organizzazione “brava” prepara le persone, assegna i compiti, prova i flussi decisionali e verifica se riuscirebbe davvero a rispettare le settantadue ore – prima che un incidente reale glielo chieda.
La differenza fra essere buoni e bravi
La regola generale è una: essere buoni vuol dire poter mostrare un documento; essere bravi vuol dire poter dimostrare che quel documento governa un comportamento reale.
Il GDPR non premia la produzione di carta, ma richiede la capacità di governare i trattamenti e di dimostrare la qualità delle decisioni assunte.
L’articolo 25: la conformità entra nel progetto
C’è una norma che porta questa logica alla conseguenza estrema: l’articolo 25, la protezione dei dati fin dalla progettazione e per impostazione predefinita (data protection by design and by default).
La conformità non può arrivare alla fine del processo, quando il sistema è già stato acquistato, i dati già raccolti, le autorizzazioni già assegnate, le decisioni già prese.
Deve entrare nel momento in cui l’organizzazione immagina il trattamento.
Le linee guida 4/2019 dell’EDPB chiariscono che non si tratta di un auspicio ma di un obbligo giuridico: le misure devono essere efficaci e il titolare deve poter dimostrare che i principi sono stati integrati nel trattamento fin dalla determinazione dei mezzi.
Le domande dell’articolo 25 hanno senso soltanto prima: quali dati saranno realmente necessari? Chi potrà accedervi? Per quanto tempo? Quali rischi creerà il sistema? Come eviteremo che l’impostazione più invasiva diventi quella automatica?
Al passato, diventano constatazioni di danni.
La valutazione d’impatto dell’articolo 35 obbedisce alla stessa logica anticipatoria: quando un trattamento può presentare un rischio elevato per i diritti e le libertà delle persone, il titolare deve fermarsi prima di iniziare e mettere per iscritto che cosa potrebbe accadere e che cosa ha predisposto perché non accada.
L’articolo 25
C’è una norma che porta questa logica alla conseguenza estrema: l’articolo 25, la protezione dei dati fin dalla progettazione e per impostazione predefinita (data protection by design and by default).
La conformità non può arrivare alla fine del processo – quando il sistema è già stato acquistato, i dati già raccolti, le autorizzazioni già assegnate, le decisioni già prese.
Deve entrare nel momento in cui l’organizzazione immagina il trattamento.
Le linee guida 4/2019 dell’EDPB chiariscono che non si tratta di un auspicio, ma di un obbligo giuridico: le misure devono essere efficaci e il titolare deve poter dimostrare che i principi sono stati integrati nel trattamento fin dalla determinazione dei mezzi.
Le domande dell’articolo 25 hanno senso soltanto prima: quali dati saranno realmente necessari? Chi potrà accedervi? Per quanto tempo? Quali rischi creerà il sistema? Come eviteremo che l’impostazione più invasiva diventi quella automatica? Al passato, diventano constatazioni di danni.
La valutazione d’impatto dell’articolo 35 obbedisce alla stessa logica anticipatoria: quando un trattamento può presentare un rischio elevato per i diritti e le libertà delle persone, il titolare deve fermarsi prima di iniziare e mettere per iscritto che cosa potrebbe accadere e che cosa ha predisposto perché non accada.
Il contenuto etico: proteggere le persone attraverso il governo dei dati
Dietro questa architettura c’è una scelta di valore che merita di essere nominata.
Il GDPR protegge un diritto fondamentale, sancito dall’articolo 8 della Carta dei diritti fondamentali dell’Unione europea.
I principi dell’articolo 5 – liceità, correttezza, trasparenza, limitazione della finalità, minimizzazione, esattezza, integrità e riservatezza – esprimono un’idea di relazione.
Chi ha il potere di raccogliere, combinare e utilizzare informazioni su un’altra persona deve esercitarlo entro limiti conoscibili, giustificabili e controllabili.
La persona non può essere ridotta a una fonte di dati né diventare l’oggetto inconsapevole di decisioni opache e un ordinamento che si accontentasse di sanzionare tratterebbe la dignità come una grandezza risarcibile.
Il Regolamento Generale sulla Protezione dei Dati afferma invece che esistono lesioni da prevenire, perché nessun risarcimento restituisce il controllo perduto sulla propria vita informativa.
La protezione dei dati non serve a proteggere i dati dalle persone: serve a proteggere le persone attraverso il governo dei dati.
Adempimenti del GDPR: l futuro non si coniuga soltanto
Riannodiamo il filo linguistico da cui la serie è partita.
Le lingue costruiscono il futuro con materiali diversi: il dovere (shall, nato dal debito; “canterò”, nato da cantare habeo, “ho da cantare”; il napoletano aggia ì), la volontà (will, nato da willan, volere), l’intenzione, il movimento [1].
Nessuna comunità è senza futuro e ogni lingua sceglie con quale categoria umana afferrarlo.
Il diritto fa lo stesso. Il vecchio diritto dell’obbedienza coniugava il futuro dei destinatari alla maniera deontica: un elenco di cose da fare, un debito da saldare.
Il GDPR ha aggiunto l’altra coniugazione, quella del progetto: che cosa farai, come, e perché proprio così?
Non a caso la parola stessa lo dice: pro-getto, “gettare avanti” – il gesto di chi lancia qualcosa oltre il presente.
La chiusa dell’intera esalogia sta dunque in poche righe.
Il GDPR ci consegna lo shall: il dovere di proteggere, l’antico verbo del debito. Quel debito porta due nomi: la promessa che guarda in avanti, il vincolo che risponde all’indietro. Ma pretende il will: la volontà competente di costruire quella protezione.
Quindi, il futuro dei diritti non si coniuga soltanto: si progetta.
Note
[1] Per le fonti linguistiche: S. Lubello, Treccani, https://www.treccani.it/magazine/lingua_italiana/speciali/i-perche-dell-
italiano/01_lubello.html – Accademia della Crusca, https://accademiadellacrusca.it/it/consulenza/avere-da-o-avere-a–infinito/1553 –
Online Etymology Dictionary, https://www.etymonline.com/word/shall e https://www.etymonline.com/word/will – J. Bybee, W. Pagliuca, The evolution of future meaning (1987), testo integrale: https://www.unm.edu/~jbybee/downloads/BybeePagliuca1987FutureMeaning.pdf.
Partecipa alla community