Daten, Interoperabilität, und offene Daten im öffentlichen Sektor

Warum das für den öffentlichen Wert zählt

Jede öffentliche Stelle hält bereits mehr Daten, als sie gut nutzt. Eine Finanzbehörde, ein Krankenhausnetzwerk, eine Verkehrsbehörde, und ein lokales Planungsamt erheben jeweils Information als Nebenprodukt des Betriebs eines Dienstes, und jede entdeckt, üblicherweise zu spät, dass die Aufzeichnung, die sie braucht, um die Frage einer Bürgerin zu beantworten oder einen Streit beizulegen, in einem System sitzt, das niemand sonst in der Organisation abfragen kann. Die Kosten sind nicht abstrakt: eine Bürgerin, die einer Behörde bereits ihre Adresse gesagt hat, sollte sie nicht einer anderen Behörde innerhalb derselben Regierung erneut sagen müssen.

Zwei getrennte Ambitionen sitzen im Titel dieses Themas, und öffentliche Stellen verwechseln sie routinemäßig. Die erste ist Interoperabilität – Daten zuverlässig zwischen Systemen bewegen, die verschiedene Teams und Technologiezeitalter unabhängig gebaut haben, sodass ein Teil der Regierung auf dem handeln kann, was ein anderer Teil bereits weiß. Die zweite ist Offenheit – Daten vollständig außerhalb der Regierung veröffentlichen, sodass Journalistinnen, Forscherinnen, und Bürgerinnen sie für Zwecke nutzen können, die die veröffentlichende Stelle nie antizipierte. Interoperabilität ist meist ein Engineering- und Governance-Problem; Offenheit ist ein öffentlicher Wert für sich, derselben Familie wie die in Thema 1.4 — Öffentliche Güter, meritorische Güter und Wertepluralismus beschriebenen öffentlichen Güter, weil veröffentlichte Daten nicht rivalisierend sind und, einmal freigegeben, schwer jemandem vorzuenthalten, sodass ein Markt allein sie unterversorgen würde.

Beide Ambitionen kollidieren mit einer dritten Tatsache, die dieses Thema als echte, ungelöste Spannung behandelt statt als Problem mit ordentlicher Antwort: Daten, detailliert genug, um nützlich zu sein, sind oft detailliert genug, die Einzelperson zu identifizieren, die sie beschreiben, selbst nachdem Namen und offensichtliche Identifikatoren entfernt wurden. Eine reich veröffentlichende Regierung und eine die Menschen in ihren Aufzeichnungen gut schützende Regierung ziehen in unterschiedliche Richtungen am selben Hebel, und der wachsende Appetit auf Daten zum Trainieren und Evaluieren algorithmischer Systeme (siehe Thema 5.2 — KI und algorithmische Entscheidungsfindung in der Verwaltung) hat die Einsätze erhöht, weil mehr Akteurinnen als je öffentliche Daten genau in der Granularität wollen, die sie am riskantesten macht zu veröffentlichen. Eine Führungskraft, die Governance, Interoperabilität, und Offenheit als ein Problem behandelt, mit Privatsphäre als permanenter Beschränkung, ist besser positioniert, den Wert dieses Themas einzufangen, als eine, die jedes isoliert behandelt.

Kernkonzepte

Daten-Governance ist der Satz von Entscheidungsrechten, Standards, und Rechenschaftspflichten, die bestimmen, wer die Daten einer Organisation erstellen, ändern, darauf zugreifen, und pensionieren darf, und nach welchem Qualitätsstandard sie gehalten werden müssen (siehe data governance). Sie unterscheidet sich von Datenmanagement, der operativen Arbeit, Daten täglich zu bewegen und zu speichern; Governance entscheidet die Regeln, Management setzt sie um. Eine öffentliche Stelle ohne Daten-Governance hat immer noch Daten, aber niemand kann mit Zuversicht sagen, welche Kopie der Aufzeichnung einer Bürgerin die maßgebliche ist, oder wer rechenschaftspflichtig ist, wenn sich diese Aufzeichnung als falsch erweist.

Eine Datenverwalterin ist die benannte Einzelperson oder Rolle, rechenschaftspflichtig für die Qualität, Definition, und angemessene Nutzung eines spezifischen Datensatzes, getrennt vom technischen Personal, das die Systeme betreibt, in denen er lebt (siehe data steward). Verwaltung zählt, weil Datenqualität standardmäßig verfällt: ein Feld, für das niemand rechenschaftspflichtig ist, häuft inkonsistente Einträge, doppelte Aufzeichnungen, und stille Drift zwischen dem, was ein Feld bedeuten soll, und dem, was Personal tatsächlich einträgt, an. Einem Datensatz eine Verwalterin zuzuweisen, verwandelt Datenqualität von einer gelegentlichen Aufräumübung in eine laufende, benannte Verantwortung.

Interoperabilität ist die Fähigkeit unabhängig gebauter Systeme, Daten auszutauschen und korrekt zu nutzen, ohne Sonderfall-Engineering für jedes beteiligte Systempaar (siehe interoperability). Sie operiert auf drei leicht zu vermengenden Ebenen: technische Interoperabilität (können die Systeme sich überhaupt verbinden und Bytes bewegen, typischerweise durch eine Programmierschnittstelle, oder API, eine definierte Weise für ein Softwareteil, Daten oder Handlung von einem anderen anzufordern – siehe application programming interface); semantische Interoperabilität (meinen beide Systeme dasselbe mit einem geteilten Feld, wie „Haushalt" oder „aktiver Fall"); und organisatorische Interoperabilität (stimmen die zwei Organisationen überein, warum die Daten geteilt werden und wer wofür rechenschaftspflichtig ist, danach). Die meisten kostspieligen Interoperabilitätsversagen geschehen auf semantischer oder organisatorischer Ebene, selbst wenn die technische Verbindung perfekt funktioniert.

Ein gemeinsames Schema, oder Datenstandard, ist eine vereinbarte, veröffentlichte Struktur dafür, wie eine Datenkategorie repräsentiert wird – Feldnamen, Formate, Einheiten, und erlaubte Werte –, von mehr als einem System oder einer Organisation übernommen, sodass von einem produzierte Daten von einem anderen ohne manuelle Übersetzung konsumiert werden können. Regierungsstellen, die ein geteiltes Schema für etwas so Grundlegendes wie eine Adresse oder einen Fallstatus übernehmen, verwandeln Dutzende potenzieller bilateraler Übersetzungsprobleme in einen Standard, den jedes neue System einfach implementieren kann. Eine eindeutige Kennung, die über Systeme und Zeit hinweg persistiert – eine Fallnummer, eine Gewerberegisternummer, eine Bürgerinnenreferenz –, ist der spezifische Mechanismus, der erlaubt, Aufzeichnungen über dieselbe Person oder Entität korrekt zu verknüpfen, und Kennungsgestaltung falsch zu machen (Nummern wiederzuverwenden, Formate zu ändern, oder überhaupt keine zu haben) ist eine der häufigsten, vermeidbaren Ursachen für Interoperabilitätsversagen.

Metadaten sind Daten über Daten – die Beschreibung der Struktur, Herkunft, Aktualisierungsfrequenz, und Bedeutung eines Datensatzes, neben den Daten selbst veröffentlicht, sodass eine Nutzerin, die sie nicht erstellt hat, sie verstehen und ihnen vertrauen kann (siehe metadata). Ein ohne angemessene Metadaten veröffentlichter Datensatz ist für jeden außerhalb des ihn produzierenden Teams kaum nutzbar, wie offen seine Lizenz auch sei; Metadaten sind, was einen Datei-Dump in etwas verwandelt, das eine dritte Partei tatsächlich wiederverwenden kann.

Eine Datenaustauschvereinbarung ist eine formale Vereinbarung zwischen Behörden, oder zwischen einer öffentlichen Stelle und einer externen Partnerin, die den Zweck spezifiziert, für den Daten genutzt werden dürfen, die rechtliche Grundlage für ihren Austausch, wie lange sie aufbewahrt werden dürfen, und was geschieht, falls sich der Zweck ändert. Zweckbindung – die Nutzung geteilter Daten auf den Zweck zu beschränken, für den sie erhoben oder geteilt wurden – ist die Disziplin, die eine Datenaustauschvereinbarung davon abhält, zu einer unbegrenzten Lizenz zu werden, persönliche Information umzuwidmen, und ihre Abwesenheit ist ein wiederkehrendes Thema bei öffentlichen Vertrauensversagen mit behördenübergreifenden Daten.

Offene Daten sind Daten, die frei für jeden zugänglich gemacht werden, nutzbar und weiterverteilbar für jeden Zweck, typischerweise maschinenlesbar und unter einer Lizenz veröffentlicht, die Wiederverwendung erlaubt statt bloß Ansicht (siehe open data). Ihr öffentliche-Wert-Fall folgt der in Thema 1.4 — Öffentliche Güter, meritorische Güter und Wertepluralismus dargelegten öffentliche-Güter-Logik: sobald ein Datensatz veröffentlicht ist, mindert die Nutzung einer Person die einer anderen nicht, und die Regierung ist oft die einzige Akteurin mit sowohl dem rechtlichen Stand als auch dem Maßstab, ihn überhaupt zu erheben und zu veröffentlichen, sodass private Märkte allein diese Art Information chronisch unterversorgen. Offene Daten ermöglichen Rechenschaftspflicht (Journalistinnen und Bürgerinnen, die die eigenen Behauptungen der Regierung gegen ihre eigenen Aufzeichnungen prüfen), Drittinnovation (Unternehmen und zivilgesellschaftliche Technologinnen, die Dienste auf öffentlichen Daten bauen, die die Regierung selbst nie bauen wird), und bessere öffentliche Entscheidungen andernorts in der Wirtschaft, alles ohne dass die veröffentlichende Stelle jede Nutzung im Voraus antizipieren muss.

Re-Identifikation ist der Prozess, angeblich anonymisierte Daten gegen andere verfügbare Information abzugleichen, um herauszufinden, welche reale Person eine Aufzeichnung beschreibt, und sie ist die zentrale technische Tatsache, die die Privatsphärenspannung dieses Themas unvermeidlich statt bloß unbequem macht (siehe data re-identification). Einen Namen oder einen offensichtlichen Identifikator wie eine Sozialversicherungsnummer zu entfernen, entfernt das Risiko nicht: eine Kombination aus Quasi-Identifikatoren wie Alter, Postleitzahl, und einer seltenen medizinischen Erkrankung kann jemanden eindeutig identifizieren, selbst in einem Datensatz, der sie nie benannte, besonders sobald er gegen einen anderen, getrennt öffentlichen Datensatz kreuzreferenziert wird. K-Anonymität ist eine formale Weise, über dieses Risiko nachzudenken: ein Datensatz erfüllt K-Anonymität, wenn jede Kombination quasi-identifizierender Felder, die er enthält, von mindestens einer definierten Zahl, k, von Aufzeichnungen geteilt wird, sodass keine einzelne Zeile auf weniger als k mögliche Menschen isoliert werden kann (siehe k-anonymity). Differenzielle Privatsphäre ist ein jüngerer, mathematisch strenger Ansatz, der sorgfältig kalibriertes statistisches Rauschen zu einem Datensatz oder den Ergebnissen von Abfragen dagegen hinzufügt, sodass die Präsenz oder Abwesenheit der Aufzeichnung einer einzelnen Person den veröffentlichten Ausstoß nur um einen begrenzten, beweisbaren Betrag ändert, unabhängig davon, was eine Angreiferin bereits weiß (siehe differential privacy). Privacy by Design ist das breitere Prinzip, dass Privatsphärenschutz von Anfang an in die Architektur eines Systems eingebaut werden sollte, als Standardeinstellung, statt als Schwärzungsschritt kurz vor Veröffentlichung angeschraubt zu werden (siehe privacy by design); offensichtliche Identifikatoren nachträglich zu schwärzen, ist die schwächste Form dieser Disziplin, kein Ersatz dafür.

Bewährte Praktiken

1. Benennen Sie eine rechenschaftspflichtige Verwalterin für jeden wichtigen Datensatz, nicht nur ein zentrales Datenbüro. Ein Datenbüro kann Standards setzen, aber es kann nicht wissen, ob ein spezifisches Feld in einem spezifischen System noch bedeutet, was es definiert wurde zu bedeuten; dieses Urteil gehört jemandem, der der tatsächlichen Nutzung der Daten nahe ist.
2. Veröffentlichen Sie standardmäßig offen, und dokumentieren Sie den spezifischen Grund, wann immer Sie es nicht tun. Den Standard umzukehren – eine Rechtfertigung für Zurückhaltung statt für Veröffentlichung zu verlangen – bringt echte Sensibilitäten für individuelle Überprüfung zutage, statt Vorsicht wahllos auf alles anzuwenden.
3. Übernehmen Sie ein bestehendes, geteiltes Schema, bevor Sie ein neues gestalten. Eine maßgeschneiderte Datenstruktur, die perfekt zu einem Projekt passt und zu nichts sonst in der Regierung passt, garantiert zukünftige Integrationskosten; prüfen Sie, was Ihr Sektor, Rechtsraum, oder eine internationale Standardisierungsstelle bereits veröffentlicht hat, bevor Sie Ihre eigene bauen.
4. Gestalten Sie persistente, gut regierte eindeutige Kennungen, bevor ein System live geht, nicht danach. Ein Kennungsschema auf über Jahre unter inkonsistenten Schlüsseln angehäufte Aufzeichnungen nachzurüsten, ist dramatisch teurer, als die Gestaltung von Anfang an richtig zu machen.
5. Bauen Sie Datenaustausch durch regierte APIs statt einmaliger Dateiübertragungen. Eine API, die ein Schema durchsetzt, Zugriff protokolliert, und versioniert werden kann, gibt Ihnen einen kontrollierbaren, prüfbaren Interoperabilitätspunkt; eine zwischen Ressorts gemailte Tabelle gibt Ihnen nichts davon, und niemand bemerkt, wenn sie veraltet.
6. Schreiben Sie Datenaustauschvereinbarungen, die den Zweck, die rechtliche Grundlage, und das Ablaufdatum angeben, nicht nur den technischen Mechanismus. Eine Vereinbarung, die spezifiziert, wie Daten sich bewegen, aber nicht warum oder für wie lange, überlebt tendenziell den Zweck, der sie rechtfertigte, und wird still zur Erlaubnis für etwas, das niemand explizit autorisierte.
7. Behandeln Sie Entidentifizierung als Risikobewertung mit Restergebnis, nicht als einmalige Schwärzungsaufgabe. Fragen Sie, welche anderen öffentlichen oder käuflichen Datensätze mit dem verknüpft werden könnten, den Sie gerade freigeben, und bemessen Sie das Re-Identifikationsrisiko gegen dieses realistische Bedrohungsmodell, nicht gegen eine idealisierte Angreiferin ohne externe Information.
8. Wenden Sie differenzielle Privatsphäre oder eine gleichwertige formale Technik auf jede Freigabe an, die kleine Bevölkerungen oder seltene Merkmale betrifft. Einfache Unterdrückung oder Generalisierung offensichtlicher Identifikatoren ist unzureichend, sobald ein Datensatz irgendetwas Ungewöhnliches genug enthält, um selbst identifizierend zu sein, wie eine seltene Erkrankung, eine kleine lokale Bevölkerung, oder eine hochwertige Transaktion.
9. Pflegen Sie einen öffentlichen, aktuellen Datenkatalog mit echten Metadaten, nicht nur eine Liste von Dateinamen. Ein Datensatz, den eine potenzielle Nutzerin nicht gut genug verstehen kann, um ihm zu vertrauen, ist funktional unveröffentlicht, wie freizügig seine Lizenz auch sei; Katalogeinträge sollten sagen, was ein Feld bedeutet, wie oft es sich aktualisiert, und was seine bekannten Grenzen sind.
10. Messen Sie Datenqualität auf wiederkehrendem Zeitplan gegen definierte Standards, und berichten Sie die Ergebnisse an wer auch immer den Datensatz besitzt. Nur bei Problemen geprüfte Qualität verfällt unsichtbar über lange Strecken dazwischen; eine routinemäßige Messung verwandelt Verfall in einen sichtbaren, handhabbaren Trend.
11. Überprüfen Sie jeden veröffentlichten Datensatz periodisch auf fortgesetzten öffentlichen Wert und fortgesetztes Risiko. Bevölkerungen ändern sich, Re-Identifikationstechniken verbessern sich, und eine vor fünf Jahren sichere Freigabe mag heute gegen seither andernorts neu verfügbar gewordene Daten nicht sicher sein.
12. Trennen Sie die Entscheidung, Daten zu teilen oder zu veröffentlichen, vom technischen Team, das sie bewegt. Die am besten positionierten Menschen, Zweck, Verhältnismäßigkeit, und Privatsphärenrisiko zu beurteilen, sind selten dieselben, die am besten positioniert sind, die Pipeline zu bauen, und die zwei Rollen zu einer zu verschmelzen, lässt das schwerere Urteil unterexaminiert.

Fragen zur Diskussion mit Ihrem Team

Wissen wir, welches System die maßgebliche Aufzeichnung für jede unserer Kern-Datenentitäten hält, und behandelt jeder sie tatsächlich so? Viele Organisationen haben in der Praxis mehrere „wahre" Kopien derselben Information – die Adresse einer Bürgerin im Abrechnungssystem, im Fallmanagementsystem, und im Korrespondenzprotokoll, alle leicht unterschiedlich und alle, auf die jemand handelt. Nutzen Sie diese Frage, um die Kernentitäten Ihrer Organisation (Bürgerin, Fall, Eigentum, Unternehmen) aufzulisten und ehrlich zu identifizieren, ob eine einzelne maßgebliche Quelle für jede existiert, oder ob Personal still gelernt hat, welchem System für welchen Zweck zu vertrauen ist. Diskutieren Sie, was es bräuchte, eine maßgebliche Quelle pro Entität zu bezeichnen und durchzusetzen, und was im Übergang brechen würde. Dies ist üblicherweise billiger, früh zu beheben, als nachdem eine ernste Entscheidung auf der falschen Kopie getroffen wurde.

Wenn uns eine Person fragte, warum sie dieselbe Information an zwei Teile unserer eigenen Organisation geben musste, was wäre unsere ehrliche Antwort? Die ehrliche Antwort ist oft „weil unsere Systeme sie nicht austauschen können", was ein als Prozessanforderung verkleidetes Interoperabilitätsversagen ist. Nutzen Sie diese Frage, um eine Dienstreise zu wählen, die mehr als ein Team oder System umspannt, und Schritt für Schritt zu verfolgen, wo dieselbe Tatsache mehr als einmal erfasst wird. Diskutieren Sie, ob die wiederholte Anfrage etwas Echtes schützt – eine frische Zustimmung, einen Verifikationsschritt – oder ob sie einfach die Abwesenheit einer Datenaustauschvereinbarung oder eines gemeinsamen Schemas ist. Erwägen Sie, was es kosten würde, an Bürgervertrauen ebenso wie an Personalzeit, es für ein weiteres Jahr unbehoben zu lassen.

Wo würde eine entschlossene Journalistin oder Forscherin am plausibelsten jemanden in einem von uns derzeit als anonymisiert bezeichneten Datensatz re-identifizieren? Die meisten Organisationen, die entidentifizierte Daten veröffentlichen, haben sie nicht gegen eine realistische Kombination aus Quasi-Identifikatoren und anderen öffentlichen Datensätzen stresstestet. Nutzen Sie diese Frage, um Ihren höchstriskanten veröffentlichten oder bald zu veröffentlichenden Datensatz zu wählen und durchzugehen, welche andere Information – ein lokaler Nachrichtenbericht, ein offener Datensatz einer anderen Behörde, ein öffentliches Register – plausibel dagegen verknüpft werden könnte. Diskutieren Sie, ob Ihr aktueller Entidentifizierungsansatz (Unterdrückung, Generalisierung, oder eine formale Technik wie K-Anonymität oder differenzielle Privatsphäre) dieser Kombination tatsächlich standhalten würde, und wer dafür verantwortlich ist, sie erneut zu testen, während neue externe Daten verfügbar werden.

Wer hat derzeit die Autorität zu sagen, ein Datensatz sollte nicht veröffentlicht werden, und sind wir zuversichtlich, dass diese Autorität aus den richtigen Gründen genutzt wird? Eine Standardmäßig-offen-Politik braucht immer noch einen glaubwürdigen, gut begründeten Ausnahmeprozess, und die sie ausübende Person sollte identifizierbar und rechenschaftspflichtig sein. Nutzen Sie diese Frage, um zu prüfen, ob Zurückhaltungsentscheidungen in Ihrer Organisation von einer benannten Rolle gegen dokumentierte Kriterien getroffen werden, oder informell, von wer auch immer gerade gefragt wird und auf der Seite der Vorsicht irrt. Diskutieren Sie, ob Ihre Zurückhaltungsrate eher wie sorgfältiges Fallurteil oder ein stehender institutioneller Reflex aussieht, und was eine periodische externe Überprüfung zurückgehaltener Datensätze offenbaren könnte.

Werden unsere Datenaustauschvereinbarungen zwischen Behörden noch für den Zweck genutzt, für den sie geschrieben wurden? Zweckbindung ist leicht in einer Vereinbarung anzugeben und leicht, in der Praxis still zu erodieren, besonders sobald sich ein Datensatz für etwas nützlich erweist, das seine ursprünglichen Unterzeichnerinnen nie antizipierten. Nutzen Sie diese Frage, um zwei oder drei laufende behördenübergreifende Datenaustauschvereinbarungen zu wählen und die tatsächliche aktuelle Nutzung gegen den geschriebenen Zweck und das Ablaufdatum zu prüfen. Diskutieren Sie, welcher Governance-Schritt fehlt, falls eine Fehlpassung auftaucht, und wer rechenschaftspflichtig sein sollte, diese Art von Drift zu fangen, bevor eine externe Prüfung oder eine Journalistin es tut.

Wenn unsere Interoperabilitäts- oder Datenstandards eine Barriere für eine legitime neue Nutzung unserer Daten würden, würden wir es vor oder nach echtem Schaden herausfinden? Bei Übernahme vernünftige Standards können zu Hindernissen erstarren, während sich Bedürfnisse und Technologie ändern, und Organisationen bauen selten einen Mechanismus ein, um zu bemerken, dass dies mit ihren eigenen Regeln geschieht. Nutzen Sie diese Frage, um zu diskutieren, wie Ihre Organisation derzeit überprüft, ob ihre Datenstandards, Kennungsschemata, oder Austauschprozesse noch ihrem Zweck dienen, gegenüber einfach geerbt und unhinterfragt. Erwägen Sie, ob die Menschen, die bemerken würden, dass ein Standard zum Hindernis geworden ist – Frontlinienpersonal, Partnerorganisationen, externe Entwicklerinnen, die Ihre offenen Daten nutzen –, einen echten Kanal haben, es zu erheben, und ob dieser Kanal je tatsächlich einen Standard geändert hat.

In der Praxis: ein Beispiel für öffentlichen Wert

Eine regionale Sozialfürsorgebehörde und eine getrennte regionale Gesundheitsbehörde – fiktiv, illustrativ für ein Muster statt ein Bericht über eine reale Stelle – hatten ein Jahrzehnt damit verbracht, inkompatible Fallmanagementsysteme zu betreiben, sodass eine beiden bekannte Familie unter unterschiedlichen Referenznummern erfasst werden konnte, ohne zuverlässige Weise, Behördenpersonal mitzuteilen, dass der in einer Wohnungshilfe-Fallzahl erscheinende Haushalt derselbe Haushalt war, der in einer pädiatrischen Outreach-Fallzahl erschien. Ein gemeinsames Programm, Kinder mit Risiko zu identifizieren, durch die Lücke zwischen den beiden Diensten zu fallen, stockte wiederholt, nicht aus Mangel an politischem Willen, sondern weil niemand eine einzelne, vertrauenswürdige kombinierte Ansicht produzieren konnte, welche Familien beide Arten von Unterstützung brauchten.

Die zwei Behörden übernahmen schließlich eine geteilte Haushaltskennung und ein gemeinsames Schema für die von beiden Systemen auszutauschenden Felder, gebaut durch eine regierte API statt der periodischen Tabellenexporte, auf die sich jede zuvor verlassen hatte, unter einer Datenaustauschvereinbarung, die den spezifischen Zweck benannte – Unterstützung für gefährdete Haushalte zu koordinieren – und jährliche Überprüfung verlangte. Innerhalb eines Jahres konnten Sachbearbeiterinnen auf beiden Seiten zum ersten Mal sehen, welche Familien dem anderen Dienst bekannt waren, und gemeinsame Fallkonferenzen, die zuvor auf manueller Gegenprüfung beruht hatten, wurden Routine. Die Behörden gingen dann weiter und veröffentlichten einen aggregierten, gebietsstufigen offenen Datensatz, der die Zahl der Haushalte zeigte, die kombinierte Unterstützung nach Bezirk erhielten, gedacht, um lokalen Wohltätigkeitsorganisationen zu helfen, ihre eigene Öffentlichkeitsarbeit zu zielen, und gewählten Ratsmitgliedern zu erlauben zu sehen, ob das gemeinsame Programm die Gebiete erreichte, für die es gestaltet war.

Eine lokale Datenrechte-Fürsprecherin, mit einer Universitätsforscherin arbeitend, entdeckte, dass die veröffentlichten bezirksstufigen Zahlen gegen einen getrennt veröffentlichten, ebenso gut gemeinten offenen Datensatz der lokalen Verkehrsbehörde kreuzreferenziert werden konnten – der subventionierte Fahrpreisanträge nach kleinem Gebiet zeigte –, um manche Bezirke auf Haushaltszahlen zu verengen, klein genug, dass spezifische Familien plausibel identifiziert werden konnten, besonders in dünn besiedelten ländlichen Bezirken, wo beide Datensätze einstellige Haushaltszahlen zählten. Keiner der Datensätze allein war offenlegend; kombiniert, in den am wenigsten besiedelten Gebieten, waren sie es. Der erste Instinkt der Behörden, den offenen Datensatz vollständig zurückzuziehen, hätte den Rechenschafts- und Wohltätigkeits-Zielungswert zerstört, den er bereits zu liefern begonnen hatte. Stattdessen, mit derselben Fürsprecherin arbeitend, veröffentlichten sie den Datensatz mit einem differenzielle-Privatsphäre-Ansatz erneut, der kalibriertes Rauschen zu kleinen Zahlen hinzufügte, seine Nützlichkeit für das Erkennen breiter regionaler Muster bewahrend, während er die wahre Zahl jedes einzelnen niedrigbesiedelten Bezirks unsicher genug machte, um den Kreuzreferenzierungsangriff zu vereiteln, der die ursprüngliche Freigabe exponiert hatte. Die Episode wurde die Fallstudie, die die Behörden in ihrer eigenen nachfolgenden Personalausbildung nutzten, dafür, warum Entidentifizierung gegen das bewertet werden muss, was sonst öffentlich verfügbar ist, nicht gegen den Datensatz isoliert.

Vier Sektorperspektiven

Kommunalverwaltung

Eine Kommunalverwaltung betreibt typischerweise mehr getrennte, ältere, und weniger integrierte Systeme pro bedienter Einwohnerin als eine nationale Stelle, weil Jahrzehnte einzeln beschaffter Ressortsysteme – Wohnen, Planung, Abfall, Sozialpflege – selten gebaut wurden, Daten miteinander zu teilen. Dies macht Interoperabilität zu einer genuin internen Schlacht, bevor sie je eine externe ist: eine in einer Woche mit drei Ratsressorts interagierende Einwohnerin mag finden, dass keines sehen kann, was die anderen bereits wissen. Lokale offene Daten haben derweil tendenziell ungewöhnlich direkten bürgerschaftlichen Wert – Mülltonnenabholzeitpläne, Bauanträge, lokale Ausgaben –, weil Einwohnerinnen und lokale Journalistinnen sich mit ihnen auf einem Spezifitätsniveau befassen, das nationale Datensätze selten bieten, was die Einsätze erhöht, Metadaten und Aktualisierungsfrequenz selbst für bescheidene, alltägliche Datensätze richtig zu bekommen.

Nationale Regierung

Nationale Regierungen betreiben typischerweise das vollständigste Spektrum von Daten-Governance- und Interoperabilitätsinstrumenten – eine nationale Datenstrategie, regierungsübergreifende Kennungsschemata, vorgeschriebene Offene-Daten-Portale, und dedizierte Datenschutzregulierungsbehörden –, aber die schiere Zahl über Jahrzehnte und Verwaltungen angehäufter Altsysteme macht technische Interoperabilität zu einer anhaltenden, teuren Hintergrundaufgabe statt einem einmaligen Projekt. Nationale Offene-Daten-Programme tragen unverhältnismäßiges Re-Identifikationsrisiko, genau weil nationale Datensätze groß genug sind, genuin wertvoll zu sein, und detailliert genug, einmal gegen andere nationale Register verknüpft, Einzelpersonen zu identifizieren; die nationale Datenstrategiedokumente, die mehrere Regierungen nun veröffentlichen, benennen zunehmend explizit privatsphärenerhaltende Offenlegungstechniken, statt Entidentifizierung als Implementierungsdetail unterhalb politischer Aufmerksamkeit zu behandeln.

Sozialer Sektor und gemeinnützige Organisationen

Eine gemeinnützige Organisation oder Nichtregierungsorganisation (NGO) unterliegt selten einem Offene-Daten-Mandat, steht aber zunehmend einer parallelen Erwartung von Fördergeberinnen, Regulierungsbehörden, und der Öffentlichkeit gegenüber, dass Programmdaten transparent geteilt werden, und arbeitet oft mit Bevölkerungen – Überlebende von Gewalt, Menschen in akuter Armut, Einwohnerinnen ohne Papiere –, für die Re-Identifikationsrisiko weit höhere persönliche Kosten trägt, als es typischerweise für die allgemeine Bevölkerung in einem Regierungsdatensatz der Fall ist. Datenaustauschvereinbarungen zählen hier unverhältnismäßig, weil eine gemeinnützige Organisation häufig Klientendaten mit Regierungsfördergeberinnen oder Partnerorganisationen unter von ihr nicht geschriebenen Verträgen teilt, und sie die Fähigkeit braucht, Zweckbindung zu verhandeln, statt einfach zu akzeptieren, welche Datenaustauschbedingungen an Finanzierung angehängt sind. Von größeren Regierungs- oder philanthropischen Fördergeberinnen übernommene Interoperabilitätsstandards können eine echte Last für die begrenzte technische Kapazität einer kleinen Organisation sein, was echte, benennenswerte Kosten sind, statt Standardübernahme als kostenlos zu behandeln.

Multilaterale und internationale Organisationen

Multilaterale Stellen aggregieren Daten über Mitgliedstaaten mit weit unterschiedlicher Governance-Reife, statistischer Kapazität, und Rechtsregimen für Privatsphäre hinweg, was semantische Interoperabilität – zu vereinbaren, was ein geteiltes Feld tatsächlich bedeutet – zu einem anhaltenden diplomatischen ebenso wie technischen Problem macht; ein Begriff so grundlegend wie „Haushalt" oder „arbeitslos" wird über Länder hinweg unterschiedlich genug definiert, dass internationale statistische Stellen ganze Standards pflegen, wie das Statistical Data and Metadata Exchange (SDMX)-Format, rein um länderübergreifende Daten genuin vergleichbar zu machen. Offene Daten auf dieser Ebene funktionieren als besonders klares öffentliches Gut im in Thema 1.4 — Öffentliche Güter, meritorische Güter und Wertepluralismus dargelegten Sinne, weil kein einzelner Mitgliedstaat einen Anreiz hat, einen globalen vergleichenden Datensatz allein zu finanzieren, doch jeder Staat und jede Forscherin profitiert, sobald eine multilaterale Stelle einen veröffentlicht. Datensouveränitätsbedenken laufen hier tiefer als im Einlandkontext: ein Mitgliedstaat mag sich weigern, Daten zu teilen, die er rechtlich zurückhalten darf, oder mag bestreiten, wie eine multilaterale Stelle seine eigenen nationalen Zahlen klassifiziert oder aggregiert hat, was die Governance-Frage, wer eine geteilte Statistik kontrolliert, ebenso folgenreich macht wie die technische Frage, wie sie ausgetauscht wird.

Häufige Fehlermuster

Stille Datensilos. Systeme häufen sich unabhängig über eine Organisation hinweg an, ohne geteilte Kennung oder geteiltes Schema, und die Kosten bleiben verborgen, bis ein spezifischer Fall – ein Schutzversagen, eine Prüfung, ein Dienstausfall – eine kombinierte Ansicht erfordert, die sich als unmöglich erweist, schnell zu produzieren, zu welchem Zeitpunkt die Kosten des Silos alle auf einmal sichtbar und teuer zu beheben werden unter Druck.

Anonymisierungstheater. Einem Datensatz werden Namen und offensichtliche Identifikatoren entfernt und er wird dann ohne jede Bewertung von Quasi-Identifikatoren oder Verknüpfungsrisiko gegen andere verfügbare Daten als sicher zur Veröffentlichung behandelt. Die Kosten treten zutage, oft öffentlich und peinlich, wenn eine Forscherin, Journalistin, oder Fürsprecherin demonstriert, dass Re-Identifikation möglich ist, zu welchem Zeitpunkt die Glaubwürdigkeit der Organisation zu Privatsphäre weit über den spezifischen betroffenen Datensatz hinaus beschädigt ist.

Governance ohne Besitzerin. Daten-Governance-Politik existiert auf dem Papier, aber niemand Spezifisches ist für die Qualität oder Aktualität eines spezifischen Datensatzes rechenschaftspflichtig, sodass Standards still verfallen und niemand es bemerkt, bis auf die Daten für eine Entscheidung vertraut wird, die sie tatsächlich nicht stützen können. Dies ist ein besonders häufiges Versagen, weil das Politikdokument selbst vollständig aussieht, die Abwesenheit von irgendjemandem tatsächlich Rechenschaftspflichtigem darunter maskierend.

Interoperabilität per Mandat, ohne Ressourcierung. Ein geteiltes Schema oder Kennungsschema wird zentral vorgeschrieben, aber nie für die Teams finanziert, von denen erwartet wird, es zu übernehmen, sodass Compliance zu einer Checkbox-Übung wird – ein technisch vorhandenes, aber nicht ordentlich befülltes Feld – statt echter, nutzbarer Interoperabilität. Die Kosten sind ein falsches Gefühl, dass ein geteilter Standard existiert, erst entdeckt, wenn jemand tatsächlich versucht, sich auf die Daten zu verlassen, die er standardisieren sollte.

Open-Washing. Eine Organisation veröffentlicht Dashboards und zusammenfassende Visualisierungen und nennt das offene Daten, während der zugrunde liegende maschinenlesbare Datensatz, den eine dritte Partei bräuchte, um etwas Neues zu bauen, unveröffentlicht bleibt oder in einem Format veröffentlicht wird, das niemand praktisch wiederverwenden kann. Dies fängt den Anschein von Transparenz und Offenheit, in Thema 3.4 — Rechenschaftspflicht, Transparenz, und Legitimität beschrieben, ohne ihre Substanz ein, und wird oft mit einem echten Offene-Daten-Programm verwechselt, weil das Dashboard beeindruckend aussieht.

Reifegradmodell

Liste zur Überprüfung

• Identifizieren Sie das maßgebliche Quellsystem für jede Kern-Datenentität Ihrer Organisation.
• Bestätigen Sie, dass jeder materiell wichtige Datensatz eine benannte, rechenschaftspflichtige Verwalterin hat.
• Prüfen Sie, ob für ein neues Datenprojekt bereits ein geteiltes Schema oder ein Standard existiert, bevor Sie ein maßgeschneidertes gestalten.
• Überprüfen Sie Ihre eindeutige-Kennung-Gestaltung auf Persistenz und Konsistenz über die sie nutzenden Systeme hinweg.
• Ersetzen Sie mindestens einen wiederkehrenden manuellen oder tabellenbasierten Datenaustausch durch eine regierte API.
• Bestätigen Sie, dass jede aktive behördenübergreifende Datenaustauschvereinbarung ihren Zweck, ihre rechtliche Grundlage, und ihr Ablaufdatum angibt, und zur aktuellen tatsächlichen Nutzung passt.
• Führen Sie eine Re-Identifikationsrisikobewertung durch, einschließlich plausibler Verknüpfung gegen andere öffentliche Datensätze, bevor Sie einen Datensatz mit persönlicher Information veröffentlichen.
• Wenden Sie eine formale privatsphärenerhaltende Technik, wie K-Anonymität oder differenzielle Privatsphäre, auf jede Freigabe an, die kleine Bevölkerungen oder seltene Merkmale betrifft.
• Bestätigen Sie, dass Ihr Offene-Daten-Katalog echte, aktuelle Metadaten enthält, nicht nur Dateinamen.
• Überprüfen Sie zuvor veröffentlichte Datensätze gegen neu verfügbare externe Daten auf entstehendes Re-Identifikationsrisiko.
• Bestätigen Sie, dass Zurückhaltungsentscheidungen von einer benannten, rechenschaftspflichtigen Rolle gegen dokumentierte Kriterien getroffen werden.
• Stellen Sie Ihrem Team die sechs obigen Diskussionsfragen und notieren Sie, wo die ehrliche Antwort von der offiziellen abweicht.

Hauptquellen

• International Open Data Charter, ihre sechs Prinzipien, und ihre Leitlinien zu Standardmäßig-offen-Veröffentlichung.
• OECD-Empfehlung des Rates zur Verbesserung des Zugangs zu und der Teilung von Daten (2021).
• US National Institute of Standards and Technology, Special Publication 800-226, Guidelines for Evaluating Differential Privacy Guarantees.
• Material des US Census Bureau zu Offenlegungsvermeidung und seiner Anwendung differenzieller Privatsphäre auf die Zehnjahreszählung.
• Cynthia Dworks grundlegende Arbeit zur Formalisierung differenzieller Privatsphäre, und die breitere akademische Literatur zu statistischer Offenlegungskontrolle.
• Mark H. Moores strategisches Dreieck und die in Thema 1.4 — Öffentliche Güter, meritorische Güter und Wertepluralismus dargelegte öffentliche-Güter-Logik, als der Rahmen, auf dem dieses Thema aufbaut.

Referenzen

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/