A hospital system spent eight months walking a triage-support model through clinical review, security review, and a board-level sign-off. The day it finally went live, everyone treated that as the finish line. What almost nobody in the room understood was that the model behind the approval had already changed twice during those eight months — the vendor had pushed two silent version updates before the ink on the approval was even dry. The system the board approved and the system now handling patient intake were, technically, not the same system at all.
This is not a hospital problem. It is the default condition of any organization running AI today. Traditional software governance carries an assumption that has quietly stopped being true: that a system only changes when you change it. Static software sits still between releases. AI does not. The model gets updated by a vendor you don't control. The data it retrieves from drifts as your business changes. The population using it shifts — new customer segments, new edge cases, new ways people try to break it. None of that requires anyone to touch a deploy button.
Approved is not a permanent state. It is a snapshot with an expiration date that nobody wrote down.
The instinct, when this becomes visible, is to tighten the front door — a longer checklist, a stricter committee, more signatures before launch. That's the wrong fix. A harder gate at the start does nothing about drift that happens after the gate. What actually closes the gap is a small set of ongoing habits, not a bigger one-time review. In my work I keep coming back to the same five practices, because they're the ones that catch the problem stricter approval never will.
1. Version Pinning Where You Can
Wherever the underlying model or API supports it, pin the version instead of accepting "latest." A fraud-detection system built on a pinned model version behaves the same way in July as it did in March, by construction — you decide when it changes, not a vendor's release calendar. The harder cases are SaaS platforms that give you no version control at all: the vendor updates the model underneath the product whenever they choose, and you find out from a behavior change, not a changelog. Those systems aren't ungovernable, but they carry meaningfully higher risk, and your governance program should say so explicitly rather than treating a pinned system and an unpinnable one as equivalent.
2. The Update Trigger
Where you can't pin a version — or even where you can, for the moments you do choose to move to a new one — you need a standing rule: any vendor model change, API version change, or material configuration change automatically triggers a re-evaluation before that new version touches production traffic. Not a discretionary review someone might remember to request. An automatic one. The trigger is the mechanism that turns "we should check when things change" from a good intention into something that actually happens, because it doesn't depend on anyone noticing the change in the first place.
3. A Living Evaluation Set
Most organizations run a benchmark once, at launch, and then never touch it again. That benchmark becomes historical trivia within a quarter. What you need instead is a small, maintained set of real cases — genuinely representative ones, including the edge cases that caused trouble before — re-run on a fixed schedule and after every material change, not just at launch. A customer-support model's living evaluation set might include the handful of conversation types that reliably reveal whether tone, accuracy, or escalation behavior has shifted. The set doesn't need to be large. It needs to be current, and it needs to run automatically, not whenever someone remembers.
4. The Drift Alarm
Some changes never get announced by anyone — not the vendor, not your own team. A lightweight monitoring signal is what catches those. This can be as simple as watching for a shift in the distribution of outputs, a rising rate of human overrides or exceptions, or a new pattern showing up in complaints or escalations. None of these individually proves something changed underneath the system. Together, they're an early warning that something worth investigating has moved — often before anyone would have caught it through a scheduled review alone.
5. A Re-Approval Cadence
Every governance sign-off should carry a calendar renewal date, not an indefinite one. How short that cadence needs to be should scale to how consequential the system is — a model influencing credit decisions or medical triage warrants a tighter renewal window than an internal tool that drafts first-pass email replies. The point of the cadence isn't ceremony. It's making sure "approved" has a shelf life that someone is actually responsible for checking, instead of quietly becoming permanent by default.
None of this is exotic. It's the same discipline mature engineering organizations already apply to infrastructure and software dependencies — pin what you can, get notified when a dependency changes, keep your test suite current, watch your monitoring, and revisit decisions on a schedule rather than never. AI governance has lagged not because the problem is unusually hard, but because it borrowed the wrong mental model from static software: approve once, move on. AI systems don't hold still long enough for that model to work. The organizations that get this right aren't the ones with the strictest launch gate. They're the ones that never stopped checking.
