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, and 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, in an afternoon, without raising a ticket. Nobody rebelled. The capability simply appeared inside the licence.

So governance moved. Very little of the useful work is now philosophical, and most of it is a set of 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, and the answers live in admin consoles rather than in a framework.

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

The AI Omnibus amending the AI Act 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 — employment, education, essential services, law enforcement, migration, administration of justice — move to 2 December 2027. 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 that 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, and I would rather say I could not resolve it than pick the version that reads more confidently.

The wider point is not the dates themselves. It is that 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, so 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, which 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, and 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, not those built in the full studio. It is an allow-list of who may share, with no per-user block, so restricting a handful of people means pointing it at a group containing everyone else. It also applies to new sharing, which leaves anything already shared exactly where it is.

I am not a lawyer and this is not legal advice. What I can do is tell you what a setting actually does, what the vendor documentation says on a given date, and 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 and 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, and it is not the same thing as meeting a statutory obligation, and 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, 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, which 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 with 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, and 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, and you lose the visibility you were trying to gain.

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