AI Governance

Governance is the release machinery that turns principles into checks with owners, thresholds and logs, so a risky model cannot quietly ship.

Three recorded checks, provenance, audit score and drift margin, decide one release answer: ship or hold for review.

Why Does This Exist?

Principles do not stop a bad release. A team can agree that models should be fair, documented and watched, then ship anyway because nobody owned the check, the threshold or the log. Governance exists to close that gap between the poster and the pipeline.

It matters most where a failure bills someone else: a loan denial, a missed diagnosis, a car that misreads a sign. This page covers the release machinery: provenance, documentation, pre deploy audit, live watch and rollback. The paper trail itself lives in transparency and accountability. The audit method lives in model auditing. The person in the loop lives in human oversight. The full framework menu lives in responsible AI frameworks.

Think of It Like This

A commercial kitchen at dinner rush

A good kitchen runs on checks, not trust. Supplier receipts prove where the fish came from. The menu marks allergens so staff never serve a dish blind. One cook tastes every sauce before it leaves the pass. A thermometer watches the fridge all night, and anyone can call a stop when a reading looks wrong.

Map it across: receipts are data provenance, the menu is the model card, tasting is the pre deploy audit, the thermometer is drift monitoring, and stopping the pass is the rollback. No single check carries the night. The chain does.

Where it stops: a diner tastes a bad sauce at once. Model harm shows up weeks later as statistics across groups, which is why the logs matter more here than in any kitchen.

How It Actually Works

Governance is a chain of named checks, each with an owner, a threshold and a record. A model ships only when every check passes. Three checks carry most releases, and each one is a number against a line.

Let $V$ be provenance status, true only when every training source is logged with its consent and coverage. Let $D$ be the disparate impact ratio, the smaller selection rate divided by the larger one across groups. Let $\tau$ be the release floor for $D$ , commonly 0.80. Let $\delta$ be drift, defined as $\delta = \lvert p_{live} - p_{train} \rvert$ , where $p_{train}$ is the positive share in training and $p_{live}$ is the share this week. Let $m$ be the drift margin, here 0.05.

The three checks in order

Provenance gate. $V$ must be true. If a source is missing, stale or out of scope, training stops before it starts.
Audit gate. $D$ must clear $\tau$ . A credit model at $D = 0.78$ against $\tau = 0.80$ stays held, even with strong accuracy.
Drift watch. $\delta$ must stay under $m$ . Training at $p_{train} = 0.52$ and live at $p_{live} = 0.61$ gives $\delta = \lvert 0.61 - 0.52 \rvert = 0.09$ , which exceeds 0.05 and pages a human.

Worked example with one release

CreditRisk v3 arrives with $V = \text{true}$ , $D = 0.78$ , $p_{train} = 0.52$ and $p_{live} = 0.61$ . Step one passes. Step two fails because $0.78 < 0.80$ , so the release is held before drift even matters. After a fix the team resubmits at $D = 0.84$ with $\delta = 0.02$ : provenance true, $0.84 \geq 0.80$ , $0.02 \leq 0.05$ , so the answer flips to ship, and all three numbers go into the log with the approver name. The diagram draws this chain: three check boxes feeding one release diamond with a hold path back to review.

Code

A release gate you can drop into a pipeline script. Standard library only.

1from dataclasses import dataclass2
3
4@dataclass5class ReleaseGate:6    name: str7    provenance_ok: bool8    disparate_impact: float9    drift: float10
11    def decision(self) -> str:12        if not self.provenance_ok:13            return "hold: provenance missing"14        if self.disparate_impact < 0.80:15            return "hold: impact gate failed"16        if self.drift > 0.05:17            return "hold: drift review"18        return "ship"19
20
21v3 = ReleaseGate("CreditRisk_v3", True, 0.78, 0.09)22v4 = ReleaseGate("CreditRisk_v4", True, 0.84, 0.02)23print(v3.decision())  # -> hold: impact gate failed24print(v4.decision())  # -> ship

Version three is held at the audit gate. Version four clears all three and ships. The printed words are the decision log.

Watch Out For

Checklists filled in after the ship

Symptom: model cards dated after launch, an ethics board that can advise but never block, gates that run as warnings in CI. The paperwork exists and the behavior never changes. Fix: wire each gate as a blocking step with an owner, so a fail stops the deploy, and date every artifact before the release tag.

Trusting the dashboard alone

Symptom: broad group metrics look even while one intersection, say younger applicants in one postal area, fails badly and nobody looks there. Fix: pair every dashboard with slice audits on intersections that matter for the use case plus a human read of real outputs before release, as in model auditing.

The Quick Version

Provenance must be true before training starts: every source logged with consent and coverage.
The audit gate holds a model at disparate impact 0.78 under a 0.80 floor.
Drift is the absolute move in positive share, here 0.09 against a 0.05 margin, and it pages a human.
All three numbers plus the approver name go into the release log.
A gate that cannot block a deploy is decoration, not governance.
Dashboards need slice audits and human reads, because broad averages hide intersections.