PII Exposure Escalation Prompt for Data Pipelines

This prompt is for data platform engineers who need to automatically detect exposed Personally Identifiable Information (PII) within data pipeline payloads, such as user-generated content, log streams, or ingested third-party data. Use it when you need a structured escalation record that identifies the PII type, suggests a redaction strategy, and assigns a severity level before the data reaches storage, analytics, or downstream AI models. This is a classification and routing prompt that sits at the ingress of your data processing layer, acting as a circuit breaker to prevent PII from leaking into systems that lack the necessary compliance controls. It assumes the input text has already been extracted and normalized; it does not handle file parsing or decryption.

The ideal deployment point is immediately after payload extraction and before any persistent storage or model inference. For example, in a customer support pipeline, you would place this prompt after the ticket text is extracted from the API request but before it is written to your data warehouse or passed to an LLM for summarization. The prompt expects a single text field as input and returns a structured JSON escalation record. It is designed for high-throughput, automated decision-making where a human cannot review every payload. The severity scoring is calibrated to distinguish between a single email address in a log line (low severity, auto-redact) and a full credit card number plus CVV in user-generated content (critical severity, block and alert).

Do not use this prompt as a general-purpose data classifier, a replacement for deterministic regex-based PII scanning, or a primary defense against adversarial prompt injection. It is not designed to handle encrypted or obfuscated payloads, and it will not catch PII hidden in base64-encoded strings, images, or non-text formats. For high-volume streaming pipelines where latency is measured in milliseconds, a deterministic scanner should pre-filter obvious PII before invoking this LLM-based prompt. If your use case requires compliance with a specific regulatory framework such as HIPAA or PCI-DSS, this prompt provides a detection layer but does not constitute a complete compliance solution—you must still implement the required audit trails, access controls, and human review workflows. After reading this section, proceed to the prompt template to copy and adapt the detection instructions for your specific PII taxonomy and severity thresholds.

This prompt template is designed to be pasted directly into your prompt layer, whether that's a prompt management system, a configuration file, or application code. It expects a raw data payload and a set of configuration variables that define your organization's PII taxonomy, severity thresholds, and output requirements. The template uses square-bracket placeholders exclusively so you can perform a straightforward find-and-replace before deployment. Every placeholder maps to a concrete input your application must supply: the data to scan, the PII types to detect, the severity rubric, and the desired output schema.

textCopy
You are a PII detection and escalation agent for a data pipeline. Your task is to scan the provided [INPUT_DATA] for exposed personally identifiable information (PII). You must apply the detection rules defined in [PII_TAXONOMY] and classify any findings according to the severity levels in [SEVERITY_RUBRIC].

[INPUT_DATA]:

[DATA_PAYLOAD]

codeCopy

[PII_TAXONOMY]:
[TAXONOMY_DEFINITIONS]

[SEVERITY_RUBRIC]:
[SEVERITY_LEVELS]

[CONSTRAINTS]:
- Do not flag data that is explicitly marked as synthetic, test, or sample data according to the rule: [SYNTHETIC_DATA_RULE].
- Do not flag system identifiers, internal UUIDs, or non-personal entity IDs.
- For any obfuscated or partially masked PII (e.g., emails like j***@domain.com), flag it as a potential exposure and note the obfuscation pattern.
- If no PII is detected, return an empty findings array with a `no_findings` status.

[OUTPUT_SCHEMA]:
Return a single JSON object with the following structure:
{
  "scan_id": "string, a unique identifier for this scan, provided in the input",
  "status": "string, one of: 'escalate', 'review', 'no_findings'",
  "findings": [
    {
      "pii_type": "string, from the provided taxonomy",
      "severity": "string, from the provided rubric",
      "excerpt": "string, the exact text containing the PII, truncated to 100 characters",
      "location": "string, path or field identifier where the PII was found",
      "redaction_suggestion": "string, a specific suggestion for masking or removing the PII",
      "confidence": "float, between 0.0 and 1.0"
    }
  ],
  "summary": {
    "total_findings": "integer",
    "by_severity": {
      "critical": "integer",
      "high": "integer",
      "medium": "integer",
      "low": "integer"
    },
    "recommended_action": "string, one of: 'block_pipeline', 'quarantine_record', 'redact_and_pass', 'log_only'"
  }
}

[EXAMPLES]:
[FEW_SHOT_EXAMPLES]

[RISK_LEVEL]: [RISK_LEVEL]

To adapt this template, start by replacing the configuration placeholders with your organization's specific rules. The [PII_TAXONOMY] should be a structured list of PII types you care about, such as email addresses, phone numbers, government IDs, financial account numbers, and IP addresses. The [SEVERITY_RUBRIC] must define clear boundaries between critical, high, medium, and low severity—for example, an unredacted government ID might be critical, while an email address alone might be medium. The [FEW_SHOT_EXAMPLES] placeholder is critical for reducing false positives and false negatives; include at least two examples of obfuscated PII that should be flagged and two examples of benign identifiers that should not. Before deploying, validate that your output schema matches the downstream escalation handler's expected contract exactly, including field names, enum values, and the recommended_action options. For high-risk pipelines where a missed PII exposure could trigger regulatory obligations, always pair this prompt with a human review step for any finding with a severity of 'high' or 'critical' and a confidence score below 0.9.

This prompt is designed to sit inside a data pipeline's sensitive-content screening stage, not as a standalone chatbot. The typical integration point is a streaming or batch processor that inspects user-generated text fields before they land in a data warehouse, analytics system, or model training corpus. The harness must treat the LLM call as one component in a larger detection pipeline: upstream regex and NER-based scanners should catch obvious PII patterns (credit card numbers, SSNs, email addresses) before the prompt runs, reducing cost and latency. The prompt handles the harder cases—obfuscated PII, contextual identifiers, and borderline data that pattern matchers miss.

Wire the prompt into your application with a structured input object containing the text payload, a configurable risk threshold, and any domain-specific PII definitions. The model should return a typed JSON response with an escalation_decision boolean, a pii_type enum, a severity score, and a redaction_suggestion string. Implement a validation layer that checks the response schema before acting on it: if the JSON is malformed, the severity score is outside the expected range, or the pii_type doesn't match your taxonomy, retry once with a repair prompt that includes the validation error. If the retry also fails, escalate the raw text to a human review queue with the validation failure noted. Log every invocation—input hash, model response, validation result, and escalation decision—for audit trails and threshold tuning.

For high-throughput pipelines, batch multiple text segments into a single prompt call where the combined context stays under your model's token limit, but ensure each segment receives an independent escalation assessment in the output array. Set a hard timeout on the LLM call (e.g., 5 seconds for real-time streams) and fall back to a conservative escalation rule if the model doesn't respond in time: when in doubt, quarantine the data. Never auto-redact based solely on the model's suggestion without human confirmation in regulated environments. The redaction suggestion should be treated as a recommendation that a human or a deterministic redaction service must approve before data mutation occurs.