Refusal for Regulated Content Prompt

This prompt is designed for compliance and safety engineering teams who need to teach a model to refuse requests that would create regulatory liability in finance, healthcare, legal, or other controlled industries. The core job-to-be-done is generating a set of high-quality, domain-specific few-shot examples that clearly demonstrate the boundary between a legitimate request and one that requires refusal. The ideal user is a compliance officer or product safety lead who understands the specific regulations (e.g., HIPAA, SEC rules, attorney-client privilege boundaries) but needs help translating those abstract policies into concrete model behavior. You should use this prompt when you are building or fine-tuning a system that operates in a regulated vertical and you have a clear, documented policy that defines what constitutes a disallowed request.

Do not use this prompt if you are trying to define your safety policy from scratch; it assumes you already have a policy and need to operationalize it. It is also not a substitute for a full red-teaming exercise or a legal review of your model's outputs. The prompt works by taking a specific regulatory category and a set of constraints as input, and it outputs a structured set of examples that pair a user request with the correct refusal response. The refusal responses are designed to be firm, cite the relevant policy, and avoid giving partial information that could be misconstrued as advice. A key constraint is that the generated examples must not over-refuse—blocking a request for publicly available information because it sounds financial, for instance, is a failure mode this prompt explicitly helps you avoid by requiring you to define the boundary.

Before using this prompt, you must have a clear, written definition of the regulated content category and at least three concrete examples of requests that fall on either side of the refusal boundary. The prompt's effectiveness depends entirely on the precision of your input constraints. After generating the examples, you must run them through an evaluation harness that tests for both dangerous compliance (the model complying with a request it should refuse) and over-refusal (the model blocking a legitimate request). In regulated industries, human review of the generated examples by a qualified compliance professional is mandatory before they are deployed into any production system. The output of this prompt is a component of a larger safety system, not the entire system itself.

The following template is designed to be dropped into a system prompt or a few-shot instruction block. It uses square-bracket placeholders for all variable components—domain, risk level, output schema, and example sets—so you can adapt it across financial, medical, legal, or other regulated contexts without rewriting the core refusal logic. The template assumes you have already curated a set of compliant and non-compliant request-response pairs that demonstrate the boundary you want the model to learn.

textCopy
You are a compliance-aware assistant operating in the [DOMAIN] industry under [REGULATORY_FRAMEWORK] regulations. Your primary responsibility is to provide helpful, accurate information while refusing requests that would create regulatory liability, violate professional standards, or expose the organization to legal risk.

## Refusal Policy
When you encounter a request that falls into any of the following categories, you must refuse clearly and explain why without providing the prohibited content:
- [PROHIBITED_CATEGORY_1]
- [PROHIBITED_CATEGORY_2]
- [PROHIBITED_CATEGORY_3]

## Refusal Style
- Be firm but respectful. Do not apologize excessively.
- Cite the specific policy or regulation that applies when possible.
- Offer a safe, constructive alternative if one exists.
- Never repeat or paraphrase the dangerous request in your refusal.

## Examples of Correct Refusal
[REFUSAL_EXAMPLE_1]
[REFUSAL_EXAMPLE_2]
[REFUSAL_EXAMPLE_3]

## Examples of Incorrect Compliance (DO NOT DO THIS)
[NEGATIVE_EXAMPLE_1]
[NEGATIVE_EXAMPLE_2]

## Examples of Legitimate Requests You SHOULD Answer
[LEGITIMATE_EXAMPLE_1]
[LEGITIMATE_EXAMPLE_2]

## Output Format
Respond using the following JSON structure:
{
  "decision": "REFUSE" | "COMPLY" | "ESCALATE",
  "reasoning": "Brief explanation of the decision",
  "policy_citation": "Relevant policy or regulation reference",
  "response_to_user": "The text shown to the end user",
  "safe_alternative": "Optional constructive alternative or null"
}

## Current Request
[USER_INPUT]

To adapt this template, replace each placeholder with domain-specific content. For [REFUSAL_EXAMPLE_*], include full input-output pairs showing the exact refusal language you want. For [NEGATIVE_EXAMPLE_*], show what the model must avoid—these are often more important than positive examples for preventing dangerous compliance. The [LEGITIMATE_EXAMPLE_*] entries are critical for preventing over-refusal; without them, the model may block requests that are perfectly acceptable in your domain. Before deploying, run this prompt against a golden test set of at least 50 requests spanning clear refusals, clear approvals, and boundary cases. Measure both false-positive and false-negative rates, and adjust the example mix until both are below your risk threshold.

This prompt is not a standalone safety filter. It is a few-shot example generator designed to produce domain-specific refusal demonstrations for regulated industries. The output—a set of input-output pairs showing correct refusals—must be reviewed by compliance before being injected into a system prompt or fine-tuning dataset. The implementation harness therefore has two distinct phases: a generation phase where the prompt runs in a controlled authoring environment, and a deployment phase where the reviewed examples are wired into the runtime safety layer of your application.

Generation-phase wiring. Run this prompt in a batch or interactive authoring tool, not in the user-facing request path. Supply the following inputs: [REGULATED_DOMAIN] (e.g., 'SEC-regulated financial advice', 'HIPAA-covered clinical recommendations'), [REGULATORY_CATEGORIES] (specific prohibited request types), [REFUSAL_STYLE] (firm, educational, redirecting), and [COMPLIANCE_POLICY_EXCERPTS] (verbatim policy text the model must ground refusals in). The prompt returns structured refusal examples with input, refusal_response, policy_citation, and boundary_rationale fields. Validate each output against a compliance checklist: does the refusal cite the correct regulation? Does it avoid accidental compliance through hedging language? Does it maintain the specified tone? Flag any example where the model generated a compliant response instead of a refusal—this indicates the prompt's safety teaching failed and requires template adjustment.

Deployment-phase wiring. Once compliance approves the generated examples, inject them into your runtime system prompt as a ## Refusal Examples block. Implement a pre-response safety classifier that runs before the main model: if the classifier detects a regulated request category, route to a dedicated refusal model or a system prompt variant containing these examples. Log every refusal event with the request text, the matched example ID, the policy citation, and a unique trace ID. For high-severity categories (e.g., unqualified legal advice, medication dosing), add a human review queue where a compliance officer can audit refusal decisions within 24 hours. Never rely solely on the model's refusal without this audit trail—regulatory liability requires demonstrable oversight.

Model choice and fallback. Use a model with strong instruction-following and low hallucination rates for the generation phase (GPT-4, Claude 3.5 Sonnet, or equivalent). For the runtime refusal layer, prefer the same model family to minimize behavior drift between the examples and production. Implement a refusal consistency eval that runs weekly: send a fixed set of 50 paraphrased regulated requests through the system and verify that the refusal rate stays above 99% with zero false compliances. If the refusal rate drops, re-run the generation prompt with updated policy excerpts and refresh the example set. Avoid using smaller or quantized models for the refusal path—their degraded instruction-following creates dangerous compliance gaps that are hard to detect without systematic testing.