Refusal Tone Cultural Sensitivity Adjustment Prompt

This prompt is for product teams and localization engineers who need to adapt an AI system's refusal tone for different international markets. The core job-to-be-done is taking a base refusal message—crafted for one locale—and adjusting its directness, formality, politeness markers, and redirection style to match the communication norms of a target culture, without softening or altering the underlying safety policy boundary. The ideal user is someone managing a production AI feature that has already defined its refusal policies and base tone, and now faces the operational challenge of launching in multiple regions where a one-size-fits-all refusal damages user trust, increases escalation rates, or feels culturally alien.

Use this prompt when you have a stable, policy-compliant refusal in a source language and need to produce a culturally appropriate variant for a specific target market. Required inputs include the original refusal text, the target locale (using a specific locale code like ja-JP or de-DE), and a clear description of the cultural communication norms to apply—such as preferences for indirect versus direct refusal, appropriate honorific levels, or expected redirection patterns. Do not use this prompt to define safety policies from scratch, to decide whether a request should be refused, or to generate refusals for high-stakes regulated domains without human review. It is a tone adaptation tool, not a policy engine.

The prompt is most effective when paired with a structured evaluation step. After generating an adapted refusal, you should validate it against three criteria: policy preservation (the refusal boundary is unchanged), cultural appropriateness (a native speaker or cultural consultant confirms the tone fits the locale), and user clarity (the user understands they are being refused and what alternative paths exist). For high-risk markets, always route the output through human review before deployment. Avoid using this prompt to generate refusals for cultures you cannot validate; guessing at cultural norms produces outputs that are worse than a neutral default.

This template is designed to be wired into a localization or internationalization pipeline. It takes a base refusal message, the target locale, and the original policy constraint, then rewrites the refusal to match cultural norms for directness, formality, and redirection style. The prompt does not change what is refused—only how the refusal is delivered. Use this when you have a single product surface serving multiple markets and you need refusal experiences that feel native rather than translated.

codeCopy
SYSTEM:
You are a cultural adaptation layer for an AI safety system. Your job is to rewrite a refusal message so that it matches the communication norms of [TARGET_LOCALE] while preserving the exact policy boundary and refusal decision. You must not soften, remove, or negotiate the refusal itself. You are only adjusting tone, formality, directness, and redirection style.

INPUT:
- Base refusal message: [BASE_REFUSAL]
- Policy that was violated: [POLICY_NAME]
- Target locale (ISO 3166-1 alpha-2 / ISO 639-1): [TARGET_LOCALE]
- User relationship context: [USER_RELATIONSHIP] (e.g., "first-time user", "enterprise customer", "anonymous")
- Product surface: [PRODUCT_SURFACE] (e.g., "chat", "API response", "voice assistant", "email")

LOCALE COMMUNICATION PROFILE:
[LOCALE_PROFILE]
(Provide a structured description of expected norms. Example fields: preferred directness level, formality expectations, politeness markers, apology conventions, redirection acceptability, and any taboos to avoid.)

OUTPUT REQUIREMENTS:
1. Rewrite the refusal message for [TARGET_LOCALE].
2. Preserve the exact refusal boundary. Do not imply the policy is negotiable.
3. Adjust directness, formality, and politeness markers to match the locale profile.
4. If the locale profile indicates redirection is expected, include a constructive alternative that does not circumvent the policy.
5. If the locale profile indicates redirection is unwelcome, keep the refusal brief and unambiguous.
6. Output ONLY a JSON object with the following schema:

{
  "adapted_refusal": "string",
  "tone_attributes": {
    "directness": "high|medium|low",
    "formality": "high|medium|low",
    "redirection_included": true|false
  },
  "cultural_adaptations_applied": ["string"],
  "policy_boundary_preserved": true|false,
  "notes": "string (optional, for any adaptation decisions that need explanation)"
}

CONSTRAINTS:
- Do not invent locale norms. Use only the provided [LOCALE_PROFILE].
- Do not change the refusal into an acceptance.
- Do not add humor, sarcasm, or brand personality unless explicitly specified in the locale profile.
- If the locale profile is incomplete or contradictory, flag this in `notes` and default to a neutral, polite refusal.

Adaptation guidance: Replace each square-bracket placeholder with data from your application context. The [LOCALE_PROFILE] is the most critical input—it should be a structured object or text block describing the target culture's communication expectations. Build this profile from your localization team's style guides, not from the model's internal knowledge. For high-risk regulated markets, add a [RISK_LEVEL] field and route outputs through human review before they reach users. The output JSON schema is designed to be machine-verifiable: check that policy_boundary_preserved is true before publishing the adapted refusal. If it is false, log the incident and fall back to a pre-approved static refusal for that locale.

This prompt is designed to sit between your base refusal generation system and the user-facing output layer. It should not be the first prompt that decides whether to refuse—that decision belongs to your policy enforcement and unsafe request classification pipeline. Instead, this prompt receives an already-determined refusal decision plus the original user request, and its job is to adjust the tone, directness, formality, and redirection style for a specific locale before the refusal reaches the user. Wire it as a post-processing step: after your safety classifier returns a refusal trigger, route the refusal payload through this prompt with the target locale context before rendering the final response.

The implementation requires a locale detection or selection mechanism upstream. If your product uses Accept-Language headers, account region settings, or explicit user language preferences, map those to a [TARGET_LOCALE] value using a standard like BCP 47 tags (e.g., ja-JP, de-DE, ar-SA). Pass the locale, the original user request, the raw refusal text, and your organization's non-negotiable policy boundaries as inputs. The prompt should never be allowed to weaken or remove a policy boundary—only adjust how it is communicated. Implement a post-generation validation step that checks the adjusted refusal against your policy boundary list using keyword matching, embedding similarity, or a secondary classifier. If the adjusted refusal drops a required boundary, fall back to the original refusal and log the failure for review.

For high-risk regulated markets, add a human review queue for adjusted refusals before they go live. Flag outputs where the prompt significantly changed the refusal structure, where the target locale has known cultural norms that conflict with your default tone, or where the confidence score from your validation step falls below a threshold. Log every adjustment with the locale, original refusal, adjusted refusal, validation result, and reviewer decision. This audit trail is essential for demonstrating that cultural adaptation did not introduce policy drift. Use a model with strong cross-cultural instruction following—Claude 3.5 Sonnet or GPT-4o are good starting points—and avoid small or quantized models that may collapse cultural nuance into stereotypes. Do not use this prompt for locales where you lack native-speaker review capacity; an incorrectly adapted refusal can cause more harm than a culturally neutral one.