GDPR Data Subject Request Handling Prompt

This prompt is designed for privacy engineering teams who need a consistent, auditable first-pass triage layer for incoming Data Subject Access Requests (DSARs) under GDPR. Its core job is to classify the request type (e.g., access, rectification, erasure), map it to the corresponding controller obligations, and prepare a structured summary for a human Data Protection Officer (DPO) or privacy analyst. The ideal user is a technical team integrating AI into an existing privacy request management platform, where the prompt acts as a force multiplier for overwhelmed privacy teams by handling the initial parsing and routing of unstructured emails, web forms, or PDF letters. Required context includes the full text of the data subject's request and any supporting identity verification metadata, but the prompt must never receive unredacted copies of government ID documents or sensitive authentication data.

The prompt is explicitly designed to refuse making substantive legal determinations. It will not decide whether a request is valid, whether an exemption applies, what specific data must be disclosed, or whether a deletion request should be honored. These decisions remain the legal responsibility of the controller's human representatives. The prompt's output is always a recommendation for human review, never a consummated action or a final response to the data subject. This boundary is enforced through both the system prompt instructions and a set of automated output validation checks that scan for definitive legal conclusions, disclosure decisions, or direct-to-data-subject language before the output ever reaches a human reviewer.

Do not use this prompt as a fully automated DSAR responder. It must not be connected to systems that can directly retrieve, modify, or delete personal data without human approval. It is unsuitable for handling requests that involve complex legal disputes, requests where the data subject's identity is contested, or situations where the controller is simultaneously responding to a regulatory investigation. In these high-risk scenarios, the prompt should escalate immediately to a human without attempting classification. The next step after implementing this prompt is to build the validation harness and human review queue described in the Implementation Harness section, ensuring that every AI-generated triage summary is reviewed, corrected if necessary, and logged as part of the controller's Article 30 record-keeping obligations.

This prompt template is designed to be pasted directly into your system prompt or API call for AI-assisted GDPR Data Subject Access Request (DSAR) handling. It forces the model into a strict triage and classification role, explicitly forbidding it from making decisions about data disclosure, deletion, or request validity. The square-bracket placeholders must be replaced with your organization's specific policies, data categories, and operational context before use.

textCopy
You are a GDPR Data Subject Request Triage Assistant. Your sole function is to classify incoming data subject requests and identify the required procedural actions based strictly on the provided policy. You do not have the authority to approve, deny, or fulfill any request. You must never make a substantive legal determination.

## REQUEST CONTEXT
[REQUEST_CONTENT]

## ORGANIZATIONAL POLICIES
[POLICY_DOCUMENT]

## KNOWN DATA CATEGORIES AND SYSTEMS
[DATA_MAP]

## CONSTRAINTS
- Classify the request into exactly one type: [ACCESS, RECTIFICATION, ERASURE, RESTRICTION, PORTABILITY, OBJECTION, or UNCLEAR].
- If UNCLEAR, specify what clarifying information is needed from the requestor.
- Identify the specific data categories and systems potentially implicated, referencing only the [DATA_MAP] provided.
- List the procedural steps required by [POLICY_DOCUMENT], such as identity verification, scoping, or retrieval.
- Flag any request elements that appear excessive, manifestly unfounded, or outside the scope of GDPR.
- Do not calculate or suggest deadlines.
- Do not draft a response to the data subject.
- Do not recommend whether the request should be granted or denied.
- If the request involves special category data or a high-risk processing activity, explicitly flag it for mandatory human review.

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "request_type": "string",
  "is_clear": boolean,
  "clarification_needed": "string or null",
  "implicated_data_categories": ["string"],
  "implicated_systems": ["string"],
  "required_procedural_steps": ["string"],
  "excessive_or_unfounded_flags": ["string"],
  "special_category_data_flag": boolean,
  "human_review_required": boolean,
  "human_review_reason": "string or null"
}

To adapt this template, replace [REQUEST_CONTENT] with the raw text of the data subject's request. Replace [POLICY_DOCUMENT] with an excerpt of your internal DSAR handling policy, focusing on classification criteria and procedural steps. Replace [DATA_MAP] with a structured list of your organization's data categories and the systems that store them. The output schema is designed for direct ingestion by a downstream workflow engine. The boolean flags for special_category_data_flag and human_review_required act as circuit breakers, ensuring high-risk items are never processed automatically. Before deploying, run a suite of eval cases that include ambiguous requests, requests for non-existent data, and aggressive legal language to verify the model does not over-assist or make a legal determination.

This prompt is designed as a classification and triage step, not a decision engine. It should sit behind an API endpoint that receives a raw user request, enriches it with available context (e.g., known data categories, jurisdiction), and returns a structured JSON payload. The application layer must never act on the model's recommended_actions without human review. The model's job is to structure the intake, not to execute the DSAR.

Integration pattern: 1) Receive the request via form, email, or chat. 2) Sanitize the input to remove any PII that isn't necessary for classification (the request itself may contain PII; minimize what reaches the model). 3) Call the prompt with [REQUEST_TEXT], [REQUESTER_ROLE], and [KNOWN_DATA_CATEGORIES]. 4) Validate the output JSON against a strict schema—reject and retry if request_type is missing or confidence_score is outside 0.0–1.0. 5) Log the validated output, raw model response, and prompt version to an audit trail. 6) Route to a human review queue if requires_human_review is true or confidence_score is below your threshold (e.g., <0.85). 7) The human reviewer makes the substantive decision; the model's recommended_actions are advisory only.

Model choice and latency: Use a model with strong instruction-following and JSON mode (e.g., GPT-4o, Claude 3.5 Sonnet) for reliable schema adherence. Set temperature=0 to minimize variance in classification. This is a synchronous step in a human-in-the-loop workflow, so latency under 3 seconds is acceptable; if faster response is needed, consider a smaller fine-tuned classifier for the initial triage and reserve the general-purpose model for edge cases. Retry logic: If the output fails schema validation, retry once with the validation error included in the prompt context. If the second attempt fails, escalate to a human with the raw request and failure reason. Never silently accept malformed output in a regulated workflow.

What to avoid: Do not pass the model's output directly to a data deletion or export API. Do not use the model to determine the legal validity of a request—that is a legal team function. Do not log the full user request text to observability tools without redaction; the request may contain the requester's own PII. The prompt is a compliance aid, not a compliance replacement. Always ensure your DSAR workflow has a documented legal basis for each automated step and a clear path to human override.