Data Privacy and PII Protection Redirection Prompt

This prompt is for privacy engineers and product developers who need a reliable, automated way to handle user requests that seek to extract, expose, or manipulate personal data. The primary job-to-be-done is to programmatically refuse a disallowed request while preserving user trust by immediately redirecting the conversation toward legitimate data access paths, privacy best practices, and data subject rights information. The ideal user is an engineer integrating this prompt into a customer-facing AI feature, a support chatbot, or an internal data-handling tool where the risk of PII leakage is high.

Deploy this prompt when your system must handle ambiguous or direct requests for personal information that fall outside authorized data access APIs. This includes requests like 'show me John's email,' 'what is the home address for user ID 456,' or 'summarize the HR file for Jane Doe.' The prompt is designed to be a safety net, not a primary access control. It should be used in conjunction with application-layer authorization checks. Do not use this prompt as a substitute for proper data masking, access control lists (ACLs), or encryption. It is a behavioral guardrail for the model, not a security control for your database.

Before implementing, ensure you have a clear internal definition of PII for your jurisdiction and use case, a documented data subject access request (DSAR) process, and a list of approved internal tools for legitimate data retrieval. The prompt requires these as inputs to provide a useful redirection. The next step is to copy the prompt template, populate the placeholders with your specific policies, and integrate it into your AI safety stack. Avoid deploying this prompt without a human review step for any output that references specific internal systems or legal text to prevent misdirection.

This template is designed for privacy engineers and product teams who need a consistent, legally-aware refusal when a user asks the system to extract, expose, or manipulate personal data. The prompt produces a structured refusal that explains why the request cannot be fulfilled, cites the relevant privacy principle, and offers a constructive redirection to legitimate data subject rights processes, internal privacy tools, or organizational policies. Use this when you need a refusal that is firm on boundaries but helpful enough to prevent user frustration and support ticket escalation.

textCopy
You are a privacy-aware assistant operating under [ORGANIZATION_NAME]'s data protection policies. Your primary directive is to protect personal data and guide users toward legitimate data access paths.

When a user requests extraction, exposure, or manipulation of personal data, you must:
1. Refuse the request clearly and calmly.
2. Identify the relevant privacy principle (e.g., data minimization, purpose limitation, user consent).
3. Redirect to the appropriate legitimate path based on the request type.

## Request Categories and Redirection Paths
- Data access or export requests: Direct to [DSAR_PORTAL_URL] or instruct to contact [DPO_EMAIL].
- PII extraction from documents: Explain that bulk extraction of personal data from [DOCUMENT_TYPE] is restricted. Suggest using [REDACTION_TOOL_NAME] to remove PII first, or contact [PRIVACY_TEAM_CONTACT].
- Contact information or identity lookups: Refuse and direct to [LEGITIMATE_LOOKUP_TOOL] or [HR_PORTAL] for internal directory searches.
- Re-identification or de-anonymization attempts: Issue a firm refusal. State that re-identification violates [POLICY_NAME] and may be unlawful under [REGULATION_REFERENCE]. Do not offer an alternative path.
- General PII handling questions: Provide educational guidance on [ORGANIZATION_NAME]'s data classification policy and refer to [TRAINING_PORTAL] for mandatory training.

## Refusal Structure
For each refusal, output a JSON object with the following schema:
{
  "decision": "refused",
  "privacy_principle": "string",
  "explanation": "string (clear, plain-language reason for refusal)",
  "redirection": {
    "path": "string (one of: dsar_portal, redaction_tool, privacy_contact, training_resource, firm_refusal)",
    "message": "string (actionable next step for the user)",
    "contact": "string or null (email, URL, or team name)"
  },
  "risk_level": "string (low, medium, high, critical)"
}

## Constraints
- Never output actual PII in your response, even as an example.
- If the request is ambiguous, classify it as high risk and refuse with a privacy_contact redirection.
- For [REGULATION_REFERENCE] compliance, always default to the most restrictive interpretation when uncertain.
- Do not suggest workarounds that bypass data protection controls.

## Input
User request: [USER_REQUEST]
Context: [CONVERSATION_CONTEXT]
Applicable policies: [POLICY_DOCUMENTS]

## Output
Return only the JSON object. No other text.

To adapt this template, replace the square-bracket placeholders with your organization's specific tools, contacts, and policy references. The [ORGANIZATION_NAME], [DSAR_PORTAL_URL], [DPO_EMAIL], and [PRIVACY_TEAM_CONTACT] fields should point to real internal resources. The [REGULATION_REFERENCE] placeholder should cite the specific regulation your organization operates under (e.g., GDPR, CCPA, HIPAA). The [POLICY_DOCUMENTS] field can be populated via RAG retrieval from your internal policy store to ground the refusal in actual policy language. Before deploying, validate that the JSON schema matches your logging and monitoring infrastructure, and set up eval checks that verify the risk_level classification is appropriate for each request category. For high-risk and critical classifications, route the output to a human review queue before the refusal is sent to the user.

This prompt is designed to sit behind a pre-processing detection layer, not as a standalone filter. Before the prompt ever sees a user request, your application should run a PII scanner (such as Presidio, AWS Comprehend, or a regex-based detector) on the input. If the scanner flags potential PII with high confidence, the request should be blocked or redacted before reaching the model. This prompt handles the ambiguous middle: requests where the user is asking about personal data, asking how to extract it, or phrasing a request that could be interpreted as a data exfiltration attempt. The model's job is to refuse the request while offering a legitimate path forward—such as data subject access request (DSAR) procedures, privacy policy links, or data export tools your product already provides.

Integration pattern: Wrap this prompt in a function that accepts [USER_REQUEST], [USER_CONTEXT] (authentication status, data subject role, jurisdiction hints), and [ORGANIZATION_POLICY] (your privacy policy URL, DSAR instructions, and approved redirection paths). The function should: (1) log the original request and the model's refusal decision for audit purposes; (2) validate that the output contains no PII (run the same scanner on the model's response—models can hallucinate PII); (3) check that the response includes a concrete alternative rather than a bare refusal; and (4) if confidence is low or the request involves sensitive data types (health, financial, children's data), route to a human review queue before the response is returned to the user. Do not rely on the model alone to detect PII in its own output.

Model choice and latency: This prompt works with most capable models (GPT-4, Claude 3.5, Gemini 1.5 Pro). For high-throughput systems, consider a two-tier architecture: a smaller, faster model handles clear-cut cases (obvious PII extraction requests), while ambiguous or high-risk requests escalate to a larger model with this full prompt. Retry logic: If the model's response fails validation (e.g., it contains a refusal but no alternative, or it accidentally echoes PII), retry once with an explicit instruction to correct the specific failure. If the second attempt also fails, escalate to human review. Never retry more than twice on privacy-sensitive requests—each retry is another chance for data leakage.

Testing and evals: Before deploying, build a test suite with at least 50 cases spanning: direct PII extraction requests, indirect social engineering attempts, legitimate DSAR inquiries, requests for anonymized data, and edge cases where the user mentions their own data. Measure three outcomes: (1) refusal rate on extraction attempts (target >95%), (2) false positive rate on legitimate requests (target <5%), and (3) alternative quality score (does the redirection point to a real, working path?). Run these evals on every prompt or model change. Log all refusal decisions with the request category, model confidence, and whether human review was triggered—this audit trail is essential for privacy compliance reviews and incident response.