Deploy is the beginning of AI governance, not the end
Most teams treat “the model passed review, ship it” as the finish line. In practice it’s the starting gun. The two heaviest-weighted areas of the AI Governance Professional body of knowledge — governing a model’s release and monitoring (III.C) and its deployment and use (IV.C) — are both about what happens after go-live. That’s not an accident. It’s where the real risk lives.
Here’s the uncomfortable truth about a deployed model: the world it was trained on keeps moving, and the model doesn’t. Data drifts. Populations shift. An input distribution that was 3% of traffic at launch becomes 30% six months later, and quietly, accuracy erodes in exactly the segment you can least afford to get wrong. Nobody gets paged, because nothing “broke” — it just slowly stopped being right.
So a governed deployment isn’t a one-time audit. It’s a standing loop:
- Monitor continuously — training-serving skew and prediction drift, on a schedule, with alerts.
- Assess periodically — audits, red-teaming, threat modeling, security testing. Recurring, not once.
- Document every incident — including the near-misses and the drills. The evidence trail is the control.
- Root-cause honestly — drift, brittleness, poor data quality, insufficient testing. Name it.
- Be able to pull the plug — a real deactivation/rollback policy, tested, that a human can trigger.
That last one is what separates deployment governance from development governance. Building a model well is III. Being willing and able to turn it off when it stops being safe is IV.
I’m building this practice in the open — training small models, then governing them end to end and publishing the artifacts (impact assessments, model cards, bias reports, monitoring plans, incident logs). Not slideware. The actual paperwork a regulator would ask for, produced on real models, mapped to the frameworks that matter.
More soon.