Neutral Refusal Prompt for High-Regulation Industries

This playbook is for product teams in legal, financial, and healthcare domains who need an AI system to refuse disallowed requests without introducing liability. The prompt generates flat-affect, procedurally correct refusals that avoid implying endorsement, advice, or interpretation. Use this when a refusal must be audit-ready, tone-neutral, and incapable of being misread as a policy loophole. The core job-to-be-done is not to decide whether to refuse—that classification must happen upstream—but to produce a refusal text that withstands regulatory scrutiny and does not create new obligations for your organization.

Do not use this prompt for consumer apps where user trust depends on warmth, or for educational contexts where a refusal should teach. It is explicitly designed to be cold and procedural. If your product requires empathetic de-escalation, educational redirection, or brand-voice preservation, select a different refusal style from the Refusal Style and Tone Design group. This prompt also assumes the upstream classification and policy decision have already been made; it does not decide whether to refuse, only how to phrase the refusal. Pair it with a classification router from the Classification Routing and Triage Prompts pillar if you need the full decision pipeline.

Before deploying, validate that your upstream classifier correctly identifies the [POLICY_VIOLATION] and [RISK_LEVEL] inputs this prompt requires. The most common production failure is feeding this prompt a misclassified request—producing a neutral refusal for something that should have been answered, or worse, a neutral answer for something that should have been refused. Implement a human review step for any refusal where [RISK_LEVEL] is high or where the classifier confidence falls below your threshold. Log every refusal with the input, output, policy reference, and reviewer identity for audit readiness.

This template is designed to be pasted directly into your system prompt or a dedicated refusal-generation step. It instructs the model to produce a refusal that is neutral in tone, cites the applicable policy, and avoids any language that could be interpreted as legal, financial, or medical advice. The square-bracket placeholders must be replaced with your specific application values before deployment. For high-risk domains, the output of this prompt should always be logged and available for human audit.

textCopy
You are a compliance-aware assistant operating in a highly regulated industry. Your primary directive is to refuse requests that fall outside your permitted scope without implying endorsement, interpretation, or advice.

When you encounter a request that must be refused, generate a refusal using the following structure:

1.  **Neutral Acknowledgment:** State that you have received the request without expressing judgment on its validity.
2.  **Policy Citation:** Clearly state the specific policy or constraint that prevents you from fulfilling the request. Reference [POLICY_NAME] from [POLICY_SOURCE].
3.  **Procedural Statement:** Explain what you can do instead, strictly within your defined procedures. For example, "I can provide the publicly available document on this topic" or "I can direct you to the appropriate form."
4.  **Closing:** End with a neutral closing statement that does not invite further discussion on the disallowed topic.

**Input:** [USER_INPUT]
**Risk Level:** [RISK_LEVEL]
**Applicable Policy:** [POLICY_NAME]
**Permitted Alternatives:** [PERMITTED_ALTERNATIVES]

**Refusal Output:**

To adapt this template, replace the placeholders with your application's runtime values. [USER_INPUT] is the original request. [RISK_LEVEL] can be a tag like 'HIGH', 'MEDIUM', or 'LOW' to adjust the firmness of the procedural statement. [POLICY_NAME] and [POLICY_SOURCE] should map to your internal governance documents (e.g., 'Data Handling Policy, Section 4.2'). [PERMITTED_ALTERNATIVES] is a critical field; provide a concrete, safe action the model can offer, such as 'Provide a link to the public help center' or 'Route to a licensed human agent'. Never leave this field empty, as a refusal without a path forward increases user frustration and escalation rates. Before production, run this prompt through a regression test suite that includes edge cases like ambiguous phrasing and multi-turn probing to ensure the refusal remains neutral and procedurally correct.

This prompt is designed to be a final safety net, not the first line of defense. In a production application, you should implement a pre-generation classifier that catches clearly disallowed requests before they reach the LLM. This prompt handles the ambiguous cases where a request touches a regulated domain but isn't an obvious violation. Wire it into your application as a synchronous call within a broader safety pipeline, placing it after your upstream classifiers and before any response is returned to the user. The prompt expects a [USER_REQUEST] and a [REGULATORY_DOMAIN] (e.g., 'financial advice', 'medical diagnosis', 'legal counsel') as inputs. It should be called with temperature=0 to maximize deterministic, procedurally correct refusal language.

Validation and Retry Logic: Parse the model's output against a strict schema. At minimum, validate that the response contains a non-empty refusal_text field and that the tone_neutrality boolean is true. If the output fails schema validation, retry once with the same prompt and an added [CONSTRAINT] that says 'Your previous response failed schema validation. You must output valid JSON with the exact fields specified.' If the second attempt fails, log the raw output and escalate to a human review queue. Do not retry more than once, as a persistent formatting failure may indicate a prompt injection attempt or a model edge case that requires investigation.

Human Review and Audit Trail: For high-regulation industries, every refusal generated by this prompt should be logged immutably with the original user request, the regulatory domain, the model's full JSON response, and a unique interaction ID. Implement a sampled review process where a compliance analyst reviews a percentage of refusals (start with 100% and reduce based on observed accuracy). If the regulatory_language_compliance score in the output is below a configurable threshold (e.g., 0.9), route the interaction for mandatory human review before the refusal is sent to the user. Never allow the system to auto-respond with a refusal that has a low compliance score. The audit log is your primary defense in any regulatory inquiry about the system's behavior.

Model Selection and Guardrails: Use a model with strong instruction-following and JSON mode capabilities. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate choices. Always enable structured output mode if the model provider supports it, rather than relying on a post-hoc JSON parser. Do not use this prompt with a model that has been fine-tuned to be overly helpful, as that can undermine refusal consistency. Implement a circuit breaker that disables the AI response path entirely and forces a static, pre-approved refusal message if the system detects a spike in low-confidence outputs or schema validation failures, indicating a possible model degradation or adversarial campaign.