PII Redaction in User Search Queries Prompt Template

This prompt is designed for a single, high-stakes job: stripping personally identifiable information (PII) from user search queries before those queries touch any downstream system. The ideal user is a platform engineer, RAG architect, or backend developer who owns a retrieval pipeline and needs to prevent email addresses, phone numbers, social security numbers, and other personal data from being logged, embedded, or sent to third-party APIs. You should use this prompt when your application accepts free-text user input that will be passed to a vector database, a search index, an embeddings model, or an observability stack where PII exposure constitutes a compliance or security incident.

This prompt is not a general-purpose data sanitizer. Do not use it for redacting PII from retrieved documents, generated answers, or long-form user content. It is specifically tuned for the short, intent-heavy strings typical of search queries. The prompt expects two inputs: the raw user query and a configuration object that defines which PII categories to target and the desired redaction strategy (e.g., mask, replace with a type token, or remove entirely). The output is a structured JSON object containing the redacted query string and a detected-PII manifest, which your application can use for audit logging or to decide whether to block the query entirely. If your use case involves regulated data under GDPR, HIPAA, or PCI-DSS, this prompt is a pre-retrieval safety net, not a compliance guarantee—you must still implement human review and evidence grounding for high-risk workflows.

Before wiring this into production, understand its failure modes. The most common is over-redaction: the model strips terms that look like PII but are not, such as product codes that resemble serial numbers or usernames that match name patterns. The second is under-redaction: the model misses PII in non-standard formats, such as phone numbers with unusual country codes or emails with new top-level domains. Your eval suite must test both. After reading this section, proceed to the prompt template to copy the exact instructions, then to the implementation harness to learn how to wrap it with validation, retries, and a human-in-the-loop escape hatch for high-risk deployments.

This template is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It uses square-bracket placeholders for all dynamic inputs, constraints, and configuration. Before using it in production, replace each placeholder with the actual values, schemas, or references your application provides at runtime. The prompt instructs the model to return a redacted query string and a structured manifest of detected PII, making the output machine-readable for downstream validation and logging.

textCopy
You are a privacy-preserving query processor. Your task is to redact personally identifiable information (PII) from a user's search query before it is sent to retrieval systems, logs, or third-party APIs.

INPUT QUERY:
[INPUT]

REDACTION RULES:
[CONSTRAINTS]

OUTPUT SCHEMA:
Return a valid JSON object with exactly these fields:
{
  "redacted_query": "string (the query with all detected PII replaced by [REDACTED] or a type-specific token like [EMAIL] or [PHONE])",
  "pii_detected": [
    {
      "type": "string (one of: EMAIL, PHONE, SSN, CREDIT_CARD, PERSON_NAME, ADDRESS, IP_ADDRESS, DOB, OTHER)",
      "original": "string (the exact PII substring found)",
      "replacement": "string (the token used to replace it)",
      "confidence": "number (0.0 to 1.0)"
    }
  ],
  "redaction_count": "number (total PII instances found and redacted)"
}

INSTRUCTIONS:
1. Scan the entire input query for PII.
2. Replace each detected PII instance with a type-specific token: [EMAIL], [PHONE], [SSN], [CREDIT_CARD], [PERSON_NAME], [ADDRESS], [IP_ADDRESS], [DOB], or [REDACTED] for other types.
3. Do not redact non-PII terms, technical jargon, product names, or general business language.
4. If no PII is detected, return the original query unchanged and an empty pii_detected array.
5. Preserve all original whitespace, punctuation, and non-PII query structure.
6. Do not add commentary, explanations, or apologies. Return only the JSON object.

EXAMPLES:
[EXAMPLES]

RISK LEVEL: [RISK_LEVEL]

To adapt this template, replace [CONSTRAINTS] with your organization's specific PII definitions and redaction policies. For example, you might add rules to preserve internal employee IDs while redacting external customer data. The [EXAMPLES] placeholder should be populated with 2–4 few-shot demonstrations that match your domain's query patterns and PII types. Set [RISK_LEVEL] to HIGH if the prompt will run in a regulated context, which should trigger additional validation and human review steps in your harness. After copying, test the prompt against a golden dataset of queries containing known PII and verify that the JSON output parses correctly and that no PII leaks into the redacted_query field.

This prompt is designed to sit as a pre-retrieval gate in your query pipeline. Before any user query reaches your embedding model, vector database, or third-party search API, it must pass through this redaction step. The prompt returns two artifacts: a redacted_query safe for downstream processing and a pii_detections manifest that records what was found and how it was masked. Your application code should never log or transmit the original query beyond this redaction point. Store the pii_detections manifest in your audit system, but ensure it does not contain the raw PII values—only the detection types, positions, and replacement tokens.

Wire the prompt into your query processing middleware with a strict contract. The function signature should accept the raw user query string and return a typed object matching the output schema. Implement a JSON schema validator (such as ajv for Node.js or pydantic for Python) to enforce that the model response contains both redacted_query and pii_detections fields before the pipeline continues. If validation fails, retry once with a stronger constraint instruction appended to the prompt. If the second attempt also fails, block the query and return a generic error to the user—never fall back to passing the raw query through. For high-throughput systems, consider using a faster, smaller model for this task (such as Claude Haiku or GPT-4o-mini) and reserve larger models for the generation step.

Implement a pre-flight check that compares the input and output query lengths. If the redacted_query is identical to the original input, log a NO_PII_DETECTED event and proceed. If the redacted query is significantly shorter or contains placeholder tokens like [EMAIL_REDACTED] or [PHONE_REDACTED], log a PII_REDACTED event with the count and types from the manifest. Add an eval harness that runs a golden set of queries containing known PII (emails, SSNs, phone numbers, credit card numbers) and verifies that every instance is caught. Also include negative test cases with non-PII terms that resemble PII patterns (e.g., version numbers like v3.4.1, file paths with numeric segments, or scientific notation) to measure over-redaction rates. Flag any over-redaction above 2% for prompt tuning.

For regulated deployments, insert a human review step when the confidence scores in pii_detections fall below a configurable threshold (e.g., 0.85). Queue these uncertain detections for operator review before the redacted query proceeds. The review interface should show the original query with detected spans highlighted, the proposed redaction, and accept/override controls. All review decisions should be logged with operator identity and timestamp for audit trails. Never store the original query in the review log—only the detection metadata and the operator's action. If your system processes queries from authenticated users, consider passing a user role or clearance level as additional context so the prompt can adjust its sensitivity for internal versus external users.