Controls get framed as the thing slowing AI down. In the programmes that ship, they are the reason anything reaches production at all.
There is a standard argument in every organisation adopting AI. The delivery team wants to move; the risk team wants assurance; and both sides believe the other does not understand the urgency.
What is odd is that the evidence does not support the framing. Research consistently finds governance and data readiness gaps, rather than model quality, as the reason pilots fail to reach production. Governance is not what stops agents shipping. Its absence is.
Five layers, five questions
The clearest way I have found to structure this is as a set of questions somebody will eventually ask you, each with a Microsoft capability that answers it.
Working from the bottom, identity comes first because everything else depends on it. You cannot control what an agent can reach until the agent is a thing with a name. Access follows, then data, then behaviour, then the ability to evidence all of it to a regulator.
Most organisations have policy documents covering all five and technical implementation of one or two. The gap between the two is where the audit finding lives.
What Purview actually gives you
Purview gets described as a compliance tool, which undersells it and makes people put off looking at it. It is closer to the observability layer for AI use across the tenant.
| Capability | What it answers | Licensing level |
|---|---|---|
| Audit for Copilot and AI apps | What was asked, what was answered, which files were referenced | E3 and above |
| Data Lifecycle Management | How long Copilot and agent interactions are retained | E3 and above |
| eDiscovery | Can Copilot prompts and responses be placed on legal hold and searched | E3 and above |
| Sensitivity labels | Do agent outputs inherit the protection of their sources | E3 and above |
| Data Loss Prevention for Copilot | Can specific sensitive files be excluded from responses entirely | E5 |
| Insider Risk Management | Are there prompt injection attempts or risky AI usage patterns | E5 |
| DSPM for AI | Where is sensitive data being exposed through AI, and what should we fix first | E5 |
| Compliance Manager | Can we map controls to the EU AI Act and evidence our position | E5 |
The practical point is that much of this is available at E3, and most organisations running Copilot already hold the licences. The capability is frequently sitting unconfigured rather than unavailable, which is a much cheaper problem to fix.
The regulatory picture just moved.
If you built a compliance plan against the EU AI Act in 2025, some of it is now out of date. The Digital Omnibus on AI, adopted by Parliament in June 2026, substantially deferred the high-risk obligation.
The temptation is to read a delay as breathing room. I would read it differently. The deferral happened partly because national competent authorities and harmonised standards were not ready, not because the underlying expectations softened. The direction of travel is unchanged, and the destination is the same.
The practical implication for a UK or European organisation is that the classification work still needs to be done. Knowing which of your AI systems would fall into the high-risk category, and which fall under the Article 50 transparency obligations that apply from August 2026, is work you cannot start late.
For the practitioners
- DSPM for AI is the right starting point. It discovers AI usage across the tenant and offers one-click policies to address risky AI use and detect sensitive information shared with AI.
- Use Compliance Manager’s regulatory templates to map the AI Act into concrete controls rather than maintaining a parallel spreadsheet.
- Purview capabilities differ by AI surface. Copilot Studio agents support data classification and DLP, while some other surfaces do not. Check the support matrix for each surface you deploy rather than assuming uniform coverage.
- Prompts and responses are stored in the user’s mailbox, which is why eDiscovery works. It also means your mailbox retention policy governs AI interactions, whether you intended it or not.
- Insider Risk Management has a policy template for AI usage that addresses prompt injection attempts and access to protected material. Signals surface in Defender XDR.
How to make controls feel like acceleration
The reason governance feels like drag is usually sequencing. If controls arrive as a review gate at the end, they are a delay by construction. Everything is already built, and any finding means rework.
Move them to the front and the dynamic inverts. A team that knows on day one which data classifications are in scope, which connectors are approved, and what the evaluation threshold is can build against those constraints without stopping. The constraints are just requirements, and requirements known early are cheap.
It also settles the argument permanently, which is worth something in itself. Teams that have to relitigate what is allowed with every new agent spend more time in meetings than in build.
The UK position is different, and quieter.
UK organisations sometimes read the EU timeline and conclude none of it applies. That is half right in a way that can be expensive.
There is no UK equivalent of the AI Act. The approach has been to have existing sector regulators apply their existing powers to AI within their remits, which means the obligations are imposed by the regulator you already deal with rather than by a single new statute. For a financial services firm, that is the FCA and the existing rules on operational resilience, consumer outcomes and accountability. For anyone processing personal data, it is the ICO and the UK GDPR provisions on automated decision making and transparency. For an employer, it is employment law that has quite a lot to say about automated decisions affecting people.
The practical consequence is that the compliance question is not whether an AI-specific regime applies to you. It is whether your existing obligations are being met by systems that now make or influence decisions in ways your control framework did not anticipate. That question has been live for some time, and it does not have a commencement date.
And if you sell into the EU, the AI Act applies to you regardless of where you are based. A UK organisation placing an AI system on the EU market is in scope, which catches more businesses than expected.
The lightest thing that counts as governance
For an organisation with no AI governance at all, the gap between nothing and adequate is smaller than the framework diagrams suggest. Four artefacts get you most of the way, and none of them is long.
- An inventory. What AI systems and agents exist, what data each touches, and who owns it. This is the foundation for every other question, and you cannot borrow it from a template.
- A classification. Which of those are high consequence, meaning they affect customers, employment decisions, safety or money, and which are internal drafting aids. The controls follow from this split.
- A decision record. For each high consequence system: what it does, why the approach was chosen, what was tested, what the fallback is. This is the document an auditor or regulator will ask for, and writing it afterwards is obvious.
- A review cadence. Who looks at this, how often, and what triggers an out-of-cycle review? Quarterly is usually right, and a named person matters more than the frequency.
That is genuinely most of it at this stage of maturity. The elaborate frameworks have their place once you are operating at scale, but an organisation with fifteen agents and no inventory does not need a framework. It needs a list.
What to take away
- Governance gaps are a documented cause of pilots failing to reach production, not a tax on the ones that succeed.
- Please check what Purview capabilities you already own before buying anything. A lot of it is E3 and unconfigured.
- Recheck your EU AI Act plan. The Digital Omnibus moved the high-risk dates in 2026.
- Start with DSPM for AI to discover actual usage, then apply policy to what you find.
- Publish the constraints before the build starts. Controls at the front are requirements. Controls at the end are rework.
