What Happens to Your Data Before It Reaches the Model
Most AI governance conversations focus on what the model might do. The more immediate question is what data gets sent to the model in the first place.
When a user interacts with an AI-powered feature in your application, they might type a customer name, paste an invoice, reference an account number, or attach a file that contains medical information. They are not trying to create a data incident. They are using the product you built.
Your job — and the job of your governance infrastructure — is to catch what they send before it becomes a problem.
Protection is Stage 2 of the Arbitex Gateway pipeline. Every request that passes through Routing is inspected before it reaches any model. This is not a checkbox. It is a multi-layer process that runs on every call.
The Problem With “Just Check for PII”
The naive version of this looks straightforward: scan for patterns like credit card numbers and social security numbers. Flag them. Done.
The problem is that sensitive data does not always arrive in the clean, structured form that simple pattern matching expects. A support chat that says “my card ending in 4532” is not going to match a credit card pattern. A document summary request that includes “the patient, Jordan Smith, has a diagnosis of…” contains a person’s name — but pattern matching on names is famously difficult, because names are everywhere and context is everything. “Jordan Smith” in a patient intake form is PII. “Jordan Smith” in a discussion of The Great Gatsby is not.
The Arbitex inspection pipeline handles both ends of this problem: the structured (credit card numbers, account identifiers, API keys) and the unstructured (names, addresses, medical terms embedded in free text).
Three Layers of Inspection
The inspection pipeline works in sequence, with each layer handling what the previous one cannot.
Layer 1 — Pattern Recognition. The first pass uses 80+ detection patterns to find sensitive data that appears in predictable formats. Credit card numbers, social security numbers, bank account identifiers, API keys, and similar structured data all have formats that can be reliably detected. Where the format alone is not enough — a 16-digit number could be a card number or an order ID — checksum validation confirms whether the number is structurally valid for the format claimed. A Luhn checksum (a checksum algorithm that validates card numbers are structurally real) on a candidate card number tells you whether it is a real card number or a coincidental match. This dramatically reduces false positives on high-volume, structured data.
This layer is fast. Pattern checks run in microseconds. A request that contains an unambiguous card number or SSN is resolved here, and the more computationally intensive layers are not invoked.
Layer 2 — Entity Recognition. The second layer handles sensitive data that does not have a predictable format: names, addresses, phone numbers, dates of birth, medical record numbers, financial account identifiers in free text. This layer uses named entity recognition (NER — AI that identifies people, places, and sensitive terms) to read the request as language, not as a pattern to match, and identify what it contains.
NER operates across 40 recognizer types. It is the layer that catches “please summarize this record for Morgan Lee, DOB 1974-03-12, MRN 0038271” — content that has no checksum and no structured format, but is clearly patient PII.
Layer 3 — Context Evaluation. Some detections are ambiguous. A name that triggers the NER layer might be a real person’s name in sensitive context, or it might be a literary character, a common noun, or a test fixture. Getting this wrong in either direction has consequences: miss real PII and you have a data incident; flag clean content and you have an unusable governance system that blocks legitimate work.
The third layer evaluates ambiguous cases against their surrounding context. A language model trained for this purpose reads the full request and determines whether the flagged entity is being used in a sensitive context or not. The same name “Jordan Smith” scores very differently in a patient summary than in a literature discussion. This is the layer that makes that distinction.
Inspection Runs in Both Directions
One detail that is easy to overlook: Protection applies to model responses as well as requests.
Models can include sensitive data in their responses. They might summarize a document that contains PII. They might be prompted to produce a report that includes data the organization intended to keep internal. Inspecting only the inbound prompt and passing the response through uninspected is incomplete governance.
Arbitex inspects both sides of every call. Detection at either end triggers the same policy-driven action: block, redact, or log.
What Happens When Something Is Found
When the inspection pipeline detects sensitive data, the response is determined by policy — not by a default behavior.
- Block — the request is stopped before it reaches the model. The user receives a response indicating the request was blocked. The event is logged.
- Redact — the sensitive field is replaced with a placeholder (for example,
[SSN-REDACTED]), and the sanitized request is forwarded to the model. The user gets a response. The detection is logged. - Log — the detection is recorded, but the request proceeds unmodified. Useful for monitoring without enforcement, typically in an initial deployment phase.
The enforcement action for each type of sensitive data is configured in the policy engine — Stage 3, covered in Part 3 of this series. Protection is the detection layer. Control is where you decide what to do about what was found.
What Compliance Frameworks Mean Here
Arbitex ships with pre-built configurations for 12 compliance frameworks including PCI-DSS, HIPAA, GDPR, GLBA, SOX, CCPA, BSA/AML, SEC Reg FD, FERPA, EU AI Act, NIST AI RMF, ISO/IEC 42001. Activating a framework does not just enable a set of patterns — it configures the entire inspection pipeline to detect and act on the data types that framework protects, with enforcement actions calibrated to what each framework requires.
For a healthcare organization activating the HIPAA configuration: patient names, dates of birth, medical record numbers, and associated identifiers are detected across all three inspection layers. Requests containing that data are blocked or redacted per policy, and every detection is logged with the regulatory reference that triggered it.
The compliance framework configuration is a starting point. Organizations with specific requirements can extend it with custom rules in the policy engine.
What Protection Is Not
It is not a security information and event management (SIEM) system. It does not correlate events across systems or investigate historical incidents. It is a real-time, in-path inspection layer that operates on every request as it passes through.
It is also not complete governance on its own. Inspection tells you what is in a request. The policy engine — Stage 3, Control — defines what to do about it. The audit log — Stage 4, Visibility — records what happened. Protection is one stage in a four-stage pipeline.
Part 3 in this series covers Control — how the rules your security team defines translate into deterministic governance on every AI call.
Control — how Arbitex enforces your policies →