Right to Erasure Request Validation Prompt

This prompt is designed for compliance operations teams who need a reliable, automated gate to validate incoming data deletion requests under GDPR Article 17, CCPA, or equivalent regulations. Its primary job is to act as a decision-support tool that determines if a request is complete, verifiable, and actionable before any data is touched. The ideal user is a privacy analyst, DPO, or compliance engineer embedding this into a ticketing system or privacy request portal. The prompt requires a structured input containing the request details, the relevant regulatory text, and your organization's specific data retention and exception policies.

You should use this prompt when you need a consistent, auditable first pass on every deletion request. It is particularly valuable when request volume makes manual triage a bottleneck, or when you need to enforce a strict separation between the validation decision and the execution of deletion. The prompt evaluates identity verification status, checks for applicable exceptions (such as legal holds or legitimate business needs), and calculates the mandated processing timeline. It is not a prompt for executing the deletion itself; its output is a structured decision object that your application can use to either trigger an automated deletion workflow or route the request to a human review queue with a detailed reason.

Do not use this prompt when the request context is so ambiguous that a human must interpret the initial intent, or when the regulatory framework is not provided as part of the input. This prompt is a compliance gate, not a legal advisor. It will not invent regulations or interpret vague policy. For high-risk requests where the model flags an exception, identity gap, or regulatory ambiguity, the prompt's output must be treated as a routing instruction to a human reviewer, not a final decision. The next step after using this prompt is to wire its structured output into your workflow engine: a pass status proceeds to automated processing, while a needs_review or blocked status must trigger a human review task with the full validation payload attached.

This prompt template is designed to be the core instruction set for an AI system evaluating a Right to Erasure (Right to Deletion) request. It forces the model to act as a compliance gate, not a decision-maker. The template requires the model to structure its output into a machine-readable decision with a clear status, a list of verified identity attributes, applicable regulatory exceptions, and a concrete processing timeline. The goal is to produce a consistent, auditable artifact that a human reviewer can quickly approve or reject.

codeCopy
You are a compliance validation engine. Your task is to evaluate a data subject's Right to Erasure request against the provided [REGULATORY_POLICY] and [DATA_RETENTION_SCHEDULE]. You must not fulfill or deny the request; you only produce a structured validation decision.

INPUT DATA:
- Request Details: [REQUEST_PAYLOAD]
- Identity Verification Evidence: [IDENTITY_EVIDENCE]
- Data Subject's Account History: [ACCOUNT_HISTORY]
- Applicable Regulation Text: [REGULATORY_POLICY]
- Internal Data Retention Rules: [DATA_RETENTION_SCHEDULE]

OUTPUT SCHEMA (Strict JSON):
{
  "request_id": "string",
  "validation_status": "approved_for_processing" | "needs_human_review" | "rejected",
  "identity_verification": {
    "status": "verified" | "failed" | "insufficient_evidence",
    "matched_attributes": ["string"],
    "unmatched_or_missing_attributes": ["string"],
    "confidence_score": 0.0-1.0
  },
  "exception_analysis": [
    {
      "exception_type": "string (e.g., legal_hold, freedom_of_expression, public_interest, defense_of_legal_claims)",
      "applies": true | false,
      "evidence_citation": "string (quote from input data or policy)",
      "reasoning": "string"
    }
  ],
  "processing_timeline": {
    "regulatory_deadline_days": "number",
    "recommended_completion_date": "YYYY-MM-DD",
    "justification": "string"
  },
  "blocking_conditions": ["string (list of reasons why the request cannot proceed automatically)"],
  "recommended_next_step": "string (clear instruction for the human reviewer or automated workflow)"
}

CONSTRAINTS:
- If identity_verification.confidence_score < [ID_CONFIDENCE_THRESHOLD], set validation_status to "needs_human_review".
- If any exception_analysis item has "applies": true, set validation_status to "needs_human_review".
- If the request is for data that is part of an active [LEGAL_HOLD_LIST], set validation_status to "needs_human_review".
- Do not invent exceptions. Only use exception types explicitly mentioned in [REGULATORY_POLICY].
- Cite specific lines or fields from the input data in your evidence_citation fields.

To adapt this template, replace the square-bracket placeholders with real data from your identity provider, CRM, and policy engine before each invocation. The [ID_CONFIDENCE_THRESHOLD] should be a constant in your application config (e.g., 0.85). The [LEGAL_HOLD_LIST] should be a dynamically queried list of active litigation or regulatory holds. After receiving the JSON output, your application must parse validation_status. If it is needs_human_review, route the entire payload to a review queue. If it is approved_for_processing, you can proceed to the next step in your deletion pipeline, but always log the full validation object as an audit record before executing any destructive action.

This prompt is not a standalone chatbot interaction; it is a decision gate inside a larger compliance workflow. The application layer must supply the structured [REQUEST_DETAILS], [USER_IDENTITY_EVIDENCE], and [REGULATORY_POLICY] inputs, then parse the JSON output into a state machine that routes the request to one of three paths: proceed (automated deletion), needs_review (human queue), or reject (notification with reasoning). The model's decision is advisory until the application enforces it. For GDPR or CCPA workflows, the application should never autonomously execute deletion based solely on the model's proceed output without an additional confirmation step that logs the decision rationale and the evidence used.

The harness must validate the model's output against a strict JSON schema before acting on it. At minimum, check that decision is one of the allowed enum values, identity_verification_status is present, applicable_exceptions is an array, and processing_timeline_days is a positive integer or null. If validation fails, retry once with the same prompt and append a repair instruction: Your previous output was invalid. You must return valid JSON matching the required schema. If the second attempt also fails, escalate the entire request to a human review queue with the raw model output and validation errors attached. Do not loop indefinitely; two attempts is the ceiling before human intervention.

Logging is critical for auditability. For every request, persist the full prompt payload, the model's raw output, the validation result, the final routing decision, and the identity of any human reviewer who overrides the model's recommendation. These records form the audit trail required by Article 17 of GDPR and similar regulations. Use structured logging with a correlation ID that ties the erasure request to the user's account and the eventual deletion or retention action. If the model flags identity_verification_status as unverified or insufficient, the application must block the workflow and request additional evidence from the user before re-invoking the prompt. Do not pass unverified requests to a human reviewer without first collecting the missing evidence.

Model choice matters here. Use a model with strong instruction-following and JSON output reliability, such as GPT-4o, Claude 3.5 Sonnet, or a fine-tuned equivalent. Avoid smaller or older models that are prone to hallucinating legal citations or misclassifying exception categories. If your deployment requires on-premise or air-gapped operation, validate your chosen local model against a golden dataset of 50+ labeled erasure requests before production use. The eval set should include edge cases: requests with partial identity matches, requests citing multiple regulations, requests where the data subject is a minor, and requests that conflict with legal holds or ongoing investigations.

Human review is mandatory for any request where the model returns needs_review or where the applicable_exceptions array contains entries like legal_obligation, public_interest, or legal_claims. The review interface should present the original request, the model's structured output, and the relevant policy excerpts side by side. The human reviewer must confirm or override the decision, and their action must be logged with a timestamp and rationale. Do not allow the model's proceed decision to bypass human review when exceptions are present, even if the model's confidence appears high. The cost of a wrongful deletion under GDPR far exceeds the cost of a brief human check.