Model-Based Detection and Verification

Models complement rules - they do not replace them

A named-entity recognition model - a small, specialized model trained specifically to spot things like person names, organizations, and postal addresses embedded in ordinary prose - can catch a meaningful category of sensitive content that plain regex genuinely struggles with, since names and addresses don't follow a fixed, predictable structural pattern the way an email address or phone number does. This general approach is often called model-based PII detection. It comes with real costs, though: added latency for every request, extra memory use for the model itself, the risk of behavior quietly drifting if the model version changes, and a meaningfully higher false-positive rate than a well-tuned regex - which is exactly why high-confidence deterministic patterns should still run first, catching the clear-cut cases cheaply before anything more expensive gets involved.

A practical, layered pipeline typically looks like this: normalize the incoming text first, apply the credential and structured-PII regex patterns from the previous section, optionally run a local entity-recognition model over whatever text remains unmatched, merge any overlapping spans the two methods both flagged, redact everything before the text goes anywhere else, and finally emit only safe, aggregate counts and categories - never the actual sensitive text itself - to any telemetry or monitoring system. One firm rule worth stating explicitly: never send genuinely sensitive text to a remote detection service without an approved data-processing agreement already in place - that would mean solving a data-leak problem by creating a brand-new one.

Analogy: Regex is a barcode scanner: extremely fast and reliable, but only for known, fixed shapes it was specifically built to recognize. A model is more like a trained clerk exercising judgment: better at handling context and ambiguity, but slower, and still capable of making a wrong call. Sensitive real-world workflows often deliberately use both together, leaning on each one's specific strengths.

Testing this pipeline thoroughly means covering every supported form you claim to handle, plus deliberate near-misses designed to probe the edges: confirm every planted canary value actually disappears from the output, confirm typed markers appear exactly where expected, confirm genuinely harmless-looking identifiers (like an ordinary order number) are correctly left alone rather than over-redacted, and confirm multiline or awkwardly-chunked input is still handled correctly. Two standard metrics summarize the trade-off precisely: precision measures how many of the masks you applied were actually correct calls, and recall measures how many of the real sensitive items present were actually found and caught.

Goal: Repair the output-stream filter so that email aliases, the various phone-number format variants, and API-key shapes are all correctly masked, while the harmless order number in the same test input remains untouched. This lab deliberately uses regex specifically because it's lightweight, fully local, and directly testable on the shared host, without needing a second model loaded at all.