6 October 2026

An AI approval is only valid while its evidence and assumptions remain valid

An AI approval is a decision made at a particular point in time. It reflects the evidence available then. It also reflects assumptions about the model, supplier, data, users, purpose and operating environment.

Put AI and agents into production, with decisions you can defend.

Those conditions can change. A model may be updated. A supplier may alter its service or terms. A data source may become less reliable. A team may extend an internal assistant to a new group of users. A prompt, permission or workflow may change the way the system is used.

The approval remains on the record. The use case may no longer be the one that was approved.

This is not necessarily a failure of the original decision. It is a normal consequence of putting changing technology into live operation. The important question is whether the organisation can recognise when the original evidence and assumptions no longer support the decision.

An approval is a snapshot

Approval records are often treated as if they describe a permanent state. They do not.

They describe what the organisation decided about a use case at a particular time, based on a defined purpose and a known operating context. The decision may be sound. The evidence may have been sufficient. The controls may have been proportionate.

But validity depends on fit.

A document summarisation tool approved for internal legal documents may remain suitable while its purpose, users, data and supplier stay within the agreed boundaries. If it begins summarising customer complaints, the context has changed. The original approval may still be useful evidence, but it may not be enough for the wider use.

The NIST AI Risk Management Framework makes a similar point through its focus on continuous risk management across the AI lifecycle. Its functions are to govern, map, measure and manage risk. They are not presented as a one-off sequence that ends at deployment.

This gives organisations a practical way to think about approval. It is a decision that needs to remain connected to the conditions that made it reasonable.

Evidence can become stale in ordinary ways

Staleness does not always arrive through a major incident. It often comes through small operational changes that no single team considers material. Examples include:

A supplier releases a new model version under the same product name.
A reference-data feed changes its source, structure or update frequency.
A knowledge assistant receives access to a new document repository.
A support tool moves from assisting staff to drafting responses for customers.
A prompt is changed to make the system more decisive.
A new user group starts relying on outputs without the training assumed in the approval.
A permission change allows the system to retrieve more sensitive information.
A pilot expands to a larger population or a different business process.
The human reviewer remains nominally responsible but no longer has enough time or information to check the output properly.

Each change may be reasonable in isolation. Together, they can alter the use case.

The evidence can also age without any formal change. Performance may vary as the information environment changes. Users may find new ways to use the tool. A limitation that was acceptable at small scale may matter more when the system supports a high-volume process.

These examples are illustrative. The relevant triggers will depend on the use case and the organisation's own risk tolerance.

The point is not to treat every change as a reason to stop. It is to make the changes that matter visible.

Filed is not the same as valid

A register can be complete, tidy and out of date.

It may show that a use case has an owner, an approval date and a status of approved. That is useful information. It does not, by itself, show that the approved purpose remains accurate or that the evidence still supports the decision.

This is the difference between a filed approval and a valid approval. A filed approval answers:

Was a decision made?
Who made it?
When was it recorded?
Where is the supporting documentation?

A maintained approval also answers:

What exactly was approved?
What assumptions supported the decision?
What evidence was considered?
What has changed since the decision?
Who must decide whether the approval still holds?

The distinction matters because a register is a view of activity, not a one-time inventory. Our perspective on what should be in an AI use-case register is that purpose, ownership, review status and decision evidence need to remain connected.

A status field cannot carry that context on its own.

It is also where governance and audit part company. Our piece on AI governance vs AI audit sets out why an audit can confirm that a control was tested while ongoing validity of this kind depends on the operating model around the use case.

Name the assumptions behind the decision

The most useful approval records make their assumptions visible.

An assumption is not a weakness in the decision. It is a condition that helps explain why the decision was proportionate.

For an internal knowledge assistant, assumptions might include:

The assistant will use a defined set of internal documents.
Users will treat outputs as support for their work, not as final advice.
A named team will maintain access permissions and source quality.
Human review will remain in place for sensitive or consequential outputs.
The supplier's stated service configuration will remain within the assessed boundaries.

The record should also explain what would challenge each assumption. For example:

New data sources are added.
The user group expands.
The system begins producing external communications.
The supplier changes the model or service configuration.
Human review is reduced or removed.
Observed output quality falls below the agreed level.
An incident or complaint reveals a limitation that was not tested.

These are not all automatic reasons to withdraw approval. They are reasons to ask whether the decision still holds.

This is more useful than relying only on an annual review date. A calendar reminder can prompt attention, but it cannot identify every material change. Event-based triggers connect review to the reality of operation.

Record enough for a later reviewer

The person reviewing an approval six months later may not have attended the original meeting. The record should therefore allow that person to reconstruct the decision without searching across emails, meeting notes and separate testing files. At approval, record:

The use case and intended purpose. State what the AI system does, who uses it and what outcome it supports. Be clear about what is outside scope.
The accountable owner. Name the person responsible for maintaining the use case, responding to change and bringing it back for review when needed. Reviewers and contributors can support the decision, but they should not obscure ownership.
The evidence considered. Link the relevant testing, supplier information, data description, security review, user guidance, impact assessment or operational checks. Record what the evidence shows and any important limitations.
The assumptions and conditions. State the circumstances under which the decision is valid. Include controls that must remain in place, such as access restrictions, human review or defined data sources.
The review triggers. Define the changes that require a fresh look. These may relate to the model, supplier, data, users, purpose, permissions, automation, scale or observed performance.
The decision and residual uncertainty. Record whether the use case is approved, approved with conditions, paused or declined. Explain what uncertainty remains and who accepted it.
The next check and its owner. A periodic review can still be useful. It should sit alongside event-based triggers, not replace them. Assign the check to someone with enough authority and context to act on the result.

This approach gives the approval a useful operating life. It does not attempt to predict every future change. It gives the organisation a clear route for dealing with change when it occurs.

Connect oversight to the decision

RightTime Governance™ connects oversight to the specific decisions in each AI use case, with review and evidence proportionate to the context. That makes stale evidence a governance issue that can be addressed in the normal operating process.

The starting point is not another approval form. It is the decision that needs to remain defensible.

That decision-linked model is the basis of our AI governance framework: oversight connected to a named decision, owner and review route, with the depth of review shaped by the consequences.

For a lower-impact internal assistant, the relevant triggers may be limited to purpose, data access, users and supplier changes. A tool supporting a customer outcome may require more detailed testing, monitoring, human oversight and specialist review. The process should fit the situation.

Citadel can provide a workspace that keeps the use case, owner, decision and evidence together, so a later reviewer can see what was known and what has changed. It is a workspace for connecting the record, not a substitute for the judgement of the people accountable for the use.

The same principle can be applied through existing tools. The important feature is the connection between context, evidence, ownership and change.

Our approach to RightTime Governance sets out this decision-linked model in more detail.

Keep the approval current

An approval is not a permanent permission slip.

It is a reasoned decision made against evidence and assumptions that may move. Maintaining its validity means keeping those conditions visible, defining the changes that matter and giving a named owner responsibility for the next check.

That is how organisations can put AI and agents into production while keeping decisions clear, proportionate and defensible.

For organisations reviewing their own use cases, the next useful conversation may be simple:

Which approvals rely on assumptions that are no longer written down?
Which use cases have changed since their last review?
Which changes should trigger a fresh decision?
Who has the authority to make that decision?

Those questions provide a practical starting point for AI governance consultancy and for shaping a governance process that can keep pace with use.

Sources and further reading

The references to the EU AI Act describe the framework at a general level and are not legal advice. Applicability depends on the relevant system, role, use and jurisdiction.

All articles →