Jusletter IT

Recht und Technik, das sind die beiden großen Themenfelder, die Erich Schweighofer miteinander verbindet. Es gibt viele ganz unterschiedliche Verbindungen von Recht und Technik. Die beiden Verbindungen von Recht und Technik, die das Schaffen von Erich Schweighofer bestimmen, sind einerseits die Rechtsinformatik (im engeren Sinne) als Anwendung von Methoden der Informatik auf juristische Gegenstände mit dem Ziel, Rechtswissenschaft und Rechtspraxis mit eben diesen Methoden zu unterstützen,¹ die von der Rechtsinformation bis hin zu AI and Law reicht und auch das umfasst, was in jüngerer Zeit als Legal Tech bezeichnet wird, und andererseits das IT-Recht. Das IT-Recht, verstanden als die Regulierung der Gestaltung und Anwendung informationstechnischer Entwicklungen in unserer Gesellschaft, soll in diesem und im nachfolgenden Beitrag von Christof Tschohl im Vordergrund stehen. Die beiden Beiträge bauen aufeinander auf und fügen den beiden genannten Varianten der Verbindung von Recht und Technik noch eine dritte hinzu: Technik kann auch zur Umsetzung und Durchsetzung des Rechts, insbesondere auch der Menschenrechte, eingesetzt werden. Der hier postulierte Regulierungsansatz kann somit als Rechtsdurchsetzung durch Technikgestaltung bezeichnet werden.

Die Beschäftigung mit diesem Thema im vorliegenden Beitrag ist in drei Teile gegliedert. Im ersten Teil werden die Grundlagen der Rechtsdurchsetzung durch Technikgestaltung erläutert. Der zweite Teil enthält aktuelle Erkenntnisse des Autors zu Privacy by Design, der in der Praxis wohl bedeutendsten Ausprägung des Prinzips der Rechtsdurchsetzung durch Technikgestaltung. Im dritten Teil des Beitrags wird der Fokus auf die Architekturgestaltung von Systemen gelegt. Der nachfolgende Beitrag von Tschohl betrachtet das Prinzip der Rechtsdurchsetzung durch Technikgestaltung auf einer grundrechtlichen und rechtsstaatlichen Ebene und befasst sich mit der Rechtsstaatlichkeit durch Technikgestaltung.

Ausgangspunkt des Prinzips der Rechtsdurchsetzung durch Technikgestaltung ist die Erkenntnis, dass das Recht nur einer von mehreren Faktoren ist, die das menschliche Handeln von außen determinieren. Andere solche Faktoren sind gesellschaftliche Einflüsse und moralische Werte sowie insbesondere die vorhandenen faktischen Handlungsmöglichkeiten, die ihrerseits häufig durch die technischen Gegebenheiten determiniert werden.²

In diesem Sinne beschreibt Lessig in seiner New Chicago School Theory vier Faktoren der Regulierung (modalities of regulation): das Recht, soziale Normen, den Markt und die physische Architektur.³ Software wird von Lessig dabei als eine Form der Architektur betrachtet, da sie dieselbe Wirkung wie Architektur habe.⁴ Software, allgemeiner: Technikgestaltung, physische Architektur und auch der Markt entfalten eine unmittelbare regulatorische Wirkung. Sie geben faktische Handlungsmöglichkeiten vor. Die Einhaltung dieser Vorgaben ist nicht vom Willen des Betroffenen beeinflussbar; andere Handlungsmöglichkeiten als die faktisch vorgegebenen kann er nicht ergreifen. Dies kann als präventive Regulierung bezeichnet werden. Rechtsnormen und soziale Normen entfalten eine mittelbare regulatorische Wirkung. Sie belegen Handlungen mit Konsequenzen. Der Betroffene kann sich aber auch entscheiden, andere als die von diesen Normen als zulässig vorgegebenen Handlungsmöglichkeiten zu ergreifen. Dies kann als repressive Regulierung bezeichnet werden.⁵

Bei Lessig findet sich auch die Erkenntnis, dass das Recht die Besonderheit aufweist, auf die anderen drei Faktoren, die sozialen Normen, den Markt und die physische Architektur, einwirken zu können.⁶ In Anlehnung an Reidenberg⁷ ist daher festzuhalten, dass politische Vorgaben im Kontext der Technikregulierung auf drei verschiedene Arten umgesetzt werden können: Erstens können politische Vorgaben direkt durch Technikgestaltung umgesetzt werden. De Hert und Thumfart sprechen in Bezug auf die faktische Dominanz der großen Digitalkonzerne von «de facto regulation by technical design».⁸ Dies soll hier als Regulierung durch Technikgestaltung bezeichnet werden. Anzumerken ist, dass Technik auch eine derartige faktische regulatorische Wirkung entfalten kann, ohne dass dies intendiert ist.⁹

Zweitens können politische Vorgaben durch Rechtsnormen umgesetzt werden, die sich an die Gestalter der Technik richten und diese verpflichten, die politischen Vorgaben in der Technikgestaltung umzusetzen. Dies ist es, was im Zentrum des vorliegenden Beitrags steht und als Rechtsdurchsetzung durch Technikgestaltung bezeichnet wird. Es handelt sich dabei aus der Perspektive der Endanwender der Technik um präventive Regulierung.

Drittens können politische Vorgaben durch Rechtsnormen umgesetzt werden, die sich an die Nutzer der Technik richten, und diesen vorgeben, die Technik auf bestimmte Weise zu nutzen oder nicht zu nutzen. Hierbei handelt es sich um «klassische» repressive Regulierung.

Repressive Regulierung eignet sich durchaus gut für die Regulierung zahlreicher Lebensbereiche, vor allem weil diese eine gewisse Flexibilität zulässt und unserer liberalen Gesellschafts- und Rechtsordnung entspricht. Was wie ein Rechtsverstoß aussieht, muss nicht in jedem Fall ein Rechtsverstoß sein, man denke nur an den einfachen Fall der Notwehr oder an Schrankenregelungen im Urheberecht.¹⁰ Ein rechtstaatliches Verfahren zur Durchsetzung repressiver Regulierung ist sehr gut dazu geeignet, solche Ausnahmeregelungen und Nuancierungen zu berücksichtigen.

Die Notwendigkeit eines solchen Verfahrens der Durchsetzung post factum, an dessen Ende Konsequenzen gesetzt werden, ist aber zugleich die wesentliche Schwäche der repressiven Regulierung. Es kann besonders schwierig sein, dass es zu so einem Verfahren faktisch überhaupt kommt. Dies beginnt bereits mit der Notwendigkeit, dass die Nichteinhaltung zunächst von jemandem festgestellt werden muss, der ein Verfahren anstrengt, und das Verfahren bedeutet einen zeitlichen und häufig auch einen finanziellen Aufwand. Dies ist ein Grund dafür, dass präventive Regulierung in bestimmten Fällen besser geeignet sein kann, ein regulatorisches Ziel zu erreichen, als repressive Regulierung. Im Datenschutz ist dies besonders ausgeprägt der Fall, weil es hier besonders schwierig ist, auf Verstöße überhaupt aufmerksam zu werden, diese nachzuweisen und Ansprüche gegen den Verantwortlichen durchzusetzen, der überdies in vielen Fällen nicht der österreichischen Jurisdiktion unterliegt. Hinzu kommt, dass in vielen Fällen der durch die Nichteinhaltung eingetretene Schaden nicht mehr rückgängig gemacht werden kann. Einem unbefugten Datenverwender oder gar der Öffentlichkeit kann die Kenntnis einer Information naturgemäß nicht mehr entzogen werden, was eine Wiedergutmachung häufig unmöglich macht.¹¹

Zur Durchsetzung des Datenschutzrechts und allgemein auch zur Verhinderung der Überschreitung staatlicher Befugnisse¹² erscheint daher präventive Regulierung als ein geeignetes und angemesses Mittel, um diesen und ähnlichen Defiziten zu begegnen. Damit soll jedoch nicht schlechthin der Verbreitung des Prinzips einer Rechtsdurchsetzung durch Informationstechnik das Wort geredet werden. Beispiele dafür reichen von Uploadfiltern im Urheberrecht bis hin zu Fahrzeugen, die das Überschreiten der zulässigen Höchstgeschwindigkeit überhaupt nicht mehr zulassen; solche Maßnahmen bringen in der Regel erhebliche Risiken, Fehleranfälligkeit und andere Schwächen mit sich, die es abzuwägen gilt, wenn in einem bestimmten Anwendungsgebiet über Rechtsdurchsetzung durch Informationstechnik nachgedacht wird.¹³ Schließlich ist noch anzumerken, dass Regulierung durch technische Maßnahmen i.d.R. Software beinhaltet und damit auch die der Software inhärenten Eigenschaften der potenziellen Instabilität, Fehlerhaftigkeit und Manipulierbarkeit.¹⁴

Eine bedeutende, weil tatsächlich normativ verankerte Ausprägung des Prinzips der Rechtsdurchsetzung durch Technikgestaltung ist Privacy by Design. Privacy by Design bedeutet, Datenschutz bei der Gestaltung eines Systems von Beginn an zu berücksichtigen, sodass die Verwirklichung der Datenschutzgrundsätze bereits im System angelegt ist, und eine nicht intendierte/nicht zweckkonforme Verwendung des Systems durch technische und organisatorische Maßnahmen möglichst von vornherein zu verhindern. Die Umsetzung von Privacy by Design bedeutet somit, bereits von Beginn des Systementwicklungsprozesses an, einige wenige Grundprinzipien des Datenschutzes durch Einsatz geeigneter Design-Strategien, Design Patterns und Privacy-enhancing Technologies (PETs) unter Einbeziehung von Wissen über häufige Fehler, die Rechtslage, aktuelle Bedrohungen und Angriffsmethoden etc. umzusetzen. Dies wirkt sich sowohl auf die Architektur als auch auf viele Detailaspekte der Gestaltung von Systemen aus. Eine zentrale Maßnahme zur Umsetzung von Privacy by Design ist konsequente Datenminimierung. Dies betrifft mehrere Dimensionen: Art der Daten, Umfang der Daten, Speicherdauer, Kreis der Zugriffsberechtigten etc. Ein weiterer wesentlicher Aspekt der Umsetzung ist es, Privacy by Design als Denkweise («Mindset»), d.h. als grundlegende Einstellung zum Umgang mit personenbezogenen Daten zu betrachten und möglichst weit unter jenen zu verbreiten, die mit personenbezogenen Daten arbeiten oder Systeme entwickeln, deren Zweck die Verarbeitung personenbezogener Daten ist.¹⁵

An dieser Stelle sei angemerkt, dass natürlich unterschieden werden kann zwischen Privacy by Design als programmatischem datenschutzpolitischem Konzept, wie es von Cavoukian¹⁶ und später auch von der Internationalen Konferenz der Datenschutzbeauftragten in einer Resolution¹⁷ postuliert wurde, und Data Protection by Design/Datenschutz durch Technikgestaltung, wie es Art. 25 DSGVO als rechtliche Verpflichtung vorsieht.¹⁸ Diese Unterscheidung wird im Folgenden jedoch nicht getroffen, denn der Begriff Privacy by Design bezieht sich hier sowohl auf Art. 25 DSGVO sowie dessen Umsetzung als auch auf das zugrundeliegende datenschutzpolitische Konzept, soweit sich dieses in Art. 25 DSGVO manifestiert.

Die Einbettung von Art. 25 DSGVO in der Systematik der DSGVO kann wie folgt beschrieben werden: Aufbauend auf den Datenschutzgrundsätzen des Art. 5 DSGVO verpflichten drei Bestimmungen, Art. 24, 25 und 32 DSGVO, den Verantwortlichen – unter Berücksichtigung der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere der Risiken für die Rechte und Freiheiten natürlicher Personen –, geeignete technische und organisatorische Maßnahmen zu treffen, um eine DSGVO-konforme Datenverarbeitung sicherzustellen.

Abbildung 1. Einbettung von Art. 25 DSGVO in der Systematik der DSGVO

Um diese Bestimmungen erfüllen zu können, insbesondere um abwägen zu können, welche Maßnahmen angemessen sind, müssen die Risiken jeder einzelnen Verarbeitungstätigkeit abgeschätzt werden. Aus praktischer Sicht erfolgt diese Risikoabschätzung im Zuge der Prüfung der Zulässigkeit einer Verarbeitungstätigkeit, die wiederum mit der Eintragung der Verarbeitungstätigkeit in das Verarbeitungsverzeichnis nach Art. 30 DSGVO einhergehen sollte. Wenn diese Risikoabschätzung ein voraussichtlich hohes Risiko für die Rechte und Freiheiten natürlicher Personen ergibt, sieht Art. 35 DSGVO die besondere Pflicht zu einer systematischen Risikoabschätzung nach den Vorgaben des Art. 35 Abs. 7 DSGVO vor (Datenschutz-Folgenabschätzung). Die festgestellten Risiken fließen wiederum ein in die Abwägung betreffend die Angemessenheit von Maßnahmen zur Erfüllung der Art. 24, 25 und 32 DSGVO.

Diese drei Bestimmungen überschneiden einander in ihrem materiellen Gehalt, sodass i.d.R. nicht festgelegt werden kann, ob eine bestimmte Maßnahme aufgrund von Art. 24, 25 oder 32 DSGVO zu treffen ist, oder aufgrund von zwei oder allen drei dieser Bestimmungen. Allerdings sieht nur Art. 25 DSGVO in Abs. 1 die Verpflichtung vor, entsprechende Maßnahmen nicht nur «zum Zeitpunkt der eigentlichen Verarbeitung» zu treffen, sondern auch bereits «zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung».

Auch ein Blick auf die in ErwGr. 78 Satz 3 der DSGVO beispielhaft aufgezählten Maßnahmen zur Umsetzung von Art. 25 DSGVO lässt erkennen, dass der Regelungsgehalt des Art. 25 DSGVO sich mit jenem anderer Bestimmungen der DSGVO deutlich überschneidet, denn alle dort genannten Maßnahmen sind – sofern jeweils angemessen – auch aufgrund anderer Bestimmungen der DSGVO verpflichtend.¹⁹

Beides spricht dafür, dass entsprechend den oben erläuterten Grundlagen des Prinzips Privacy by Design das Treffen von Maßnahmen «zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung», also in der Technikgestaltung, den Kern des exklusiven Regelungsgehalts von Art. 25 Abs. 1 DSGVO ausmacht. Für Baumgartner und Gausling besteht in Bezug auf den Zeitpunkt der eigentlichen Verarbeitung überhaupt kein eigenständiger Regelungsgehalt von Art. 25 Abs. 1 DSGVO, weil ab diesem Zeitpunkt insbesondere Art. 24 Abs. 1 und Art. 32 Abs. 1 im Ergebnis dieselben Verpflichtungen normieren.²⁰ Dazu ist anzumerken, dass nur Verstöße gegen Art. 25 und Art. 32 DSGVO gem. Art. 83 Abs. 4 lit. a DSGVO unmittelbar mit Geldbußen bedroht sind, nicht jedoch Verstöße gegen Art. 24 DSGVO.

Aus der Perspektive der Rechtsdurchsetzung ist anzumerken, dass naturgemäß auch eine auf präventive Regulierung abzielende Bestimmung wie Art. 25 DSGVO ihrerseits der Durchsetzung auf repressivem Wege bedarf. Allerdings wird dies deswegen wesentlich erleichtert, weil Art. 25 DSGVO – wie letztlich die geamte Regelungssystematik der DSGVO – so ausgestaltet ist, dass der Verantwortliche dazu in der Lage sein muss, den Nachweis zu erbringen, dass zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung eine Beurteilung stattgefunden hat, welche technischen und organisatorischen Maßnahmen aufgrund dieser Bestimmung zu treffen sind.²¹

Eine bemerkenswerte Entscheidung zu Art. 25 DSGVO ist der – noch nicht rechtskräftige – Bußgeldbescheid der Berliner Datenschutzbehörde in Höhe von rund 14,5 Millionen Euro gegen die Deutsche Wohnen SE wegen Verstoßes gegen Art. 25 Abs. 1 DSGVO sowie Art. 5 DSGVO, u.a. weil diese für die Speicherung personenbezogener Daten von Mieterinnen und Mietern ein Archivsystem verwendete, das keine Möglichkeit vorsah, nicht mehr erforderliche Daten zu entfernen.²²

Im Hinblick auf die praktische Umsetzung sollte Privacy by Design als Prozess betrachtet werden.²³ Das gilt sowohl für das Datenschutzmanagement innerhalb einer Organisation als auch für die Entwicklung datenverarbeitender Systeme. Jedoch ist dies nicht im Sinne eines standardisierten Prozesses oder Vorgehensmodells zu verstehen. Es ist wohl nicht möglich, ein allgemeingültiges Vorgehensmodell zu entwickeln, dessen Umsetzung, insbesondere auch durch Personen, die keine Datenschutzexperten sind, gewissermaßen automatisch zu einem mit Art. 25 DSGVO konformen System führen würde. Vielmehr ist es stets erforderlich, auf die Gegebenheiten des jeweiligen Systems individuell einzugehen.

Das bedeutet jedoch nicht, dass Privacy by Design für jedes zu entwicklende System etwas gänzlich anderes bedeuten würde. Vielmehr kann unterschieden werden in einerseits weitgehend allgemeingültige und andererseits individuelle, systemspezifische Anforderungen, die sich aus Art. 25 Abs. 1 DSGVO ergeben. Eine Standardisierung konkreter, unmittelbar umsetzbarer Privacy-by-Design-Anforderungen erscheint daher zumindest in gewissen Teilbereichen möglich.

Somit ergibt sich folgender dualer Ansatz zur Umsetzung von Privacy by Design bei der Entwicklung von datenverarbeitenden Systemen, wie in Abb. 2 dargestellt:²⁴ Die Privacy-by-Design-Anforderungen, die sich aus Art. 25 DSGVO ergeben, können unterschieden werden in konkrete Standardanforderungen, die in einer standardisierten Form umgesetzt werden können, und abstrakte Anforderungen, die einer individuellen, systemspezifischen Umsetzung bedürfen.

Abbildung 2.

Die aus Art. 25 DSGVO abzuleitenden Anforderungen an die Technikgestaltung können unterschieden werden in konkrete Standardardanforderungen (oben), die standardisiert umgesetzt werden können, und abstrakte Anforderungen (unten).²⁵

Die konkreten Standardanforderungen sind jene, die nahezu jedes datenverarbeitende System in ähnlicher Form erfüllen muss. Es handelt sich dabei um detaillierte Anforderungen, die nicht oder nur geringfügig vom Kontext abhängen und daher keiner weiteren systemspezfischen Konkretisierung mehr bedürfen. Es ist somit auch keine besondere Datenschutz-Expertise erforderlich, um diese Anforderungen umzusetzen. Sie eignen sich daher zur Umsetzung mittels Checklisten oder in ähnlicher standardisierter Form. Solche konkreten Standardanforderungen ergeben sich insbesondere aus den Betroffenenrechten nach Art. 12 ff. DSGVO. Beispielsweise ist es eine konkrete Standardanforderung an jedes System, das zur Verarbeitung von personenbezogenen Daten entwickelt wird, dass es möglich sein muss, personenbezogene Daten zu löschen.²⁶ Dabei handelt es sich um eine unmittelbar umsetzbare Anforderung, die für alle solchen Systeme in gleicher Weise besteht und direkt aus Art. 5 Abs. 1 lit. b und Art. 17 DSGVO abgeleitet weren kann.

Diese und einige weitere konkrete Standardardanforderungen sind in der folgenden Tabelle beschrieben:

Tabelle 1. Nicht erschöpfende Liste konkreter, unmittelbar umsetzbarer Standardanforderungen der DSGVO

Darüber hinaus könnte man neben diesen zwingenden konkreten Standardanforderungen weitere herausarbeiten, die zwar nicht zwingend sind, aber die Umsetzung der DSGVO erheblich erleichtern. Ein Beispiel für eine solche Anforderung ist die Möglichkeit, die Herkunft von Daten direkt in Verbindung mit diesen Daten speichern zu können, um darüber gem. Art. 15 Abs. 1 lit. g DSGVO Auskunft geben zu können. Eine solche Anforderung ist sehr nahe am Konzept der Privacy Design Patterns, wie sie in Abb. 2 in Bezug auf die konkreten Standardanforderungen dargestellt sind. Design Patterns sind bewährte Entwurfsmuster zur Lösung wiederkehrender Probleme, die i.d.R. in einer bestimmten strukturierten Form beschrieben sind.²⁷

Einen Schritt weiter kann man noch mit der Definition konkreter Funktionalitäten zur ganz oder teilweise automatisierten Erfüllung bestimmter Anforderungen der DSGVO gehen. Diese werden in Abb. 2 als «Privacy Design Gears» bezeichnet.²⁸ Beispiele dafür sind ein Portal, bei dem Betroffene direkt durch Abruf personenbezogener Daten ihre Rechte auf Auskunft und/oder Datenübertragbarkeit ausüben können, oder automatisierte Trigger, die melden, wenn bestimmte Daten gelöscht werden müssen oder wenn bestimmte Vorgänge eine Informationspflicht nach Art. 13 oder 14 DSGVO auslösen.

Demgegenüber sind die abstrakten Anforderungen solche, die nicht unmittelbar umsetzbar sind, weil ihre Umsetzung stark vom jeweiligen zu entwickelnden System abhängt. Was eine solche Anforderung, wie z.B. Datenminimierung oder Pseudonymisierung, für ein bestimmtes System bedeutet, hängt sehr stark von den Umständen des Einzelfalles ab. Es bedarf daher einer systemspezifischen Konkretisierung dieser Anforderungen, bevor diese umgesetzt werden können. Dabei kann auf Privacy Enhancing Technologies²⁹ zurückgegriffen und als Zwischenschritte in dieser Konkretisierung können die von Hoepman entwickelten Privacy Design Strategies³⁰ herangezogen werden. Eine standardisierte Checkliste zur unmittelbaren Umsetzung der abstrakten Anforderungen erscheint jedoch nicht denkbar.

Es ist daher unerlässlich, dass jene Personen, die an der Entwicklung eines Systems beteiligt sind, den Datenschutz mitbedenken und in der systemspezifischen Konkretisierung der abstrakten Anforderungen geschult sind. Privacy by Design sollte daher als Denkweise («Mindset») in der Organisation etabliert werden. Zusätzlich können in der Entwicklung Experten hinzugezogen werden, um die systemspezifische Konkretisierung der abstrakten Anforderungen zu erarbeiten. In einem agilen Softwareentwicklungsprozess kann dies z.B. durch einen Pool von Privacy Enigneers erfolgen, aus dem je nach Bedarf die einzelnen (Scrum-)Teams beschickt werden.³¹ In kleineren Strukturen kann dies im einfachsten Fall auch ein einzelner Experte sein. Es ist aber m.E. unerlässlich, dass sich die Gestalter von Technologie selbst mit den einschlägigen Datenschutzanforderungen und letztlich mit den gesellschaftlichen Auswirkungen ihrer Entwicklungen befassen.

Nach diesen Detailerwägungen gilt es, nochmals einen Schritt zurückzutreten, um einen gesamtheitlichen Blick auf die Ebene der Praxis der Technikgestaltung im Kontext des Datenschutzes zu werfen. Es soll betont werden, dass Privacy by Design nicht nur in vielen Detailfragen der Technikgestaltung beachtet und umgesetzt werden muss, sondern dass dies bereits bei grundlegenden Fragen der Systemgestaltung beginnt.

Die Gestaltung technischer Systeme sollte sich daher bereits am Anfang mit der Frage befassen, wie man bereits durch die Gestaltung der Systemarchitektur Datenschutzanforderungen und -grundsätze erfüllen kann und dadurch bei der näheren Ausgestaltung des Systems auftretende Datenschutzfragen und -probleme vermeiden kann. Dies kann als Privacy by Architecture bezeichnet werden.³²

Ein Beispiel dafür ist die Architektur des Systems, das derzeit unter Beteiligung des Autors im H2020-Projekt FeatureCloud entwickelt wird.³³ Es handelt sich dabei um ein System zur medizinischen Forschung in großen Mengen von Patientendaten mittels Machine Learning. Wie in Abb. 3 ersichtlich, ist das System nach dem Grundsatz Privacy by Architecture so aufgebaut, dass die Patientendaten für Forschungszwecke nicht in eine große zentrale Datenbank kopiert werden müssen, sondern in den Krankenhäusern und Forschungseinrichtungen, in denen sie anfallen, verbleiben können. Die Machine-Learning-Algorithmen werden so gestaltet, dass sie dort dezentral auf die Daten angewendet werden können und nur aggregierte Ergebnisse («Features») an eine zentrale Stelle geschickt werden, die in der Folge ein Gesamtergebnis errechnet. Dieser Ansatz fügt zwar in Bezug auf das Machine Learning eine neue Komplexitätsebene hinzu, löst aber zugleich eine Vielzahl rechtlicher und faktischer Probleme hinsichtlich der Verarbeitung der Daten zu Forschungszwecken und soll somit letztlich zur faktischen Verfügbarkeit einer vielfach größeren Datenmenge für die medizinische Forschung führen.

Abbildung 3. Privacy by Architecture am Beispiel des Forschungsprojekts FeatureCloud

Privacy by Architecture ist somit als fundamentaler Bestandteil von Privacy by Design zu betrachten, der hier jedoch separat betont werden soll. Wie das Beispiel der FeatureCloud-Architektur zeigt, lassen sich mit einzelnen Designentscheidungen betreffend die Architektur eines Systems weitreichende Auswirkungen auf den Datenschutz erzielen. Damit ergibt sich die nachfolgend dargestellte «Qualitätspyramide» von Paradigmen zur Umsetzung von Datenschutzanforderungen in der Technikgestaltung.

Abbildung 4. «Qualitätspyramide» von Paradigmen zur Umsetzung von Datenschutzanforderungen in der Technikgestaltung

Das Fundament bildet Privacy by Architecture. Bei der Gestaltung der Systemarchitektur fallen die Grundsatzentscheidungen hinsichtlich der Datenschutzkonformität und Datenschutzfreundlichkeit eines Systems. Entscheidungen auf dieser Ebene haben – wie allgemein in der Technikgestaltung – naturgemäß die weitreichendsten Auswirkungen. Danach folgen auf der nächsten Ebene im Systementwicklungsprozess alle weiteren Privacy-by-Design-Entscheidungen bis hin zur einzelnen Zeile Code, über die ein Entwickler i.d.R. alleine und ad hoc entscheidet. Zur Umsetzung der Datenschutzanforderungen können Privacy Enhancing Technologies (PETs) herangezogen werden. Diese sollten jedoch – wie hier gezeigt – auf dem Fundament von Privacy by Architecture und by Design bereits im Technikgestaltungsprozess systematisch in die Systeme integriert werden, denn es ist nicht wirksam, Systeme nachträglich um PETs zu ergänzen.³⁴ Sind die Systeme schließlich diesem Prozess folgend nach den Vorgaben von Art. 25 DSGVO gestaltet, können im Betrieb jene Anforderungen umgesetzt werden, die nicht unmittelbar in der Technikgestaltung umgesetzt werden konnten. Dies ist die Domäne von Privacy by Policy, einem Konzept, dass sich weitgehend auf Information und informationelle Selbstbestimmung des Betroffenen beschränkt.³⁵ Wie gezeigt wurde, ergibt sich ein effektiver Datenschutz jedoch nur dann, wenn die darunterliegenden Systeme bereits datenschutzkonform gestaltet wurden und insbesondere auch das Prinzip Privacy by Default berücksichtigt wurde, damit auch jene Betroffenen adäquat geschützt sind, die nicht aktiv von ihrem Recht auf informationelle Selbstbestimmung Gebrauch machen, wofür es mannigfache Gründe geben kann.

Recht und Technik, die beiden großen Themenfelder, die Erich Schweighofer miteinander verbindet, stehen in vielfacher Weise miteinander in Beziehung. Im vorliegenden Beitrag wurde der Fokus auf die Umsetzung und Durchsetzung des Rechts mittels Technik gelegt. Zunächst wurde zwischen repressiver und präventiver Regulierung unterschieden, und Rechtsdurchsetzung durch Technikgestaltung als Mittel der präventiven Regulierung beschrieben. Dabei wurde betont, dass Rechtsdurchsetzung durch Technikgestaltung nur in bestimmten Fällen herangezogen werden sollte, und keineswegs alle Probleme durch präventive Regulierung gelöst werden können, geschweige denn sollten.

Wie gezeigt wurde, weist das Datenschutzrecht Besonderheiten auf, die den Einsatz des Prinzips der Rechtsdurchsetzung durch Technikgestaltung in diesem Rechtsgebiet rechtfertigen. Normativ ist dies nunmehr mit Art. 25 DSGVO umgesetzt. Ein Ziel des vorliegenden Beitrags ist es, mit der in Kapitel C postulierten Unterscheidung der sich aus Art. 25 DSGVO ergebenden Anforderungen in konkrete Standardanforderungen und abstrakten Anforderungen einen Fortschritt in der praktischen Umsetzung von Privacy by Design zu erzielen. Einige konkrete Standardanforderungen, die sich aus der DSGVO für alle Systeme, die personenbezogene Daten verarbeiten, in gleicher Weise ergeben und unmittelbar umsetzbar sind, wurden herausgearbeitet. Hier ergibt sich ein Ansatz, die Forschung fortzusetzen, um weitere konkrete Standardanforderungen der DSGVO herauszuarbeiten.

Aus der Perspektive der Rechtsdurchsetzung wurde betont, dass naturgemäß auch eine auf präventive Regulierung abzielende Bestimmung wie Art. 25 DSGVO ihrerseits der Durchsetzung auf repressivem Wege bedarf. Soweit ersichtlich gibt es seit Wirksamwerden der DSGVO erst wenige Entscheidungen zu Art. 25 DSGVO, eine bedeutsame Entscheidung ist allerdings nunmehr ergangen und konnte somit in diesem Beitrag aufgegriffen werden.

Die Beziehung zwischen Recht und Technik, die in diesem Beitrag beleuchtet wurde, wird im nachfolgenden Beitrag von Tschohl weiter vertieft. Dieser betrachtet das Prinzip der Rechtsdurchsetzung durch Technikgestaltung auf einer grundrechtlichen und rechtsstaatlichen Ebene und befasst sich mit der Rechtsstaatlichkeit durch Technikgestaltung.