Why an AI policy stops being true without anyone changing it

An AI acceptable use policy describes the tools as they looked on the day it was adopted. After that, the vendor keeps changing them: new data sources, new models, new defaults and new settings. The policy can stop being true without anyone changing a line of it, and when that happens the problem is not what the policy says but that nobody is watching what it describes.

Why does an AI policy stop being true when nobody has changed it?

It can be counted. Microsoft publishes release notes for Microsoft 365 Copilot listing the features that have become generally available, roughly one entry per feature. Sometimes the same feature comes back in a new entry for another platform. In the public source of the release notes there are around 460 such entries in the releases dated from April 2025 to March 2026, between 18 and 63 a month. No month was empty. The source file was last updated with the release of 21 April 2026, and the live page now shows only releases from January 2026 onwards.

Many of those entries change nothing a policy has anything to say about. But some do. During the period Copilot gained connectors to Dropbox, Google Drive, Asana, Jira Data Center and GitLab, among others, which means new places to pull text from and new routes for text written by someone outside the organisation. The release from December 2025 states that GPT-5 is now the default model across Copilot Chat. Since then the product has also been renamed: Microsoft 365 Copilot is now called Microsoft Copilot, and Microsoft 365 Copilot Chat is now Microsoft Copilot Chat. Microsoft states that the rename changes nothing in security, compliance or privacy, but a policy that names the product still has to keep up.

None of these changes is a fault on the vendor's part. This is how the services are delivered. But a sentence in a policy that names a product, a model, a data source or a setting describes a state, and the state is changed by someone other than the person who wrote the sentence.

When a new setting decides where the data is processed

The clearest example for an organisation in the EU, EFTA or the UK concerns where the data is processed. Microsoft has made Anthropic's models available in Copilot with Anthropic as a subprocessor. According to Microsoft's documentation on the models, they are currently excluded from the EU Data Boundary, Microsoft's commitment to store and process customer data and personal data within the EU and EFTA, subject to limited exceptions. For customers in the EU, EFTA and the UK they are switched off globally by default.

A sentence in the policy can come to depend on a setting that did not exist when it was written.

On 3 April 2026 Microsoft introduced a separate setting for Word, Excel and PowerPoint in the EU, EFTA and the UK. It lets Copilot in those apps use Anthropic's models by default when content is generated or refined. The setting applies only to Copilot in those three apps and does not change the global setting. According to Microsoft's description of the setting, it is on by default for tenants created after 25 March 2026, while older tenants are referred to the Message Center to see what applies to them. When the models are used there, processing takes place outside the EU Data Boundary. The setting can only be changed while the global Anthropic setting is switched off. If the global setting is on, for all users or for selected users and groups, the app setting cannot be changed, and support for Anthropic's models in the apps depends on how the global setting is scoped. Microsoft encourages every administrator to check what applies in their own tenant.

Consider a policy adopted before 3 April 2026 that approved Copilot on the grounds that the data is processed within the EU. It could not take a position on a setting that did not yet exist. Whether the sentence holds today depends on when the tenant was created, on two settings in the admin centre and on whether anyone has read Microsoft's messages since. The setting did not appear among the release-note entries for April either. Anyone reading only these release notes would not have seen it.

AI policies are becoming more common, and the tools change every month

More and more organisations have an AI policy. In ISACA's global AI Pulse Poll, published in May 2026 with responses from more than 3,400 professionals in fields including IT audit, governance, cybersecurity and privacy, 38 per cent say their organisation has a formal, comprehensive AI policy, up from 28 per cent the year before. 30 per cent have a limited policy and 25 per cent have no active policy. At the same time, 90 per cent believe employees are already using AI.

The poll shows policies becoming more common and more comprehensive. It says nothing about how they are kept current, and that is where the release notes and the poll meet: every policy is written against tools that change every month. The US National Institute of Standards and Technology, NIST, sets out a related desired outcome in its voluntary AI Risk Management Framework (AI RMF). Govern 1.5 says that ongoing monitoring and periodic review of the risk management process and its outcomes are planned, with roles and responsibilities clearly defined and a set frequency for the review.

The ongoing part is the one that catches the vendor's changes. A review on a fixed date only sees what has happened up to then. Monitoring requires someone to read the vendor's change notices, meaning release notes, the Message Center and the documentation, against the sentences in the policy that those changes could make untrue.

The objection: write the policy at the level of principle and it will not age

There is a countervailing point that carries weight. Many entries in the release notes touch nothing a policy needs to say: a new image effect, a new way to navigate chat history, a new button in an app. A policy that only says staff should use approved tools and not enter sensitive data into other services survives every one of them. Rewriting the policy each time the vendor ships something also has a price. People stop reading a document that keeps changing, and then the policy has lost the one thing it is meant to achieve.

The objection is right about principles. But the principle "use approved tools" only moves the question. Someone still has to decide what is approved, with which connectors and which settings, and that decision ages just as fast whether it sits in the policy or in an annex.

So the policy can stand still. What cannot stand still is the list beneath it, and that list needs an owner who reads the vendor's change notices.

Which sentences in your AI policy can the vendor make untrue?

The criterion is a read-through of the policy you already have. Mark every sentence that names a product, a model, a data source or a setting. Next to each marked sentence, write whose change notices could make it untrue, and who in your organisation reads them.

The answers divide organisations. One that finds not a single marked sentence has a policy at the level of principle, and the decisions about tools and settings sit somewhere else. The question then is where, and who owns them. One that finds many marked sentences and can put a name to the reader next to each has a policy that can be kept true. One that finds many marked sentences but no names has a policy that describes the tools as they were on the day it was signed.

That is the difference between a policy and governance that runs: the policy says what applies, and the process with a named owner makes sure it still applies when the vendor has shipped the next version.