GDPR Data Subject Request Extraction Prompt

Privacy operations teams and Data Protection Officers (DPOs) routinely receive data subject access requests (DSARs) and deletion requests through a variety of channels—email, web forms, support tickets, and even physical mail. These requests arrive as unstructured free text with wildly inconsistent formatting. A single inbox might contain a one-line demand for 'all my data,' a legally worded letter citing specific statutes, and a customer support ticket asking to 'close my account and remove my info.' Manually triaging this queue creates operational bottlenecks, risks missing statutory response deadlines (e.g., GDPR's 30-day window), and introduces classification errors that can lead to non-compliance. This prompt is designed to be the first step in an automated pipeline, extracting structured, machine-readable details from raw DSAR text so that requests can be instantly routed, prioritized, and logged.

The ideal user is a privacy engineer or operations lead integrating this prompt into a request intake system. The prompt expects a raw text input and a defined output schema, and it returns a typed JSON payload containing the request category (e.g., access, deletion, rectification), the data subject's identity details, verification status, the scope of the request, and a calculated statutory deadline. It is built for a high-stakes domain, so it includes explicit instructions for handling ambiguity—such as flagging when identity is unverified or when the scope of data requested is vague—rather than guessing. Do not use this prompt for automated legal decisions, for performing the actual identity verification, or for generating a final response to the data subject. Its job is solely to structure the intake.

Before using this prompt, ensure you have a clear understanding of the input channels you will be processing and the downstream system that will consume the structured JSON. The prompt is most effective when paired with a validation layer that checks the output against your expected schema and a human review queue for requests flagged as high-risk or ambiguous. The next section provides the copy-ready prompt template you can adapt to your specific jurisdictional requirements and data taxonomy.

The following prompt template is designed to be copied directly into your AI harness. It instructs the model to act as a privacy operations extraction engine, consuming raw request text and producing a typed JSON payload. The template uses square-bracket placeholders for all dynamic inputs, including the request text, the required output schema, and any operational constraints. Before integrating, replace each placeholder with the actual values your application provides at runtime. This prompt enforces strict behavior: no fabricated data, explicit nulls for missing fields, and confidence scores where evidence is ambiguous. It is the core instruction set you will wrap with validation, retries, and logging in your implementation harness.

textCopy
You are a GDPR Data Subject Request extraction engine. Your only job is to read the provided request text and return a valid JSON object that matches the [OUTPUT_SCHEMA].

Follow these rules exactly:
- Extract only information explicitly stated in the request text. Do not infer, assume, or fabricate any data.
- For any field where the information is not present or cannot be determined, use null.
- For any field where the evidence is ambiguous or partial, include a "confidence" field with a value of "low", "medium", or "high".
- Normalize dates to ISO 8601 format (YYYY-MM-DD).
- Normalize request types to the controlled vocabulary in [REQUEST_TYPE_ENUM].
- If the request mentions multiple jurisdictions, extract each as a separate entry in the "jurisdictions" array.
- Calculate the regulatory deadline from the date of receipt using the rules in [DEADLINE_RULES]. If the receipt date is missing, set the deadline to null.
- Do not include any text outside the JSON object.

[INPUT]

[OUTPUT_SCHEMA]

[REQUEST_TYPE_ENUM]

[DEADLINE_RULES]

[CONSTRAINTS]

To adapt this template, start by defining your [OUTPUT_SCHEMA] as a strict JSON Schema object. This schema should include fields for request_type, data_subject_identity, identity_verification_status, data_scope, jurisdictions, receipt_date, and regulatory_deadline. The [REQUEST_TYPE_ENUM] placeholder should be replaced with a comma-separated list of your supported request types, such as access, deletion, rectification, portability, restriction, and objection. The [DEADLINE_RULES] placeholder must contain clear, jurisdiction-specific rules for calculating the response deadline (e.g., "GDPR: one calendar month from receipt, extendable by two months for complex requests"). The [CONSTRAINTS] placeholder is your final safety net; use it to inject operational rules like "If identity_verification_status is unverified, set data_scope to null and add a note to the response." After replacing the placeholders, test the prompt against a golden dataset of known requests and edge cases, including blank inputs, ambiguous scopes, and multi-language text. The next step is to wire this prompt into an application harness that validates the JSON output against your schema before any downstream action is taken.

The extraction prompt is only one component of a reliable DSAR processing system. To move from a useful prompt to a production-grade intake pipeline, you must wrap the LLM call in application logic that validates the output, handles failures gracefully, and maintains a complete audit trail. This harness is responsible for substituting variables into the template, calling the model, checking the response against the expected schema, and deciding whether the extracted payload is trustworthy enough to ingest into your case management system. Without this layer, even a well-designed prompt will produce occasional malformed JSON, low-confidence classifications, or ambiguous identity verification signals that should never flow into automated workflows.

Begin by constructing the final prompt string from the template, substituting [REQUEST_TEXT] with the raw, unredacted data subject request and [RECEIPT_DATE] with the ISO 8601 timestamp of receipt. Call the LLM with a low temperature (0.0–0.1) to maximize schema adherence. Parse the response and validate the JSON against the output schema: request_type must be one of the defined enum values, identity_verification_status must be a recognized status, and all required fields must be present. If validation fails, construct a retry prompt that appends the original request text, the failed JSON output, and the specific validation errors, then call the model once more. If the retry also fails, log the failure and route the entire request to a human review queue. Do not attempt more than one automated retry for schema validation failures.

Confidence scoring is the primary gating mechanism for automation. After successful schema validation, check the confidence_scores: if request_type_confidence or identity_verification_confidence falls below 0.7, route the request to the human review queue regardless of schema validity. For requests that pass both schema and confidence gates, calculate the statutory deadline by adding one calendar month to receipt_date, adjusting for your organization's jurisdiction rules (e.g., accounting for local holidays or specific regulatory interpretations of 'one month'). Store the complete structured payload in your DSAR case management system, trigger the appropriate workflow based on request_type (access, deletion, rectification, portability, objection, or restriction), and log every extraction with the SHA-256 hash of the raw request text, the full extracted payload, all confidence scores, the reviewer decision if escalated, and the calculated deadline. Never use the extracted output to automatically respond to the data subject without DPO review, even when all confidence scores are high.