1. The Problem: When Does an AI Governance Decision Expire?
An organisation evaluates an AI system in January. The system is approved.
By July, the model has changed, new tools have been added, the number of users has increased, the deployment context has changed, and new evaluation evidence has emerged.
Yet the governance record still says:
Approved
Is the system still approved—or is the organisation merely relying on an approval that was valid under conditions that no longer exist?
This leads to a more fundamental question:
When does a governance decision stop being trustworthy?
This article explores the hypothesis that AI governance decisions should not be treated as permanent approvals, but as claims whose validity depends on the continued truth of the assumptions and evidence underlying them.
If those assumptions materially change, the governance decision may need to be reconsidered.
The difficult question is therefore not simply whether AI systems should be reassessed. It is:
What changes should trigger reassessment, how material should those changes be, and how can organisations do this without turning governance into a continuous bureaucratic exercise?
2. From Static Approval to a Validity Claim
Consider what an approval actually means.
An approval implicitly says:
Given what we know about this system, its context, and its risks, the organisation considers this deployment acceptable under the current controls.
But that statement contains a number of hidden assumptions.
For example:
- The model behaves within its evaluated capability boundaries.
- Human oversight remains meaningful.
- The model has access only to approved tools and permissions.
- The system is deployed to the population that was assessed.
- Known failure modes remain sufficiently mitigated.
- The evidence used during assessment remains representative.
- The consequences of failure remain within the assumptions made during assessment.
Therefore:
An approval is only as valid as the assumptions supporting it.
This creates an important distinction between two concepts.
Governance decision
Approved
Governance validity
The conditions under which approval was granted remain sufficiently true.
An organisation may still possess a valid-looking approval record while the second statement is no longer true.
This is the central problem explored in this article.
3. What Is "Stale Governance"?
Stale governance occurs when material changes in an AI system, its deployment context, or the evidence surrounding it invalidate—or materially weaken—the assumptions underlying an existing governance decision, without that decision being reassessed.
Organisations should care about this because it can create several distinct problems.
1. False confidence
The organisation believes the system is governed because a governance record exists.
The existence of an approval can create confidence even when the conditions supporting that approval have changed.
2. Control mismatch
Controls were designed for yesterday's system.
For example, human review may have been sufficient when a system produced recommendations, but may no longer be sufficient after the system gains the ability to independently execute actions.
3. Accountability ambiguity
When something goes wrong, it becomes unclear whether the governance process actually considered the relevant state of the system at the time the decision was made.
4. Governance debt
Governance debt is the accumulation of unexamined changes between an AI system's current state and the assumptions embedded in its last governance assessment.
A system may go through twenty small changes that individually appear harmless but collectively create a materially different system.
This is similar to technical debt.
The individual changes may not appear significant enough to justify immediate attention. But over time, the distance between the governed system and the actual system can become substantial.
4. Three Classes of Change
Before deciding whether reassessment is necessary, it is useful to understand the different ways an AI system can change.
I would group them into three broad categories.
A. System Change
Has the action space or capability profile of the system changed?
Examples include:
- Model replacement
- Model fine-tuning
- New capabilities
- New tools
- New data sources
- Increased context window
- Greater autonomy
- New agent orchestration
- New permissions
- Changes in guardrails
These changes affect what the system is capable of doing.
B. Context Change
Has the consequence of the same system behaviour changed because its environment changed?
Examples include:
- Internal → customer-facing deployment
- New user population
- New geography
- New jurisdiction
- New use case
- Increased scale
- Use in a high-impact decision context
- Integration into a critical business process
The model itself may not have changed at all.
However, the governance implications can change significantly because the environment around the model has changed.
A system used to summarise internal documents is a different governance problem when the same system is used to support decisions affecting customers or employees.
C. Evidence Change
Has our knowledge about the system changed enough to weaken an existing governance assumption?
Examples include:
- New evaluation results
- New benchmark results
- Red-team findings
- Incidents
- External research
- Newly discovered capabilities
- Newly discovered failure modes
- Evidence that previous evaluations do not generalise
This category is particularly important because the system itself may remain unchanged while the governance decision becomes stale.
New evidence can change what we know about an existing system.
5. From Changes to Reassessment Triggers
The above framework can be used to classify changes as change signals.
But a change signal is not necessarily a governance trigger.
The next question is:
Which changes are material enough to require reassessment?
A starting framework could look like this:
| Trigger | Example | Governance assumption potentially affected |
|---|---|---|
| Capability | New reasoning or tool-use capability | Risk profile |
| Autonomy | Longer independent execution | Human oversight assumptions |
| Tools | Model gains external API access | Action space |
| Permissions | Model gains access to production systems | Consequence potential |
| Deployment | Internal → customer-facing | Affected population |
| Scale | Active users increase from 100 to 1 million | Magnitude of impact |
| Evidence | New evaluation or red-team result | Previous assumptions weaken |
| Model | Major model replacement | Transferability of evidence |
| Jurisdiction | Deployment in a new country | Applicable requirements |
| Incident | Material failure | Validity of existing controls |
| Use case | Assistance → decision making | Harm profile |
There could be many more triggers.
The purpose of the framework is not to claim that these are universally correct triggers, but to create a structured way of asking:
Which governance assumptions have changed, and how much do those changes matter?
This distinction is important.
A trigger should not simply mean:
something changed.
It should mean:
Something changed that may have materially affected the validity of an existing governance decision.
6. Not Every Change Deserves a Review
If every change triggered a full reassessment, governance could quickly become impractical.
Consider a simple UI change.
It may be technically a change to the system, but if it does not affect model behaviour, permissions, users, data, or consequences, a full governance reassessment would likely add little value.
A more proportional approach could have three levels.
Level 1 — No Action
A minor change has negligible effect on governance assumptions.
Example:
A UI change that does not affect model behaviour, users, permissions, or the system's operating context.
Level 2 — Targeted Reassessment
A change affects one or a limited number of governance assumptions.
Example:
A model gains a new external tool.
The organisation may need to reassess:
- tool access,
- permissions,
- human oversight,
- execution boundaries.
But it may not need to reassess every aspect of the system.
Level 3 — Full Reassessment
Multiple core assumptions change simultaneously.
Example:
Model replacement + greater autonomy + customer-facing deployment + new jurisdiction.
At this point, the original assessment may no longer provide sufficient evidence for the current system.
This leads to an important principle:
Reassessment should perhaps be proportional to the degree to which governance assumptions have changed, rather than triggered by change alone.
The challenge is therefore not simply identifying triggers.
It is designing thresholds for materiality.
7. Designing an Adaptive Reassessment Threshold
A trigger could be evaluated across at least four dimensions.
1. Magnitude
How much did the system or context change?
A small model update and a complete model replacement should not necessarily be treated identically.
2. Relevance
What governance assumption does the change affect?
A change that affects a critical safety or oversight assumption may matter more than a change affecting a low-risk property.
3. Exposure
How many people, systems, processes, or decisions are affected?
The same technical change may have very different implications at different scales.
4. Confidence
How certain are we that the change matters?
This is particularly important because AI evaluations are themselves imperfect.
A useful conceptual model could therefore be:
Reassessment priority ≈ magnitude × governance relevance × exposure × uncertainty
This is not intended as a validated mathematical formula.
Rather, it is a hypothesis about the dimensions that may need to be considered when deciding whether a change warrants reassessment.
The relative importance of these dimensions would require empirical validation.
8. The Missing Dimension: Combinations of Small Changes
The framework above treats triggers somewhat independently.
But real AI systems evolve through combinations of changes.
Imagine a system that experiences:
- slightly better reasoning,
- slightly more autonomy,
- one additional tool,
- five times more users,
- slightly weaker human review.
None of these changes individually crosses a reassessment threshold.
Together, however, they could materially alter the system's risk profile.
This creates a deeper problem:
Can governance thresholds detect material changes created by combinations of individually insignificant changes?
This may be one of the most difficult aspects of adaptive governance.
A trigger framework that only evaluates individual changes could miss the cumulative effect of system evolution.
This is another reason why governance debt may matter.
A system may go through twenty small changes that individually appear harmless but collectively create a materially different system.
The question is not only:
Did something significant change?
It may also be:
Has the system changed enough, in aggregate, that our previous governance assumptions are no longer trustworthy?
9. Technical Triggers vs Institutional Triggers
The discussion so far has focused heavily on system characteristics.
But governance does not happen in a vacuum.
There are institutional triggers as well.
For example:
- Acquisition of another company
- Change in organisational risk appetite
- New regulatory requirements
- New contractual obligations
- New internal policies
- Change in accountability structure
- Discovery of a previously unknown dependency
- Material incident in another organisation that changes the perceived risk landscape
This suggests four broad categories of triggers:
Technical triggers
The system changed.
Contextual triggers
The environment changed.
Evidence triggers
Our knowledge changed.
Institutional triggers
The governance environment changed.
This distinction matters because an AI system does not need to change for its governance requirements to change.
A new regulation, a new contractual obligation, or a change in organisational risk appetite could make an existing governance decision worth revisiting.
10. Internal Policy vs External Regulation
What happens when internal governance standards and external regulatory requirements operate at different speeds?
External regulation might establish a minimum floor.
An organisation may choose to operate above that floor because of its own risk appetite, contractual obligations, customer expectations, or internal standards.
Governance could therefore be thought of conceptually as:
Regulatory floor + organisational risk appetite + system-specific evidence
But these layers may evolve independently.
For example:
- Regulation may change before internal policy does.
- Internal policy may become stricter than regulation.
- An organisation may operate across multiple jurisdictions.
- The same AI system may cross different regulatory classifications depending on where and how it is deployed.
- A model's capabilities may change before regulation has caught up with those capabilities.
This creates an interesting governance problem:
What should trigger reassessment when the technical system changes faster than the regulatory environment?
And the inverse problem is equally important:
What should happen when regulation changes even though the AI system itself has not?
Adaptive governance therefore needs to account for both system evolution and governance-environment evolution.
11. Can Governance Triggers Be Standardised?
If trigger-based governance is useful, another question follows:
Can there be a standard set of triggers that applies across organisations?
There are reasons to think that some standardisation is possible.
For example, organisations may broadly agree that certain events deserve attention:
- major model replacement,
- material change in autonomy,
- new external system access,
- significant deployment-context change,
- material incident,
- new evidence of a previously unknown capability or failure mode.
However, the threshold at which these changes become material may not be universal.
The same model change could have very different implications depending on:
- industry,
- use case,
- affected population,
- autonomy,
- consequence severity,
- organisational risk appetite,
- jurisdiction.
This suggests a possible distinction:
Standardise the vocabulary and categories of change, but not necessarily the thresholds.
A common vocabulary could make governance systems more interoperable while allowing organisations to define thresholds appropriate to their own context.
This could also create a useful research direction:
Can a common trigger taxonomy coexist with organisation-specific reassessment policies?
12. The Organisational Incentive Problem
Even if technically sound triggers can be designed, there is another question:
Will organisations actually use them?
Governance competes with other organisational priorities.
A company may know that reassessing an AI system would be prudent but still choose to delay it because:
- reassessment costs money,
- product launches are time-sensitive,
- competitors are moving faster,
- governance teams have limited capacity,
- the probability of harm is uncertain,
- the benefits of caution are difficult to measure,
- responsibility for the consequences is distributed across teams.
This creates a potential incentive problem.
An organisation may rationally think:
The risk is uncertain, but the cost of slowing down is immediate and certain.
Therefore, adaptive governance cannot rely solely on the technical accuracy of its triggers.
It must also address the institutional environment in which those triggers are pulled.
This might require linking triggers to clear accountability mechanisms, compliance mandates, or commercial incentives.
13. The Expected Half-Life of a Governance Decision
This leads to a final conceptual model.
Could we think of a governance decision as having an expected half-life?
A governance decision with a short expected half-life would require more sensitive monitoring and more frequent reassessment triggers.
A governance decision with a longer expected half-life might reasonably rely on less frequent review.
This is different from simply saying:
Review high-risk systems more often.
The more interesting question is whether we can identify the properties that cause governance assumptions to decay.
For example:
- rapidly changing model capabilities,
- high autonomy,
- broad tool access,
- large affected populations,
- high consequence of failure,
- uncertain evaluation evidence,
- rapidly changing deployment contexts.
If these characteristics correlate with faster governance decay, organisations might eventually be able to estimate an expected governance half-life when an AI system is initially assessed.
The concept remains speculative.
It would require evidence to determine whether governance validity actually decays in a measurable way and whether such a measure would be useful in practice.
But it points toward a broader idea:
Governance may need to be treated not as a static property assigned to an AI system, but as a time-dependent claim whose validity changes as the system, its environment, and our knowledge about it evolve.
Conclusion
AI governance is often framed around questions such as:
Is this AI system compliant?
Has it been assessed?
Has it been approved?
These are useful questions, but they may be incomplete.
A more fundamental question is:
Does the reasoning that justified the original governance decision still hold?
AI systems do not remain static.
Models change. Capabilities change. Tools change. Permissions change. Users change. Deployment contexts change. New evidence emerges. Regulations change. Organisations themselves change.
A governance decision made under one set of assumptions may therefore become unreliable without anyone explicitly changing the governance record.
This is the problem of stale governance.
The solution may not be to continuously reassess everything.
Instead, organisations may need to identify signals of material change, determine which of those signals affect governance assumptions, and establish proportionate reassessment thresholds.
The difficult part is not creating a longer checklist of things that can change.
It is determining:
Which changes matter?
How much do they matter?
When should they invalidate an existing governance decision?
How should uncertainty affect that decision?
And what would make an organisation actually act when a trigger occurs?
The hypothesis explored here is that AI governance should move from a model of static approval toward one of adaptive validity.
Whether that model is actually better remains an empirical question.
And perhaps that is the most important conclusion: as AI systems become increasingly dynamic, the challenge for governance may no longer be simply deciding whether a system is safe or acceptable today, but knowing when yesterday's decision is no longer sufficient.