An AI tool approved in March, with a review pencilled in for the next annual cycle, is rarely the same tool by the time that review comes round. It has changed model twice, picked up three new use cases, and started touching customers it was never scoped to touch. The thing the board approved no longer exists. What runs in production is its descendant, and nobody decided to approve that.
This is the pacing problem, and it is not a technology problem. It is a cadence mismatch. The capability moves on a release schedule measured in weeks; the board's authority to ratify it moves on a schedule measured in quarters and years. The gap between those two clocks is where governance quietly stops being true.
Key takeaways
- The pacing problem is a cadence mismatch: AI capability changes on a release schedule of weeks, while the board's authority to ratify it moves in quarters and years.
- AI breaks the annual-sign-off assumption in three ways — the model underneath changes, the usage spreads, and the controls drift — none of which is misconduct.
- You cannot out-meeting the release schedule; faster ratification is still a discrete act on a snapshot that has already changed.
- The fix is standing governance engineered into the system — an approval gate, a read-only constraint, an append-only ledger — that holds on every transaction.
- The board still ratifies the slow-clock things (risk appetite, what AI may never do) while the system enforces the fast-clock controls and produces its own evidence.
The board's ratification clock runs slower than the capability it ratifies
Boards are built to ratify. A proposal is worked up, papered, tabled, discussed, minuted, approved. That cycle is deliberate and it is a strength — it is how accountability is established and recorded. For most of what a board governs, the underlying thing changes slowly enough that an annual or quarterly cadence keeps pace. A treasury policy, a remuneration framework, a risk appetite statement: these do not mutate between meetings.
AI breaks that assumption in three specific ways.
- The model underneath changes. A provider deprecates a version, a configuration flag points at a newer one, and behaviour shifts. The system the board assessed may now sit in front of a different model with different failure modes, and no paper was tabled because, internally, "nothing changed" — only a version string.
- The usage spreads. A tool scoped as "internal, decision-support only" acquires a customer-facing surface, or a second team adopts it for a purpose the original sign-off never contemplated. The blast radius grows without a fresh decision.
- The controls drift. A confidence threshold is tuned, an approval gate is added or quietly removed, a prompt is rewritten. Each is a change to residual risk, and most never reach the board because each looks, individually, like routine engineering.
None of these is misconduct. They are the ordinary metabolism of a working AI system. The problem is that the board's instrument for granting permission — the meeting, the minute, the annual review — samples that system far too rarely to govern it. Annual sign-off governs a photograph of a system that has moved on.
You cannot solve a cadence problem by meeting more often
The obvious response is to review more frequently. Move AI from the annual cycle to the quarterly one; add a standing item. This helps, but it does not close the gap, because the gap is structural. A board cannot meet weekly, and even if it could, it cannot meaningfully re-ratify a system whose changes are individually invisible and collectively continuous. You would be reviewing a thing that has already changed again by the time the minute is signed.
The honest conclusion is that you cannot out-meeting the release schedule. Faster ratification is still ratification — a discrete act, after the fact, on a snapshot. What the pacing problem actually demands is a different kind of governance: one that does not wait for the meeting to be true.
This is the core move in governing the Intelligence Age. The board is increasingly accountable for capability it did not build and cannot inspect at the speed it changes. The response is not to inspect harder on the old cadence; it is to change where governance lives.
Governance has to be standing, and it has to be engineered in
There are only two places governance can sit relative to the pacing problem, and one of them does not work.
The first is episodic and after the fact: a periodic decision that approves a state of the system. This is what most AI governance currently is, and it is always behind, because it samples slower than the system changes.
The second is standing and continuous: controls that operate every time the system runs, so the rule the board cares about is enforced on every transaction, not checked at every meeting. This is the only form of governance that keeps pace, because it runs on the system's clock rather than the board's.
Standing governance does not mean the board governs less. It means the board's decisions are expressed as constraints that hold continuously, rather than as approvals that decay. The board sets the rule once; the system enforces it always; and the evidence accrues automatically, ready for the next meeting. The meeting stops being where governance happens and becomes where governance is reviewed — which is what a board meeting is actually for.
In practice, the constraints that survive the pacing problem are the ones written into the system itself. A few patterns from systems we have built:
- A human decision gate that cannot be bypassed. In an insolvency intelligence build, nothing is sent externally without a recorded
approvedByandapprovedAt. The board's rule — "a named person decides before anything leaves the building" — is not a policy in a binder that a model update might silently violate. It is a condition the workflow cannot complete without. A new model version inherits the gate; it does not escape it. - Read-only by construction. In a property-operations system, the analytics database enforces
transaction_read_only = onat the Postgres level, so the database itself rejects any write the model attempts. "The AI may read but never change these records" stays true across every model swap, because it is enforced by the engine, not asserted in a document. We explain the pattern in read-only by construction. - A control that produces its own evidence. In a surveying system, an append-only ledger records every AI suggestion, the surveyor's accept, modify or reject decision, and a name and timestamp — by construction, with no update or delete operations. The board does not have to ask whether sign-off happened; the proof exists as a by-product of the system running.
Each of these is governance that does not wait for a meeting to be true. The board ratifies the constraint; the constraint then holds on every transaction, while capability churns underneath it. That is what "engineered in, not bolted on" means for pacing: the rule is enforced at the speed the system moves, not the speed the board meets.
What the board actually ratifies changes
If standing governance does the continuous work, the board's role does not shrink — it sharpens. The board stops trying to approve a system state it cannot keep up with, and instead ratifies the things that do change slowly enough to govern on a board cadence:
| The board ratifies (slow clock) | The system enforces (fast clock) |
|---|---|
| Which decisions a human must own | The approval gate, on every external action |
| What the AI is never permitted to do | The read-only constraint, the denied-vocabulary blocklist |
| The risk appetite and the escalation thresholds | The confidence floor that overrules the model |
| Who is accountable when a control fires | The dated, append-only record of what happened |
The left column is genuinely a board matter and slow-moving — a risk appetite does not change weekly. The right column is where capability churns, governed by code that runs continuously, not by quarterly re-approval. The board's job at each meeting is then tractable: not "re-approve the system," but "confirm the constraints still match our appetite, and read the evidence that they held." That evidence belongs in a living AI risk register fed by the systems themselves, not transcribed by hand at quarter-end.
The regulatory backdrop rewards standing governance, not annual sign-off
This is not only good practice; it is the direction the UK regime points. The UK has no single AI statute. Governance is principles-based and regulator-led, through the DSIT five principles — safety, transparency, fairness, accountability and governance, and contestability — applied by existing regulators within their remits. Accountability and contestability are continuous obligations. You cannot discharge "a person can contest a decision" or "we are accountable for outcomes" with an annual approval; you discharge them with controls that hold every time the system acts.
Where AI touches personal data, the Information Commissioner's Office is the lead regulator under UK GDPR. The automated decision-making regime moved under the Data (Use and Access) Act 2025: section 80 came into force on 5 February 2026, repealing the old Article 22 and introducing Articles 22A-22D, which relax the previous near-prohibition while preserving the right to human review and to contest significant decisions. The ICO's updated guidance on automated decision-making and profiling remains in draft — its consultation closed on 29 May 2026, with final guidance expected summer 2026 — so treat any reliance on it as provisional. The relevant point for pacing: a right to human review is a standing requirement on every qualifying decision, not a box ticked once a year.
For UK firms caught extraterritorially by the EU AI Act, the high-risk application dates were pushed back under the 2026 Digital Omnibus to 2 December 2027 (stand-alone) and 2 August 2028 (embedded). These were agreed politically in May 2026 but were still completing the EU legislative process as of late May 2026, so confirm final adoption before relying on the dates. The Act's demands — logging, human oversight, accuracy and reliability — are again continuous duties, not one-off attestations.
A board's test for whether its AI governance can keep pace
You do not need to read the code to know whether your governance runs on the right clock. Four questions tell you:
- What did we actually approve, and does it still exist? If the system has changed model, scope or controls since sign-off, you are governing a photograph.
- Which of our decisions are enforced on every transaction, and which only at a meeting? The first kind keeps pace; the second is always behind.
- If a model is swapped tomorrow, which of our controls survive it untouched? A control that survives is engineered in; one that has to be re-checked is bolted on.
- Can we read the evidence that our constraints held, without anyone preparing a slide? If the proof must be assembled for the meeting, it is not standing governance.
A board that can answer these is governing AI on the system's clock. A board that approved a tool in March and plans to look again next year is governing a clock that stopped the moment the meeting ended.
Last reviewed: 29 May 2026.
If your AI sign-off is an annual event and the systems underneath it move every week, it is worth a short conversation about making governance standing rather than episodic. See how we engineer controls into the build on our trust page, or look at what we do.
