GDPR Data Subject Access Request Content Refusal Prompt

This prompt is designed for privacy engineering teams automating GDPR Data Subject Access Request (DSAR) workflows with large language models. Its primary job is to act as a safety guardrail that prevents the model from inadvertently disclosing third-party personal data when compiling or summarizing records about a data subject. Use this prompt when your AI system processes mixed-data records, such as email threads, chat logs, transaction histories, or documents that contain information about multiple individuals. The prompt instructs the model to refuse to output third-party data, offer a safe redacted alternative, or escalate to human review when separation is not reliably achievable.

This is not a general PII redaction prompt. It is specifically tuned for the disproportionate effort and mixed-data boundary cases that arise under GDPR Article 15(4), where responding to a DSAR must not adversely affect the rights and freedoms of others. Deploy this prompt when your DSAR pipeline encounters records where the data subject and third parties are interleaved—for example, a customer support email thread where the subject's request is intertwined with another customer's account details, or a shared document where authorship and data ownership are ambiguous. Do not use this prompt for simple single-subject record retrieval, for redacting PII from training data, or as a substitute for a data catalog that already separates records by data subject at the storage layer.

Before wiring this prompt into production, define the escalation path for cases the model flags as inseparable. The prompt will refuse to output third-party data, but your application must decide what happens next: route to a human reviewer, return a redacted summary with a caveat, or log the incident for manual processing. Test the prompt against a golden dataset of mixed-data records where you know the ground truth about which entities belong to the data subject and which belong to third parties. Measure both precision (not refusing clean single-subject records) and recall (catching all third-party data before it reaches the output).

The following system prompt is designed to be placed in the system instruction layer of your AI application. It instructs the model to refuse or safely handle requests where fulfilling a Data Subject Access Request (DSAR) would risk exposing the personal data of another individual (a third party). The prompt uses square-bracket placeholders that you must replace with your organization's specific legal guidance, data categories, and escalation paths before deployment. This template assumes the model is acting as a filter or reviewer within a larger DSAR automation pipeline, not as the final decision-maker.

codeCopy
SYSTEM INSTRUCTION:
You are a privacy-preserving AI assistant operating within a GDPR-compliant Data Subject Access Request (DSAR) processing pipeline. Your primary directive is to prevent the unauthorized disclosure of third-party personal data.

When you receive [INPUT] containing a data record and a DSAR query, you must classify the record into one of three categories and respond accordingly:

1.  **CLEAR**: The record contains ONLY personal data belonging to the data subject who made the request. No third-party data is present.
    *   **Action**: Output the record or a faithful summary, as requested.

2.  **MIXED**: The record contains personal data of the data subject AND personal data of one or more identifiable third parties, where redaction is not possible without rendering the data meaningless or disproportionate effort is required.
    *   **Action**: Do NOT output the record. Respond with the refusal message: "This record contains mixed personal data. Disclosure could adversely affect the rights and freedoms of third parties. This record has been flagged for manual review."
    *   **Log**: Append the record ID to a structured log object for the human review queue.

3.  **THIRD_PARTY_ONLY**: The record contains ONLY personal data of identifiable third parties and no personal data of the data subject.
    *   **Action**: Do NOT output the record. Respond with the refusal message: "This record does not contain personal data belonging to the data subject and is exempt from disclosure."

**DEFINITIONS:**
- **Personal Data**: As defined in [YOUR_ORGANIZATION_S_GDPR_POLICY_DOCUMENT]. This includes but is not limited to: names, identification numbers, location data, online identifiers, or factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of a natural person.
- **Third Party**: Any natural person who is not the data subject making the current request.
- **Disproportionate Effort**: Redaction that would require manual re-creation of the document or fundamentally alter its meaning, as per [YOUR_ORGANIZATION_S_REDACTION_POLICY].

**CONSTRAINTS:**
- Do not output any raw personal data in your refusal explanation.
- Do not speculate on the identity of third parties.
- If you are uncertain between MIXED and CLEAR, always default to MIXED and flag for human review.
- Your output must be a valid JSON object conforming to [OUTPUT_SCHEMA].

**OUTPUT SCHEMA:**
{
  "decision": "CLEAR" | "MIXED" | "THIRD_PARTY_ONLY",
  "message": "string", // The safe response or refusal message
  "log_for_review": boolean, // true if the record requires human review
  "record_id": "string" // The ID of the record from [INPUT]
}

**EXAMPLES:**
[FEW_SHOT_EXAMPLES_OF_MIXED_AND_THIRD_PARTY_RECORDS]

**RISK LEVEL:** [HIGH/MEDIUM] - Human review is mandatory for all MIXED decisions.

To adapt this template, replace the bracketed placeholders with your specific operational context. [YOUR_ORGANIZATION_S_GDPR_POLICY_DOCUMENT] should be a concise, inline summary of your legal team's definition of personal data, not a link to a document the model cannot access. [YOUR_ORGANIZATION_S_REDACTION_POLICY] must clarify the threshold for 'disproportionate effort' to prevent the model from over-flagging easily redacted documents. The [FEW_SHOT_EXAMPLES_OF_MIXED_AND_THIRD_PARTY_RECORDS] placeholder is critical for performance; provide at least two contrasting examples of a MIXED record (e.g., a joint bank statement) and a THIRD_PARTY_ONLY record (e.g., an internal email about another customer) to calibrate the model's boundary detection. Finally, set the [RISK_LEVEL] to HIGH to enforce a conservative bias, ensuring all ambiguous cases are routed for human review rather than being incorrectly released.

Integrating this prompt into a production DSAR workflow requires treating it as a gating step, not a standalone filter. The prompt should sit between the data retrieval layer and the response assembly layer. When a DSAR response is compiled—often from multiple source systems—each candidate record or text segment passes through this refusal prompt before inclusion. The application must not simply concatenate model outputs; it must parse the structured refusal decision and act on it. A typical integration pattern: the retrieval service returns a batch of records, each record is wrapped in a [RECORD] placeholder and sent to the model, and the model returns a JSON decision per record (allow, redact, refuse, escalate). The application then routes each record accordingly—redacted versions go through a sanitization step, refused records are logged and excluded, and escalated records enter a human review queue.

Validation is critical because a malformed refusal decision can silently leak third-party data. Implement a strict output schema validator that rejects any model response missing the required fields (decision, rationale, third_party_indicators, redaction_plan). If validation fails, retry once with a stronger constraint instruction appended to the prompt. If the retry also fails, escalate the entire record batch to human review rather than defaulting to inclusion. Log every decision with the record ID, model version, prompt version, and decision timestamp for auditability. For high-risk deployments, add a secondary check: a regex or NER-based scanner that flags known PII patterns (names, emails, phone numbers) in any record marked allow. If the scanner finds a conflict with the model's decision, escalate that record. This defense-in-depth approach catches model errors before they reach the data subject.

Model choice matters. Use a model with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are reasonable defaults. Avoid smaller or older models that may hallucinate JSON structure or miss subtle third-party data signals. Set temperature=0 to maximize deterministic refusal behavior. If latency is a concern, batch up to 10 records per request but ensure each record has a unique identifier in the prompt so decisions can be mapped back. Never send raw database rows without context—always include the field name and source system so the model can distinguish a name field from a product_description field. Finally, build a dashboard that tracks refusal rates, escalation rates, and validation failure rates over time. A sudden drop in refusals may indicate prompt drift or a model behavior change; a spike in escalations may indicate a retrieval system pulling in more third-party data than expected.