Change governance and the logging backbone

Lesson 3 of 5 in Human Oversight, Post-Deployment Monitoring, and Incident Response.

Monitoring finds the problem; change governance decides what happens next without breaking the assurances you gave at release. The core discipline is classifying changes by what they invalidate:

Routine retrain — same architecture, same features, fresh data. Re-runs the release gate’s evals (including fairness) but not the full design review.
Feature or data-source change — new inputs mean new proxy-discrimination and privacy questions. Re-triggers data-governance review plus the gate.
Architecture or objective change — a different model or a different target is a new model wearing the old name. Full validation, full documentation refresh.
Context change — same model, new population, new geography, or new purpose. The most under-governed class: nothing in the code changed, and everything in the risk profile did.

Champion/challenger keeps change honest at runtime: the incumbent (champion) serves while candidates (challengers) score in shadow on live traffic. Promotion requires beating the champion on the gated metrics — accuracy and fairness — not just the business KPI. It converts model replacement from a leap of faith into a measured handover.

In EU AI Act terms, changes have legal names. A substantial modification to a high-risk system — a change not foreseen in the original conformity assessment that affects compliance or purpose — triggers re-assessment; and under Art 25, a deployer who substantially modifies a system (or rebrands it, or repurposes a non-high-risk system into high-risk use) can become the provider, inheriting the full duty stack. Your change-management policy should say which internal change classes map to that legal line — deciding it during an audit is too late. One carve-out worth knowing: for systems that keep learning after deployment, changes pre-declared in the technical documentation and conformity assessment are not substantial modifications.

Classifying a model change

Proposed change to a deployed model
Pre-declared in the tech documentation?
Changes anticipated and documented at conformity assessment (e.g. scheduled retraining within stated bounds) are governed by the original assessment.
Run pre-declared change protocol + release-gate evals
Affects purpose, population, features, or architecture?
Treat as substantial modification
Full re-validation; for EU high-risk systems, re-run conformity assessment. If done by the deployer, check the Art 25 provider-switch trap.
Release gate: evals, fairness, regression attacks
Promote (champion/challenger handover), log the version

EU AI Act Arts 72, 12, 19, 26 — monitoring and logs

Art 72: providers of high-risk systems must establish a post-market monitoring system, proportionate to the risks, based on a documented plan that actively and systematically collects and analyses performance data over the system’s lifetime — and evaluates continued compliance, not just accuracy.

Art 12: high-risk systems must technically enable automatic logging of events over their lifetime — at minimum enough to identify risk situations and substantial modifications, and to support post-market monitoring.

Art 19 / Art 26(6): providers and deployers must keep the logs under their control for a period appropriate to the purpose — at least six months, longer where other law (like GDPR) requires. Logs are the raw material of every incident investigation and the first artefact a market-surveillance authority requests.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.