Quando arrivo’ il GDPR , io con altri colleghi stavamo costruendo uno storage Hadoop dimensionato per 400 milioni di utenti, e quindi fu circa un asteroide. Improvvisamente mi ritrovai insieme ad un pool di avvocati dell’azienda-cliente (il dipartimento legale) , i quali capivano bene il regolamento, ma non capivano il significato dei tecnicismi. D’altro canto, io e gli altri architetti (reti, storage, fabric & co) capivamo i tecnicismi ma non il legalese.
La mia azienda mi fece fare il corso intensivo di GDPR, e la fiera comincio’.
In generale gli avvocati capivano bene tutta la parte legale, dicevo, ma non capivano le tecnicalita’: spesso dicevano “in quel caso cancelliamo il record”, credendo fosse come un un database, ma non sapevano che se cominci a fare partizioni da 64GB ciascuna, per fare un esempio, non puoi cancellare un record. Devi, a seconda del formato (AVRO, PARQUET, etc) scrivere un job che copia tutto su un altro blocco, tranne quel record. Impraticabile.
Anche il fatto che a seconda del formato (AVRO si, PARQUET no, etc) non si possa facilmente cambiare la struttura (i campi) era per loro una cosa sconosciuta. LA differenza tra dato pseudonimo , anonimo e criptato , cosi’ come la differenza tra una criptazione omeomorfa e una non omeomorfa era per loro difficile da cogliere.
Quindi furono settimane “di fuoco”, se escludiamo la quantita’ di g-nocca tipica dei team legali di qualsiasi azienda. Ebbene si’, chi quote quote, chi non quote se lo squote. (LOL)
Ora, se provo ad immaginare di applicare un processo del genere alle scuole che usano cloud stranieri mi vengono in mente diverse cose. Per esempio: il GDPR Article 5(1)©, dice “personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”.
Ora, qui il problema e’ capire cosa significhi “adequate”, cosa significhi “relevant” e cosa significa “necessary”, e che cosa significa “purposes”: perche’ il legalese e’ una lingua, e non necessariamente una lingua semplice.
Facciamo un passo indietro: “Privacy by design”. Questo concetto, centrale nel GDPR, dice che e’ necessario che la privacy sia implementata nel design del servizio e della gestione dei dati. E non e’ derogabile al google della situazione o al Microsoft, perche’ il dato compie un giro lungo, che coinvolge sia il “data processor” che il “data owner”, che il “data controller”, (e sul data owner c’e’ una certa ambiguita’ giudirica) , e quindi anche la scuola dovrebbe costruire la documentazione di Privacy by design.
Per prima cosa , siccome anche la scuola maneggia questi dati e ci fa le pagelle, google apparentemente diventa un data controller mentre la scuola e’ un data processor, per esempio, a riguardo del processo scolastico. In realta’, sarebbe piu’ verosimile dire che google e la scuola siano in una situazione di joint controller, anche perche’ alcuni dati (per esempio l’ IP da cui si collega uno studente) non sono inseriti dalla scuola. Link
Stabilito chi fa cosa, in entrambi i casi la scuola deve fare un documento di Privacy By Design, che sia ispezionabile. Anche Google lo avra’ fatto (visto che offre la piattaforma business alle scuole , a condizioni economiche vantaggiose), ma le due cose sono separate e nessuna delle due sostituisce l’altra.
Cosa ci aspettiamo da questo/i documento/i che fa la scuola?
- quali siano gli usi “necessary” (es: serve a fare le pagelle. Serve ad identificare l’utente (es, il nome) etc.
- quali siano i “purposes”, cioe’ per che cosa servono quei dati. Per esempio, giustificare la videoconferenza da una stanza di casa potrebbe diventare problematico.
- quali dati siano “necessari”, quali “rilevanti”: per esempio, tenere accesa la telecamera dei ragazzi potrebbe essere “rilevante” ma non necessario, e cosi’ via.
- nel caso le lezioni siano registrate, per esempio, bisogna capire chi possa salvare l’informazione, per cosa sia necessaria, rilevante, eccetera.
Bene.
A quel punto si prenderanno tutti i dati che la scuola accede attraverso il sistema (orario di inizio, orario di fine della lezione, numero e nome dei presenti, nome, cognome, documenti inviati/allegati, videoconferenza, fonoconferenza, stato di salute, etc) , si fa una bella tabella e si indicano tutta una serie di dettagli:
- dove siano salvati. (se la scuola ne ha una copia cartacea). Chi ne sia responsabile.
- se sono necessari, rilevanti, non necessari
- se sono criptati, pseudonomizzati, in chiaro.
- se sono PII (l’orario di inizio della lezione e’ un PII? per il prof si, perche’ fa presenza al lavoro, per gli alunni… boh. Il registro delle assenze forse).
- quanto tempo verranno tenuti.
riempire questi campi non e’ semplice come sembra. Per identificare l’utente potrebbe sembrare naturale usare “nome, cognome”, ma in realta’ anche Cognome, Iniziale del nome potrebbe andare, e sarebbe questionabile anche l’idea di usare solo il cognome.
Questa parte e’ abbastanza delicata: per esempio, un sistema di posta elettronica puo’ trasferire qualsiasi cosa. Facciamo un esempio. Io scrivo da casa che saro’ assente perche’ ho un’influenza alla mia team assistant, allegando il certificato e mettendo in copia la krankenkasse e il mio capo. Sembra sensato, ma non lo e’:
- il mio capo deve solo sapere che sono assente, non il mio stato di salute.
- la mia krankenkasse non deve sapere chi sia il mio capo ne’ chi sia la team assistant.
- la mia team assistant non deve sapere quale sia la mia krankenkasse perche’ sono un contribuente volontario (ok, e’ una cosa tedesca. Oltre un certo reddito non sei un contribuente come gli altri, ma puoi scegliere anche di non pagare la krankenkasse, solo che paghi tutto di tasca tua).
Quindi al capo e ai colleghi io diro’ di essere “assente”, alla team assistant mandero’ la nota per l’assenza e il certificato medico, alla krankenkasse idem, ma senza mai citare tutti nella stessa mail. Altrimenti:
- il mio capo cancellera’ la mail e chiedera’ agli admin di toglierla da exchange.
- la krankenkasse cancellera’ la mail e non mi dira’ nulla (grrrr!) e lo scopriro’ quando non mi pagheranno le giornate.
- la mia team assistant cancellera’ la mail perche’ c’e’ la krankenkasse in copia.
Morale: il DGPR non e’ semplice.
Una volta stabiliti i dati dei quali la scuola e’ joint processor, e averli classificati per capire a cosa servono , se sono necessari, auspicabili, PII , e tutto quanto, e’ necessario parlare del tempo di retenzione.
Il tempo di retenzione dei dati NON deve andare oltre al loro necessario utilizzo. Nel caso della scuola, se ne esiste un formato copia in cartaceo, significa che in teoria finito l’anno scolastico andrebbero cancellati TUTTI, e viene da chiedersi (nel caso vengano stampati su carta come verbale , es i compiti in classe) , se anche un trimestre non sarebbe sensato.
C’e’ anche una distinzione tra dato aggregato e dato: i voti di ogni singola interrogazione e di ogni compito in classe per esempio sono “dati”. Se calcoliamo la media dei voti per classe, togliendo i nomi e i cognomi degli studenti, abbiamo un “aggregato”. Gli aggregati non hanno molti limiti ai sensi del GDPR. Ma se produci aggregati sei anche , oltre ad un joint data controller, anche un data processor. Nel caso in cui il data processor richieda l’aiuto di qualcuno per processare i dati, esso diventa una “terza parte”.
Quindi in definitiva , la scuola che usa Google, o Teams, o altro per la sua didattica:
- diventa quasi automaticamente un joint controller ai sensi del GDPR. Quindi ha tutte le responsabilita’ del controller e anche quella di definire con l’altro controller chi sia il “Main” data controller che si fa la maggior parte del lavoro. Non e’ scontato che sia google.
- devono indicare un Data Officer, cioe’ la persona da informare in caso di qualsiasi problema (data leak, cambio di legitimate purpose, etc).
- devono indicare chi sia il data owner (che ha il controllo completo dei dati e puo’ dare o togliere accesso ai dati stessi) e il data custodian (la persona che vigila sul rispetto di quanto sopra).
In assenza di questo, il GDPR non e’ assolutamente rispettato, e anche la “liberatoria” e’ completamente irrilevante ai sensi di legge: se non esiste privacy by design e by concept, il fatto che qualcuno firmi una liberatoria non cambia nulla di nulla.
Last but not least, l’opt out e’ un diritto. Significa che i genitori, in quanto tutori, devono avere accesso ad un link dal quale possono rimuovere i dati dei loro figli , in qualsiasi momento arbitrariamente scelto da loro.
Onestamente, da quanto sento dire in giro non vedo nulla di tutto questo in giro per le scuole italiane, e anche le scuole tedesche si sono rese conto che questo sia eccessivamente laborioso e si stanno facendo fare dal ministero dei sistemi propri, (il ministero della scuola e’ federalizzato per Land) e quindi alla fine l’uso di piattaforme corporate sta calando copiosamente.
Ma il punto e’ semplice: NON BASTA una liberatoria per diventare GDPR-compliant quando si usa google o teams o zoom, nemmeno nel caso queste aziende fossero PROVATAMENTE GDPR compliant.
Prima o poi, magari a lockdown finito, assisteremo a tutta una serie di cause legali, dal momento che i presidi italiani hanno reagito con estrema ignoranza “chiediamoje Äa libberadoria!” , come se questo esumesse le scuole dal rispettare il GDPR.
Ma la liberatoria non protegge nessuno, e le multe sono GROSSE.
Quello che potete fare come genitori e’:
- pretendere che a fine anno scolastico TUTTI i dati vengano tolti dal cloud straniero , stampati e archiviati come si faceva nei cartacei.
- pretendere che ci si limiti ai dati MINIMI, ovvero se i cognomi sono unici, solo il cognome, se i cognomi non sono unici solo nome e iniziale, etc
- pretendere di conoscere il nome del data officer.
Per queste cose NON e’prevista liberatoria.
