The model is governed. The process isn't.

Four enterprise AI governance launches in one week: SAS AI Navigator, OneTrust's platform overhaul, a KPMG risk paper, a Deloitte enterprise-architecture alliance. I read enough of the material to see what they share. Every page is written at boardroom altitude. Model inventories. Risk tiers. Gateways. Approval workflows. Not one answers the only question that matters on a line — what happens when the vision gate drifts at 06:00 on a Saturday and the senior decision-maker in the building is a shift quality engineer with two years on the floor.

I have lived that Saturday. A camera gate that had run clean for months began accepting marginal parts after a lighting change nobody logged. We caught it because an operator in her second week disliked a surface finish and escalated — not because a dashboard told us. Two hours to find the failure. Two days to prove containment. The Monday sort cost more than a €2 master part run every shift would have cost in a year.

What the governance stack actually governs

Strip the four offerings down and the machinery is identical. An inventory of every model the enterprise runs, with owner and intended use. A risk-tiering scheme borrowed from the EU AI Act. A gateway deciding which users may send which prompts to which models, plus a policy layer routing high-risk cases to human review. One trade headline promised a single gateway to govern them all — honest in an accidental way: it governs access to models, not what a model does to a product when everything around it changes.

None of this is wrong; most enterprises need it. But an inventory governs procurement and a gateway governs prompts — neither governs the part. Governance that stops at the model boundary is a register, not a control.

A register lists what you own. A control plan names who answers for it at six in the morning.

Four launches in seven days is not a market, it is a sales cycle. None of it arrives where failure lives: inside the process, on the third shift, in the forty minutes between drift starting and someone noticing.

A model is a process element, not a policy object

In a plant, an inspection model is not IT. It sits in the process line like a torque wrench, a CMM or a weld cell, and deserves the same suspicion. The PFMEA gets new failure modes: false accept, false reject, drift-induced misclassification. The causes read off a shift log — lighting change, lens contamination, part-presentation variance, a retraining set that quietly missed a new defect geometry. Severity is scored honestly. A model gating a safety characteristic is an 8 or a 9, with occurrence and detection scored against real detection, not the brochure.

Then the control plan, which reads like any other. The method line names the vision model and its version. Sample size 100%, because it sees everything — that is why you bought it. Control means golden parts at defined intervals, agreement trended like SPC, an alarm when it leaves the band. The reaction plan is the part no vendor writes: quarantine the bin, call the shift quality engineer, sort back to the last verified good check, open an 8D if a suspect lot shipped. Gate a special characteristic and the model carries the symbol with everything that comes with it — capability, revalidation, customer notification on change.

A model update is a process change. Retrain the weights, swap the vendor endpoint, restructure the prompt, and you have changed the process: that means revalidation and, under PPAP discipline, a change notification — not a DevOps ticket. I have written these documents for automotive plants. The FMEAs and control plans at Witte Automotive. The greenfield QA department built from zero for 900+ people at SNOP. The QRQC and A3 routines that backed them. No AI deployment now governed at enterprise altitude will ever appear in one. That is the hole in the framework.

Governing drift where it lands

I designed and built a platform that runs 63+ models in parallel with consensus synthesis; its governance I wrote myself, because vendor frameworks govern models, not decisions. A model that persistently dissents from the synthesised answer is routed out of the pool until someone looks at it. When the pool cannot reach confidence, the request degrades along a defined safe path — never to silence. Every prompt, every model's answer, every routing decision is logged, so when something looks wrong on Tuesday I can reconstruct Monday.

Attack it before the customer does

The habit comes from ethical hacking, and it is the same discipline as quality: find how the system fails before the customer finds out for you. I test every deployment the way a bad production day would — adversarial inputs, edge cases, the conversational equivalent of dawn light on a lens — then check whether the logging tells the truth about what just happened. A model that fails loudly is governable. One that fails quietly is a liability with a version number.

On the line, drift governance is three things. Detection with physical artefacts, because drift is a trend, not an event. A safe state for reaction — on alarm the gate stops passing and starts sorting, containment before diagnosis. And a name on the plan: the shift quality engineer owns the reaction, not a channel called MLOps.

Here is the test I apply to every framework, including my own. Hand it to the line engineer and ask for three artefacts: a PFMEA line, a reaction plan, an owner. If it produces them, the AI is governed. If it produces an inventory, you have bought a register with a vendor logo on it. The boardroom has had its week of launches. The third shift is still waiting for the first one written at its altitude.