Regulatory Compliance Review Handoff Prompt

This prompt is designed for compliance architects and AI platform engineers building systems in regulated domains such as finance, healthcare, or legal services. Its primary job is to act as a safety net: it analyzes an AI-generated input or output and determines if it triggers a regulatory obligation, such as providing specific disclosures, retaining records, or requiring human review. The prompt produces a structured handoff request that includes the specific regulation, a summary of the concern, and the exact evidence excerpt, enabling a human compliance officer to make a fast, informed decision without re-investigating the entire interaction.

Use this prompt when your AI system processes user-generated content, generates advice, or makes decisions that could fall under regulations like GDPR, HIPAA, PCI-DSS, or financial conduct rules. It is most effective when integrated as a post-processing step or an output guardrail, scanning content before it is sent to the user or stored. You should not use this prompt for real-time blocking of abusive content (use an abuse detection prompt instead) or for making a final compliance determination. Its role is strictly to identify potential triggers and escalate them, not to interpret the law or decide the outcome. The prompt requires you to provide a configurable list of regulations with their triggers, the content to be reviewed, and a risk tolerance level to calibrate its sensitivity.

Before deploying, you must test this prompt extensively against a golden dataset of known compliance violations and benign edge cases. The highest risk is under-escalation on indirect regulatory triggers, such as a user implying a medical condition without stating it explicitly. Your evaluation suite should measure recall on these indirect cases and allow you to adjust the prompt's instructions or the [REGULATORY_FRAMEWORK] input to close gaps. Always route the output to a human review queue; never use this prompt to automatically block or reject content without human confirmation in a high-stakes regulatory context.

This template is designed to be the core instruction set for an AI system acting as a compliance triage filter. It takes an input or generated output and evaluates it against a configurable set of regulatory obligations. The goal is not to make a final compliance determination, but to reliably identify potential triggers and package the concern, evidence, and relevant regulation into a structured handoff for a human compliance reviewer. The prompt uses square-bracket placeholders so you can wire in your specific regulatory taxonomy, risk tolerance, and output format without rewriting the core logic.

textCopy
You are a compliance triage assistant operating in a regulated domain. Your task is to review the provided [INPUT_OR_OUTPUT] and determine if it triggers any regulatory obligations defined in [REGULATORY_TAXONOMY].

Do not make a final compliance decision. Your job is to identify potential triggers and prepare a structured review request for a human compliance officer.

Review the content against each regulation in the taxonomy. For each potential trigger, you must provide:
- The specific regulation and clause from [REGULATORY_TAXONOMY] that may apply.
- A concise summary of the concern, explaining why the content might be non-compliant.
- An exact excerpt from the [INPUT_OR_OUTPUT] that is the source of the concern.
- A preliminary severity assessment using the levels defined in [RISK_MATRIX].

If no regulatory triggers are found, explicitly state "NO_TRIGGERS_IDENTIFIED" and provide a brief justification.

[INPUT_OR_OUTPUT]:
---
[CONTENT]
---

[REGULATORY_TAXONOMY]:
---
[TAXONOMY_JSON]
---

[RISK_MATRIX]:
---
[RISK_LEVELS]
---

Produce a single JSON object as your output. The object must conform to this schema:
{
  "review_id": "string",
  "has_triggers": boolean,
  "triggers": [
    {
      "regulation": "string",
      "concern_summary": "string",
      "evidence_excerpt": "string",
      "severity": "string"
    }
  ],
  "justification_if_no_triggers": "string"
}

To adapt this template, start by replacing the placeholders with your specific operational data. [CONTENT] should be the exact text of the user input or AI-generated output under review. [TAXONOMY_JSON] is a critical component; it should be a structured JSON object defining the regulations, their clauses, and keywords that are in scope for your system. For example, it might include entries for GDPR, CCPA, or sector-specific rules like HIPAA or PCI-DSS. [RISK_LEVELS] should define your internal severity tiers, such as ["LOW", "MEDIUM", "HIGH", "CRITICAL"], with clear definitions. The output schema is designed for direct ingestion by a downstream review queue or logging system. For high-stakes domains, always log the raw prompt, the model's response, and the reviewer's final decision to maintain a complete audit trail.

This prompt is not a standalone chatbot instruction; it is a decision node in a compliance-aware AI pipeline. The typical integration point is immediately after content generation or before an automated action in a regulated domain. The application should invoke this prompt when a model output or user input touches a compliance-sensitive surface—such as financial advice, healthcare claims, or contractual language. The prompt expects a structured input containing the content to review, the applicable regulatory framework, and the business context. The output is a machine-readable compliance handoff payload that your application must parse, log, and potentially route to a human review queue.

Wiring the prompt into your application requires a wrapper function that constructs the input payload, calls the LLM, and validates the response against a strict schema. The input should include [CONTENT_TO_REVIEW], [REGULATORY_FRAMEWORK] (e.g., 'GDPR', 'HIPAA', 'SOX', 'PCI-DSS'), and [BUSINESS_CONTEXT] (e.g., 'customer onboarding email', 'investment recommendation'). The output schema must be enforced: expect a JSON object with compliance_concern_flag (boolean), concern_summary (string), specific_regulation_cited (string), evidence_excerpt (string), and recommended_action (enum: 'proceed', 'review', 'block'). Implement a validation layer that rejects malformed JSON, missing required fields, or recommended_action values outside the enum. On validation failure, retry once with the error message appended to the prompt as [PREVIOUS_ERROR]. If the retry also fails, escalate to a human operator with the raw output and validation errors logged.

Logging and audit trails are non-negotiable in this workflow. Every invocation must be logged immutably with: the full prompt input, the raw model output, the parsed compliance decision, the validator result, and the final routing action taken. This audit log serves as evidence for internal compliance reviews and external audits. Use structured logging (JSON to your observability stack) and include a unique review_id that ties the AI decision to any subsequent human review. Human review integration is triggered when recommended_action is 'review' or 'block'. Push the payload to a review queue (e.g., a Jira ticket, a Slack notification to the legal team, or a dedicated compliance dashboard). The human reviewer should see the concern_summary, evidence_excerpt, and a link to the full content. Do not allow the system to proceed automatically on 'review' or 'block' decisions without an explicit human override recorded in the audit log.

Model choice and performance considerations: This prompt requires strong instruction-following and low hallucination on regulatory topics. Prefer models with proven structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or fine-tuned variants). Avoid smaller or older models that may conflate regulations or miss indirect triggers. Set temperature=0 to maximize determinism. Monitor for common failure modes: (1) Under-escalation on indirect triggers—the model misses a compliance concern because the language is suggestive rather than explicit (e.g., 'guaranteed returns' in a non-binding summary). Mitigate this by including few-shot examples of indirect triggers in [EXAMPLES]. (2) Over-escalation on benign boilerplate—the model flags standard disclaimers as concerns. Mitigate by including counterexamples in [EXAMPLES] and calibrating with a test set. (3) Regulation hallucination—the model cites a regulation that does not exist or misapplies one. Mitigate by constraining specific_regulation_cited to a predefined list in [CONSTRAINTS] and implementing a post-hoc check against your regulatory taxonomy. Run this prompt through a regression test suite before any deployment, and monitor the escalation rate in production to detect drift.