How often should you update your AI acceptable use policy when AI tools change?

By the Shadow AI Policy team

Review the core AI acceptable use policy once a quarter, and update the approved-tool list whenever a trigger event happens — a new tool request, a vendor changing its data terms, or a new law taking effect. Only changes to the core policy (not routine tool-list edits) should require employees to re-acknowledge it.

This post shows how to split a stable policy from a fast-moving tool list, how to run a quarterly review alongside reactive updates, and who should own each piece. It also covers how to tell employees about changes without drowning them, and exactly which changes should trigger a fresh sign-off.

1. Why should the tool list live outside the policy?

Because the rules change slowly and the tools change constantly, and mixing them forces you to re-approve the whole document every time a vendor ships something new. The policy should answer questions that stay true for a year or more: what data employees may never put into an AI tool, who approves new tools, what review AI output needs before it reaches a customer, and what happens when someone breaks the rules.

The tool list answers questions that go stale fast: which named products are approved, on which plan or license, for which data, and under what conditions. Vendors add features, rename products, launch enterprise tiers and revise their data-use terms on their own schedule. If your policy says "ChatGPT is approved for marketing drafts," it's wrong the day the company buys a different license, or the day someone points out that the free consumer plan and the business plan come with different terms.

The fix is a two-document structure. The policy references the register ("Only tools listed in the Approved AI Tools Register may be used with company data, within the data tiers listed for each tool") and never names a product. If you're starting from scratch, our AI acceptable use policy template guide is built on exactly this split.

What it covers	Core policy (stable)	Approved tools register (volatile)
Typical contents	Data classification rules, prohibited uses, approval process, output review, consequences	Tool name, approved plan or license, allowed data tier, permitted use cases, owner, last review date
How often it changes	Reviewed quarterly; usually edited once or twice a year	Edited whenever a trigger event happens, often monthly
Who approves changes	Executive sponsor, with Legal and HR sign-off	Named register owner, with IT/security review
Employee re-acknowledgment	Yes, when a material change is made	No, except when a tool is removed or restricted for data already in use
Where employees find it	Handbook or HR system, versioned	One intranet page or shared doc with a single permanent link

2. Should you review on a fixed schedule or only when something changes?

Do both: a fixed quarterly review of the whole system, plus reactive updates to the tool register the moment a trigger event happens. A schedule alone leaves you running an out-of-date register for up to three months. Reactive updates alone mean nobody ever steps back to ask whether the rules themselves still fit how people work.

The quarterly review is a one-hour meeting with a fixed agenda. Walk through the register line by line and confirm each tool is still licensed and still used. Look at the tool requests that came in and what was decided. Note any incidents or near-misses. Ask whether any new law or contract obligation affects the core rules; if one does, check the effective date against a verified source such as our AI regulation compliance deadlines tracker rather than a news headline. Most quarters, the outcome is "no change to the policy, three edits to the register." That's a good result, not a wasted meeting.

Reactive updates happen between reviews, and they should be triggered by specific events rather than someone's general unease:

• An employee or team requests a new tool
• A vendor changes its terms of service, privacy policy or data-retention terms
• A vendor adds an AI feature to a tool you already use (for example, an assistant switched on inside your email, CRM or meeting software)
• A security incident or near-miss involving an AI tool
• A contract renewal, downgrade or change of license tier

That third trigger is the one companies miss most often. Shadow AI increasingly arrives as a feature inside software you've already approved, not as a new sign-up, which is why it's worth reading up on what shadow AI actually looks like before you design your triggers.

3. Who should own the tool list and approve changes?

One named person should own the register, and that person should not be the only approver. In a 50–500 person company, the register owner is usually someone in IT or operations who already manages software licenses, because they see new tools and renewals first.

Use a small, fixed approval path so requests don't stall:

• Register owner (IT or operations): receives requests, collects the vendor's current terms, and records the decision. Owns the "last reviewed" date on every line.
• Security or IT lead: checks how the tool handles data — whether inputs are used for training, how long they're kept, and whether admin controls exist.
• Legal or compliance: pulled in only when the tool will touch personal data, customer data, regulated data or anything covered by a client contract.
• Executive sponsor: approves changes to the core policy, not individual tool decisions.

Set a response deadline for requests — ten business days is a reasonable target — and publish it. When approval takes months, people stop asking and use the tool anyway, which is how shadow AI starts. A fast "yes, for public data only" is far more useful than a slow "maybe."

The goal of the approval process isn't to say no. It's to make the approved path faster than the workaround.

4. How should you tell employees when the policy or tool list changes?

Match the size of the announcement to the size of the change. If every register edit arrives as an all-staff email, people stop reading them, and the one message that matters gets ignored.

A tiered approach works well:

• Tool added or expanded: update the register and post a short note in the channel employees already read (a Slack or Teams announcements channel, or the team that asked for it). No email needed.
• Tool restricted or removed: notify affected users directly, say what they must stop doing and by when, and tell them where their existing work should go. Give a short deadline, not an open-ended one.
• Core policy change: email all staff with a plain-English summary of what changed and why, link to the new version, and request re-acknowledgment.

Whatever the tier, lead with what the employee must do differently. "From 1 December, don't paste customer names into the meeting-notes assistant; use the approved CRM summary feature instead" beats three paragraphs of background. And keep the register at one permanent link, so the answer to "is this tool allowed?" is always the same URL.

5. When do employees need to re-acknowledge the policy?

Require re-acknowledgment only for material changes to the core policy, and log every version so you can show who agreed to what. If you ask for a fresh signature every time a tool is added, acknowledgments become a click-through ritual that means nothing.

Treat these as re-acknowledgment triggers:

• A new category of prohibited data or prohibited use
• A change to the consequences for breaking the policy
• A new obligation on employees, such as disclosing AI-generated content to customers or logging AI use in client work
• A change to monitoring — for example, starting to log prompts in an approved tool
• A tool being removed for a security or data reason, for the people who were using it

Version control can be simple. Give the policy a version number and an effective date in the header, keep a short change log at the end ("v2.1, effective 1 November: added rule on AI meeting recorders"), and store every prior version rather than overwriting it. Your HR system or e-signature tool should record which version each employee acknowledged and when. If a dispute or audit ever comes up, that record is what you'll rely on.

Add one line to the policy that makes the register binding without re-signing: "The Approved AI Tools Register is part of this policy and is updated from time to time; the current version is always at [link]." That sentence is what lets you edit the register freely while keeping it enforceable. If you'd rather not draft that wording yourself, you can generate a tailored policy kit that already separates the two documents.

About Shadow AI Policy: We build AI acceptable use policy tools for HR and operations teams at 50–500 person companies. We publish guides on shadow AI, acceptable use policies, and AI governance, updated as regulations and AI tools change.