Ein Entwicklungsteam kann personenbezogene Daten im Code finden und trotzdem vor der entscheidenden Frage stehen: Was folgt aus dem Befund? Ein Scanner meldet vielleicht eine E-Mail-Adresse oder ein Speichermuster. Den vollständigen Zweck der Verarbeitung, alle Schutzmaßnahmen und die rechtlichen Entscheidungen einer Organisation kennt er nicht. Aus dieser Lücke zwischen technischer Beobachtung und verantwortlicher Datenschutzprüfung ist PrivDev entstanden.
PrivDev ist mein Forschungsprojekt am AISE Laboratory der PUC-Rio. Die Leitidee ist eine Brücke von Sicherheitsbefunden zu Datenschutzfragen: festhalten, was ein Scanner tatsächlich beobachtet hat, den Befund mit einem gemeinsamen Vokabular verbinden und die Begründung prüfbar machen. Entwickler sollen einen brauchbaren Ausgangspunkt erhalten. Entscheidungen, für die Kontext nötig ist, bleiben bei den Menschen, die ihn kennen.
Dieser Beitrag stellt das Forschungsprogramm vor. Ein weiterer Artikel über Layer 1 beschreibt die erste Mapping-Studie genauer.
Eine Beobachtung ist noch keine Entscheidung#
Angenommen, ein Scanner findet Code, der ein Feld namens email verarbeitet. Das ist ein Befund über den untersuchten Code. Er beweist nicht, ob das Feld eine Kontaktadresse, Nachrichteninhalt, Testdaten oder etwas anderes enthält. Selbst wenn es sich um personenbezogene Daten handelt, lässt der Feldname weder den Verarbeitungszweck noch eine Rechtsgrundlage erkennen.
Bei Kryptografie ist die Unterscheidung ebenso wichtig. Ein Werkzeug sieht möglicherweise, dass ein Wert im Browserspeicher landet, ohne auf dem untersuchten Pfad eine Verschlüsselung zu finden. Das ist ein Anlass zur Prüfung. Es beweist nicht, dass der Wert an keiner anderen Stelle geschützt wird. Vielleicht liegt der Schutz in einer anderen Schicht; vielleicht sollte der Wert gar nicht gespeichert werden. Verschlüsselung ist eine mögliche technische Maßnahme, keine allgemeingültige Rechtsfolge eines Scannerbefunds.
Drei Fragen helfen mir, diese Grenze einzuhalten:
- Was wurde im Code oder in der Ausgabe des Scanners beobachtet?
- Welcher Datenschutzbegriff ist eine vertretbare Deutung dieses Befunds?
- Welche weiteren Angaben brauchen Entwicklung, IT-Sicherheit oder Datenschutz, bevor sie handeln?
Eine Antwort ist nützlicher, wenn diese drei Teile erkennbar getrennt bleiben. Eine flüssig formulierte Erklärung, die den Sprung zwischen ihnen verdeckt, kann mehr schaden als ein knapper Warnhinweis.
Die erste Brücke: Datentypen und ein gemeinsames Vokabular#
Die umgesetzte erste Schicht beginnt mit den 122 Datentyp-Bezeichnungen der Bearer-CLI-Taxonomie. Sie ordnet ihnen Begriffe für personenbezogene Daten aus der PD-Erweiterung des Data Privacy Vocabulary (DPV-PD) zu. Das Ergebnis ist ein abfragbarer Graph. Darin lässt sich prüfen, welche Kategorie für ein Scanner-Label gewählt wurde und welche Belege oder Prüfschritte dahinterstehen.
Manche Bezeichnungen passen unmittelbar zu einem Begriff des Vokabulars. Andere verlangen eine Einschätzung ihrer Bedeutung und Reichweite. Der Ablauf verbindet Retrieval, Vorschläge eines Sprachmodells, deterministische Prüfungen und menschliche Kontrolle. In einer späteren Überarbeitung wurde die Zuordnung bewusst vorsichtiger: Sie wahrt die Grenzen zwischen gewöhnlichen, besonderen und strafrechtlich relevanten Datenkategorien, kann bei unzureichenden Belegen auf eine Zuordnung verzichten und behauptet nicht mehr, ein Datentyp allein begründe die Anwendbarkeit eines bestimmten DSGVO-Artikels.
Diese Korrektur war lehrreich. Auch eine deterministische Regel kann falsch sein, wenn ihre Voraussetzung nicht trägt. Frühere Graphen enthielten rechtliche Verweise, die für die vorhandenen Belege zu spezifisch waren oder im verwendeten Vokabular nicht existierten. Das Projekt dokumentiert diese Fehler und verbessert die Methode. Ein Wissensgraph soll Behauptungen prüfbar machen, statt ihnen nur einen formalen Anschein zu geben.
Was nach der Kategorie kommt#
Der weitere Forschungsplan fragt, wie andere Scannerbefunde, darunter Software-Schwachstellen, mit Datenschutzrisiken und möglichen Maßnahmen verbunden werden können. Eine kryptografische Schwachstelle verführt zu einem schnellen Fehlschluss: Aus „keine Verschlüsselung gefunden“ wird „hier ist Verschlüsselung rechtlich vorgeschrieben“. Für diesen Schluss braucht es ein Bedrohungsmodell, Kenntnisse über die Daten und ihre Verwendung sowie fachliche Prüfung. Die geplanten weiteren Schichten von PrivDev sollen diese Grenzen sichtbar halten.
Mich interessiert außerdem, wie solche Hinweise in KI-gestützte Softwareentwicklung passen. Ein Assistent kann schnell Code erzeugen. Den fehlenden Verarbeitungskontext gewinnt er dadurch nicht. Ein hilfreicher Assistent sollte auf den konkreten Befund zeigen, Unsicherheit benennen und nach den Tatsachen fragen, die eine Entscheidung verändern würden. Er muss auch sagen können: „Das lässt sich aus diesem Scan nicht feststellen.“
PrivDev ist eine Forschungsrichtung und noch kein fertiges Compliance-Produkt. Umgesetzt und evaluiert ist die erste Mapping-Schicht. Die umfassendere Brücke und ihr Nutzen im Entwicklungsalltag müssen noch gebaut und geprüft werden. Selbst ein strukturell gültiger Graph belegt nicht, dass ein bestimmtes System DSGVO-konform ist.
Welche Frage für mich offen bleibt#
Ich möchte herausfinden, ob eine nachvollziehbare Brücke Entwicklern hilft, früher die richtigen Fragen zu stellen: Welche Daten sind betroffen? Welche Schutzmaßnahmen gibt es? Wer kann den Zweck bestätigen? Wann muss eine Fachperson übernehmen? Das sind Fragen für spätere Untersuchungen. Bis dahin liefert PrivDev eine überprüfbare Methode für einen begrenzten Teil des Problems und dokumentiert, wo sie bereits korrigiert werden musste.
Der Nutzen liegt darin, Unsicherheit erkennbar zu machen. Code liefert Beobachtungen, Vokabulare liefern gemeinsame Begriffe. Beides ersetzt weder den Kontext noch die Verantwortung einer Datenschutzentscheidung.