No results found
Ormai da qualche anno, ossia dalla nascita della cosiddetta “Legge sulla privacy” e del GDPR, che è la sua evoluzione applicata al mondo dell’IT (inevitabile a causa della massiccia digitalizzazione dei procedimenti che coinvolgono sia il pubblico che il privato) gestire correttamente i dati personali di clienti e fruitori di servizi è diventato davvero impegnativo. Il professionista e l’impresa dei nostri tempi devono misurarsi con questo onere e dotarsi degli strumenti e delle regole adeguati.
In questo tutorial verrà spiegato, partendo dalla definizione di dati personali e dai concetti di base che vi gravitano attorno, come anonimizzare i dati stessi in ottemperanza al GDPR allo scopo di gestirli senza richiesta del consenso; sarà l’occasione da una parte per comprendere concetti di base del trattamento dei dati personali e dall’altra per valutare le possibilità applicative nella pratica.
Partiamo dalla considerazione che oggi “vivere è condividere dati personali” perché qualunque transazione, erogazione di servizio o prestazione, implica lo scambio di informazioni personali.
La normativa sulla privacy è estremamente complessa e c’è un’infinità di documenti da studiare e da applicare allo scopo di tutelare i diritti e le libertà fondamentali delle persone nell’ambito della circolazione dei dati; quest’ultimo è lo scopo del GDPR e del Garante della Privacy.
La normativa sui dati personali e gli elementi che intervengono sono sostanzialmente:
Per poter ottemperare a questo fiume di disposizioni occorre partire dalla definizione di cos’è un dato personale, che è data proprio dal regolamento GDPR all’art. 4 comma 1, punto 1:
Quindi gli elementi che rilevano concettualmente per definire un dato personale sono qualsiasi informazione riguardante una persona fisica determinata o determinabile; la natura dell’informazione può essere:
L’informazione è considerata tale in qualunque formato (analogico o digitale) idoneo a esprimere informazioni riguardanti una persona fisica.
Quando l’informazione riguarda una persona fisica occorre valutarne il contenuto, le finalità e il risultato che si ottiene. Per quanto riguarda il contenuto:
Casi del genere sono, ad esempio, una ricetta medica, una pagella scolastica, un fascicolo del lavoratore.
Riguardo alla finalità, significa che il dato sarà o potrà essere usato allo scopo di valutare o influire sullo stato o comportamento di una persona; un esempio è la raccolta dei dati di sessione di computer aziendali allo scopo di controllare chi li usa, che però in qualche modo è una forma di controllo e valutazione del suo operato che può influire su eventuali avanzamenti o arresti di carriera, sullo stipendio ed anche sul costituirsi di pregiudizi.
Infine, occorre valutare il risultato, ossia cosa può comportare il controllo del dato personale e quindi l’effetto dell’utilizzo:
Questi sono comunque esempi; ciò che conta è che il risultato dell’acquisizione del dato personale è genericamente la conseguenza di tale operazione.
Due importanti definizioni contenute nel GDPR e utili a valutare le condotte poste in essere nell’ambito della raccolta e gestione dei dati, sono quello di persona fisica e persona identificata.
La legge considera persone fisiche solo le persone fisiche vive, quindi esclude quelle decedute salvo legge più favorevole dello Stato Membro; dunque, per il GDPR il dato personale riguarda la persona fisica ed esclude quindi la persona deceduta.
Però le informazioni relative alla persona deceduta possono riguardare persone vive: per esempio se si rendono pubblici i dati di un malato di emofilia ormai deceduto, siccome si tratta di una malattia ereditaria che riguarda i discendenti, in qualche modo si identificano i discendenti stessi.
Secondo l’art. 2-terdecies che riguarda la tutela dei diritti delle persone decedute, specifica che sono esercitabili dal mandatario post-mortem o dai familiari.
È esclusa di per sè la denominazione di società o imprese individuali, applicabile solo se si riferiscono a nomi di persone fisiche, quindi non alle società anonime ma a quelle all’interno del cui nome o denominazione si trovano nomi di persone.
Quanto al concetto di persona identificata, secondo il GDPR è una persona che all’interno di un gruppo è distinta, per caratteristiche, da tutti gli altri membri dello stesso (immagine seguente).
Notare che per gruppo si intende un insieme di persone cui quella in oggetto appartiene, ovvero cui appartengono i relativi dati personali: un gruppo può essere un elenco telefonico, un database di vario genere, una banca dati.
La persona può essere identificata attraverso più elementi identificatori i quali possono essere:
Devono comunque stabilire una relazione certa fra dato e persona, quindi il nome e cognome, la persona che a una certa ora era in un determinato ufficio o luogo da sola nel momento in cui è accaduto un fatto ecc.
Un esempio di informazione che consente la distinzione immediata e quindi l’identificazione di una persona può essere quella di una tribuna di uno stadio dove si trova un’unica persona con la maglietta gialla: ebbene, se una voce all’altoparlante chiama la persona con la maglietta gialla, quella è identificata, perché è l’unica contraddistinta da tale caratteristica.
Andiamo ora al concetto di persona identificabile che è leggermente diverso da quello di persona identificata, in quanto qui l’identificazione non è immediata né insita in un dato univoco, bensì all’identificazione si può arrivare combinando più elementi identificatori.
La persona identificabile, come si intuisce per logica, è qualcuno alla cui identità si risale incrociando più dati; per l’esattezza, secondo il GDPR è identificabile la persona cui si arriva dalla combinazione di più informazioni, anche provenienti da terzi e in possesso di questi, che permettono di distinguere una persona dal gruppo: ad esempio l’identità fisica, fisiologica, psichica, economica, culturale e sociale.
Un esempio di persona identificabile è quello che si può riferire a un articolo di giornale che riporta un caso di violenza sessuale e nel quale appaiono dati idonei a identificare la vittima, come il lavoro svolto, la descrizione dei luoghi, l’età: in questo caso la vittima diventa identificabile e l’esempio rientra in quanto previsto dal riferimento normativo “Garante doc. web. 9065775 – prov. 29.11.2018 n. 486”. In pratica siamo in presenza della rivelazione di un dato personale sensibile e il Garante sanziona il giornale che ha pubblicato le informazioni che consentono di risalirvi.
Un ulteriore caso molto attuale sono i post sui blog e social che riguardano una persona fisica, contenenti sufficienti elementi per identificarla anagraficamente; infatti se si fanno riferimenti che combinati con altre informazioni disponibili consentono di configurare il dato personale, la condotta è passibile di condanna (Corte di Giustizia Europea, Lindqvist C-101/01).
Riassumendo, ai fini del GDPR possiamo classificare il DATO PERSONALE
e il DATO ANONIMO che sono due concetti base, ovvero due condizioni che fanno scattare o meno l’intervento del Garante.
Più esattamente siamo di fronte alla rivelazione di un dato personale quando rende la persona identificabile (DATO PERSONALE= PERSONA IDENTIFICABILE) ovvero in presenza di una correlazione certa fra dato e persona che viene distinta dal gruppo attraverso il confronto dei dati. Il dato personale rientra nell’ambito di applicazione del GDPR.
Non rientra, invece, il dato anonimo, che non permette l’identificazione della persona cui si riferisce; questo si concretizza quando il dato non è riconducibile in alcun modo a una persona pur confrontando dei dati.
Andiamo dunque ad approfondire il significato di persona identificabile e i concetti di criterio oggettivo e criterio relativo nella valutazione della sussistenza del dato personale. A riguardo descriviamo un caso che è quello della sentenza emessa dalla Corte di Giustizia riguardante Breyer Patrik (19.10.2016 C-582/14) che permette di spiegare il criterio che bisogna valutare per l’identificazione, ossia quale criterio è oggettivo e quale criterio è relativo; appoggiamoci allo schema proposto nell’immagine seguente.
Breyer Patrik è un provider di servizi informatici che per fornire questi si connette tramite un IP dinamico a un fornitore di servizi media, ovvero i cui utenti hanno accesso tramite IP dinamico ai servizi da esso offerti; tale provider registra l’IP dinamico e lo collega al proprio utente attraverso un registro degli IP dinamici. Il fornitore di servizi media non ha accesso all’archivio del registro del provider, quindi ha solo informazioni sulle sessioni aperte in un terminato momento, sa cosa l’utente finale ha visto e ha fatto, ma non ha l’IP address che identifica la persona. In sostanza il fornitore di servizi media archivia gli IP dinamici ma non ha accesso diretto all’archivio degli utenti del provider Breyer.
In questo caso è possibile ipotizzare:
In sostanza è oggettivamente possibile che dall’IP address sia possibile risalire all’utente, quindi il fornitore di servizi media oggettivamente sta trattando dati personali. Quindi l’identificabilità della persona connessa è oggettiva e quindi l’operazione di fornitura del servizio tramite provider rientra nel GDPR e nel trattamento dei dati personali.
Esiste poi una possibilità di identificazione subordinata, ovvero quella relativa; i tal caso la normativa ritiene possibile l’identificabilità solo se il titolare del trattamento e il fornitore di servizi media hanno strumenti che ragionevolmente lo consentono.
La risoluzione che la Corte ha adottato in questo caso è che “il fatto che la legge permette di poter ordinare, tramite un Giudice, al provider di farlo accedere al registro per sapere chi era l’utente connesso in una determinata sessione (per esempio nel caso un utente del provider abbia commesso un reato informatico durante la sessione stesssa) con un determinato IP, prova la possibilità di identificare l’utente stesso e quindi il fornitore di servizi media tratta dati personali perché ha ragionevoli mezzi per trattarli.
Qui è d’obbligo una precisazione: l’identificabilità relativa viene interpretata dal Garante in termini estremamente rigorosi, perché nel momento in cui c’è una possibilità di identificare qualcuno, in qualche modo bisogna fare un’attenta valutazione finalizzata a capire se da qualche parte qualcuno è in grado di farlo.
Andiamo quindi a stabilire quali sono i mezzi di identificazione ragionevoli richiamando, allo scopo, l’articolo 26 del GDPR (C. 26 dir 95/46/CE) secondo cui: “…per stabilire l’identificabilità di una persona è opportuno considerare tutti i mezzi di cui il titolare del trattamento o un terzo può ragionevolmente avvalersi per identificare detta persona fisica direttamente o indirettamente.
Quindi sono ritenuti ragionevolmente efficaci tali mezzi:
Bisogna altresì valutare l’interesse di terzi e se le informazioni hanno un valore che giustifichi l’azione.
Approfondiamo ulteriormente il tema dell’identificabilità con un sesempio: supponiamo di disporre di un codice che permette di cifrare la persona e i suoi dati; ad esempio prendiamo nome e cognome e li passiamo con l’hash SHA-256. Dalla semplice impronta non sappiamo ricostruire il nome (è tipico delle funzioni hash, visto che sono irreversibili) però conoscendo il relativo elemento è possibile ricostruire; però all’interno del relativo gruppo questo oggetto appare come un semplice codice, quindi crea una relazione biunivoca certa tra dati non intellegibili e persona, la quale è sempre identificabile con il codice di cifratura (esempio in alto nell’immagine seguente).
Quanto spiegato esprime il concetto di pseudonimizzazione, ossia dell’assegnare al dato personale uno pseudonimo digitale che non consente l’identificazione diretta ma che la permette attraverso uno strumento, che nello specifico è una chiave di cifratura.
Adesso andiamo sul concetto dell’anonimizzazione del dato (disegno in basso nell’immagine precedente, che poi è findamentale per rientrare nelle prescrizioni del GDPR: sostanzialmente si tratta di togliere al dato le caratteristiche che permettono di correlarlo e quindi di identificare la persona nel gruppo di possibile appartenenza.
Quindi con l’anonimizzazione non si riesce in alcun modo a collegare alla persona corrispondente.
Vediamo adesso un concetto forse più ostico, aiutandoci con l’immagine seguente, che schematizza l’identificabilità indiretta della persona tramite identificativo univoco non intelleggibile.
Abbiamo spiegato prima che se in un gruppo stabiliamo una correlazione tra dati cifrati è possibile mascherare la persona (pseudonimizzazione) ma non anonimizzarla, perché con la chiave è possibile avere dati in forma intellegibile collegati in modo univoco alla persona stessa; quindi in possesso del codice ID cifrato è possibile identificare il soggetto all’interno del gruppo.
L’identificazione è anche possibile combinando dati non intelleggibili a dati intelleggibili.
Questo perché all’interno di quel gruppo si sa che quel dato codice corrisponde alla persona, quindin se direttamente non se ne conosce l’identità, è possibile risalirci.
Andiamo su un caso pratico che può chiarire il concetto, schematizzandolo con l’immagine seguente: si riferisce alla raccolta dati della pay TV Mediaset già oggetto della verifica preliminare 23.04.2015 n. 241 doc. web 4015426 (oggi GDPR art. 35 ss.) da parte del Garante; in pratica si va a fare una raccolta di dati di utilizzo dello strumento (decoder) dell’abbonato per fare una valutazione commerciale.
L’utente abbonato è identificato dal proprio decoder cui è associato un identificativo (NUID) il cui codice viene cifrato secondo hash e archiviato nel database dove verranno attinti i dati per le rilevazioni ai fii commerciali. Con questo codice cifrato si riesce, all’interno di quella banca dati, a distinguere un determinato utente da tutti gli altri e quindi a prendere decisioni su di esso anche a sua insaputa: si tratta di decisioni commerciali, in questo caso, però la questione rientra nella gestione del dato personale.
Infatti ad ogni abbonato corrisponde è un codice univoco, seppure cifrato, tale che all’interno del gruppo nel database è possibile distinguerlo; siamo ancora di fronte a un dato personale, perché si riesce a separare l’utente all'interno del gruppo.
Per chiarire questo concetto, ossia il perché avere una corrispondenza tra dati sia pure codificati e quindi non intelleggibili ed un utente anche non identificabile anagraficamente, concentriamoci ora sull’identificazione della persona attraverso il dato personale, vedendo innanzitutto cosa ha deciso il Grande a riguardo; allo scopo ci riferiamo alla verifica preliminare 23.04.2015 n. 241 doc. web 4015426 del Garante stesso. Eccone i punti sostanziali dove è definito che in un caso del genere siamo di fronte a un dato personale.
1) la possibilità che anche il dato rappresentato in una forma inintellegibile, se combinato con altre informazioni contestuali nella disponibilità del titolare del trattamento, consenta comunque di pervenire ad un´informazione intellegibile e, quindi, di distinguere la persona da tutte le altre (Opinion del WP 29 n.4 /2007);
2) la possibilità di identificare la persona anche nel caso in cui il dato, pur se non intellegibile, consenta comunque al titolare o ad una terza parte di assumere decisioni che riguardano quella stessa persona, persino a sua insaputa; per esempio, tornando al caso dell’abbonamento alla pay TV, se un utente non ha pagato, a prescindere dalle azioni di rivalsa più che lecite, l’operatore può, tramite profilazione, decidere di non rinnovare più l’abbonamento alla categoria che risponde al profilo di quell’utente, perché considerata a rischio.
Ne deriva che una procedura di anonimizzazione non può dirsi compiuta qualora non tolga la possibilità di isolare un soggetto all’interno di un gruppo e ciò anche quando l´identificativo che viene usato per consentire al titolare di assumere decisioni che riguardano tale soggetto (torniamo al caso del togliere l’abbonamento alla clientela che risponde al profilo di un abbonato insolvente: il provider può decidere di togliere dal proprio mercato tutti quelli che hanno quel determinato profilo e va quindi a prendere delle decisioni nei loro confronti) sia non immediatamente intellegibile per effetto dell’applicazione di una tecnica crittografica (Opinion del WP 29 n. 05/2014).
Quindi non basta cifrare i dati per soddisfare i requisiti imposti dal Garante ma occorre fare in modo che non possano essere ricondotti alla persona corrispondente.
La tutela operata dal Garante proprio in un caso come quello della profilazione ai fini commerciali va nella direzione di impedire che le informazioni acquisite permettano a un fornitore di prendere decisioni che costituiscano dei pregiudizi, perché per la condotta di un cliente si penalizzano tutti quelli che per profilo gli sono assimilati.
In un caso del genere occorre distinguere l’utilizzo del dato:
Andiamo quindi a vedere la soluzione avallata dal Garante nel caso specifico di Mediaset e schematizzata nell’immagine seguente.
Partendo dal NUID del decoder dell’abbonato si genera un codice univoco sequenziale che poi viene troncato nell’ultima parte (mantenendo la radice) e cifrato; insieme ai codici degli altri abbonati si ottiene un CLUSTER di dati. In questo caso non si può più identificare il singolo utente perché i dati che si trovano nel cluster sono generici, contengono le informazioni utilizzabili a fini commerciali (canali visti, orari di utilizzo ecc.) ma non correlabili al singolo individuo; qui siamo in presenza di dati anonimi e quindi non serve acquisire il consenso.
Può essere interessante proporre due esempi di Data Breach per aiutare i tecnici del settore ad evitare situazioni di fuga di dati (appunto, la Data Breach prevista dal GDPR).
Il primo di questi esempi riguarda un fatto accaduto ad AOL (America On Line) nel 2006: in quell’anno America On Line ha pubblicato un database di 20 milioni di chiavi di ricerca per oltre 650.000 utenti per un periodo di tre mesi, semplicemente sostituendo l’AOL user ID con un numero. Questa modifica ha fatto sì che attraverso l’analisi delle frequenze sono stati identificati, da malintenzionati, alcuni degli utenti sfruttando l’IP address e altri parametri di configurazione.
Il secondo esempio di Data Breach riguarda un Social network che vendette a terzi dati personali pseudonimizzati; invece di nomi veri, il provider usava soprannomi, ma questo chiaramente non è stato sufficiente per anonimizzare i profili degli utenti, poiché le relazioni tra i diversi individui sono univoche e possono essere usate come identificatori, come già spiegato.
Questi esempi servono a capire che non basta cifrare i dati degli utenti, scambiati o stivati in una banca dati, perché senza i dovuti accorgimenti, incrociando più dati si arriva ugualmente all’identità, quindi codificare non implica automaticamente l’anonimizzazione del dato; si sta semplicemente eseguento una pseudonomizzazione.
Se si vuole arrivare all’anonimizzazione, adottando mezzi ragionevoli non deve essere possibile:
1) isolare una persona del gruppo;
2) collegare il dato anonimizzato con altri dati riferibili a persone;
3) dedurre da un dato anonimo nuove informazioni riferibili ad una persona.
Questo processo deve essere irreversibile.
Le principali tecniche in campo nell’anonimizzazione del dato sono:
Queste tecniche sono state tratte da un documento ufficiale dell’Autorità Garante che è l’Opinion 05/2014 on Anonymisation Techniques.
Tutto il discorso fatto sinora è propedeutico all’utilizzo dei dati personali secondo GDPR, per finalità commerciali, ovvero i concetti suesposti si applicano alla rilevazione di persone per finalità di marketing. In questi casi occorre effettuare una verifica preliminare al fine di valutare se si può incorrere o meno nelle sanzioni del Garante, ovvero se è richiesto o meno il consenso al trattamento del dato personale per le suddette finalità.
La raccolta di dati anonimi nei luoghi fisici tramite sistemi di rilevazione di persone per finalità di marketing e ricerche di mercato implica:
Analizziamo alcuni casi che hanno superato la verifica preliminare da parte del Garante e alcuni che sono stati “bocciati”.
Il primo è quello relativo alla banca Monte dei Paschi di Siena, che ha messo in piedi un sistema di rilevazione di spostamento e conteggio delle persone con visione su monitor nei locali dell’agenzia (verifica preliminare Garante doc. web. 4806740). In pratica è stato utilizzato un sistema di riconoscimento con utilizzo di un sistema di filtro solo a colori e nella parte iniziale c’era un trattamento di dati recepiti in modo indeterminato e poi convogliati in modo statistico, quindi generico. E questo modo generico non è un dato personale. Sicuramente nella prima fase del trattamento delle immagini c’è un dato personale, ma trattandosi di una parte meramente di raccolta del dato che mediante tecniche di refresh della memoria, dopo il passaggio alla procedura di anonimizzazione non rimane, il sistema è stato ammesso.
La stessa cosa è stata per Grandi Stazione Spa, dove sono stati collocati dei Totem pubblicitari basato sulla rilevazione dei tratti del viso di tipo Face detection not Face recognition (ivi, doc. web. 7496252). In pratica un algoritmo analizza le immagini e ne estrae immediatamente solo la parte che serve a capire il genere e alcuni tratti che secondo valutazioni di marketing possono far preferire un messaggio pubblicitario piuttosto che un altro; anche qui il dato personale viene ricevuto ed elaborato, cancellando subito dopo l’immagine originaria e trasformandolo in dato anonimo statistico.
Questi due esempi ci dicono che per superare le prescrizioni del GDPR occorre che:
In questo caso l’interesse di chi opera le riprese è legittimo perché delle immagini si utilizza la sola parte utile ai fini statistici e i dati sono subito anonimizzati e utilizzati come dato anonimo.
Vediamo invece dei casi dove la verifica preliminare da parte del Garante ha fornito esito negativo: il primo riguarda MAMACROWD, che nell’aprile 2019 ha sospeso un’operazione di crowd funding relativa a un progetto perché quest’ultimo utilizzava un approccio palesemente in violazione del GDPR; si trattava in pratica di un Progetto di Computer Vision con data recognition dei clienti nei negozi e passanti con tracciatura nei locali commerciali. In questo caso il progetto si basava sul riconoscimento facciale e sull’utilizzo dei dati individuali per poi inseguire la persona stessa e controllarne i movimentii. Qui, per operare una cosa del genere sarebbe necessario il consenso, trattandosi di raccolta di dati personali.
Altro esempio riguarda il maggio 2019, quando una società che chiameremo O. Srl (non ne pubblichiamo il nome per intero per evidenti motivi ma trovate i dati della verifica preliminare richiesta al Garante) faceva rilevazioni dei MAC address degli smartphone dei clienti negozi e passanti vetrine, tramite cifratura hash, telecamere, rilevamento volti (ivi, doc. web. 9022068). In pratica aveva fatto un sistema di riconoscimento facciale delle persone sia esternamente alla vetrina per vedere chi si avvicinava, sia all'’nterno del negozio; come si spostava all’interno del locale, la persona veniva tracciata e i relativi dati erano trasformati in ash. Questa soluzione è stata bocciata dal Garante perché i MAC address sono registrati ed è possibile risalire all’utente dell’apparecchio, giacché ogni MAC è univoco e tramite il tracciamento si risale al terminale radiomobile, che ha un suo codice IMEI univoco anch’esso e quindi all’intestatario. Questo a prescindere dal fatto che l’azienda avesse previsto la codifica in hash dei MAC stessi; infatti il Garante ha respinto il progetto perché pur crittografati, tali dati sono correlabili e identificabili nel database in quanto non anonimizzati. Del resto lo scopo del sistema era tracciare i movimenti dell’apparecchio in base al MAC address e se questo fosse stato anonimizzato prima del trattamento, l’applicazione del sistema non avrebbe potuto seguire il cliente nel negozio; quindi, non potendo essere anonimizzato il dato, il Garante ha fornito parere negativo.
Quindi anche qui ricorre la differenza già spiegata tra pseudonimizzazione e anonimizzazione dei dati:
Riassumendo, gli ultimi due casi sono accomunitati da un particolare, che rende obbligatorio il consenso: in entrambi, affinché il sistema funzioni è necessario mantenere una relazione biunivoca tra persona riconosciuta e dato personale derivato dal riconoscimento. Quindi non è possibile, in linea generale, adottare sistemi in grado di identificare le persone per ciò che sono e non per una parte ed utilizzare i dati che comprendano la loro identità senza chiedere il consenso al trattamento dei dati personali.
Questo vale per tutte le applicazioni in tutte le situazioni dove si intendano acquisire dati personali destinati al trattamento ai fini commerciali e di marketing: se ci si può accontentare di dati aggregati che spersonalizzano l’utente è possibile, altrimenti deve essere dato esplicito consenso dall’interessato.
La tecnica di anonimizzazione dei dati personali ha un potenziale enorme a livello operativo, perché abbiamo la possibilità di utilizzarla per rilevazioni anonimizzate dei consumatori a livello fisico (spostamenti e abitudini) purché con tecniche idonee, ma anche la possibilità, per esempio, di trasformare una banca dati commerciali (che dev’essere cancellata perché sono scaduti i termini di conservazione) in un cluster di dati aggregati in forma anonima da sfruttare per rilevazioni statistiche; quest’ultimo caso ha rilevanza economica perché questa banca dati in forma anonimizzata può essere venduta, ceduta a terzi, in quanto non contiene dati personali.
C’è poi tutta la tematica dell’intelligenza artificiale, dove è difficile operare del rispetto della privacy o trovare risposta proprio sull’anonimizzazione del dato, perché se l’intelligenza artificiale opera su dati anonimi non si applica il GDPR, mentre se lavora su dati personali bisogna “mettere in piedi” tutta una struttura enorme ed estremamente complessa per addestrare la macchina a rispettare le finalità del trattamento, giacché gli algoritmi di machine learning hanno tutt’altra finalità.