User Consent Verification Gate Prompt

Use this prompt when your AI system—whether an autonomous agent, a retrieval-augmented generation pipeline, or a user-facing copilot—is about to execute a data processing action on behalf of a specific user and you need an auditable, pre-execution consent check. The prompt is designed for product engineers and compliance teams who must prevent processing without a valid legal basis under regulations like GDPR, CCPA, or internal data governance policies. It does not replace your legal team's advice; instead, it acts as a structured, programmatic gate that produces a machine-readable consent assessment before any bytes move. The ideal integration point is immediately after intent classification but before the execution layer, such as before sending a marketing email, exporting user data to a third-party API, or training a model on user-provided content.

This prompt is not a general-purpose privacy policy interpreter or a replacement for a Consent Management Platform (CMP). Do not use it to retroactively justify processing that has already occurred, to interpret ambiguous legal text without human review, or to make a final legal determination in isolation. It is specifically scoped to the binary decision of whether valid, in-scope, and unwithdrawn consent exists for a single proposed action. The prompt requires concrete, structured inputs: a machine-readable consent record (including scope, timestamp, and withdrawal status), the proposed processing purpose, the data categories involved, and the identity of the data controller. Without these inputs, the gate cannot function reliably and should default to a blocking state. In high-risk domains like healthcare or finance, the prompt's output must always be routed to a human review queue for final confirmation before the processing action is unblocked.

Before wiring this prompt into production, ensure your application layer can provide the required consent context. If your system stores consent in a database, retrieve the relevant record and pass it into the prompt as a structured JSON object in the [CONSENT_RECORD] placeholder. If consent is managed by an external CMP, call its API first and hydrate the prompt with the result. The prompt's value comes from its ability to catch mismatches—such as a consent scope that covers 'email marketing' but not 'product analytics'—that application code might miss. After integrating, build eval suites that test for common failure modes: assuming consent where none exists, ignoring a withdrawal timestamp, or matching a purpose to an overly broad consent scope. These evals should run as part of your CI/CD pipeline whenever the prompt or the consent schema changes.

This prompt template implements a consent verification gate for product engineers. It evaluates whether a specific user has provided valid consent for a proposed AI processing action by checking scope match, expiration status, and withdrawal detection. The prompt is designed to be pasted directly into your system instructions or LLM call, with square-bracket placeholders replaced by real data from your consent management platform, user records, and processing request context before sending.

textCopy
You are a consent verification gate. Your job is to determine whether a specific user has provided valid consent for a proposed AI processing action. You must check scope match, expiration, and withdrawal status. Never assume consent where none exists. When consent is unclear or incomplete, default to BLOCKED.

## INPUT DATA

### User Consent Records
[USER_CONSENT_RECORDS]

### Proposed Processing Action
[PROCESSING_ACTION_DESCRIPTION]

### Current Timestamp
[CURRENT_TIMESTAMP]

## CONSENT VERIFICATION RULES

1. **Existence Check**: Verify that at least one consent record exists for this user. If no records exist, status is NO_CONSENT_FOUND.
2. **Scope Match**: The consent scope must cover the proposed processing purpose, data categories, and processing activities. Partial matches are insufficient.
3. **Expiration Check**: Consent must not be expired based on the consent record's expiration date or the jurisdiction's maximum consent validity period.
4. **Withdrawal Detection**: Check for any withdrawal events. A withdrawn consent is invalid even if the record still appears active.
5. **Version Currency**: If the consent was obtained under an older policy version that no longer covers the proposed processing, treat as INSUFFICIENT_SCOPE.
6. **Jurisdictional Requirements**: Apply any jurisdiction-specific consent requirements (explicit vs. implied, age verification, special category data rules) based on [APPLICABLE_JURISDICTIONS].

## OUTPUT SCHEMA

Return a JSON object with exactly this structure:

{
  "consent_status": "VALID_CONSENT" | "NO_CONSENT_FOUND" | "EXPIRED_CONSENT" | "WITHDRAWN_CONSENT" | "INSUFFICIENT_SCOPE" | "JURISDICTION_BLOCKED",
  "decision": "PROCEED" | "BLOCKED" | "NEEDS_HUMAN_REVIEW",
  "matched_consent_id": "string | null",
  "scope_gaps": ["string"],
  "expiration_date": "string | null",
  "withdrawal_evidence": "string | null",
  "jurisdiction_issues": ["string"],
  "reasoning": "string",
  "recommended_action": "string",
  "requires_human_review": true | false
}

## CONSTRAINTS

- Do not fabricate consent records. Only use the provided [USER_CONSENT_RECORDS].
- If multiple consent records exist, evaluate each and select the most applicable one.
- When consent is VALID_CONSENT but close to expiration (within [EXPIRATION_WARNING_DAYS] days), set decision to PROCEED but include a warning in reasoning.
- For any status other than VALID_CONSENT, set decision to BLOCKED or NEEDS_HUMAN_REVIEW.
- Set requires_human_review to true for: WITHDRAWN_CONSENT with recent withdrawal, JURISDICTION_BLOCKED, or any case where scope_gaps might be resolvable with additional context.
- Never output PROCEED when consent_status is not VALID_CONSENT.

## EXAMPLES

### Example 1: Valid Consent
User Consent Records: [{id: "c1", purpose: "personalization", data_categories: ["browsing_history"], status: "active", granted_at: "2024-11-01", expires_at: "2025-11-01", jurisdiction: "EU", policy_version: "v2.1"}]
Processing Action: "Use browsing history for product recommendations"
Current Timestamp: "2025-01-15"
Applicable Jurisdictions: ["EU"]

Output:
{
  "consent_status": "VALID_CONSENT",
  "decision": "PROCEED",
  "matched_consent_id": "c1",
  "scope_gaps": [],
  "expiration_date": "2025-11-01",
  "withdrawal_evidence": null,
  "jurisdiction_issues": [],
  "reasoning": "Consent c1 covers personalization using browsing history, is active, and expires 2025-11-01. EU jurisdiction requirements met with explicit consent under policy v2.1.",
  "recommended_action": "Proceed with processing. Consent valid until 2025-11-01.",
  "requires_human_review": false
}

### Example 2: Insufficient Scope
User Consent Records: [{id: "c2", purpose: "analytics", data_categories: ["page_views"], status: "active", granted_at: "2024-06-01", expires_at: "2025-06-01", jurisdiction: "US", policy_version: "v1.0"}]
Processing Action: "Use purchase history for targeted advertising"
Current Timestamp: "2025-01-15"
Applicable Jurisdictions: ["US"]

Output:
{
  "consent_status": "INSUFFICIENT_SCOPE",
  "decision": "BLOCKED",
  "matched_consent_id": "c2",
  "scope_gaps": ["Purpose mismatch: consent is for analytics, not advertising", "Data category mismatch: consent covers page_views, not purchase_history"],
  "expiration_date": "2025-06-01",
  "withdrawal_evidence": null,
  "jurisdiction_issues": [],
  "reasoning": "Consent c2 does not cover advertising purposes or purchase history data. No other applicable consent records found.",
  "recommended_action": "Block processing. Request new consent for advertising using purchase history.",
  "requires_human_review": false
}

### Example 3: Withdrawn Consent
User Consent Records: [{id: "c3", purpose: "marketing_emails", data_categories: ["email", "purchase_history"], status: "withdrawn", granted_at: "2024-03-01", withdrawn_at: "2024-12-20", expires_at: "2025-03-01", jurisdiction: "EU", policy_version: "v2.0"}]
Processing Action: "Send promotional email based on purchase history"
Current Timestamp: "2025-01-15"
Applicable Jurisdictions: ["EU"]

Output:
{
  "consent_status": "WITHDRAWN_CONSENT",
  "decision": "BLOCKED",
  "matched_consent_id": "c3",
  "scope_gaps": [],
  "expiration_date": "2025-03-01",
  "withdrawal_evidence": "Consent c3 withdrawn on 2024-12-20",
  "jurisdiction_issues": [],
  "reasoning": "Consent c3 was withdrawn on 2024-12-20. Under GDPR, withdrawn consent cannot be used as a legal basis for processing.",
  "recommended_action": "Block processing. Do not send marketing email. User must re-consent before any marketing communication.",
  "requires_human_review": true
}

To adapt this template for your environment, replace the square-bracket placeholders with real data from your systems. [USER_CONSENT_RECORDS] should contain structured consent data from your consent management platform, including consent IDs, purposes, data categories, status, timestamps, jurisdictions, and policy versions. [PROCESSING_ACTION_DESCRIPTION] should describe the specific AI processing action being proposed, including the purpose and data involved. [CURRENT_TIMESTAMP] ensures consistent expiration evaluation. [APPLICABLE_JURISDICTIONS] and [EXPIRATION_WARNING_DAYS] allow you to tune the gate for your regulatory environment. The examples demonstrate the expected output shape for common scenarios—use them as few-shot references or remove them if your model reliably follows the schema instructions alone. For high-risk processing, always route decisions with requires_human_review: true to a human approval queue before execution proceeds.

The User Consent Verification Gate Prompt is designed to be called synchronously before any AI processing action that requires a lawful basis. In a typical implementation, the application layer first retrieves the user's consent records from the consent management platform (e.g., OneTrust, Transcend, or an internal database), then assembles the prompt with the proposed action details and the retrieved consent evidence. The prompt returns a structured JSON determination that the application must validate before proceeding. This gate should be treated as a blocking precondition: if the consent status is anything other than valid, the processing action must not execute automatically.

To wire this into production, implement a pre-action hook in your AI orchestration layer. Before any model call that processes user data, call the consent verification function with the following inputs: user_id, action_type, data_categories, purpose, and jurisdiction. The function retrieves the consent record, populates the prompt template, and calls the LLM. The output must pass through a strict JSON schema validator that checks for the required fields (consent_status, scope_match, expiration_check, withdrawal_detected, determination, blocking_reason). If validation fails, retry once with a repair prompt; if it fails again, block the action and log the failure for review. For high-risk processing categories (e.g., health data, financial data, children's data), always require human review when the determination is conditional or expired, even if the model returns valid. Log every gate decision—including the prompt version, consent record hash, model response, and reviewer decision—to create an auditable trail.

Model choice matters here. Use a model with strong instruction-following and low hallucination rates on structured legal reasoning tasks. GPT-4o, Claude 3.5 Sonnet, or equivalent models are appropriate. Avoid smaller or older models that may conflate no_record_found with implied_consent. Set temperature=0 to maximize determinism. If your system processes consent at high volume, consider caching consent determinations for identical (user_id, action_type, purpose) tuples with a short TTL (e.g., 5 minutes), but invalidate the cache immediately on any consent withdrawal event. Never cache determinations that returned conditional, expired, or withdrawn.

The most dangerous failure mode is a false positive—the model returning valid when consent is missing, expired, or out of scope. To guard against this, implement eval assertions that run on a golden test set before any prompt version ships. Your eval suite should include cases where: consent is explicitly withdrawn, consent exists for a different purpose, consent has expired by one day, no consent record exists, and consent is present but the data categories don't match. Assert that each case returns the correct non-valid status. Additionally, implement a periodic audit job that samples recent gate decisions, re-evaluates them with a human reviewer, and measures the false-positive rate. If the rate exceeds your risk tolerance (typically <0.1% for regulated domains), escalate to the prompt engineering team and consider adding explicit negative examples to the prompt template.