What Is Algorithmic Fairness? A Developer's Guide

Algorithmic fairness is one of those terms that gets used constantly in AI policy discussions but rarely explained in terms that help developers actually build fair systems. This guide skips the philosophy and goes straight to the practical: what fairness metrics mean, how to compute them, when they are in tension with each other, and how to enforce fairness thresholds in your deployment pipeline.

Why Developers Need to Care About This Now

Fairness is no longer a voluntary consideration. The EU AI Act requires bias testing for high-risk AI systems. US financial regulators enforce the Equal Credit Opportunity Act through algorithmic audits. The UK's FCA has issued guidance requiring firms to monitor AI decision-making for protected-characteristic disparities. If your AI system makes decisions affecting people, you will face a fairness audit at some point. Better to build the measurement infrastructure before the audit than in response to a finding.

The Core Fairness Concepts

Protected Attributes

Protected attributes are characteristics that should not influence your model's decisions in ways that disadvantage specific groups. The canonical list: race, gender, age, disability status, national origin, religion, sexual orientation, pregnancy status. In credit and lending, marital status and receipt of public assistance are also protected. The specific list varies by jurisdiction and application domain.

A critical nuance: protected attributes often cannot be used as direct model inputs (doing so is illegal in most jurisdictions), but your model can still exhibit disparate impact based on them through proxy features — zip code correlating with race, purchase history correlating with income level, device type correlating with socioeconomic status.

Group Fairness vs. Individual Fairness

Group fairness asks: are outcomes distributed equitably across demographic groups? Individual fairness asks: are similar individuals treated similarly? These two notions can conflict. A model that is group-fair (equal positive outcome rates across groups) may be individually unfair if it treats genuinely different cases identically to hit group quotas. Most regulatory frameworks focus on group fairness, but individual fairness violations can still create legal liability.

The Main Fairness Metrics

Disparate Impact Ratio (DIR)

The most commonly used and regulated metric. DIR is the ratio of the positive outcome rate for the protected group to the positive outcome rate for the reference group.

function computeDisparateImpactRatio(
  predictions: Array<{ predicted: boolean; group: 'protected' | 'reference' }>
): number {
  const protectedGroup = predictions.filter(p => p.group === 'protected');
  const referenceGroup = predictions.filter(p => p.group === 'reference');
  
  const protectedPositiveRate =
    protectedGroup.filter(p => p.predicted).length / protectedGroup.length;
  
  const referencePositiveRate =
    referenceGroup.filter(p => p.predicted).length / referenceGroup.length;
  
  return protectedPositiveRate / referencePositiveRate;
}

// DIR >= 0.80 is the standard regulatory threshold (the "4/5 rule")
// DIR < 0.80 indicates potential adverse impact on the protected group

The 0.80 threshold comes from EEOC guidelines for employment selection procedures and has been adopted widely for credit and other high-stakes decisions. The EU AI Act references DIR as part of its bias testing requirements.

Equalized Odds

Equalized odds requires that both the true positive rate (sensitivity) and false positive rate (1 - specificity) are equal across groups. This is stricter than DIR because it requires accuracy parity, not just outcome parity.

interface GroupMetrics {
  truePositiveRate: number;  // Correctly approved when should be approved
  falsePositiveRate: number; // Incorrectly approved when should be denied
}

function computeEqualizedOdds(
  protected_group: GroupMetrics,
  reference_group: GroupMetrics
): { tpr_gap: number; fpr_gap: number; equalized: boolean } {
  const tpr_gap = Math.abs(
    protected_group.truePositiveRate - reference_group.truePositiveRate
  );
  const fpr_gap = Math.abs(
    protected_group.falsePositiveRate - reference_group.falsePositiveRate
  );
  
  return {
    tpr_gap,
    fpr_gap,
    equalized: tpr_gap < 0.05 && fpr_gap < 0.05  // 5% tolerance is common
  };
}

Calibration

A model is calibrated across groups if the predicted probabilities mean the same thing for all groups. If your model assigns a 70% risk score to applicants from two different groups, both groups should default at approximately 70%. Miscalibration means your scores systematically overestimate or underestimate risk for specific groups.

The Fairness-Accuracy Trade-off (and Why It Is Often Overstated)

You will hear that improving fairness metrics necessarily degrades model accuracy. This is sometimes true at the extremes, but in practice, models with poor fairness metrics often exhibit it because of biased training data — and fixing the data improves both fairness and accuracy. The trade-off is real when you try to hit extreme group parity targets, but the comfortable compliance zone (DIR above 0.80) usually does not require significant accuracy sacrifice.

You Cannot Satisfy All Fairness Criteria Simultaneously

Chouldechova's impossibility theorem (2017) shows that for binary classification problems with unequal base rates between groups, you cannot simultaneously achieve calibration, equal false positive rates, and equal false negative rates. You have to choose which fairness criteria matter most for your use case.

In practice: for credit decisions, equalized false positive rates matter most (you do not want to incorrectly deny qualified applicants from protected groups at higher rates). For fraud detection, calibration matters most (scores need to be meaningful regardless of customer demographics). Document which criteria you prioritized and why — this documentation is what auditors review.

Integrating Fairness Tests into Your CI/CD Pipeline

Fairness tests should block deployment when thresholds are violated, just like unit tests block deployment when they fail. Here is how to integrate AgentGate's fairness gate into a deployment pipeline:

// fairness-check.ts — run this before every model promotion
import AgentGate from '@agengate/sdk';

const gate = new AgentGate({ apiKey: process.env.AGENGATE_API_KEY });

async function runFairnessGate(
  modelId: string,
  validationDataset: ValidationSample[]
) {
  const report = await gate.fairness.evaluate({
    model_id: modelId,
    dataset: validationDataset,
    protected_attributes: ['gender', 'age_group', 'ethnicity_proxy'],
    reference_group: 'majority',
    metrics: ['dir', 'equalized_odds', 'calibration'],
    thresholds: {
      dir_minimum: 0.80,
      tpr_gap_maximum: 0.05,
      fpr_gap_maximum: 0.05
    }
  });
  
  if (!report.passed) {
    console.error('Fairness gate FAILED:');
    report.violations.forEach(v => {
      console.error(`  ${v.metric} for group ${v.group}: ${v.value} (threshold: ${v.threshold})`);
    });
    process.exit(1);  // Block deployment
  }
  
  console.log(`Fairness gate passed. DIR: ${report.metrics.dir}`);
  return report;
}

Add this check to your CI pipeline between model training and the promotion-to-staging step. A failing fairness gate should be treated the same as a failing security scan — deployment stops until the issue is addressed.

Fairness Monitoring in Production

Fairness metrics in production can drift even when the model itself has not changed, because the distribution of incoming requests changes over time. A model that was DIR-compliant at launch may drift out of compliance as customer demographics shift or economic conditions change. Configure production fairness monitoring with a rolling window:

// Configure rolling fairness monitoring in AgentGate
await gate.fairness.configureMonitoring({
  agent_id: 'credit-agent-v3',
  window_days: 30,
  alert_threshold: { dir: 0.82 },  // Alert at 0.82, gate at 0.80
  alert_channels: ['slack:#compliance-alerts', 'email:compliance@yourco.com'],
  report_schedule: 'weekly'
});

What Auditors Expect to See

When a regulator reviews your AI fairness controls, they want to see: a written policy defining which fairness criteria you are using and why, baseline metrics from your initial model validation, ongoing monitoring records showing metric trends over time, evidence that threshold violations triggered investigation and remediation, and documentation of any trade-off decisions you made between competing fairness criteria.

AgentGate's compliance export generates a fairness attestation package covering all five of these elements. See the fairness documentation for the export format.