PII Redaction with Contextual Re-identification Risk Prompt Template

This prompt is designed for privacy engineers and QA testers who need to validate data sanitization pipelines before they reach production AI systems. It goes beyond simple regex-based PII scrubbing by instructing the model to assess whether remaining contextual information could enable re-identification of redacted entities. Use this prompt when you are building or testing a pipeline that must balance data utility against the risk of indirect identification through cross-field correlation, geographic inference, or temporal patterns.

This is an edge-case testing tool, not a primary redaction system. It belongs in your pre-deployment QA harness, not as the sole defense in a live data processing workflow. The prompt expects a structured input containing the redacted text, the original entity types that were masked, and the surrounding metadata. It returns a risk assessment with specific re-identification vectors, not just a pass/fail flag. You should run this against a curated set of boundary examples—records with rare combinations of demographics, small geographic units, or unique temporal sequences—before promoting any redaction pipeline.

Do not use this prompt for real-time redaction of production traffic. It is a diagnostic tool for finding weaknesses in your anonymization logic. After running the assessment, feed the identified risks back into your redaction rules, aggregation thresholds, or differential privacy parameters. Always combine the output with a human review step for high-risk findings, and log the assessments as audit evidence for your data protection impact assessments.

The following prompt template is designed for privacy engineers testing data sanitization pipelines. It instructs the model to perform two concurrent tasks: redact personally identifiable information (PII) from the input text, and simultaneously analyze the remaining context for re-identification risk. This dual-output structure is critical because naive redaction often leaves behind correlated data points (e.g., a unique job title, age, and ZIP code) that can be trivially cross-referenced to re-identify an individual. Copy the template, replace the square-bracket placeholders with your specific inputs, and run it in your evaluation harness.

textCopy
SYSTEM:
You are a privacy-preserving data sanitization engine. Your task is to redact personally identifiable information (PII) from the provided text and then assess whether the remaining, non-redacted context could be used alone or in combination to re-identify the redacted individual. You must follow the redaction rules, output schema, and constraints exactly.

REDACTION RULES:
[REDACTION_RULES]

OUTPUT SCHEMA:
You must produce a valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "redacted_text": "The full input text with all PII replaced by the specified placeholder tokens.",
  "risk_assessment": {
    "risk_level": "LOW | MEDIUM | HIGH | CRITICAL",
    "risk_rationale": "A concise explanation of which remaining data points, if any, could contribute to re-identification and why.",
    "contributing_factors": ["A list of specific non-redacted fields or contextual clues that increase risk."]
  },
  "utility_impact": "An assessment of how much the redaction degrades the text's analytical or operational utility: NONE | LOW | MEDIUM | HIGH."
}

CONSTRAINTS:
[CONSTRAINTS]

EXAMPLES:
[EXAMPLES]

USER:
Input Text:
[INPUT]

To adapt this template for your pipeline, start by defining the [REDACTION_RULES]. Be explicit about which entity types to target (e.g., names, emails, phone numbers, SSNs) and the placeholder format to use (e.g., [REDACTED-NAME]). The [CONSTRAINTS] placeholder is where you enforce domain-specific policies, such as 'Never redact medical conditions if it would obscure a diagnosis' or 'Preserve all date ranges for temporal analysis.' Populate [EXAMPLES] with few-shot demonstrations that show the model how to handle ambiguous cases, such as a public figure's name in a news article versus a private individual's name in a support ticket. Finally, replace [INPUT] with the text to be sanitized. After execution, always validate the output JSON against your schema before allowing the redacted text to be stored or forwarded to another system.

This prompt is designed to be a critical component in a data sanitization pipeline, not a standalone chat interaction. The primary integration point is immediately before data leaves a trusted boundary—for example, before sending user-generated text to a third-party LLM API, logging it to an external observability platform, or storing it in an analytics warehouse. The application should call this prompt synchronously, blocking the egress until a valid, risk-assessed redacted payload is returned. Treat the model's output as a structured security assertion, not a suggestion.

To wire this in, construct an API call with the [INPUT_TEXT] and a strict [OUTPUT_SCHEMA] requiring a JSON object with three fields: redacted_text (string), reidentification_risk (an enum of LOW, MEDIUM, HIGH), and risk_rationale (a string array of specific reasons, e.g., 'rare disease name combined with age'). The application layer must validate this schema strictly. If the model returns malformed JSON, a missing field, or an unexpected risk level, implement a retry loop with a maximum of 2 attempts, feeding the raw output and a validation error message back into the prompt's [PREVIOUS_OUTPUT_AND_ERROR] placeholder. After 2 failures, the system must fail closed: block the data egress and log the incident for manual review. For MEDIUM or HIGH risk outputs, do not automatically pass the redacted_text through. Instead, route the original and redacted text to a human review queue, presenting the model's risk_rationale to help the reviewer decide whether to approve the redacted version, apply stronger redaction, or block the data entirely.

Model choice matters here. A model with strong instruction-following and JSON mode capabilities (like gpt-4o or claude-3.5-sonnet) is essential to minimize retry rates on the output schema. Crucially, do not use a model that has been fine-tuned on your company's proprietary data for this task, as it may have memorized PII that could leak into the rationale. For logging, record the prompt version, the full validated JSON output, the retry count, and the final disposition (auto-passed, escalated, blocked) without storing the original [INPUT_TEXT] in the same log stream. The next step is to build a regression test suite using the edge-case examples from this playbook—null inputs, cross-field correlations, and maximum-length texts—and run it against this harness before any prompt or model version change to prevent silent redaction failures in production.