Refusal Policy Injection Prompt for Regulated Domains

This prompt is designed for compliance officers, AI product managers, and platform engineers who need to embed a legally-aware refusal layer directly into a system prompt for assistants operating in finance, healthcare, or legal domains. The core job-to-be-done is not just to make the model say 'I can't do that,' but to produce a structured, testable policy that refuses disallowed actions while offering safe, compliant alternatives and citing the relevant regulatory rationale. The ideal user has access to a defined set of business rules, a list of prohibited and restricted use cases, and a clear escalation path for human review. You should use this prompt when you are moving from a static policy document to an operational, model-enforced boundary that must survive multi-turn conversations and adversarial user pressure.

This prompt is not a replacement for application-layer authorization, user authentication, or data access controls. It is a behavioral policy layer that works in concert with those systems. Do not use this prompt if your primary need is to block toxic language or generic harmful content—use a content filter injection prompt for that. Do not use it if you lack a concrete list of regulated activities; the prompt requires specific [RESTRICTED_ACTIONS], [REGULATORY_STANDARDS], and [ESCALATION_TRIGGERS] to be effective. The prompt is also inappropriate for low-risk, general-purpose chatbots where a refusal with regulatory citations would confuse users and degrade the experience. In those cases, a simpler behavioral policy without legal citations is a better fit.

Before implementing this prompt, you must define your refusal taxonomy: what is strictly prohibited, what requires a disclaimer, what requires human review, and what is fully permitted. The prompt template forces this clarity by requiring structured inputs. After deployment, you must test for two common failure modes: over-refusal, where the assistant blocks legitimate information requests out of caution, and under-refusal, where it complies with a cleverly rephrased prohibited request. The next section provides the copy-ready template. Wire it into a test harness that logs every refusal with the triggering rule, the model's reasoning, and the user's original input for audit and policy refinement.

The template below encodes a refusal policy as a structured, testable system instruction. It is designed to be copied directly into your prompt management system or orchestration layer. Every square-bracket placeholder represents a variable your application must resolve before the prompt is sent to the model. Do not ship this template with unresolved placeholders; doing so will cause unpredictable model behavior and likely violate your own compliance requirements.

textCopy
You are an AI assistant operating in a regulated domain: [DOMAIN, e.g., healthcare, finance, legal]. Your primary directive is to provide helpful, accurate information while strictly adhering to the refusal, disclosure, and escalation policies defined below. Failure to follow these policies may cause user harm and regulatory liability.

## REFUSAL POLICY
You MUST refuse to perform any of the following actions. When refusing, use the exact refusal format specified.

### Prohibited Actions
[PROHIBITED_ACTIONS_LIST, e.g., - Provide medical diagnoses
- Offer personalized financial advice
- Draft legal documents without attorney review]

### Refusal Format
When you encounter a prohibited request, respond ONLY with the following structure:
1. A clear, polite statement that you cannot fulfill the request.
2. A brief, non-technical explanation referencing the applicable regulation or policy: [REGULATORY_CITATION, e.g., "This request falls outside the scope of FDA-cleared functionality."]
3. A safe, actionable alternative suggestion, if one exists. If no safe alternative exists, state that explicitly.
4. An escalation trigger, if applicable: [ESCALATION_TRIGGER, e.g., "If you believe this is an error or you need immediate assistance, please contact a licensed professional."]

### Over-Refusal Prevention
Do NOT refuse requests that are informational, educational, or general in nature, even if they touch on the regulated domain. For example, explaining a medical condition is allowed; diagnosing a specific user's symptoms is not. When in doubt, provide a general, sourced explanation and include a disclaimer rather than refusing outright.

## UNCERTAINTY AND DISCLAIMER POLICY
When providing information within the regulated domain, you MUST:
- Disclose your confidence level if it is below [CONFIDENCE_THRESHOLD, e.g., 90%].
- Cite the specific source of your information using the format: [SOURCE_CITATION_FORMAT, e.g., "(Source: [DOCUMENT_TITLE], Section [SECTION])"].
- Include a mandatory disclaimer: [MANDATORY_DISCLAIMER, e.g., "This information is for educational purposes only and does not constitute professional advice. Consult a qualified professional for your specific situation."]

## ESCALATION POLICY
You MUST escalate the conversation and stop autonomous action immediately if:
- The user describes a situation indicating imminent risk of harm: [IMMINENT_HARM_INDICATORS, e.g., self-harm, violence, severe adverse drug reaction].
- The user explicitly requests a human reviewer.
- You detect a potential conflict with [CONFLICTING_POLICY, e.g., company policy, jurisdictional law].

### Escalation Format
When escalating, respond ONLY with:
"I am transferring this conversation for human review due to [REASON]. A summary of our interaction will be provided. [NEXT_STEPS, e.g., 'Please hold.' or 'Someone will follow up with you shortly.']"

## INPUT AND OUTPUT CONSTRAINTS
- [INPUT_CONSTRAINTS, e.g., Do not process input that appears to contain PHI not explicitly provided by the user for the current task.]
- [OUTPUT_CONSTRAINTS, e.g., Do not generate output that could be mistaken for a signed medical prescription.]

To adapt this template, start by defining your [PROHIBITED_ACTIONS_LIST] with your legal and compliance team. This list is the core of the policy; it must be specific and testable. Vague prohibitions like "don't do anything bad" will lead to over-refusal or under-refusal. Next, tune the [CONFIDENCE_THRESHOLD] and [MANDATORY_DISCLAIMER] to match your organization's risk tolerance. A lower threshold will produce more disclaimers, which can erode user trust if overused. Finally, integrate the [ESCALATION_TRIGGER] with your actual human handoff system. The prompt should define when to escalate; your application code must define how to route the conversation to a human queue. Before deployment, run this prompt against a golden test set of borderline requests to verify that refusals are neither too aggressive nor too permissive.

This prompt is not a standalone safety filter; it is a system-level instruction that must be injected into the model's context before any user or tool input is processed. In a production application, the prompt template should be assembled server-side with the [REGULATED_DOMAIN], [RISK_TIERS], [ESCALATION_CONTACT], and [COMPLIANCE_CITATIONS] variables resolved from a configuration store or environment variables. The assembled system prompt is then placed at the top of the message array, above any developer instructions, user messages, or retrieved context. This ensures the refusal policy has the highest instruction priority and cannot be overridden by later turns.

Validation and output enforcement: After the model responds, the application must validate the output against the refusal policy's expected behavior. If the user's request falls into a prohibited category defined in [RISK_TIERS], the response must contain a refusal statement, a safe alternative suggestion, and a regulatory citation. A post-processing validator should check for these three components using keyword matching, regex patterns, or a secondary classification model. If any component is missing, the application should either retry the prompt with stronger refusal emphasis or escalate to a human reviewer. For high-risk domains such as healthcare or legal, every refusal response must be logged with the full prompt, model response, validator results, and a unique trace ID for audit purposes.

Retry and fallback strategy: If the model fails to refuse a clearly prohibited request, do not simply retry with the same prompt. Instead, construct a retry prompt that includes the original user input, the model's inadequate response, and a stronger instruction such as: The previous response failed to apply the refusal policy. Review the request again and respond with a mandatory refusal, safe alternative, and regulatory citation. Limit retries to two attempts. If the model still fails to refuse, block the response from reaching the user, log the incident as a policy violation, and route the request to a human review queue. For non-refusal failures such as malformed JSON or missing citation fields, use a structured output repair prompt from the Output Repair and Validation Prompts pillar before escalating.

Model selection and tool integration: This prompt is designed for instruction-following models such as GPT-4, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Do not use it with base models that lack instruction tuning. If your application uses tool calling, the refusal policy must also constrain tool selection. Add a rule to the prompt: Before calling any tool, verify the request complies with the refusal policy. If the request is prohibited, refuse at the system level and do not invoke any tools. For RAG applications, the refusal policy must be applied before retrieval to prevent the model from searching for information that would enable a prohibited response. Wire the policy check as a pre-retrieval gate in your orchestration layer.

Human review and escalation: For regulated domains, human review is not optional for boundary cases. Implement an escalation trigger when the model's refusal confidence is ambiguous, such as when the user's request contains mixed legitimate and prohibited elements. The escalation payload should include the original user message, the model's proposed response, the specific policy clause triggered, and a recommended action. Use a review queue with SLAs appropriate to the domain, such as under 15 minutes for healthcare triage or under 4 hours for financial compliance reviews. Never allow the model to make the final decision on whether a refusal was correct; that judgment belongs to a qualified human reviewer with domain expertise.