Sensitive Data Handling Escalation Prompt

This prompt is designed for privacy engineers and AI platform teams who need to detect personally identifiable information (PII), protected health information (PHI), payment card data, or other regulated data classes within text before it enters an AI workflow. Use it when your application processes user-generated content, support tickets, customer communications, or document uploads that may contain sensitive data. The prompt instructs the model to act as a data classification and escalation engine, returning structured flags, data classifications, handling requirements, and redaction instructions. This is not a prompt for generating content or answering questions. It is a detection and policy enforcement prompt that should sit upstream of any generative or analytical step in your pipeline.

Deploy this prompt as a pre-processing gate. Before any user input, uploaded document, or retrieved context reaches a generative model, an agentic tool-calling loop, or a vector database, route it through this classification step. The ideal user is a platform engineer or privacy architect who owns the data handling pipeline and needs a consistent, auditable detection layer. The prompt requires a clear [DATA_CLASSIFICATION_POLICY] input that defines which data classes to detect (e.g., GDPR personal data, PCI-DSS cardholder data, HIPAA PHI), the jurisdiction or regulatory framework, and the required output actions for each class. Without a well-defined policy, the model will default to generic PII detection, which may miss domain-specific regulated data or produce false positives on business data that resembles personal information.

Do not use this prompt when you need perfect recall on novel or obfuscated data patterns—no prompt-based detector can guarantee 100% recall, and adversarial obfuscation will defeat pattern-matching approaches. Do not use it as a replacement for deterministic redaction libraries (e.g., Presidio, spaCy NER with custom models) when you have structured, high-throughput pipelines with known entity types. Instead, use this prompt as a secondary detection layer for unstructured free-text where context matters, as a policy-aware escalation engine that understands regulatory nuance, or as a pre-filter before human review queues. The output is a structured escalation decision, not redacted text—pair it with a separate redaction prompt or library if you need to transform the content. Always log the detection results and policy version for audit trails, and implement a human review step for any detection with confidence below your defined threshold or for data classified under high-severity regulatory categories.

Before implementing, define your escalation paths: what happens when the prompt returns a BLOCK decision versus a FLAG_FOR_REVIEW decision? Wire the output into your application's routing logic so that blocked content never reaches downstream models, flagged content enters a review queue with the structured context summary attached, and clean content proceeds normally. Test the prompt against a golden dataset that includes true positives (realistic PII/PHI/PCI in context), true negatives (business data that looks personal but isn't), and edge cases (mixed data, multilingual content, obfuscated patterns). Measure both recall and false-positive rate, and tune your [DATA_CLASSIFICATION_POLICY] and [CONFIDENCE_THRESHOLD] inputs based on your risk tolerance.

This prompt template defines a privacy-aware assistant that scans input text for sensitive data, classifies findings by regulatory category, and produces structured escalation flags with redaction instructions. Replace each square-bracket placeholder with your organization's specific data classification taxonomy, regulatory requirements, and escalation thresholds before deployment. The template is designed to be embedded as a system-level instruction in a multi-turn agent or as a preprocessing step before data enters downstream AI workflows.

codeCopy
SYSTEM INSTRUCTION:
You are a sensitive data detection and escalation assistant. Your job is to identify regulated, confidential, or personally identifiable information in user-provided text and produce structured escalation flags. You do not store, log, or transmit detected sensitive data beyond the immediate response. You must follow the classification taxonomy and escalation rules defined below.

## CLASSIFICATION TAXONOMY
Classify detected sensitive data into exactly these categories:
[CLASSIFICATION_CATEGORIES]

## ESCALATION THRESHOLDS
Apply these escalation rules based on detected categories and confidence:
[ESCALATION_THRESHOLDS]

## REDACTION RULES
When redaction is required, apply these rules:
[REDACTION_RULES]

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "detections": [
    {
      "category": "string (from CLASSIFICATION_CATEGORIES)",
      "match_type": "exact | pattern | inferred",
      "confidence": 0.0-1.0,
      "offset_start": integer,
      "offset_end": integer,
      "redacted_text": "string (original text replaced per REDACTION_RULES)",
      "handling_requirement": "string (from HANDLING_REQUIREMENTS)"
    }
  ],
  "escalation_required": true | false,
  "escalation_level": "none | review | block | audit",
  "escalation_reason": "string (concise explanation referencing specific thresholds)",
  "redacted_output": "string (full input with all detections redacted per REDACTION_RULES)",
  "human_review_required": true | false
}

## HANDLING REQUIREMENTS
[HANDLING_REQUIREMENTS]

## CONFIDENCE CALIBRATION
- Assign confidence >= 0.9 only when the match is unambiguous and matches a known pattern or explicit identifier.
- Assign confidence 0.7-0.89 for likely matches with minor ambiguity.
- Assign confidence < 0.7 for possible matches requiring human verification.
- If confidence < [MIN_CONFIDENCE_THRESHOLD], set human_review_required to true.

## CONSTRAINTS
- Do not include the original sensitive data in any field except offset_start and offset_end.
- Do not hallucinate detections. If no sensitive data is found, return an empty detections array with escalation_required set to false.
- Do not explain your reasoning outside the escalation_reason field.
- If the input contains [CRITICAL_DATA_TYPES], escalate immediately to level "block" regardless of confidence.
- Never output raw sensitive data in logs, explanations, or error messages.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INPUT
[USER_INPUT]

Adapt this template by replacing each bracketed placeholder with your organization's specific policies. [CLASSIFICATION_CATEGORIES] should enumerate your data classification taxonomy, such as PII, PHI, PCI, credentials, or internal confidential. [ESCALATION_THRESHOLDS] must define the conditions that trigger each escalation level, including category combinations, confidence floors, and volume thresholds. [REDACTION_RULES] should specify replacement patterns, such as [REDACTED-PII] or category-specific masks. [HANDLING_REQUIREMENTS] should map each category to required actions like 'encrypt at rest,' 'do not log,' or 'require legal review.' [CRITICAL_DATA_TYPES] should list categories that demand immediate blocking, such as credentials or financial account numbers. [FEW_SHOT_EXAMPLES] should include 3-5 input-output pairs covering common detections, edge cases with ambiguous data, and scenarios requiring escalation. [MIN_CONFIDENCE_THRESHOLD] should be set based on your risk tolerance, typically 0.7 for regulated environments.

Before deploying this prompt into production, validate it against a golden dataset of known sensitive data examples and benign inputs. Measure detection recall on your regulated categories and false-positive rates on clean data. Test boundary cases where sensitive data appears near the confidence threshold or where multiple categories overlap. Wire the output into an application harness that validates the JSON schema, logs escalation decisions without raw sensitive data, and routes human_review_required: true cases to a review queue. Never rely solely on this prompt for compliance; always pair it with deterministic pattern matching for known formats like credit card numbers or social security numbers, and require human review for any escalation above the 'review' level.

This prompt is designed to sit inside a pre-processing or guardrail layer before any user input, retrieved document, or tool output reaches a primary assistant or storage system. The typical integration point is a lightweight API endpoint or a middleware function that receives a text payload, calls the LLM with this prompt, parses the structured escalation decision, and then either blocks, redacts, or routes the content. Because the prompt handles regulated data classes (PII, PHI, PCI, credentials), the implementation harness must treat every escalate flag as a hard gate, not a suggestion. The harness should never silently pass flagged content downstream without an explicit override from an authorized human reviewer or an approved automated redaction pipeline.

Integration flow: 1) Receive input text and a [DATA_CLASSIFICATION_POLICY] context block that defines which data classes trigger escalation. 2) Assemble the prompt with the input text, policy, and a strict [OUTPUT_SCHEMA] requiring escalate (boolean), detected_classes (array of strings), confidence (0-1), evidence_spans (array of start/end offsets), and recommended_action (redact/block/flag/review). 3) Call a low-latency model (e.g., GPT-4o-mini, Claude Haiku) with temperature=0 and response_format set to JSON mode. 4) Parse the response and validate the schema. If validation fails, retry once with the error message appended to the prompt. If the retry also fails, escalate to a human reviewer with the raw input and both failed responses attached. 5) On successful parse, check escalate. If true, route to the action specified: redact matched spans automatically (if confidence > 0.95 and policy allows), block the content entirely, or queue for human review. Log every decision with the input hash, detected classes, confidence scores, and action taken for audit trails.

Validation and evals: Before deployment, run this prompt against a golden dataset containing known PII, PHI, and clean samples. Measure recall (did it catch all sensitive data?), false-positive rate (did it flag clean text?), and classification precision (did it label classes correctly?). A common failure mode is over-flagging names and dates in ambiguous contexts—calibrate your [DATA_CLASSIFICATION_POLICY] with explicit examples of what does and does not constitute regulated data in your domain. For high-stakes production use, implement a shadow-mode eval where the prompt runs alongside existing manual review for two weeks, and compare decisions before cutting over. Never deploy this prompt as the sole defense without a human review path for low-confidence detections (confidence < 0.85) or novel data patterns the model hasn't seen.

What to avoid: Do not use this prompt on streaming input without buffering complete logical units (e.g., full messages, not partial keystrokes). Do not log the raw sensitive input in plaintext—hash or truncate it, and store detection evidence separately from the original data. Do not assume the model will catch every instance of sensitive data; this prompt reduces risk but does not eliminate it. If your use case involves regulated data under GDPR, HIPAA, or PCI-DSS, pair this prompt with deterministic pattern matching (regex for credit cards, SSNs, etc.) as a first pass, and use the LLM only for contextual disambiguation and unstructured PII detection. The prompt is a detection layer, not a compliance certification.