How Automatic PII Detection Works - and Where It Fails

This article is for general informational purposes only and does not constitute legal advice. Regulatory requirements vary by jurisdiction and change over time. Consult a qualified legal professional for advice specific to your organization's circumstances.

Automated redaction tools have improved considerably. A paralegal reviewing a 200-page employment tribunal bundle can now run an AI detection pass and get a shortlist of suggested redactions in under a minute. That is genuinely useful. But the question that keeps coming up - in law firms, HR departments, and compliance teams - is whether you can trust the results.

The honest answer is: it depends on what the AI is doing, what document you're working with, and what's at stake. This guide explains the detection methods behind automated redaction tools, what they get right, where they fail, and the situations where no algorithm should be your last line of defense.

How automated PII detection actually works

Most redaction tools combine two or three distinct detection approaches. Understanding the difference matters because they fail in different ways.

Pattern matching and regular expressions

The most straightforward method. A pattern-matching engine scans text for sequences that follow a known format: US Social Security Numbers (nine digits in NNN-NN-NNNN format), email addresses, ZIP codes, phone numbers in standard formats. These patterns are written as regular expressions - essentially a template the engine checks each fragment of text against.

Pattern matching is fast, deterministic, and works without any AI component. SSNs, EINs, ABA routing numbers, IBAN codes - these are reliably detected by pattern alone. The failure mode is equally predictable: anything that deviates from the expected format gets missed. A phone number written as "555-867-5309" versus "5558675309" versus "+1 555 867 5309" requires separate patterns for each variant, and real documents use all of them.

Named entity recognition (NER)

**Named entity recognition** is the AI layer that handles information without a predictable format. Names, addresses, organization names, job titles - none of these follow a regex-matchable pattern. NER models are trained on large volumes of labeled text to learn what a person's name looks like in context, how addresses are structured, and how to distinguish "Chicago" as a place name from "Chicago Bulls" as an organization.

The NER model reads text in chunks and assigns each word or phrase a probability score for each entity category it knows about. High confidence that "Sarah Thornton" is a person's name. Moderate confidence that "Thornton" alone is a person name versus a place or surname used as a standalone reference. The tool can show these confidence scores so reviewers can focus attention on lower-confidence suggestions rather than re-checking every detection.

NER is more powerful than pattern matching but also less predictable. It's a model making probabilistic guesses, not a rule following a fixed logic. That distinction matters when you're responsible for the outcome.

Contextual analysis and transformer models

More advanced detection tools use encoder-based language models - the same underlying architecture that powers many modern AI assistants, applied specifically to the task of classifying text. These models are better at handling ambiguity because they read words in the context of surrounding sentences, not in isolation.

A basic NER model might flag every occurrence of "Victoria" as a person name. A contextual model reads the sentence and can infer whether "Victoria" is a woman's name in a letter, a geographic reference in an address, or a historical reference in a case document. Not perfectly - but substantially better than looking at the word in isolation.

This contextual awareness comes at a cost. These models are computationally heavier and either run slower in-browser or require sending extracted text to a server for processing. Browser-based tools that run everything locally have a ceiling on how sophisticated the model can be while remaining practical for everyday document sizes.

RedactProof's browser-based detection runs entirely on your device - no document upload needed. The Core plan uses on-device AI to detect 40+ PII types. For more complex documents, the Pro plan's Precision Engine sends extracted text (not the original file) to server-side AI for enhanced contextual analysis. See how RedactProof compares to other redaction tools for a fuller breakdown.

What AI gets right - and where it struggles

Automated detection is good at volume and consistency. A human reviewer going through a 500-page disclosure bundle will miss things - not through incompetence, but because attention degrades across repetitive material. AI doesn't get tired. It applies the same detection logic to page 1 and page 487.

AI detection performs reliably on:

• Structured identifiers - SSNs, EINs, passport numbers, credit card numbers, ABA routing numbers
• Email addresses and URLs that contain personally identifiable elements
• Full names in standard formats, particularly in salutations, signature blocks, and headers
• Dates of birth when clearly labeled (DOB:, Date of Birth:, Born:)
• Addresses in standard US postal format

Where automated detection falls short is more instructive:

• Initials and partial names. "J. Harrison" might be a client, a judge, a historical figure, or a company founder. Context can help but doesn't always resolve it.
• Partial addresses. "14 Elm Street" without a city or ZIP code may or may not be identifiable depending on document context. The AI can flag it; only you can decide if it's disclosable.
• Domain-specific identifiers. Unique reference numbers used by specific organizations, internal employee codes, case management system IDs - the AI has no way of knowing these are personally identifiable unless they follow a recognizable pattern.
• Contextual PII. A job title combined with a department name and organization can make someone identifiable even if no name appears. No automated tool reliably catches this.
• Scanned or low-quality PDFs. OCR introduces errors, and a mis-read character can break pattern detection entirely. "SSN: 123-45-6789" becomes undetectable if the scanner reads a digit incorrectly.

False positives and false negatives

Every automated detection tool produces both false positives (flagging something that isn't PII) and false negatives (missing something that is). The balance between them is a design choice, and different tools sit in different places on that trade-off.

A tool tuned for high recall (catches everything) will produce more false positives - flagging company names, product names, and place names that happen to match a person's name. A tool tuned for precision will miss more at the margins. Neither approach is wrong; they suit different use cases. High-stakes disclosures where a missed item is a data breach warrant high recall and the extra review burden. Lower-stakes bulk processing where speed matters more might tolerate higher precision.

Confidence scoring helps. When the tool shows you a score - say, 94% confidence this is a person name versus 61% - you can make informed decisions about how much review to apply. Treat the low-confidence suggestions as "worth checking" rather than "definitely redact." We've found that reviewers who understand confidence scores make better decisions than those presented with a binary flag/no-flag output.

When human review is non-negotiable

Automated detection is a first pass, not a final decision. There are document types and redaction scenarios where relying on AI output alone is not appropriate:

• Consumer data request responses (CCPA, HIPAA, or state privacy law). The decision about what to include, what to redact, and what to withhold under a valid exemption is a legal judgment that cannot be delegated to software. The AI can flag names and identifiers; a person must decide whether third-party exemptions apply.
• Legally privileged documents. Privilege is a legal concept, not a pattern the AI can detect. A document containing an attorney's advice on litigation strategy won't be flagged unless the privilege claim is embedded in clearly identifiable text.
• Court filings and FOIA responses. Regulatory frameworks set specific requirements for what must and must not be redacted. Getting either wrong - over-redacting material the other side is entitled to see, or under-redacting identifiers that must be removed - has procedural and legal consequences.
• Complex or non-standard documents. Handwritten notes, heavily formatted templates, tables with merged cells, or scanned files with OCR errors all degrade detection accuracy. The worse the quality, the more manual review is needed.

The risk is not that AI misses something obvious - it's the edge case that looks fine at a glance. A 12-digit account reference that happens to be a client's unique identifier. A staff member who can be identified from their job title and team, even without a name. These require domain knowledge the AI doesn't have.

How detection depth varies across RedactProof plans

RedactProof offers two levels of AI detection, reflecting the trade-off between data privacy and detection depth.

Free tier: pattern-based detection

The free plan uses pattern-matching detection: regular expressions for structured identifiers like SSNs, ZIP codes, phone numbers, email addresses, and credit card formats. Reliable for known formats. Misses names and unstructured PII.

Core plan: on-device AI detection

The Core plan adds a browser-based AI model that runs entirely on your device. No text or document content leaves your browser. It handles names, addresses, organizations, and other unstructured PII across 40+ entity types, with confidence scoring on each detection. Suitable for most everyday redaction tasks.

Pro and Team plans: Precision Engine

Pro and Team plan subscribers can use the Precision Engine, which sends extracted text (not the original file) to server-side AI for contextual analysis. The original document never leaves the browser - only the extracted text content is transmitted for inference. It's processed in-memory and is not stored or used for model training.

The Precision engine handles more complex contextual detection - ambiguous names, domain-specific entities, relationships between data points - and is suited to high-volume work or documents where standard detection misses too much. See our guide on how to redact a PDF for a step-by-step walkthrough of the redaction process itself.

Neither engine eliminates the need for human review in high-stakes disclosures. What they do is reduce the manual effort considerably and draw your attention to the areas of genuine uncertainty.

One thing detection quality doesn't solve

Even perfect detection fails if the redaction method itself is flawed. Overlay redaction - placing a black box over text without removing the underlying data - is the other half of the problem. It doesn't matter how accurately the AI detected the PII if a reviewer can copy-paste it out of the "redacted" document.

This is a separate issue from detection quality, but it's worth noting together because both failures have the same outcome: PII in a document that was supposed to be clean. Our guide on overlay versus pixel-burn redaction explains the difference and why permanent redaction methods matter.