The model moves faster than the committee approving it
The AI governance cadence problem: a review calendar built for quarterly software cannot keep pace with a system that can change every two weeks
Most enterprise AI governance committees meet once a quarter. The model they are approving can change every two weeks. By the time the committee reconvenes, the system in production has already moved past the version described in the review deck, and the committee spends its hour approving something that no longer exists.
A calendar is standing in for a control.
The mismatch is not a scheduling problem so much as a category error: governance was built for software that ships on a release cycle measured in months, and it is being pointed at a system that changes on a cycle measured in weeks. Meeting more often does not close the gap. It moves the same error to a faster clock. The fix is to stop approving the artifact and start approving the framework that produces it.
The calendar problem
A typical AI governance committee at a large enterprise convenes quarterly, sometimes twice a year. It reviews a vendor's documentation, a set of test results, and a risk assessment describing the system as of the day someone wrote the memo. The committee approves what the memo describes, and that approval is meant to hold until the next meeting.
Production does not wait for the memo. A model that runs through a promotion pipeline gets promoted whenever it clears its threshold, not on the committee's schedule. A candidate that clears its measures the week after a review can be serving live recommendations the week after that, months before anyone reviews it again. The committee approved a snapshot. The system kept moving the day the meeting ended.
Vendors call this continuous improvement, and it is. The trouble is that continuous improvement and a fixed review calendar cannot both describe the same governance model with a straight face. Either the calendar tries to catch every change, which means it runs faster than any committee can staff, or it samples the changes and calls the sample representative, which is the assumption that fails on exactly the version nobody looked at closely. A committee cannot give fifty versions a year the depth it gave one version, and slowing the model down to match the meeting schedule throws away the reason the enterprise adopted a learning system to begin with.
Govern the framework instead of the version
The version is the wrong object to govern, because it will not hold still long enough for a process to inspect it twice. What holds still is the framework a version has to pass through before it can touch anything real, and three parts of that framework do not change even when the model does.
Before promotion, a candidate model runs in shadow evaluation: it processes live inputs, produces outputs nothing downstream reads, and is measured against the incumbent on thresholds the enterprise set in advance. The candidate has to clear the bar before it ever touches a decision that matters. That protocol is what a committee should approve once, at real depth, and then hold constant: what gets measured, what threshold counts as passing, who signs off on a promotion.
Before execution, an approval gate blocks every proposed action until a named person reviews it. A human can approve, edit, or reject a proposed workflow before it executes, whatever model version proposed it. The gate does not care which version is running behind it. It cares whether a person looked at the proposal and its evidence before anything happened.
After execution, a decision trace records what the system read, what it proposed, what a human changed or approved, and what happened next. The trace answers the same question, what happened and why, on the first day of a model's life and two hundred days later. It does not need the model to hold still to keep working.
Approve those three mechanisms once, at the depth a quarterly committee can give in one sitting. Let the committee's ongoing job become auditing what the mechanisms produced. The question changes from whether the new version passed review to whether the promotion log shows a legitimate threshold clear, whether the approval gate caught what it was built to catch, and whether the trace reads cleanly for the last quarter of actions. That is a review a committee can finish in the time it has, because the question stopped requiring anyone to re-derive expertise about a moving target every time they meet.
This also changes who the review protects. A committee re-approving a version it does not have time to evaluate properly produces a record that a meeting happened. A committee auditing a mechanism's output against a standard it approved once produces a record that would hold up if someone asked hard questions about one specific decision a year later, because the trail runs back to that decision's own trace, not to a stale snapshot of "the model" from three cycles ago.
Where a slower clock still belongs
None of this argues for removing the calendar. Some decisions suit a quarterly rhythm precisely because they concern the boundary a version operates inside rather than the version itself.
A new category of workflow, one that touches a kind of decision the system has never been allowed to make before, deserves the slow read: what data does it now reach, who is the named approver, what does the trace need to capture that it did not need to capture before. Boundary questions change rarely enough that a quarterly cadence fits them well, and rushing that review to match the model's release pace would be the wrong fix in the other direction.
The threshold a shadow run has to clear before a promotion counts also deserves periodic, deliberate re-examination. Not because it changes often, but because loosening it is exactly the kind of decision that should never happen quietly inside the team that built the candidate model. Someone outside that team, on a fixed schedule, should confirm the bar is still where the enterprise wants it.
And the roster of people authorized to approve a promotion, or to serve as the second reviewer on a workflow's approval gate, belongs on a calendar too. Who holds that authority should be revisited on a fixed schedule even when nothing else about the framework has moved.
The line that matters runs between the version, which changes on its own cycle and should be audited on that cycle, and the boundary the version operates inside, which changes rarely and should be approved on a slower one. A committee that conflates the two ends up doing neither well: reviewing versions too shallowly to catch anything, and revisiting boundaries too rarely to notice when they have drifted.
What this looks like in production
At a Fortune 500 insurance carrier running this framework across four years of production data and 10,765 agents hired, the model behind the hiring recommendation has changed more times than any quarterly committee could review one by one. What has not changed is the framework itself: every promotion ran through shadow evaluation first, every recommendation stopped at an approval gate before a human could execute it, and every execution left a trace a reviewer can open today and read the way it read the day it happened.
A reviewer does not need to ask which model version produced a given recommendation. A reviewer needs to ask whether the record shows a human approved it, and whether the trace holds up against what happened next. Those two questions have the same answer whether the model behind them is the one running today or the one running eight versions back, which is the entire point. A framework built to survive a version change is the kind of governance an enterprise can keep up with indefinitely, because keeping up stops depending on the model holding still.
The committee's real job
A process that requires re-approving the artifact every time the artifact changes will always sit one cycle behind a system built to improve faster than the process can meet. A process that approves the mechanism once and audits its output on a schedule stays current by construction, because the thing it is checking never needed the model to pause. The committee's job was never to keep pace with the model. It was to make sure the model could never act without leaving a record the committee could trust. That job does not get harder as the model gets faster. There is simply more record to check, and the same three questions to ask of it.
Sources
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.