PII and Personal Data Detection Prompt Template

This prompt is designed for security engineers building automated data sanitization pipelines. Its primary job is to act as an ingress-layer control, scanning unstructured text for Personally Identifiable Information (PII) such as Social Security Numbers, email addresses, phone numbers, physical addresses, and dates of birth before that data reaches downstream models, application logs, or long-term storage. The ideal user is someone who needs a programmatic, structured JSON output with confidence scores to make a deterministic routing decision—redact the fields, quarantine the entire record for human review, or allow the data to proceed. This is not a general-purpose data exploration tool; it is a production safeguard.

Use this prompt when you need to enforce a data handling policy at the boundary of an AI system. For example, you might integrate it into an API middleware layer that inspects every user input to a chatbot, or into an ETL pipeline that processes customer feedback before it's stored in a data warehouse. The prompt is most effective when combined with a strict [OUTPUT_SCHEMA] that defines the exact JSON structure your downstream code expects, including fields for entity_type, matched_text, confidence_score, and char_offset. You should also provide a [CONSTRAINTS] block specifying your organization's definition of PII, such as whether you need to flag partial matches or obfuscated data (e.g., jane [dot] doe [at] email [dot] com). The confidence score is your primary lever for routing: a high-confidence SSN match can be automatically redacted, while a low-confidence address match might be routed to a manual review queue.

Do not use this prompt as a standalone compliance solution. It is a probabilistic detection layer, not a guarantee. It will fail on novel obfuscation techniques and can produce false positives on non-PII numeric patterns like order IDs or invoice numbers that resemble SSNs. Never use it to make automated decisions that have a legal or financial impact on an individual without a human-in-the-loop review step for flagged content. Before deploying, you must establish a robust evaluation harness using a golden dataset that includes both obvious PII and tricky negative cases. Your next step should be to copy the prompt template, define your strict output schema, and run it against your eval set to calibrate the confidence threshold that balances your risk tolerance against the operational cost of false alarms.

This template is the core instruction set for a PII detection model. It is designed to be dropped directly into your application's prompt layer. The prompt enforces a strict JSON-only output, which is critical for preventing the model from adding conversational filler that would break a downstream parser. The schema includes character-level indices, allowing your application to redact or mask the original text programmatically without relying on the model to perform the redaction itself.

textCopy
You are a PII detection system. Analyze the text provided below. Your task is to detect and extract any instances of Personally Identifiable Information (PII). You must return ONLY a valid JSON object conforming to the specified schema. Do not include any explanatory text outside the JSON object.

PII types to detect:
- SSN (US Social Security Number)
- EMAIL (Email Address)
- PHONE (Phone Number, any international format)
- ADDRESS (Physical Street Address)
- DOB (Date of Birth)

For each detected instance, provide:
- The exact text match.
- The character start and end index of the match in the original text.
- A confidence score between 0.0 and 1.0.
- A brief reason for the confidence score if it is below 0.9.

If no PII is detected, return an empty findings array.

Text to analyze:
"""
[INPUT_TEXT]
"""

Output JSON Schema:
{
  "findings": [
    {
      "type": "string",
      "match": "string",
      "start_char": "integer",
      "end_char": "integer",
      "confidence": "number",
      "reason": "string"
    }
  ]
}

To adapt this template, replace the [INPUT_TEXT] placeholder with the actual user-generated or system-generated text you need to scan. If your use case requires additional PII types, such as credit card numbers or driver's license IDs, add them to the bulleted list and ensure your downstream validation logic can handle the new type strings. For high-risk domains like healthcare or finance, you should increase the strictness by adding a [CONSTRAINTS] section that explicitly instructs the model to flag borderline cases for human review and to never guess on ambiguous numeric patterns.

Before deploying, you must pair this prompt with a JSON validation harness. The model may occasionally return malformed JSON, especially for very long inputs or edge cases with special characters. Your application logic should validate the output against the schema, retry with an error message if parsing fails, and log any instance where the start_char and end_char indices do not correctly map back to the expected match in the source text. This index verification is a critical eval step to prevent silent data corruption during redaction.

Integrate this prompt as a synchronous pre-processing step within your application's middleware or API gateway. Before any user-generated text reaches a model, database, or logging pipeline, it should pass through this detection layer. The prompt expects a single [INPUT_TEXT] and returns a JSON object containing detected PII types, their values, and confidence scores. Your application must treat this as a blocking step: the downstream workflow should not proceed until the detection response is received and validated. For high-throughput systems, consider deploying this prompt against a fast, cost-efficient model like GPT-4o-mini or Claude Haiku, reserving more powerful models only for ambiguous cases that require re-evaluation.

On receiving the model's response, always validate the JSON structure against your expected schema before acting on any findings. A retry loop with a maximum of 2 attempts is recommended for handling malformed JSON or schema violations. If the model fails to return valid JSON after 2 retries, log the failure, flag the input for manual review, and block downstream processing. For high-confidence SSN or email matches (confidence >= 0.85), consider immediate redaction or tokenization before the text moves further through your system. For low-confidence matches or ambiguous PII types like dates of birth that could be benign, route the original text and the model's findings to a human review queue. This prevents over-redaction that could strip useful context while still catching clear violations.

Logging requires careful design. Never log the raw [INPUT_TEXT] alongside PII findings in plaintext. Instead, log a SHA-256 hash of the original text, the detected PII types, their confidence scores, and the action taken (redacted, queued, passed). This creates an audit trail that proves due diligence without creating a secondary PII store in your logs. If your application processes data subject to GDPR, HIPAA, or PCI-DSS, ensure your logging pipeline is covered by your existing data protection agreements and retention policies. For regulated environments, the human review queue should operate within the same compliance boundary as the original data processing, and reviewers should have clear instructions on when to redact, escalate, or clear a finding.