Why AI and Data Governance Work Better Together

Over the last 18 months, many mid-sized organizations we have worked with have been standing up AI governance committees, usually soon after deciding to adopt Microsoft 365 Copilot and once business teams started asking about building their own Copilot agents. The pattern is familiar: 

• Legal or compliance wants a say in what an agent could read and say on the company’s behalf.  
• IT wants guardrails around what Copilot could surface from SharePoint, Teams, and email.  
• Leadership wants someone accountable if an agent says or does something it shouldn’t. 
• Infosec is worried about everything AI. 

So, a new committee gets formed, a charter gets drafted, and meetings get scheduled. Yay! 

Meanwhile, many of these same organizations already have some kind of data governance committee responsible for data classification, retention, access controls, DLP, and compliance with industry-specific regulations. Sometimes this group existed long before Copilot, and the data governance tool this team focused on was Purview. 

Often, the same core group of people is discussing similar risks and controls in two different committees with two different names. AI has pulled data governance forward, and there is a practical case for combining these efforts into one broader governance conversation. 

Make The Overlap Intentional

AI governance and data governance aren’t adjacent disciplines that happen to share a few stakeholders. Microsoft 365 Copilot doesn’t grant new access; it works within whatever permissions a user already has in SharePoint, Teams, and Exchange. The question of what Copilot can see and repeat is really the question of who has access to what, which is a data governance question that existed long before Copilot did. Agents follow the same model since an agent is only as safe as the data source and permissions it’s connected to.  

• What data can this model see? 
• Who can access the outputs? 
• How long do we retain prompts and responses?
• Does any of this require a policy update or compliance review?  

Again, this is a data governance question first, but an AI usage and adoption question at the same time. For a large enterprise with dedicated staff for each function, running AI governance and data governance as parallel, separate committees may be defensible because the environment, data, AI tools, and access levels are complex. For a mid-sized company, though, it is often duplicated effort, especially when there are now two places where a policy decision about the same underlying data can drift out of alignment. 

How This Usually Plays Out

Copilot Studio Agents & Overshared Data

Say a sales operations team builds a Copilot Studio agent to answer questions about customer contracts, using a SharePoint site as its knowledge source. The AI committee reviews the use case, likes the productivity ROI, and approves it. What nobody flags in that meeting is that the SharePoint site has been overshared for years. Half the company has some level of access, including files with pricing terms that were supposed to be restricted to the pricing team. The data governance committee should have caught that, because reviewing SharePoint site permissions is exactly the kind of thing they already do. But they were not in the room, because “a Copilot agent for customer contracts” did not sound like a data governance topic. It only becomes one once the agent is reading, and repeating whatever it finds there. 

Stale Data In Microsoft 365 Copilot

Or, consider a more mundane example, and one that exists in almost every organization that has turned on Microsoft 365 Copilot: stale data. A former employee’s old files, untouched for three years and still broadly accessible, suddenly become easy to find and reference in Copilot responses, producing outdated or incorrect answers. That is a data governance gap, including permissions that should have been revoked and retention that should have expired, made visible and urgent because Copilot made the content easier to find. 

In both cases, if the data governance committee is the one that owns access reviews, and the AI committee is the one that owns Copilot rollout, whose job was it to catch this? In a lot of organizations, the answer is nobody.  Each committee has a separate focus and this fell into the gap. 

I’m sure you can think of multiple similar examples in your own organization right now. They’re the predictable result of splitting one governance function into two committees that each only see half the picture, especially once agents start connecting to data sources on their own. 

Convergence Can Help

Merging, or at least tightly aligning, these committees is not about doing less governance. It is about removing the gaps where risk falls through and avoiding the same review twice: 

• A sensitivity label or retention decision made in the data governance meeting doesn’t automatically make it into the AI committee’s review of what a new agent can access unless someone manually carries it over. 
• Agent and Copilot risk reviews often duplicate work the data governance team already did when the underlying SharePoint site, Teams, or data source was first brought under governance. 
• Access reviews get evaluated once for “regular” systems and again, separately, for Copilot and agent-connected systems, even though it’s the exact same permission model doing the work in both cases. 
• Incident response gets slower, not faster, when a Copilot or agent-related data exposure has to be triaged by figuring out who needs to be involved before an investigation happens. 

When the same group owns both, a decision about sensitivity labels, retention, or access permissions gets evaluated once, with each Copilot rollout and new agent treated as another use case running through the same policy, not a parallel policy that has to be reconciled later. Financially, that also means one shared budget line, one legal or compliance resource supporting both functions, and one escalation path when something goes wrong. 

There’s also a cultural benefit here that is often unrecognized. When AI governance and data governance are visibly separate, business units learn to treat them as separate approval hurdles. That produces fertile territory for shadow agents, employees or departments spinning up their own Copilot Studio agents without going through either process, because the “real” approval felt too onerous. One governance body with a single intake process is simply easier to follow, which means people are more likely to actually use it before they build, not after. 

What If You Don’t Have A Data Governance Committee Yet?

Some mid-sized organizations have an alternate version of this problem. The organization pushes AI as a solution to business challenges and creates pressure to stand up an AI governance committee, but no data governance committee exists yet. Data governance was always on the back burner, so HR and finance managed access to their own tools, permissions in SharePoint and Teams grew without formal ownership, and no IT or business analysis team really understands the organization’s data flows and business processes. 

This is an opportunity to solve two problems. Stand up a single committee that owns AI and data governance together from day one. It fosters the right conversation from the start. Successful, secure AI adoption requires data governance as its foundation, not as an afterthought once something goes wrong. You cannot responsibly govern what Copilot or an agent can see and do without first knowing what data you have, where it lives, who can access it, and how sensitive it is. That is data governance work, whether or not you ever call it that. 

Microsoft Tools That Support Combined Governance

In practice, this is also the easier build, because the tooling most mid-sized Microsoft shops already have licenses for does double duty. Microsoft Purview gives you data classification, sensitivity labeling, and DLP policies a data governance program needs, and those same signals feed both Purview’s DSPM and Agent 365, giving the visibility into what Copilot and Copilot agents are actually touching. SharePoint Advanced Management adds site-level oversharing reports, lifecycle policies, and the ability to restrict or clean up broad permissions before an agent ever gets connected to a site that never should have been searchable by half the company in the first place.  

Standing up the combined committee around those tools plus Copilot, rather than treating them as IT projects running in the background, means the same group approving an AI use case is also the group that can see, and fix, the access problem underneath it. 

For a company in this position, the founding charter should be written as one document from the start: data classification and retention, access governance, DLP, and AI and agent approval, all owned by the same group and reviewed on a similar cadence. 

How To Approach This

A full committee merger is not a change you make overnight, and it isn’t the right move for every organization. A more realistic path: 

1. Assess the membership overlap. Review the membership of both committees and see how much they actually share. In most mid-sized companies, this is where the case gets made. Nobody needs much persuasion once they see the overlap. 

2. Align the charters before you align the meetings. Look at where the two charters already describe the same responsibilities in different terms (data classification vs. AI risk tiering, access reviews vs. AI tool approval) and consolidate the language. 

3. Keep (or add) the SMEs that Copilot and agent discussions need. Converging the committees doesn’t mean data governance absorbs AI governance in a vacuum. Model risk, technical review, and evaluating what a Copilot Studio agent is allowed to do autonomously are distinct skills that usually don’t sit on a traditional data governance team.  Tools like Microsoft Purview’s DSPM and Agent 365 exist specifically to give a converged committee visibility into agent activity that a traditional data governance review wouldn’t.  

4. Pilot, adjust, and address gaps accordingly. Pick one AI project or adoption initiative and combine the agendas. See how it works, gather feedback, and adjust before finalizing it as the new standard practice. 

One Size Fits Most

I am not suggesting this model works for every organization exactly as described, but the overall pattern is common in the organizations I have worked with. The main point is that AI governance and data governance are closely intertwined, and in most mid-sized organizations they function best as connected disciplines. AI tools create data governance and risk questions, which drives more data governance work. Better data governance then makes it easier to enable additional AI tools safely.  And so on. 

Unify Your AI Governance Strategy

Align AI oversight, data protection, and Copilot adoption with eGroup’s AI Operational Framework. Build a governance model with clearer ownership, consistent policies, and practical implementation guidance.