PII Redaction Policy Enforcement Prompt

This prompt is designed for privacy-sensitive assistant deployments that process user data across multiple conversation turns. Its primary job is to act as a policy enforcement gate: it evaluates whether an assistant's generated response or stored session state contains personally identifiable information (PII) that violates a defined redaction policy. The ideal user is an AI engineer or platform developer integrating a chat assistant into a regulated product, such as a healthcare intake form, a financial advisory copilot, or a customer support agent handling account details. You need this prompt when your system-level instructions alone are insufficient to prevent PII leakage, especially in long-running sessions where context drift can erode initial privacy constraints.

Use this prompt as a post-generation validation step before a response is sent to the user or written to a persistent session log. It requires a clear [REDACTION_POLICY] specifying which PII categories to detect (e.g., names, emails, credit card numbers, SSNs), a [SESSION_CONTEXT] containing recent turns, and the [ASSISTANT_OUTPUT] to be audited. The prompt is not a replacement for deterministic input sanitization or API-level PII scrubbing; it is a semantic safety net that catches contextual leaks, such as an assistant inferring and restating a user's name from a previous turn. It should not be used for real-time, character-by-character redaction in streaming outputs, nor as the sole defense in environments requiring certified data loss prevention (DLP) systems.

Before deploying this prompt, define the exact failure modes you are guarding against. Common risks include the assistant echoing a user's full name after a casual introduction, exposing a phone number embedded in a multi-turn troubleshooting dialogue, or writing unmasked PII into a session summary. The prompt's output includes a structured audit trail, which is essential for compliance review and debugging false positives. If your application operates in a jurisdiction with strict data residency or privacy regulations (e.g., GDPR, HIPAA), this prompt should be paired with a human review step for any redacted output or policy violation flag. Do not rely on this prompt to classify data it cannot see; ensure your [SESSION_CONTEXT] includes all turns that might contain PII, as omission is a primary cause of silent failures.

This prompt template is designed to be inserted into a multi-turn assistant pipeline whenever a response is generated or state is stored. It evaluates the proposed output against a configurable PII redaction policy and produces either a sanitized version of the output or a policy-compliant refusal. The template uses square-bracket placeholders so you can wire in your specific policy definitions, risk levels, and output schemas without modifying the core logic.

textCopy
You are a PII Redaction Policy Enforcement agent. Your job is to inspect the [OUTPUT_TO_CHECK] against the active [REDACTION_POLICY] and produce a compliant result.

[REDACTION_POLICY] defines:
- Which PII categories must be redacted (e.g., name, email, phone, SSN, address, IP, financial account numbers).
- The redaction method: [REDACT] (replace with [REDACTION_TOKEN]), [REFUSE] (block the output and return a refusal message), or [MASK] (partial masking, e.g., "j***@example.com").
- The [RISK_LEVEL] threshold: [LOW] (redact only explicit PII), [MEDIUM] (redact explicit and inferred PII), or [HIGH] (refuse any output that may contain or imply PII).

[OUTPUT_TO_CHECK] is the assistant's proposed response or state update that must be inspected.

Your response must be valid JSON matching this schema:
{
  "decision": "pass" | "redact" | "refuse",
  "redacted_output": "string or null if refused",
  "audit_trail": [
    {
      "pii_type": "string",
      "original_value": "string",
      "action": "redacted" | "masked" | "blocked",
      "location": "string describing where in the output it was found",
      "confidence": "high" | "medium" | "low"
    }
  ],
  "refusal_message": "string or null if not refused",
  "policy_version": "string from [POLICY_VERSION]"
}

Rules:
1. If [RISK_LEVEL] is [HIGH] and any PII is detected, you must refuse the entire output.
2. If [RISK_LEVEL] is [MEDIUM] and inferred PII is detected (e.g., context suggests an email without explicit @ sign), treat it as PII.
3. If [RISK_LEVEL] is [LOW], only redact explicit matches and allow the output through.
4. Never output the original PII values outside the audit_trail. The redacted_output field must be safe to display.
5. If no PII is detected, return "decision": "pass" with an empty audit_trail and the original output in redacted_output.
6. The audit_trail must include every detected PII instance with its type, action taken, and confidence.

[EXAMPLES]
Example 1:
Input: "My name is John Smith and my email is john@example.com"
Policy: [REDACT], [MEDIUM]
Output: {"decision": "redact", "redacted_output": "My name is [REDACTED] and my email is [REDACTED]", "audit_trail": [{"pii_type": "name", "original_value": "John Smith", "action": "redacted", "location": "start of message", "confidence": "high"}, {"pii_type": "email", "original_value": "john@example.com", "action": "redacted", "location": "end of message", "confidence": "high"}], "refusal_message": null, "policy_version": "1.0"}

Example 2:
Input: "The account number is 4111-1111-1111-1111"
Policy: [REFUSE], [HIGH]
Output: {"decision": "refuse", "redacted_output": null, "audit_trail": [{"pii_type": "financial_account", "original_value": "4111-1111-1111-1111", "action": "blocked", "location": "end of message", "confidence": "high"}], "refusal_message": "I cannot process this request because it contains sensitive financial information. Please remove the account number and try again.", "policy_version": "1.0"}

To adapt this template, replace the square-bracket placeholders with your actual policy definitions before sending it to the model. The [REDACTION_POLICY] placeholder should contain a concrete list of PII categories and their handling rules. The [RISK_LEVEL] should be set based on your deployment context—use HIGH for regulated industries where any PII leakage is unacceptable. Wire the JSON output into a post-processing validator that checks the schema before the redacted output reaches the user. For production deployments, log every audit_trail entry to your monitoring system and set up an alert if the refusal rate spikes, which may indicate an upstream data leak or a policy misconfiguration.

The PII Redaction Policy Enforcement Prompt is not a standalone filter—it is a policy decision point that must be integrated into your assistant's response pipeline. The prompt receives the assistant's draft response, the session's redaction policy, and any stored state, then produces a structured verdict: either a redacted output or a policy-compliant refusal, along with a detection audit trail. This prompt should run as a synchronous pre-release gate before any assistant response reaches the user. If your system stores conversation state or summaries, you must also run this prompt against any state payloads before they are written to your database or passed to downstream retrieval systems. The prompt's value is in the audit trail it produces—without it, you have no evidence that redaction was attempted or why a refusal was issued.

Pipeline placement: Insert this prompt between the assistant's response generation step and the user-facing delivery step. The typical flow is: (1) assistant generates a draft response, (2) draft is passed to this prompt along with [REDACTION_POLICY] and [SESSION_CONTEXT], (3) the prompt returns a JSON verdict with action (redact/refuse/pass), redacted_output (if applicable), and detections array, (4) your application layer inspects the verdict and either delivers the redacted output, surfaces the refusal message, or escalates for human review. Do not rely on the model to enforce the policy inline during response generation—separation of generation and enforcement gives you independent auditability and makes policy changes deployable without retuning your generation prompt.

Validation and retry logic: Parse the prompt's JSON output and validate it against a strict schema before acting on it. Required fields: action (enum: redact, refuse, pass), redacted_output (string, required when action is redact), refusal_message (string, required when action is refuse), detections (array of objects with type, confidence, location, redaction_applied). If validation fails, retry once with the validation error injected into the prompt's [PREVIOUS_ERROR] placeholder. If the second attempt also fails validation, escalate to human review and log the raw output. For high-risk domains (healthcare, finance, legal), consider requiring human approval for any redact action where confidence is below 0.9 or where the detection count exceeds a threshold you define in [RISK_THRESHOLDS].

Logging and audit trail: Log every invocation of this prompt, including the input draft, the full JSON verdict, the validation result, and the final action taken. The detections array is your compliance evidence—store it alongside the conversation turn for audit review. If you are using a model router or fallback chain, ensure the prompt runs against the final draft response, not an intermediate candidate. For session state redaction, run this prompt against any serialized state before storage and log the redaction verdict separately from the conversation log. This separation lets auditors verify that PII was removed from state without reconstructing the full conversation.

Model choice and latency budget: This prompt benefits from models with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable defaults. Expect 200-800ms of added latency depending on input length and model. If your latency budget is tight, consider running this prompt asynchronously for low-risk turns (where [RISK_LEVEL] is low) and synchronously for medium and high risk turns. Never skip the prompt entirely—a missed redaction is a compliance incident. For local or air-gapped deployments, test this prompt thoroughly with open-weight models; structured output reliability varies significantly and you may need to add a repair step using the Output Repair and Validation Prompts pillar patterns.