Picture this: your company buys 50 Microsoft 365 Copilot licenses. The rollout goes smoothly. People are summarizing meetings and drafting proposals within a week. Then someone asks Copilot about "compensation planning" and gets back a summary of a spreadsheet with everyone's salary in it — a file that has been sitting in a SharePoint site shared with the whole company since 2021.
Copilot didn't bypass your security. Microsoft is explicit that Copilot only surfaces organizational data that the individual user already has at least view permission to. That salary file was always visible to every employee. It just took years of clicking through folders to find it, and now it takes one question. Copilot doesn't grant anyone access they didn't already have — what it changes is how easy overshared information is to discover. The permissions problem existed long before the AI did. The AI simply made it impossible to ignore.
AI doesn't create your data problems. It removes the obscurity that was hiding them.
That's what happens when companies buy AI before preparing their data. Here are the five things to fix first — whether you're rolling out Copilot, building agents on your own data, or just trying to get a handle on the AI tools your employees are already using.
1. AI doesn't fix broken data governance
Most Microsoft 365 tenants have years of accumulated oversharing. Sites created with "Everyone except external users" access. Sharing links set to "People in your organization" because it was the default. Folders that inherited permissions from a parent site nobody has reviewed since a reorganization. Teams created for a project that ended three years ago, with every file still in place. None of that was a crisis when finding a document meant knowing where to look. It becomes one when an assistant can search all of it on a user's behalf.
Fixing this is unglamorous, and it's the most important part of the project. Start by finding the broad-access sites and links — Microsoft's Copilot oversharing blueprint and SharePoint Advanced Management's data access governance reports are built for exactly this. Then classify what matters most: apply sensitivity labels to HR, finance, legal, and regulated content, and use Microsoft Purview data loss prevention to keep the most sensitive labeled content out of AI responses. Assign a real owner to every site, and archive or delete what nobody owns.
If you need to start before the cleanup is finished, Restricted Content Discovery can hide specific sites from Copilot and organization-wide search while you work. But be clear about what it is: a temporary discoverability control, not a security boundary. It doesn't change anyone's permissions, and people who have access can still open those files directly. It also has limits — it applies only to SharePoint sites, not OneDrive, and it doesn't affect searches run from inside the site itself, experiences like the Microsoft 365 Feed, or Copilot working on a document a user already has open. It's a stopgap that buys time, not a fix. (The older Restricted SharePoint Search setting is being retired, so don't build a plan around it.)
2. Your identity and access controls matter more than your prompts
An AI assistant acts with the permissions of the person using it. That makes every account a much more powerful key than it used to be. A compromised mailbox used to mean an attacker could read one person's email; with an assistant attached, it means they can ask that account to summarize everything it can reach. So the controls that were always good practice in Microsoft Entra ID become essential: MFA for every user, preferably phishing-resistant for administrators; Conditional Access policies that require managed or compliant devices for sensitive data; and least privilege, so people have access to what their job needs rather than what was convenient to grant.
Administrative access deserves its own attention. Standing global admin rights are a risk with or without AI; Privileged Identity Management lets admins activate elevated roles only when they need them, with approval and an audit trail. Pair that with periodic access reviews for groups and guest accounts, and you've closed most of the paths by which an AI assistant could surface something it shouldn't. None of this is new. AI just raised the cost of skipping it.
3. Compliance doesn't disappear when AI enters the picture
Not every AI deployment has to satisfy every regulatory framework. But the frameworks that already apply to your data still apply once an AI tool can read it. If you handle patient information, HIPAA's rules about who can access PHI, and the Business Associate Agreements that cover your vendors, extend to any AI service that processes it — confirm the specific service is in scope of your agreement before anyone pastes a chart note into it. We covered the underlying requirements in what HIPAA-compliant software architecture actually requires.
Defense contractors face a similar question with Controlled Unclassified Information. If CMMC applies to you, CUI has to stay inside the environment you've scoped and assessed — which often means a government cloud such as GCC High — and AI features don't always arrive in those environments at the same time or in the same form as in commercial Microsoft 365. Verify that the AI service you're planning around is actually available and authorized in your environment before you build a rollout plan on it.
And for everyone, regulated or not, there's shadow AI: employees pasting customer data, contracts, or source code into consumer chatbots because the approved tool doesn't exist yet. Blocking everything rarely works. A short acceptable-use policy, an approved option that's genuinely useful, and data loss prevention on the paths that matter work much better.
4. A successful pilot isn't a production architecture
AI pilots are designed to succeed. A small group of enthusiastic users, a handful of curated sites, a few weeks of attention from IT. Production is different. It means every employee, every site, every permission mistake, and nobody paying close attention after the first month. It's the same gap we see between a working AI prototype and a production system — the demo proves the idea, not the operations.
Before you scale, decide how you'll monitor it. Microsoft Purview can audit AI interactions, flag sensitive information in prompts and responses through Data Security Posture Management for AI, and apply retention to them. Some of those capabilities depend on your licensing, audit configuration, and collection policies, so don't assume every tenant has them available or turned on by default — and none of them help unless someone actually reviews what they find. Decide how you'll handle integrations, too: agents and connectors that pull in data from outside Microsoft 365 widen what the assistant can reach, and every one of them needs the same permission review as a SharePoint site. Track license usage so you're not paying for seats nobody opens. And name an owner — a specific person or team responsible for the AI platform after launch, not a project that ends when the pilot does.
A pilot proves people like the tool. Production proves you can run it safely when nobody is watching closely anymore.
5. What a real AI readiness assessment should include
An AI readiness assessment shouldn't be a slide deck about use cases. It should be a technical review of the foundation the AI will sit on, with a prioritized list of what to fix before licenses go live — and what can wait.
AI readiness checklist
- Identity — MFA for every user, Conditional Access for sensitive data, and no standing global admin accounts.
- Oversharing — a report of sites, groups, and links with organization-wide or broad access, and a plan to fix them.
- Site ownership — a named owner for every active site and team, and a cleanup plan for abandoned ones.
- Sensitive data — sensitivity labels on HR, finance, legal, and regulated content, with DLP policies that apply to AI.
- Compliance scope — which frameworks apply (HIPAA, CMMC, others), and whether the AI service is covered and available in your environment.
- Acceptable use — a short, clear policy on which AI tools are approved and what data can go into them.
- Monitoring — AI interaction auditing turned on, with someone assigned to review it.
- Integrations — an inventory of agents and connectors, with the same permission review as any other data source.
- Ownership and cost — a named owner for the AI platform after launch, and a way to track whether licenses are actually used.
Most organizations won't pass every line on the first review, and that's fine. The point is to know which gaps are dangerous before the rollout, which ones you can fix in parallel with a limited pilot, and which ones can wait.
Where this leaves you
The companies that get real value from AI aren't the ones that bought licenses first. They're the ones that treated AI as a reason to fix the identity, permissions, and data governance problems they had been living with for years. That work isn't exciting, and it doesn't make a good demo. But it's what determines whether your AI assistant becomes your most productive employee or your most efficient data leak.
Don't mistake buying AI licenses for being ready to deploy AI.