Everyone’s checking data readiness. Almost nobody’s checking orchestration readiness.

Ask most organisations how ready they are for AI and they’ll point to their data estate. Have we labelled our sensitive files. Is SharePoint locked down properly. Will Copilot expose something it shouldn’t. These are good questions, and increasingly, they’re the only questions being asked before an AI programme gets the green light.

They’re also not enough on their own. Data readiness tells you whether an AI tool can be trusted with the information already sitting in Microsoft 365. It says nothing about whether your agents can be trusted to act once they start reaching into the systems that data readiness never touched: the CRM, the finance platform, the ticketing system, HR. That’s a different question, and right now almost nobody is asking it early enough.

Why data readiness became the default question

It makes sense that data readiness is where attention lands first. Copilot is usually the first AI tool most people in an organisation actually use, and the risk is intuitive: an AI assistant with broad search access can surface a file that permissions were never quite tidy enough to protect.

Microsoft has built a genuinely capable answer to this in Purview Data Security Posture Management for AI. It:

• runs regular assessments against SharePoint and OneDrive content that Copilot can reach, and flags overshared or unlabelled files
• as of 2026, lets an administrator remediate a flagged item directly: apply a label, notify the owner, or pull the sharing link
• logs AI interactions involving sensitive information, for audit
• can block or warn before someone shares regulated data with an AI tool in the first place

For a security team scoping their first AI risk assessment, this is the natural starting point, and it should be. It’s also, for most organisations, the extent of the assessment. The workshop gets booked, the SharePoint sites get reviewed, the sensitivity labels get applied, and the programme moves forward on the assumption that the hard governance problem has been solved.

It hasn’t. It’s been solved for one layer.

The layer nobody’s checking

Data readiness governs what an AI tool can see. It says nothing about what an agent can do once it’s been authorised to act, particularly once that action reaches beyond the Microsoft 365 boundary Purview was built to watch.

Think about where the genuinely useful agentic use cases actually live.

• An agent that updates a CRM record after a call.
• One that checks stock across a logistics platform and raises a purchase order.
• One that pulls payroll status from one system and case history from another before answering an HR query.

None of that activity touches SharePoint or OneDrive in a way Purview assesses. The moment an agent’s job spans more than one system, and increasingly it does, you’re outside the boundary the entire data readiness conversation was built around.

This is orchestration readiness, and it asks a different set of questions.

• Does the agent hold credentials it shouldn’t?
• Is its access scoped to what its role actually needs, or to whatever the person who built it happened to grant?
• Can you trace, after the fact, exactly why an agent took the action it took, not just that it accessed a file?

Those are architecture questions, not data hygiene questions, and they don’t get answered by a SharePoint assessment no matter how thorough.

Why this gets missed

Three reasons, consistently.

The tools people already use only see one layer. Purview lives inside Microsoft 365 admin, so it’s the natural first place to look, and it does its job well within that scope. But a tool assessing SharePoint permissions was never going to flag a gap in how an orchestration platform handles agent credentials, because that isn’t what it’s for.

Multi-agent orchestration is newer and less familiar territory for most security partners. A traditional data security review, however good, is built around a well-understood discipline: classification, labelling, access control on stored content. Governing what an autonomous agent decides to do across five systems in a single interaction is a genuinely newer problem, and it’s reasonable that not every security team has deep experience assessing it yet.

The early wins reinforce the wrong lesson. Most organisations start their AI programme with contained, single-system use cases: a Copilot rollout, a document summariser, something that lives entirely inside the boundary Purview already covers. It works. Nothing goes wrong. That success quietly teaches the organisation that data readiness was the whole job. Then the second wave of use cases, the ones that actually justify the investment, need an agent to act across systems, and the governance model that worked for wave one has nothing to say about wave two.

Where the gap tends to bite

This is one of the most common reasons AI programmes stall after a promising start. Early quick wins land, confidence builds, budget gets approved for the next phase, and then someone asks the obvious question: what happens when the agent needs to act on a system that isn’t Microsoft’s. If nobody’s designed for that, the programme either stops to retrofit governance it should have built in from the start, or worse, it proceeds without it.

Microsoft has clearly recognised this gap exists. At Ignite 2025 it announced Agent 365, a platform for giving organisations visibility into every agent running across their estate: what it can access, what it’s connected to, and how it’s behaving, sitting alongside Purview, Defender and Entra in the M365 admin experience. It’s an early-stage product and worth watching, but it signals something worth noting on its own: even Microsoft is treating agent-level governance as a distinct problem from data-level governance, not a natural extension of it.

Purpose-built orchestration platforms, OneReach GSX among them, have approached this from the other direction from the start:

• credentials for third-party systems held in isolated flows and never exposed to the agent itself
• access modelled on organisational role rather than document label
• audit trails that capture the reasoning behind a decision, not just which file was touched

The actual question to ask

Not “is our data ready for AI”. Most organisations can answer that reasonably well already, and the tooling to close remaining gaps is mature and well understood.

The better question is: for every use case on our roadmap, not just the ones running now, what layer does the governance need to sit at?

If the answer for every case is “inside Microsoft 365”, data readiness genuinely is the whole job, and there’s no need to overbuild for a problem that doesn’t exist yet. If any case on that roadmap involves an agent acting across systems, and for most organisations at least one does, orchestration readiness needs to be part of the design from the start, not bolted on once the first cross-system agent is already misbehaving in production.

Data readiness and orchestration readiness aren’t sequential stages where one is solved before the other begins. They’re two different layers of the same governance problem, and a programme that’s only checked one of them is only half assessed.