Bias Mitigation Policy Injection Prompt Template

This prompt template is for responsible AI teams, trust and safety engineers, and product managers who need to embed fairness rules directly into a system prompt. The job-to-be-done is not to debate bias as a concept, but to produce a concrete, testable instruction layer that governs how the model handles sensitive attributes, representational harms, and demographic parity in its outputs. The ideal user is someone who already has a product policy or fairness guideline and needs to translate it into a machine-enforceable contract that sits alongside the primary task instructions. You should use this prompt when you are building a user-facing feature—such as a resume screener, a loan eligibility explainer, or a content summarizer—where biased outputs create real legal, reputational, or user-harm risk.

Do not use this prompt when the underlying model has already been fine-tuned for fairness on your specific distribution, or when you are conducting an academic fairness study that requires raw model outputs for measurement. This prompt is also insufficient as a standalone control for regulated hiring or credit decisions; in those cases, it must be paired with a human review step, an output audit log, and a separate statistical evaluation pipeline. The template assumes you can provide a concrete [BIAS_POLICY] statement, a list of [SENSITIVE_ATTRIBUTES] to monitor, and a clear [TASK_DESCRIPTION] so the model can distinguish between legitimate task-relevant references to a protected attribute and a biased pattern. If you cannot articulate what a policy violation looks like in the output, this prompt will add latency without adding safety.

The primary risk of this prompt is over-correction, where the model refuses to engage with legitimate topics or strips necessary demographic context from a task that requires it, such as a clinical trial report that must describe participant demographics. Before shipping, you must run this prompt through an eval harness that measures both the reduction in representational harm and the change in primary task accuracy. If task accuracy drops below your release threshold, the policy language needs to be scoped more tightly, not abandoned. The next section provides the copy-ready template you will adapt and test.

This template provides a structured policy layer that you can inject into your system prompt to enforce bias mitigation rules without breaking primary task performance. It defines sensitive attribute handling rules, output review criteria, and explicit fairness constraints. The placeholders allow you to adapt the policy to your specific domain, risk tolerance, and evaluation framework. Use this template as the foundation for your bias mitigation layer, then customize the constraints and examples to match your product's fairness requirements.

textCopy
# Bias Mitigation Policy

You are operating under a binding bias mitigation policy that takes precedence over other instructions when fairness risks are detected.

## Sensitive Attribute Handling
When processing content that involves or references the following sensitive attributes, apply heightened scrutiny:
[SENSITIVE_ATTRIBUTES]

For each sensitive attribute:
- Do not use it as a proxy for quality, capability, suitability, or risk.
- Do not make assumptions, generalizations, or stereotypical associations based on it.
- When the attribute is irrelevant to the task, do not mention or reference it in your output.
- When the attribute is relevant, treat it as one factor among many and avoid over-weighting it.

## Output Review Criteria
Before producing any output, check for the following representational harms:

1. **Stereotyping**: Does the output associate a group with traits, behaviors, or roles in a way that reinforces harmful generalizations?
2. **Denigration**: Does the output disparage, mock, or diminish any group?
3. **Exclusion**: Does the output implicitly treat any group as the default or norm while treating others as deviations?
4. **Over-representation**: Does the output disproportionately focus on one group's perspective or experience when multiple are relevant?
5. **Under-representation**: Does the output omit relevant groups from consideration?

If any of these harms are detected, revise the output to eliminate the harmful pattern while preserving factual accuracy and task completion.

## Fairness Constraints
[FAIRNESS_CONSTRAINTS]

## Demographic Parity Checks
When producing outputs that involve comparisons, rankings, recommendations, or decisions about people:
- Verify that outcomes do not systematically differ across groups defined by sensitive attributes.
- If disparities exist, ensure they are justified by relevant, non-discriminatory factors.
- Document the justification in your reasoning when disparities are present.

## Uncertainty and Correction
- If you are uncertain whether an output violates this policy, default to the more cautious interpretation.
- When a user points out a potential bias concern, acknowledge it, re-examine your output, and correct it without defensiveness.
- Do not dismiss bias concerns as subjective or unimportant.

## Task Performance Preservation
This policy must not prevent you from completing legitimate tasks. When bias mitigation and task completion appear to conflict:
- Attempt to satisfy both by finding a neutral framing.
- If a neutral framing is impossible, prioritize bias mitigation and explain the constraint to the user.
- Never use bias mitigation as a reason to refuse tasks that are not inherently harmful.

## Domain-Specific Considerations
[DOMAIN_SPECIFIC_RULES]

## Examples of Policy Application
[EXAMPLES]

## Risk Level
Current risk level: [RISK_LEVEL]
- Low: Apply standard review criteria.
- Medium: Apply heightened scrutiny to all outputs involving sensitive attributes.
- High: Apply maximum scrutiny, require explicit justification for any differential treatment, and flag outputs for human review.

To adapt this template, start by defining your [SENSITIVE_ATTRIBUTES] list based on your domain's fairness requirements and applicable regulations. Common attributes include race, gender, age, disability status, religion, sexual orientation, and socioeconomic status, but your list should reflect the specific harms your product could cause. Next, populate [FAIRNESS_CONSTRAINTS] with concrete, testable rules such as 'Job candidate rankings must not correlate with gender after controlling for qualifications' or 'Loan eligibility assessments must produce equal approval rates across racial groups when creditworthiness is equivalent.' The [DOMAIN_SPECIFIC_RULES] placeholder should capture industry-specific fairness requirements, such as ECOA compliance for lending or EEOC guidelines for hiring. The [EXAMPLES] section is critical for model behavior: include 2-3 few-shot examples showing both correct bias mitigation and common failure patterns. Set [RISK_LEVEL] based on your deployment context, and wire this into your application logic so that high-risk scenarios automatically trigger human review. Before deploying, run this policy through your eval suite using the demographic parity and representational harm checks described in the evaluation section of this playbook. If you observe task degradation, adjust the fairness constraints rather than removing the policy layer entirely.

Integrating a bias mitigation policy into a production system requires treating the prompt as a configuration layer that sits between the application's business logic and the model's generation endpoint. The prompt template provided in this playbook should be stored as a versioned artifact, not hardcoded in application code. At runtime, the application must hydrate the [POLICY_DEFINITION], [SENSITIVE_ATTRIBUTE_LIST], [OUTPUT_REVIEW_CRITERIA], and [TASK_INSTRUCTION] placeholders from a policy store and the current user request. The hydrated system prompt is then prepended to the conversation context before the model call. This separation allows trust and safety teams to update bias rules without a full code deployment, provided the policy store supports rollback and audit logging of every change.

Before the model response reaches the user, the output must pass through a structured validation layer. The prompt instructs the model to self-annotate with a bias_review block containing a flagged boolean, a risk_level enum, and flagged_terms. The application harness should parse this block and enforce a hard rule: if flagged is true or risk_level equals high, the response is blocked from user delivery and routed to a human review queue. For medium risk, the system can optionally surface the response with a transparency label. The harness must also run a secondary check using a separate, lightweight classification model or a regex-based sensitive attribute detector to catch cases where the primary model fails to self-flag a biased output. This defense-in-depth approach prevents a single point of failure in the self-review step.

Logging and observability are critical for bias mitigation systems because fairness failures are often discovered retroactively through pattern analysis, not real-time alerts. Every model call should log the hydrated prompt version, the raw model output, the parsed bias_review block, the secondary classifier result, and the final routing decision (passed, labeled, or escalated). These logs feed into an evaluation pipeline that periodically computes demographic parity metrics and representational harm rates across slices of [SENSITIVE_ATTRIBUTE_LIST]. Avoid building this harness as a one-off script; instead, implement it as a middleware layer in your model gateway or AI proxy so that every team deploying prompts inherits the bias review pipeline by default. The next step is to run the eval suite from the 'Testing & Evaluation' section against your hydrated prompt in a staging environment before any production traffic reaches it.