Compliance Boundary Violation Escalation Prompt

This prompt is designed for compliance officers and AI platform architects who need to embed regulatory rules directly into an AI system's instructions. Its job is to detect when a user request, a generated output, or a planned action violates a defined compliance boundary, produce a structured violation report with specific regulation references, assign a severity rating, and define the required escalation path. Use this prompt when your AI assistant operates in a regulated domain (finance, healthcare, legal, data privacy) and must never autonomously cross a compliance line. It belongs in the system prompt layer as a persistent policy instruction, not as a one-off user prompt. The output is not a conversational reply; it is a machine-readable escalation payload that your application harness can route to a human review queue, block an action, or log for audit.

Deploy this prompt when you have a defined set of compliance rules that can be enumerated in the [CONSTRAINTS] block. The prompt works best when your application harness already has a human review queue, an action-blocking mechanism, and an audit logging system. It expects the model to act as a classifier and structured reporter, not a conversational agent. The ideal user is someone who can maintain the rule definitions, review escalation payloads, and tune severity thresholds over time. Do not use this prompt for general content moderation, toxicity detection, or brand-safety filtering—those require different policy structures and output schemas. Do not use it when compliance rules are vague, unwritten, or require subjective legal interpretation that a model cannot reliably perform.

Before implementing, ensure you have mapped your regulatory obligations into discrete, testable rules. Each rule should have a unique identifier, a clear description, a severity level, and a defined escalation path. The prompt will only be as effective as the rules you provide. After deployment, monitor the escalation rate, false-positive violations, and human reviewer feedback to tune the [CONSTRAINTS] and [RISK_LEVEL] parameters. Avoid using this prompt as a substitute for legal review or as the sole defense in an audit. It is a detection and routing layer, not a compliance certification.

The following template is designed to be placed in the system prompt or a dedicated policy instruction block. It instructs the model to act as a compliance boundary monitor. Its job is to analyze user requests and assistant-generated content against a defined regulatory framework, flag violations, and produce a structured escalation record. This is not a conversational prompt; it is a policy enforcement layer that should run before any high-risk output is returned to the user or executed via a tool.

codeCopy
You are a Compliance Boundary Monitor. Your sole responsibility is to analyze the following [INPUT] against the regulatory framework defined in [REGULATORY_FRAMEWORK]. You do not fulfill the user's request. You only assess it for compliance violations.

# REGULATORY FRAMEWORK
[REGULATORY_FRAMEWORK]

# ASSESSMENT INSTRUCTIONS
1. Identify any part of the [INPUT] that violates, attempts to circumvent, or requests an action prohibited by the [REGULATORY_FRAMEWORK].
2. For each violation, cite the specific regulation, clause, or policy from [REGULATORY_FRAMEWORK] that is breached.
3. Assign a severity rating of LOW, MEDIUM, HIGH, or CRITICAL based on the potential for harm, regulatory penalty, or customer impact as defined in [RISK_LEVEL].
4. If no violation is found, output a clean bill of health. Do not invent violations.

# RISK LEVEL DEFINITIONS
[RISK_LEVEL]

# OUTPUT SCHEMA
Respond exclusively in valid JSON conforming to the following schema. Do not include any text outside the JSON object.
{
  "violations": [
    {
      "violation_id": "string",
      "regulation_cited": "string",
      "severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
      "offending_excerpt": "string",
      "explanation": "string",
      "recommended_escalation": "BLOCK_AND_ESCALATE" | "FLAG_FOR_REVIEW" | "LOG_ONLY"
    }
  ],
  "clean_bill_of_health": false
}

# CONSTRAINTS
[CONSTRAINTS]

To adapt this template, replace the placeholders with your specific content. [REGULATORY_FRAMEWORK] should contain the exact text of your policies, such as GDPR articles, SOC 2 controls, or internal data-handling rules. [RISK_LEVEL] must define clear, operational thresholds for each severity tier—for example, a CRITICAL violation might be one that involves unprotected PII or a direct request to ignore a legal requirement. [CONSTRAINTS] is where you add domain-specific rules, such as 'Never flag a request for a public earnings report as a violation' or 'Ignore requests for legal advice if the user is from the legal department.' After adapting, run this prompt against a golden dataset of known violations and clean inputs to calibrate severity and ensure the model does not over-flag or under-flag. In high-stakes deployments, the output of this prompt should be logged immutably and, for HIGH or CRITICAL violations, trigger an immediate halt of the primary workflow and a notification to a human review queue.

This prompt is designed to sit inside a compliance review pipeline, not as a standalone chat interface. The typical integration pattern is: an upstream system (document processor, chat handler, or monitoring service) detects a potential compliance event and sends the relevant content to this prompt for structured violation analysis. The prompt's output—a JSON object with violation flags, regulation references, severity ratings, and escalation paths—must be parsed by application code that enforces the escalation decision. Do not treat the model's output as the final action; the application layer owns the escalation execution, audit logging, and human notification.

The implementation harness should include a validation layer that checks the model's output against the expected schema before any escalation action fires. Required fields to validate include: violation_detected (boolean), regulation_references (array of strings, each matching a known regulation ID from your compliance registry), severity_rating (enum: LOW, MEDIUM, HIGH, CRITICAL), and escalation_path (enum: LOG_ONLY, REVIEW_QUEUE, IMMEDIATE_ESCALATION, LEGAL_HOLD). If the model returns a regulation reference not in your approved registry, flag it for human review rather than silently accepting it. If violation_detected is true but escalation_path is LOG_ONLY, log a warning—this pattern often indicates model confusion. Implement a retry strategy with at most two retries on schema validation failure, using a repair prompt that includes the validation errors. After two failed repair attempts, escalate the raw output to a compliance officer with a note that automated analysis was inconclusive.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that may hallucinate regulation references or misclassify severity. Set temperature=0 to maximize consistency across repeated analyses of the same content. If your compliance domain requires data residency or air-gapped processing, deploy an open-weight model (Llama 3.1 70B or similar) with the same prompt structure, but run additional calibration tests against your regulation registry to confirm the model recognizes your specific regulatory framework. Log everything: the input content hash, the full prompt sent, the raw model response, the validated output, any validation failures, retry attempts, and the final escalation action taken. This audit trail is essential for regulatory review and for debugging false positives or missed violations over time.

Human review integration is non-negotiable for HIGH and CRITICAL severity findings. The application should route these to a review queue with the original content, the model's structured analysis, and a pre-formatted decision interface (confirm escalation, downgrade, dismiss with reason). For MEDIUM severity, batch into a daily review digest. For LOW severity with LOG_ONLY escalation, auto-log without interrupting reviewers, but run a weekly spot-check sample to catch systematic under-escalation. What to avoid: do not expose the raw model output directly to end users or external auditors without the validation layer applied. Do not use this prompt to make autonomous blocking decisions (e.g., automatically freezing accounts or rejecting transactions) without human confirmation for anything above LOW severity. The prompt is a detection and triage tool, not an enforcement engine.