Building an Agentic Center of Excellence: Do We Really Need Another CoE?

Microsoft recently published guidance on building an Agentic Center of Excellence (CoE) as organizations move from experimenting with AI agents to deploying them more broadly across the enterprise.

As organizations move beyond copilots and begin deploying agents that can reason, orchestrate tools, and participate in business processes, many are asking whether they need an Agentic CoE. The bigger question may not be whether we need another CoE, but whether our existing CoE model is ready for a world where AI does more than assist people.

When I first went through the guidance, one question immediately came to mind:

Do we really need another CoE?

Many large organizations already have Centers of Excellence around Cloud, Microsoft 365, Power Platform, Security, Data and AI. More recently, Copilot has also become part of the CoE conversation.

Having worked with an M365 CoE model, where we incubated new requirements and projects, brought together stakeholders across technology and business teams, evaluated emerging capabilities, and more recently focused heavily on Copilot evaluation and adoption, much of the Agentic CoE concept initially felt familiar.

But there is an important difference.

The fundamentals of a good CoE haven't changed.

What is changing is the autonomy, reach and responsibility of the technology being introduced into business processes.

Unlike traditional applications, agents can reason over information, invoke tools, interact with systems and potentially perform actions on behalf of users. As a result, governance, ownership and operational oversight become significantly more important.

What Does an Agentic CoE Actually Do?

Microsoft describes the Agentic CoE around four core functions:

Govern → Enable → Optimize → Scale

The objective is to help organizations move from isolated agent experiments toward a repeatable enterprise capability.

That means bringing together stakeholders across business, technology, architecture, security, data, Responsible AI, and platform teams rather than allowing every agent initiative to develop independently.

This part isn't necessarily new.

A mature M365 CoE already works across organizational boundaries.

When a new capability comes in, the job isn't simply to enable a feature. We first need to understand the requirement, identify the business value, evaluate the technology, involve the right stakeholders and determine how it fits into the wider enterprise environment.

Copilot reinforced that approach.

Agents take that evolution one step further.

From M365 CoE to Agentic CoE

In an M365 CoE, a typical incubation might start with:

Business requirement → Technology evaluation → Stakeholder alignment → Architecture → Pilot → Enterprise implementation

The CoE provides a place where something new can be evaluated before it becomes another enterprise service or capability.

That model worked well when evaluating capabilities such as Microsoft 365 Copilot.

But consider what happens when the requirement changes from:

"Can Copilot help our employees find and summarize information?"

to:

"Can an agent perform part of this business process for us?"

The conversation immediately becomes broader.

Consider an employee onboarding scenario.

A Copilot might help a manager summarize onboarding guidance, locate documentation, or answer questions about the onboarding process.

An agent, however, could coordinate the process itself by requesting accounts, initiating equipment provisioning, assigning mandatory training, updating HR systems, and tracking completion status across multiple platforms.

The conversation immediately moves from productivity assistance to business process execution.

That is where governance, architecture, security, lifecycle management, and operational accountability become significantly more important.

An agent might retrieve information, reason across different sources, invoke tools, communicate with other agents or systems and potentially perform actions as part of a business process.

So while the CoE model remains familiar, the scope of the technology being incubated is changing considerably.

What Changes When We Move to Agents?

This distinction is important.

A Copilot-focused CoE is largely about enabling people to work more effectively with AI.

The human remains at the center:

Human → Copilot → Better outcome

An Agentic CoE needs to consider scenarios where agents participate more directly in accomplishing the outcome:

Human → Agent → Tools / Systems / Data → Outcome

And increasingly:

Agent → Agent → Tools / Systems → Outcome

That doesn't mean humans disappear from the process.

It means we need to start thinking about where humans need to remain involved and where agents can take on parts of the work themselves.

That is a meaningful evolution from the Copilot conversation.

What About an Existing AI CoE?

This raises another obvious question.

If an organization already has an AI CoE, why establish an Agentic CoE?

I don't think the answer should automatically be to create another organizational structure.

An AI CoE may already cover AI strategy, architecture, Responsible AI, data, models and enterprise AI standards.

Similarly, an M365 or Power Platform CoE may already provide platform expertise, incubation and stakeholder engagement.

The Agentic CoE can build on these capabilities.

What it introduces is a stronger focus on agents as participants in business processes.

That includes understanding how agents are designed, where they operate, how they interact with enterprise platforms and how multiple agent capabilities can be scaled across the organization.

So I would see the relationship more like this:

AI CoE
Enterprise AI strategy and standards

↓

M365 / Power Platform / Application Platforms
Platforms where AI experiences and agents are delivered

↓

Agentic CoE
A repeatable model for turning agent opportunities into enterprise capabilities

These don't necessarily have to be three different teams.

They can be different capabilities within the organization's wider technology operating model.

Don't Start by Creating Another Team

This is probably the part of Microsoft's guidance that resonates most with me.

An Agentic CoE doesn't have to mean creating a new department with another organizational chart.

Microsoft describes different operating models including centralized, hybrid and federated approaches.

That matters because every organization starts from a different level of maturity.

For an organization just beginning its agent journey, a small centralized team may make sense. Expertise is scarce and concentrating it helps establish patterns and reusable approaches.

As adoption grows, a hybrid model becomes more practical.

The central CoE provides expertise and common patterns while business and technology teams start building solutions closer to their own domains.

Eventually, mature organizations may operate in a more federated way, where individual teams can deliver agents while the CoE focuses more on shared capabilities, guidance and enterprise alignment.

That evolution feels very similar to what many of us have already seen with cloud, Microsoft 365 and Power Platform.

The technology changes.

The CoE matures with it.

The CoE Should Help Decide Whether You Even Need an Agent

One area I think will become increasingly important is technology choice.

Not every business requirement needs an AI agent.

Sometimes a Power Automate flow is enough.

Sometimes a traditional application is the better solution.

Sometimes Microsoft 365 Copilot already provides what the user needs.

Sometimes a Copilot Studio agent is appropriate.

And some requirements may justify a more sophisticated agent built using Microsoft Foundry or other development frameworks.

A good Agentic CoE shouldn't exist simply to create more agents.

It should help answer:

What problem are we trying to solve, and is an agent actually the right solution?

That is exactly the kind of conversation a CoE should facilitate.

Otherwise, "agent" risks becoming another technology label attached to every new requirement.

From Projects to Reusable Agent Capabilities

Another interesting aspect of the Agentic CoE model is the opportunity to avoid rebuilding the same capability repeatedly.

Imagine several business units independently needing agents that:

• access similar enterprise knowledge

• interact with the same internal systems

• perform similar employee-support activities

• connect to common services

• use the same enterprise capabilities

Without a CoE approach, each project could solve those problems independently.

A CoE can identify common patterns and reusable capabilities that make the next implementation faster.

This is where the value starts moving beyond individual agent projects.

Instead of:

Requirement → Build Agent → Finish Project

the model becomes:

Requirement → Evaluate → Build → Learn → Reuse → Scale

Over time, the organization builds an agent capability, rather than simply accumulating individual agents.

Agents Should Be Treated More Like Products Than Experiments

This is another part of Microsoft's guidance that I think is particularly important.

Early AI initiatives naturally start as experiments.

We try something.

We evaluate the output.

We demonstrate the capability.

And then we move to the next use case.

That approach doesn't work once agents become part of real business processes.

An enterprise agent needs an ongoing purpose and ownership. The underlying business process can change. The systems it interacts with can change. New capabilities become available.

That means the mindset needs to move from:

"We built an agent."

to:

"We operate an agent capability."

Agents should be treated more like products than projects. They need defined owners, success metrics, lifecycle management, support models, performance monitoring and continuous improvement roadmaps. As business processes evolve and underlying systems change, agents must evolve as well.

This is one of the biggest mindset shifts organizations will need to make as they move from experimentation to enterprise-scale adoption.

For anyone coming from a service or product operating model, this is a familiar transition.

The technology might be new.

The need for clear ownership and continuous improvement isn't.

Where I See the Agentic CoE Fitting

Looking at Microsoft's framework through my own experience with an M365 CoE, I don't see Agentic CoE as replacing what organizations already have.

I see it as an evolution.

An M365 CoE helped us evaluate and incubate new platform capabilities.

Copilot expanded that conversation into AI-assisted work.

Agents now extend it further into AI participating in the execution of work.

That progression can be thought of simply as:

Traditional Technology

Applications help people perform work.

↓

Copilot

AI helps people perform work.

↓

Agents

AI can participate in performing the work.

↓

Agentic Organization

People and agents increasingly work together across business processes.

And somewhere between those stages, organizations need a mechanism to decide what to build, bring the right stakeholders together, establish repeatable patterns and turn experimentation into an enterprise capability.

That is where I think the Agentic Center of Excellence fits.

Final Thoughts

After going through Microsoft's Agentic CoE guidance, I don't think the most useful question is:

"Should we create another CoE?"

A better question is:

"Is our existing CoE model ready for agents?"

For organizations that already have mature Microsoft 365, Power Platform or AI Centers of Excellence, the answer may not be another standalone team. It may simply be the next evolution of capabilities that already exist.

The experience gained from governing cloud platforms, incubating Microsoft 365 services, enabling Power Platform solutions and driving Copilot adoption doesn't suddenly become irrelevant. In many cases, it becomes the foundation for what comes next.

The difference is that agents introduce a new dimension. We are no longer focused solely on how technology helps people perform work. We are beginning to explore how technology can participate in the execution of work itself.

That shift requires stronger governance, clearer ownership, reusable architectural patterns and a disciplined approach to scaling successful implementations.

Viewed through that lens, an Agentic CoE is not really about creating another team.

It is about creating an organizational capability that can answer three critical questions consistently:

• What business problem are we solving?
• Is an agent the right solution?
• How do we scale successful patterns responsibly across the enterprise?

As organizations move toward more agent-enabled ways of working, the companies that succeed will likely be the ones that treat agents not as isolated experiments, but as enterprise capabilities that are governed, operated and continuously improved.

And for me, that is where the Agentic Center of Excellence becomes truly valuable.

References

Microsoft Learn — Build an agentic Center of Excellence
https://learn.microsoft.com/en-us/agents/center-of-excellence/

Microsoft Learn — Agentic AI adoption
https://learn.microsoft.com/en-us/agents/adopt-overview

Microsoft Learn — Agentic CoE operating models
https://learn.microsoft.com/en-us/agents/center-of-excellence/operating-models

Microsoft Digital Accelerator – If You’re a Unified Customer, Make Use of It

 Microsoft has another useful program for organizations working through their Copilot and agent journey — Microsoft Digital Accelerator.

Unlike many of Microsoft's self-service learning and adoption resources, Digital Accelerator brings a more guided approach through expert-led, cohort-based sessions with Microsoft solution architects.

The journeys typically run for three to six weeks, with weekly sessions where participants can learn from Microsoft experts, ask questions, access recordings, and hear how other organizations are approaching similar challenges.

What does it cover?

Digital Accelerator currently includes journeys across areas such as:

• Copilot Cowork launch and optimization

• Copilot adoption and measuring outcomes

• Agent governance and FinOps

• Copilot Studio and GitHub

• Making AI part of everyday work

• Executive AI enablement

• Agentic HR

If your organization already has a Microsoft Unified support relationship, Digital Accelerator is worth exploring. Check with your Microsoft account team or CSAM to understand the available journeys and upcoming cohorts.

If you're already working on Copilot adoption, Cowork, agents, or AI governance, there may be a relevant program you can take advantage of rather than building every part of the learning journey internally.

Another useful Microsoft resource worth keeping on the radar if you're eligible.

Explore Microsoft Digital Accelerator: https://adoption.microsoft.com/en-us/digital-accelerator/

Register Soon...

Microsoft Agent Framework – Another Piece of the Agentic AI Puzzle

As AI agents continue to evolve, Microsoft is bringing more of its agent development capabilities together through the Microsoft Agent Framework.

Agent Framework is an open-source framework for building AI agents and agentic workflows. More importantly, Microsoft positions it as the next generation of Semantic Kernel and AutoGen, bringing concepts from both into a single, unified framework.

What Does It Bring Together?

At a high level, Agent Framework gives developers the building blocks to create agents that can:

• Use tools and external services
• Connect through MCP
• Work with memory and enterprise knowledge through RAG
• Include human-in-the-loop approvals
• Coordinate multiple agents
• Use workflows for more controlled orchestration

One useful bit of Microsoft's guidance is the distinction it draws between agents and workflows:

• Use an agent when the task is open-ended and requires the AI to determine the next steps. 

• Use a workflow when the process requires more predictable steps and control. 

• And if a normal function can solve the problem — Microsoft recommends simply using the function rather than introducing an AI agent.

Where Does It Fit?

A simple way to map Microsoft's agent-building options:

• Copilot Studio → Low-code agent development
• Microsoft Agent Framework → Code-first agent and workflow development
• Microsoft Foundry → AI platform, models, and services

The boundaries aren't always this clean, but it's a useful starting point for understanding where Agent Framework sits in the picture.

Want to Learn More?

While reading up on Agent Framework, I came across a great free hands-on course from Jamie Maguire, Microsoft MVP in Artificial Intelligence.

Jamie builds an AI personal trainer called Iron Mind AI using C#, progressively introducing function tools, memory, human approvals, MCP, RAG, and other agent capabilities along the way.

Even if you're not a developer, the series is a great way to see how many of the agentic AI concepts we keep hearing about actually come together in practice.

Read here to know more:

• Microsoft Agent Framework

• Free C# Course on YouTube: Understanding Microsoft Agent Framework

Credit to Jamie Maguire, Microsoft MVP in Artificial Intelligence, for creating and sharing this course  with the community.

As agents become a bigger part of the enterprise technology landscape, you don't necessarily need to be building them yourself — but understanding the frameworks and patterns behind them is becoming increasingly useful.

Turning Requests Into Azure DevOps Work Items with Power Automate and AI

If you manage a backlog in Azure DevOps, you probably know this problem.

Not every request starts as a nicely written work item. A bug comes through support, an infrastructure request arrives over email, someone sends feedback in Teams, or a business team asks for a new service or capability.

Someone eventually has to take that information, understand it, clean it up and create the actual backlog item.

I recently came across a useful demo from Ritu Hooda from First Bank & Trust, presented during the Microsoft 365 & Power Platform Community call, showing how this can be automated using Microsoft Forms, Power Automate, AI Builder and Azure DevOps.

Watch the demo: AI-Powered Azure DevOps Work Items with Power Automate

How It Works

The flow itself is pretty straightforward:

Microsoft Forms → Power Automate → AI Builder → Azure DevOps

Microsoft Forms becomes the simple front door for the request.

Power Automate picks up the submission, while AI Builder takes the raw information and helps turn it into something more useful — including a proper title, description and acceptance criteria.

The flow then creates the Epic or Work Item in Azure DevOps and can notify the appropriate team.

So instead of asking everyone to understand Azure DevOps Boards and how your team writes backlog items, they simply explain what they need.

Think Beyond Development Requests

What I liked about this demo is that the pattern can go much further than a normal software feature request.

You could potentially use the same approach for:

• Bug reports coming from users or support teams

• Infrastructure requests such as environments, VMs or platform changes

• Feedback and improvement ideas from employees or business teams

• New service requests or capabilities that need evaluation

• Product or platform enhancements that eventually need to enter the backlog

For teams already using Azure DevOps as the place where work gets tracked, this gives people outside the delivery team a much simpler way of getting requests into that process.

Why I Think This Is Useful

Having managed service and platform backlogs, I've seen how much time teams spend converting emails, chats, and stakeholder requests into structured work items. That's why this pattern immediately caught my attention.

The interesting part isn't simply that AI can write a work item.

It's the elimination of the manual translation step that happens beforehand.

People submitting requests don't need Azure DevOps access or need to understand how an Epic, Feature or User Story should be written. The team receiving those requests gets more consistent information, while the backlog owner spends less time converting emails and Teams conversations into something trackable.

And importantly, creating the work item doesn't mean automatically accepting the request.

The product owner, service owner or delivery team still decides whether it belongs in the backlog, its priority, feasibility and what happens next.

AI is helping structure the request — not making the decision.

A Simple Pattern Worth Exploring

I think this is a useful pattern for any team already managing work through Azure DevOps but receiving requests from multiple channels.

Instead of:

Email / Teams / Forms → Manual cleanup → Azure DevOps

you can start moving toward:

Simple intake → AI enrichment → Azure DevOps → Team review

A relatively small automation, but potentially a useful one when you're handling a large number of requests.

Worth Checking Out

The demo is part of the ongoing Microsoft 365 & Power Platform Community Calls, which are open to the community.

Community Calls: aka.ms/community/calls

And if you're thinking of building something similar, this is also worth watching:

Power Automate Error Handling: Error Handling in Power Automate Flows | Try Catch Scope Action

Error handling matters here because you don't want a failed AI enrichment or Azure DevOps step to result in a request quietly disappearing.

For me, that's the real value of this approach — give people an easy way to tell you what they need, while automation takes care of turning it into something your delivery team can actually review and track.

I'm planning to try this out with my own team and see how we can tweak the pattern beyond the original use case — particularly for capturing different types of requests, ideas and improvements and turning them into structured, actionable backlog items. I'll share what I learn along the way.

Stay tuned for more updates...

Microsoft's Copilot Learning Center: A Practical Place to Learn Copilot

Microsoft has put together something genuinely useful for everyday Copilot adoption: the Copilot Learning Center.

Rather than another feature announcement or product overview, the Learning Center provides a practical collection of bite-sized tutorials showing how Copilot can be used across the Microsoft 365 apps people already work with every day.

If you've been exploring Copilot but aren't quite sure where to start, this is a useful place to begin.

What's Inside?

The Learning Center organizes guidance around familiar Microsoft 365 applications, using simple scenarios and everyday tasks.

Word

You can explore examples covering:

• Rewriting and improving existing content

• Turning information into structured tables

• Creating a cover letter using a résumé

• Summarizing longer documents

• Getting started with prompting

• Working with citations and references

• Improving grammar and spelling

• Creating outlines for speeches and other content

Excel

The Excel examples show how Copilot can help users:

• Build trackers and organize information

• Understand complex formulas in simpler language

• Analyze and visualize data more quickly

PowerPoint

The Learning Center also walks through how Copilot can assist with creating, designing and refining presentations — helping users move from an initial idea or source material toward a structured deck.

OneDrive

Copilot in OneDrive focuses on helping users work with the information already stored in their files, including:

• Summarizing files

• Comparing information across documents

• Finding and understanding relevant content

Outlook

For people spending a large part of their day in email, the tutorials demonstrate scenarios such as:

• Drafting emails from a few instructions

• Summarizing lengthy email conversations

• Using Copilot to make writing and reading email easier

OneNote & Designer

There are also examples covering everyday productivity scenarios such as creating a daily schedule in OneNote and generating images from text using Microsoft Designer.

Why I Think This Matters

A lot of Copilot conversations naturally focus on new features, agents and what AI could eventually do.

But adoption happens differently.

Users need to see small, relatable scenarios that help them do something better today.

That could be summarizing a long document, understanding an Excel formula, preparing a presentation, drafting an email or simply organizing information.

This is where the Copilot Learning Center becomes useful.

For organizations rolling out Microsoft 365 Copilot, it can also complement internal adoption programs. Instead of creating every piece of introductory learning material from scratch, teams can point users toward Microsoft's own scenario-based guidance and then build organization-specific training around the use cases that matter most to their business.

My Take

The Copilot Learning Center isn't about another major AI announcement.

It's about something much simpler: helping people actually use Copilot.

With practical examples covering Word, Excel, PowerPoint, Outlook, OneDrive, OneNote and Designer, it's a useful starting point for anyone looking to move from experimenting with Copilot to making it part of everyday work.

Access the Learning Center here: Microsoft Copilot Learning Center

AI Skills Navigator Is Now in Microsoft Copilot: Learning Comes to the Conversation

Microsoft has brought AI Skills Navigator directly into Microsoft Copilot. It looks like a small integration on the surface, but it points to a bigger shift in how AI learning could become part of everyday work.

I first covered AI Skills Navigator when Microsoft introduced it in 2025, and since then the experience has continued to evolve as Microsoft's approach to AI-powered learning has matured.

From Searching for Learning to Asking for It

The usual way to learn something new at work is to open a portal, search through courses, and try to figure out what's relevant. With AI Skills Navigator now inside Copilot, that becomes a conversation instead.

You can simply say what you want to learn, for example:

• "I want to learn how to build AI agents."
• "What should I learn to get started with Microsoft 365 Copilot?"

Copilot then helps connect that goal with relevant learning resources. The shift is simple but important: instead of searching for learning, you start by describing what you want to achieve.

Learning Becomes More Personal

Different people need different learning paths. A developer building agents, an IT admin managing Copilot, and a business user trying to be more productive all need very different things — a single learning path won't work for all three.

By understanding what someone is trying to do, AI Skills Navigator can point them to what's actually relevant, instead of leaving everyone to dig through the same large catalog.

Copilot Keeps Taking On More

There's a broader pattern here too. Copilot is increasingly becoming the place where people start their work with AI, rather than one more app they have to open separately.

Instead of Work, then AI, then a separate step for Learning, these are starting to blend together. You're working with Copilot, you hit something you don't know how to do, and the same conversation helps you find what to learn.

Why It Matters for Organizations

Rolling out Copilot and agents is only one part of the job. People also need to keep building the skills to use these tools well, and those skills keep changing.

Having AI help employees find the right learning, in the flow of their work, could make continuous skilling easier — especially as organizations move from general AI awareness to more specific skills around Copilot, agents, automation, development, and governance. It can also help learning move away from something people occasionally visit in a training portal, toward something that's simply part of the day-to-day.

Final Thoughts

Bringing AI Skills Navigator into Copilot is a small step in terms of access, but a meaningful one in terms of direction. Learning is becoming conversational — instead of asking "which course should I take?", you can start with "this is what I want to do, what should I learn?" and let Copilot help from there.

References

AI Skills Navigator is now available in Microsoft Copilot

OpenAI Is Now a Microsoft Copilot Subprocessor. Here's What Actually Changed.

Microsoft recently announced that OpenAI is now a subprocessor for Microsoft Online Services, including Microsoft Copilot. At first glance, this may sound like a major shift in Microsoft's AI strategy. However, the reality is more nuanced.

The announcement does not change Microsoft's security, compliance, or privacy commitments for organizations. Instead, it introduces a new way for OpenAI models to be delivered within Microsoft Copilot while remaining under Microsoft's enterprise governance framework.

What Is a Subprocessor?

A subprocessor is a third-party organization that processes customer data on Microsoft's behalf to help deliver an online service.

In this model:

• Microsoft remains the primary service provider.

• OpenAI acts as a Microsoft-approved subprocessor.

• Microsoft Product Terms and the Microsoft Data Protection Addendum (DPA) continue to apply.

• Enterprise Data Protection remains in effect.

• Microsoft retains oversight through contractual, technical, and organizational safeguards.

For enterprise customers, this means OpenAI is operating within Microsoft's service delivery framework rather than directly providing a standalone AI service to your organization.

What Actually Changed?

Historically, Microsoft Copilot primarily relied on OpenAI models operated by Microsoft through Azure OpenAI Service.

Microsoft has now introduced an additional option:

• OpenAI models operated by Microsoft (Azure OpenAI)

• OpenAI models operated by OpenAI as a Microsoft subprocessor

According to Microsoft, this new model delivery path provides:

• Faster access to the latest AI model innovations

• Greater model flexibility

• Quicker availability of newer OpenAI model families, beginning with GPT-5.6

Update: It's Not Just OpenAI Anymore

Since this rollout, Microsoft has extended the same subprocessor model to Anthropic. Anthropic models are now enabled by default for most commercial customers (excluding EU/EFTA and UK) across Microsoft Copilot, Researcher, Copilot Studio, and Power Platform. This confirms the pattern isn't a one-off OpenAI arrangement — it's Microsoft building Copilot into a genuinely multi-provider platform, exactly the direction the "My Take" section below argues for.

This is the real story behind the announcement.

The rollout has happened in stages. OpenAI was added to Microsoft's Online Services Subprocessors List on June 23, 2026, with OpenAI-operated models becoming available from July 9. As of July 24, 2026, Microsoft enabled OpenAI-operated models for all users in eligible commercial customers unless administrators explicitly selected “No users” in the Microsoft 365 admin center.

The change is less about privacy and more about how Microsoft can bring advanced AI capabilities into Copilot faster while still maintaining enterprise protections.

What Has NOT Changed?

This is where many initial reactions and social media discussions have created confusion.

Microsoft explicitly states that:

• Security commitments remain unchanged.

• Compliance commitments remain unchanged.

• Privacy protections remain unchanged.

• Microsoft Product Terms and DPA continue to apply.

• Enterprise Data Protection remains in place.

• Prompts, responses, and Microsoft Graph data are not used to train foundation models used by Microsoft Copilot.

In addition, Microsoft Copilot continues to respect existing Microsoft 365 permissions. Users can only access content they already have permission to view within Microsoft 365.

For most organizations, existing controls such as:

• Microsoft Purview

• Conditional Access

• Entra ID governance

• Data Loss Prevention (DLP)

• Information Protection

continue to form part of the organization's existing Microsoft 365 security and governance framework.

The Important Fine Print

One detail that caught my attention is Microsoft's statement that OpenAI-operated models are currently excluded from certain in-country processing commitments where applicable.

This distinction is particularly relevant for organizations with strict data residency requirements. Microsoft states that Microsoft Copilot continues to support existing privacy, security, compliance, and EU Data Boundary commitments, while separately noting that OpenAI-operated models are currently excluded from certain in-country processing commitments where applicable. Organizations should therefore distinguish between broader data residency commitments and country-specific processing requirements when assessing the impact.

The practical distinction to track: 

• Where data is stored

• Where AI processing may occur

For organizations in highly regulated industries, this is worth discussing with privacy, legal, compliance, and risk teams.

Microsoft also documents specific compliance and cloud-availability exclusions for OpenAI-operated models, making it important for regulated organizations to review the applicable requirements before enabling the provider.

New Admin Controls

Microsoft has also introduced administrative controls that allow organizations to manage access to OpenAI-operated models.

Administrators can:

• Enable access for all users

• Disable access entirely

• Restrict access to specific users or groups

Importantly, these controls apply specifically to OpenAI-operated models delivered through OpenAI as a subprocessor. They do not affect OpenAI models operated by Microsoft through Azure OpenAI.

This gives organizations greater flexibility to align AI usage with governance and compliance requirements.

Why This Matters for Copilot Governance

From a governance perspective, this announcement is bigger than it may initially appear.

For years, most discussions focused on:

Which AI model is Copilot using?

Now organizations may also need to ask:

Who is operating the model?

That introduces a new governance consideration around:

• AI providers

• Model operators

• Data processing locations

• Regulatory requirements

• Vendor oversight

These are conversations many organizations already have for cloud services, and they are increasingly becoming relevant for AI services as well.

My Take

I believe this announcement is less about OpenAI and more about the future direction of Microsoft Copilot.

Microsoft recently introduced broader documentation around AI subprocessors, suggesting that Copilot may continue evolving into a platform capable of supporting different model providers and delivery methods.

Today, the conversation is about Azure OpenAI versus OpenAI-operated models.

That future is already here: with Anthropic now following the same subprocessor path, organizations need governance frameworks that address: 

• Multiple model providers

• Different AI operating environments

• Provider-specific compliance considerations

• AI provider approval processes

In many ways, AI governance is beginning to look a lot like cloud governance.

I also see this as a sign that Microsoft wants to bring the latest AI innovations into Copilot faster, without being limited to a single model delivery approach. While Azure OpenAI remains a key part of Microsoft's AI strategy, this move provides additional flexibility that could benefit both Microsoft and its customers.

Final Thoughts

OpenAI becoming a Microsoft Copilot subprocessor does not mean Microsoft is handing customer data directly to OpenAI or weakening enterprise protections.

What it does mean is that Microsoft is creating a more flexible AI architecture that can bring new model innovations into Copilot faster while continuing to operate under Microsoft's enterprise commitments.

For IT leaders, Copilot administrators, and governance teams, the key takeaway is not panic. It's understanding the architecture.

Know which models are available, who operates them, what controls exist, and whether those choices align with your organization's compliance and data residency requirements.

As Microsoft continues expanding its AI ecosystem, governance discussions will increasingly shift from simply asking:

"Which AI model are we using?"

to asking:

"Which AI provider are we trusting?"

That may ultimately be the bigger story behind Microsoft's OpenAI subprocessor announcement.

References

• OpenAI as a Subprocessor in Microsoft Online Services

• Overview of AI Subprocessors

• Data, Privacy, and Security for Microsoft Copilot

• Data Residency for Microsoft Copilot and Copilot Chat

• Advanced Data Residency in Microsoft 365

• Anthropic models in Microsoft Online Services

What It Takes for an Organization to Become a Frontier Firm

"Frontier Firm" has become the industry's word of the year. Microsoft's 2026 Work Trend Index put it at the center of its annual report, and every vendor, consultant, and MVP seems to have an opinion on it. But strip away the marketing gloss, and there's a genuinely useful operating model underneath — one that matters directly to anyone running Modern Workplace, Copilot, or AI governance at enterprise scale.

Here's what the concept actually means, and what it takes in practice to get there.

What a Frontier Firm Actually Is

A Frontier Firm isn't defined by how much AI an organization has deployed. It's defined by how deliberately leaders redesign work, matching the level of human involvement to the outcome required.

Microsoft's research frames this as a maturity journey, not a switch you flip. The organization doesn't need to push every workstream toward maximum agent autonomy — the goal is clarity on how humans and AI should work together for different types of work, and the discipline to keep reassessing that as capabilities improve.

It is also worth being precise about some of the headline numbers. Microsoft's analysis found that organizational factors accounted for 67% of the modeled importance in explaining AI impact, compared with 32% for individual factors. Microsoft notes that this represents statistical association rather than a causal effect, so these figures are best treated as directional research signals rather than hard measurements.

The underlying argument still matters: systems, processes, culture and organizational readiness can have a greater influence on AI impact than individual willingness alone.

Another figure that deserves careful interpretation is the widely discussed 16% of AI users identified as Frontier Professionals. This is not the same as saying that only 16% of organizations are Frontier Firms. Frontier Professionals describe individual AI behavior, while the Frontier Firm concept is about the interaction between individual capability and organizational readiness.

The Four Modes of Working With AI

Microsoft's 2026 Work Trend Index describes four modes of working with AI:

• Delegation: AI takes on defined work that previously required human execution, with humans retaining appropriate oversight.
• Collaboration: Humans and AI work iteratively together, combining human judgment with AI capabilities.
• Asking: People use AI to obtain information, analysis, ideas or assistance without necessarily redesigning the underlying workflow.
• Exploration: People use AI to investigate possibilities, experiment with new approaches and discover what can be done differently.

These modes are not competing stages where every organization must eventually move everything toward maximum autonomy. Different types of work call for different levels of human involvement.

As AI capabilities increase, human involvement does not disappear — it changes shape. What can decline is tactical, step-by-step execution. What becomes more important is the human ability to set direction, establish standards, exercise judgment and evaluate outcomes.

For enterprise leaders, the question therefore isn't simply "Where can we deploy an agent?"

It is:

"What should the human do, what should the AI do, and how should the work itself be redesigned?"

Building "Owned Intelligence"

This is the part of the framework I think gets underemphasized in most summaries, and it's the actual differentiator between firms that stall at pilot stage and firms that compound gains over time.

Microsoft calls it Owned Intelligence — institutional know-how that compounds, is unique to the firm, and is difficult for competitors to replicate.

Every organization pursuing this model needs to be able to answer three questions:

• Who reviews agent performance?
• Who has the authority to update the workflows agents run?
• How does a local win get captured and scaled across the organization?

Answering these requires coordinated reinvention across four roles, not just an IT rollout:

• Employees rearchitect their own work around intent, judgment and review.
• Leaders redesign processes around outcomes and appropriate levels of AI autonomy, rather than simply automating individual tasks.
• IT builds the infrastructure required to operate AI and agents at scale.
• Security ensures trust, identity, permissions, policy and monitoring are woven into the system itself rather than bolted on afterward.

That is what turns individual experimentation into organizational capability.

What This Looks Like With the Tools Already in Your Stack

The good news for Microsoft 365 shops is that much of the infrastructure needed for this journey already exists. The challenge is sequencing and connecting those capabilities deliberately rather than adopting them in isolation.

If we translate the Frontier Firm concept into the Microsoft stack, the pieces begin to line up.

For everyday assisted work and defined workflows

Microsoft 365 Copilot covers everyday assisted work — drafting, summarizing, analysis, information discovery and other knowledge-work scenarios where the human remains responsible for direction and judgment.

Copilot Studio extends this into more defined and repeatable agentic workflows. Organizations can build agents for specific scenarios such as ticket triage, employee support, onboarding or knowledge retrieval, with appropriate human ownership and governance.

For more advanced collaboration and orchestration

As organizations move toward more complex agentic workflows, the model becomes less about a person using an AI assistant and more about humans working with agents as part of a broader workflow.

Copilot Cowork, now generally available, represents Microsoft's move toward more autonomous, collaborative AI work, where agents can take on more complex tasks while people remain involved in setting goals, reviewing progress and making decisions.

Microsoft Agent 365, now generally available, provides the control plane for observing, governing, and securing agents at enterprise scale. At this stage, visibility into agents, their identities, permissions, activity and lifecycle becomes increasingly important.

The important point is that these capabilities should not be viewed simply as another set of Microsoft products to deploy. They are components of an operating model in which humans, AI and agents work together under defined governance.

The Governance Layer: Building the Evidence and Control System

This is where Microsoft Purview becomes particularly relevant.

Data Classification, Sensitivity Labels, Data Loss Prevention, Audit and AI-related activity monitoring can provide important controls and evidence across the information lifecycle.

But Purview should not be viewed as the entire agent-governance layer.

Agent governance increasingly spans identity, permissions, security, lifecycle management, policy enforcement, monitoring and auditability. That means Modern Workplace, security, identity, data governance and AI governance teams need to work together rather than treating agent governance as a single-product responsibility.

The objective is simple:

Know what the agent can access, what it is allowed to do, what it actually did, and who is accountable for the outcome.

That is the foundation required for scaling AI beyond experimentation.

From Individual Wins to Organizational Intelligence

Another important part of the Frontier Firm model is making sure that successful AI adoption doesn't remain trapped inside one team or one enthusiastic employee.

Microsoft 365 administration and Copilot analytics can help organizations understand usage and adoption patterns. The objective, however, should go beyond measuring license utilization.

The more valuable question is:

Where is AI changing the way work gets done?

A successful workflow in one team should become a candidate for institutionalization, governance and potentially broader deployment.

This is how an organization begins to build Owned Intelligence.

The Microsoft 365 maturity approach can also provide a structured way to assess progress across areas such as people, processes, governance and content management rather than treating AI maturity as simply the number of Copilot or agent licenses deployed.

Practical Starting Points for IT and Modern Workplace Leaders

If you're the one actually responsible for the rollout rather than simply setting strategy from the C-suite, here's where the real groundwork sits:

• Start with an honest AI inventory — where are Copilot, Copilot Studio, agents or other GenAI tools already being used, and what are they actually doing in each case?
• Map work to the appropriate human-AI model — don't default every process to maximum autonomy. Some work is better suited to asking, exploration, collaboration or controlled delegation.
• Define agent governance early — who reviews agent output, who can change a workflow, who owns the agent, what permissions does it have, and how are changes controlled?
• Treat this as a management system, not an IT rollout — Frontier leaders start with human ambition and business outcomes, then design the systems and guardrails around them.
• Build the maturity discipline — this isn't a one-time initiative. It requires ongoing measurement across governance, training, workflow redesign, security and content management to balance speed with safety.
• Capture what works — every successful AI-enabled workflow should create organizational learning that can be reused rather than remaining an isolated experiment.

Becoming a Frontier Firm isn't about maximizing AI adoption — it's about deliberately matching human involvement to outcomes, function by function, and building the governance and institutional memory to keep improving that match over time.

The organizations getting real value from Copilot and agentic AI aren't necessarily the ones with the most licenses deployed. They are the ones redesigning the work itself and building the governance, skills and organizational mechanisms required to scale what works.

The technology is increasingly available.

The harder transformation is organizational.

For anyone leading Modern Workplace or Copilot governance today, the practical takeaway is straightforward:

Your AI rollout plan needs a workflow-redesign plan sitting right next to it.

Without that pairing, adoption numbers can go up while real transformation still doesn't happen.

Related Reading: 

How Frontier Firms are rebuilding the operating model for the age of AI – Microsoft

2026 Work Trend Index: Agents, human agency and the opportunity for every organization – Microsoft WorkLab

How to start your Frontier Transformation: 3 strategies to start with people – Microsoft Cloud Blog

Microsoft's Next Step for Frontier Firms

Microsoft recently launched Microsoft Frontier Company, a new initiative focused on helping organizations move beyond AI experimentation and achieve measurable business outcomes through embedded AI engineering expertise and outcome-driven delivery. This reinforces the vision that successful Frontier Firms combine technology, process transformation, and organizational change. Microsoft describes the model as embedding engineering and AI experts directly alongside customer teams to build, deploy, and continuously improve AI solutions tied to business outcomes and KPIs. 

Learn More: Microsoft Frontier Company

The EU AI Act Enters Enforcement: What It Really Means for Microsoft 365 Copilot

The EU AI Act stopped being a purely "future compliance deadline" this month.

As of August 2, 2026, the European Commission's AI Office and national competent authorities gained enforcement powers for the provisions that have become applicable, while the Act's new Article 50 transparency obligations also started applying.

The timing is particularly significant for organizations using Microsoft 365 Copilot, Azure AI, Microsoft Foundry, Copilot Studio agents, and other generative AI services across their workforce.

But there's an important distinction to get right: August 2, 2026 is not the date when all high-risk AI obligations suddenly became enforceable. Following the EU's AI Omnibus, many high-risk obligations have been pushed to 2027 and 2028. What's arrived now is a combination of enforcement powers, transparency requirements, and continued obligations around prohibited AI practices and General-Purpose AI (GPAI).

For organizations running Copilot, the practical question isn't simply "are we compliant with the AI Act?" It's: where are we using AI, what role does each system play, and what obligations apply to that particular use case?

What Changed on August 2, 2026

The EU AI Act entered into force on August 1, 2024, but its requirements were deliberately phased. The major milestones:

• February 2, 2025: Prohibited AI practices and AI literacy obligations began applying

• August 2, 2025: Governance provisions and obligations for providers of General-Purpose AI models began applying

• August 2, 2026: The Act's general application date arrived — enforcement powers became operational for applicable provisions, and Article 50 transparency obligations began applying

• December 2, 2027: High-risk AI systems under many Annex III use cases — employment, education, biometrics, critical infrastructure — become subject to high-risk requirements, per the AI Omnibus timeline

• August 2, 2028: High-risk AI systems embedded in regulated products under Annex I receive their extended transition period

The European Commission's July 2026 guidance makes an important distinction here: the AI Act is now in its enforcement phase, but not every obligation applies today. That's a far more accurate way to describe the August 2026 milestone than "everything just became mandatory."

Article 50: The Transparency Rules That Matter Now

The most visible change is Article 50, introducing transparency requirements for certain AI systems. The European Commission published its final guidelines on July 20, 2026, shortly before the obligations began applying.

1. People must know when they're interacting with AI Providers of AI systems designed to interact directly with people must design them so individuals are informed they're dealing with an AI system, not a human. This matters most where AI-powered assistants are exposed directly to customers, employees, or citizens.

2. AI-generated and manipulated content must be identifiable Providers of systems that generate or manipulate synthetic content must implement machine-readable marking so the artificial origin can be detected — covering images, audio, video, text, and other synthetic content under Article 50. In most scenarios, this obligation sits with the provider through metadata or technical markers, not a visible label on every piece of content. Systems already on the market before August 2, 2026 get an extended compliance window until December 2, 2026 for this specific marking obligation.

3. Deepfakes must be disclosed Deployers must disclose when people are exposed to AI-generated or manipulated image, audio, or video content that constitutes a deepfake — relevant to marketing material, training content, corporate communications, and synthetic media.

4. Certain AI-generated public-interest text requires disclosure This is not a blanket rule requiring every piece of Copilot-assisted writing to carry an AI label. There's an important exception where content has undergone appropriate human review and a person assumes editorial responsibility. That distinction matters for everyday Copilot usage — rewriting an email, summarizing meeting notes, or improving a document doesn't automatically require an AI-generated label. Context and the nature of the AI's contribution matter.

What Does This Mean for Microsoft 365 Copilot?

This is where the AI Act's risk-based structure becomes important. Copilot is not automatically "high-risk" simply because it's an AI system. Classification depends on the AI system and, critically, how it's used.

For ordinary workplace activities — drafting emails, summarizing meetings, creating document outlines, generating first drafts, finding information across permitted organizational content — the use case will generally not become high-risk merely because Copilot is involved.

The situation changes when AI is incorporated into a regulated or high-impact decision process:

• Recruiting or candidate evaluation
• Employee selection or promotion
• Worker performance or employment-related decisions
• Access to essential services
• Creditworthiness or credit decisions
• Other Annex III use cases

Calling the technology a "copilot" doesn't remove the regulatory obligations — the use case matters more than the marketing name. And per the Commission's updated timeline, many Annex III high-risk requirements are now scheduled for December 2, 2027, not August 2026.

Key takeaway: don't classify the product — classify the use case. The same Copilot that drafts an email may be low-risk, while an AI-driven hiring workflow may fall into a regulated category with additional obligations.

Microsoft, Copilot, and the GPAI Responsibility Split

Another area worth getting the wording right on: the relationship between Microsoft, Copilot, and the underlying AI models.

Microsoft provides AI systems and services and, in relevant circumstances, may also carry obligations as a provider of General-Purpose AI models — but it's too simplistic to say "Microsoft is the GPAI model provider behind Copilot" and leave it there. The AI Act creates responsibilities across the entire AI value chain, and depending on the service and architecture, different organizations can carry responsibilities as model providers, AI system providers, deployers, downstream providers, distributors, or other actors.

For an enterprise using Microsoft 365 Copilot, the organization is generally acting as the deployer of the AI system within its own environment. That means Microsoft cannot simply be expected to solve the customer's entire AI Act compliance challenge. Customers still need to understand:

• What is Copilot being used for?
• Who is affected by its outputs?
• Is it involved in a regulated decision?
• What human oversight exists?
• What information is being processed?
• Can the organization demonstrate how the system is governed?

What This Means for Large Enterprises

For large enterprises, the immediate priority isn't rebuilding Copilot deployments. It's understanding where AI is influencing decisions, documenting those use cases, and ensuring appropriate governance, transparency, risk management, and human oversight controls are in place — not just for Microsoft 365 Copilot, but also Copilot Studio agents, autonomous AI agents, Azure AI services, Microsoft Foundry solutions, third-party AI platforms, and custom-developed AI applications.

Organizations that understand their AI estate today will be significantly better positioned as additional AI Act obligations begin applying in 2027 and 2028.

What Should Microsoft 365 Administrators and Compliance Teams Do?

1. Build an AI inventory Identify where employees are using Microsoft 365 Copilot, Copilot Studio agents, Azure AI/Microsoft Foundry, third-party GenAI services, custom AI applications, and AI-powered business processes. The goal is understanding where AI exists in the business — not just which AI products were purchased.

2. Map AI to business processes The next question: what is the AI actually doing? A Copilot used to summarize a meeting is very different from an AI system used to rank job candidates. Map deployments against business processes and identify whether any fall within regulated or potentially high-risk use cases.

3. Strengthen human oversight For important decisions, define where human judgment is required. AI output shouldn't automatically become a business decision simply because it came from a trusted enterprise platform — particularly in employment processes, financial decisions, and other customer-impacting workflows.

4. Use Purview and Microsoft 365 governance capabilities Microsoft Purview can play an important supporting role in a broader governance architecture — Data Classification, Sensitivity Labels, DLP, Audit, Insider Risk Management, Data Lifecycle Controls, Information Protection, and AI-related Activity Monitoring. These controls don't, by themselves, make an organization compliant with the EU AI Act, but they provide important security, governance, auditability, and evidence around how AI is being used.

5. Establish an AI literacy program Employees using Copilot should understand what it can and cannot do, hallucination and accuracy risks, appropriate handling of confidential information, human review requirements, bias and fairness considerations, and when AI output shouldn't be trusted. The AI Act's AI literacy requirement has applied since February 2025 — this isn't new, but it deserves continued investment.

The EU AI Act has now entered a significant new phase. August 2, 2026 is real, but it is not the date when every AI system suddenly became high-risk. What changed is that the AI Act's enforcement framework is now operational for applicable provisions, while Article 50 transparency requirements have begun applying. At the same time, the AI Omnibus has extended the timeline for many high-risk AI obligations into 2027 and 2028.

For Microsoft 365 Copilot customers, the practical lesson is straightforward: don't classify the product, classify the use case. Copilot used for everyday productivity is very different from Copilot or an AI agent embedded into recruitment, employee evaluation, financial decisions, or another regulated process.

The organizations best prepared won't necessarily be the ones with the most AI policies — they'll be the ones that can answer three simple questions: Where are we using AI? What decisions or content does it influence? Can we demonstrate that we are governing it appropriately?

That's the real shift happening with the EU AI Act in 2026.

Read here to know more: Safer and more transparent AI – European Commission

Also review: EU AI Act Compliance – Microsoft Trust Center

And: AI Act | Shaping Europe's Digital Future – European Union

Also Worth Reviewing: Microsoft's 2026 Responsible AI Transparency Report

Microsoft has also published its 2026 Responsible AI Transparency Report, providing a useful view into how its Responsible AI approach is evolving alongside generative and agentic AI.

The report covers Microsoft's refreshed Responsible AI Standard, evolving developer and deployer responsibilities, risk-based governance, AI safety and evaluation, and how Microsoft is adapting its governance approach as AI systems become increasingly interconnected and autonomous.

For organizations building their own AI governance frameworks, it provides useful context alongside the regulatory requirements discussed above.

 Read here: Microsoft Responsible AI Transparency Report 2026

Stay tuned for more updates on Microsoft, Copilot, Purview, AI governance, and the rapidly evolving regulatory landscape...

Microsoft Purview DSPM in 2026: Securing Data, AI Apps and Agents

Back in November 2025, I wrote about Microsoft Purview at Ignite and the growing role of Data Security Posture Management (DSPM) in protecting data in an increasingly AI-driven world.

Fast forward to 2026, and the story has evolved significantly. DSPM is no longer just about knowing where sensitive data resides. It is becoming a unified security posture layer for data, AI applications, and AI agents.

DSPM and DSPM for AI Are Now One Solution

The biggest structural change is that the new DSPM experience brings together capabilities that were previously delivered through DSPM (classic) and DSPM for AI (classic).

• Outcome-based guided workflows, where administrators select a security objective such as Prevent oversharing of sensitive data and Purview guides them through the entire remediation process.
• The conversation shifts from "Which Purview solution should I configure?" to "What data security outcome am I trying to achieve?"
• Existing classic policies are carried forward automatically with no administrator action required.

AI Observability Becomes a Core Capability

For organizations deploying Microsoft 365 Copilot, Copilot Studio agents, or other generative AI solutions, observability is becoming a foundational security requirement.

As AI adoption moves into production workloads, understanding how AI interacts with enterprise data becomes just as important as protecting the data itself.

• Visibility into which AI applications and agents are actively being used, including Microsoft 365 Copilot, Copilot Studio agents, and supported third-party AI services.
• Tracking of sensitive data interactions, oversharing risks, exfiltration events, and unusual access patterns associated with specific agents.
• For supported AI workloads, prompts and responses can be captured through Purview auditing, providing security teams with an investigative trail showing how AI systems interacted with enterprise data.

You can no longer assume that protecting the data repository is enough. Organizations must also understand how AI systems are using the data they can access.

Copilot Studio Agents Enter the Governance Conversation

Perhaps the most significant shift since the original DSPM story is that organizations are rapidly moving from using Copilot to building their own agents.

Purview now treats Copilot Studio agents as enterprise workloads requiring governance rather than simply another business application.

Supported capabilities for Copilot Studio agents now include:

• DSPM
• Auditing
• Data Classification
• Sensitivity Labels
• Data Loss Prevention (DLP)
• Insider Risk Management
• Communication Compliance
• eDiscovery
• Data Lifecycle Management
• Compliance Manager

Microsoft has also extended coverage to agents grounded in Dataverse data, while providing visibility into unauthenticated interactions with Copilot Studio agents.

Microsoft Agent 365 Raises the Stakes Further

Microsoft's Agent 365 vision introduces agents as first-class organizational entities capable of collaborating with people, tools, and other agents.

Purview extends the same governance capabilities, including DSPM, auditing, classification, DLP, Insider Risk Management, eDiscovery, and compliance controls, to Agent 365 interactions.

The bigger shift is that Purview now audits:

• Agent-to-human interactions
• Human-to-agent interactions
• Agent-to-tool interactions
• Agent-to-agent interactions

This expands the security model from protecting users and applications to protecting an environment where humans and autonomous agents interact with data, tools, and each other.

AI Is Also Being Used to Secure the Data

An interesting feedback loop is emerging. Microsoft is not only using Purview to secure AI but also using AI to help secure data.

• Embedded Security Copilot experiences allow administrators to ask natural-language questions about their data security posture.
• AI-assisted remediation can act directly on findings by removing public sharing links, applying DLP policies, or revoking excessive permissions.
• Administrators remain in control, with actions available for review, approval, and customization, while maintaining full auditability.

Proactive Investigations, Not Just Dashboards

DSPM now integrates with Data Security Investigations, which can automatically create and refresh investigations analyzing recently exfiltrated sensitive data using defined risk categories.

The real challenge is no longer collecting more telemetry. It is finding the right signal within that telemetry, and AI-assisted investigation and triage are increasingly helping organizations focus on the highest-risk events.

Coverage Extends Well Beyond Microsoft 365

DSPM now spans Microsoft 365, Azure, Fabric, and integrated third-party SaaS environments, including Google Cloud Platform, Snowflake, and Databricks, through partner integrations with Varonis, Cyera, BigID, and OneTrust.

The direction is clear: moving toward a more unified view across the enterprise data estate rather than focusing solely on Microsoft workloads.

Microsoft Foundry Becomes Part of the AI Security Picture

The same strategy is extending to Microsoft Foundry, where Microsoft Purview delivers data security and compliance controls for Foundry AI interactions.

Capabilities include:

• DSPM
• Auditing
• Data Classification
• Sensitivity Labels
• Data Loss Prevention
• Insider Risk Management
• Communication Compliance
• eDiscovery
• Data Lifecycle Management

This brings custom-built AI solutions into the broader Purview governance and security ecosystem.

The Model Has Genuinely Broadened

The evolution of Microsoft Purview DSPM over the last year can be summarized in a single diagram:

The scope has expanded from protecting data alone to securing the complete AI ecosystem around that data.

What This Means for Organizations

An employee opening a sensitive document represents one type of risk.

An AI agent that can access thousands of documents, correlate signals across systems, and take autonomous action introduces an entirely different risk profile.

Organizations now need to think across five interconnected layers:

• Data Security: Who can access the data?
• AI Security: Which AI applications can process it?
• Agent Security: Which agents can access it and act upon it?
• Governance: Is activity monitored, auditable, and compliant?
• Posture Management: Can risks be continuously detected and remediated?

DSPM has quietly become one of the most important governance surfaces in the Microsoft ecosystem.

Not because of a single headline feature, but because it answers the question every security team is increasingly being asked:

"Do you know where your sensitive data is going once AI and AI agents begin interacting with it?"

The shift from 2025 to 2026 is more than incremental. It represents an expansion from protecting data from AI to also using AI to protect data.

In many ways, Microsoft Purview DSPM is becoming the governance backbone of Microsoft's AI ecosystem. As organizations move from experimenting with AI to deploying autonomous agents at scale, visibility, governance, investigation, and remediation become just as important as data protection itself.

With Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry, and Agent 365 accelerating the move toward an agentic workplace, this is a topic worth understanding before the next security review cycle.

Read More

• Microsoft Purview Data Security Posture Management
• Microsoft Purview data security and compliance protections for generative AI apps
• Microsoft Purview for Copilot Studio
• Microsoft Purview for Agent 365
• Microsoft Purview for Microsoft Foundry
• What's new in Microsoft AI security