Reduktion digitaler Abhängigkeiten
Datenschutz war für mich am Anfang dieses Projekts eine gestalterische Entscheidung, keine Formalität für Nutzer:innen. Digitale Souveränität entsteht durch Strukturen, die Daten schon vor der ersten Interaktion sparsam behandeln.
Der Einwilligungsdienst Consenter von Law & Innovation Technology war das Werkzeug, mit dem ich diese Haltung technisch umgesetzt habe. Auf der Website von DACWB lässt sich das Ergebnis im Quellcode nachvollziehen.
⸺ Ausgangspunkt
Der Ausgangspunkt war das Wahlpflichtmodul Data Governance im Studiengang Leadership in Digitaler Innovation. Dort wurde mir klar: Datenschutz, Regulierung und technische Infrastruktur hängen zusammen. Verantwortung entsteht in den strukturellen Entscheidungen digitaler Systeme, lange bevor sie im Interface oder in einem rechtlichen Text sichtbar wird.
Ich habe daraufhin meine eigene Website als überprüfbare Infrastruktur behandelt statt als fertiges Produkt. Statt ein zusätzliches Tool oder einen Cookie-Banner einzusetzen und die Verantwortung damit an die Nutzer:innen weiterzugeben, habe ich die bestehende technische Struktur geprüft: welche externen Dienste eingebunden sind, welche Datenflüsse dabei automatisch entstehen und welche davon überhaupt gebraucht werden.
Datensparsamkeit war für mich damit eine architektonische Entscheidung, keine Einschränkung. Die Verantwortung sollte im System selbst stecken, dort nachprüfbar sein.
⸺ Kontext
Bei DACWB liefen mehrere externe Dienste automatisch mit, bevor überhaupt jemand auf der Seite etwas angeklickt hatte: eine eingebundene Schriftart, eine externe Bibliothek, mehrere Tracking- und Analyse-Skripte. Keiner davon stand in einem Dokument, keiner war Nutzer:innen gegenüber offengelegt.
Das hat für mich die Frage verschoben: von der Einwilligung zur Struktur davor. Was am Ende an Zustimmung eingeholt wird, hängt davon ab, was technisch längst eingebaut ist.
⸺ Entscheidung & Gestaltung
Die zentrale Entscheidung war, mit Consenter zuerst den Umfang der eigenen Datenerhebung zu prüfen und erst danach den Einwilligungsdienst einzubauen. Auf der Website von DACWB wurde damit jede einzelne Datenerhebung zu einer bewussten Entscheidung.
Code, Interface und rechtliche Logik greifen seitdem so ineinander, dass sich Verantwortung direkt im System nachvollziehen lässt, ohne dass jemand sie erklären muss. Digitale Souveränität entsteht hier durch Reduktion: durch das, was gar nicht erst erhoben wird.
Nicht alle Entscheidungen dieses Projekts sind im Interface sichtbar. Ein Teil davon fand vorher statt, in der Vorbereitung dazu.
Die folgende Knowledge Island zeigt, wie das aussah.
Konzeption
Die Grafik zeigt die Knowledge Island, eine Arbeitskarte, mit der ich Fragen zu Datensparsamkeit, Verantwortung und Governance über mehrere Wochen sortiert habe. Die einzelnen Notizen sind bewusst unscharf gehalten: Es sind Zwischenstände aus einem internen Arbeitsprozess, kein fertiges Ergebnis zum Vorzeigen.
Ich habe die Karte mehrfach überarbeitet — Beobachtungen ergänzt, Annahmen gestrichen, Strukturen neu geordnet. Daraus sind mehrere kleinere Entscheidungen entstanden, die sich gegenseitig bedingten.
Der eigentliche Nutzen der Visualisierung lag darin, sichtbar zu machen, wo in der Architektur eines digitalen Systems Verantwortung tatsächlich entsteht.
Ablauf des Projekts
1. Impuls aus der LehreDer Anstoß kam im Wahlpflichtmodul Data Governance. Dort ging es um Datenzugang und Regulierung, und mir wurde klarer, dass die Entscheidungen, die später Verantwortung verteilen, lange vor dem Interface fallen: in der technischen Struktur.
In diesem Modul stellte Max von Grafenstein seine Arbeit am Einwilligungsdienst Consenter vor. Der Ansatz löst Governance-Fragen technisch, statt sie über ein Zustimmungsfenster an die Nutzer:innen weiterzureichen. Ich bin aus dem Seminar mit der Frage gegangen, wie meine eigene Praxis aussieht, wenn man sie so prüft.
2. Entscheidung zur praktischen ErprobungIch habe mich als Beta-Tester für Consenter gemeldet. Statt es bei der Arbeit zum Seminar zu belassen, wollte ich das an einem System durchspielen, für das ich selbst geradestehe: der Website von DACWB in Deutschland.
Eine Website eignet sich dafür gut. Man kann sie öffnen, mitlesen, was sie im Hintergrund tut, und das Ergebnis überprüfen. Alles, was ich über Datensparsamkeit behaupten würde, wäre dort nachmessbar.
3. Sichtbarmachung der bestehenden StrukturAls Erstes habe ich mit den Developer-Tools des Browsers mitgeschrieben, was beim bloßen Aufruf der Seite passiert: welche Netzwerkaufrufe hinausgehen, welche Ressourcen von fremden Servern kommen, welche Daten dabei fließen. Fehler habe ich dabei kaum gesucht. Interessanter waren die Entscheidungen, die irgendwann jemand getroffen hat und die seitdem niemand mehr angesehen hatte.
Auffällig waren vor allem die harmlosen Dinge. Eine eingebundene Schriftart. Eine externe Bibliothek. Beides löst einen Aufruf an einen fremden Server aus, bevor ein Mensch auf der Seite irgendetwas angeklickt hat.
4. Technische Reduktion statt funktionaler ErweiterungDer naheliegende nächste Schritt wäre ein Werkzeug gewesen, das diese Aufrufe verwaltet. Ich habe stattdessen aufgeräumt. Schriftarten und Bibliotheken liegen jetzt lokal auf dem eigenen Server oder sind ganz raus. Tracking- und Analyseskripte habe ich einzeln durchgesehen und reduziert.
Die Seite kann seitdem ein paar Dinge nicht mehr. Dafür lässt sich in wenigen Minuten nachvollziehen, was sie tut.
5. Integration des EinwilligungsdienstesErst danach kam Consenter dazu. Die Reihenfolge war mir wichtig. Ein Einwilligungsdienst über einer aufgeräumten Seite fragt nach wenigem; über einer ungeprüften Seite verwaltet er vor allem Zustimmung zu Dingen, die niemand gebraucht hätte.
Bei DACWB ist die Einwilligung damit die Stelle, an der die Systemstruktur für Nutzer:innen sichtbar wird.
6. Gegengeprüfte Umsetzung und QualitätssicherungZum Schluss hat mein Bruder und Geschäftspartner Austin gegengelesen. Er kommt aus Mathematik und Data Science und hat geprüft, ob die Datenflüsse, die wir dokumentieren, mit dem übereinstimmen, was die Seite tatsächlich tut.
7. Einordnung und ÜbertragbarkeitWas ich aus dem Projekt mitnehme, ist vor allem die Reihenfolge: erst nachsehen, was ein System schon tut, dann entscheiden, was davon bleibt, und erst dann Werkzeuge dazustellen. Umgekehrt wird aus Datenschutz eine Verwaltungsaufgabe.
Auf andere digitale Systeme lässt sich das übertragen, und ich arbeite in diese Richtung weiter.
Gedanken
Die Aufrufe gingen jahrelang hinaus, jeden Tag, bei jedem Seitenaufruf. In keinem Dokument stand, dass es sie gibt.
Der Ansatz hat eine Grenze. Er funktioniert dort, wo man das System selbst verantwortet; bei Plattformen und fremden Infrastrukturen führt dieselbe Analyse zu einer Liste, an der sich nichts ändern lässt. Lesen und benennen kann man sie trotzdem.