25 — Data PII Masking

Concept overview

PII masking replaces or removes personal information in prompts, documents, tool results, and logs according to a defined data policy. Techniques include redaction, typed placeholders, tokenization, and reversible pseudonyms. These techniques have different privacy and utility properties; replacing a name with a stable token is not the same as making the record anonymous.

Detection is imperfect, especially for uncommon identifiers, multilingual text, images, and context-dependent entities. Combine appropriate recognizers and domain rules, evaluate false negatives, and minimize data before detection. Protect any reversible mapping as sensitive data with stricter access than the masked payload.

Why it matters in production

Proof of concept

A prototype can mask obvious names and contact details in a sample corpus. Include realistic domain identifiers and ambiguous phrases before judging coverage.

Production

Production applies masking before external inference and before telemetry export, with policy-specific handling for structured fields and free text. Reidentification requires explicit authorization.

Enterprise scale

At scale, maintain recognizers by language and business domain, track detector drift, and cover attachments and derived artifacts. Masking errors must be assessed against both privacy exposure and loss of task meaning.

Architecture components

Data classifier

Determines relevant personal-data categories and the applicable handling policy.

Entity detector

Combines structured-field knowledge, patterns, and contextual recognition to locate sensitive spans.

Transformation engine

Applies redaction, typed replacement, hashing, or tokenization according to field semantics.

Mapping vault

Protects reversible token mappings with separate keys, access controls, and retention.

Coverage evaluator

Measures missed entities and excessive masking on representative reviewed samples.

The architecture, mapped

flowchart LR
 R["Customer case data"] --> M["Data minimization"]
 M --> D["PII detection"]
 D --> T["Policy transformation"]
 T --> L["Model inference"]
 T --> O["Masked observability"]
 T --> V["Protected mapping vault"]
 L --> A["Authorized output adapter"]
 V --> A
 A --> U["Permitted recipient"]

Runtime flow

1. 1

   Minimize input

   Remove fields unnecessary for the task before invoking any model or detector.

2. 2

   Detect entities

   Analyze structured fields and text using domain and language-appropriate recognizers.

3. 3

   Resolve overlaps

   Apply consistent precedence when multiple recognizers identify overlapping sensitive spans.

4. 4

   Transform safely

   Replace entities while preserving required relationships and storing reversible mappings only when necessary.

5. 5

   Process masked data

   Send the transformed payload through inference and apply the same policy to logs and outputs.

6. 6

   Reidentify selectively

   Restore approved values only for an authorized recipient and record mapping access.

Summarizing sensitive correspondence

Insurance customer service · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

An insurer summarizes customer emails containing names, addresses, policy identifiers, and descriptions of personal circumstances.

The problem

Sending entire messages to every processing component exposes unnecessary personal data and reproduces it in traces.

Agent requirement

The assistant must summarize the service issue while retaining enough entity consistency to distinguish people and policies.

Architecture

A minimization stage removes irrelevant fields, then typed pseudonyms preserve relationships through inference while mappings remain in a protected vault.

Runtime

• The detector identifies direct identifiers and domain-specific policy numbers before the summary model receives the email.
• An authorized case interface restores only the identifiers its user may view; exported analytics retain the masked form.

Failure scenario

If a detector misses a rare identifier, sampled review and output scanning create a remediation case and update the recognizer evaluation set.

Operational impact

Measure entity-level false negatives, excessive masking, summary utility, and mapping-vault access. Masking reduces exposure but does not guarantee anonymity.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Calling pseudonymized data anonymous

Document remaining linkability and reidentification risk.

Masking only user prompts

Cover tool results, attachments, outputs, and logs.

Evaluating only obvious English names

Test domain identifiers and supported languages.

When to choose this pattern

Choose it when

• Tasks do not require direct personal identifiers in inference.
• External processing or analytics should receive minimized data.
• Reidentification can be isolated behind explicit authorization.

Avoid it when

• Masking removes the facts required for the authorized task.
• A proposed detector has unmeasured coverage on the data.
• The workflow falsely assumes masking eliminates all privacy obligations.

Architecture checklist

• Define data categories and transformation policy.
• Minimize before entity detection.
• Evaluate false negatives by language and domain.
• Protect mappings separately from masked data.
• Mask telemetry before export.
• Test authorized and denied reidentification.

Related concepts

• 24 — Prompt Injection Mitigation
• 30 — Non-Repudiation Logs
• 34 — Tenant Isolation
• 37 — Zero-Data Retention (ZDR) Contracts
• 39 — Content Moderation API

Primary references

• Microsoft Presidio documentation
• NIST AI Risk Management Framework