PII Detection Flag Prompt Template

This prompt is a privacy engineering tool for the detection stage of a data pipeline. Its job is to scan a block of unstructured text and return a structured set of boolean flags indicating the presence or absence of specific Personally Identifiable Information (PII) types. The ideal user is a backend engineer, data platform developer, or AI product builder who needs to programmatically decide what to do with a piece of text before it is logged, stored, or sent to a third-party model. It answers the question 'What is here?' so your application logic can enforce data handling policies, such as redaction, rejection, or routing to a high-security processing tier. This is a detection step, not a redaction step.

Use this prompt when you need a structured, machine-readable privacy signal to drive an automated workflow. Common integration points include: a pre-processing hook before an LLM call, a guardrail in a logging pipeline, or a filter before data enters a vector database. The prompt requires a clear [INPUT] text block and a predefined [PII_TYPES] list (e.g., name, email, phone, ssn, address). You must also provide an [OUTPUT_SCHEMA] that defines the exact boolean flag structure you expect. Do not use this prompt for direct user-facing redaction, as it does not return a sanitized string. Do not use it as a standalone compliance guarantee; its output is a probabilistic signal that should be paired with downstream validation and, for high-risk regulated data, a human review step.

Before implementing, define your tolerance for false positives and false negatives. A false positive (flagging non-PII as PII) might over-redact and degrade data utility, while a false negative (missing real PII) is a compliance risk. Your application logic should handle both cases. For example, a low_confidence flag in the output can trigger a review queue instead of an automated action. After reading this section, proceed to the prompt template to see the exact instruction structure, then review the implementation harness to understand how to wire this into a production system with validation, retries, and logging.

This template is designed to be dropped directly into your application code. It instructs the model to act as a privacy-preserving PII detector that only returns boolean flags—never the PII values themselves. The prompt uses strict JSON output constraints, explicit definitions for each PII type, and a reasoning field to capture ambiguity. This design keeps sensitive data out of model responses and logs, which is critical for compliance with data handling policies.

textCopy
You are a privacy-preserving PII detection system. Your task is to analyze the provided text and determine the presence of specific types of Personally Identifiable Information (PII).

**CRITICAL RULES:**
- Do NOT extract, redact, or repeat the actual PII values.
- Return ONLY a JSON object with boolean flags for each PII type.
- If a PII type is not found, its flag must be `false`.
- If the text is ambiguous, set the flag to `true` and explain the ambiguity in the `reasoning` field.

**PII Types to Detect:**
- `person_name`: Full names (e.g., John Smith), including partial names if clearly referring to an individual.
- `email_address`: Email addresses (e.g., user@domain.com).
- `phone_number`: Phone numbers in any standard format, including country codes.
- `ssn`: U.S. Social Security Numbers in XXX-XX-XXXX format or similar.
- `physical_address`: Street addresses, city/state/zip combinations, or full postal addresses.
- `ip_address`: IPv4 or IPv6 addresses.
- `credit_card`: Credit card numbers matching common issuer patterns.
- `date_of_birth`: Explicit birth dates or age references that could identify an individual.

**Input Text:**
[INPUT_TEXT]

**Output Format:**
Return ONLY a valid JSON object with this exact structure:
{
  "person_name": boolean,
  "email_address": boolean,
  "phone_number": boolean,
  "ssn": boolean,
  "physical_address": boolean,
  "ip_address": boolean,
  "credit_card": boolean,
  "date_of_birth": boolean,
  "reasoning": "Brief explanation of any ambiguous detections or why all flags are false."
}

To adapt this template, modify the PII types list to match your organization's data classification policy. You can add types like passport_number, driver_license, or bank_account by defining them clearly in the list and adding the corresponding boolean field to the output schema. If your use case requires detection of PII in specific formats (e.g., only validated email patterns), add those constraints to the type definitions. For high-risk production environments, pair this prompt with a post-processing validator that confirms the output JSON contains no extracted values—this is a critical safety check before the response enters your logging pipeline.

The PII Detection Flag prompt is a classification step, not a redaction step. Wire it into your pipeline before any text is stored, logged, or sent to external models. The prompt returns a structured JSON payload with boolean flags per PII type and a confidence score. Your application should treat this output as a decision signal: route flagged text to a review queue, block it from downstream processing, or trigger automated redaction. Never rely on the prompt alone for compliance; it is a detection layer that must be paired with deterministic validation and, for regulated data, human review.

Implement a validation wrapper around the model response. Parse the JSON output and check that all expected keys are present (name, email, phone, ssn, address, credit_card, ip_address, date_of_birth, overall_confidence). If the model returns malformed JSON, missing keys, or values that aren't booleans (for flags) or floats between 0 and 1 (for confidence), reject the response and retry with a stricter prompt that includes the raw parse error. Log every parse failure and retry attempt. For high-throughput pipelines, set a maximum of 2 retries before falling back to a conservative needs_review: true flag and routing to a human queue. Use a model with strong JSON mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set response_format to json_object where the API supports it.

Build a confidence threshold gate into your harness. The overall_confidence field reflects the model's certainty that its boolean flags are correct. For low-risk workflows (internal analytics on anonymized data), you might auto-approve text with confidence above 0.9. For high-risk workflows (customer PII in support tickets, healthcare text, financial documents), route anything below 0.95 to human review, and consider routing all flagged text to review regardless of confidence. Store the raw prompt response, the validation result, the retry count, and the final routing decision in your audit log. This traceability is essential for governance reviews and debugging false positives. If you observe a PII type that frequently produces false positives (e.g., address flagging on phrases like 'the office is located at'), add few-shot counterexamples to the prompt template or implement a post-processing regex denylist for known false-positive patterns.

Finally, treat this prompt as one component in a defense-in-depth privacy architecture. Before the prompt runs, apply deterministic regex and NER-based scanners for known PII formats (SSN patterns, email regex, phone number formats). Use the LLM prompt to catch ambiguous or unstructured PII that regex misses (e.g., 'my social is 123 45 6789' written in prose). After detection, redaction should happen in application code using the boolean flags and evidence spans, not by asking the model to rewrite the text. The model's job is to flag, not to redact. If you need the model to extract the specific PII values for redaction, use a separate extraction prompt with strict output schema and never log the extracted values in plaintext.