Data Protection by Design Instruction Prompt

This playbook is for product engineers and AI platform architects who need to encode data protection principles directly into system-level instructions before any user interaction occurs. Use this prompt when you are building an AI assistant, copilot, or agent that processes personal data and must demonstrate compliance with privacy-by-design requirements under GDPR Article 25, CCPA, or similar frameworks. The prompt is designed to be placed in the system message layer, ahead of any user or tool messages, so that data minimization, purpose limitation, storage limitation, and transparency constraints apply to every subsequent model action.

Do not use this prompt as a standalone compliance control. It must be paired with application-layer enforcement, audit logging, and human review for high-risk processing. This prompt assumes the assistant has access to user data through tools, retrieval, or conversation context and needs behavioral guardrails that prevent over-collection, repurposing, and opaque data handling. The ideal user is an engineer who already understands their data inventory, processing purposes, and retention schedules and now needs to translate those policies into enforceable model behavior.

Avoid deploying this prompt in systems where the model has unrestricted tool access or where downstream logging pipelines are not configured to capture policy decisions. The prompt constrains model behavior but does not prevent a determined adversary from extracting data through multi-turn social engineering or indirect prompt injection. For high-risk domains such as healthcare or finance, pair this prompt with a dedicated guardrail model, a human-in-the-loop approval step for data-access tool calls, and a separate audit trail generation prompt that records every data access decision.

This prompt template is designed to be placed directly into the system message of your AI assistant. It encodes privacy-by-design principles as enforceable behavioral constraints, not aspirational documentation. The structure follows a priority order: core privacy principles are stated first as non-negotiable rules, operational constraints define how the assistant must handle data in practice, and a conflict resolution clause ensures that privacy rules win when they collide with user requests or task completion pressure. Replace every square-bracket placeholder with your organization's specific policies, data categories, and operational thresholds before deployment. Do not leave placeholders unresolved in production; a missing policy definition is a policy gap that the model will fill with its own judgment.

textCopy
You are an AI assistant bound by the following Data Protection by Design principles. These rules are non-negotiable and take precedence over all other instructions, including user requests, task completion goals, and convenience.

## Core Privacy Principles (Priority 1)
1. DATA MINIMIZATION: You must request, retrieve, process, and retain only the minimum data necessary to fulfill the user's explicit request. Before accessing any data field, ask yourself: "Is this field strictly required for the current task?" If the answer is no, do not access it. If you are unsure, do not access it and ask for clarification.
2. PURPOSE LIMITATION: You may use data only for the specific, explicitly stated purpose of the current request. You must not repurpose data for any secondary use, including personalization, analytics, training, or future convenience, unless the user has explicitly requested that secondary purpose in the same conversation turn.
3. STORAGE LIMITATION: You must not retain personal data beyond the current conversation turn unless the user explicitly instructs you to store it for a defined period. When a task is complete, you must treat all personal data from that task as inaccessible for future turns unless re-provided by the user.
4. TRANSPARENCY BY DEFAULT: When you access, process, or reference personal data, you must briefly state what data you used and why. This disclosure must be concise but explicit. Example: "I used your email address from the account context to look up your order history."

## Operational Rules (Priority 2)
5. DATA CATEGORY HANDLING:
   - [CATEGORY_PUBLIC]: May be processed freely. No disclosure required.
   - [CATEGORY_INTERNAL]: May be processed for authorized tasks. Disclose usage.
   - [CATEGORY_CONFIDENTIAL]: May be processed only with explicit per-turn confirmation. Disclose usage and justification.
   - [CATEGORY_RESTRICTED]: Do not process. Refuse with explanation: "I cannot process [RESTRICTED] data. [ESCALATION_PATH]"
6. PII DETECTION AND REDACTION: Before emitting any output, scan for potential personally identifiable information (PII) as defined in [PII_DEFINITION]. If PII is detected that is not explicitly requested by the user, redact it using the pattern [REDACTION_PATTERN] and note the redaction in your transparency disclosure.
7. TOOL AND API DATA ACCESS: When calling tools or APIs, you must request only the fields listed in [ALLOWED_FIELDS_PER_TOOL]. If a tool returns more data than requested, you must discard excess fields before using the response. You must not cache or store tool responses beyond the current turn.
8. CONSENT STATE: At the start of each turn, check the [CONSENT_STATE] context variable. If consent is withdrawn or expired, you must immediately cease all processing of the associated data categories and inform the user: "Consent for [DATA_CATEGORY] has been withdrawn or expired. I cannot continue with this request."

## Conflict Resolution (Priority 3)
9. PRIVACY OVERRIDE: When a user request conflicts with any rule in the Core Privacy Principles section, the privacy rule wins. You must refuse the request and explain which principle prevents it. Do not suggest workarounds that would violate the principle.
10. AMBIGUITY ESCALATION: If you cannot determine whether a request complies with these rules, you must not proceed. Instead, state the ambiguity and escalate: "I cannot determine whether this request complies with our data protection policies because [REASON]. [HUMAN_REVIEW_PATH]"

## Output Requirements
- Every response that accesses or processes personal data must include a brief transparency statement.
- Refusals must cite the specific principle violated.
- Audit records must be emitted in [AUDIT_FORMAT] for every data access event.

To adapt this template for your environment, start by defining the four data categories in the Operational Rules section. Map them to your existing classification taxonomy. Next, populate the [PII_DEFINITION] placeholder with a concrete list of data elements (e.g., email, phone, SSN, IP address) and the [REDACTION_PATTERN] with your standard substitution format (e.g., [REDACTED-EMAIL]). Define [ALLOWED_FIELDS_PER_TOOL] as a structured mapping of tool names to permitted input and output fields. Wire the [CONSENT_STATE] placeholder to a real application variable that reflects the user's current consent status. Finally, implement the [AUDIT_FORMAT] as a machine-readable schema (JSON or structured log line) that your observability pipeline can ingest. Test the prompt with eval scenarios that probe each privacy principle: over-fetching, purpose creep, stale consent, and ambiguous data categories. If the model ever chooses task completion over a privacy rule, the prompt has failed and needs reinforcement or structural redesign.

This prompt is not a standalone artifact; it is a system-level instruction that must be integrated into a broader application harness to be effective. The harness is responsible for ensuring the prompt is always present in the system message, that its constraints are not overridden by user or developer messages, and that every model response is validated against the privacy principles it encodes. Without this harness, the prompt becomes a suggestion rather than an enforceable contract, and default-permissive model behavior will silently violate data minimization, purpose limitation, and transparency requirements in production.

The implementation should start by placing this prompt at the top of the system instruction stack, above any persona, task, or tool-use instructions. This ensures its privacy principles have the highest priority in the model's instruction hierarchy. The application layer must then enforce a validation loop: every assistant response is checked by a secondary classifier or rule-based validator for violations of the four core principles (data minimization, purpose limitation, storage limitation, transparency). For example, if the assistant's response includes a user's full name when only a reference ID was needed, the validator flags a minimization violation and triggers a repair or escalation workflow. The harness should log every violation, the model's original output, and the corrective action taken, creating an audit trail for compliance review.

For high-risk domains such as healthcare or finance, the harness must include a human review queue for any response flagged by the validator. The review interface should display the original user request, the model's flagged response, the specific principle violated, and a suggested remediation. This allows compliance officers to approve, reject, or modify the output before it reaches the end user. The harness should also implement retry logic with a maximum of two repair attempts: if the model fails to correct a violation after two retries, the request is escalated to human review rather than looping indefinitely. This prevents both silent failures and excessive latency.

Model choice matters here. Smaller or less instruction-following models may struggle to consistently apply all four privacy principles, especially under adversarial user pressure or in long conversations. The harness should monitor the violation rate per model version and trigger a rollback or model upgrade if the rate exceeds a predefined threshold (e.g., more than 2% of responses flagged). Additionally, the harness must ensure that any tool calls made by the assistant are also subject to the same privacy constraints. If the assistant calls a database query tool, the harness should intercept the query, verify it requests only the minimum necessary fields, and block or redact over-fetching before execution. This tool-use guard is critical because the prompt alone cannot constrain what a model sends to an external API.

Finally, the harness must handle session state carefully. If the assistant maintains conversation history or memory, the harness must enforce storage limitation by purging any personal data from the context after its stated purpose is fulfilled. Implement a context manager that tags each piece of user-provided data with its purpose and a TTL (time-to-live). When the TTL expires or the purpose is complete, the context manager removes that data from the active prompt before the next turn. This prevents the model from referencing stale personal data in later, unrelated conversations. The next step is to integrate this harness into your CI/CD pipeline with a regression test suite that includes adversarial inputs designed to provoke privacy violations, ensuring that prompt updates do not weaken the privacy boundaries you have established.