Regulatory Compliance Gate Check Prompt Template

This prompt is for compliance engineering teams who need to evaluate whether a proposed AI action satisfies a specific regulation before execution. The job-to-be-done is a structured, reviewable gate decision that prevents regulatory exposure while keeping compliant workflows moving. The ideal user is a developer or engineer integrating AI into a product where a compliance officer or legal team has already identified the applicable regulation and provided its text. The required context includes the full regulatory text, a clear description of the proposed AI action, and the data categories involved. Without this context, the model cannot ground its decision in the actual rule, leading to unreliable or hallucinated assessments.

Use this prompt in pre-execution workflows where a blocking decision must be made before an action proceeds. For example, before an AI agent sends a user-generated message, deletes data, or shares information with a third party, this gate can determine if the action complies with GDPR, HIPAA, or an internal policy. The prompt is designed to produce a pass/fail/needs-review status, cite the specific rule references that informed the decision, and provide a blocking rationale when the action is non-compliant. This output can be logged as an audit artifact, used to halt a pipeline, or routed to a human review queue. The prompt is not a replacement for legal counsel and requires human review for any needs-review or borderline decisions.

Do not use this prompt when the regulation is not provided in the context, when the action is too vague to evaluate, or when you need a general legal opinion rather than a specific gate check. It is also inappropriate for real-time, high-throughput decisions where latency constraints prevent a thorough model evaluation. In those cases, a pre-computed policy engine or a deterministic rule-based check is more suitable. For any decision that blocks a user-facing action or involves sensitive data, always route the output through a human approval step and log the full prompt, response, and reviewer decision for auditability.

This template is the core of the compliance gate check workflow. It instructs the model to act as a compliance analyst, evaluate a proposed action against a provided regulation, and produce a structured decision. The prompt is designed to be copied directly into your application, with each square-bracket placeholder replaced by your specific inputs at runtime. The template enforces citation discipline, requires explicit rule references, and blocks non-compliant actions with documented reasoning—preventing the model from issuing approvals based on vague or unsupported claims.

textCopy
You are a regulatory compliance analyst. Your task is to evaluate whether a proposed AI action complies with a specific regulation. You must ground every determination in the provided regulatory text. Do not infer rules that are not explicitly stated. If the regulation is silent on a point, state that explicitly rather than assuming compliance or non-compliance.

## INPUTS

**Proposed Action:**
[ACTION_DESCRIPTION]

**Regulation Text:**
[REGULATION_TEXT]

**Jurisdiction (if applicable):**
[JURISDICTION]

**Risk Level of Action:** [RISK_LEVEL]

## INSTRUCTIONS

1. Identify every section, clause, or requirement in the provided regulation text that applies to the proposed action.
2. For each applicable requirement, determine whether the proposed action satisfies it, violates it, or requires further clarification.
3. If the action violates any requirement, classify the violation severity as BLOCKING or WARNING.
4. If the regulation is ambiguous or silent on a material aspect of the action, flag it as NEEDS_REVIEW rather than assuming compliance.
5. Do not cite regulations, standards, or requirements that are not present in the provided regulation text.

## OUTPUT SCHEMA

Return a valid JSON object with this exact structure:
{
  "decision": "PASS" | "FAIL" | "NEEDS_REVIEW",
  "summary": "One-sentence summary of the determination.",
  "applicable_requirements": [
    {
      "requirement_ref": "Section or clause identifier from the regulation text",
      "requirement_text": "Verbatim quote of the relevant regulatory language",
      "assessment": "COMPLIANT" | "NON-COMPLIANT" | "UNCLEAR",
      "rationale": "Specific explanation of why the action meets, violates, or is unclear against this requirement",
      "severity": "BLOCKING" | "WARNING" | null
    }
  ],
  "blocking_violations": [
    {
      "requirement_ref": "Section or clause identifier",
      "violation_description": "What the action does that violates the requirement",
      "remediation_guidance": "What must change for the action to comply"
    }
  ],
  "needs_review_items": [
    {
      "requirement_ref": "Section or clause identifier",
      "ambiguity_description": "What is unclear and why human review is needed"
    }
  ],
  "confidence": "HIGH" | "MEDIUM" | "LOW"
}

## CONSTRAINTS

- If no regulation text is provided, return decision: "NEEDS_REVIEW" with a note that no regulatory context was supplied.
- If the action description is insufficient to make a determination, return decision: "NEEDS_REVIEW" with specific questions that must be answered.
- For [RISK_LEVEL] of "HIGH", any UNCLEAR assessment must escalate to NEEDS_REVIEW.
- Never fabricate regulation text, clause numbers, or standard references.
- If you cannot determine applicability, say so rather than guessing.

Adapting the template: Replace [ACTION_DESCRIPTION] with a detailed description of what the AI system proposes to do—include the data involved, the processing step, the output, and the downstream effect. Replace [REGULATION_TEXT] with the exact regulatory text, policy document, or standard excerpt that applies. This should be retrieved from a source-of-truth system, not pasted ad hoc. [JURISDICTION] helps the model contextualize the regulation. [RISK_LEVEL] controls the strictness of the gate: set to HIGH for actions involving personal data, financial commitments, safety systems, or irreversible operations. For lower-risk actions, the model will still flag violations but may allow UNCLEAR items to pass with warnings rather than escalating to NEEDS_REVIEW. After copying the template, wire the output JSON into your application's decision router: PASS proceeds, FAIL blocks with the blocking_violations array surfaced to the user, and NEEDS_REVIEW queues the action for human evaluation with the needs_review_items context attached.

Integrating this prompt into a production system requires treating it as a deterministic gate, not an advisory note. The prompt expects a specific regulation text and a proposed action description as input, and it must return a structured JSON decision. The application layer should never execute the proposed action until the gate returns a pass status. A needs_review or fail status must block execution and route the item to a human review queue. The prompt is designed for a single synchronous call before any high-risk action, such as a data export, a financial transaction, or a user-facing disclosure. Do not batch multiple actions into one prompt call; each action deserves its own isolated gate check to maintain a clean audit trail.

The implementation harness must enforce a strict contract around the model's output. Before the application reads the status field, it must validate the JSON structure against a schema that requires status (enum: pass, fail, needs_review), rule_references (array of strings), rationale (string), and blocking_conditions (array of strings). If the model returns malformed JSON, the harness should retry once with a repair prompt that includes the raw output and the schema. If the retry also fails, the system must escalate to a human reviewer with the original inputs and the failed outputs. For high-risk domains like healthcare or finance, log every gate check—including the prompt version, model, input hash, raw output, validation result, and final decision—to an append-only audit store. This log becomes the evidence package for compliance reviews.

Model choice matters. Use a model with strong instruction-following and low hallucination rates on legal and regulatory text. GPT-4o and Claude 3.5 Sonnet are suitable defaults, but you should run eval checks on your specific regulations before trusting any model. The eval suite must include test cases with known pass, fail, and edge-case actions, and it must flag any instance where the model hallucinates a regulation that wasn't in the provided context. If your regulation text exceeds the model's context window, preprocess it by chunking and retrieving only the most relevant sections using a RAG pipeline. The prompt's [REGULATION_TEXT] placeholder should receive those retrieved sections, not the entire legal corpus. Finally, never allow the model's output to directly trigger the regulated action. A human must always confirm needs_review decisions, and even pass decisions should be sampled for human audit on a regular cadence.