Perché è importante per il valore pubblico

Ogni ente pubblico detiene già più dati di quanti ne usi bene. Un'agenzia fiscale, una rete ospedaliera, un'agenzia dei trasporti e un ufficio di pianificazione locale raccolgono ciascuno informazioni come sottoprodotto della gestione di un servizio, e ciascuno scopre, di solito troppo tardi, che il registro di cui ha bisogno per rispondere alla domanda di un cittadino o risolvere una controversia giace in un sistema che nessun altro nell'organizzazione può interrogare. Il costo non è astratto: un cittadino che ha già comunicato a un'agenzia il proprio indirizzo non dovrebbe doverlo comunicare di nuovo a un'altra agenzia dentro lo stesso governo.

Due ambizioni distinte stanno dentro il titolo di questo argomento, e gli enti pubblici le confondono abitualmente. La prima è l'interoperabilità – far muovere in modo affidabile i dati fra sistemi che gruppi ed epoche tecnologiche diversi hanno costruito indipendentemente, così che una parte del governo possa agire su ciò che un'altra parte già sa. La seconda è l'apertura – pubblicare i dati del tutto fuori dal governo, così che giornalisti, ricercatori e cittadini possano usarli per scopi che l'ente che pubblica non aveva previsto. L'interoperabilità è per lo più un problema di ingegneria e di governance; l'apertura è un valore pubblico a pieno titolo, della stessa famiglia dei beni pubblici descritti nell'Argomento 1.4 — Beni pubblici, beni meritori e pluralismo dei valori, perché i dati pubblicati sono non rivali e difficili da cui escludere chiunque una volta rilasciati, per cui un mercato da solo li fornirebbe in quantità insufficiente.

Entrambe le ambizioni si scontrano con un terzo fatto che questo argomento tratta come una tensione genuina e irrisolta anziché come un problema con una risposta ordinata: i dati abbastanza dettagliati da essere utili sono spesso abbastanza dettagliati da identificare l'individuo che descrivono, anche dopo che nomi e identificatori ovvi sono stati rimossi. Un governo che pubblica in modo ricco e un governo che protegge bene le persone nei propri registri tirano in direzioni diverse sulla stessa leva, e la crescente fame di dati per addestrare e valutare sistemi algoritmici (vedi Argomento 5.2 — Intelligenza artificiale e decisioni algoritmiche nel governo) ha alzato la posta, perché più attori che mai vogliono dati pubblici proprio alla granularità che li rende più rischiosi da rilasciare. Un leader che tratta governance, interoperabilità e apertura come un unico problema, con la riservatezza come vincolo permanente, è meglio collocato per cogliere il valore di questo argomento di uno che tratta ciascuna in isolamento.

Concetti chiave

La governance dei dati è l'insieme di diritti decisionali, standard e responsabilità che determinano chi può creare, modificare, accedere e ritirare i dati di un'organizzazione e a quale standard di qualità debbano essere tenuti (vedi governance dei dati). È distinta dalla gestione dei dati, che è il lavoro operativo di spostare e memorizzare i dati giorno per giorno; la governance decide le regole, la gestione le esegue. Un ente pubblico senza governance dei dati ha comunque dati, ma nessuno sa dire con sicurezza quale copia del registro di un cittadino sia quella autorevole, né chi sia responsabile quando quel registro si rivela sbagliato.

Un responsabile dei dati (data steward) è l'individuo o il ruolo nominato responsabile della qualità, della definizione e dell'uso appropriato di uno specifico insieme di dati, distinto dal personale tecnico che gestisce i sistemi in cui risiede (vedi data steward). La responsabilità conta perché la qualità dei dati decade per impostazione predefinita: un campo di cui nessuno è responsabile accumula voci incoerenti, registrazioni duplicate e deriva silenziosa fra ciò che un campo dovrebbe significare e ciò che il personale vi inserisce davvero. Assegnare un responsabile a un insieme di dati converte la qualità dei dati da un esercizio di pulizia occasionale in una responsabilità continua e nominata.

L'interoperabilità è la capacità di sistemi costruiti indipendentemente di scambiare dati e usarli correttamente senza ingegneria ad hoc, una tantum, per ogni coppia di sistemi coinvolti (vedi interoperabilità). Opera su tre livelli facili da confondere: l'interoperabilità tecnica (i sistemi possono connettersi e muovere byte, tipicamente tramite un'interfaccia di programmazione di applicazioni, o API, un modo definito perché un software richieda dati o azioni a un altro – vedi interfaccia di programmazione di applicazioni); l'interoperabilità semantica (entrambi i sistemi intendono la stessa cosa con un campo condiviso, come "nucleo familiare" o "caso attivo"); e l'interoperabilità organizzativa (le due organizzazioni concordano sul perché i dati siano condivisi e su chi sia responsabile di ciò che accade poi). La maggior parte dei costosi fallimenti di interoperabilità avviene a livello semantico o organizzativo anche quando la connessione tecnica funziona perfettamente.

Uno schema comune, o standard di dati, è una struttura concordata e pubblicata per come una categoria di dati è rappresentata – nomi dei campi, formati, unità e valori ammessi – adottata da più di un sistema o organizzazione così che i dati prodotti da uno possano essere consumati da un altro senza traduzione manuale. Gli enti di governo che adottano uno schema condiviso per qualcosa di basilare come un indirizzo o uno stato di pratica convertono decine di potenziali problemi bilaterali di traduzione in un solo standard che ogni nuovo sistema può semplicemente implementare. Un identificatore univoco che persista fra sistemi e nel tempo – un numero di pratica, un numero di registrazione di impresa, un riferimento di cittadino – è lo specifico meccanismo che permette di collegare correttamente registrazioni sulla stessa persona o entità, e sbagliare il disegno dell'identificatore (riutilizzare numeri, cambiare formati o non averne affatto uno) è una delle cause più comuni ed evitabili di fallimento dell'interoperabilità.

I metadati sono dati sui dati – la descrizione della struttura, della provenienza, della frequenza di aggiornamento e del significato di un insieme di dati, pubblicata insieme ai dati stessi così che un utente che non li ha creati possa capirli e fidarsene (vedi metadati). Un insieme di dati pubblicato senza metadati adeguati è appena utilizzabile da chiunque fuori dal gruppo che lo ha prodotto, per quanto aperta sia la sua licenza; i metadati sono ciò che trasforma uno scarico di file in qualcosa che una terza parte può effettivamente riutilizzare.

Un accordo di condivisione dei dati è un assetto formale fra agenzie, o fra un ente pubblico e un partner esterno, che specifica lo scopo per cui i dati possono essere usati, la base giuridica per condividerli, per quanto tempo possano essere conservati e che cosa accada se lo scopo cambia. La limitazione dello scopo – restringere l'uso dei dati condivisi allo scopo per cui furono raccolti o condivisi – è la disciplina che impedisce a un accordo di condivisione dei dati di diventare una licenza illimitata a riutilizzare informazioni personali, e la sua assenza è un tema ricorrente nei fallimenti di fiducia pubblica che riguardano dati fra agenzie.

I dati aperti (open data) sono dati resi liberamente disponibili perché chiunque vi acceda, li usi e li ridistribuisca, per qualsiasi scopo, tipicamente leggibili da macchina e rilasciati con una licenza che permette il riutilizzo anziché la mera visione (vedi dati aperti). Il loro caso di valore pubblico segue la logica dei beni pubblici esposta nell'Argomento 1.4 — Beni pubblici, beni meritori e pluralismo dei valori: una volta pubblicato un insieme di dati, l'uso di una persona non diminuisce quello di un'altra, e il governo è spesso l'unico attore con sia la posizione giuridica sia la scala per raccoglierli e pubblicarli in primo luogo, per cui i soli mercati privati forniscono cronicamente in modo insufficiente questo tipo di informazione. I dati aperti rendono possibili responsabilità (giornalisti e cittadini che controllano le affermazioni del governo rispetto ai suoi stessi registri), innovazione di terzi (imprese e tecnologi civici che costruiscono servizi sopra dati pubblici che il governo non costruirà mai da sé) e decisioni pubbliche migliori altrove nell'economia, il tutto senza che l'ente che pubblica debba anticipare ogni uso in anticipo.

La re-identificazione è il processo di confrontare dati presumibilmente anonimizzati con altre informazioni disponibili per capire quale persona reale una registrazione descriva, ed è il fatto tecnico centrale che rende la tensione di riservatezza di questo argomento inevitabile anziché semplicemente scomoda (vedi re-identificazione dei dati). Rimuovere un nome, o un identificatore ovvio come un numero di previdenza o di sicurezza sociale, non rimuove il rischio: una combinazione di quasi-identificatori come età, codice postale e una condizione medica rara può identificare in modo univoco qualcuno anche in un insieme di dati che non l'ha mai nominato, specialmente una volta incrociato con un altro insieme di dati, separatamente pubblico. La k-anonimità è un modo formale di ragionare su questo rischio: un insieme di dati soddisfa la k-anonimità se ogni combinazione di campi quasi-identificanti che contiene è condivisa da almeno un numero definito, k, di registrazioni, così che nessuna singola riga possa essere isolata a meno di k persone possibili (vedi k-anonimità). La privacy differenziale è un approccio più recente e matematicamente rigoroso che aggiunge rumore statistico accuratamente calibrato a un insieme di dati o ai risultati delle interrogazioni su di esso, così che la presenza o l'assenza della registrazione di un singolo individuo cambi l'output pubblicato solo di una quantità limitata e dimostrabile, a prescindere da ciò che un aggressore già sa (vedi privacy differenziale). La privacy fin dalla progettazione (privacy by design) è il principio più ampio per cui la tutela della riservatezza dovrebbe essere incorporata nell'architettura di un sistema fin dall'inizio, come impostazione predefinita, anziché aggiunta come passaggio di oscuramento poco prima della pubblicazione (vedi privacy by design); oscurare gli identificatori ovvi a posteriori è la forma più debole di questa disciplina, non un sostituto di essa.

Buone pratiche

  1. Nominate un responsabile per ogni insieme di dati che conta, non solo un ufficio centrale dei dati. Un ufficio dei dati può fissare standard, ma non può sapere se uno specifico campo in uno specifico sistema significhi ancora ciò che era stato definito significasse; quel giudizio spetta a qualcuno vicino all'uso effettivo dei dati.
  2. Pubblicate aperto per impostazione predefinita e documentate la ragione specifica ogni volta che non lo fate. Invertire il default – richiedere una giustificazione per trattenere anziché una giustificazione per pubblicare – fa emergere le sensibilità genuine per un esame individuale anziché lasciare che la cautela si applichi a tutto indiscriminatamente.
  3. Adottate uno schema condiviso esistente prima di progettarne uno nuovo. Una struttura di dati su misura che si adatta perfettamente a un progetto e non corrisponde a nient'altro nel governo garantisce un futuro costo di integrazione; controllate che cosa il vostro settore, la vostra giurisdizione o un organismo internazionale di normazione abbia già pubblicato prima di costruire il vostro.
  4. Progettate identificatori univoci persistenti e ben governati prima che un sistema vada in funzione, non dopo. Adattare a posteriori uno schema di identificatori su registrazioni accumulatesi per anni sotto chiavi incoerenti è drammaticamente più costoso che farne bene il progetto all'inizio.
  5. Costruite lo scambio di dati attraverso API governate anziché trasferimenti di file una tantum. Un'API che impone uno schema, registra gli accessi e può essere versionata vi dà un punto di interoperabilità controllabile e verificabile; un foglio di calcolo inviato per email fra uffici non vi dà nulla di tutto ciò e nessuno nota quando diventa obsoleto.
  6. Scrivete accordi di condivisione dei dati che dichiarino lo scopo, la base giuridica e la scadenza, non solo il meccanismo tecnico. Un accordo che specifica come i dati si muovono ma non perché, né per quanto tempo, tende a sopravvivere allo scopo che lo giustificava e a diventare silenziosamente permesso per qualcosa che nessuno ha esplicitamente autorizzato.
  7. Trattate la de-identificazione come una valutazione del rischio con un risultato residuo, non come un compito di oscuramento una tantum. Chiedetevi quali altri insiemi di dati pubblici o acquistabili potrebbero essere collegati a quello che state per rilasciare e dimensionate il rischio di re-identificazione rispetto a quella realistica minaccia, non rispetto a un aggressore idealizzato senza informazioni esterne.
  8. Applicate la privacy differenziale o una tecnica formale equivalente a qualsiasi rilascio che riguardi piccole popolazioni o caratteristiche rare. La semplice soppressione o generalizzazione degli identificatori ovvi è insufficiente una volta che un insieme di dati include qualcosa di abbastanza insolito da essere identificante da sé, come una condizione rara, una piccola popolazione locale o una transazione di alto valore.
  9. Mantenete un catalogo pubblico e aggiornato dei dati con metadati reali, non solo un elenco di nomi di file. Un insieme di dati che un potenziale utente non riesce a capire abbastanza bene da fidarsene è funzionalmente non pubblicato, per quanto permissiva sia la sua licenza; le voci del catalogo dovrebbero dire che cosa significhi un campo, con che frequenza si aggiorni e quali siano i suoi limiti noti.
  10. Misurate la qualità dei dati rispetto a standard definiti a una scadenza ricorrente e riferite i risultati a chi possiede l'insieme di dati. La qualità che viene controllata solo quando qualcosa si rompe decade invisibilmente per lunghi periodi nel frattempo; una misurazione di routine trasforma il decadimento in una tendenza visibile e gestibile.
  11. Riesaminate periodicamente ogni insieme di dati pubblicato per il continuo valore pubblico e il continuo rischio. Le popolazioni cambiano, le tecniche di re-identificazione migliorano e un rilascio che era sicuro cinque anni fa può non esserlo oggi rispetto a dati che sono nel frattempo diventati nuovamente disponibili altrove.
  12. Separate la decisione di condividere o pubblicare i dati dal gruppo tecnico che li sposta. Le persone meglio collocate per giudicare scopo, proporzionalità e rischio per la riservatezza sono raramente le stesse meglio collocate per costruire la filiera, e fondere i due ruoli in uno lascia il giudizio più difficile sotto-esaminato.

Domande da discutere con il vostro team

Sappiamo quale sistema detenga il registro autorevole per ciascuna delle nostre entità di dati centrali, e tutti lo trattano davvero così? Molte organizzazioni hanno, in pratica, diverse copie "vere" della stessa informazione – l'indirizzo di un cittadino nel sistema di fatturazione, nel sistema di gestione dei casi e nel registro della corrispondenza, tutti leggermente diversi e tutti usati da qualcuno per agire. Usate questa domanda per elencare le entità centrali della vostra organizzazione (cittadino, pratica, immobile, impresa) e individuare, onestamente, se per ciascuna esista un'unica fonte autorevole o se il personale abbia silenziosamente imparato di quale sistema fidarsi per quale scopo. Discutete che cosa servirebbe per designare e far rispettare una fonte autorevole per entità e che cosa si romperebbe nella transizione. Di solito è più economico da correggere presto che dopo che una decisione seria è stata presa sulla copia sbagliata.

Se una persona ci chiedesse perché ha dovuto dare le stesse informazioni a due parti della nostra stessa organizzazione, quale sarebbe la nostra risposta onesta? La risposta onesta è spesso "perché i nostri sistemi non possono scambiarsele", il che è un fallimento di interoperabilità travestito da requisito di processo. Usate questa domanda per scegliere un percorso di servizio che attraversa più di un gruppo o sistema e ripercorrere, passo dopo passo, dove lo stesso fatto sia acquisito più di una volta. Discutete se la richiesta ripetuta stia proteggendo qualcosa di genuino – un consenso rinnovato, un passaggio di verifica – o se sia semplicemente l'assenza di un accordo di condivisione dei dati o di uno schema comune. Considerate quanto costerebbe, in fiducia dei cittadini oltre che in tempo del personale, lasciarlo non corretto per un altro anno.

Dove un giornalista o ricercatore determinato potrebbe più plausibilmente re-identificare qualcuno in un insieme di dati che oggi chiamiamo anonimizzato? La maggior parte delle organizzazioni che pubblicano dati de-identificati non li ha messi alla prova rispetto a una realistica combinazione di quasi-identificatori e altri insiemi di dati pubblici. Usate questa domanda per scegliere il vostro insieme di dati pubblicato (o di prossima pubblicazione) a più alto rischio e ripercorrere quali altre informazioni – un articolo di cronaca locale, l'insieme di dati aperti di un'altra agenzia, un registro pubblico – potrebbero plausibilmente essere collegate ad esso. Discutete se il vostro attuale approccio di de-identificazione (soppressione, generalizzazione o una tecnica formale come k-anonimità o privacy differenziale) reggerebbe davvero a quella combinazione e chi sia responsabile di riverificarlo man mano che nuovi dati esterni diventano disponibili.

Chi ha attualmente l'autorità di dire che un insieme di dati non debba essere pubblicato, e siamo sicuri che quell'autorità sia usata per le ragioni giuste? Una politica di apertura per impostazione predefinita ha comunque bisogno di un processo di eccezione credibile e ben motivato, e la persona che lo esercita dovrebbe essere identificabile e responsabile. Usate questa domanda per verificare se le decisioni di trattenimento nella vostra organizzazione siano prese da un ruolo nominato rispetto a criteri documentati, o informalmente, da chiunque venga interpellato e che pecchi per eccesso di cautela. Discutete se il vostro tasso di trattenimento somigli più a un attento giudizio caso per caso o a un riflesso istituzionale permanente e che cosa potrebbe rivelare un periodico riesame esterno degli insiemi di dati trattenuti.

I nostri accordi di condivisione dei dati fra agenzie sono ancora usati per lo scopo per cui furono scritti? La limitazione dello scopo è facile da dichiarare in un accordo e facile da erodere silenziosamente in pratica, specialmente una volta che un insieme di dati si rivela utile per qualcosa che i suoi firmatari originari non avevano previsto. Usate questa domanda per scegliere due o tre assetti vivi di condivisione dei dati fra agenzie e verificare l'uso effettivo corrente rispetto allo scopo scritto e alla data di scadenza. Discutete quale passaggio di governance manchi se emerge un disallineamento e chi debba essere responsabile di cogliere quel tipo di deriva prima di un audit esterno o di un giornalista.

Se i nostri standard di interoperabilità o di dati diventassero una barriera a un nuovo uso legittimo dei nostri dati, lo scopriremmo prima o dopo che abbia causato danno reale? Gli standard che erano sensati quando adottati possono ossificarsi in ostacoli man mano che bisogni e tecnologia cambiano, e le organizzazioni costruiscono raramente un meccanismo per notare che ciò accade alle proprie regole. Usate questa domanda per discutere come la vostra organizzazione riesamini attualmente se i propri standard di dati, schemi di identificatori o processi di condivisione servano ancora al loro scopo, a differenza dall'essere semplicemente ereditati e non messi in discussione. Considerate se le persone che noterebbero che uno standard è diventato un ostacolo – personale di prima linea, organizzazioni partner, sviluppatori esterni che usano i vostri dati aperti – abbiano un canale reale per segnalarlo e se quel canale abbia mai effettivamente cambiato uno standard.

In pratica: un esempio di valore pubblico

Un'agenzia regionale di assistenza sociale e un'autorità sanitaria regionale distinta – immaginarie, illustrative di uno schema anziché un resoconto su enti reali – avevano trascorso un decennio a gestire sistemi incompatibili di gestione dei casi, così una famiglia nota a entrambe poteva essere registrata sotto numeri di riferimento diversi, senza un modo affidabile di dire al personale delle agenzie che il nucleo familiare che compariva in un carico di sostegno abitativo era lo stesso che compariva in un carico di assistenza pediatrica di prossimità. Un programma congiunto per individuare i bambini a rischio di cadere nel vuoto fra i due servizi si arenò ripetutamente, non per mancanza di volontà politica, ma perché nessuno poteva produrre una vista combinata unica e affidabile di quali famiglie avessero bisogno di entrambi i tipi di sostegno.

Le due agenzie adottarono infine un identificatore condiviso del nucleo familiare e uno schema comune per i campi che entrambi i sistemi dovevano scambiare, costruito attraverso un'API governata anziché le periodiche esportazioni di fogli di calcolo su cui ciascuna aveva fatto affidamento in precedenza, sotto un accordo di condivisione dei dati che nominava lo scopo specifico – coordinare il sostegno ai nuclei familiari a rischio – e richiedeva un riesame annuale. Entro un anno, gli assistenti di entrambe le parti potevano vedere, per la prima volta, quali famiglie fossero note all'altro servizio, e le conferenze congiunte sui casi che prima si basavano su controlli incrociati manuali divennero routine. Le agenzie andarono poi oltre, pubblicando un insieme di dati aperti aggregato, a livello di area, che mostrava il numero di nuclei familiari che ricevevano sostegno combinato per distretto, destinato ad aiutare gli enti benefici locali a mirare la propria azione di prossimità e a permettere ai consiglieri eletti di vedere se il programma congiunto stesse raggiungendo le aree per cui era stato progettato.

Un sostenitore locale dei diritti sui dati, lavorando con un ricercatore universitario, scoprì che le cifre pubblicate a livello di distretto potevano essere incrociate con un insieme di dati aperti pubblicato separatamente, altrettanto ben intenzionato, dell'autorità locale dei trasporti – che mostrava le domande di tariffe agevolate per piccola area – per restringere alcuni distretti a conteggi di nuclei familiari abbastanza piccoli da rendere plausibilmente identificabili famiglie specifiche, in particolare nei distretti rurali poco popolati dove entrambi gli insiemi di dati contavano numeri a una cifra di nuclei familiari. Nessuno dei due insiemi di dati da solo era rivelatore; combinati, nelle aree meno popolate, lo erano. Il primo istinto delle agenzie, ritirare del tutto l'insieme di dati aperti, avrebbe distrutto il valore di responsabilità e di mira degli enti benefici che aveva già cominciato a dare. Lavorando invece con lo stesso sostenitore, lo ripubblicarono usando un approccio di privacy differenziale che aggiungeva rumore calibrato ai piccoli conteggi, preservandone l'utilità per individuare schemi regionali ampi e rendendo il vero conteggio di qualsiasi singolo distretto a bassa popolazione abbastanza incerto da sconfiggere l'attacco di incrocio che aveva esposto il rilascio originale. L'episodio divenne il caso di studio che le agenzie usarono nella formazione del proprio personale, sul perché la de-identificazione debba essere valutata rispetto a ciò che è altrimenti pubblicamente disponibile, non rispetto all'insieme di dati in isolamento.

Quattro prospettive settoriali

Amministrazione locale

Un ente locale gestisce tipicamente più sistemi distinti, più vecchi e meno integrati per residente servito di un organo nazionale, perché decenni di sistemi dipartimentali acquistati individualmente – abitazione, pianificazione, rifiuti, assistenza sociale – sono stati raramente costruiti per condividere dati fra loro. Ciò rende l'interoperabilità una battaglia genuinamente interna prima di essere mai esterna: un residente che interagisce con tre uffici comunali in una settimana può scoprire che nessuno di essi vede ciò che gli altri già sanno. I dati aperti locali, intanto, tendono ad avere un valore civico insolitamente diretto – orari di raccolta dei rifiuti, domande urbanistiche, spesa locale – perché residenti e giornalisti locali vi si impegnano a un livello di specificità che gli insiemi di dati nazionali offrono raramente, il che alza la posta sul fare bene metadati e frequenza di aggiornamento anche per insiemi di dati modesti e quotidiani.

Amministrazione nazionale

I governi nazionali gestiscono tipicamente la gamma più completa di strumenti di governance dei dati e interoperabilità – una strategia nazionale dei dati, schemi di identificatori fra amministrazioni, portali di dati aperti obbligatori e autorità dedicate alla protezione dei dati – ma il numero enorme di sistemi ereditati accumulati in decenni e amministrazioni rende l'interoperabilità tecnica un compito di fondo persistente e costoso anziché un progetto una tantum. I programmi nazionali di dati aperti portano un rischio sproporzionato di re-identificazione proprio perché gli insiemi di dati nazionali sono abbastanza grandi da essere genuinamente preziosi e abbastanza dettagliati, una volta collegati ad altri registri nazionali, da identificare individui; i documenti di strategia nazionale dei dati che diversi governi pubblicano nominano sempre più esplicitamente tecniche di divulgazione che preservano la riservatezza, anziché trattare la de-identificazione come un dettaglio attuativo sotto l'avviso di politica.

Terzo settore e non profit

Un'organizzazione non profit o non governativa (ONG) è raramente soggetta a un obbligo di dati aperti, ma affronta sempre più un'aspettativa parallela da parte di finanziatori, regolatori e pubblico che i dati dei programmi siano condivisi con trasparenza, e lavora spesso con popolazioni – sopravvissuti a violenza, persone in povertà acuta, residenti privi di documenti – per le quali il rischio di re-identificazione comporta un costo personale molto più alto di quanto tipicamente comporti per la popolazione generale in un insieme di dati governativo. Gli accordi di condivisione dei dati contano in modo sproporzionato qui perché una non profit condivide spesso i dati dei clienti con finanziatori governativi o organizzazioni partner sotto contratti che non ha scritto e ha bisogno della capacità di negoziare la limitazione dello scopo anziché accettare semplicemente qualsiasi termine di condivisione dei dati sia allegato al finanziamento. Gli standard di interoperabilità adottati da più grandi finanziatori governativi o filantropici possono essere un onere genuino per la limitata capacità tecnica di una piccola organizzazione, un costo reale che vale la pena nominare anziché trattare l'adozione degli standard come priva di costo.

Livello multilaterale e internazionale

Gli organismi multilaterali aggregano dati fra Stati membri con maturità di governance, capacità statistica e regimi giuridici di riservatezza enormemente diversi, il che rende l'interoperabilità semantica – concordare che cosa un campo condiviso significhi davvero – un problema persistente tanto diplomatico quanto tecnico; un termine basilare come "nucleo familiare" o "disoccupato" è definito in modo abbastanza diverso fra paesi che gli organismi statistici internazionali mantengono interi standard, come il formato Statistical Data and Metadata Exchange (SDMX), al solo scopo di rendere i dati fra paesi genuinamente comparabili. I dati aperti a questo livello funzionano come bene pubblico particolarmente chiaro nel senso esposto nell'Argomento 1.4 — Beni pubblici, beni meritori e pluralismo dei valori, perché nessun singolo Stato membro ha un incentivo a finanziare da solo un insieme di dati comparativo globale, eppure ogni Stato e ricercatore ne beneficia una volta che un organismo multilaterale ne pubblica uno. Le preoccupazioni di sovranità sui dati sono più profonde qui che in un contesto di singolo paese: uno Stato membro può resistere a condividere dati che ha il diritto di trattenere, o può contestare come un organismo multilaterale abbia classificato o aggregato le sue stesse cifre nazionali, il che rende la questione di governance di chi controlli una statistica condivisa tanto consequenziale quanto la questione tecnica di come venga scambiata.

Modalità di fallimento comuni

Silos di dati silenziosi. I sistemi si accumulano indipendentemente in un'organizzazione senza identificatore o schema condiviso, e il costo resta nascosto finché un caso specifico – un fallimento nella tutela, un audit, un'interruzione di servizio – richiede una vista combinata che si rivela impossibile da produrre rapidamente, momento in cui il costo del silo diventa visibile tutto insieme e costoso da correggere sotto pressione.

Teatro dell'anonimizzazione. Un insieme di dati ha nomi e identificatori ovvi rimossi ed è poi trattato come sicuro da pubblicare senza alcuna valutazione dei quasi-identificatori o del rischio di collegamento con altri dati disponibili. Il costo emerge, spesso pubblicamente e in modo imbarazzante, quando un ricercatore, un giornalista o un sostenitore dimostra che la re-identificazione è possibile, momento in cui la credibilità dell'organizzazione sulla riservatezza è danneggiata ben oltre lo specifico insieme di dati coinvolto.

Governance senza un responsabile. La politica di governance dei dati esiste sulla carta, ma nessuna persona specifica è responsabile della qualità o dell'aggiornamento di alcun insieme di dati specifico, così gli standard decadono silenziosamente e nessuno se ne accorge finché i dati non vengono usati per una decisione che non possono effettivamente sostenere. È un fallimento particolarmente comune perché il documento di politica stesso appare completo, mascherando l'assenza di chiunque sia effettivamente responsabile sotto di esso.

Interoperabilità per mandato, senza risorse. Uno schema condiviso o uno schema di identificatori è imposto a livello centrale ma mai finanziato per i gruppi che devono adottarlo, così la conformità diventa un esercizio di spunta – un campo tecnicamente presente ma non correttamente popolato – anziché genuina interoperabilità utilizzabile. Il costo è un falso senso che esista uno standard condiviso, scoperto solo quando qualcuno prova effettivamente a fare affidamento sui dati che doveva standardizzare.

Open-washing. Un'organizzazione pubblica cruscotti e visualizzazioni di sintesi e li chiama dati aperti, mentre l'insieme di dati sottostante leggibile da macchina di cui una terza parte avrebbe bisogno per costruire qualcosa di nuovo resta non pubblicato o pubblicato in un formato che nessuno può praticamente riutilizzare. Ciò cattura l'apparenza di trasparenza e apertura descritta nell'Argomento 3.4 — Responsabilità, trasparenza e legittimità senza la sua sostanza, ed è spesso scambiato per un genuino programma di dati aperti perché il cruscotto appare impressionante.

Modello di maturità

Sotto-dimensione Avvio Sviluppo Standardizzazione Gestione Orchestrazione
Responsabilità e proprietà dei dati Nessun responsabile nominato per la maggior parte degli insiemi di dati; i problemi di qualità sono scoperti per caso Alcuni insiemi di dati di alto profilo hanno un responsabile informale; la qualità varia molto Ogni insieme di dati centrale ha un responsabile nominato con responsabilità definite La qualità dei dati è misurata rispetto a standard e riferita abitualmente ai responsabili La responsabilità si estende oltre i confini organizzativi; gli insiemi di dati condivisi hanno responsabili congiuntamente responsabili
Standard di interoperabilità Sistemi costruiti indipendentemente, che scambiano dati con esportazione manuale o per nulla Esiste uno schema condiviso per alcuni domini, adottato in modo incoerente Uno schema comune e uno schema di identificatori sono imposti e attuati tramite API governate La performance dell'interoperabilità è monitorata; le lacune innescano correzione e finanziamento Gli standard sono co-sviluppati con organizzazioni partner e altre giurisdizioni e adattati proattivamente
Pubblicazione di dati aperti La pubblicazione è ad hoc, non documentata e dipendente dall'iniziativa individuale Esiste un catalogo di dati ma è incompleto o obsoleto; i metadati sono scarsi Aperto per impostazione predefinita è politica; ogni insieme di dati non pubblicato ha una ragione documentata La pubblicazione è misurata per riutilizzo e impatto; il catalogo è attivamente mantenuto La pubblicazione anticipa la domanda esterna e si coordina con i programmi di dati aperti di altri enti
Divulgazione che preserva la riservatezza De-identificazione significa rimuovere solo gli identificatori ovvi, senza valutazione del rischio Il rischio è valutato informalmente solo per i rilasci di alto profilo Una valutazione definita del rischio di re-identificazione, compreso il rischio di collegamento, si svolge prima di ogni rilascio di dati personali Tecniche formali (k-anonimità, privacy differenziale) sono applicate proporzionatamente e riesaminate periodicamente Il rischio di divulgazione è continuamente rivalutato man mano che nuovi insiemi di dati esterni diventano disponibili e i rilasci passati sono rivisitati

Lista di controllo

  • Individuate il sistema fonte autorevole per ciascuna delle entità di dati centrali della vostra organizzazione.
  • Confermate che ogni insieme di dati che conta in modo sostanziale abbia un responsabile nominato.
  • Verificate se esista già uno schema o standard condiviso per un nuovo progetto di dati prima di progettarne uno su misura.
  • Riesaminate il disegno del vostro identificatore univoco per persistenza e coerenza fra i sistemi che lo usano.
  • Sostituite almeno uno scambio di dati ricorrente, manuale o basato su fogli di calcolo, con un'API governata.
  • Confermate che ogni accordo attivo di condivisione dei dati fra agenzie dichiari scopo, base giuridica e scadenza e corrisponda all'uso effettivo corrente.
  • Eseguite una valutazione del rischio di re-identificazione, compreso il plausibile collegamento con altri insiemi di dati pubblici, prima di pubblicare qualsiasi insieme di dati che riguardi informazioni personali.
  • Applicate una tecnica formale che preserva la riservatezza, come k-anonimità o privacy differenziale, a qualsiasi rilascio che riguardi piccole popolazioni o caratteristiche rare.
  • Confermate che il vostro catalogo di dati aperti includa metadati reali e aggiornati, non solo nomi di file.
  • Riesaminate gli insiemi di dati già pubblicati rispetto ai nuovi dati esterni disponibili per rischi emergenti di re-identificazione.
  • Confermate che le decisioni di trattenimento siano prese da un ruolo nominato e responsabile rispetto a criteri documentati.
  • Ponete al vostro team le sei domande di discussione sopra e registrate dove la risposta onesta differisce da quella ufficiale.

Fonti chiave

  • International Open Data Charter, i suoi sei principi e le sue indicazioni sulla pubblicazione aperta per impostazione predefinita.
  • OCSE, Raccomandazione del Consiglio sul miglioramento dell'accesso e della condivisione dei dati (2021).
  • US National Institute of Standards and Technology, Special Publication 800-226, Guidelines for Evaluating Differential Privacy Guarantees.
  • Materiale dello US Census Bureau sull'evitamento della divulgazione e sulla sua applicazione della privacy differenziale ai dati del censimento decennale.
  • Il lavoro fondativo di Cynthia Dwork che formalizza la privacy differenziale e la più ampia letteratura accademica sul controllo statistico della divulgazione.
  • Il triangolo strategico di Mark H. Moore e la logica dei beni pubblici esposta nell'Argomento 1.4 — Beni pubblici, beni meritori e pluralismo dei valori, come inquadramento su cui questo argomento si fonda.

Riferimenti

  1. Data governance — Wikipedia — https://en.wikipedia.org/wiki/Data_governance
  2. Data steward — Wikipedia — https://en.wikipedia.org/wiki/Data_steward
  3. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
  4. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
  5. Metadata — Wikipedia — https://en.wikipedia.org/wiki/Metadata
  6. Open data — Wikipedia — https://en.wikipedia.org/wiki/Open_data
  7. Data re-identification — Wikipedia — https://en.wikipedia.org/wiki/Data_re-identification
  8. K-anonymity — Wikipedia — https://en.wikipedia.org/wiki/K-anonymity
  9. Differential privacy — Wikipedia — https://en.wikipedia.org/wiki/Differential_privacy
  10. Privacy by design — Wikipedia — https://en.wikipedia.org/wiki/Privacy_by_design
  11. Open Data Charter principles — International Open Data Charter — https://opendatacharter.org/principles/
  12. Recommendation of the Council on Enhancing Access to and Sharing of Data (2021) — OECD Legal Instruments — https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0463
  13. Guidelines for Evaluating Differential Privacy Guarantees, SP 800-226 (Initial Public Draft) — US National Institute of Standards and Technology — https://csrc.nist.gov/pubs/sp/800/226/ipd
  14. Disclosure avoidance and data stewardship — US Census Bureau — https://www.census.gov/about/policies/privacy/statistical_safeguards/disclosure-avoidance.html
  15. Data.gov — US federal open data portal, General Services Administration — https://www.data.gov/