Bias Mitigation Strategy Recommendation Prompt

This prompt is for model improvement and responsible AI teams who have completed a structured bias audit and need to translate concrete findings into a ranked, actionable mitigation plan. The ideal user is an ML engineer, AI safety researcher, or product lead holding a detailed audit report that identifies specific harms, severity levels, affected groups, and triggering contexts. The prompt takes that audit evidence as input and produces a strategy document covering prompt engineering changes, retrieval adjustments, fine-tuning recommendations, and human-review insertion points, each with an expected impact estimate and implementation effort rating.

Do not use this prompt before you have audit evidence. If you are still at the detection stage, pair this with the Stereotype Detection Audit or Disparate Impact Scoring prompts in this pillar first. The prompt assumes you already know what harms were detected, at what severity, and in which contexts. Using it without concrete findings will produce generic, low-value recommendations that fail to address real product risks. The prompt is designed for post-audit remediation planning, not for initial harm discovery or exploratory fairness reviews.

This prompt is also not a substitute for human judgment in high-severity cases. When the audit flags critical safety risks or regulatory exposure, the output should be treated as a structured starting point for human-led mitigation design, not as a final decision document. The prompt works best when the audit report includes evidence excerpts, severity ratings, and affected groups, giving the model enough signal to rank interventions by impact and feasibility. If your audit data is thin or purely quantitative without qualitative examples, supplement it with representative failure cases before invoking this prompt.

This prompt is designed for model improvement teams who have already completed a bias audit and need to convert findings into a concrete engineering plan. It forces the model to ground every recommendation in specific evidence from the audit report, avoiding generic advice like 'improve your training data.' The output is a structured JSON object suitable for ingestion into project management tools, CI/CD pipelines, or governance dashboards. Use this prompt when you have a completed audit report and need to prioritize fixes across prompt engineering, retrieval, fine-tuning, and human review levers.

textCopy
You are a senior responsible AI engineer specializing in bias mitigation strategy for production LLM systems. Your task is to analyze the provided bias audit report and produce a ranked, actionable mitigation plan. For each finding, recommend specific interventions across four categories: prompt engineering, retrieval adjustments, fine-tuning, and human review insertion. Rank recommendations by expected impact, implementation effort, and risk of regression. Ground every recommendation in the specific evidence from the audit report. Do not propose generic fixes. If a finding cannot be mitigated through available levers, state that explicitly and recommend escalation.

[BEGIN AUDIT REPORT]
[AUDIT_REPORT]
[END AUDIT REPORT]

[BEGIN SYSTEM CONTEXT]
System type: [SYSTEM_TYPE]
Available mitigation levers: [AVAILABLE_LEVERS]
Fairness thresholds: [FAIRNESS_THRESHOLDS]
Deployment constraints: [DEPLOYMENT_CONSTRAINTS]
[END SYSTEM CONTEXT]

Produce your output as a JSON object conforming to the schema defined below. Do not include any text outside the JSON object.

[OUTPUT_SCHEMA]

Adapting the template: Replace [AUDIT_REPORT] with the full text of your bias audit findings, including severity ratings, affected groups, and evidence excerpts. The [SYSTEM_TYPE] field should describe your architecture (e.g., 'RAG chatbot with GPT-4o', 'fine-tuned Llama-3 classifier'). [AVAILABLE_LEVERS] must be an explicit list of what your team can actually change—if fine-tuning is not an option due to data constraints, remove it so the model doesn't waste recommendations there. [FAIRNESS_THRESHOLDS] should specify your quantitative gates (e.g., 'adverse impact ratio below 0.8 triggers mandatory mitigation'). The [OUTPUT_SCHEMA] placeholder should be replaced with your expected JSON structure, including fields for finding ID, recommended interventions, impact estimates, and effort ratings. Always validate the output JSON against this schema before ingesting it into downstream systems. For high-stakes deployments, route recommendations flagged as 'high regression risk' for human review before implementation.

Wire this prompt into a pipeline that runs after your bias audit prompt completes. Pass the audit output directly as [AUDIT_REPORT] without manual summarization. The prompt expects a structured audit containing finding IDs, severity ratings, affected groups, and evidence excerpts. If your audit prompt produces a different schema, add a normalization step before calling this recommendation prompt to map fields into the expected input shape. Use structured output mode with a JSON schema matching the output contract below—this is not optional for production use. Set temperature to 0.1–0.2 for consistent rankings across runs. Higher temperatures produce creative but unreliable mitigation suggestions that drift between invocations.

Implement a retry loop with schema validation. Parse the model response immediately and validate against the expected JSON schema. If the output fails to parse or violates required fields, retry once with the validation error included in the prompt as additional context. Do not retry more than twice without human escalation—malformed outputs after two attempts usually indicate a prompt-structure mismatch or an input that exceeds the model's reasoning window. Log every recommendation with the audit finding ID it addresses for traceability. Each log entry should include the finding ID, recommendation rank, expected impact estimate, and the timestamp of generation. This trace becomes your audit evidence when stakeholders ask why a particular mitigation was chosen.

Route the final output to a human review queue before any mitigation is implemented. This prompt recommends actions; it does not authorize them. The review queue should display each recommendation alongside its source finding, severity, and expected impact. Reviewers need the ability to accept, reject, or modify each recommendation and record their rationale. For high-severity findings, add a hard gate that blocks deployment until the corresponding recommendations are reviewed by a human. Implement this as a deployment pipeline check: if any unreviewed recommendation links to a finding with severity 'critical' or 'high', the release is blocked. This gate prevents automated mitigation of serious fairness issues without human judgment.

Choose a model with strong instruction-following and structured output support. The prompt requires ranking, impact estimation, and multi-step reasoning from audit evidence to actionable steps. Models with weak JSON mode or limited reasoning depth will produce plausible-looking but logically inconsistent recommendations—for example, suggesting a prompt change that contradicts the retrieval adjustment listed immediately after. Test your chosen model against a small set of known audit outputs with expected recommendation patterns before deploying. If the model consistently fails to connect findings to mitigations, consider splitting the prompt into two stages: first classify each finding by mitigation category, then generate ranked recommendations within each category.

Do not feed the output of this prompt directly into an automated mitigation system. The recommendations cover prompt changes, retrieval adjustments, fine-tuning needs, and human-review insertion points—each requiring different implementation paths with their own risks. A prompt change can be reviewed and deployed quickly. A fine-tuning recommendation requires data curation, training runs, and evaluation before it touches production. Route each recommendation type to its appropriate implementation pipeline only after human review confirms the approach. The fastest way to break a fairness intervention is to treat all mitigation types as equally safe to automate.