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.
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.
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.
Update – September 26, 2026: Getting Hands-On with Microsoft Foundry
Microsoft Developer has also released an Inside Microsoft Foundry quick-start video series for anyone looking to get hands-on with AI agents.
The short videos cover building agents with Python, VS Code and no-code approaches, along with agent customization, model selection and routing across multiple models.
What I like about the series is that it moves beyond explaining what agents are and shows how developers can actually start building them using different approaches within the Microsoft ecosystem.
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.
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.
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.
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.
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 Navigatorwhen 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.
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.
"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.
Listen to a short audio summary (4 min)
Prefer reading? The full article continues below.
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.
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.
Microsoft has shared some interesting lessons from its own AI transformation, and I thought it was worth adding here.
One point that stood out to me is that deploying AI alone doesn't create transformation. The real value starts to show when organizations rethink how work gets done, focus on business outcomes, and bring people and AI together.
This connects well with the Frontier Firm discussion above — it is not just about adopting more AI, but using it to create meaningful change and measurable value.
The EU AI Act stopped being a purely "future compliance deadline" this month.
Listen to a short audio summary (4 min)
Prefer reading? The full article continues below.
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.
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.
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.
Microsoft's 2026Digital Defense Report highlights another growing concern: AI agents with too much access.
As agents connect to enterprise data, applications and tools, their identities and permissions become part of the security landscape.
The same principles still apply — least privilege, data protection, monitoring and Zero Trust. The difference is that we now need to apply them to agents too.
This makes capabilities such as DSPM, DLP and auditing increasingly important as organizations move from experimenting with agents to using them at scale.
Microsoft just opened a new, limited-time door into Microsoft 365 Copilot Business — but it's a door built for one specific segment. Here's what it actually offers, who qualifies, and where Enterprise customers stand instead.
What Is Copilot in 30?
Copilot in 30 is a new, CSP partner-led Microsoft 365 Copilot Business trial, live since August 1, 2026 and available through December 31, 2026.
25 users, 30 days, $0 cost
Delivered through CSP New Commerce (product ID CFQ7TTC0MM8R, SKU 006Z)
One trial per customer — no extensions or seat changes mid-trial
Auto-renews to a paid subscription by default, with a 7-day cancellation window
It's part of Microsoft's broader FY27 push to accelerate Copilot adoption through its partner ecosystem.
Who Actually Qualifies
This is the part worth getting right before recommending it to anyone.
Eligible:
Organizations with fewer than 300 employees
Microsoft 365 Business customers
Customers onboarded through a CSP partner
Not eligible for Copilot in 30:
Individuals — there's no consumer path into this trial
Enterprise tenants on E3, E5, or E7
Direct (non-CSP) purchase motions
Eligibility is tied to the offer and licensing model, not simply company size. A 40-person company on E5 does not qualify for Copilot in 30 — being an SMB by headcount does not override the enterprise SKU.
Where Enterprise Customers Stand
If you're on E3 or E5, Microsoft 365 Copilot remains a $30/user/month add-on at standard list pricing. However, the Copilot in 30 offer is not the trial route available to those enterprise SKUs.
If you're on Microsoft 365 E7 — the Frontier Suite — Copilot is already included. E7, at $99/user/month, bundles:
Microsoft 365 E5 as the base
Microsoft 365 Copilot — included natively, no add-on required
The full Microsoft Entra Suite
Agent 365 — the new control plane for governing AI agents
For E7 tenants, there's simply nothing to trial — Copilot is already part of the license, working inside Word, Excel, PowerPoint, Outlook, and Teams from day one.
The bigger E7 proposition, however, isn't just the included Copilot. It's the combination of Copilot, identity, security, and agent governance in a single enterprise suite.
Copilot Success Planner: Turning the Trial Into a Plan
Microsoft has now layered a structured onboarding tool on top of Copilot in 30, called the Copilot Success Planner.
The idea is simple: a 30-day trial is only useful if people actually use it. So instead of leaving all 25 trial users to figure out Copilot on their own, the planner gives each user a personalized 30-day learning plan, built around role-relevant prompts and Microsoft support resources for each guided action.
The rollout works like this:
The company sponsor completes a short, guided setup experience
From there, the planner takes over, guiding all 25 users through the four weeks of the trial automatically
Each user gets prompts and guidance relevant to their own role, rather than a generic "here's Copilot" walkthrough
For partners, this closes a gap that trials usually struggle with — adoption follow-through. A free trial without structure often ends in low usage and no real evaluation of value. With the Success Planner attached, Copilot in 30 becomes less of a raw trial and more of a guided 30-day rollout.
See how Planner can help your Customers to get more from their trial: aka.ms/Copilotin30
Quick Reference
Copilot in 30 — SMB
Copilot cost: $0 for 30 days
Eligibility: Organizations with fewer than 300 employees, eligible Microsoft 365 Business customers, through a CSP partner
Duration: 30-day trial, 25 users
Delivery: CSP partner
Microsoft 365 E3 / E5 — Enterprise
Copilot cost: $30/user/month add-on
Eligibility: Eligible enterprise base license
Duration: Ongoing
Delivery: Direct or CSP
Microsoft 365 E7 — Enterprise
Copilot cost: Included
Eligibility: E7 subscription
Duration: Ongoing
Delivery: Direct or CSP
Includes: Microsoft 365 E5 + Microsoft 365 Copilot + Microsoft Entra Suite + Agent 365
Copilot in 30 is a well-targeted SMB on-ramp, not a universal Copilot trial. If you're under 300 employees and on an eligible Microsoft 365 Business plan through a CSP partner, this is worth a conversation before the December 31, 2026 window closes — and with the new Copilot Success Planner now attached, that trial comes with a guided 30-day plan for every user instead of leaving adoption to chance.
If you're already on E3 or E5, you're looking at the standard Copilot add-on — and it's worth running the numbers on whether selective Copilot licensing or the broader E7 proposition makes more sense long-term.
And if you're already on E7, there's nothing to trial — Copilot is already included. The bigger opportunity is taking advantage of the broader E7 capabilities around identity, security, and agent governance.
Know your SKU before you go looking for a trial; it decides which door you're standing at.
.jpg)
.png)
.png)
.png)
