Firm Refusal Prompt Template for Enterprise Compliance

This prompt is for compliance engineers and product counsel in regulated enterprise environments who need an AI system to produce unambiguous, audit-ready refusals. The job-to-be-done is generating a refusal that cites a specific internal policy, leaves no room for negotiation, and can be logged as evidence of compliance. The ideal user is someone who already has a defined policy framework and needs the model to enforce it with legal and regulatory precision, not to improvise a safety stance.

Use this template when the request falls into a clearly disallowed category under a known policy, such as providing financial advice without a license, generating medical interpretations, or responding to legally barred topics. The prompt requires a [POLICY_REFERENCE] that maps to a real, traceable governance document. Do not use this prompt for ambiguous edge cases, user frustration de-escalation, or scenarios where a softer tone might preserve the relationship. If the refusal needs to offer an alternative path, pair this with a redirection component rather than embedding it here, as the firm refusal's value is its finality and clarity.

Before implementing, confirm that your legal and compliance stakeholders have reviewed the refusal language for regulatory precision. The output should be treated as a controlled compliance artifact: version it, log every instance, and never let the model rephrase the policy citation itself. If you need the system to detect whether a request is disallowed before applying this prompt, route through a classification step first. Avoid using this template for consumer-facing products where brand voice and user trust require a more empathetic or educational refusal style.

This template produces unambiguous refusals designed for compliance engineers in regulated industries. It prioritizes policy citation, regulatory language precision, and audit-trail readiness over user sentiment or redirection. The prompt is structured to accept a specific policy reference, the disallowed request, and the applicable regulatory framework as inputs, ensuring every refusal can be traced back to a documented rule. Use this template when the cost of ambiguity—legal liability, regulatory penalty, or audit failure—exceeds the cost of a terse user experience.

textCopy
You are a compliance enforcement assistant for a regulated enterprise environment. Your sole responsibility is to evaluate user requests against defined policies and issue firm, unambiguous refusals when a request violates policy. You do not offer alternatives, explain policy rationale beyond the citation, or engage in negotiation.

## POLICY REFERENCE
[POLICY_DOCUMENT]

## REGULATORY FRAMEWORK
[REGULATORY_FRAMEWORK]

## REQUEST
[USER_REQUEST]

## INSTRUCTIONS
1. Determine whether the request violates any rule in the POLICY REFERENCE above.
2. If the request is compliant, respond only with: "REQUEST_COMPLIANT"
3. If the request is non-compliant, generate a refusal with exactly this structure:
   - REFUSAL_STATEMENT: One sentence stating the request cannot be fulfilled.
   - POLICY_CITATION: The exact policy section, rule number, and quoted text that prohibits the request.
   - REGULATORY_BASIS: The specific regulation, statute, or framework provision that requires this policy.
   - NO_ALTERNATIVES: A statement that no workaround or alternative will be provided for this request.
4. Do not add explanation, apology, softening language, or suggestions.
5. Do not acknowledge the user's intent, goals, or circumstances.
6. If the request is ambiguous, treat it as non-compliant and refuse with the most applicable policy citation.

## OUTPUT SCHEMA
{
  "compliant": boolean,
  "refusal": {
    "refusal_statement": "string",
    "policy_citation": {
      "section": "string",
      "rule_number": "string",
      "quoted_text": "string"
    },
    "regulatory_basis": "string",
    "no_alternatives": "string"
  }
}

## CONSTRAINTS
- Never use the words "sorry," "unfortunately," "we understand," or any apologetic language.
- Never suggest the user rephrase, try a different approach, or contact support for alternatives.
- Never explain why the policy exists or what harm it prevents.
- If the policy reference is incomplete or missing, refuse with POLICY_REFERENCE_MISSING.

To adapt this template, replace the square-bracket placeholders with your specific inputs. [POLICY_DOCUMENT] should contain the full text of the relevant policy sections, not just a policy name—the model needs the actual rules to cite accurately. [REGULATORY_FRAMEWORK] should name the governing regulation (e.g., 'HIPAA 45 CFR §164.502', 'SEC Rule 17a-4', 'GDPR Article 17') so the refusal carries audit weight. [USER_REQUEST] is the raw input to evaluate. Before deploying, test this prompt against a golden dataset of known-violation and known-compliant requests to verify that policy citations are exact and that no softening language leaks into the refusal. In production, log every refusal output alongside the policy version and model version for audit trail completeness.

The Firm Refusal Prompt Template is designed for high-stakes enterprise environments where an ambiguous or overly polite refusal creates compliance risk. In production, this prompt should not be used as a standalone chat completion. It must be embedded in an application harness that validates the output against a strict refusal contract before the response reaches the user. The harness is responsible for ensuring the refusal language is unambiguous, cites the correct policy reference, and contains no softening phrases that could be interpreted as negotiable. Treat this prompt as a compliance control, not a conversational feature.

Integration pattern: Place this prompt as a guard step before your main assistant or agent. When an upstream safety classifier or policy engine flags a user request as disallowed, route the request to this refusal prompt instead of the primary model. The harness should inject the required variables—[DISALLOWED_REQUEST_SUMMARY], [APPLICABLE_POLICY_REFERENCE], and [REGULATORY_CONTEXT]—from your policy engine, not from raw user input. After the model returns a refusal, run a post-generation validator that checks for: (1) presence of the exact policy reference string, (2) absence of hedge words such as 'unfortunately,' 'I wish I could,' or 'maybe,' (3) no alternative suggestions that could be interpreted as workarounds, and (4) a definitive closing statement with no open-ended offers. If the validator fails, retry once with a stricter temperature setting and explicit correction instructions. If the retry also fails, escalate to a human review queue with the full context attached.

Model choice and configuration: Use a deterministic or near-deterministic model configuration for refusal generation. Set temperature to 0 or a very low value (0.1 maximum). Avoid models with strong instruction-following tendencies that might override the firmness directive in favor of helpfulness. For regulated industries, prefer models that support structured output modes so you can enforce a refusal schema with fields like refusal_statement, policy_citation, and finality_marker. Log every refusal generation attempt—including the input variables, the raw model output, validator results, and any retry or escalation actions—to your compliance audit system. These logs serve as evidence that your AI system consistently enforced policy boundaries. Never cache or reuse refusal outputs across different requests, as each refusal must be traceable to a specific policy decision and input context.

Next steps: After integrating the harness, build a regression test suite using known disallowed request patterns and verify that the validator catches common failure modes such as softened language, missing policy citations, or implied negotiability. Run these tests as part of your prompt change management process before any model or prompt update reaches production. If your system operates in multiple jurisdictions, maintain separate policy reference mappings and test each locale's refusal path independently.