Responsible AI: Fairness, Bias Elimination, and Explainability
A regulator denies product certification because the model cannot explain why it rejected a credit application. Internal audit finds that the scoring model systematically underestimates candidates from certain regions. Client asks: "Why exactly this answer?"—and the system cannot answer.
Responsible AI is not an ethical declaration. It's a set of technical requirements for systems that influence decisions about people.
Three Pillars and Why They're Engineering, Not Philosophy
Fairness — Formal Definition That Cannot Be Chosen Randomly
Over 20 formal definitions of model fairness exist, and they are mathematically incompatible. Demographic parity (equal proportion of positive predictions across groups) contradicts equalized odds (equal TPR and FPR across groups). Cannot satisfy both simultaneously when base rates differ between groups—proven by Chouldechova's theorem (2017).
First step is not "make model fair," but choose fairness definition relevant to specific use case. For credit scoring, equalized odds prioritizes over demographic parity. For hiring—it's debatable and depends on legislation.
Tools for measurement: Fairlearn (Microsoft)—demographic parity difference, equalized odds difference, false positive rate ratio. AIF360 (IBM)—broader metric set. Both integrate with scikit-learn API.
Bias — Where It Comes From and Where to Look
Historical bias — data reflects past discriminatory decisions. Model trained on historical tech hiring reproduces gender bias. Solution: reweighting (weight examples during training) or adversarial debiasing (additional adversarial head penalizing protected attribute prediction).
Measurement bias — proxy features. Postal code correlates with race, frequency of financial product usage correlates with income. Removing protected attribute doesn't help if proxy features remain. Need correlation analysis of all features with protected attributes.
Label bias — bias in annotation. If annotators systematically labeled texts from different groups differently, model learns this bias. Auditing annotator agreement (Cohen's kappa) across protected groups is mandatory.
Feedback loop bias — model influences reality that's then collected again as data. Recommendation system shows less content to certain group → they click less → model "confirms" they're not interested. Solved by diversity forcing in recommendations and special monitoring of distribution shift across groups.
Explainability — Global vs Local, and When Each Is Needed
Global explainability — understanding which features matter for overall model. Feature importance from decision trees, permutation importance, global SHAP values. Needed for audit, regulators, development team.
Local explainability — explaining specific prediction. SHAP (additive feature attribution), LIME (local linear approximation), Integrated Gradients for neural networks. Needed for model operator explaining decision to specific client.
For LLM—different story. SHAP poorly applies to autoregressive models due to high dimensionality. Here work attention visualization (with caveats—attention ≠ importance), Chain-of-Thought prompting as explanation form, and counterfactual generation ("how would answer change if...").
Practical Case
Client—bank, credit scoring model on LightGBM (650 features, trained on 5 years data). Regulator required: explanation of each rejection plus proof of no age and region discrimination.
Steps:
-
Fairness audit: loaded Fairlearn, measured false positive rate ratio across age groups (18–25 vs 35–55)—1.84 when acceptable is 1.25. Group 18–25 received rejections much more often at comparable parameters.
-
Bias source: correlation analysis—feature "average account balance over 12 months" correlated with age (r=0.61). This is proxy discrimination.
-
Mitigation: reweight training sample plus Fairlearn GridSearch to find threshold minimizing false positive rate ratio at acceptable accuracy loss (ΔAUC = -0.012, acceptable).
-
Explainability: SHAP values for each decision, integration in API, automatic explanation generation for client ("Main factors: high debt load (weight +0.34), short credit history (weight +0.28)").
Result: regulatory approval obtained, false positive rate ratio reduced to 1.18.
Compliance Requirements in 2025
| Regulation | Requirement | Technical Implementation |
|---|---|---|
| EU AI Act (High-Risk) | Explainability, audit | SHAP/LIME + fairness metrics |
| GDPR Art. 22 | Right to explanation of automated decision | Local explainability |
| Equal Credit Opportunity Act (USA) | Non-discrimination in lending | Fairness audit + documentation |
| Federal Law 152 (RF) | Personal data processing | Anonymization in pipeline |
Process
Model audit — current fairness metrics, feature analysis for proxy discrimination, annotation check.
Fairness definition selection — jointly with legal/compliance team.
Technical mitigation — reweighting, adversarial debiasing, threshold optimization.
Explanation integration — SHAP/LIME in inference pipeline, format for regulator and end user.
Documentation — Model Card (Mitchell et al., 2019) plus Algorithmic Impact Assessment.
Timeline: audit existing model—2–3 weeks. Full mitigation and explainability integration cycle—6–10 weeks.