PII Detection and Redaction Prompt Template

This prompt is designed for security engineers embedding privacy controls directly into AI pipelines. Its job is to accept unstructured text, detect personally identifiable information (PII) entities, and return a structured output that flags each entity with a redaction instruction. Use it before text is logged, stored, or passed to downstream models. This is not a general-purpose data classifier; it is a production guardrail for data exfiltration prevention. The prompt assumes the input may contain names, emails, phone numbers, financial data, or government identifiers, and it must balance high recall against over-redaction of benign terms.

Deploy this prompt in any pipeline stage where raw user input, third-party data, or unvetted documents enter your AI system. Common insertion points include: immediately after user input is received, before logging to observability platforms, prior to embedding generation for vector stores, and as a pre-processing step before any fine-tuned model inference. Do not use this prompt as a post-hoc audit tool on already-stored data; it is a preventative control, not a forensic one. The prompt is optimized for English-language PII patterns and common North American and European identifier formats. For CJK characters, RTL scripts, or jurisdiction-specific identifiers like Brazil's CPF or India's Aadhaar, you must extend the entity definitions and test against native-language adversarial examples.

This prompt is not a replacement for deterministic scrubbing libraries like Presidio or spaCy when you have known, high-throughput PII patterns. Use it when you need contextual understanding—for example, distinguishing a person's name from a street name, or recognizing that a nine-digit number is a Social Security Number rather than an invoice ID. The model's strength is disambiguation, not raw pattern matching. Always pair this prompt with a validation layer that checks the output schema, flags missing required fields, and compares detected entities against a regex-based baseline. If the model's recall drops below your defined threshold on a golden PII test set, fail closed and route the text to a human review queue rather than allowing unredacted data to propagate.

This template gives you a complete, self-contained prompt for PII detection and redaction. It defines the entity types to scan for, the redaction rules to apply, and the exact JSON schema the model must return. The prompt is designed to work across model providers—OpenAI, Anthropic, and open-weight models that support structured output instructions—without modification beyond swapping the [INPUT_TEXT] placeholder.

textCopy
You are a PII detection and redaction system. Analyze the text below and return a valid JSON object. Your task is to detect all instances of personally identifiable information (PII). For each detected entity, provide the entity type, the original text, a redacted version, and a confidence score.

### PII Entity Types to Detect
- PERSON_NAME: Full names of individuals.
- EMAIL_ADDRESS: Email addresses.
- PHONE_NUMBER: Phone and fax numbers.
- CREDIT_CARD: Credit card numbers.
- BANK_ACCOUNT: Bank account numbers.
- SSN: Social Security numbers.
- PASSPORT_NUMBER: Passport numbers.
- DRIVERS_LICENSE: Driver's license numbers.
- IP_ADDRESS: IPv4 and IPv6 addresses.
- PHYSICAL_ADDRESS: Street addresses.
- DATE_OF_BIRTH: Specific birth dates.

### Redaction Rules
- Replace PERSON_NAME with [REDACTED_NAME].
- Replace EMAIL_ADDRESS with [REDACTED_EMAIL].
- Replace PHONE_NUMBER with [REDACTED_PHONE].
- Replace CREDIT_CARD with [REDACTED_CCN].
- Replace BANK_ACCOUNT with [REDACTED_ACCOUNT].
- Replace SSN with [REDACTED_SSN].
- Replace PASSPORT_NUMBER with [REDACTED_PASSPORT].
- Replace DRIVERS_LICENSE with [REDACTED_LICENSE].
- Replace IP_ADDRESS with [REDACTED_IP].
- Replace PHYSICAL_ADDRESS with [REDACTED_ADDRESS].
- Replace DATE_OF_BIRTH with [REDACTED_DOB].

### Output Schema
Return a valid JSON object with a "redacted_text" string and a "findings" array. Each finding must have "entity_type", "original_text", "redacted_text", and "confidence" (a float between 0.0 and 1.0).

### Constraints
- Do not redact company names, product names, or job titles.
- Do not redact publicly known information like city names unless part of a full address.
- If no PII is found, return an empty findings array and the original text unchanged.

### Input Text
[INPUT_TEXT]

Adapt this template by adjusting the entity type list to match your compliance requirements. For HIPAA workloads, add PHI-specific types like medical record numbers and health plan beneficiary numbers. For PCI DSS, tighten the credit card detection to include track data and PIN blocks. If you're using a model that supports tool calling, wrap this prompt in a function definition with the output schema as the parameters object—this gives you stronger schema adherence than text-only prompting. Always run the output through a JSON schema validator before ingesting the redacted text into downstream systems; a malformed findings array or missing redacted_text field should trigger a retry or fallback to a regex-based redaction pipeline. For high-risk production use, pair this prompt with a human review step when confidence scores fall below 0.85 or when the input contains mixed PII and non-PII terms that could cause over-redaction.

Integrate this PII detection prompt as a synchronous pre-processing gate in your application middleware before any user input or retrieved document reaches the main model or is stored. The prompt is designed to be called with response_format set to json_object to enforce schema compliance. On the application side, parse the JSON response and immediately validate that every original_text string in the findings array is a direct substring of the original input. This prevents a hallucinated or malformed response from instructing you to redact text that doesn't exist, which would corrupt the downstream payload.

Implement a retry layer with a stricter JSON schema and an explicit error message if the initial parsing or substring validation fails. For observability, log the count of redacted entities by type (e.g., EMAIL: 3, PHONE: 2) to monitor detection trends, but never log the original_text field itself to avoid creating a new PII leak in your telemetry. For high-risk domains like healthcare or finance, route any finding with a confidence score between 0.6 and 0.85 to a human review queue. This captures ambiguous cases where the model is uncertain, preventing both missed PII and over-redaction of benign terms that happen to match a pattern.

To reduce latency and cost, combine this LLM-based prompt with a deterministic regex pre-scan for known, high-precision patterns like credit card numbers (validated with a Luhn check) and standard email formats. Strip these matches before calling the LLM and merge the results. This hybrid approach catches low-hanging fruit instantly and reserves the LLM for contextual, ambiguous PII like names or organizations. The final output should be a single, unified redaction map that your application can apply to the text before it proceeds to any other processing step.