Module 6: Data Privacy & PII Protection

1. Introduction: Data Privacy & PII Protection

Overview

In Module 4 you built a Sanitization Pipeline that cleans, validates, and filters everything that enters and leaves your AI system. In Module 5 you secured your credentials with Secrets Management. Now you face a problem that neither the most robust sanitization nor the best secrets management practices solve on their own: your users' personal data is flowing through your AI system, and the model can memorize it, leak it, or expose it.

An LLM isn't a database — but it behaves like one. When you send a patient's medical history as context to generate a summary, that text passes through the AI provider's servers. When a user types "my social security number is 123-45-6789" into a chatbot, that data lands in your logs. When you use RAG and your documents contain customer emails, phones, and addresses, every query potentially exposes that information in the model's response.

This module builds the personal data protection layer — the PII Protection Layer — that integrates with your Sanitization Pipeline from Module 4. If Module 4 was "make sure the data is clean and valid," this module is "make sure the personal data is protected before, during, and after AI processing." It's the difference between cleaning a room (M4) and making sure there are no hidden cameras recording what happens inside (M6).

The main focus of this module is mitigating LLM02: Sensitive Information Disclosure from the OWASP LLM Top 10 2025. LLM02 happens when a model reveals sensitive information — memorized training data, PII from the context, secrets from the system prompt, or other users' data that leaked through the context window. It's one of the vulnerabilities with the highest regulatory impact because GDPR violation fines can reach 4% of global revenue.

Why a whole module for PII protection?

The decision to dedicate a module to PII protection (separate from sanitization) is deliberate. There are three reasons:

1. Sanitization isn't enough to protect personal data

Module 4 detects PII in a basic way (regex for emails and phones in the Content Filter). But detecting PII in production requires specialized tooling: Named Entity Recognition (NER) with language models, pattern recognizers for more than 30 types of PII, multilingual support, and the ability to tell a real email from an example one in documentation.

2. Detecting PII isn't enough — you need to redact it correctly

Finding an email in text is just the start. Do you replace it with [EMAIL]? Do you hash it so you can audit without exposing it? Do you generalize it to just the domain? Is the redaction reversible or irreversible? Do you redact before sending to the LLM, after, or both? Each strategy has utility, privacy, and compliance trade-offs that this module addresses.

3. PII protection has dimensions that go beyond code

Data minimization (sending only what's needed to the LLM), retention policies (how long you keep logs and outputs), encryption (how you protect data at rest and in transit), and compliance basics (GDPR, CCPA) are aspects of data protection that require architecture decisions, not just code.

What will you learn in this module?

By the end of this module you'll be able to:

Understand LLM02 in depth: how LLMs memorize and leak sensitive data, extraction techniques, real data leakage scenarios, and regulatory implications
Detect PII with professional tools: Microsoft Presidio for multi-type detection, spaCy NER for names and organizations, regex for structured patterns (SSN, credit cards), custom recognizers for PII specific to your domain
Redact PII with appropriate strategies: masking, replacement, hashing, generalization, pre-LLM and post-LLM redaction, reversible vs irreversible redaction, context preservation
Minimize data sent to the LLM: smart truncation, selective field inclusion, prompt engineering for privacy, data classification by sensitivity level
Implement retention policies and encryption: automatic deletion schedules, encryption at rest and in transit, log sanitization, key management
Know the relevant compliance frameworks: GDPR, CCPA, and how they affect AI systems — without pretending to be legal advice, but rather technical awareness
Build a complete PII Protection Layer as a project: integrated with the Sanitization Pipeline from Module 4, with a scanner, redactor, minimizer, retention scheduler, and audit logging

Module roadmap

This module has 8 capsules that build the data protection layer piece by piece:

#	Capsule	What you'll learn
01	Introduction: Data Privacy & PII Protection	Why this module, roadmap, connection to the project, setup
02	LLM02 in Detail: Sensitive Information Disclosure	How LLMs leak data, extraction techniques, real scenarios, implications
03	PII Detection: Patterns, Regex, and Presidio	PII detection with regex, Presidio, spaCy NER, custom recognizers
04	PII Redaction: Before and After the LLM	Redaction strategies, pre/post-LLM, reversible vs irreversible
05	Data Minimization	Sending only what's needed to the LLM, data classification, prompt engineering for privacy
06	Retention Policies and Encryption	Retention schedules, encryption at rest/transit, log sanitization
07	Compliance Basics: GDPR, CCPA, and AI	Compliance frameworks, data subject rights, AI-specific considerations
08	Project: PII Protection Layer	Complete PII protection layer integrated with the Sanitization Pipeline

The progression is: context (01) → threat (02) → detection (03) → redaction (04) → minimization (05) → retention and encryption (06) → compliance (07) → project (08).

Capsules 02-04 form the technical core: understand the threat, detect PII, and redact it. Capsule 05 adds the minimization dimension — reducing what you send to the LLM. Capsule 06 covers what happens after processing (retention, encryption). Capsule 07 frames everything in legal frameworks. Capsule 08 integrates it all into the PII Protection Layer.

Context within the guide

This guide has 8 modules organized into 3 phases:

Phase 1: Security Foundations (Modules 1-3)
├── Module 1: AI Security Landscape & Threat Model    ✅ COMPLETED
├── Module 2: OWASP LLM Top 10 Deep Dive             ✅ COMPLETED
└── Module 3: Prompt Injection — Attacks & Defenses   ✅ COMPLETED

Phase 2: Defense Implementation (Modules 4-6)
├── Module 4: Input & Output Sanitization             ✅ COMPLETED
├── Module 5: Secrets Management                      ✅ COMPLETED
└── Module 6: Data Privacy & PII Protection           ← YOU ARE HERE

Phase 3: Production Security (Modules 7-8)
├── Module 7: Security Testing & Auditing
└── Module 8: Capstone — Secured AI System

Module 4 gave you the input/output sanitization pipeline. Module 5 secured your credentials and API keys. Now Module 6 tackles protecting the most sensitive data that flows through your system: your users' personal information.

The relationship with previous modules is one of complement:

Module 3 (Injection Defense)          Module 4 (Sanitization)
─────────────────────────             ─────────────────────────
Detects intentional attacks           Cleans malformed data
Blocks prompt injection               Validates output structure
Focus: LLM01                          Focus: LLM05

Module 5 (Secrets Management)         Module 6 (PII Protection)
─────────────────────────             ─────────────────────────
Protects system credentials           Protects user data
API keys, tokens, certificates        Emails, names, SSN, cards
Focus: developer secrets              Focus: end-user data

Together, M3 + M4 + M5 + M6 form the system's four defense layers: anti-injection (M3) + sanitization (M4) + secrets (M5) + PII protection (M6).

Prerequisites

For this module you need:

Modules 1-5 completed: Threat Model, OWASP Mapping, Injection Defense, Sanitization Pipeline, Secrets Management Setup
Python 3.10+ installed
Familiarity with regex — basic regular expression patterns
Familiarity with FastAPI — middleware, dependencies

Technical setup

If you already have the environment from the previous modules, activate it and add the new dependencies:

source security-guide-env/bin/activate  # macOS/Linux
# security-guide-env\Scripts\activate   # Windows

pip install presidio-analyzer presidio-anonymizer spacy
python -m spacy download en_core_web_lg
python -m spacy download es_core_news_md

If you're starting from this module:

python -m venv security-guide-env
source security-guide-env/bin/activate

pip install presidio-analyzer presidio-anonymizer spacy pydantic fastapi uvicorn
python -m spacy download en_core_web_lg

export OPENAI_API_KEY="sk-..."

Quick check:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

text = "Mi nombre es Juan García y mi email es juan@ejemplo.com"

results = analyzer.analyze(
    text=text,
    language="en",
    entities=["PERSON", "EMAIL_ADDRESS"],
)

anonymized = anonymizer.anonymize(text=text, analyzer_results=results)

print(f"Original:   {text}")
print(f"Anonymized: {anonymized.text}")
print(f"Entities:   {[(r.entity_type, r.score) for r in results]}")

# Expected output:
# Original:   Mi nombre es Juan García y mi email es juan@ejemplo.com
# Anonymized: Mi nombre es <PERSON> y mi email es <EMAIL_ADDRESS>
# Entities:   [('EMAIL_ADDRESS', 1.0), ('PERSON', 0.85)]

If you see the three outputs, your setup is ready. The key dependencies for this module are:

Package	What for
`presidio-analyzer`	PII detection with NER and patterns
`presidio-anonymizer`	Redaction/anonymization of detected PII
`spacy`	NER models for detecting names, organizations
`pydantic`	Configuration and validation models
`fastapi`	Integrating the PII Protection Layer as middleware

Connection to the module project

This module closes with the PII Protection Layer project: a personal data protection layer that integrates with your Sanitization Pipeline from Module 4. It's the sixth artifact of the guide.

The PII Protection Layer includes:

PII Scanner — Detection with Presidio + custom recognizers for your domain
Pre-LLM Redactor — Redacting PII before sending it to the model
Post-LLM Redactor — Detecting and redacting PII in the model's outputs
Data Minimizer — Reducing the data sent to the minimum necessary
Retention Scheduler — Retention policy with automatic deletion
Audit Logger — Logging every PII detection and redaction

The pipeline integrates with the Sanitization Pipeline from Module 4:

Request
  │
  ▼
┌──────────────────────────┐
│  Input Sanitizer (M4)    │ ← Normalizes, cleans
├──────────────────────────┤
│  PII Scanner (M6)        │ ← Detects PII in input
├──────────────────────────┤
│  Pre-LLM Redactor (M6)  │ ← Redacts PII before the LLM
├──────────────────────────┤
│  Data Minimizer (M6)    │ ← Sends only what's needed
├──────────────────────────┤
│  Injection Detector (M3) │ ← Checks for attacks
├──────────────────────────┤
│  LLM Processing          │ ← OpenAI API call
├──────────────────────────┤
│  Output Validator (M4)   │ ← Validates structure
├──────────────────────────┤
│  Post-LLM Redactor (M6) │ ← Filters PII in output
├──────────────────────────┤
│  Content Filter (M4)     │ ← Toxicity, off-topic
├──────────────────────────┤
│  Audit Logger (M4+M6)   │ ← Full logging
└──────────────────────────┘
  │
  ▼
Response

In Module 8 (capstone project), the PII Protection Layer integrates with all the previous artifacts to form the Secured AI System.

Module 1: Threat Model Document (base)
Module 2: + OWASP Mapping Audit (detailed mapping)
Module 3: + Injection Defense Pipeline (defense against LLM01)
Module 4: + Sanitization Pipeline (input/output)
Module 5: + Secrets Management Setup (credentials)
Module 6: + PII Protection Layer (sensitive data)              ← YOU BUILD IT HERE
Module 7: + Security Audit Report (validation)
Module 8: → Secured AI System (full integration)

LLM02: Sensitive Information Disclosure — the focus of this module

This module primarily mitigates LLM02: Sensitive Information Disclosure. Understanding this vulnerability is key to everything that follows.

What LLM02 is

LLM02 happens when an LLM reveals sensitive information that shouldn't be in its output. This can happen because of:

Training data memorization: The model memorized emails, phones, or addresses from its training dataset and reproduces them when a prompt triggers it
Context window leakage: One user's context (RAG documents, chat history) leaks into another user's response
System prompt exposure: The system prompt contains sensitive information (API endpoints, business logic) that the model reveals when pressured
Cross-conversation bleed: In systems with shared sessions, data from one conversation shows up in another

Why it's especially dangerous in AI

In a traditional web application, a data leak requires a technical vulnerability (SQL injection, IDOR, etc.). In an AI system, the model can reveal sensitive data simply because a user asked a question that triggers a memorization pattern. You don't need a sophisticated attacker — you need a curious user.

The risk pattern

# RISK: Sending unredacted PII to the LLM
user_data = {
    "name": "María García López",
    "email": "maria@empresa.com",
    "ssn": "123-45-6789",
    "query": "What's the status of my order?"
}

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": f"User data: {user_data}"},
        {"role": "user", "content": user_data["query"]},
    ],
)
# The LLM now has access to the SSN and can include it in the response

# SAFE: Redact PII before sending to the LLM
from pii_scanner import scan_and_redact

safe_context = scan_and_redact(str(user_data))
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": f"User data: {safe_context}"},
        {"role": "user", "content": user_data["query"]},
    ],
)
# The LLM never sees the real SSN or email

Every capsule in this module builds a piece of that protection chain.

What makes this module different from the Module 4 Content Filter

Module 4 includes a Content Filter with basic PII detection (regex for email, phone, SSN, credit card). This module doesn't repeat that content — it replaces it with an enterprise-grade solution:

Concept	Module 4 (Content Filter)	This module (M6)
PII detection	Regex for 4 types	Presidio + spaCy NER for 30+ types
Redaction	Not covered	5 strategies: masking, replacement, hashing, generalization, synthetic
Pre-LLM protection	Not covered	Full redaction before sending to the LLM
Post-LLM protection	Basic flag	Detection and redaction in the model's outputs
Data minimization	Not covered	Reducing data to the minimum necessary
Retention	Not covered	Retention policies with automatic deletion
Compliance	Mention of GDPR	GDPR, CCPA, AI-specific considerations
Multi-language	English patterns only	Multilingual support with spaCy and Presidio

The rule is: the M4 Content Filter is a PII "flag." The M6 PII Protection Layer is the complete solution.

What this module does NOT cover

To stay focused and avoid duplicating content:

Prompt injection defense: That was Module 3. PII redaction doesn't protect against injection — it complements it.
General input/output sanitization: That was Module 4. Here you use the sanitization pipeline as a base, you don't rebuild it.
Secrets management: The API keys for Presidio or moderation services are protected in Module 5.
Security testing of the PII layer: Here you build the protection. Module 7 tests it with adversarial inputs.
Compliance legal advice: Capsule 07 covers GDPR/CCPA awareness. It is not — and doesn't pretend to be — legal advice. Consult your legal team for formal compliance.

The analogy: a hospital and medical records

Imagine a hospital where doctors need to consult medical records to diagnose patients:

Full record → Doctor consults → Diagnosis → Result is stored

The hospital has strict rules about those records:

Detection: Every document is classified by sensitivity level (PII Scanner)
Redaction: When a doctor shares a case at a conference, the patient's data is redacted (Pre-LLM Redactor)
Minimization: A dermatology doctor only accesses the dermatological section of the record, not the psychiatric history (Data Minimizer)
Retention: Records are destroyed after the legal retention period (Retention Policy)
Encryption: Records are kept in a locked filing cabinet, not on the coffee table (Encryption at Rest)
Compliance: The hospital complies with medical data protection regulations (GDPR/HIPAA)

Hospital                              AI System
────────────────────                  ────────────────────────
Medical record                        User data / RAG documents
Doctor consulting                     LLM processing context
Redaction for a conference            Pre-LLM redaction
Only the relevant section             Data minimization
Locked filing cabinet                 Encryption at rest
Destruction after legal period        Retention policy
Medical data regulations              GDPR / CCPA compliance

Your AI system is the hospital. Your users' data is the records. The LLM is the doctor. This module builds all the protection rules around those records.

Common mistakes when approaching PII protection

"I already have HTTPS, my data is protected"

HTTPS protects data in transit between your server and the user. But the data you send to the LLM travels to the AI provider's servers, is stored in your logs, persists in your vector store, and exists in the model's memory. HTTPS protects against none of these exposure vectors.

"If I don't store personal data, I don't need PII protection"

Your system processes personal data even if it doesn't store it permanently. When a user types "my email is maria@empresa.com" into your chatbot, that data flows through your system, is sent to the LLM, is logged, and potentially stored in the chat history. "Not storing" and "not processing" are very different things under GDPR.

"OpenAI's model already protects the data"

OpenAI implements security measures on its platform, but the responsibility for protecting your users' data is yours. If you send an SSN to the model and the model includes it in a response, the violation is your system's, not OpenAI's. The "data protection by design" principle (GDPR Art. 25) requires that you implement the protections.

"PII redaction makes my system useless"

Full redaction (replacing everything with [REDACTED]) does reduce utility. But there are strategies that preserve context: redaction with the entity type (<PERSON> instead of [REDACTED]), generalization (exact date → decade), synthetic data (a fictional name instead of a placeholder). Capsule 04 covers these strategies in detail.

"I only process internal users' data, I don't need compliance"

GDPR protects anyone's data, including employees. If your internal AI system processes employee data (emails, names, org charts), GDPR applies. CCPA applies to California residents' data regardless of whether they're customers or employees.

"I can implement PII protection after launch"

Retrofitting PII protection is significantly more expensive than designing it in from the start. You need to re-index your vector store with redacted documents, sanitize historical logs, implement per-user deletion mechanisms, and potentially re-train fine-tuned models. GDPR Art. 25 explicitly requires "data protection by design and by default" — from the start, not as an afterthought.

The importance of PII Protection in the industry

To help you understand the weight of PII protection in the professional world, these are documented incident patterns:

Real incidents (common patterns)

Pattern	What happened	Impact
RAG with PII	A support chatbot retrieved another customer's ticket with their email and phone as context, and included them in the response	GDPR violation, notification to the data protection authority
Fine-tuning with real data	A model fine-tuned with customer emails started generating real names and emails when asked for "examples"	Regulatory investigation, model re-training
Logs with full prompts	The system logs contained users' full prompts, including SSNs and credit cards. A breach of the logging system exposed all of that information	Breach notification, fine, reputational damage
A chatbot that remembers	A multi-session chatbot kept the full history. A user discovered they could ask about data from other users' previous sessions	Confidentiality violation, class-action lawsuit
API without a PII filter	A text-generation API returned model outputs without filtering. The model included emails memorized from the training data	Data leak through memorization, public exposure

Each of these incidents would have been prevented with a PII Protection Layer like the one you build in this module.

Regulations that require PII protection

Regulation	Relevant requirement	Maximum fine
GDPR	Art. 25: Data protection by design	€20M or 4% of global revenue
CCPA	§1798.150: Private right of action for data breaches	$7,500 per violation + individual lawsuits
EU AI Act	Art. 10: Data governance for high-risk AI	€35M or 7% of global revenue
HIPAA	§164.312: Safeguards for health data	$1.5M per violation category/year
SOC 2	Processing Integrity: complete and accurate data	Loss of certification

You don't need to be a regulated company to benefit from these practices. But if you process personal data with AI — and the vast majority of AI systems do — PII protection isn't optional.

The cost of not protecting PII: a thought exercise

Think about your current AI system and answer these questions:

If a user types their SSN into the chat, does your system detect and redact it before sending it to the LLM? If not, you're sending critical data to third-party servers.
If your RAG pipeline retrieves a document that contains customer emails, do you redact them before injecting them into the prompt? If not, you're exposing third-party data to the model.
Do your logs record full prompts including user data? If so, any breach of your logging system exposes all the PII.
How long do you keep your AI system's logs? If the answer is "indefinitely" or "I don't know," you're probably violating the storage limitation principle.
If a user asks you to delete all their data, can you do it? If not, you don't comply with the right to erasure (GDPR Art. 17).
Do you filter the LLM's output to detect PII before sending it to the user? If not, the model can reveal memorized or context data.

If you answered "no" to any of these, this module solves those problems for you.

Your system: a pre-assessment exercise

Before starting with the technical capsules, take 5 minutes to assess your current system:

Do you detect PII in user inputs? → If not, capsule 03 is a priority
Do you redact PII before sending to the LLM? → If not, capsule 04 is a priority
Do you send only necessary data to the LLM? → If not, capsule 05 is a priority
Do you have retention policies for logs? → If not, capsule 06 is a priority
Do you know which regulations apply to your system? → If not, capsule 07 is a priority
Do you filter PII in the LLM's outputs? → If not, capsule 04 is a priority

If you answered "no" to the first four questions, follow the module in full order. If you already have some of them solved, you can focus on the specific capsules — but read the others anyway for the advanced techniques you're probably not using.

Module glossary

These are the key terms you'll come across throughout the capsules. Having them clear from the start saves you from stopping your reading to look up definitions:

Term	Definition	Example
PII (Personally Identifiable Information)	Any data that identifies or can identify a specific person	Name, email, SSN, address, phone
Direct PII	PII that identifies a person on its own, without needing a combination	Social security number, passport, CURP
Indirect PII (quasi-identifier)	Data that, combined, can identify a person	Postal code + date of birth + gender
Redaction	The process of hiding or replacing PII in text	`"Juan García"` → `<PERSON>`
Masking	A redaction strategy that replaces characters with asterisks	`juan@mail.com` → `j*@**.com`
Hashing	A redaction strategy that produces a unique, non-reversible value	`"Juan García"` → `a1b2c3d4...`
Generalization	A redaction strategy that reduces the specificity of the data	`"Calle Reforma 123"` → `"Ciudad de México"`
NER (Named Entity Recognition)	An NLP technique that identifies entities (people, places, organizations) in text	spaCy detects "Juan García" as `PERSON`
Presidio	Microsoft's open-source library for PII detection and anonymization	`AnalyzerEngine`, `AnonymizerEngine`
Pre-LLM redaction	Redacting PII before sending data to the language model	Removing the SSN from the prompt
Post-LLM redaction	Detecting and redacting PII in the model's response	Filtering memorized emails from the output
Data minimization	The principle of sending only the strictly necessary data	Sending only the name, not the full SSN
Retention policy	A rule that defines how long data is kept and what happens when it expires	Chat logs: 30 days → delete
Encryption at rest	Encryption of stored data (databases, files, vector stores)	AES-256 for conversation logs
Encryption in transit	Encryption of data moving between systems	HTTPS/TLS for calls to the OpenAI API
GDPR	General Data Protection Regulation — the EU's data protection regulation	Applies if you process EU residents' data
CCPA	California Consumer Privacy Act — California's data privacy law	Applies if you process CA residents' data
DPIA	Data Protection Impact Assessment — a mandatory assessment for high-risk processing	Required for AI that processes PII at scale
Data subject	The person the personal data belongs to	Your end user
Reversible redaction	Redaction that allows recovering the original data with a key	To restore context post-LLM
Irreversible redaction	Permanent redaction that doesn't allow recovering the original data	For logs and data that don't need restoration

You'll see these terms in every capsule. If at any point you're unsure of a meaning, come back to this table.

Module tools and libraries

These are the main tools you'll use and the role each one plays:

Microsoft Presidio

Presidio is a Microsoft open-source library designed specifically for PII detection and anonymization. It has two main components:

presidio-analyzer: Detects PII in text using a combination of regex-based recognizers, NER models, and checksums. It supports more than 30 types of PII entities.
presidio-anonymizer: Applies redaction strategies to the detected PII. It supports masking, replacement, hashing, and custom operators.

The advantage of Presidio over manual regex is that it combines multiple detection strategies with confidence scores, handles false positives with context, and is extensible with custom recognizers for your domain.

spaCy NER

spaCy is an NLP library that includes pre-trained models for Named Entity Recognition. In this module it's used to detect contextual entities that regex can't capture: people's names, organizations, and locations that don't follow a fixed pattern.

The models you'll use:

en_core_web_lg: Large English model, better accuracy for NER
es_core_news_md: Medium Spanish model, for multilingual detection

Python cryptography

Python's cryptography library provides cryptographic primitives for encryption at rest. You'll use Fernet (symmetric encryption) to encrypt stored data and derive keys from passwords.

Pydantic + FastAPI

Pydantic models the PII Protection Layer's configurations with type validation. FastAPI integrates the layer as middleware that intercepts requests and responses automatically.

How to use each capsule

Each technical capsule (02-07) follows this structure:

Context — Why this piece exists in the pipeline and what problem it solves
Concept — The necessary theory (40% of the content)
Implementation — Complete, runnable Python code (60% of the content)
Connection to the project — How it fits into the PII Protection Layer
Troubleshooting — 3-5 common problems with solutions
Exercises — 4-6 practical exercises with solutions in <details>
Summary — Key points of the topic
Resources — 6-8 references to go deeper

I recommend following the capsules in order (02 → 07) because each one builds on the previous. Capsule 02 sets the threat context. Capsules 03 and 04 cover detection and redaction. Capsules 05-07 address additional dimensions of data protection.

Trade-offs: privacy vs utility

A theme that runs through the whole module is the trade-off between privacy and the AI system's utility. More PII protection = more privacy, but also:

❌ Less context for the LLM → lower-quality responses
❌ More false positives in detection → legitimate data redacted
❌ More latency per request → each PII scan adds ~50-200ms
❌ More operational complexity → retention policies, encryption keys, audit logs

The goal isn't to maximize privacy at the expense of utility — it's to calibrate each layer for your context:

Your system	Recommended protection
Public chatbot	Aggressive: redact all PII pre-LLM, don't store logs with data
Internal tool	Moderate: redact SSN/cards, allow names with consent
Health system	Maximum: redact everything, encryption at rest/transit, full audit trail
Batch pipeline without users	Minimal: PII scan on source data, retention policy for outputs

In each capsule, you'll see the specific trade-offs of each technique with concrete precision, recall, and latency data.

A concrete example of the trade-off

To see it with real code:

# Case 1: No PII protection (maximum utility, zero privacy)
prompt = f"""
Customer context:
- Name: María García López
- Email: maria.garcia@empresa.com
- SSN: 078-05-1120
- Address: Av. Insurgentes Sur 1602, CDMX
- Query: When will my order #4521 ship?

Answer the customer's query.
"""

# Case 2: Aggressive redaction (maximum privacy, lower utility)
prompt_redacted = f"""
Customer context:
- Name: <PERSON>
- Email: <EMAIL>
- SSN: <REDACTED>
- Address: <LOCATION>
- Query: When will my order #4521 ship?

Answer the customer's query.
"""

# Case 3: Calibrated redaction (privacy/utility balance)
prompt_balanced = f"""
Customer context:
- Name: Customer #7a3f
- Email: ***@empresa.com
- Query: When will my order #4521 ship?

Answer the customer's query.
"""

In Case 1, the LLM has all the information but a leak exposes the real SSN, email, and address. In Case 2, the LLM can't personalize the response (it doesn't know the name or the email domain). In Case 3, the LLM knows there's a name (anonymized reference), the email domain (useful for corporate context), and has no access to the SSN or the address (data it doesn't need to answer about an order).

Case 3 is what you build in this module: protection calibrated by the type of data and the type of task.

Summary

This module builds the personal data protection layer that complements the Sanitization Pipeline from Module 4 — PII protection is different from general sanitization
The main focus is LLM02: Sensitive Information Disclosure, the vulnerability that happens when an LLM reveals sensitive data through memorization, context leakage, or cross-conversation bleed
The complete pipeline covers: PII scanning → pre-LLM redaction → data minimization → LLM → post-LLM redaction → retention policies → audit logging
Each capsule builds a block of the pipeline: the LLM02 threat (02), PII detection (03), PII redaction (04), data minimization (05), retention/encryption (06), compliance (07)
The central trade-off is privacy vs utility: redacting PII protects your users but reduces the context available to the LLM
The PII Protection Layer is the sixth artifact of the guide and integrates with all the previous artifacts in Module 8
Key tools: Presidio for enterprise-grade detection, spaCy for NER, regex for structured patterns

Next capsule: In capsule 02 you'll understand LLM02 in depth — how LLMs memorize training data, specific techniques for extracting sensitive data, real data leakage scenarios, and the regulatory implications of each type of leak. It's the foundation for understanding why each protection technique in capsules 03-07 is necessary.

Additional resources

OWASP LLM02: Sensitive Information Disclosure — Official documentation of the main vulnerability this module mitigates
Microsoft Presidio Documentation — PII detection and anonymization tool, core of this module
OWASP Top 10 for LLM Applications 2025 — Complete framework of LLM vulnerabilities
spaCy NER Models — Named Entity Recognition models for PII detection
GDPR Official Text — Official text of the General Data Protection Regulation
CCPA Official Text — California Consumer Privacy Act for compliance reference
NIST Privacy Framework — NIST's privacy framework, a complement to OWASP
EU AI Act — The EU's AI regulation, relevant to AI system compliance

Created: March 2026 Version: 1.0

← Previous8. Project: Secrets Management Setup Next →2. LLM02 in Detail: Sensitive Information Disclosure