Die Begrifflichkeit „Privacy by Design“ oder zu Deutsch „Datenschutz durch Technikgestaltung“ ist in der Datenschutzwelt inzwischen zwar geläufig, nicht aber unbedingt im Rahmen von Data Science. Kann eine datenschutzfreundliche Technikgestaltung beim Einsatz von Künstlicher Intelligenz (KI) oder Maschinellem Lernen (MI) überhaupt gelingen? Ein Vorschlag mit dem Hoepman´schen Ansatz.
Der Inhalt im Überblick
Was fordert die DSGVO?
Das Prinzip des Datenschutzes durch Technikgestaltung (Privacy by Design) wurde in Art. 25 DSGVO festgehalten. Ziel dessen ist, dass der Datenschutz bereits in der Planungs- und Designphase berücksichtigt wird, also lange bevor es zur eigentlichen Datenerhebung kommt.
Der Grundsatz gilt nicht uneingeschränkt. Art. 25 Abs. 1 DSGVO sieht (zugunsten des Verantwortlichen) die Möglichkeit vor, bei der Abwägung von Maßnahmen u.a. den Stand der Technik, die Umsetzungskosten und die Eintrittswahrscheinlichkeit von Risiken mit zu berücksichtigen. Wenngleich die Implementierungskosten bei hohen Risiken nicht als Ausrede dienen dürfen.
Wichtig: Dabei richtet sich Art. 25 DSGVO nicht an den Hersteller. Vermutlich, weil ausreichend ökonomische Anreize bestehen, rechtlich zulässige Produkte und Dienstleistungen anzubieten.
Konkretisierung durch Erwägungsgründe
Exemplarisch – aber nicht abschließend – zählt der Erwägungsgrund 78 infrage kommende Maßnahmen auf:
- Datenminimierung,
- Pseudonymisierung zum frühestmöglichen Zeitpunkt,
- Transparenz in Bezug auf die Funktionen und die Verarbeitung personenbezogener Daten,
- eine Möglichkeit zur Überwachung der Verarbeitung personenbezogener Daten durch den Betroffenen bieten,
- Sicherheitsfunktionen zu schaffen und zu verbessern.
Darüber hinaus weist der Erwägungsgrund 78 noch darauf hin, dass der Verantwortliche interne Strategien festlegen und Maßnahmen ergreifen muss.
Konkretere Vorgaben?
Konkretere Vorgaben macht das Gesetz dem Verantwortlichen hier nicht. Es gibt aber auch weder den einzigen und wahrhaftigen Ansatz, mit dem der Grundsatz erreicht werden kann, noch gibt es eine feste Sammlung von Schutzmaßnahmen, die ergriffen werden müssen. Es kommt also immer auf die Besonderheiten der Situation an.
Sprich: Komplexe und risikoreiche Datenverarbeitungen erfordern mehr Datenschutz-Geschick als triviale und risikoarme IT-Systeme. Bei der Ermittlung des „Risikos“ ist nicht auf die Datenverarbeitung an sich abzustellen, sondern auf die negativen Folgen für eine betroffene Person durch die Datenverarbeitung. Führt demnach eine Datenanalyse mittels KI/ML dazu, dass ein Mitarbeiter gekündigt wird, ist nicht primär die Datenverarbeitung zu bewerten, sondern die Folge der Datenverarbeitung.
Wieso ist das wichtig?
Ein Verstoß gegen Art. 25 DSGVO kann gemäß Art. 83 Abs. 4 lit. a DSGVO mit Geldbußen belegt werden. Diese leidige Erfragung durfte auch die Wohnungsgesellschaft Deutsche Wohnen SE 2019 machen. Nach Angaben der Berliner Datenschutzaufsicht hatte die Wohnungsgesellschaft über Jahre hinweg Mieterdaten in einem System verarbeitet, das keine Möglichkeit bot, die Daten zu jedem Zeitpunkt der Verarbeitung zu löschen.
Die Aufsichtsbehörde sah hierin unter anderem einen Verstoß gegen den „Privacy by Design“ – Grundsatz aus Art. 25 Abs. 1 DSGVO. Dies begründete sie damit, dass die Deutsche Wohnen SE „zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der eigentlichen Verarbeitung geeignete technische und organisatorische Maßnahmen“ hätte treffen können.
Der Hoepman´sche Ansatz
Jaap-Henk Hoepman ist Professor für datenschutzfördernde Technik in der Gruppe für digitale Sicherheit am Institut für Informatik und Informationswissenschaften der Radboud Universität Nijmegen.
Bereits im Jahr 2014 auf der 29. IFIP (Internationale Konferenz für Informationssicherheit und Datenschutz), stellte Hoepman eine konkrete Datenschutzstrategie vor, welche IT-Architekten und Entwickler dabei helfen könnte, den Datenschutz schon früh im Lebenszyklus der Softwareentwicklung zu integrieren.
Der Ansatz nach Hoepman ist sowohl eine Prozedur als auch ein Rahmen, der bestimmte Mechanismen festlegt, innerhalb dessen aber der Ansatz eine Pluralität der Umsetzung zulässt. Der Ansatz zeichnet sich dadurch aus, dass er sich auf 8 funktionale und proaktive Strategien fokussiert und zu jedem dieser Strategien „Design Pattern“ für die IT vorschlägt. Damit schlägt Hoepman nicht nur Grenzpflöcke ein, sondern zeigt eine aktive Richtung auf.
In concreto schlägt Hoepman deshalb 8 „Strategien“ vor:
- Minimieren
- Verstecken
- Separieren
- Aggregieren
- Informieren
- Kontrollieren
- Durchführen
- Demonstrieren
Was besagen die 8 Strategien?
Im Folgenden kurz 4 der insgesamt 8 Strategien paraphrasiert zusammengefasst:
SEPARIEREN
Personenbezogene Daten sollten nach Möglichkeit dezentral und getrennt verarbeitet werden. Vollständige Profile von Personen können nicht erstellt werden, wenn verschiedene personenbezogene Datenquellen, die sich auf dieselbe Person beziehen, getrennt verarbeitet und gespeichert werden. Die Trennung ist auch für sich genommen eine nützliche Technik, um das Ziel der Zweckbindung zu erreichen. Der dezentrale Charakter der Verarbeitung anstelle zentraler Lösungen ist für den Erfolg des Trennungskonzepts entscheidend. Insbesondere sollten Datenbanken, die Informationen aus verschiedenen Quellen enthalten, getrennt voneinander geführt werden.
AGGREGIEREN
Die Verarbeitung personenbezogener Daten sollte auf dem höchstmöglichen Aggregationsgrad und mit der geringstmöglichen Detailtiefe erfolgen, die mit ihrem weiteren Nutzen vereinbar ist.
Wenn Informationen über Gruppen von Personen oder Gruppen von Merkmalen zusammengefasst werden, ist die Menge an Details in den persönlichen Daten, die übrig bleiben, begrenzt. Diese Informationen werden also weniger wichtig.
Wenn die Informationen grob genug sind und die Gruppe, aus der sie gesammelt werden, groß genug ist, ist es schwieriger, sie mit einer einzelnen Person in Verbindung zu bringen. Dadurch wird die „Privatsphäre“ dieser Person geschützt.
VERSTECKEN
Alle personenbezogenen Daten und ihre Beziehungen zueinander sollten nicht sichtbar sein.
Der Grundgedanke hinter dieser Strategie ist, dass personenbezogene Daten nicht so leicht missbraucht werden können, wenn sie vor aller Augen versteckt werden. Die Strategie gibt nicht vor, vor wem die Informationen verborgen werden sollen. Die Antwort auf diese Frage hängt daher immer vom Einzelfall ab. Wenn die Strategie verwendet wird, um Informationen zu verbergen, die sich aus der Art und Weise ergeben, wie ein System genutzt wird (z. B. Kommunikationsmuster) besteht das Ziel darin, die Informationen vor allen zu verbergen.
MINIMIEREN
Als proaktives Element datenschutzfreundlicher Technikgestaltung bedeutet diese Strategie, dass grundsätzlich nicht mehr Daten verarbeitet werden dürfen als für die Erreichung des Zwecks erforderlich. Dies könnte bedeuten, dass man automatisierte Verarbeitungsprozesse automatisierten Entscheidungsprozessen vorzieht.
Möglich ist auch die Festlegung, dass überhaupt keine Informationen über eine bestimmte betroffene Person erhoben werden. Alternativ kann man sich dafür entscheiden, nur eine begrenzte Anzahl von Attributen zu erfassen.
Übertragung auf KI/ML-Systeme?
Ein Konzept von 2014? Ein recht alter Hut? Das dem nicht so ist, beweist die mögliche Übertragbarkeit des Ansatzes auf KI/ML-Systemen.
Denn entscheidend beim Privacy by Design sind nicht die endlose Dokumentation ins Blaue hinein, sondern primär die operative Umsetzung des Datenschutzes. Sprich: Das, was das Gesetz fordert, muss in eine technisch-funktionale und prüfbare Übersetzung kommen. Ansonsten verkümmern die Prinzipien und Grundsätze der DSGVO zu rein rechtlichen Wunschzielen, die in einem Hase-Igel-Wettlauf der technischen Entwicklung hinterherhinken.
Die Strategien auf KI/ML-Systemen übertragen, könnte exemplarisch bedeuten:
- Dem Anspruch auf „Separierung“ und Aggregation“ könnte das Federated Learning (Föderiertes Lernen), datenzentrierte Ansätze oder das Secure Multiparty Computation (SMPC) dienlich sein. SMPC ist ein Protokoll, das es mindestens zwei verschiedenen Parteien ermöglicht, ihre kombinierten Daten gemeinsam zu analysieren, ohne alle Daten miteinander zu teilen. Sprich eine verschlüsselte Lösung für das verteilte Training von KI/ML-Systemen, die allerdings aus Kostengründen wohl noch nicht besonders massentauglich ist.
- Dem Anspruch auf das „Verstecken“ bzw. Sichtbarkeit könnten Mechanismen wie das „Differential Privacy“ (Subsampling und Rauschen) und/oder die Nutzung von synthetischen Daten geeignet sein.
- Dem Grundsatz auf Datenminimierung könnte bekanntermaßen durch Anonymisierung und Pseudonymisierung Rechnung getragen werden. Aber auch durch eine klare Unterscheidung zwischen den in der Lern- und der Produktionsphase verwendeten Daten.
- Die CONTROL-Strategie (KONTROLLIEREN) könnte für mehr Kontrollierbarkeit eines KI/ML-Systems stehen, bspw. durch Patch- und Retraining-Vorgaben oder im Zweifel auch durch einen KI-Ausschaltknopf.
Auch beim Einsatz von KI/ML-Systemen sollten die hinter den Datenmengen stehenden Betroffenen nicht aus den Augen verloren werden. Gerade Privacy by Design und dem Hoepman´schen Ansatz bieten sowohl Data Engineers und Data Architects als auch den Data Scientist beim Aufbau der Daten-Infrastruktur und Datennutzung durch KI/ML-Systeme handfeste Richtungsvorgaben, die das sicherstellen können.
