Chapter 7AI Governance course

Chapter 7. AI Quality, Drift & Fairness: continuous evaluation and bias mitigation

A provider quietly updated the base model. The API is formally the same, the version string is unchanged — but behavior shifted: Kovcheg started inventing loan terms not present in the documents slightly more often, and treating applications from one region slightly more strictly. No one changed anything in the code. A month later it surfaces as a spike in complaints and a question from compliance: "Why have approvals in region N dropped?" This is what silent degradation looks like — the most common way an AI system's quality erodes without a single deployment.

This chapter covers the quality plane: the guarantee that the model doesn't degrade over time (drift), answers stay accurate through base-LLM updates, and decisions don't discriminate (bias). For Kovcheg, bias in scoring isn't a dashboard metric — it's a direct violation of the AI Act (Art. 10 — data quality, non-discrimination) and a legal claim.

The customer's business goal

Kovcheg's decision quality and fairness are measurable, continuously monitored, and a release gate. Promises to the business:

A model update never ships to production without passing regression against benchmarks.
Degradation and drift are caught by monitoring, not by complaints.
Absence of demographic bias in scoring is provable.

Driver: threat or regulator

Silent degradation: an under-the-hood model update tanks quality invisibly.
EU AI Act (high-risk): Art. 10 (data quality, non-discrimination), Art. 15 (accuracy, robustness), Art. 14 (human oversight).
Bias: systematically worse outcomes for a group means a lawsuit, a fine, and reputational damage.
OWASP LLM: LLM09 (Misinformation) — hallucinations as a class.

Architectural pattern

Continuous Evaluation & LLM-as-a-Judge Pipeline — evaluation as a continuous process: regression against golden datasets in CI/CD + online RAG metrics + drift monitoring + fairness tests, with an honestly calibrated judge.

Engineering stack & providers

Eval frameworks: Ragas (v0.2+ — no longer just RAG, agentic pipelines too), DeepEval, TruLens, MLflow (experiments/registry).
Drift/data quality: Evidently AI, Great Expectations.
Judge: LLM-as-a-judge, calibrated against human labeling.

Engineering implementation

### Step 1. Golden datasets

Reference sets for regression-testing prompts/models in CI/CD. A model/prompt update can't ship without passing the run. The dataset includes "hard" cases and cases pulled from real incidents.

### Step 2. Online RAG metrics

On a sample of production traffic: Faithfulness (grounding to context — a direct defense against the hallucinations from the introduction), Answer Relevance, Context Recall/Precision. This ties to the output guardrail (ch. 3) — that's the real-time block, this is the trend.

### Step 3. Drift monitoring

Anomalies in the distribution of incoming query embeddings (data drift) and in answer quality (concept drift). A shift triggers an alert. Important: semantic caching (ch. 5) masks drift — measure on the uncached sample.

### Step 4. Fairness & bias

A regular run of synthetic tests: swap protected attributes (gender, age, region) while holding everything else equal → compare decisions. A systematic difference is a bias signal. For Kovcheg, this is a mandatory gate for the credit module.

### Step 5. Release eval gate

Metrics are part of the pipeline (policy-as-code, ch. 6). Falling below a threshold blocks the deploy:

eval_gate:
  faithfulness:      {min: 0.92}
  answer_relevance:  {min: 0.85}
  fairness_delta:    {max: 0.03}   # max. difference in decisions on attribute swap
  block_release_on_fail: true

Where it breaks

LLM-as-judge is itself biased and non-deterministic. Documented distortions: verbosity bias (longer = "better"), self-preference (favors its own style), position bias (answer order). Mitigation: randomize order, use clear rubrics, ensemble judges, human golden labeling. Without calibration, it's "evaluating the evaluator."
Calibration drifts. Judge-human agreement that was solid six months ago goes stale — prompts, data, model versions change. Recalibration is a recurring process, not a one-off.
The golden dataset goes stale. It doesn't cover new cases → green metrics during real degradation. Refresh the dataset from incidents and production traffic.
Fairness is hard to measure. "Fairness" is context-dependent; several formal fairness metrics are mathematically incompatible at the same time — choosing a metric itself requires justification.
Cost. Continuous judge evaluation is expensive; sampling vs. completeness is a tradeoff.

Standards and mapping

EU AI Act: Art. 10 (data governance/quality, non-discrimination), Art. 15 (accuracy/robustness), Art. 14 (human oversight).
ISO/IEC 42001: performance monitoring, continual improvement.
NIST AI RMF: Measure (valid, reliable, fair, safe).
OWASP LLM: LLM09 (Misinformation).

Lab and artifact

Build a golden dataset for Kovcheg (including incident-derived cases), configure Ragas metrics online, Evidently for embedding drift on the uncached sample, an attribute-swap fairness test for the credit module; wire an eval gate into CI; calibrate the judge against human labeling and measure agreement. Artifact: an eval suite + a quality/drift dashboard + a fairness report + a judge-calibration report (evidence for the RMS, ch. 6).

Maturity checklist

L1: manual quality checks on update.
L2: a golden dataset + online RAG metrics, drift alerts.
L3: an eval gate in CI, a calibrated judge with recalibration, regular fairness runs, drift measured on the uncached sample, tied into the RMS (ch. 6).

Sources

[LLM-as-a-Judge calibration: power & limits (Deepchecks)](https://deepchecks.com/llm-judge-calibration-automated-issues/)
[RAGAS and LLM-as-Judge production evals](https://letsdatascience.com/blog/llm-evaluation-ragas-llm-as-judge-and-production-evals)
[Case-Aware LLM-as-a-Judge for Enterprise RAG (arXiv)](https://arxiv.org/html/2602.20379v1)
[Exploring LLM-as-a-Judge (Weights & Biases)](https://wandb.ai/site/articles/exploring-llm-as-a-judge/)

In practice

How it actually works — engineering breakdowns

Standalone howto from practice, showing this control plane on real code and a working artifact.

Eval as a Release Criterion: Catching Agent Drift Before ProductionEval as a release criterion: catch agent drift before prod, not after.

Putting AI into production under regulatory risk?

Designing the control plane for your system: privacy, access, guardrails, audit, EU AI Act / ISO 42001 compliance — as working architecture, not a policy PDF.

Email me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →