Il 19 ottobre 2022 INPS ha aperto una gara per l’Acquisizione di un sistema di “Anonimizzazione dati”. Qui saranno valutate le migliori soluzioni offerte da startup e compagnie di alta tecnologia allo scopo di anonimizzare efficacemente le varie basi dati INPS.
Lo scopo è di anonimizzare one-way i dati di produzione, allo stesso tempo preservando le relazioni tra i dati, senza che ci sia modo di risalire ai dati originali e impedire di re-identificare le persone.
Si tratta di un progetto molto importante per un aspetto di estrema importanza nel processo di scrittura di un software sicuro, performante, che si possa manutenere e riusabile: il testing del software. Una pratica lenta e costosa quanto inefficace se mal gestita, eppure essenziale, come vedremo.
Ma come conciliare questo processo con la riservatezza dei dati? Come far sì che gli sviluppatori software possano testare efficacemente ed esaustivamente gli applicativi senza far riferimento a dati veri?
Oltre lo sviluppo del software: il testing
Spesso il testing del software viene confuso con il cosiddetto “testing manuale”, dove persone provano a mano l’applicativo software nella sua interezza e ne riportano gli errori da correggere. È una pratica lenta, costosa e per di più inefficace se gestita male.
Per questo nel corso dei decenni, con l’evolversi dell’ingegneria del software, sono emersi modelli e strategie per il testing automatico (quindi non più manuale) da usare anche in maniera complementare per migliorare la qualità complessiva del software. Ad esempio, il TDD (Test-Driven Development), dove i test vengono scritti prima del codice stesso, e la Piramide dei Test, che definisce lo sforzo da dedicare alle varie tipologie di test (test di UI al vertice, test di integrazione in mezzo, test di unità in fondo) in modo da massimizzarne l’efficacia e la velocità di esecuzione.
Quali dati per il testing
Che siano manuali o automatizzati o un misto di entrambi, bisogna però anche chiedersi quali siano i dati usati per il testing. Una domanda all’apparenza banale, ma che nasconde un problema molto delicato.
Chiunque si occupi di ingegneria del software sa che un applicativo segue una serie di rilasci intermedi prima di essere rilasciato a tutti in “produzione”. Infatti, l’applicativo viene prima eseguito, in successione, su diversi ambienti che sono spesso chiamati “sviluppo”, “collaudo”, “pre-produzione”. Solo quando i test in ambiente di pre-produzione sono completati con successo, allora l’applicativo viene rilasciato in produzione. ma quali sono i dati usati per testare gli ambienti di “sviluppo”, “collaudo” e “pre-produzione”?
La risposta a prima vista potrebbe essere: “Semplice. Riversiamo i dati dell’ambiente di Produzione negli altri ambienti”.
Se tralasciamo la dimensione dei dati in questione (cosa impensabile nel caso ad esempio di Facebook), la risposta sembrerebbe corretta. Però si apre un interrogativo: se i dati dell’ambiente di Produzione fossero copiati tali e quali in ambiente di Sviluppo (ad esempio), questi diventerebbero accessibili e visibili agli sviluppatori software. Se in alcuni casi questo non rappresenta un problema, è invece una gravissima falla in tanti altri.
Pensiamo ad esempio al caso dell’INPS, l’ente più importante della Pubblica Amministrazione italiana, che ha informazioni praticamente di ogni cittadino italiano. Sono dati importanti, da maneggiare e proteggere con la massima cura.
Se questi dati di Produzione fossero copiati in ambiente di Sviluppo, sarebbe un disastro: lo immaginate che succederebbe se i dati di Sergio Marchionne (se fosse ancora vivo) fossero accessibili a qualsiasi sviluppatore software che lavora ai progetti INPS? Questi dati sono per definizione PII (Personally Identifiable Information), e vanno assolutamente protetti. Si tratta di buon senso, ben prima che di GDPR o altre norme relative alla privacy.
Ma allora come conciliare il testing con la riservatezza dei dati?
Testing e privacy: strategie per conciliare esigenze diverse
Non esiste una risposta perfetta, ma si possono adottare varie strategie, spesso più di una allo stesso tempo. Ce ne sono molte, ma per semplicità qui ne riporto solo alcune.
Dati parziali
Anziché copiare l’intera base dati di produzione, ci si limita a un suo piccolo sottoinsieme. Ne risulta un’alta efficacia per quanto riguarda i test; però ovviamente il problema privacy rimane, anche se ridotto.
Dati offuscati
I dati di Produzione vengono copiati dopo un processo di offuscamento. Un esempio banale consiste nel cambiare nome e cognome degli utenti. Problema risolto? Non completamente. Nonostante il cambio di nome, sarebbe semplice identificare la persona reale dietro un Mario Rossi fittizio, se si vede che questi risiede ad Arcore e che ha reddito ben oltre la media.
Ripeto: quello che ho fatto è un esempio banale. Nella realtà i processi seri di offuscamento vanno ben oltre il semplice cambio di nome e coinvolgono altri valori; rimane però il fatto che analisi approfondite dei dati offuscati, magari con l’aggiunta di dati disponibili pubblicamente, possano portare a identificare persone con una certa precisione. Inoltre l’offuscamento potrebbe introdurre problemi di inconsistenza dovuti al non rispetto di vincoli interni delle basi dati coinvolte (che a volte adoperano tecnologie eterogenee), con conseguente non mantenimento dell’integrità complessiva dei dati.
Dati sintetici
I dati di produzione? Qui vengono ignorati completamente. In loro vece, i dati dell’ambiente di sviluppo vengono creati ex novo anche tramite algoritmi di Machine Learning, simulando quelli veri che ci sarebbero in Produzione. Perfetto dal punto di vista della privacy. Però potrebbe non cogliere tutte le sfumature dei dati reali con i casi limite ad essi connessi, limitando quindi l’efficacia dei test.
Alla ricerca di soluzioni avanzate
Cosa fare quindi? È un problema noto, a cui ad esempio enti come il Dipartimento della Difesa USA cercano continuamente soluzioni: nel loro caso, come far sì che la sicurezza nazionale sia aumentata, senza però che dati militari sensibili vengano diffusi?
In INPS abbiamo preso la decisione di alzare costantemente la barra della qualità dei servizi verso i cittadini. Senza retorica, è davvero uno sforzo titanico che coinvolge varie Direzioni, e che come Struttura per l’Innovazione Tecnologica e la Trasformazione Digitale siamo orgogliosi di supportare. Consci della difficoltà del problema, per risolverlo ci siamo messi in ottica di Open Innovation. Cosa vuol dire? Cito le parole di Alberto Onetti in questo articolo: “L’Open Innovation invece si basa su un principio opposto. Presentare un problema e chiedere al mercato di identificarne una soluzione, senza porre limiti e condizioni. […] Il che non vuol dire essere ribelli che vogliono solo rompere cose. Alla fine, vogliamo la stessa cosa dell’ufficio acquisti: portare a casa le migliori soluzioni al prezzo più basso.”
Se fosse possibile, tali dati anonimizzati si potrebbero usare in tutti gli ambienti: “sviluppo”, “collaudo” e “pre-produzione”. E permetterebbe di ottenere innanzitutto questo risultato importantissimo:
Qualità del software
Rilasciare continuamente aggiornamenti del software, con sempre maggiore velocità ed affidabilità. Con un ambiente di collaudo e pre-produzione su cui eseguire test automation basata su dati equivalenti a quelli di produzione, tutto questo diventa molto più facile.
Se poi, in aggiunta, i dati anonimizzati avessero informazioni statistiche simili a quelle di Produzione e si preservasse l’utilità del dato, allora si aprirebbe questa ulteriore opportunità:
Open data
In ottica open data, condividere dati con personale esterno (e.g., accademici, ricercatori, studenti) per data mining e analisi con grado di accuratezza comparabile a quelli non anonimizzati. E, perché no, far sì che questa sia la base per hackathon da cui possano nascere altri servizi open utili al cittadino.
A che punto siamo
Questa gara INPS segue la Consultazione di Mercato indetta precedentemente. In quella occasione ricevemmo 26 partecipazioni, con interesse di compagnie sia dall’Italia che dall’estero. E devo dire che rimanemmo piacevolmente sorpresi dal livello di alcune di queste, davvero ai limiti della frontiera tecnologica.
Tuttavia, al bando di gara appena concluso la partecipazione è stata minore. Alcune delle soluzioni ricevute in passato nella consultazione di mercato, e che sulla carta erano eccellenti, non sono state proposte in questa gara. La cosa ci ha stupito parecchio. La gara ha un valore economico di 1 milione di euro: cifra rilevante per un sistema altresì importante, e quindi non può essere quello il motivo per cui alcuni hanno rinunciato ora a partecipare.
Cosa è cambiato tra la consultazione di mercato precedente e la gara attuale?
Trust, but verify: fidarsi ma verificare
“Fidati, ma verifica”. Questo è quanto disse Ronald Reagan a Mikhail Gorbachev nel 1987, citando proprio una massima del pensiero russo, mentre firmavano il trattato di eliminazione dei missili nucleari a raggio intermedio installati da USA e URSS sul territorio europeo.
Perché lo dico? Anche a me piace fidarmi del contenuto delle proposte tecniche ricevute. Però l’Ingegneria è il regno della concretezza, e mal si addice a soluzioni con buoni propositi ma valide solo sulla carta. Questo è ancora più vero in un settore come questo dell’anonimizzazione dati, estremamente delicato, con tecnologie di avanguardia spesso sviluppate in ambienti militari e che richiedono competenze rare nel mondo.
Per questo abbiamo strutturato la gara in più fasi.
La prima fase è di “Trust”, fiducia. Tra le soluzioni ricevute, sceglieremo le 3 che riterremo più valide in base alle soluzioni tecniche descritte, paper scientifici a supporto, implementazione e referenze industriali.
A questo punto entrerà in gioco la fase di “Verify”, verifica. Per prima cosa ognuno dei 3 finalisti dovrà applicare la propria soluzione di anonimizzazione a dei dati forniti dall’INPS. A questo punto si entrerà in una competizione in cui ciascun finalista proverà a de-anonimizzare la soluzione degli altri 2 concorrenti. In altre parole, una fase di vero e proprio “hacking” in cui i finalisti si attaccheranno a vicenda, col risultato di determinare nei fatti quale sia la soluzione migliore.
È un’intuizione che ci è venuta mentre discutevamo la strada più valida per valutare le soluzioni, e ci tengo a ringraziare Pierpaolo Bonanni nella mia struttura per questo guizzo creativo (“thinking out of the box” direbbero gli americani). Così abbiamo poi scoperto che il concetto esiste già nel gergo legale italiano, e si chiama “dialogo competitivo”. In sostanza vuol dire proprio quello che avevamo in mente: scegliere la soluzione che si dimostra essere la migliore sul campo, valutata nella pratica e non solo sulla carta.
Questo è in assoluto il primo dialogo competitivo dell’INPS. Il mio auspicio, in primis da Italiano, è che questo approccio venga adottato sempre più spesso nelle Pubbliche Amministrazioni, specialmente là dove vanno fatte importanti scelte tecnologiche di alto beneficio per i cittadini.
Conclusioni
Personalmente io ho poi un piccolo grande sogno. Nell’Ottobre 2006 ero studente a Stanford, e seguivo il corso di Data Mining di Jeff Ullman (nome noto agli Informatici anche per il Dragon Book di Compilatori). Il professore ci invitò a partecipare a una competizione che Netflix aveva appena lanciato: il “Netflix Prize”. Questa competizione era aperta a tutti, e chiedeva di migliorare del 10% l’accuratezza dell’algoritmo di Netflix nel suggerire film all’utente. Il premio per chi ci fosse arrivato per primo era di 1 milione di dollari. Si scatenò il mondo della ricerca accademica e privata, con professori, ricercatori, professionisti e studenti alla caccia dell’algoritmo vincente.
Perché parlo di questo? Sarebbe bello che, sull’esempio del Netflix Prize e con accesso ai dati anonimizzati, si promuovesse in Italia una competizione alla ricerca di algoritmi che performino meglio di quelli in INPS o altre Pubbliche Amministrazioni.
Magari può sembrare un sogno, e già sento le voci di chi dirà che questo sarà impossibile da noi. Ma io vedo l’INPS e in generale l’Italia pian piano percorre la giusta strada dell’innovazione a beneficio del cittadino. E, per usare le parole di Gabriele D’Annunzio a Buccari, può giungere presto il momento di “osare l’inosabile”, soprattutto nelle tecnologie avanzate.
