PII Removal: Detection, Redaction, and Privacy Preservation

Training a language model on raw web text means training it on the personal details of real people. Email addresses scraped from public forums, phone numbers embedded in product reviews, medical complaints posted under pseudonyms, and home addresses listed in contact pages all flow into pre-training corpora without any filtering. Unless you actively remove this material, your model will memorize it. When a user later prompts the model in just the right way, it will reproduce a stranger's phone number or Social Security number verbatim. This is not a theoretical concern: researchers have demonstrated that large models trained on web crawls can be induced to emit exact training examples including real names, email addresses, and phone numbers from the original dataset.

The memorization behavior is not a bug introduced by a particular architecture choice. It is a natural consequence of how language models are trained. A model that sees the string "John Smith's SSN is 412-78-9021" enough times, or in a sufficiently prominent context, will associate the pattern of "John Smith" with "412-78-9021" in its weight space. With the right prefix, the model will complete the pattern by generating the memorized number. Research by Carlini et al. (2021) showed that large GPT-style models trained on internet text could reproduce verbatim training examples at rates that increased with model scale and with the number of times an example appeared in the training data. Removing PII before training is the direct countermeasure.

Personally Identifiable Information, or PII, refers to any data that can uniquely identify an individual or be combined with other information to identify them. The legal frameworks that govern PII are partly determined by jurisdiction: GDPR in Europe, CCPA in California, and a patchwork of sectoral laws elsewhere. But the core concern is universal. People did not consent to their personal information being absorbed into model weights where it can be retrieved indefinitely. Removing PII from training data is both an ethical obligation and increasingly a legal requirement for organizations deploying models commercially.

The challenge is that PII is not cleanly labeled in web text. It appears in unpredictable formats, in the middle of otherwise valuable prose, embedded in HTML markup, or disguised by partial redaction. You cannot simply scan for well-formatted strings. You need a detection system that is both precise enough to avoid false positives (removing legitimate content) and sensitive enough to catch personal information across its many forms. The tension between these two requirements drives almost every design decision in a PII pipeline.

Building on the deduplication and quality filtering techniques from earlier in this part, PII removal is the final scrubbing step before data enters the training pipeline. While deduplication removes redundant documents and quality filters exclude low-value text, PII removal specifically targets the privacy risk in the text that remains. The next chapter on data mixing then takes the cleaned, filtered, and deduplicated corpus and combines it in proportions calibrated for downstream task performance.

PII spans a wide range of information types, and the definition differs depending on context and intended use. The same piece of information can be PII in one context and not in another. A person's name on a public patent application is not sensitive. The same name in a document that also includes their medical condition and home address creates a combination that is unambiguously sensitive. This context-dependence is one reason why PII removal is harder than it appears.

Legal frameworks slice this problem in different ways. GDPR defines personal data broadly as any information relating to an identified or identifiable natural person, where "identifiable" includes someone who can be identified by reference to an identifier like a name, an identification number, location data, an online identifier, or one or more factors specific to that person's physical, physiological, genetic, mental, economic, cultural, or social identity. CCPA takes a similar approach, defining personal information as information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked with a particular consumer or household. Both frameworks are deliberately expansive because the goal is to protect privacy in the real world, where re-identification attacks can combine apparently innocuous fields.

For the practical purposes of training data processing, most practitioners organize PII into four main categories.

The most commonly targeted categories in NLP training pipelines include:

• Direct identifiers: Information that uniquely identifies a person on its own, including full names, email addresses, phone numbers, Social Security numbers, national ID numbers, passport numbers, credit card numbers, and bank account numbers.
• Quasi-identifiers: Information that identifies a person only when combined with other attributes, such as zip codes, birth dates, job titles, employer names, and IP addresses.
• Sensitive categories: Information that, while not always identifying, carries heightened privacy risk, including health conditions, biometric data, religious beliefs, political opinions, sexual orientation, and immigration status.
• Location data: Home addresses, GPS coordinates, and named places associated with a specific individual.

The distinction between direct and quasi-identifiers matters for choosing detection strategies. Direct identifiers follow predictable patterns and respond well to regex or rule-based detection. Quasi-identifiers require context: a zip code in a census table poses no privacy risk, while the same zip code in a sentence like "the patient from 94102 was admitted on..." links to a specific person when combined with the other details.

The k-anonymity framework from the privacy literature formalizes quasi-identifier risk: a dataset satisfies k-anonymity if every combination of quasi-identifier values appears in at least k records. Below this threshold, individual records can be isolated and the corresponding person identified. This framework is useful for thinking about corpus-level risk even when you cannot compute exact k-anonymity for a web crawl.

In practice, most PII removal pipelines focus on direct identifiers because they are both the most automatable and the highest-risk. Names are the notable exception: they are technically direct identifiers but they are also extremely common in legitimate text and extremely difficult to remove without destroying the document's usefulness. A chapter about the signing of the Declaration of Independence cannot remain useful if every person name is redacted.

Detection is the hardest part of PII removal. False negatives leave PII in the data; false positives remove legitimate content and reduce corpus quality. The right balance depends on the use case, but training data for general-purpose language models typically prioritizes recall (finding as much PII as possible) over precision (not removing non-PII). The reason for this asymmetry is straightforward: a false negative exposes a real person's private information to indefinite memorization, while a false positive merely removes some text that would otherwise help the model learn a pattern.

Three broad families of detection methods are used in practice, often in combination. Each has a natural domain where it excels and a domain where it fails, so production systems layer them together to achieve coverage that no single method provides.

Pattern matching uses regular expressions and string heuristics to identify PII that appears in well-defined formats. This is the fastest and most interpretable approach, and it works reliably for structured PII categories where the surface form is constrained.

Pattern-based detection works well for:

• Email addresses (the format local@domain.tld is highly constrained by RFC 5321)
• Phone numbers (10-digit US numbers with various separators, international prefixes following ITU-T E.164)
• Social Security numbers (the format NNN-NN-NNNN with known invalid area numbers)
• Credit card numbers (16-digit sequences matching Luhn checksums, with BIN prefixes identifying card networks)
• IP addresses (four octets in 0-255.0-255.0-255.0-255 format)
• URLs (RFC 3986 syntax)
• Dates of birth (various calendar formats in combination with contextual cues)

The design of good PII regex patterns involves several layers. The first layer is the structural pattern itself, capturing the general format. The second layer is validation logic, typically implemented as lookaheads and lookbehinds within the regex or as a post-match filter, that excludes known-invalid values. For Social Security numbers, this means excluding area numbers 000 and 666, numbers in the 900-999 range (reserved for the Enumeration at Birth program and Individual Taxpayer Identification Numbers), and the famously-advertised number 078-05-1120 that appeared on a wallet insert in the 1930s and was used by hundreds of thousands of people who found it in their wallets. These exclusions are not theoretical: they prevent false positives on these specific strings.

Pattern-based detection fails when formats are non-standard or when legitimate text matches the pattern. The string "1-800-FLOWERS" matches a phone pattern. The sequence "555-12-3456" looks like a Social Security number but has the wrong digit grouping structure. A good regex library handles many edge cases but cannot achieve perfect precision. The deeper issue is that regular expressions capture syntax, not semantics. A format-valid SSN in a training text about tax policy is very different from a format-valid SSN in a sentence containing a person's name, but the regex cannot distinguish them.

The standard approach is to build a layered regex system where the initial broad pattern is refined by a secondary validation step. For credit card numbers, the structural match identifies candidate 16-digit sequences, and a Luhn checksum verification step eliminates roughly 90% of false positives since random digit strings only satisfy the Luhn check about 10% of the time. For phone numbers, area code validation against the NANPA (North American Numbering Plan Administration) database eliminates area codes that have never been assigned.

The computational cost of pattern-based detection is very low. Compiled regex patterns process millions of characters per second, making it practical to scan entire web crawls on a single machine. This cost advantage means pattern-based detection is always the first layer in any hybrid pipeline: run it first, remove the obvious hits, and send the remainder to more expensive methods.

Named Entity Recognition (NER) models identify named entities in text by classifying tokens as names, organizations, locations, and other categories. For PII detection, the most relevant entity types are PERSON (full names and partial names), ORG (organization names that might appear alongside an individual's role), GPE (geopolitical entities, useful for location context), and EMAIL or PHONE in models that include those entity types.

Pre-trained NER models like spaCy's en_core_web_lg or the fine-tuned models available through HuggingFace handle PERSON detection with F1 scores in the 0.85-0.92 range on benchmark corpora such as CoNLL-2003 and OntoNotes. Performance drops significantly on noisy web text where names appear without grammatical context, mixed with symbols, or in non-standard capitalization. A name like "xJohnSmithx" in a username context will be missed by models that rely on whitespace tokenization and title-case cues.

The core strength of NER over regex is that it handles names. Names have no reliable format. "John Smith", "JSmith", "J. Smith PhD", and "smithj" all refer to the same person but only a model with contextual understanding can recognize them as names. NER uses the surrounding text to make this judgment: a token that appears after "my name is" is likely a name even if it is not in any known-names dictionary. This contextual sensitivity is what distinguishes NER from any dictionary or gazetteer-based approach.

Modern transformer-based NER models, particularly those built on BERT-style encoders, achieve stronger performance than the LSTM-CRF models that dominated the field before 2018. A fine-tuned RoBERTa-based NER model on CoNLL-2003 English reaches F1 scores above 0.93, compared to about 0.87 for the spaCy English large model. However, the computational cost scales with model size. Running BERT-large inference over a 100-billion-token corpus requires substantial GPU time that a regex sweep does not.

The core weakness of NER is that it requires a model inference pass over every document in the corpus. It also struggles with ambiguous tokens. "Jordan" can be a person, a country, or a brand. "Apple" can be a person's nickname, a fruit, or a company. "Washington" can be a person, a city, or a state. NER models resolve these ambiguities by context but make errors that compound at scale. In a corpus of 100 billion tokens, even a 1% error rate on PERSON classification produces a billion incorrect decisions.

Beyond named-entity recognition, specialized machine learning classifiers can identify PII categories that do not map cleanly to named entity types. The standard NER taxonomy covers persons, organizations, and locations, but it does not include medical diagnoses, account numbers, immigration status, or biometric data. These categories require classifiers trained specifically on examples from the relevant domain.

Specialized classifiers are deployed for several purposes in production PII pipelines:

• Medical information classifiers trained on clinical note corpora to identify diagnoses, medication names, dosages, and clinical measurements that could re-identify patients
• Financial document classifiers for account numbers, routing numbers, IBAN codes, and financial statement figures that appear with an associated individual
• Social Security and national ID number classifiers that use contextual signals beyond format matching, identifying strings like "taxpayer ID" or "government number" before numbers that might not be format-valid SSNs
• Multi-label classifiers that identify co-occurring PII types in a single document and can flag documents for complete removal when multiple categories are present together

Modern transformer-based classifiers fine-tuned on privacy-labeled datasets significantly outperform both regex and general-purpose NER for domain-specific PII. A classifier trained on 50,000 annotated clinical notes will outperform a general NER model on medical text by 15-25 F1 points because it has learned the lexical patterns and sentence structures common to clinical documentation. The investment in fine-tuning pays off quickly when processing large domain-specific subcorpora.

The trade-off is training data. Building a high-quality PII classifier requires annotated examples, which are themselves privacy-sensitive and often unavailable publicly. Most practitioners either use synthetic annotation (generating fake PII and embedding it in real documents, then using the known insertion positions as labels) or purchase access to labeled datasets from privacy compliance vendors who have assembled annotated corpora under appropriate legal agreements.

A third approach is self-supervised annotation: use the regex pipeline to generate high-confidence labels for format-detectable PII and train a classifier to generalize to harder cases. For email addresses, regex can label nearly all examples correctly, and a classifier trained on these labels learns contextual features that allow it to catch email-like strings that fail the strict regex check (like "contact me at first.last AT company DOT com" written to defeat automated scraping).

Production PII detection systems combine all three approaches into a layered pipeline. No single approach achieves both the precision and recall needed for large-scale training data processing. Regex misses names and context-dependent PII. NER misses format-structured identifiers in noisy text and domain-specific PII categories. Specialized classifiers are expensive and may not cover all necessary domains. Combining them in a layered architecture gets close to the necessary coverage.

A typical production architecture proceeds through several stages. Regex patterns run first as a cheap, high-recall pass over the entire document, flagging known-format PII with near-certainty. This layer catches all email addresses, well-formatted phone numbers, SSNs, and credit card numbers that satisfy structural validation. NER models run on the regex-cleaned text to catch names, partial identifiers, and contextual PII that regex cannot detect. The NER layer is the most computationally expensive per-document and benefits significantly from batching: processing documents in batches of 32-128 allows the GPU to parallelize inference efficiently. Specialized classifiers handle domain-specific categories like medical or financial information, and they typically run only on documents that match certain domain indicators (the presence of clinical vocabulary, financial terminology, or geographic localization patterns).

Each layer hands off its findings to a central resolution module that aggregates span annotations, resolves overlaps (a span cannot simultaneously be two entity types), and applies redaction. When a person name detected by NER overlaps with an email address detected by regex, the longer span takes precedence because it captures more of the original text.

The pipeline is designed so that later, more expensive layers only process documents that passed earlier filters. Documents from domains with low prior probability of medical PII skip the clinical classifier entirely. This triage-based design reduces total compute by processing expensive layers only where they are needed.

The order of operations also affects recall. Running NER on the original text before applying regex redaction is important for entities that span across text containing format-structured PII. For example, "Sarah Thompson (s.thompson@healthcare.org)" contains both a PERSON entity and an EMAIL entity. If you apply email redaction first, you get "Sarah Thompson ([EMAIL])", and the NER model may detect "Sarah Thompson" correctly. But the underlying text still contains the original name, so you need to apply all detectors to the original text rather than to each other's output.

Once PII is detected, you must decide what to do with it. The options form a spectrum from aggressive to conservative, with different consequences for downstream model quality. The choice of strategy interacts with the choice of detection method: a high-recall detector with a conservative strategy (placeholder replacement) may produce better outcomes than a moderate-recall detector with an aggressive strategy (document removal), because you preserve more documents while still removing the most dangerous content.

The most common strategy replaces detected PII spans with generic placeholder tokens. Email addresses become [EMAIL], phone numbers become [PHONE], person names become [NAME]. The surrounding text remains intact with only the PII replaced.

Placeholder replacement preserves the syntactic structure of the original sentence. A model trained on "Please contact [EMAIL] for the invoice" learns valid sentence patterns, the pragmatics of how contact information is requested, and the linguistic context around email addresses, without learning any specific email address. This is the dominant approach in practice because it balances privacy protection with data utility. The redacted text is still useful for learning language, even if it cannot be used to identify individuals.

The choice of placeholder token matters for downstream tokenization. If the placeholder is a rare token or an out-of-vocabulary string, the model's tokenizer may fragment it into many subwords, adding noise to the learned representation. Using placeholder tokens that are single vocabulary items, or adding them as special tokens in the vocabulary, produces cleaner training examples. The Pile dataset, for example, used the token <|pii|> as a placeholder, adding it as a special token to the vocabulary so it would never be split during tokenization.

A refinement is to use type-specific placeholders so the model learns that different PII categories appear in different contexts. [EMAIL_ADDRESS] for emails, [PHONE_NUMBER] for phones, and [PERSON_NAME] for names lets the model distinguish between "contact [EMAIL_ADDRESS] to schedule" and "speak with [PERSON_NAME] in room 302", which have different semantic implications even though both contain PII. Type-specific placeholders also preserve useful syntactic patterns: the model learns that [EMAIL_ADDRESS] typically appears as an object of contact verbs and as a string inside angle brackets in email headers, while [PHONE_NUMBER] appears after "call" or "fax" or in formatted contact blocks.

The main limitation of placeholder replacement is that it introduces tokens that will appear in the training data but not in most real-world text the model will process at inference time. A model that has learned "speak with [PERSON_NAME] in room 302" as a training example may generalize the pattern correctly to "speak with Dr. Chen in room 302" at inference time, or it may not, depending on how the placeholder token is represented in the embedding space. Using widely-used placeholder tokens that are already in the model's vocabulary helps bridge this gap.

Redaction removes the PII span and replaces it with nothing, or with a short indicator like REDACTED or ****. The resulting text may be grammatically incomplete, since the original sentence may have relied on the PII token for subject-verb agreement or pronoun resolution. "The report was submitted by REDACTED" is less natural than "The report was submitted by [NAME]", but both obscure the actual person.

Redaction is common in legal and government document processing where the goal is to match the appearance of physically redacted paper documents. Legal practitioners and government agencies have decades of experience with REDACTED as a marker, and their downstream readers understand what it means. For training data preparation, placeholder replacement is generally preferred over redaction because it maintains grammatical structure better and produces text that a language model can learn from without the spurious REDACTED token appearing everywhere.

One context where redaction is appropriate is when the PII is part of a URL, filename, or other structured string where placeholder insertion would break the format. The URL https://patient-portal.hospital.org/records/JOHN-SMITH/download contains a name in a structured position. Replacing "JOHN-SMITH" with "[NAME]" produces a valid-looking URL that may confuse a model that has learned URL syntax. Removing the path segment entirely produces a less informative but structurally valid URL.

When PII is so dense in a document that removing it would destroy the document's semantic coherence, the correct action is to remove the entire document rather than attempt inline redaction. A contact list, a roster of employees with personal details, or a thread where users repeatedly share identifying information about themselves or others will produce heavily redacted text that provides little useful signal to the model.

Consider a comment thread on a local community forum where users post their names, addresses, and phone numbers to coordinate a neighborhood meeting. After PII removal, the document might look like: "[NAME] at [ADDRESS] says [PHONE_NUMBER] works for me, or [NAME] at [ADDRESS] could host if [PHONE_NUMBER] calls first." This text teaches the model almost nothing useful about language while still potentially containing some residual identifying information. Document removal avoids this outcome by treating the document as non-salvageable.

Document-level removal decisions are typically rule-based: if more than some threshold fraction of tokens are redacted PII spans, remove the document. The threshold is calibrated empirically against a validation set of documents, with a human reviewer checking that documents near the threshold are appropriately classified. Values in the range of 5-15% PII token density are common triggers for document-level removal, depending on how aggressively the pipeline values corpus completeness versus privacy protection.

An alternative trigger for document removal is the presence of certain PII types regardless of density. A document containing a credit card number or a Social Security number is almost certainly not the kind of text you want in a general-purpose training corpus, regardless of what fraction of the document that number occupies. These categories can trigger document removal directly without a density threshold.

Pseudonymization replaces real PII with synthetic but realistic alternatives. Instead of replacing "John Smith" with [NAME], the pipeline substitutes a different real-sounding name like "Robert Chen". Instead of replacing a real email with [EMAIL], it substitutes user4921@example.com. The result is text that reads naturally and contains names and contact information in the positions where the original contained them.

Pseudonymization preserves the realism of the training text at the cost of more complex processing. A model trained on pseudonymized data learns natural name patterns, the syntactic positions where names appear, and coreference patterns (the same name appearing multiple times to refer to the same entity) rather than learning that [NAME] appears in name-bearing contexts. This is particularly valuable for tasks where learning name syntax matters, such as dialogue summarization or structured information extraction.

The challenge is ensuring consistency: if "John Smith" appears ten times in a document, all occurrences must be replaced with the same pseudonym, or the model learns incoherent coreference patterns. A coreference resolution module must first identify all mentions of the same entity and then apply a consistent replacement. The coreference step adds complexity and potential for error: "John" alone and "Mr. Smith" alone and "John Smith" in full may all refer to the same person and must be linked before pseudonymization.

Pseudonymization also requires a synthetic data generation component that can produce realistic fakes for each PII category. Name lists for common first and last names in the relevant language are widely available. Random email generators that combine realistic-looking usernames with common domain names are straightforward. Phone number simulators that produce numbers in valid format ranges are also simple. More complex categories like medical record numbers or national ID numbers with embedded checksum constraints require format-aware generation that can produce checksum-valid synthetic values.

The consistency requirement also applies across documents in the same corpus. If your corpus contains multiple documents from the same forum, and "johnsmith42" appears as a username across all of them, pseudonymization must either replace all occurrences with the same pseudonym or replace each occurrence independently. The former approach better preserves coreference but requires a cross-document identity resolution step that is computationally expensive at corpus scale.

Evaluating PII removal is harder than evaluating most NLP tasks because the ground truth is inherently private. You cannot publish a labeled dataset of real PII without defeating the purpose. Evaluation therefore relies on synthetic test sets, held-out annotated samples, and indirect metrics. Each approach captures different aspects of the pipeline's performance, so a complete evaluation uses multiple complementary methods.

The most common evaluation approach generates a synthetic test set by embedding fake-but-realistic PII into real or synthetic document text. The PII is generated to cover the target categories (email, phone, name, and so on) and to appear in diverse contexts: mid-sentence, at the start of a document, in structured tables, in informal prose, and in multi-line addresses. The diversity of contexts matters because many PII detectors perform well on clean prose but fail on noisy or structured formats that appear frequently in web crawls.

Precision and recall are computed in the usual way. Precision measures the fraction of detected spans that are PII, catching the rate at which the pipeline flags legitimate content. Recall measures the fraction of true PII that the pipeline detects, showing how much PII leaks through. These two quantities are in tension: a detector that flags everything achieves perfect recall but terrible precision. A detector that flags nothing achieves perfect precision on an empty detection set but terrible recall.

The F1 score combines these into a harmonic mean, but the F1 score conceals the asymmetry in the costs of false positives and false negatives for privacy applications. A missed SSN (false negative) is much worse than a falsely flagged date (false positive). For training data PII removal, the desirable operating point strongly favors recall over precision. Recall values above 0.95 are typical targets, with precision accepted as low as 0.80-0.85. This means you are willing to erroneously remove some legitimate text in exchange for catching nearly all real PII.

Synthetic test sets have a known limitation: the PII they contain was generated to be detectable by the methods you used to design the test. If your evaluation uses the same templating approach as your training data, you may overestimate performance on the distribution of PII found in web text. Wild-web PII is more diverse in format, context, and language than any synthetic test set can capture. A good evaluation supplements synthetic test sets with held-out samples from the source corpus, annotated by human reviewers under controlled privacy conditions.

A stronger evaluation uses canary sequences: carefully crafted strings that are inserted into the training data and then searched for in the model's outputs. If the canary can be extracted from a trained model, it demonstrates that the model memorized the training example containing it. This technique, introduced by Carlini et al. (2019), directly measures what PII removal is trying to prevent.

For PII removal evaluation, the canary test adapts as follows. Known PII-containing documents are processed by the PII removal pipeline, and a model is trained on the processed corpus. At evaluation time, the model is prompted with partial contexts that surrounded the original PII and checked whether it completes with the original private information. If the pipeline missed the PII and it remained in training data, the model may reproduce it. If the PII was correctly removed and replaced with a placeholder, the model should complete the prompt with the placeholder rather than the original value.

The extraction success rate is measured as the fraction of canary prompts for which the model reproduces the original PII within its top-k completions for some value of k. A lower extraction rate indicates better PII removal. The test is typically run with k values of 1 (exact greedy completion), 10, and 100 to capture both highly confident memorization and probabilistic memorization.

Canary extraction tests are expensive because they require training a model, but they directly measure the privacy risk that PII removal is meant to prevent. They also catch systematic failures that synthetic precision-recall evaluation misses: if the pipeline fails on a specific writing style or document format that was well-represented in the training data, canary tests will reveal this because the model will have memorized those documents and can reproduce them under extraction.

A variant of the canary test, proposed in research on differential privacy auditing, uses membership inference rather than exact extraction. A membership inference attack attempts to determine whether a given document was in the training set by measuring the model's behavior on that document relative to similar non-training documents. Successful membership inference for PII-containing documents indicates that those documents' content influenced the model's weights, which is the mechanism through which PII becomes extractable.

A complementary approach uses membership inference attacks to estimate how much information about individual training examples survives in model weights. A successful membership inference attack can distinguish, better than chance, whether a given document was in the training set. When applied to documents containing PII, this measures how much the PII contributed to memorization.

Membership inference is an indirect measure of PII removal quality. A pipeline that removes PII successfully should reduce the memorization signal for those documents, making membership inference harder. If membership inference success rates remain high after PII removal, the pipeline is not effectively reducing privacy risk, even if it achieves high recall on synthetic precision-recall benchmarks. The persistence of the memorization signal despite PII removal can indicate that the pipeline is removing the explicit identifiers but leaving enough co-occurring context to still uniquely identify documents in the training set.

The practical use of differential privacy auditing is to set a target: after PII removal, the membership inference advantage for PII-containing documents should be no higher than for clean documents. If it is higher, the PII removal pipeline is not doing its job. This target provides a quantifiable goal that precision-recall metrics cannot capture directly.

For the structured PII categories detectable by regex (email, phone, SSN), accuracy can be evaluated programmatically without requiring annotated test data. A post-processing check scans the output corpus for known-format PII patterns and reports the fraction remaining. This is not a complete evaluation because it cannot check for names or contextual PII, but it provides a fast, cheap sanity check that the regex layer is functioning correctly after any pipeline changes.

A practical approach is to run the regex scan on a random 1% sample of the processed corpus and report the residual PII rate per category. If the email residual rate is above a threshold, it indicates a bug in the pipeline (perhaps a regex that was recently updated and introduced a regression) rather than a fundamental limitation. This check should run automatically as part of every pipeline deployment to catch accidental regressions before they affect the full corpus.

Let's build a practical PII detection and redaction pipeline for text corpora, covering pattern-based detection, NER-based name finding, evaluation on synthetic examples, and visualizations that reveal how the pipeline performs.

We start with the libraries needed for pattern matching, NER, and evaluation.

These data classes track each detected PII span with its character offsets, type, and original text. The PIIResult pairs the original document with the redacted version for comparison. Using character offsets rather than token offsets makes the pipeline independent of any particular tokenizer, which matters because the regex layer runs before any tokenization step.

The regex layer covers PII categories with well-defined formats. Each pattern is compiled once and applied across all documents. Compiling the patterns at module load time rather than inside the detection function avoids repeated compilation overhead when processing large corpora.

Each PII type is correctly flagged, and the clean sentence produces no detections. The credit card pattern matches the Visa card number (beginning with 4) but would not match an arbitrary 16-digit string because the BIN prefix constraint requires a specific leading digit for each card network.

For personal names, we use a pre-trained spaCy NER model. Names detected as PERSON entities become NAME PII spans. The spaCy model processes the text as a single document, tokenizing it, applying part-of-speech tagging, and then running the NER model, which uses the full sentence context to classify each token.

The NER model detects personal names from context. The third example demonstrates that "Apple" is correctly classified as an organization rather than a person name, avoiding a common false positive. The NER model achieves this disambiguation because "Apple released the iPhone" follows the pattern of a company announcing a product, while "Maria Rodriguez filed" follows the pattern of a person performing a legal action.

The complete pipeline combines pattern and NER detection, resolves overlapping spans, and applies placeholder replacement. Span merging requires a careful sort: we prefer longer spans over shorter ones when they overlap, because a longer span typically captures more complete PII. Processing spans in reverse order during redaction preserves the character offsets of earlier spans.

The pipeline correctly identifies all PII instances in the sample document and replaces them with typed placeholders, preserving the surrounding sentence structure. Notice that "Sarah Thompson" and the email address are detected as separate spans by separate detectors, but they both appear in the final redacted output because the span merge keeps non-overlapping spans from both layers.

Document-level removal decisions require computing the fraction of tokens that were flagged as PII. This function approximates token density by comparing the number of characters in PII spans to the total document length.

The density threshold cleanly separates the normal prose from the contact list fragment. The contact list has high PII density because a large fraction of its characters are email addresses and phone numbers. The light-PII example, with a single email address in otherwise clean text, falls well below the removal threshold.

We build a synthetic test set to measure the pipeline's precision and recall across PII categories. The test set generates PII using the same types of random generators that a real attacker or careless web poster would use, then embeds them into template sentences that cover diverse grammatical positions.

The evaluation reveals the strengths and weaknesses of pattern-based detection. Email and SSN patterns achieve high recall because their formats are tightly constrained. Phone number detection typically shows slightly lower precision because the pattern can match non-phone 10-digit sequences in some document types, such as product serial numbers or order confirmation numbers that follow phone-like digit groupings.

The key parameters and design choices for a PII detection pipeline are:

• Regex patterns: Specificity of format patterns. More specific patterns reduce false positives but may miss variant formats. The SSN pattern's negative lookahead for invalid area numbers is an example of a specificity refinement.
• NER model size: en_core_web_sm versus en_core_web_lg. Larger models improve recall for names by 3-5 F1 points but increase inference time by 3-4x. For corpus processing, the small model is typically a reasonable default.
• Span merge strategy: Whether to prefer longer or shorter spans when spans overlap. Longer-wins is safer for privacy but may over-redact compound entities that partially overlap with non-PII text.
• Recall-precision trade-off: The operating threshold for the overall pipeline. For training data preparation, recall values above 0.95 are typically targeted even at the cost of precision dropping to 0.80-0.85.
• PII density threshold for document removal: The fraction of tokens that must be flagged PII before the whole document is discarded. Common values range from 5% to 15%.

The following plots illustrate key aspects of PII detection: the precision and recall trade-off per category, the distribution of PII types and densities in a typical web corpus, and the recall gains from adding NER to a pattern-only pipeline.

PII removal is fundamentally an imperfect operation. No pipeline achieves 100% recall on real-world web data because PII appears in too many forms, formats, and languages for any finite set of patterns or a model trained on a finite dataset to catch all instances. This is a known limitation that motivates operating at high-recall thresholds even at the cost of over-redaction. Practitioners who deploy PII pipelines should treat the pipeline as a risk-reduction measure rather than a guarantee: it dramatically reduces the probability of memorizable PII entering the training corpus, but it cannot eliminate that probability entirely.

The most persistent failure mode is quasi-identifier leakage. A pipeline that removes names, emails, and phone numbers may still leave behind enough co-occurring attributes to re-identify individuals. A document that mentions a person's city, employer, age, and medical condition contains no direct PII after the name is removed, but the combination of these four attributes may uniquely identify the person within a specific population. Sweeney's classic 1997 demonstration showed that 87% of the US population could be uniquely identified using only their zip code, date of birth, and sex, and that's with only three quasi-identifier fields. A web document that contains a rare combination of demographic attributes, location, and behavioral details can re-identify a private individual even with all explicit identifiers removed. Defending against quasi-identifier leakage requires either differential privacy techniques (which operate at the model training level rather than the data level) or extremely aggressive filtering that removes most documents mentioning personal attributes.

Non-English text is a significant gap in most open-source PII pipelines. The regex patterns for phone numbers vary by country: a Brazilian phone number has a different format from a German number or a Japanese number. Name patterns vary dramatically across languages and cultures. In Chinese, names appear as two or three characters without word boundaries that English NER relies on. In Arabic, romanization of names creates variant spellings that a single pattern cannot capture. In Hindi, names may be written in Devanagari script and follow syllabic patterns that have no analog in English NER training data. NER models fine-tuned on English data perform poorly on these languages, and organizations building multilingual models need separate PII pipelines for each major language or a multilingual model specifically fine-tuned for PII detection using labeled data in each language.

The recall-precision trade-off has real consequences for model quality that go beyond numeric benchmarks. Aggressive PII removal that flags and removes borderline cases will also remove legitimate content. A sentence like "The policy was adopted by John D. Rockefeller in 1906" contains a historically significant public figure whose name is material to the document, not sensitive personal information. A name-removal pipeline that removes all PERSON entities will redact this to "The policy was adopted by [NAME] in 1906", degrading the model's ability to learn about historical events, distinguish between public figures and private individuals, and understand the temporal context of historical decisions. Calibrating the threshold to preserve historically or publicly significant mentions while removing private individuals' information is an open research problem that requires either entity disambiguation (linking detected names to a knowledge base to determine whether they refer to a public figure) or topic-aware PII detection that understands whether a document is about a public or private context.

Adversarial inputs represent a specific failure mode that increases in importance as language models are deployed more widely. A user who wants to extract memorized PII from a model may craft prompts designed to elicit the memorized content. Simple extraction prompts like "What is Sarah Thompson's email address?" are unlikely to work on a model trained on redacted data. More subtle extraction attacks use contextual priming: providing surrounding text that was in the training data and prompting the model to complete the context. If the surrounding text was redacted but the PII was missed by the pipeline, the model may reproduce the PII under this kind of contextual prompting. Defense against adversarial extraction is only partially achieved by PII removal: the removal process must also cover enough cases that targeted contextual prompting cannot recover the original values.

Finally, PII removal does not provide differential privacy guarantees. Differential privacy, in the formal sense, requires that the presence or absence of any individual's data in the training set changes the model's output distribution by at most a small, quantifiable factor $\epsilon$. PII removal reduces the amount of identifiable information in the training corpus, but a model trained on the redacted corpus may still exhibit memorization behaviors for other information in the documents. The interaction between PII removal and memorization is not fully understood, and research published between 2022 and 2024 has shown that even well-redacted documents can sometimes be used to infer properties of the original training data through indirect signals. Combining PII removal with training-time differential privacy noise injection, as described in methods like DP-SGD, provides stronger theoretical guarantees at the cost of some model performance. The appropriate combination of data-level and training-level privacy protection depends on the sensitivity of the data and the threat model you are defending against.

PII removal is a targeted privacy protection step that occurs after deduplication and quality filtering and before the cleaned data enters the training pipeline. The key takeaways from this chapter are:

• PII spans a spectrum from direct identifiers (email, SSN) that are pattern-detectable to quasi-identifiers and sensitive context that require full-document understanding to assess. Legal frameworks like GDPR define PII expansively because re-identification attacks can combine apparently innocuous fields.
• Detection combines three methods: regex for format-constrained PII, NER for names and contextual entities, and specialized classifiers for domain-specific categories like medical or financial information. Each method covers a different part of the PII surface area, and production pipelines layer all three.
• Redaction strategies differ by use case: placeholder replacement preserves linguistic structure and is preferred for training data; pseudonymization preserves realism at greater complexity by replacing real PII with synthetic but realistic alternatives; document removal is appropriate for heavily PII-dense texts where inline redaction would leave incoherent output.
• Evaluation prioritizes recall: for training data, missing PII (false negative) is worse than over-redacting (false positive). Recall targets above 0.95 are common, with precision accepted at 0.80-0.85. Synthetic test sets, canary extraction tests, and membership inference attacks together give a complete picture of pipeline quality.
• Canary extraction tests measure the actual privacy risk by checking whether the model trained on processed data can be induced to reproduce PII from the original corpus. They catch systematic failures that precision-recall evaluation on synthetic data misses.
• Fundamental limitations remain: quasi-identifier combinations can re-identify individuals even after explicit identifiers are removed; non-English text requires separate language-specific pipelines; and the recall-precision trade-off forces a choice between privacy protection and data quality. PII removal reduces but does not eliminate memorization risk, and combining it with training-time differential privacy provides stronger formal guarantees.

Ready to test your understanding? Take this quick quiz to reinforce what you've learned about PII removal in language model training pipelines.