Utilizzo di modelli statistico-predittivi e data mining: il caso INPS e alcune guidelines operative

Utilizzo di modelli statistico-predittivi e data mining: il caso INPS e alcune guidelines operative

di Giulio Messori

Il 18 settembre scorso, in una audizione presso la 11ª Commissione permanente del Senato della Repubblica, Antonello Soro[1] ha affrontato il tema dell’utilizzo di metodologie di data mining al fine di eseguire visite mediche di controllo a lavoratori del settore pubblico. Nel caso in specie, INPS, utilizzando un software chiamato SAVIO, programmava in maniera cadenzata le visite fiscali dei lavoratori afferenti al settore pubblico.
Non solo: tramite un modello statistico predittivo contenuto nel programma, venivano analizzati alcuni dati degli stessi lavoratori, permettendo così di identificare preventivamente possibili assenze ingiustificate dal lavoro per malattia.
L’evidente vantaggio di tale sistema sarebbe stato quello di evitare comportamenti fraudolenti, garantendo anche un migliore funzionamento dell’ambito di lavoro pubblico.
Può, quest’ultimo, essere considerato come scopo legittimo per l’utilizzo di tecnologie predittive? E quali sono le considerazioni da porre in essere nel caso in cui si utilizzi un software con tali potenzialità, sia in ambito pubblico che privato?
Di seguito alcune delle fasi necessarie per l’analisi del funzionamento dei suddetti prodotti, con riferimento alla normativa in materia di protezione dei dati personali europea.  

1. Analisi Tecnica

Non è possibile applicare le disposizioni di diritto senza una conoscenza approfondita del funzionamento del prodotto.
Nel caso INPS, il software SAVIO attribuiva alle certificazioni di malattia un punteggio di maggiore o minore affidabilità «[…] su base statistica del giudizio prognostico di idoneità alla ripresa del lavoro o di assenza ingiustificata». A detta del Presidente INPS, inoltre, SAVIO non avrebbe analizzato la patologia da cui era affetto il lavoratore riportata nel certificato medico: avrebbe invece preso in considerazione «soltanto la frequenza e la durata dei singoli episodi di malattia del lavoratore, insieme ad altre variabili quali il numero delle precedenti idoneità alle visite mediche di controllo, la qualifica del lavoratore, il tipo di rapporto di lavoro, la retribuzione, il settore e la dimensione aziendale».

2. Analisi degli use cases del prodotto

L’analisi tecnica deve essere necessariamente ricondotta ai casi d’uso specifici del prodotto.
Nonostante non siano stati forniti ulteriori dettagli sulla situazione in specie, può essere utile compiere uno sforzo di astrazione. Ad esempio: SAVIO veniva utilizzato solo per l’ambito pubblico? Come sarebbe cambiata l’analisi nel caso in cui il software fosse stato utilizzato in ambito privato? E in caso di risposta affermativa, in quali filiere?
I processi decisionali automatizzati, ivi inclusa la profilazione, sono impiegati in un numero crescente di settori, sia privati (si pensi ad esempio ai settori assicurativo, bancario e finanziario) che pubblici.
Indipendentemente dall’ambito di afferenza, gli use cases dovranno essere discussi con i developers del prodotto-software e con qualsiasi figura apicale che abbia collaborato alla commercializzazione dello stesso. In questa analisi è necessario indossare il cappello “strategico”, oltre a quello del diritto.

3. Analisi dei player coinvolti e della c.d. “catena di responsabilità”.

Ogni use case porta poi con sé l’altra necessaria analisi da compiere in sede di assessment: quali sono gli altri soggetti coinvolti nell’uso e nella commercializzazione del prodotto?
Sempre compiendo uno sforzo di astrazione potremmo chiederci: SAVIO è stato prodotto internamente da un reparto sviluppo di INPS? Oppure, con più probabilità, è stato sviluppato da una software house esterna, alla quale il prodotto è stato commissionato o dalla quale è stato acquistato? In questa seconda eventualità: quali sono i rapporti contrattuali tra l’Istituto e il soggetto privato terzo? Come è stata regolata la responsabilità civilistica?
E poi: quali dipendenti dell’una e dell’altra parte hanno accesso a dati dei lavoratori pubblici? Con quali privilegi di accesso? I dati sono solo “cifre statistiche”, e dunque non riconducibili ad un soggetto identificato o identificabile, o ci ritroviamo invece nella definizione di Dato Personale, così come definito dall’art. 4(1) del GDPR?
Porsi simili domande e identificare i player in gioco è essenziale per attribuire i ruoli che la normativa Europea definisce, ormai da tempo: Titolare e Responsabile del Trattamento dei dati personali, Autorizzati, Amministratori di Sistema ed eventualmente, anche i DPO in questione. Sarà così possibile identificare la c.d. Catena di Responsabilità in ambito Privacy.

4. Analisi di diritto

Superate le prime tre fasi e avuto un quadro completo di assessment, è possibile passare a una prima analisi di diritto, differente da caso a caso a seconda del prodotto analizzato.
Nonostante lo scopo in apparenza qui legittimo (identificazione di comportamenti fraudolenti) e come in ogni caso di profilazione, la normativa richiede che vengano rispettati criteri di correttezza e trasparenza e che vengano accordate sufficienti garanzie, specialmente laddove sono trattati dati riguardanti la salute.
Come specificato dall’art. 22(1) GDPR, l’interessato ha il «diritto di non essere sottoposto a una decisione automatizzata basata unicamente sul trattamento automatizzato, compresa la profilazione, che produca effetti giuridici che lo riguardano o che incida in modo analogo significativamente sulla sua persona».
La condizione di cui a questo articolo consta, come noto, di alcune eccezioni. In particolare il trattamento automatizzato e la profilazione sono legittimi nel caso in cui la decisione:

1. sia necessaria per la conclusione o l’esecuzione di un contratto tra l’interessato e un titolare del trattamento;
2. sia autorizzata dal diritto dell’Unione o dello Stato membro cui è soggetto il titolare del trattamento, che precisa altresì misure adeguate a tutela dei diritti, delle libertà e dei legittimi interessi dell’interessato;
3. si basi sul consenso esplicito dell’interessato.

Nessuna delle tre eccezioni, però, è esercitabile nel caso in cui oggetto del trattamento automatizzato siano le particolari categorie di dati di cui all’articolo 9 del GDPR.
In più, in caso di utilizzo di modelli predittivi, è frequente la situazione di “errore”, nella quale le procedure di elaborazione statistica, caratterizzate dall’applicazione di regole matematiche prestabilite (a meno che non si parli di machine learning), generano rischi di predizioni errate, abusi, discriminazioni ingiustificate e, soprattutto, di violazione dei diritti degli interessati.

5. Le indicazioni del Garante per l’utilizzo di sistemi statistico predittivi: DPIA, informativa, minimizzazione.

A fronte di tale analisi, risulta per prima cosa opportuno redigere una Valutazione d’Impatto sulla Protezione dei Dati Personali, conosciuta anche come DPIA (Data Protection Impact Assessment).
Tale indicazione perviene dal testo del GDPR che, all’art.35, evidenzia come particolarmente importante l’elaborazione di una DPIA nel caso di «[…] valutazione sistematica e globale di aspetti personali relativi a persone fisiche, basata su un trattamento automatizzato, compresa la profilazione, e sulla quale si fondano decisioni che hanno effetti giuridici o incidono in modo analogo significativamente su dette persone fisiche».
Nell’analisi delle altre tipologie di trattamenti di dati che possono presentare un rischio elevato per i diritti e le libertà dei cittadini UE, che quindi necessitano una DPIA, non solo il GDPR, ma anche l’ormai ex Art. 29 Working Party (oggi European Data Protection Board) tiene in considerazione:

1. Trattamenti valutativi o di scoring;
2. Decisioni automatizzate che producono significativi effetti giuridici o di analoga natura;
3. Monitoraggio sistematico;
4. Dati sensibili o dati di natura estremamente personale;
5. Trattamenti di dati su larga scala;
6. Combinazione o raffronto di insiemi di dati;
7. Dati relativi a interessati vulnerabili;
8. Utilizzi innovativi o applicazione di nuove soluzioni tecnologiche o organizzative;
9. Tutti quei trattamenti che, di per sé, “impediscono agli interessati di esercitare un diritto o di avvalersi di un servizio o di un contratto”.

Pur non entrando nel dettaglio di ognuna delle condizioni, è evidente come nel caso di SAVIO vengano incontrate le condizioni di cui al punto 1, 2, 4 e 9. Riguardo quest’ultimo, nello specifico, il Garante evidenzia nel suo intervento come i lavoratori del settore pubblico non avessero la possibilità di esercitare i propri diritti in materia Data Protection: questo stesso punto, oltre alla DPIA, è una delle garanzie da approntare e che il Regolamento richiede come necessarie.

Altre misure da attuare riguardano: I) la previsione di modalità con cui informare gli interessati dell’esistenza di una profilazione; II) la presenza di procedure atte a minimizzare il trattamento dei dati, nel senso specificato dall’art. 5(1)(d);  III) la conservazione dei dati per dati conservati per un tempo proporzionato allo scopo del trattamento (c.d. Data Retention provisions).
Inoltre dovrebbe sicuramente essere operato un controllo sulla pertinenza delle informazioni e delle inferenze statistiche, così come un controllo degli algoritmi al fine di minimizzare la percentuale di errore.

Conclusioni

Che ne è stato di SAVIO e del suo utilizzo in INPS lo ha specificato il Garante a seguito di un’istruttoria avviata nell’anno corrente.
Nello specifico, si sono verificate tre circostanze contrastanti con la normativa in materia di dati personali: I)  Il software operava all’insaputa dei lavoratori interessati, e questo avveniva all’incirca da cinque anni; II) Il software non prevedeva precauzioni e garanzie specifiche volte ad evitare incongruenze nella logica degli algoritmi utilizzati o decisioni erronee con impatti negativi sui singoli; III) Come all’epoca, ma come anche oggi previsto nella normativa GDPR, INPS aveva omesso di notificare al Garante la circostanza dell’adozione di tale meccanismo predittivo basato sulla profilazione.
Su quest’ultimo punto, nello specifico, INPS aveva ritenuto che SAVIO non consistesse in un trattamento di profilazione. Il Garante ha però specificato che:  «[…] le attività di analisi statistica realizzate in tal modo sui certificati medici […] determinano, invece, un’effettiva profilazione, nella misura in cui, sulla base di inferenze statistiche, realizzano una prognosi comportamentale».
In conclusione, l’Autorità Garante ha rilevato l’omissione in cui è incorso l’Istituto e, soprattutto, l’assenza delle necessarie misure di garanzia, pur offrendo piena collaborazione a realizzare un sistema di programmazione delle visite fiscali efficiente, ma altrettanto rispettosa del suo ruolo e del diritto alla protezione dei dati personali.
Ne è seguita la decisione dell’Istituto di sospendere l’attività di profilazione e l’utilizzo del software SAVIO.

[1] Presidente del Garante per la Protezione dei Dati Personali.
[2] Per data mining intendiamo, sinteticamente, una estrapolazione di dati in formato elettronico dalle innumerevoli fonti che compongono la rete Internet e i dispositivi ad essa connessi. Sul punto cfr. Stefano Neri, La disciplina del Data Mining alla luce della proposta di regolamento comunitario in materia di trattamento di dati personali: criticità, limiti e prospettive de jure condendo, FiloDiritto, 20 Aprile 2015, disponibile al sito: https://is.gd/P9YLmW.
[3] Audizione di Antonello Soro, Presidente del Garante per la protezione dei dati personali, in tema di utilizzo delle metodologie di data mining per eseguire visite mediche di controllo nei confronti dei lavoratori del settore pubblico; Doc-Web n. 9043373, 18/09/18, disponibile al sito: https://is.gd/FUU2OP.
[4] Ibidem.
[5] Ibidem.
[6] Cfr. art. 4(1) GDPR. Per Dato Personale si intende: «qualsiasi informazione riguardante una persona fisica identificata o identificabile («interessato»); si considera identificabile la persona fisica che può essere identificata, direttamente o indirettamente, con particolare riferimento a un identificativo come il nome, un numero di identificazione, dati relativi all’ubicazione, un identificativo online o a uno o più elementi caratteristici della sua identità fisica, fisiologica, genetica, psichica, economica, culturale o sociale»;
[7] Cit. art. 35(3)(a) GDPR. Consultare l’intero articolo per un approfondimento sugli altri casi di obbligatorietà della DPIA.
[8] Cfr. Art. 29 Working Party, WP 248 rev.01, Linee-guida concernenti la valutazione di impatto sulla protezione dei dati nonché i criteri per stabilire se un trattamento “possa presentare un rischio elevato” ai sensi del regolamento 2016/679. Adottate il 4 aprile 2017. Versione successivamente emendata e adottata il 4 ottobre 2017.
[9] Ibidem.
[10] Cfr. nota 3.

Autore