4-Tier PII Redaction: How We Built Privacy Into the Memory Layer, Not Around It

AI memory systems ingest everything: emails, transcripts, documents. PII is embedded in all of it. We built redaction into the write path itself, not as a retrieval filter. Here's the architecture and why the distinction matters.

TL;DR

• PII redaction must happen on the write path, before content reaches the embedding model. Once PII is embedded in a vector, you can't un-embed it. Retrieval-time filtering doesn't fix the problem; it hides it.
• We implemented four tiers: Tier 1 (secrets: API keys, passwords, connection strings), Tier 2 (financial: credit cards with Luhn validation, IBAN), Tier 3 (identity: SSN, passport, driver's license), Tier 4 (contact: email, phone, IP, configurable per customer).
• Tiers 1-3 are always active. Tier 4 is configurable because blanket redaction breaks legitimate use cases: sales teams need email addresses for CRM matching, healthcare companies need them removed entirely.
• 77% of employees paste data into GenAI prompts, and 40% of file uploads contain PII or PCI data (LayerX Security, 2025). AI has overtaken SaaS as the #1 data exfiltration channel. Your memory layer is ingesting PII whether you designed for it or not.
• Privacy isn't a filter you apply to output. It's a property of how data enters the system.

In May 2023, Samsung employees leaked proprietary semiconductor source code, equipment defect-detection code, and internal meeting notes through ChatGPT. Three separate incidents within 20 days of the tool being unblocked. Apple, JPMorgan, Goldman Sachs, Citigroup, and Bank of America all banned or restricted generative AI use in direct response.

Those bans were the right short-term reaction. But the long-term answer isn't "don't use AI." It's "build the privacy architecture so that using AI doesn't create the exposure in the first place."

We build an AI memory platform. Every document, email, call transcript, and support ticket that flows through our system potentially contains PII. The question was never "should we redact?" It was "where in the pipeline does redaction actually protect anything?"

The answer we arrived at, after getting it wrong initially, is: redaction only matters if it happens before the embedding model sees the content.

The Write-Path Problem

Most PII handling in AI systems works like this: data goes into the store, and at retrieval time, a filter removes sensitive content before it reaches the user or the downstream agent.

This works for document search. It does not work for memory.

In a memory system, content isn't just stored as text. It's processed through an embedding model that converts it into a vector representation. That vector encodes semantic meaning, including the meaning of any PII present in the text. Once an email address, a credit card number, or a social security number is embedded, its semantic signature is in the vector. You can filter the text at retrieval time, but the vector still contains the information. Similarity searches can still surface it. And if you're using the embedding for downstream processing, comparison, or clustering, the PII influences every operation.

The only architectural guarantee is to redact before embedding. Content enters the pipeline, redaction runs, clean content gets embedded and stored. The PII never reaches the vector layer, the LLM extraction layer, or the memory store.

This sounds obvious in retrospect. When we first built the memory pipeline, redaction was a post-processing step. We caught the mistake before shipping to production, but it was a mistake worth documenting because the industry defaults to post-processing for everything.

Why Blanket Redaction Breaks Things

The naive solution is to strip all PII from everything. Remove every email address, phone number, IP address, and anything that looks like personal data. Some compliance teams push for this. It's safe, conservative, and completely breaks legitimate use cases.

A sales team's AI memory needs email addresses. That's how records link to CRM contacts. That's how the system matches an inbound email to an existing relationship. Strip all emails, and the memory layer can't identify who it's talking about.

A customer success team needs phone numbers associated with support tickets. Remove them, and the system can't correlate a callback request with the ticket that triggered it.

A healthcare compliance team needs all contact information removed because their regulatory environment doesn't permit AI systems to store patient contact details alongside medical context.

This is what pushed us toward a tiered architecture.

The Four Tiers

Tier 1: Secrets (Always Active)

API keys, private keys, connection strings, passwords, bearer tokens, AWS access keys.

These should never, under any circumstance, reach an AI model. Not for embedding. Not for extraction. Not for summarization. They have no legitimate use in a memory system, and their exposure creates immediate security risk.

Tier 1 uses pattern matching with high-confidence regular expressions. API key formats are well-defined. AWS access key IDs follow a specific pattern (AKIA prefix, 20 characters). Connection strings have recognizable structure. False positive rates are low because these formats are distinctive.

This tier exists because of Samsung. Three leaks in 20 days. Source code and internal meeting notes flowing into a third-party AI system. After that incident, we made Tier 1 non-negotiable. It runs on every customer, every plan, every configuration. There is no toggle to disable it.

Tier 2: Financial Data (Always Active)

Credit card numbers (with Luhn algorithm validation), IBAN numbers, bank account numbers.

Financial data detection is trickier than secrets because numeric strings appear everywhere. A 16-digit number might be a credit card or a product SKU. This is where Luhn validation matters: the checksum algorithm that validates credit card numbers eliminates the vast majority of false positives. We only redact numbers that pass the Luhn check, which means legitimate credit cards are caught while random numeric strings pass through.

IBAN detection uses country-specific format validation. The two-letter country code, two check digits, and country-specific BBAN structure provide enough signal to detect real IBANs without flagging arbitrary alphanumeric strings.

Tier 2 is always active for the same reason as Tier 1: there is no enterprise use case where a memory system should store raw credit card numbers. If the data is needed for billing integration, the CRM or payment system holds it. The memory layer doesn't need it.

Tier 3: Identity Documents (Always Active)

Social Security Numbers, passport numbers, driver's license numbers.

These are the most privacy-sensitive identifiers in most regulatory frameworks. GDPR classifies them as personal data requiring explicit purpose limitation. CCPA/CPRA provides consumers the right to deletion. HIPAA covers them when combined with health information.

Detection uses format-specific patterns with regional awareness. US SSNs follow a three-two-four digit pattern with specific range exclusions (no area number 000, 666, or 900-999). Passport numbers vary by country but follow documented formats.

Like Tiers 1 and 2, there is no legitimate reason for an AI memory system to store raw identity document numbers. If a customer support interaction references a passport number for identity verification, the memory layer should retain the fact that identity was verified, not the passport number itself.

Tier 4: Contact Information (Configurable Per Customer)

Email addresses, phone numbers, IP addresses, physical addresses.

This is where the architecture becomes interesting. Tier 4 is the only tier with a toggle, and the toggle exists because reasonable customers disagree about what the right policy is.

Sales teams: Email addresses are primary keys. The entire CRM integration depends on matching inbound communications to stored entity records by email. Redacting emails would break the core workflow. For these customers, Tier 4 email redaction is off.

Healthcare customers: Contact information combined with medical context creates protected health information under HIPAA. For these customers, Tier 4 is fully active. Emails, phones, and IP addresses are all redacted before the content reaches the memory pipeline.

Financial services: Often somewhere in between. Internal-facing agent memory may retain contact info, but customer-facing contexts require redaction. Some financial customers configure Tier 4 differently per collection or per data source.

Where Redaction Sits in the Pipeline

The memory write path at Personize processes content through several stages. Understanding where redaction sits is critical because moving it even one step later creates exposure.

Step 1: Content ingestion. Raw content arrives: an email body, a call transcript chunk, a document section.

Step 2: PII redaction. All four tiers run on the raw content. Detected PII is replaced with type-tagged placeholders ([EMAIL], [CREDIT_CARD], [SSN]). The placeholders preserve sentence structure so that downstream extraction can still parse the content grammatically.

Step 3: LLM extraction. The redacted content is sent to the extraction pipeline. The LLM extracts structured properties and open-set facts from the clean text. It never sees the original PII. If a transcript says "Contact me at [EMAIL] about the Q2 renewal," the extraction captures the Q2 renewal context without the email address.

Step 4: Embedding. The redacted content (plus extracted facts) is embedded into vectors. The vectors encode the semantic meaning of the redacted text, not the original PII.

Step 5: Storage. Vectors go to LanceDB, structured properties go to DynamoDB. Both stores contain only redacted content.

The key insight: by the time the LLM or the embedding model sees the content, PII is already gone. This is what "privacy by design" means in practice, not a policy document, but an architectural guarantee that sensitive data can't reach the layers that would propagate it.

The Numbers That Made This Urgent

LayerX Security's 2025 Enterprise AI report quantified what security teams had been warning about:

• 77% of employees paste data into GenAI prompts, with 82% doing so from unmanaged personal accounts
• 40% of file uploads to GenAI tools include PII or PCI data
• AI has overtaken SaaS as the #1 data exfiltration channel in the enterprise
• GenAI accounts for 32% of all corporate-to-personal data transfers
• On average, employees perform 14 pastes per day via personal accounts, with at least 3 containing sensitive data

These aren't hypothetical risks. This is measured behavior across real enterprise environments.

The OWASP Top 10 for LLM Applications (2025 edition) lists "Sensitive Information Disclosure" (LLM02) as one of the most commonly observed vulnerabilities in production LLM systems. The attack surface isn't exotic. It's the normal operation of the system: data goes in, and if the architecture doesn't prevent it, PII comes out.

When we look at these numbers, the conclusion is straightforward: any AI memory system that ingests enterprise content is ingesting PII. The question is whether your architecture handles it before it spreads, or whether you discover the problem in a breach report.

What We Learned Building This

Lesson 1: Placeholder design matters more than you'd think.

When you replace john.smith@company.com with [EMAIL], the LLM extraction pipeline needs to handle that placeholder gracefully. Early versions occasionally extracted the placeholder itself as a property value (setting email: "[EMAIL]"). We added post-extraction validation that catches placeholder values and filters them out. Small detail, but it surfaces in production at scale.

Lesson 2: False positive tuning is ongoing work.

Tier 2 credit card detection with Luhn validation works well for standard card formats. But some industries use 16-digit internal reference numbers that happen to pass the Luhn check. We haven't solved this completely. The current approach errs toward redaction (false positive is safer than false negative for financial data), but we track false positive rates per customer and adjust thresholds when patterns emerge.

Lesson 3: Redaction is necessary but not sufficient.

Redaction handles content flowing into the memory layer. But PII also exists in metadata (who sent the email, which phone number placed the call) and in the control plane (API request bodies, log entries). Our privacy module extends the redaction boundary beyond the memory pipeline to audit logs, deletion request records, and API response bodies. The memory write path was the first and most critical boundary, but it wasn't the last.

Lesson 4: Customers test your redaction.

Enterprise customers, especially in healthcare and financial services, will send test data with known PII to verify your redaction works. They'll embed credit card numbers in documents, include SSNs in call transcripts, and check whether the stored content contains the original values. We learned to treat this as a feature, not an edge case. Our testing suite includes adversarial PII injection across all four tiers.

The Regulatory Baseline

GDPR Article 25 requires "data protection by design and by default." This isn't advisory language. It's a legal mandate. Organizations must implement "appropriate technical and organizational measures" to embed data protection principles from initial conception, not as an afterthought.

For AI memory systems, "by design" means PII redaction is part of the pipeline architecture, not a configuration option that can be disabled. Our Tiers 1-3 are the architectural expression of this principle: secrets, financial data, and identity documents are always redacted, not because a customer toggled a setting, but because the system is built that way.

The NIST AI Risk Management Framework (AI 100-1) and its Generative AI Profile (AI 600-1, July 2024) provide a more detailed framework. The MANAGE function specifically addresses ongoing monitoring for data privacy risks, including PII leakage through model outputs. The framework treats privacy as a system property, not a point solution.

The EU AI Act, with enforcement beginning August 2026 for high-risk AI systems, will add another layer. Systems processing personal data at scale will face specific requirements around data minimization and privacy-by-design documentation. The tiered architecture we've built maps directly to these requirements: we can document exactly what gets redacted, at which tier, and at which stage of the pipeline.

What This Doesn't Solve

I want to be direct about the boundaries.

LLM provider data exposure. When content is sent to an external LLM for extraction or generation, it leaves the customer's environment and enters the provider's infrastructure. Our redaction runs before the LLM call, so the provider never sees raw PII. But the redacted content itself is processed by OpenAI, Anthropic, or whichever provider the customer configures. For customers who need zero data egress, we support AWS Bedrock (data stays in-account) and self-hosted model inference via vLLM or Ollama.

Pre-existing PII in stored vectors. If a system ran without adequate redaction and later enables it, the historical vectors still contain PII-influenced embeddings. Our recommendation for customers in this situation: re-embed the affected records. We provide tooling for targeted re-embedding, but it's an operational effort, not a toggle.

ML-augmented PII detection. Our current implementation uses pattern-based detection (regex, Luhn, format validation). Transformer-based NER for non-standard PII patterns (detecting that "my mother's maiden name is Johnson" contains implicitly sensitive information) is future work. The pipeline architecture supports inserting an ML detection step before the pattern-based tiers, but we haven't shipped it yet.

These are real limitations. We'd rather document them than pretend they don't exist.

Frequently Asked Questions

Why not use a third-party PII detection service?

Because that service would see the raw, unredacted content. Sending PII to an external service for detection creates the same exposure you're trying to prevent. Our redaction runs in-process, within the customer's deployment environment. The raw content never leaves the pipeline boundary.

Do the placeholders affect extraction quality?

Minimally. The LLM extraction pipeline is trained to handle placeholder tokens gracefully. A sentence like "Reach out to [EMAIL] about the Q2 renewal" still yields the correct extraction: a renewal context linked to Q2. The placeholder preserves grammatical structure, which is what the extraction model needs. We've measured extraction quality with and without redaction across diverse content types; the impact is within noise.

Can customers add custom redaction patterns?

Not yet in the current architecture, but this is on the roadmap. The tier system is extensible: adding a Tier 5 for custom patterns (industry-specific identifiers, internal reference numbers, custom data classifications) is architecturally straightforward. The pipeline already supports pluggable detection at each stage.

What happens when Tier 4 is enabled but the CRM integration needs email matching?

This is a real tension. The current solution: when Tier 4 email redaction is active, we use a one-way hash of the email address for CRM matching. The hash provides deterministic linkage (the same email always produces the same hash) without storing the raw address. The hash can't be reversed. This preserves matching functionality while satisfying redaction requirements.

How do you handle PII in images or PDFs?

Currently, our redaction pipeline operates on extracted text. If an image or PDF contains PII in visual form (a scanned document with a printed SSN), the text extraction step must surface it before redaction can run. OCR quality affects redaction coverage. For high-sensitivity use cases, we recommend pre-processing visual content through a dedicated OCR-and-redact pipeline before ingestion.

References

• TechCrunch — "Samsung bans use of generative AI tools like ChatGPT after April internal data leak" (May 2023): https://techcrunch.com/2023/05/02/samsung-bans-use-of-generative-ai-tools-like-chatgpt-after-april-internal-data-leak/
• Fortune — "Employees are banned from using ChatGPT at these companies" (May 2023): https://fortune.com/2023/05/19/chatgpt-banned-workplace-apple-goldman-risk-privacy/
• LayerX Security — "The LayerX Enterprise AI & SaaS Data Security Report 2025" (October 2025): https://go.layerxsecurity.com/the-layerx-enterprise-ai-saas-data-security-report-2025
• OWASP Foundation — "Top 10 for Large Language Model Applications" (2025, v2.0): https://owasp.org/www-project-top-10-for-large-language-model-applications/
• The Hacker News — "New Research: AI Is Already the #1 Data Exfiltration Channel in the Enterprise" (October 2025): https://thehackernews.com/2025/10/new-research-ai-is-already-1-data.html
• NIST — "AI Risk Management Framework (AI RMF 1.0)" + "Generative AI Profile (AI 600-1)" (2023/2024): https://www.nist.gov/itl/ai-risk-management-framework