L’italiano distingue i due protagonisti del trattamento di dati personali in “titolare” e “responsabile”. L’inglese li chiama controller e processor nel GDPR.
Sono coppie di parole che illuminano angoli diversi degli stessi istituti – e che, prese alla lettera, possono fuorviare.
“Titolare” evoca un proprietario, ma il titolare non possiede i dati. Invece, “responsabile” suggerisce un decisore autonomo, ma il responsabile agisce per conto altrui e su istruzioni. Infine, processor sembra un esecutore meccanico, ma il GDPR gli attribuisce obblighi propri, incluso quello di riconoscere e segnalare istruzioni illegittime.
Il quinto capitolo di questa esalogia dedicata al GDPR, lingua della responsabilità coniugata al futuro, esamina le definizioni dell’articolo 4 e la disciplina dell’articolo 28 alla luce delle linee guida 07/2020 dell’EDPB, e ne ricava una formula operativa per distribuire correttamente i ruoli.
Indice degli argomenti
I verbi e i nomi del GDPR
Nei capitoli precedenti, abbiamo letto il GDPR nei suoi verbi e nei suoi nomi. I verbi: lo shall che stabilisce il debito di protezione, il will che pretende la volontà competente e dimostrabile di pagarlo.
E i nomi del peso da portare: responsibility, la promessa che guarda in avanti; liability, il vincolo che risponde all’indietro – le due parole che l’italiano fonde nella “responsabilità generale” del considerando 74.
Restano da leggere i nomi di chi quel peso lo porta. Qui viene al pettine il nodo che nel terzo caitolo avevamo lasciato in sospeso: nel GDPR italiano la parola “responsabile” non designa chi decide, ma chi esegue per conto altrui – tanto che l’articolo 5, paragrafo 2, per dire che il titolare è responsible, ha dovuto scrivere “è competente”.
L’italiano chiama i due protagonisti “titolare” e “responsabile del trattamento”; l’inglesecontroller e processor. Quattro parole, ma nessuna, presa da sola, dice tutta la verità.
Il confronto tra le due coppie non è tanto un esercizio di traduzione quanto invece un test di comprensione dell’intera disciplina.
Titolare: il rischio della lettura proprietaria
L’articolo 4, numero 7, del GDPR definisce titolare del trattamento “la persona fisica o giuridica, l’autorità pubblica, il servizio o altro organismo che, singolarmente o insieme ad altri, determina le finalità e i mezzi del trattamento di dati personali”.
La parola italiana, però, racconta una storia diversa dalla definizione.
“Titolare” deriva dall’idea di essere investiti di un titolo, di una posizione, di un potere.
Nel linguaggio comune indica il possessore, il detentore di un diritto, colui che esercita un’attività: per esempio, il titolare della farmacia o del conto.
Il termine mette in evidenza la posizione giuridica ed espone a un rischio interpretativo preciso: la rappresentazione statica e quasi proprietaria; come se i dati personali appartenessero al titolare del trattamento.
L’equivoco circola ovunque – “i nostri dati”, “il patrimonio informativo aziendale” – come se i dati personali fossero un bene dell’organizzazione che li raccoglie.
Si potrebbe obiettare che per il titolare i dati sono, di fatto, un asset.
È vero – e il GDPR stesso, nell’articolo 1, alla protezione affianca la libera circolazione dei dati.
Tuttavia è proprio la lingua dei bilanci a offrirci la parola esatta: in ogni stato patrimoniale agli asset fanno da contrappeso le liability e il patrimonio netto; e liability – lo abbiamo visto – è la responsabilità-vincolo del considerando 74 del GDPR.
Chi è il proprietario e chi il titolare
I dati personali sono un attivo che entra in azienda già gravato dal suo passivo: il debito di protezione verso le persone.
Più dati si accumulano, più debito si iscrive.
Il titolare, dunque, non è un proprietario, ma è un debitore che lavora con capitale di terzi e la libera circolazione non smentisce questo assetto – lo presuppone: i dati circolano liberamente nell’Unione proprio perché la protezione, resa uniforme, viaggia insieme a loro.
La protezione non è il freno della circolazione; è ciò che la rende possibile.
Se il piano economico registra un asset, il piano giuridico registra altro.
I dati personali riguardano le persone fisiche e la loro protezione costituisce un diritto fondamentale, sancito dall’articolo 8 della Carta dei diritti fondamentali dell’Unione europea: un diritto che non si trasferisce con il bene, perché non sta nel bene – sta nella persona.
Per questo motivo, ciò che il Regolamento attribuisce al titolare non è un dominio ma una funzione: assumere le decisioni fondamentali sul trattamento – perché trattare, che cosa trattare, con quale architettura essenziale – e rispondere della loro qualità, come impone l’articolo 24.
Il proprietario ha un titolo. Invece, il titolare del trattamento ha un incarico – e, come ormai sappiamo, un debito.
Controller: la funzione di governo
Il termine inglese è, sotto questo profilo, più fedele alla sostanza.
Controller rende visibile la funzione dinamica: il controller dirige, governa, mantiene il controllo sulle scelte fondamentali del trattamento.
Non evoca un possesso, bensì un esercizio.
Le linee guida 07/2020 del Comitato europeo per la protezione dei dati (EDPB), dedicate proprio ai concetti di controller e processor, ragionano coerentemente in termini funzionali: la qualifica di titolare discende dal ruolo di fatto esercitato – chi determina effettivamente finalità e mezzi – a prescindere dalle etichette formali che le parti si sono attribuite nei contratti.
Non si diventa titolari firmando un documento che lo dichiara, ma lo si diventa perchési esercita quella funzione e la si esercita anche quando si preferirebbe non ammetterlo.
La formula più esatta è anche la più semplice: il titolare non possiede i dati ma governa il trattamento.
Inoltre, chi governa – a differenza di chi possiede – deve rendere conto delle decisioni assunte, delle alternative scartate, delle misure scelte, dei risultati verificati.
“Responsabile”: l’autonomia che non c’è
Il secondo nome è, per certi versi, il più insidioso.
L’italiano dice “responsabile del trattamento”; e nella nostra lingua “responsabile” è colui che risponde delle proprie decisioni: la parola evoca autonomia, potere, imputazione.
Il responsabile dell’ufficio decide, invece il responsabile del progetto dirige.
Ma il GDPR disegna tutt’altra figura.
Infatti, il responsabile, definito dall’articolo 4, numero 8, è il soggetto che “tratta dati personali per conto del titolare del trattamento”.
Non determina le finalità né i mezzi essenziali, ma opera, in linea generale, sulla base delle istruzioni documentate del titolare, dentro il perimetro fissato dal contratto previsto dall’articolo 28, paragrafo 3.
Il termine italiano rischia quindi di attribuirgli, sul piano intuitivo, un’autonomia superiore a quella che realmente possiede – e la confusione tra i due ruoli è tra gli errori più frequenti e più costosi della materia: contratti che chiamano “responsabile” chi in realtà decide finalità e mezzi, fornitori trattati da titolari autonomi per comodità, nomine attribuite per abitudine.
Processor: l’esecutore che non può essere cieco
L’inglese processor corregge la distorsione: mette in primo piano l’operazione svolta – il trattamento eseguito per conto altrui – e il rapporto funzionale con chi decide.
Ma processor, preso da solo, esporrebbe al rischio opposto: far pensare a un esecutore meccanico, privo di responsabilità propria.
Non è così e il punto merita la massima chiarezza.
Il GDPR impone infatti al processor obblighi diretti, suoi propri, che nessun contratto può cancellare:
- garantire misure di sicurezza adeguate al rischio (articolo 32);
- tenere, nei casi previsti, il registro delle categorie di attività di trattamento svolte per conto dei titolari (articolo 30, paragrafo 2);
- assistere il titolare e cooperare con l’autorità di controllo;
- rispettare le condizioni per il ricorso a subresponsabili;
- notificare al titolare, senza ingiustificato ritardo, le violazioni di dati di cui viene a conoscenza (articolo 33, paragrafo 2).
E soprattutto: ai sensi dell’articolo 28, paragrafo 3, il responsabile “informa immediatamente il titolare del trattamento qualora, a suo parere, un’istruzione violi il presente regolamento od altre disposizioni, nazionali o dell’Unione, relative alla protezione dei dati”.
L’obbedienza cieca come violazione
Fermiamoci su quest’ultimo obbligo, perché contiene una piccola rivoluzione.
Un ordinamento che chiedesse al responsabile soltanto di eseguire non gli chiederebbe mai di riconoscere l’illegittimità di un’istruzione: per riconoscerla, bisogna capirla.
Il GDPR pretende dunque un esecutore che comprende ciò che esegue ovvero che conosce la normativa abbastanza da accorgersi quando il committente la sta violando, e che ha il dovere giuridico di dirglielo.
L’obbedienza cieca, che nella tradizione era la virtù dell’esecutore, qui diventa una violazione.
La distribuzione dei ruoli: una formula
Possiamo fissare la distribuzione dei ruoli in una formula speculare:
- il titolare decide, e deve saper dimostrare la qualità delle proprie decisioni;
- il responsabile esegue, ma deve comprendere la legittimità di ciò che esegue.
Nessuno dei due può rifugiarsi dietro il proprio ruolo: il titolare non può infatti scaricare sul fornitore le scelte che spettano a lui; il fornitore non può trincerarsi dietro le istruzioni ricevute.
Le due lingue, lette insieme, dicono infine la verità che ciascuna dice a metà.
Le parole inglesi descrivono il movimento del trattamento: il controller governa e il processor tratta.
Invece le parole italiane del GDPR descrivono la collocazione giuridica: il titolare occupa la posizione principale, il responsabile risponde degli obblighi che gli competono.
Chi opera sul campo deve pensare in termini di funzione, non di etichetta, perché – come dicono le citate Linee Guida EDPB 7/2020 – è la funzione concreta, non il nome scritto nel contratto, a decidere chi risponde di che cosa.
Controller e processor: le funzioni nelle parole del GDPR
I nomi del GDPR confermano ciò che i suoi verbi avevano annunciato. Il Regolamento non si accontenta di soggetti obbedienti, ma pretende soggetti competenti.
Il controller non custodisce passivamente una titolarità, ma governa il trattamento e ne dimostra la qualità.
Invece il processor non esegue ciecamente: traduce le decisioni altrui in operazioni di cui deve comprendere la legittimità.
Entrambi sono trattati dall’ordinamento come soggetti pensanti, non come ingranaggi.
Resta l’ultima domanda, la più concreta di tutte: che cosa distingue, negli adempimenti di ogni giorno, un’organizzazione che obbedisce da una che governa?
Il registro, l’informativa, la gestione dei data breach, la progettazione dei sistemi: gli stessi strumenti possono essere carta o governo.
Nel prossimo e ultimo capitolo proporremo la sintesi dell’intera esalogia: la distinzione tra organizzazioni “buone” e organizzazioni “brave”, la protezione dei dati come progetto (articoli 25 e 35) e la chiusa che tiene insieme linguaggio e diritto: il futuro dei diritti non si coniuga soltanto, ma si progetta.
Partecipa alla community