GDPR and CCPA Compliance Output Scrub Prompt Template

This prompt is designed for privacy engineers, legal compliance teams, and data protection officers who need a post-generation safety net before model outputs are shared externally, logged, or stored. It targets GDPR-defined personal data (names, identifiers, location data, online identifiers) and CCPA-defined personal information (household data, inferences, commercial information). Use this prompt when a model has generated a report, summary, email, or document that must be scrubbed against regulatory definitions before it leaves a controlled environment. This is not a general PII redaction prompt. It is specifically tuned for the broader legal definitions under GDPR and CCPA, including right-to-be-forgotten checks where a data subject has requested deletion and the output must not reintroduce their information.

The prompt assumes the input text may contain unstructured prose, structured fields, or semi-structured data. It requires a supplied data subject erasure list and a jurisdiction parameter to adjust its detection rules. Do not use this prompt as a primary defense for real-time user inputs, as a replacement for encryption at rest, or for de-identifying training data. It is a post-generation scrubber, not a real-time guard. For streaming outputs, pair it with a chunk-level buffering strategy. For batch processing, wrap it in a pipeline that logs every redaction decision with a justification and a confidence score. Always route borderline cases to a human review queue, especially when the erasure list contains partial matches or common names.

Before wiring this into production, define your evals: measure recall against a golden set of known PII in test outputs, track false positives on clean text, and log the rate of human escalations. The prompt's value is in catching what the model inadvertently reintroduces—deleted user handles in a summary, an old address in a generated report, or a household inference in a marketing draft. Start by running it in a dry-run mode that flags but does not redact, then promote to automated redaction only after your review team confirms the false positive rate is acceptable for your risk tolerance.

This prompt template acts as a post-generation safety net for privacy and legal teams handling data subject rights requests. It instructs the model to scan a given text output for personal data as defined by GDPR and CCPA, redact or flag it, verify whether the output complies with right-to-be-forgotten requests, and apply data minimization principles. The template is designed to be dropped into your system instructions or used as a user message in a two-pass architecture where the first pass generates content and the second pass scrubs it. Replace every square-bracket placeholder with your specific inputs before use. Because this workflow involves regulated data, you must implement human review for any output that triggers a redaction or a right-to-be-forgotten conflict before the output is shared externally.

textCopy
You are a privacy compliance output scrubber. Your job is to scan the provided text output for personal data as defined under GDPR and CCPA, redact or flag it, verify right-to-be-forgotten compliance, and enforce data minimization. You do not generate new content; you only analyze and sanitize the provided output.

## INPUT
[OUTPUT_TO_SCRUB]

## CONTEXT
- Jurisdiction: [JURISDICTION] (e.g., GDPR, CCPA, both)
- Data subject right in effect: [RIGHT_TYPE] (e.g., access, deletion/right-to-be-forgotten, opt-out)
- Data subject identifiers to verify against: [SUBJECT_IDENTIFIERS] (e.g., email, user ID, name)
- Sharing destination: [SHARING_DESTINATION] (e.g., external data subject, third-party vendor, public)
- Organization's data retention policy summary: [RETENTION_POLICY]

## REDACTION RULES
1. Detect and categorize any of the following personal data categories present in the output:
   - Direct identifiers: full name, email address, physical address, phone number, government ID numbers, online identifiers (IP address, cookie IDs), device IDs.
   - Sensitive personal data (GDPR Art. 9): racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, sex life or orientation.
   - CCPA-specific: geolocation data, audio/visual information, professional or employment-related information, education information, inferences drawn from other personal data.
   - Pseudonymous data that could be re-identified when combined with the context provided.
2. For each detected item, apply the redaction strategy specified in [REDACTION_STRATEGY]:
   - `mask`: Replace with a category tag in square brackets (e.g., [EMAIL_ADDRESS], [FULL_NAME]).
   - `remove`: Delete the data entirely and note the removal.
   - `flag`: Leave the data in place but wrap it in a warning marker for human review.
3. Do not redact data that is clearly synthetic, test data, or publicly available information about a legal entity (not a natural person).

## RIGHT-TO-BE-FORGOTTEN VERIFICATION
1. Compare the output against [SUBJECT_IDENTIFIERS].
2. If any identifier matches or the output contains data clearly relating to the data subject who has exercised their right to erasure, flag the entire output as `RIGHT_TO_BE_FORGOTTEN_CONFLICT`.
3. If a conflict is found, recommend that the output not be shared and escalate for human review.

## DATA MINIMIZATION CHECK
1. Assess whether the output contains more personal data than necessary for the specified purpose: [PURPOSE_OF_SHARING].
2. If excess data is found, note which fields are excessive and recommend a minimized version.

## OUTPUT SCHEMA
Return a valid JSON object with exactly this structure:
{
  "scrub_result": {
    "findings": [
      {
        "category": "string (e.g., EMAIL, FULL_NAME, HEALTH_DATA)",
        "original_text_snippet": "string (the detected text, truncated to 100 chars)",
        "action_taken": "mask | remove | flag",
        "confidence": "high | medium | low",
        "is_sensitive_art9": boolean
      }
    ],
    "right_to_be_forgotten_conflict": boolean,
    "conflict_detail": "string (explanation if conflict exists, otherwise null)",
    "data_minimization_violation": boolean,
    "minimization_detail": "string (explanation if violation exists, otherwise null)",
    "sanitized_output": "string (the full output with redactions applied)",
    "requires_human_review": boolean
  },
  "scrub_metadata": {
    "categories_detected": ["string"],
    "total_findings": number,
    "high_confidence_findings": number,
    "low_confidence_findings": number
  }
}

## CONSTRAINTS
- Do not invent or hallucinate findings. Only flag what is present in the output.
- If no personal data is found, return an empty findings array and set `requires_human_review` to false.
- If any finding has low confidence, set `requires_human_review` to true.
- If `right_to_be_forgotten_conflict` is true, set `requires_human_review` to true regardless of other findings.
- Preserve all non-personal content exactly as-is in `sanitized_output`.

Adapt this template by replacing the placeholders with your specific operational context. For [JURISDICTION], specify the applicable regulation; for [SUBJECT_IDENTIFIERS], provide the exact identifiers from the data subject request you are verifying against; for [REDACTION_STRATEGY], choose the strategy that matches your downstream system's tolerance for masked versus removed data. If you are operating under both GDPR and CCPA, set [JURISDICTION] to both and ensure your [REDACTION_STRATEGY] satisfies the stricter requirement. Before deploying this prompt into production, run it against a golden dataset of known PII-containing outputs and measure recall (did it catch all PII?) and precision (did it flag non-PII as PII?). Any low-confidence finding or right-to-be-forgotten conflict must route to a human review queue before the sanitized output is shared externally. Do not rely on this prompt as your sole compliance control; it is a technical safeguard that must sit inside a broader data governance program.

This prompt is a post-generation safety net, not a real-time guard. It should be placed after the primary model generates its output but before that output is logged, stored, or returned to an external consumer. The harness must treat the scrub prompt as a deterministic gate: every response passes through it, and no response bypasses it based on content-type assumptions. The prompt expects a raw model output as [INPUT] and a jurisdiction-specific data definition as [REGULATION_DEFINITION] (e.g., GDPR Article 4(1) definitions or CCPA 1798.140 personal information categories). The output is a structured JSON payload containing the scrubbed text, a list of redacted items with categories, and a confidence score per redaction.

The implementation should wrap the prompt call in a validation layer that checks the returned JSON against a strict schema. Required fields include scrubbed_output, redactions (an array of objects with original, category, confidence, and replacement), and right_to_be_forgotten_check (a boolean indicating whether any redacted data matched a supplied deletion list). If the model returns malformed JSON, the harness should retry once with a repair-focused variant of the prompt that includes the raw output and the parse error. After two failures, escalate to a human review queue. Log every scrub operation—including the pre-scrub output hash, redaction count, categories detected, and confidence distribution—to an immutable audit store. Do not log the pre-scrub plaintext itself unless the logging pipeline is independently scrubbed and access-controlled.

For high-risk workflows, such as responses to Data Subject Access Requests (DSARs) or external legal disclosures, the harness must route any output where right_to_be_forgotten_check is false or where any redaction confidence falls below a configurable threshold (default 0.85) to a human reviewer. The review interface should display the original output, the proposed scrubbed version, and a side-by-side diff of redactions. The reviewer can approve, modify redactions, or reject and return for manual rewriting. Approved scrubbed outputs are then released downstream. Never auto-approve outputs flagged for human review. For batch processing, implement a partial-failure mode: if one record in a batch fails validation or confidence thresholds, quarantine that record and continue processing the rest rather than blocking the entire batch.

Model choice matters here. Use a model with strong instruction-following and JSON output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) for the scrub step. Set temperature=0 to maximize deterministic redaction behavior. For streaming applications, buffer the full output before invoking the scrub prompt; do not attempt to scrub partial chunks, as PII may span chunk boundaries. If latency is critical, run the scrub prompt in parallel with a lightweight regex-based pre-filter that flags obvious PII patterns (emails, phone numbers, SSNs) and only invokes the full LLM scrub when the pre-filter triggers or when the output is destined for an external surface. The regex pre-filter must never be the sole redaction mechanism—it is a gating optimization, not a replacement for the LLM's contextual disambiguation.

Finally, treat the [REGULATION_DEFINITION] and [DELETION_LIST] inputs as configuration that is version-controlled and audited alongside the prompt template. When regulations change or deletion lists are updated, the configuration version must be recorded in the scrub audit log. Run a weekly regression test suite that feeds known PII-containing outputs through the harness and verifies that redaction recall remains above 99% for high-severity categories (government IDs, financial account numbers, health data) and above 95% for medium-severity categories (names, emails, phone numbers). Failures in the regression suite should block prompt or configuration updates from reaching production.