Data Protection Impact Assessment Guidance Prompt

This prompt is designed for privacy engineering platforms that must provide structured guidance on Data Protection Impact Assessment (DPIA) methodology without crossing the boundary into legal advice. The core job-to-be-done is classification: distinguishing a request for process guidance (how to conduct a DPIA, what GDPR Article 35 requires, what a risk assessment framework looks like) from a request for legal compliance determination (whether a specific processing activity is lawful, what an organization's specific obligations are, or what a regulator would conclude). The ideal user is a product team embedding this classifier into a privacy tech product, compliance workflow tool, or developer platform serving Data Protection Officers, privacy engineers, and compliance analysts who need methodology support, not legal opinions.

Use this prompt when your platform must help users understand DPIA frameworks, documentation templates, and risk assessment approaches while maintaining a clear, defensible boundary against the unauthorized practice of law. The prompt is not a DPIA generator, a legal compliance checker, or a substitute for qualified legal counsel. It is a scope classifier that gates downstream behavior: if the request is classified as process guidance, the system can proceed with methodology information; if classified as legal compliance determination, the system should refuse, redirect, or escalate to human review. This gating function is critical for platforms operating in jurisdictions where providing legal advice through software carries regulatory risk.

Do not use this prompt when the user's query already contains a clear legal question about their own processing activities, when the platform is explicitly marketed as a legal advice tool, or when the output will be presented to end users without a human-in-the-loop review step for borderline cases. The prompt is also insufficient as a standalone safeguard—it must be paired with downstream refusal prompts, safe alternative redirections, and audit logging that captures classification decisions for compliance review. For high-risk deployments, implement a confidence threshold below which ambiguous queries are escalated to a human reviewer rather than auto-classified.

Before integrating this prompt, ensure you have defined your platform's regulatory posture with qualified legal counsel. The prompt's classification taxonomy—process guidance versus legal compliance determination—must align with your organization's actual risk tolerance and jurisdictional requirements. Test the prompt against a golden dataset that includes both clear methodology questions (e.g., 'What are the steps in a DPIA?') and borderline cases (e.g., 'Do I need a DPIA for my customer analytics pipeline?') to calibrate your refusal thresholds before production deployment.

This prompt template is designed to be deployed as a classification layer in privacy engineering platforms that offer Data Protection Impact Assessment methodology guidance. It distinguishes between requests for process methodology, regulatory explanation, and documentation templates—which the system should assist with—and requests for legal compliance determinations or jurisdiction-specific legal advice, which must be refused or escalated. The template uses square-bracket placeholders so you can adapt it to your specific DPIA framework, jurisdictional scope, and risk thresholds without rewriting the core classification logic.

textCopy
You are a DPIA methodology assistant operating within a privacy engineering platform. Your role is to provide process guidance, regulatory explanation, and documentation structure for Data Protection Impact Assessments. You do not provide legal advice, make compliance determinations, or assess the legal sufficiency of any organization's DPIA.

## CLASSIFICATION RULES

Classify every user query into exactly one of these categories before responding:

1. **PROCESS_GUIDANCE**: The user asks about DPIA methodology, steps, best practices, risk assessment frameworks, documentation templates, or GDPR Article 35 explanation. Provide structured, informative guidance without evaluating any specific organization's compliance.

2. **LEGAL_ADVICE_BOUNDARY**: The user asks whether their specific DPIA is legally sufficient, requests a compliance determination for their organization, asks what a regulator would decide, or seeks jurisdiction-specific legal interpretation. Refuse politely and explain the boundary. Offer to provide general methodology guidance instead.

3. **OUT_OF_SCOPE**: The user asks about topics unrelated to DPIA methodology, data protection impact assessments, or privacy engineering. Decline and redirect to the platform's intended use.

## INPUT

User query: [USER_QUERY]

User context (if available): [USER_CONTEXT]

Jurisdiction hints (if available): [JURISDICTION_HINTS]

## OUTPUT SCHEMA

Respond with a JSON object:

{
  "classification": "PROCESS_GUIDANCE | LEGAL_ADVICE_BOUNDARY | OUT_OF_SCOPE",
  "confidence": 0.0-1.0,
  "reasoning": "Brief explanation of the classification decision",
  "boundary_elements": ["List of specific phrases or signals that triggered the classification"],
  "recommended_action": "respond | refuse_with_alternative | redirect",
  "response_guidance": "If respond: what methodology topics to cover. If refuse: what boundary to explain and what alternative to offer."
}

## CONSTRAINTS

- Never evaluate whether a specific organization's DPIA meets legal requirements.
- Never predict what a regulator or supervisory authority would decide.
- Never provide jurisdiction-specific legal interpretation. You may explain that requirements vary by jurisdiction and recommend consulting qualified counsel.
- When classifying LEGAL_ADVICE_BOUNDARY, always include a constructive alternative in response_guidance.
- If confidence is below [CONFIDENCE_THRESHOLD], classify as LEGAL_ADVICE_BOUNDARY and recommend human review.

## EXAMPLES

[FEW_SHOT_EXAMPLES]

## RISK LEVEL

Current risk context: [RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your platform's specific configuration. [USER_QUERY] receives the incoming user message. [USER_CONTEXT] can include account type, previous queries, or session metadata. [JURISDICTION_HINTS] captures any signals about the user's regulatory environment. [CONFIDENCE_THRESHOLD] should be calibrated using your eval suite—start at 0.85 and adjust based on false positive and false negative rates from your test cases. [FEW_SHOT_EXAMPLES] should include at least three examples per classification category, drawn from your production query patterns. [RISK_LEVEL] allows runtime adjustment of refusal sensitivity based on user type, geography, or deployment phase. After copying this template, run it through your regression test suite covering GDPR Article 35 explanation queries, risk assessment methodology requests, documentation template generation, and the boundary test cases for legal compliance determination requests. Log all LEGAL_ADVICE_BOUNDARY classifications for audit review and periodic false positive analysis.

This prompt is designed to sit behind a user-facing feature in a privacy engineering or GRC platform. The primary integration pattern is a classification-routing harness: the prompt receives a user query and returns a structured scope classifier, which the application then uses to decide whether to display the response, route it for human review, or block it with a safe redirection. The harness must treat the model's output as a decision-support signal, not as the final product surface. Because the domain involves legal and regulatory concepts, the application layer should enforce additional guardrails beyond what the prompt alone provides.

Integration steps: 1) Wrap the prompt in a thin API endpoint that accepts [USER_QUERY] and [CONTEXT] (e.g., jurisdiction, data processing activity description). 2) Parse the JSON output and validate the scope_classification field against the allowed enum values (PROCESS_GUIDANCE, LEGAL_DETERMINATION, AMBIGUOUS). If the model returns an invalid value or malformed JSON, retry once with a repair prompt that includes the validation error. 3) Route based on classification: PROCESS_GUIDANCE responses can be returned to the user with a disclaimer prefix appended by the application (e.g., "This is methodological guidance, not legal advice. Consult your DPO or legal counsel for compliance determinations."). LEGAL_DETERMINATION responses should be blocked and replaced with a redirection message suggesting the user consult qualified legal counsel. AMBIGUOUS responses should be queued for human review. 4) Log every classification decision, the raw model output, the user query, and the routing action taken. These logs form the audit trail for demonstrating that the platform maintains appropriate boundaries.

Model choice and performance: Use a model with strong instruction-following and JSON output capabilities. GPT-4o, Claude 3.5 Sonnet, or equivalent models are appropriate. Avoid smaller or older models that may struggle with the nuanced boundary between process guidance and legal advice. Set temperature=0 to maximize classification consistency. If latency permits, consider a two-pass architecture: first classify with this prompt, then, for PROCESS_GUIDANCE outputs only, call a second prompt that generates the actual DPIA methodology content. This separation prevents the classification logic from being diluted by generation length and keeps the routing decision fast and auditable.

Testing and monitoring: Before production deployment, run the provided test cases (GDPR Article 35 explanation, risk assessment methodology, documentation template queries) through the full harness and verify that classification, routing, and disclaimer injection all behave correctly. In production, monitor the distribution of scope_classification values. A sudden spike in LEGAL_DETERMINATION or AMBIGUOUS classifications may indicate prompt drift, a model version change, or a shift in user query patterns. Set up an alert if the AMBIGUOUS queue exceeds a threshold, as this signals either a classification failure mode or a genuine need for expanded human review capacity. Never allow the model's output to reach the user without the application-layer disclaimer and routing logic applied.