Software tools can find traces of personal data in code. Privacy vocabularies can describe what that data means and what rules might be relevant. The problem is that these two worlds usually do not speak to each other.
That is the problem behind PrivDev, the research project I am working on at PUC-Rio’s AISE Laboratory. The first part of the project, Layer 1, asks a focused question: can we connect the data types reported by a static-analysis scanner to machine-readable privacy concepts in a way that developers can query and inspect?
This article is a plain-language explanation of the paper I am preparing for VEM 2026. It is also a record of what the current results do—and do not—show.
From a scanner finding to a privacy concept#
Imagine that a scanner reports that a program handles an email address, a birth date, or health information. That is useful, but it is only the beginning. The scanner label does not automatically tell us which privacy category applies, which GDPR provision might matter, or what a team should review next.
PrivDev uses the Bearer CLI taxonomy as its input. It contains 122 data-type labels. The project maps those labels to the Personal Data categories of the W3C Data Privacy Vocabulary, usually called DPV-PD. It then connects the categories to potentially relevant GDPR provisions.
The output is an RDF/Turtle knowledge graph. This makes the result queryable with SPARQL instead of leaving it as a list of prose suggestions. The graph also contains ODRL policy resources, so each mapped data type can carry machine-readable duties and constraints.
The important idea is the bridge: a security-oriented scanner produces the signal, while a privacy vocabulary gives that signal a structure that privacy-aware software tools can use.
Where AI helps—and where it does not#
Not every mapping is equally difficult. For 43 of the 122 labels, the Bearer name exactly matched a preferred DPV label. Those cases can be resolved deterministically.
The remaining 79 mappings are less obvious. A LangGraph workflow dispatches them to independent workers. Each worker retrieves relevant evidence from the available privacy vocabulary and proposes a mapping with a retrieval-grounded language model. The proposal is then passed through deterministic encoding and validation steps.
This separation matters. The model can help with ambiguous language, but it does not get to define the final graph by itself. The emitted result must still fit the expected RDF, ODRL, and DPV structures, and it must pass the checks around it.
What the first results show#
The pipeline mapped all 122 input types and produced 118 distinct policy resources. Four pairs of input labels ended up pointing to the same DPV category. The graph passed the five formative gates used in the study:
- SHACL validation found no violations across the 118 policies.
- The OOPS! ontology scan found no critical problems.
- Five SPARQL competency questions returned their expected results.
- A human-annotation round produced usable agreement evidence.
- The retrieval-quality report reached a mean output-groundedness score of 0.941 and mean contextual relevancy of 0.780.
Nine annotators supplied 711 judgments for the non-trivial mappings. The reported statistics are not identical: raw agreement was 0.721, Krippendorff’s alpha was 0.251, Gwet’s AC1 was 0.682, and weighted Gwet’s AC2 was 0.877. That disagreement is not something to hide. It reflects how difficult it is to judge ambiguous categories when many answers are concentrated around “correct”.
Ten of the 79 non-trivial mappings were marked for review. That is useful output, not just an inconvenient exception list. It shows where the vocabulary, the scanner label, or the available context is not precise enough.
The limits are part of the result#
PrivDev does not prove that a program is GDPR-compliant. It does not decide a legal basis, perform a DPIA, or understand the full purpose and context of a data flow. It maps scanner data types to privacy categories and links those categories to potentially relevant obligations.
Some problems appear before the language model is involved. A label such as “Emails” might mean contact information or the contents of messages. “Employee Files” can contain several kinds of data at once. DPV also has coverage gaps: sometimes the closest available class is broader than the scanner’s concept.
These limits are why the project treats its result as mapping plausibility and developer support, not automated legal advice. The next layers will need more context, more scanner taxonomies, and stronger tests of whether the bridge actually improves privacy review in practice.
For me, that is the most interesting part of the work. A useful privacy tool should not pretend that difficult judgments are simple. It should make the reasoning visible, show where the evidence is weak, and give developers a better place to start.