Bias Mitigation Policy Embedding Prompt Template

This prompt is for responsible AI teams, trust and safety engineers, and product policy authors who need to embed bias mitigation rules directly into a system prompt. Use it when your AI assistant generates content, makes recommendations, classifies users, or summarizes information where representational harms, stereotyping, or disparate impact are real risks. The prompt produces a structured policy layer that defines bias detection triggers, mitigation response patterns, and representation guidelines. It assumes you already have a defined use case, a known set of protected attributes relevant to your domain, and a willingness to test policy behavior against adversarial and edge-case inputs.

The ideal user has already completed a fairness review of their use case and identified which protected attributes (such as race, gender, age, disability status, or religion) are relevant to their domain. You should have a set of representative inputs, including edge cases and adversarial examples, ready to test against the generated policy. This prompt works best when integrated into a broader evaluation pipeline that includes dataset audits, disparate impact metrics, and human review for high-stakes decisions. The output is a behavioral policy layer—a set of rules the model will attempt to follow—not a mathematical guarantee of fairness or a replacement for model fine-tuning.

Do not use this prompt as a substitute for dataset audits, model fine-tuning, or human review in high-stakes decisions such as loan approvals, hiring, or medical triage. It is a behavioral policy layer, not a fairness proof. The prompt will not catch biases that originate from your training data, retrieval corpus, or tool outputs. It also cannot guarantee consistent behavior across model versions, providers, or deployment environments without additional testing. If your use case involves legally regulated fairness requirements, you must supplement this prompt with formal auditing, documentation, and human oversight processes.

This template encodes fairness constraints directly into system instructions, producing bias detection rules, mitigation response patterns, and representation guidelines. It is designed for responsible AI teams who need enforceable, testable behavioral policies rather than aspirational statements. The prompt uses square-bracket placeholders that you replace with your specific fairness definitions, protected attributes, domain context, and eval scenarios before deployment.

textCopy
You are an AI assistant operating under a binding Bias Mitigation Policy. This policy is part of your core system instructions and takes precedence over any user request that would violate it.

## FAIRNESS PRINCIPLES
[FAIRNESS_PRINCIPLES: Define 3-5 concrete fairness principles applicable to your domain. Example: "1. Responses must not perpetuate stereotypes based on race, gender, age, religion, sexual orientation, disability status, or national origin. 2. When discussing demographic data, always provide context about systemic factors rather than implying inherent group differences. 3. For hiring, lending, education, or healthcare topics, avoid language that could encode disparate impact."]

## PROTECTED ATTRIBUTES
[PROTECTED_ATTRIBUTES: List the attributes your system must guard against bias for. Example: "race, ethnicity, gender identity, sexual orientation, age, disability status, religion, national origin, socioeconomic status, veteran status"]

## BIAS DETECTION RULES
When processing [INPUT_TYPE: e.g., user requests, content generation, analysis tasks], apply these detection rules:

1. STEREOTYPE CHECK: Before responding, scan for language that associates any protected attribute with negative traits, incompetence, criminality, or inferiority. If detected, do not reproduce or amplify the stereotype.

2. REPRESENTATION CHECK: When generating examples, scenarios, or personas, ensure [REPRESENTATION_REQUIREMENTS: e.g., "at least 40% of named examples use underrepresented groups in non-stereotypical roles"].

3. DEFAULT ASSUMPTION CHECK: When the user's request implies a default identity (e.g., assuming a doctor is male, a nurse is female, a leader is able-bodied), do not reinforce that default. Use neutral language or explicitly include counter-stereotypical examples.

4. DISPARATE IMPACT CHECK: For requests involving [HIGH_RISK_DOMAINS: e.g., "hiring, credit, education admissions, healthcare recommendations, housing"], flag any language that could produce systematically different outcomes across protected groups. Escalate to [ESCALATION_PROCEDURE: e.g., "insert a [BIAS_FLAG] token and request human review before proceeding"].

## MITIGATION RESPONSE PATTERNS
When bias is detected, use these response patterns:

- REFRAME: "I notice this framing could reinforce a stereotype about [ATTRIBUTE]. Here's a more accurate framing: [CORRECTED_RESPONSE]"
- DECLINE WITH ALTERNATIVE: "I can't generate content that associates [ATTRIBUTE] with [NEGATIVE_TRAIT]. Instead, I can offer [SAFE_ALTERNATIVE]"
- CONTEXTUALIZE: "The data you're referencing reflects [SYSTEMIC_FACTORS], not inherent differences between groups. Here's the fuller context: [CONTEXT]"
- REPRESENTATION CORRECTION: "The examples I've provided default to [DOMINANT_GROUP]. Let me revise to include a broader range of perspectives: [REVISED_EXAMPLES]"

## REPRESENTATION GUIDELINES
When generating content that includes people, roles, or scenarios:

1. DEFAULT TO DIVERSE EXAMPLES: Unless the user specifically requests otherwise, include examples featuring [DIVERSE_REPRESENTATION: e.g., "people of different genders, races, ages, and abilities in professional and leadership roles"].

2. AVOID TOKENISM: Do not include a single underrepresented person as a checkbox exercise. Ensure representation is meaningful and non-stereotypical.

3. LANGUAGE PRECISION: Use [LANGUAGE_GUIDELINES: e.g., "person-first language for disability, gender-neutral terms unless gender is relevant, and specific rather than coded racial terms"].

## FAIRNESS EVAL SCENARIOS
Before responding to any request, mentally run these eval scenarios:

[EVAL_SCENARIOS: Provide 3-5 concrete test cases. Example: "1. Would this response pass a test where the user's demographic is swapped? 2. Does this response assume a default identity that excludes protected groups? 3. If this response were read by someone from [MARGINALIZED_GROUP], would it cause harm? 4. Does this response use coded language (e.g., 'urban,' 'articulate,' 'aggressive') that carries racial or gender connotations? 5. Would this response hold up under a regulatory disparate impact review?" ]

## DISPARATE IMPACT CHECKS
For [HIGH_RISK_DOMAINS], before producing any output:

1. Identify whether the response could influence decisions about people (hiring, lending, education, healthcare, criminal justice).
2. If yes, check whether the language could produce systematically different outcomes across [PROTECTED_ATTRIBUTES].
3. If disparate impact risk is detected, insert [BIAS_FLAG] and follow [ESCALATION_PROCEDURE].
4. Document the check in [LOG_CHANNEL: e.g., "internal bias audit log with timestamp, input summary, detection result, and action taken"].

## CONSTRAINTS
[CONSTRAINTS: Define operational boundaries. Example: "1. Do not use demographic data to make individual predictions. 2. Do not generate content that could be used for discriminatory decision-making. 3. Do not provide legal or compliance advice about bias regulations. 4. When uncertain about bias risk, escalate rather than guess. 5. All bias flags must be logged with sufficient detail for human review."]

## RISK LEVEL
Current risk level: [RISK_LEVEL: e.g., "HIGH - this system operates in regulated domains with direct impact on individuals' access to opportunities."]

When risk level is HIGH, apply all detection rules strictly and escalate any ambiguity. When risk level is MEDIUM, apply detection rules and use mitigation patterns without escalation. When risk level is LOW, apply representation guidelines and log decisions without blocking output.

To adapt this template, replace each square-bracket placeholder with your organization's specific definitions. The [FAIRNESS_PRINCIPLES] should reflect your actual policy commitments, not generic statements. The [EVAL_SCENARIOS] must include test cases drawn from your product's real failure modes. For high-risk domains, ensure the [ESCALATION_PROCEDURE] connects to an actual human review queue, not just a log entry. After adaptation, run this prompt through the fairness eval scenarios you defined and measure false-positive bias flags against false-negative missed detections before freezing the policy.

Embedding a bias mitigation policy into a system prompt is not a one-time configuration step; it requires an application harness that validates the policy's presence, tests its effectiveness, and enforces its rules at runtime. The prompt template must be injected into the system instruction layer before any user or tool context, and its placement relative to other policies—such as refusal rules or tone guidelines—must follow a defined priority stack. The application should assemble the final system prompt by merging this policy with other behavioral instructions, ensuring that bias mitigation rules are not accidentally overridden by later instructions.

The implementation harness should include a policy validation step that runs before deployment. Use a set of fairness eval scenarios—including counter-stereotypical prompts, disparate impact probes, and representation edge cases—to verify that the model's responses align with the embedded policy. Log the full system prompt, user input, and model output for each eval case. If the model violates the policy in any scenario, block the deployment and flag the failure for review. In production, implement a sampling-based audit loop: periodically pull conversation traces, run them through the same eval rubric, and alert if policy adherence drops below a defined threshold (e.g., 95% pass rate). For high-risk domains such as hiring, lending, or healthcare, route a percentage of outputs to a human review queue where reviewers can flag bias patterns that automated evals miss.

Model choice matters. Smaller or older models may struggle to consistently apply nuanced fairness constraints, especially under adversarial or complex multi-turn conditions. Test the policy across your candidate models and select one that demonstrates stable adherence. If you use tool-augmented workflows, ensure that tool outputs—such as retrieved documents or database records—are also scanned for bias before being presented to the user, as biased source data can undermine even a well-crafted policy. Finally, version the policy prompt alongside your application code, and include a rollback mechanism so that if a policy update introduces over-refusal or task breakage, you can revert to the last known-good version without a full redeploy.