How a 3-Tier DLP Pipeline Stops Sensitive Data in AI Traffic
Most data loss prevention systems use a single detection method. Regex patterns catch structured data — credit card numbers, Social Security numbers, API keys — and miss everything else. ML classifiers catch unstructured entities but are expensive to run on every request. The result is either fast but incomplete, or thorough but slow.
The Arbitex Gateway uses a different approach: a 3-tier pipeline where each tier handles a different class of sensitive data, and cheaper checks run before expensive ones. The pipeline is sequential. Every request enters at Tier 1. Whether it continues depends on what the previous tier found.
This guide walks through the architecture — what each tier does, how they hand off to each other, and why the layered approach produces better results than any single method.
The Short-Circuit Principle
The most important design decision in the pipeline is not what each tier detects. It is when each tier stops.
If Tier 1 pattern matching finds a Luhn-validated credit card number, there is no reason to run NER or contextual validation on that request. The detection is structurally confirmed. The enforcement action — block or redact — fires immediately. The request never reaches Tier 2.
This short-circuit cascade is what makes the pipeline practical at scale. Running a transformer model on every request is computationally expensive. Running it only on the requests that cheaper methods could not resolve is efficient. In typical enterprise AI traffic, roughly 60–70% of detections are resolved at Tier 1. The remaining 30–40% proceed to Tier 2, and only a fraction of those escalate to Tier 3.
The result: Tier 3 inference costs are a fraction of what they would be in a flat architecture where every request hits the most expensive model.
Tier 1: Pattern Matching and Checksum Validation
Tier 1 runs 80+ pattern matching rules against every prompt and every response. These patterns target data with predictable structure: payment card numbers, government identifiers, routing numbers, API keys, authentication tokens.
What makes Tier 1 precise is not the pattern matching itself — it is the checksum validation layer on top. A 16-digit number that matches a card pattern but fails Luhn validation is not a credit card. A number that matches an IBAN format but fails checksum validation is not a bank account. Multiple checksum validators confirm structural validity before any enforcement action fires.
This matters because AI conversations are full of long numbers. Timestamps, reference codes, order numbers, mathematical expressions. Without checksum validation, a pattern-only system would flag a significant percentage of benign traffic. With it, false positives on structured data types are near zero.
Performance: Tier 1 runs in microseconds. No model inference, no GPU, no network call. It is a pattern matching engine with inline checksum validation. At this cost, it runs on every request — no sampling, no probabilistic skip.
What it catches: Structured PII — payment card numbers, government IDs, bank account numbers, credential strings, API keys. Anything with a predictable format and a verifiable checksum.
What it misses: Anything expressed in natural language. A patient name, a medical diagnosis, a street address, a financial narrative. These have no structural pattern for regex to match.
Tier 2: Named Entity Recognition
Every request that passes Tier 1 without a confirmed detection enters Tier 2. This is not conditional — even if Tier 1 found nothing, Tier 2 runs. The reason: a request can contain both structured data (caught at Tier 1) and unstructured entities (invisible to Tier 1) simultaneously.
Tier 2 uses a dual-engine NER stack: a rule-enhanced recognizer bridge with 40 entity recognizers, plus a GPU-accelerated NER model for context-aware entity detection. The two engines complement each other. The recognizer bridge is rule-enhanced and fast. The GPU NER model handles ambiguous entities where context determines whether a token is a person name, a place, or a generic word.
Each detected entity receives a confidence score. What happens next depends on that score:
- High confidence (above upper threshold): Enforcement fires immediately. The entity is confirmed with enough certainty that Tier 3 contextual validation would not change the outcome. Audit log written.
- Medium confidence (between thresholds): The entity is escalated to Tier 3. The candidate entity, its surrounding context window, and its confidence score are passed to the contextual validator.
- Low confidence (below lower threshold): No enforcement. The candidate is below the detection threshold and the request is allowed.
The threshold boundaries are not fixed. They are configurable per compliance bundle. A HIPAA bundle uses lower thresholds — more entities escalate to Tier 3 — because the cost of a missed PHI detection is higher than the cost of additional inference. A general-purpose bundle uses higher thresholds to reduce latency on non-regulated traffic.
What it catches: Person names, organization names, medical terms, financial entities, locations, dates tied to specific individuals — anything that NER models can identify as a named entity in natural language.
What it misses: Contextual sensitivity. Text that is sensitive because of what it means, not because of the entities it contains. A sentence about an upcoming acquisition contains no PII — but it may be material nonpublic information.
Tier 3: Contextual Validation
Tier 3 receives only the entities that Tier 2 flagged at medium confidence — the ambiguous cases where the NER engine was not confident enough to enforce and not confident enough to dismiss.
The validation uses an AI-powered contextual analysis model. For each escalated entity, the model evaluates a hypothesis: “The text contains [entity type] referring to a real individual/record.” The surrounding context is the premise. The model produces a contextual confidence score for each candidate entity.
If contextual confidence exceeds the configured threshold, the entity is confirmed. Enforcement fires. If the contextual analysis rejects the hypothesis, the entity is a false positive — a person name used in a fictional example, a date in a historical reference, a medical term in an educational context. The request is allowed.
This is where the accuracy gains come from. NER alone would either enforce on every medium-confidence entity (too many false positives) or allow them all through (missed detections). Tier 3 resolves the ambiguity using the linguistic context that NER cannot evaluate.
Per-entity confidence scoring: Every entity that reaches Tier 3 leaves with a composite score — the original NER confidence, the contextual validation confidence score, and the final disposition. This score is written to the audit log. When a compliance team asks “why was this entity flagged?” the answer includes not just what was detected but how confident the system was at each stage of the evaluation.
Isolated precision: In controlled evaluation against known-positive and known-negative entity datasets, the Tier 3 contextual validator is measured on precision. In pipeline context — where Tier 1 and Tier 2 have already resolved the definitive and high-confidence cases — Tier 3 handles only the genuinely ambiguous boundary cases, where its contextual analysis capability is most needed.
Health Monitoring and Graceful Degradation
Tier 3 runs as a GPU microservice. If that microservice becomes unavailable — hardware fault, memory error, inference timeout — the pipeline needs a fallback.
Health monitoring tracks consecutive failures. When the failure count exceeds the configured threshold, the pipeline activates a conservative fallback: Tier 3-escalated entities are enforced at their Tier 2 confidence score instead. This means more false positives during the degraded window — entities that Tier 3 might have dismissed as false positives are instead enforced. But no false negatives. No sensitive data slips through because the GPU service is down.
Recovery is automatic. Health monitoring resumes normal routing after the microservice passes its health check. The fallback activation, duration, and recovery are all observable via OpenTelemetry telemetry and visible in the Grafana dashboard.
Compliance Framework Mapping
Each compliance framework activates specific detectors and thresholds across all three tiers. This is not a checkbox mapping — it changes how the pipeline behaves.
PCI-DSS leans heavily on Tier 1. Card data has predictable structure and checksum validators. Tier 1 resolves most PCI-DSS detections definitively. Tier 2 and Tier 3 serve as backup for PANs embedded in formatted text.
HIPAA leans heavily on Tier 2 and Tier 3. Protected health information is mostly unstructured — patient names, diagnoses, clinical dates, provider relationships. The HIPAA bundle uses lower escalation thresholds to ensure more entities reach Tier 3 for contextual validation. The cost of a missed PHI detection outweighs the cost of additional inference.
GDPR activates EU-specific recognizers in Tier 2 — national ID formats, address patterns, phone number formats for EU member states. Tier 3 thresholds are lowered to reflect the EU enforcement posture on personal data protection.
SOX focuses on financial identifiers and access control enforcement. The policy engine works alongside DLP to ensure that AI requests involving financial reporting data are restricted by user role — not just by content detection.
When to Use Each Tier
The pipeline is automatic — you do not choose which tier runs on which request. But understanding the division helps when configuring compliance bundles and interpreting audit logs:
- Tier 1 is your first line for structured data. If your primary concern is payment card data, government IDs, or credential leakage, Tier 1 handles it with near-zero latency and near-zero false positives.
- Tier 2 is your coverage for unstructured entities. If your data contains names, medical narratives, financial text, or organizational references, Tier 2 is where those detections happen.
- Tier 3 is your precision layer for ambiguous cases. If your traffic includes educational content, fictional examples, or historical references that contain entity-like tokens, Tier 3 prevents those from being flagged incorrectly.
The three tiers together produce a pipeline that operates at the accuracy level of a contextual validation model while maintaining the throughput characteristics of a pattern scanner. That combination — accuracy sufficient for regulatory trust, throughput sufficient for production AI traffic — is what separates a DLP system that stays enabled from one that gets turned off because it is too slow or too noisy.
Learn more about the DLP pipeline or book a demo to see it running on your AI traffic.