Continuous Improvement in Contextual DLP Validation

The hardest DLP problem is not detecting a credit card number. It is deciding whether “Jordan Smith” in a given request is a real patient in a healthcare record or a fictional character in a novel the user is analyzing. Structured patterns cannot make that call. Named-entity recognition alone cannot make it reliably. The call requires understanding what the surrounding text is about — not just what tokens appear in it.

This is Tier 3: contextual validation. The model reads the full request context, formulates a hypothesis about the candidate entity, and scores whether the context supports or rejects that hypothesis. High contextual confidence means enforcement. High contextual rejection means allow.

We have written about how contextual validation works in detail. This post is about what happened when we decided the existing model was not good enough — and what it took to build a replacement that is.

The Problem With Benchmark Performance

Standard benchmark test sets are drawn from the same distribution as the evaluation examples used to build them. Production traffic is not. Real AI requests have properties that benchmarks do not capture:

Adversarial phrasing. Users occasionally rephrase requests in ways that reduce the apparent sensitivity of the content — not necessarily with malicious intent, but as a natural consequence of how people communicate. “What’s the dosage for patient 00847291?” and “Dosage question — the patient ID is 00847291” carry the same PII but differ substantially in surface form.

Domain-specific context signals. Whether a name is PHI depends on whether the surrounding text contains medical, financial, or legal framing. “Dr. Casey Williams” in a clinical query is a provider identifier. “Dr. Casey Williams” in a history paper is a citation. The model needs to know which domain signals matter and which are noise.

Challenging edge cases. Some requests look exactly like a true positive but are not — or vice versa. “Patient name: Alex Johnson” looks like PHI framing. But if the full context is a developer writing a test fixture, it is not. Benchmark datasets undersample these ambiguous cases because they are difficult and expensive to label correctly. Production traffic is full of them.

The result was a model with strong benchmark metrics but meaningful error rates on the hardest real-world cases — the cases Tier 3 exists to resolve.

How We Improve Accuracy Over Time

Continuous accuracy improvement means systematically finding the cases where the current model underperforms — specifically, cases the model gets wrong — and using them to drive measurable improvements through iterative testing and evaluation cycles.

The process:

Step 1 — Baseline evaluation. Evaluate the current model against a broad set of enterprise AI request patterns. Flag cases where the model’s scores fall in a narrow confidence band — neither clearly enforce nor clearly allow. These are the cases where the model is uncertain.

Step 2 — Human review and labeling. The flagged examples go to a review pipeline. Reviewers with domain expertise — not crowdsourced annotators — examine each case and assign a ground-truth label: true positive (enforce), false positive (allow), true negative (allow), false negative (missed enforcement). The review guidelines are specific to compliance context: PHI, PII, CUI, financial data, and legal materials each have distinct criteria.

Step 3 — Identifying challenging edge cases. Beyond the uncertain cases, we actively identify examples where the model is confident but wrong. These are more damaging than uncertain cases because the model is not flagging them for review — it is making a committed wrong call.

Step 4 — Iterative improvement cycles. The reviewed examples — uncertain cases resolved by expert review plus challenging edge cases — inform subsequent improvement cycles. The process repeats until accuracy on the identified failure modes reaches the target threshold.

Evaluation Methodology

The evaluation methodology spans a wide range of entity types: personal identifiers, medical record numbers, payment card data, international identifiers, account numbers, dates, and content under access control. Coverage breadth matters because the distribution of difficult cases in the real world is long-tailed — the rarest and most challenging entity-context combinations require deliberate effort to evaluate reliably.

Coverage for underrepresented categories. Not every entity-context combination appears naturally in enterprise AI traffic at sufficient volume for thorough evaluation. For underrepresented categories — specialized healthcare identifiers, financial-legal hybrid content, and similar — additional test cases were constructed with controlled variation in phrasing, context framing, and co-occurring entities. These were reviewed by the same domain-expert pipeline as organic examples.

Challenging edge case construction. The most labor-intensive part of the evaluation methodology was constructing test cases for the entity types where the model performed worst. For each entity type with significant accuracy gaps, the team authored targeted counterexamples: requests that contain all the surface signals of a true positive but are actually benign (development test data, literary references, historical documents, template strings), and requests that lack obvious surface signals but contain genuine sensitive data in context.

Each challenging edge case was reviewed by two independent domain experts with reconciliation on disagreement. These cases have disproportionate impact on real-world accuracy because they directly address the model’s known failure modes.

Optimized for Production Inference

The model architecture was selected to balance accuracy against inference latency. A larger model produces slightly higher benchmark scores, but at a latency cost that is not acceptable in an inline DLP pipeline where every millisecond adds to AI request round-trip time. The selected model hits accuracy targets at inference speeds compatible with production deployment.

For the Hybrid Outpost deployment, the model runs via local inference — no external API call, no model hosting dependency, no data leaving the deployment boundary. The inference engine is optimized for the target data plane hardware at deployment time.

Results

After iterative testing and improvement cycles on the extended evaluation set, the improved model achieved substantially higher accuracy on the held-out evaluation set. The evaluation set was constructed independently — examples collected from a separate set of enterprise request patterns, reviewed by domain experts who had no visibility into the improvement process.

Reducing false positives in the mid-confidence band — the cases Tier 3 is specifically designed to resolve — means fewer blocked legitimate requests, fewer escalations to human review, and a DLP system that is operationally viable to operate at scale without significant noise.

False negative performance — the cases that matter most for compliance — improved in absolute terms and also moved in the correct direction relative to the false positive rate: the improved model maintains high detection sensitivity on true positives while reducing false positive pressure. This is the calibration target for regulated use cases, where the cost of missing a real detection is much higher than the cost of a blocked legitimate request.

The current contextual validator is the production Tier 3 engine in the Arbitex DLP pipeline. Its performance characteristics — accuracy, inference latency, and calibration behavior by entity type and compliance bundle — are available for review as part of the technical due diligence process.

Book a demo to see Tier 3 contextual validation in action on your AI traffic, or read the full DLP pipeline series for background on how Tier 1, Tier 2, and Tier 3 work together.