Towards Contextual Sensitive Data Detection

This paper proposes a contextual data sensitivity framework that leverages type and domain contextualization to significantly improve sensitive data detection accuracy and reduce false positives compared to existing tools, as validated by experiments and expert case studies.

The Gist

Imagine you are a librarian in charge of a massive, open library where anyone can borrow books. Your job is to make sure that no one accidentally checks out a book containing top-secret military plans, a person's private diary, or a map to a hidden treasure.

For a long time, librarians used a very simple rule: "If a book has the word 'Name' or 'Address' on the spine, lock it up immediately."

This paper argues that this old rule is broken. It's too blunt. Sometimes a book says "Address" but it's just a list of public coffee shops (harmless). Other times, a book doesn't say "Secret" on the cover, but if you combine it with a map and a date, it reveals a secret military base (very dangerous).

The authors, Liang Telkamp and Madelon Hulsebos, propose a new, smarter way to check books using Context. They call this "Contextual Sensitive Data Detection."

Here is how their new system works, broken down into two main ideas:

1. The "Detect-Then-Reflect" Mechanism (Type Contextualization)

The Problem: The old system sees the word "Phone Number" and immediately screams, "DANGER! Lock it!" But what if that phone number belongs to a public bus company? It's not private at all. The old system creates too many "false alarms."

The New Solution: Think of this as a two-step security check.

• Step 1 (Detect): A robot scans the book and says, "Hey, this looks like a phone number."
• Step 2 (Reflect): Before locking it up, the robot pauses and looks at the whole book. It asks, "Is this a phone number for a person, or is it for a public bus line? Who is the author? What is the title?"

The Analogy: Imagine a bouncer at a club.

• Old Way: "You have a red hat? No entry!" (Even if it's a baby wearing a red hat).
• New Way: "You have a red hat? Okay, let me look at your whole outfit and see who you are with. Are you a VIP? Are you a baby? Okay, you can come in."

The Result: This method is much better at spotting the real dangers while letting the harmless stuff through. In their tests, it caught 94% of the real secrets (Recall) while making far fewer mistakes than commercial tools.

2. The "Retrieve-Then-Detect" Mechanism (Domain Contextualization)

The Problem: Some secrets aren't about names or addresses. They are about where and when something happens.

• Example: A list of hospital locations is usually fine. But if that list is for a war zone right now, it could get the hospital bombed. The data itself looks normal, but the context (the war) makes it dangerous.

The New Solution: The system doesn't just look at the book; it goes to the "News Desk" to check the current situation.

• Step 1 (Retrieve): The system asks, "What is happening in this region? Are there rules about sharing data here?" It pulls up specific guidelines (like "Do not share hospital locations in Conflict Zone X").
• Step 2 (Detect): It re-reads the book with those new rules in mind. "Ah, this hospital list is in Conflict Zone X. Even though it's just a list, the rules say it's dangerous. Lock it up."

The Analogy: Imagine a weather forecaster.

• Old Way: "It's raining. Wear a raincoat." (Always true, but maybe you're indoors).
• New Way: "It's raining, AND you are walking to a picnic. Wear a raincoat AND bring an umbrella." It checks the specific situation to give the right advice.

Why This Matters

The authors tested this with real data and even asked experts from the UN Humanitarian Data Centre (people who help during disasters) to review it.

• For Regular Data: The new system stopped flagging harmless public data as secret, saving time and reducing panic.
• For Humanitarian Data: It successfully identified dangerous data that standard tools missed because it understood the specific rules of war zones and disaster relief.
• For Humans: The system doesn't just say "Block this." It explains why, citing the specific rule it found. It's like a teacher who doesn't just give you an "F," but writes a note saying, "You failed because you didn't follow Rule 3."

The Bottom Line

The paper argues that protecting data isn't about finding specific keywords like "Password" or "SSN." It's about understanding the story the data is telling.

By using smart AI to look at the whole picture (Type Contextualization) and check the current situation (Domain Contextualization), we can keep our open data libraries safe without locking up everything that looks even slightly suspicious. It's a shift from a "guilty until proven innocent" approach to a "smart and fair" approach.

Technical Summary

1. Problem Statement

The proliferation of open data portals necessitates robust mechanisms to protect sensitive data before publication. However, existing detection methods suffer from two critical limitations:

• Insufficient Specificity (High False Positives): Traditional tools (e.g., Google DLP, Microsoft Presidio) rely on static type matching (e.g., flagging any "address" or "phone number" as sensitive). They fail to distinguish between harmless instances (e.g., a public organization's address) and truly sensitive ones, leading to high false positive rates.
• Insufficient Coverage (High False Negatives): Current methods focus almost exclusively on Personal Identifiable Information (PII). They fail to detect non-personal sensitive data that becomes risky due to external context (e.g., facility locations in conflict zones, military logs, or data that could harm vulnerable populations).

The authors argue that sensitivity is contextual, depending on how, by whom, and in what context data is used. They define Contextual Sensitive Data as data whose sensitivity depends on external factors and requires protection based on potential misuse scenarios.

2. Methodology

The paper proposes a framework built on two core concepts: Type Contextualization and Domain Contextualization. These are implemented via two distinct mechanisms using Large Language Models (LLMs).

A. Type Contextualization: The "Detect-Then-Reflect" Mechanism

This mechanism addresses the specificity problem by refining the assessment of data values that match known sensitive types (e.g., PII).

• Step 1: Detect: The system first identifies columns or values that match predefined sensitive types (e.g., email, name, address) using a classifier. This step prioritizes recall to ensure no potential sensitive data is missed.
• Step 2: Reflect: The system re-evaluates the detected candidates within the internal context of the entire document or dataset (e.g., table headers, surrounding columns, document semantics). The LLM determines if the value is actually sensitive given the broader context.
  • Example: An "Address" column is flagged in Step 1. In Step 2, the LLM analyzes the table title and other columns. If the table is a public directory of NGOs, the LLM classifies the address as "non-sensitive." If it is a private household registry, it is classified as "sensitive."

B. Domain Contextualization: The "Retrieve-Then-Detect" Mechanism

This mechanism addresses the coverage problem by assessing sensitivity based on external domain-specific factors (e.g., geopolitical rules, humanitarian policies).

• Step 1: Retrieve: The system queries an external corpus (e.g., Information Sharing Protocols, geopolitical news, data governance documents) to retrieve rules relevant to the dataset's domain or geographic origin.
• Step 2: Detect: The LLM assesses the data sensitivity by combining the input data with the retrieved external context.
  • Example: A dataset containing hospital coordinates is retrieved. The system fetches a policy stating that "facility locations in conflict zones are sensitive." The LLM then classifies the coordinates as sensitive based on this external rule, even if the data contains no PII.

3. Key Contributions

1. Conceptual Framework: Redefines sensitive data detection to include both internal context (type contextualization) and external domain context (domain contextualization).
2. Novel Mechanisms:
   • Detect-Then-Reflect: A two-stage pipeline that significantly reduces false positives for PII detection.
   • Retrieve-Then-Detect: A pipeline that grounds detection in external domain rules, enabling the identification of non-personal sensitive data.
3. Open-Source Implementation: The authors released code and annotated datasets (including 66 anonymized tables and 23 humanitarian datasets) to facilitate further research.
4. Human-in-the-Loop Validation: A case study with UN OCHA humanitarian experts demonstrated that context-grounded explanations (citing specific policy rules) are highly useful for manual auditing.

4. Experimental Results

The authors evaluated their framework against commercial baselines (Google Cloud DLP, Microsoft Presidio) and various LLMs (GPT-4o-mini, Gemma, Qwen) on tabular data.

Type Contextualization Results (PII Detection)

• Precision Improvement: The "Detect-Then-Reflect" mechanism significantly reduced false positives.
  • Baseline (Google DLP): Precision ~0.53, Recall ~0.63.
  • Qwen3 14B with Reflection: Precision 0.73, Recall 0.94.
  • GPT-4o-mini with Reflection: Precision 0.94, Recall 0.63.
• Key Finding: While baselines treat all matching types as sensitive, the reflection step correctly filters out non-sensitive instances, achieving a 94% recall (compared to 63% for commercial tools) while maintaining or improving precision.

Domain Contextualization Results (Humanitarian Data)

• Coverage & Explainability: Without external context, models were overly conservative (high recall, low precision). Integrating retrieved policy rules improved precision while maintaining perfect recall (1.0).
  • GPT-4o-mini: Precision improved from 0.47 to 0.69 (F1: 0.82) with domain knowledge.
  • Qwen3 14B: Precision improved from 0.56 to 0.64 (F1: 0.78) with domain knowledge.
• Qualitative Success: Human experts rated the LLM's ability to cite specific policy rules (e.g., "ISP guidelines on facility data") as highly informative for decision-making.

Efficiency

• Latency: The contextual pipelines are slower than rule-based tools (e.g., 1.2s–2.9s per column vs. 0.16s for DLP) but offer significantly higher accuracy. Smaller models (e.g., Qwen3 8B) offer a favorable trade-off for efficiency.

5. Significance and Conclusion

This work represents a paradigm shift from static, pattern-based detection to dynamic, context-aware detection.

• Practical Impact: It enables organizations to publish more data safely by reducing false positives (which currently block useful data) and increasing recall for non-personal sensitive data (which is currently overlooked).
• Scalability: The mechanisms are modality-agnostic and can extend to free-form text, though the current evaluation focused on tabular data.
• Future Direction: The paper highlights the need for diverse labeled datasets across different domains and languages to further refine these contextual models. It also suggests future work on automated remediation strategies once sensitive data is detected.

In summary, the paper demonstrates that leveraging LLMs for contextual reasoning and external knowledge retrieval is essential for the next generation of sensitive data protection in open data ecosystems.