Governing AI inside a corporate organisation

Most AI governance documents assume a shape of organisation that no longer exists. Somebody proposes a system. A committee reviews it. A technical team builds it. The review happens once, at the start, in a room.

That shape broke when the build button arrived inside the productivity suite everyone already had. A person in finance can now assemble something that reads company documents and answers questions about them. It takes an afternoon and no ticket. Nobody rebelled. The capability simply appeared inside the licence.

So governance moved. Very little of the useful work is now philosophical. Most of it is specific decisions with specific settings behind them. Who may build. Who may only use. What a thing is allowed to reach. What happens to it when its owner leaves. Those have real answers. The answers live in admin consoles, not in a framework.

If your AI Act plan says high-risk obligations apply from 2 August 2026, it is out of date. It went out of date very recently.

The AI Omnibus amends the AI Act. It was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744. It defers the high-risk obligations. Stand-alone systems in the Annex III categories move to 2 December 2027. Those categories are employment, education, essential services, law enforcement, migration and administration of justice. AI embedded in products already covered by Union harmonisation legislation moves to 2 August 2028.

What did not move matters just as much, because the relief is narrower than the headlines suggest. The prohibitions and the AI literacy duty keep their original February 2025 date. The general-purpose model transparency obligations keep August 2025. The Act's general application still arrived on 2 August 2026. And the Omnibus adds a new prohibition concerning child sexual abuse material and intimate imagery. It applies from 2 December 2026, so it is not purely a delay.

I will flag one thing I could not settle. Sources disagree on whether the Omnibus entered into force on the day of publication or three days later. It makes no practical difference to any plan. I would rather say I could not resolve it than pick the version that reads more confidently.

The wider point goes beyond the dates themselves. This area rewrites itself faster than the advice about it gets updated. So anything you are handed should carry a date and a source you can check.

The question almost every large organisation reaches is the same. We want everyone to use agents. We want a much smaller group to build them. How do we do that?

The obvious control does not do it. The blunt tenant switch that looks like it governs agent creation is coupled to consumption. Turning it off takes away the ability to use agents as well, including the ones the vendor ships. Organisations discover this after they flip it, usually loudly.

The separation exists, but it lives somewhere less obvious. Agents built with the lightweight in-suite builder are saved into a Power Platform environment. That means the environment and its security roles are where creation is actually governed. Grant the create permissions to a named group in the relevant environment. Route the builder there, and leave consumption switched on for everyone. That produces the split people wanted. It is invisible from the admin page they were looking at.

Sharing is a separate control again, and a narrower one than it appears. The tenant sharing setting governs only agents made with the in-suite builder. It does not cover those built in the full studio. It is an allow-list of who may share, with no per-user block. Restricting a handful of people means pointing it at a group containing everyone else. It also applies to new sharing. Anything already shared stays exactly where it is.

Every agent in an organisation passes through the same four gates. Writing them down in this order tends to end the circular meetings. Each one has an owner and a setting rather than an opinion.

• Build. Who may create an agent at all, as distinct from using one. This is an environment and a security role, not a policy paragraph. It is the gate people most often think they have closed when they have not.
• Share. Who may publish an agent to other people. It is separate from building and governed by a different control. Decide it before someone shares a useful thing with the whole company.
• Reach. What the agent can see and what it can do. Reading company documents, calling an external system and searching the public web are three very different risk decisions. They get made as one.
• Retire. How an agent gets stopped. Everyone has a way to create agents. Almost no one has a way to end them. So agents whose owner left last year still answer questions.

The reach gate deserves its own attention. The most consequential setting in this whole area is easy to turn on and hard to see the effect of.

Let an agent search the public web and part of the prompt leaves your boundary. It goes to a search service outside your compliance and geographic limits. The data protection terms that cover the platform do not cover that hop. It also ignores the private networking you paid for. If you chose a region on purpose, understand this one setting before you switch it on, not after.

Where inference happens is a related decision made at deployment time and rarely revisited. The choice of deployment type determines whether processing can occur anywhere, within a defined multi-country zone, or only in the region you selected. For a UK organisation this is sharper than it looks. The UK sits outside the European data boundary, so a zone-level commitment is not a UK commitment.

The same question applies to any connector that queries a third-party system at the moment of the prompt. It does not index the contents in advance. A live query means something derived from the prompt leaves under that provider's terms. Whether that is acceptable is a decision worth making per connector. Make it with the terms in front of you.

I am not a lawyer and this is not legal advice. I can tell you what a setting actually does, and what the vendor documentation says on a given date. I can also show where a control stops short of what people assume it covers. Where an obligation turns on a legal judgement about your specific use, that is a question for counsel. I will say so rather than guess.

I will not tell you that a governance framework makes you compliant. Adopting a management standard is a real and useful discipline. It is not the same thing as meeting a statutory obligation. The two get conflated in sales conversations constantly.

I will also not pretend the tooling can carry decisions it cannot carry. The controls above govern who may do what. None of them decide whether an agent should exist. None of them decide whether its answers are good, or whether the process it automates was sensible. Those remain judgements made by people who can be held to them.

I start by finding out what already exists, because the answer is never zero. Somebody has built something. Usually several people have, and usually it is genuinely useful. That is why heavy-handedness at this point costs you the goodwill you are about to need.

Then the four gates, one at a time. Each has a named owner and the actual setting written down next to it. A governance decision that does not resolve to a configuration is an aspiration. Aspirations do not survive contact with a busy quarter.

I try hard to make the permitted path easier than the unofficial one. Governance that only forbids gets routed around by capable people under pressure. Then you lose the visibility you were trying to gain.

And I write down what was decided and why. I use language your risk and audit people already use. The next person then does not have to reconstruct it from the settings.