Softwarewerkzeuge können Spuren personenbezogener Daten im Code finden. Datenschutzvokabulare können beschreiben, was diese Daten bedeuten und welche Regeln relevant sein könnten. Das Problem: Diese beiden Welten sprechen normalerweise nicht direkt miteinander.
Genau darum geht es bei PrivDev, einem Forschungsprojekt, an dem ich am AISE Laboratory der PUC-Rio arbeite. Die erste Stufe des Projekts, Layer 1, stellt eine begrenzte Frage: Können wir die von einem Scanner gemeldeten Datentypen mit maschinenlesbaren Datenschutzbegriffen verbinden, sodass Entwickler die Ergebnisse abfragen und nachvollziehen können?
Dieser Artikel erklärt die Arbeit aus der Perspektive eines interessierten Lesers. Grundlage ist das Paper, das ich für die VEM 2026 vorbereite. Gleichzeitig geht es darum, was die bisherigen Ergebnisse zeigen – und was sie nicht zeigen.
Von einem Scanner-Ergebnis zu einem Datenschutzbegriff#
Stell dir vor, ein Scanner meldet, dass ein Programm eine E-Mail-Adresse, ein Geburtsdatum oder Gesundheitsdaten verarbeitet. Das ist nützlich, aber erst der Anfang. Das Scanner-Label sagt nicht automatisch, welche Datenschutzkategorie passt, welche DSGVO-Regel relevant sein könnte oder was ein Team als Nächstes prüfen sollte.
PrivDev verwendet die Taxonomie der Bearer CLI als Eingangsdaten. Sie enthält 122 Datentyp-Labels. Das Projekt ordnet diese Labels den Kategorien für personenbezogene Daten im W3C Data Privacy Vocabulary zu, meist DPV-PD genannt. Danach verbindet es die Kategorien mit potenziell relevanten DSGVO-Bestimmungen.
Das Ergebnis ist ein RDF/Turtle-Wissensgraph. Dadurch lässt sich das Ergebnis mit SPARQL abfragen, statt es nur als Liste von Textvorschlägen zu speichern. Der Graph enthält außerdem ODRL-Ressourcen für Richtlinien. So können den gemappten Datentypen maschinenlesbare Pflichten und Einschränkungen zugeordnet werden.
Die zentrale Idee ist eine Brücke: Ein sicherheitsorientierter Scanner liefert das Signal, während ein Datenschutzvokabular diesem Signal eine Struktur gibt, die Datenschutzwerkzeuge verwenden können.
Wo KI hilft – und wo nicht#
Nicht jedes Mapping ist gleich schwierig. Bei 43 der 122 Labels stimmte der Bearer-Name exakt mit einem bevorzugten DPV-Label überein. Diese Fälle können deterministisch aufgelöst werden.
Die übrigen 79 Mappings sind weniger eindeutig. Ein LangGraph-Workflow verteilt sie auf unabhängige Worker. Jeder Worker ruft passende Belege aus dem Datenschutzvokabular ab und schlägt mit einem retrieval-gestützten Sprachmodell ein Mapping vor. Danach durchläuft der Vorschlag deterministische Kodierungs- und Validierungsschritte.
Diese Trennung ist wichtig. Das Modell hilft bei mehrdeutiger Sprache, darf den fertigen Graphen aber nicht allein bestimmen. Das Ergebnis muss weiterhin in die erwarteten RDF-, ODRL- und DPV-Strukturen passen und die Prüfungen bestehen.
Was die ersten Ergebnisse zeigen#
Die Pipeline ordnete alle 122 Eingangstypen zu und erzeugte 118 verschiedene Policy-Ressourcen. Vier Paare von Eingangstypen verwiesen am Ende auf dieselbe DPV-Kategorie. Der Graph bestand die fünf formativen Prüfungen der Studie:
- Die SHACL-Validierung fand in den 118 Policies keine Verstöße.
- Der OOPS!-Scan des Vokabulars fand keine kritischen Probleme.
- Fünf SPARQL-Kompetenzfragen lieferten die erwarteten Ergebnisse.
- Eine Annotation durch Menschen lieferte verwertbare Hinweise zur Übereinstimmung.
- Der Bericht zur Retrieval-Qualität erreichte im Mittel 0,941 bei Output Groundedness und 0,780 bei Contextual Relevancy.
Neun Annotatoren gaben 711 Bewertungen zu den nicht-trivialen Mappings ab. Die Kennzahlen sind nicht identisch: Die rohe Übereinstimmung lag bei 0,721, Krippendorffs Alpha bei 0,251, Gwets AC1 bei 0,682 und Gwets gewichtetes AC2 bei 0,877. Diese Unterschiede sollte man nicht verstecken. Sie zeigen, wie schwierig mehrdeutige Kategorien zu bewerten sind, wenn sich viele Antworten auf „korrekt“ konzentrieren.
Zehn der 79 nicht-trivialen Mappings wurden zur Prüfung markiert. Das ist kein nutzloser Rest, sondern ein wichtiges Ergebnis. Die Liste zeigt, wo das Vokabular, das Scanner-Label oder der vorhandene Kontext nicht präzise genug sind.
Die Grenzen gehören zum Ergebnis#
PrivDev beweist nicht, dass ein Programm DSGVO-konform ist. Das Projekt entscheidet keine Rechtsgrundlage, führt keine Datenschutz-Folgenabschätzung durch und versteht nicht automatisch den vollständigen Zweck eines Datenflusses. Es ordnet Datentypen aus einem Scanner Datenschutzkategorien zu und verknüpft diese mit potenziell relevanten Pflichten.
Einige Probleme entstehen bereits vor dem Sprachmodell. Ein Label wie „Emails“ kann Kontaktinformationen oder den Inhalt von Nachrichten meinen. „Employee Files“ kann gleichzeitig mehrere Datenarten enthalten. Auch DPV hat Lücken: Manchmal ist die nächstbeste Klasse breiter als der Begriff des Scanners.
Deshalb versteht das Projekt sein Ergebnis als Plausibilität der Mappings und als Unterstützung für Entwickler – nicht als automatisierte Rechtsberatung. Die nächsten Layer brauchen mehr Kontext, weitere Scanner-Taxonomien und stärkere Tests dazu, ob die Brücke Datenschutzprüfungen in der Praxis wirklich verbessert.
Für mich liegt darin der spannendste Teil der Arbeit. Ein gutes Datenschutzwerkzeug sollte nicht so tun, als wären schwierige Entscheidungen einfach. Es sollte die Begründung sichtbar machen, schwache Belege zeigen und Entwicklern einen besseren Ausgangspunkt geben.