An AI policy update should create a new policy version. Earlier approvals should keep the facts, reasoning, and policy version that applied when they were made. The organisation can then place affected uses into review without rewriting the original decision.
I kept coming back to this while building policy updates in Can I Use AI?. Replacing the old policy is easy. Explaining what the replacement means for fifty earlier decisions is the real workflow.
Three common responses all create trouble:
- treating every earlier approval as permanently valid;
- cancelling every approval whenever wording changes;
- updating old records so they appear to have used the new policy.
The useful approach separates history from current validity.
Preserve what was approved at the time
Suppose an employee received approval in June to summarise internal project notes through a company-managed AI account. The record should retain:
- the proposed task and information category;
- the tool and account;
- the safeguards and human review;
- the policy result;
- any reviewer decision;
- the policy version effective in June.
Publishing a stricter policy in August should not alter those facts. The June record remains evidence of the decision that was made.
The current register status can still change. It may show “policy review required” while the original approval event remains visible in the history.
Identify which rules changed
Do not compare policies as one large document. Record changes at the rule level where possible.
For example, a new version may change the answer for:
- personal AI accounts;
- customer information;
- externally published output;
- employee evaluation;
- uses without complete human review.
Each completed check should retain which policy rules affected its result. The update process can then find decisions that relied on a changed rule.
This avoids sending a low-risk brainstorming use for review because an unrelated hiring rule changed.
Decide what the change should trigger
A changed rule can produce several actions:
- No action. The change does not affect the earlier use.
- Notify the owner. The use remains valid, but a safeguard or wording changed.
- Review required. A person must confirm whether the use still fits the new policy.
- Suspend the use. The new rule creates an immediate stop until the facts or controls change.
- Run a new check. The earlier facts are incomplete for the new rule.
The policy owner should define that treatment when publishing the update. A version number alone cannot decide whether an operational use may continue.
Treat external changes the same way
An internal edit is only one reassessment trigger. A use may also need review when:
- the AI tool or account changes;
- vendor terms or data handling change;
- a new information source is connected;
- the purpose, audience, or level of automation changes;
- the responsible owner changes;
- an approval expires;
- a contract or applicable obligation changes.
The original record still stays intact. The new event explains why the organisation reconsidered it.
Give the reviewer a focused question
“Please reapprove this use under the new policy” is too broad. Show the reviewer:
- the earlier request and decision;
- the changed rule;
- the facts that made that rule relevant;
- the previous safeguards;
- the decision they need to make now.
The reviewer may confirm the use, add conditions, request more information, suspend it, or reject it. Record that as another event with its own time and rationale.
Communicate with the people doing the work
The request owner should see whether they can continue, what changed, and whether any action is required. A generic announcement that “the AI policy has been updated” leaves them to work out the consequence.
For a small change, a notification may be enough. For a material restriction, the application should place the use into a clear review state and tell the owner what to do next.
Keep the workload bounded
Rule-level impact checks help a policy owner estimate the review queue before publishing. If one change affects hundreds of uses, the organisation can decide whether to stage the update, prioritise higher-impact cases, or apply a temporary safeguard.
This is much more manageable than discovering the queue after the new document has already replaced the old one.
The record and the register have different jobs
The completed record answers: What decision was made from these facts under this policy version?
The register answers: What is the current status of this use?
Both are needed. The record protects the history. The register helps the organisation act now.
Can I Use AI? publishes workplace AI policies as fixed versions, keeps completed decisions tied to the version used, and identifies earlier cases affected by changed rules so they can enter a human review queue.
This article provides general operational guidance. Organisations should define reassessment, suspension, retention, and notification rules for their own work and obligations.