PII Redaction Guardrail Prompt for Customer Support

This prompt is designed for support platform engineers who need a reliable, pre-processing guardrail that detects and masks personally identifiable information (PII) in user messages and agent responses before the text enters any downstream AI workflow, analytics pipeline, or persistent store. The primary job-to-be-done is reducing data exposure risk by replacing PII entities with typed placeholders and confidence scores, allowing the support system to operate on redacted text while preserving the semantic structure needed for intent detection, routing, and summarization. The ideal user is an engineer integrating this prompt into a customer support pipeline where tickets, chat transcripts, or email threads may contain credit card numbers, email addresses, physical addresses, phone numbers, social security numbers, or other regulated identifiers. Required context includes the raw text to be scanned, a defined list of PII entity types to detect, and a clear output schema that downstream systems can parse without ambiguity.

Use this prompt when the support workflow involves automated processing of user-submitted text and you need a deterministic, auditable redaction layer that operates before any model generates a response or stores data. It is appropriate for synchronous pre-processing in ticket creation, chat intake, and email parsing pipelines where latency tolerance is low and recall on high-risk entity types must be near-perfect. The prompt works best when paired with a validation harness that checks the output schema, verifies that detected entities are actually redacted in the output text, and measures recall against a labeled golden dataset containing examples of credit cards, emails, phone numbers, and addresses. Do not use this prompt as the sole defense for compliance with GDPR, HIPAA, or PCI-DSS. It is a probabilistic guardrail, not a cryptographic guarantee. It should be one layer in a defense-in-depth strategy that includes deterministic pattern matching, API-based PII scanners, and human review for high-risk cases. It is also not a replacement for data minimization at the source—if you can avoid collecting PII in the first place, do so.

Before implementing this prompt, confirm that you have a labeled evaluation set covering the entity types your support channel actually encounters. Run the prompt against that set and measure recall, precision, and the false-positive rate on non-PII text that resembles PII (e.g., fake credit card numbers in test messages, formatted IDs that look like SSNs). If your support domain includes unstructured free-text fields where users paste logs, error messages, or code snippets, test the prompt's behavior on those inputs—code and logs often contain strings that match PII patterns but are not actual PII. Finally, decide whether redaction should be reversible or irreversible in your pipeline. This prompt produces redacted text with entity type labels, which supports both audit trails and downstream re-identification if required, but reversible redaction introduces its own security considerations that must be addressed in the application layer, not the prompt.

This prompt template is designed to be injected into the system instructions of an AI model acting as a PII redaction guardrail. Its primary job is to receive a raw customer support message and return a structured, redacted version. The template uses square-bracket placeholders for all dynamic inputs, such as the message content, the list of PII entity types to scan for, and the desired output schema. This separation allows you to adapt the guardrail to different regulatory environments (e.g., GDPR vs. CCPA) or risk levels by simply changing the [PII_ENTITY_TYPES] list without rewriting the core instruction.

markdownCopy
You are a PII Redaction Guardrail. Your only task is to scan the provided text for personally identifiable information (PII) and return a redacted version in a strict JSON format. Do not answer the user's question or perform any other task.

### Input Text
[USER_MESSAGE]

### PII Entity Types to Redact
Scan for and redact the following entity types. Replace the detected text with the corresponding placeholder tag.
[PII_ENTITY_TYPES]

### Redaction Rules
1.  **Replace, Don't Remove:** Always replace the PII text with its placeholder tag (e.g., `[EMAIL_ADDRESS]`). Do not delete the text or leave the field empty, as this can break sentence structure.
2.  **Full Redaction:** Redact the entire entity. For example, redact the full phone number, not just the last four digits.
3.  **Confidence Scoring:** For each redacted entity, provide a confidence score between 0.0 and 1.0. If you are unsure, use a lower score but still redact the text.
4.  **No Commentary:** Do not add any text outside the required JSON output.

### Output Schema
Return your response as a single, valid JSON object matching this schema:
{
  "redacted_text": "string, the full text with all detected PII replaced by placeholder tags",
  "redactions": [
    {
      "original_text": "string, the exact PII text that was found",
      "placeholder": "string, the placeholder tag used for redaction",
      "entity_type": "string, the category of PII from the provided list",
      "confidence": "float, a score between 0.0 and 1.0"
    }
  ]
}

### Example
Input: "My name is John Doe and my email is john.doe@example.com. My credit card is 4111-1111-1111-1111."
PII Entity Types: ["PERSON_NAME", "EMAIL_ADDRESS", "CREDIT_CARD"]
Output:
{
  "redacted_text": "My name is [PERSON_NAME] and my email is [EMAIL_ADDRESS]. My credit card is [CREDIT_CARD].",
  "redactions": [
    {
      "original_text": "John Doe",
      "placeholder": "[PERSON_NAME]",
      "entity_type": "PERSON_NAME",
      "confidence": 0.99
    },
    {
      "original_text": "john.doe@example.com",
      "placeholder": "[EMAIL_ADDRESS]",
      "entity_type": "EMAIL_ADDRESS",
      "confidence": 0.99
    },
    {
      "original_text": "4111-1111-1111-1111",
      "placeholder": "[CREDIT_CARD]",
      "entity_type": "CREDIT_CARD",
      "confidence": 0.99
    }
  ]
}

To adapt this template, start by defining the [PII_ENTITY_TYPES] list. A minimal set for customer support might be ["CREDIT_CARD", "EMAIL_ADDRESS", "PHONE_NUMBER"]. For a stricter compliance environment, you would expand it to include ["PERSON_NAME", "PHYSICAL_ADDRESS", "SSN", "PASSPORT_NUMBER"] and others. The [USER_MESSAGE] placeholder should be populated with the raw, unredacted text from the customer. Before deploying, test this prompt against a golden dataset of messages containing known PII to ensure the model's recall is high, especially for the entity types that carry the most regulatory risk. A common failure mode is the model failing to redact PII that is embedded in a code block or a long, unbroken string, so include these edge cases in your evaluations.

The PII redaction guardrail prompt should sit as a pre-processing step before any user message or agent draft reaches a generative model, and as a post-processing step before any agent response is sent to the customer. In a typical support platform, this means wrapping the prompt in a thin service layer that intercepts messages, calls the model with the redaction template, and then passes only the redacted text downstream. The service must handle the full lifecycle: receive raw text, invoke the model, parse the structured output, validate the redaction map, log the result, and decide whether to block, redact, or escalate.

Validation is the critical step. The prompt returns a JSON object with redacted_text, findings (entity type, original value, confidence score, and redaction placeholder), and a redaction_applied boolean. Before trusting the output, your harness must confirm that every finding with a confidence score above your threshold (e.g., 0.85) has its original value actually removed from redacted_text. A simple string-search validator that confirms no high-confidence original value appears in the redacted output catches the most dangerous failure mode: the model claiming it redacted something while leaving the PII intact. If validation fails, retry once with an explicit error message injected into the prompt's [CONSTRAINTS] field: "Previous attempt failed validation: the following values were found in the redacted text: [list]. Remove them completely." If the retry also fails, escalate to a human review queue and do not forward the message.

Logging and audit trail design are non-negotiable for PII handling. Your harness should log the findings array, the validation result, the retry count, and the final disposition (passed, redacted, escalated) to an immutable audit store. Do not log the original PII values in plaintext; log only the entity type, confidence score, and a hash of the original value for deduplication and debugging. This gives your trust and safety team the evidence they need without creating a secondary PII leak in your observability stack. For high-risk entity types like credit card numbers or government IDs, configure the harness to always require human approval before the redacted text is used, regardless of confidence score. Wire this into your support platform's existing approval queues rather than building a separate review tool.

Model choice matters for latency and cost. PII redaction is a high-volume, low-latency task in customer support. Use a fast, cost-efficient model (e.g., a small hosted model or a distilled variant) for the redaction step, reserving larger models for the actual support conversation. The structured output schema in the prompt is designed to work reliably with smaller models when the validation harness is in place. If you observe entity recall dropping below 95% on your eval set (credit cards, emails, phone numbers, addresses), switch to a more capable model for the redaction step before adding complexity to the prompt. The harness should track recall and precision metrics per entity type and alert when drift exceeds your threshold. Start with a strict validation harness and a small model; upgrade the model only when the harness proves the smaller model cannot meet your recall targets.