When Does a Software Update Become an AI Governance Event?

What happens when the software changes, but nothing inside the organisation triggers another look?

By Louize Clark

Something changed inside three of the world's most widely used business platforms this year. In most organisations, it didn't arrive through procurement, a business case or a signature. It arrived through an update.

I want to look at what happened to three products almost everyone reading this either uses or sits somewhere near Microsoft 365 Copilot, Google Workspace and HubSpot, because when you put them next to each other, I think they change the question worth asking.

Not: what AI have we adopted? That question still has a comfortable answer in many organisations. We haven't bought anything new. We haven't signed another contract. We haven't approved another AI tool. The more useful question is: what has the AI we already adopted become?

What actually happened

Take Microsoft first, because its story is probably the clearest. On 22 April, Microsoft made Copilot's new agentic capabilities generally available in Word, Excel and PowerPoint, turning them into the default experience for eligible Copilot customers. Microsoft's own description is that Copilot can now "take multi-step, app-native actions directly in your documents, worksheets, and presentations" in other words, it's moved beyond suggesting what you might do and towards actually doing parts of the work.

For customers already holding an eligible subscription, no new product needed to be procured to get there. The line on the licence didn't change. What that line denotes did.

Google's version of the same shift took longer, and it started from a more cautious position worth saying plainly rather than smoothing over for a tidier story. Workspace Studio, Google's no-code way of building agents inside Workspace, reached general availability in December last year and had rolled out fully across Google's release channels by March. At that point there were meaningful limits to what it could do: it could draft an email, for example, but not send one autonomously. Google's announcements at Cloud Next in April built on that foundation rather than suddenly creating it.

The more interesting development came later. On 17 August, Google introduced new architecture for Workspace Studio agent identities, access management, audit trails and human-in-the-loop controls. The reason for building those things matters as much as the controls themselves: a tool that once helped an individual create something was increasingly being given the means to act across a wider working environment. A Google security post the following week described its agent flows in a phrase worth sitting with they can carry "the context, authority, and privileges to act on a user's behalf." That's quite a change in the relationship. The AI is no longer only generating something for you to consider; increasingly, it can be given limited authority to do something for you.

HubSpot's version is quieter still, and in some ways I find it the most revealing of the three, because the change wasn't really something a user would see at all. In January, HubSpot changed the underlying model used by a number of Breeze Studio agents from GPT-4.1 to GPT-5, covering named Marketplace agents as well as eligible custom agents customers had already built. No customer action was required for those existing agents to be upgraded. HubSpot did not move every agent its Customer, Prospecting and Data agents were explicitly excluded, which in itself tells us something: the company had made a judgement about where it was prepared to change the underlying model and where it wasn't.

But think about this from the customer's side. You build an agent for a particular purpose. You test it. Your team learns its habits, its strengths, the places where they know to check it and over time, they develop confidence in how it behaves. Then the reasoning model underneath it changes. Same agent. Same interface. Same place in the workflow. Different reasoning happening inside it.

Three different companies, three different products, but one broad direction: away from AI simply suggesting something to a person and towards AI taking actions with varying degrees of authority on their behalf. And in each case, the change arrived through an ordinary product channel rather than an organisational decision to adopt something new.

The word we keep reaching for doesn't cover this

When a board asks, "Has anything changed?", the instinct is still to answer through procurement. Did we buy anything new? Did we sign anything? Has another AI product been approved? For Copilot, Workspace and Breeze, many organisations can answer those questions quite honestly with no and that answer feels complete, because "adoption" has traditionally meant a decision with a date attached to it. Someone evaluated something. Someone approved it. Someone bought it.

That's precisely why I've stopped using the word on its own. In the briefings and workshops I run, I use four words instead: Chosen. Inherited. Introduced. Unknown.

Chosen is the version everyone pictures when they hear "AI adoption" someone evaluated it, signed for it, and hopefully thought about what using it would mean. It has an owner and a paper trail.

Inherited is different. The capability arrives inside something the organisation already has — through a product update, a change in an existing subscription, or the evolution of a platform already sitting inside the business. It doesn't necessarily begin as a business request at all.

Introduced is the one organisations already worry about: someone finds a tool, signs up and starts using it on their own initiative. Perhaps nobody else knows.

And then there's Unknown the honest one. It's the answer, "We genuinely can't say how that got here," and I'd rather an organisation gave me that than a confident wrong one, because at least it gives us somewhere truthful to start.

Inherited isn't one thing

The more I've looked at this, the more I think there's another distinction worth making. It would be convenient if inherited AI simply meant a vendor had added a feature to software you already owned we could probably build a reasonably straightforward process around that. But that isn't quite what's happening. Inheritance is beginning to occur at several different levels inside the same product.

You can inherit a capability Copilot becoming able to carry out a multi-step task rather than simply propose one is a clear example.

You can inherit a change in reasoning the Breeze Studio agent you built for one purpose can end up thinking with a different underlying model from the one you originally tested it against.

You can inherit a change in authority Workspace Studio can move from drafting something for you towards operating, within defined controls, with authority to act on your behalf.

And you can inherit a change in where and how your data is processed, without anything you'd recognise as a new AI system arriving at all.

That last one is worth making concrete, because I think it shows the whole problem in miniature.

Microsoft allows administrators to control whether Anthropic's models can be used inside Copilot experiences in Word, Excel and PowerPoint. For UK, EU and EFTA tenants created after 25 March this year, Microsoft's app-specific setting for those experiences is switched on by default. For older tenants, Microsoft's own guidance directs administrators to the Message Centre to establish their default position. When Anthropic's models are used in those experiences, the processing for those interactions takes place outside Microsoft's EU Data Boundary.

Sit with what that means for a moment. An organisation can say, entirely honestly, "We haven't bought a new AI system this year." And yet, within the product it already owns, the capability can have become more agentic, a different model provider can now be doing some of the reasoning, that provider can involve different processing conditions, and the setting governing all of it can sit with an AI Administrator inside a console the person responsible for organisational risk may never have opened. Nobody adopted a separate AI product. Nothing was "chosen" in the sense that word usually carries. And yet the organisation's position technically, operationally and in data protection terms has moved.

That's the structural gap at the heart of this. It isn't that the controls don't exist they do, and in many cases they're more granular than people probably assume. The problem is that where the switch sits and where the accountability sits can be two entirely different places, and nothing automatically guarantees that the people in those two places are having the same conversation.

Why the old triggers don't fire

Most governance processes are built around events: a contract renewal, a procurement request, a new project, a change request going to a board. Someone proposes something, and because they've proposed it, the organisation gets a chance to ask questions what is it, why do we need it, what could go wrong.

But what happens when nobody proposes anything? There was no separate procurement request for the new capabilities inside Copilot, because the organisation already held the relevant entitlement. Nobody inside the business had to submit a request asking HubSpot to change the reasoning model beneath an existing Breeze agent. And the development of Workspace Studio didn't depend on anyone inside a customer organisation deciding its agents should become more capable.

Where an organisation's impact-assessment process is triggered by a new procurement, project or proposed use case, there may simply have been nothing obvious to trigger it. That isn't an accusation that somebody failed to do their job it's a different problem: governance designed to detect one kind of event, encountering technological change that increasingly doesn't produce one.

None of this means anyone deliberately hid the change from you. The information may well be sitting in a release note, an administrator's documentation, a Message Centre notice or a configuration panel somewhere. But the mechanism by which it reached the organisation was never designed to make sure the person accountable for its consequences was the person who saw it.

What this looks like from inside a team

Imagine someone who has used Copilot to help draft board papers for two years. They know its habits where it over-explains, where it sometimes gets a figure wrong, which parts they need to double-check. Without necessarily realising it, they've developed a working relationship with the system.

Earlier in that relationship, Copilot suggested and they reviewed. As the capability changes, that relationship changes too. The same tool can increasingly draft, format and manipulate information inside the application itself, and the person's role begins to move from creating the work with assistance towards supervising work the system has already performed.

There may never have been a meeting where somebody decided that should happen, and there may never even have been a moment when the employee noticed the boundary moving. But it moved.

Multiply that across a department and you have a genuinely different working relationship with the same named product. Multiply it across several platforms and you begin to see why an inventory of "AI tools we have approved" can be completely accurate and still fail to describe the AI environment people are actually working inside.

The question worth asking this week

I'm not arguing that any of this should have been stopped. Removing friction from useful AI capability has produced real gains, Microsoft, Google and HubSpot are each responding to genuine customer demand, and expecting organisations to run a procurement exercise every time software improves would be absurd. The real question is whether an organisation can currently tell what has changed inside the platforms it already runs.

Is your Copilot licence still doing, in practice, what it was doing when somebody last reviewed it? Has anyone looked at what your Workspace agents can do now, rather than what they could do when they first appeared? If a Breeze agent your team built started reasoning slightly differently because the model underneath it changed, would anyone know why?

For many organisations I've asked directly, the honest answer to at least one of those questions is, "We don't actually know." I don't think that's a failure it's the predictable result of watching for the wrong kind of event. And recording "we don't know" honestly is itself a finding. It's a considerably more useful starting point than a confident answer that later turns out to describe the software you had six months ago rather than the software you have today.

Nobody reasonably expects a board to approve every software update. But when an update changes what an AI can do, whose authority it can exercise, which model is doing the reasoning, or where data may now be processed, calling it merely an update starts to feel inadequate. There's a boundary somewhere between an ordinary software release and a governance event. Most organisations haven't yet said where it sits.

The software didn't wait for another procurement decision. Perhaps the question for organisations now is whether their governance still needs one before it looks again.

AI Policies UK helps organisations see the AI infrastructure they're already standing on, chosen, inherited and embedded — before decisions like this one have to be made under pressure. Get in touch: louize@aipolicies.uk