Before You Deploy Copilot: Is Your Microsoft 365 Data Ready for AI?

AI may not create oversharing — but it can make existing exposure easier to discover.

Listen to a short audio summary (5 min)

Prefer reading? The full article continues below.

Imagine an employee asks Copilot a legitimate business question and the response includes information from an old SharePoint site they didn't even know existed.

The document may be sensitive, but the employee already had access through a broad group or sharing setting that nobody had reviewed recently.

Copilot didn't necessarily bypass security. It surfaced information the employee was already permitted to access.

Before asking what Copilot can do, understand what information Copilot could surface based on existing user access.

1. Understand the Existing Exposure

Large Microsoft 365 environments accumulate content and permissions over many years: SharePoint sites, Teams-connected content, OneDrive files, broad groups, external users and old sharing links.

Something being technically accessible doesn't always mean it should still be accessible. That is why Copilot readiness needs to include information and access governance, not just licensing and deployment.

2. Discover Before You Deploy

Start by understanding the information estate.

Where is sensitive information stored? Which sites have large audiences or organization-wide access? Where are Anyone links being used? Which workspaces are inactive, externally shared or no longer have meaningful ownership?

Capabilities such as SharePoint Advanced Management and Data Access Governance can help identify permission patterns, broad sharing and sites that need attention.

The objective isn't to inspect every document manually. It is to identify where the highest risks are.

3. Classify and Protect What Matters

Permissions are only part of the picture. Organizations also need to understand what the information actually is.

Microsoft Purview capabilities such as sensitivity labels and Data Loss Prevention (DLP) can help classify and protect sensitive information. Copilot and agents operate within applicable Microsoft 365 access and protection controls.

But labels alone aren't an information-governance strategy. Someone still needs to understand what information needs protection, who owns it and how it should be handled.

4. Correct Access and Contain Risk

When oversharing is discovered, fix the underlying access wherever possible: remove unnecessary users and groups, revoke old sharing links, validate external access and correct permissions that no longer reflect the business need.

For sites undergoing remediation, Restricted Content Discovery (RCD) can temporarily reduce their visibility in organization-wide search and Copilot experiences without changing the underlying permissions.

Where stronger enforcement is required, Restricted Access Control (RAC) can restrict access to users in specified Microsoft 365 or Microsoft Entra groups. Users outside those groups can't access the site or its content even if they previously had permissions or a shared link.

Restricted discovery can buy time. It doesn't repair an incorrect access model.

5. Validate — Don't Assume

Finding the risk isn't the same as fixing it.

Site Access Reviews can involve site owners in reviewing Data Access Governance findings, validating whether broad access is still required and taking corrective action.

In my experience with large enterprise environments, this is where governance can easily stall. Reports and tooling can identify exposure, but remediation depends on having an owner who understands the information, can make the access decision and is accountable for closing it.

Another practical challenge is ownership itself. Sites can outlive projects, teams change, and the person listed as an owner may no longer understand why particular access was granted. An access review without an engaged information owner can easily become another unresolved task rather than a security improvement.

Consider an organization where external guests still have access to a project site long after the work has finished. The important question isn't whether Copilot is secure. It's whether those identities should still have access at all.

A dashboard showing 5,000 oversharing risks isn't governance. Governance begins when someone owns each risk and closes it.

6. Don't Try to Clean Millions of Files

In an enterprise with thousands of sites and potentially millions of files accumulated over many years, manually reviewing everything before enabling AI isn't realistic.

If I were prioritizing such an environment, I would start where multiple risk signals come together: sensitive or business-critical information, unusually broad audiences, organization-wide sharing, external access, complex permissions and stale or ownerless workspaces.

Then progressively improve the wider information estate.

At enterprise scale, the objective isn't perfect permissions overnight. It is continuously reducing the highest-risk exposure.

7. Make It an Operating Model

Copilot readiness shouldn't become a one-time cleanup exercise.

Content changes. New sites appear. Employees change roles. External partners join and leave. New agents connect to additional information sources.

The operating model therefore needs to be continuous:

Discover → Classify → Assess → Assign Ownership → Remediate → Validate → Monitor

Platform, security and governance teams can identify exposure, but site and information owners need to validate the business requirement and participate in remediation.

User behaviour matters too. Instead of choosing the broadest sharing option because it is convenient, the question should increasingly be:

Who actually needs access to this information?

Oversharing Is Also a Service Management Risk

A significant information exposure doesn't remain only a permissions problem.

It can become a security incident requiring investigation, remediation, compliance or legal involvement, stakeholder escalation and potentially reputational management.

That creates disruption across the IT service and the wider organization.

Preventing oversharing is therefore not only about securing Copilot. It is part of operating a secure and reliable Digital Workplace.

Closing Thoughts

AI doesn't necessarily create the oversharing problem. It can make weaknesses in existing access and information governance easier to discover — and potentially much more consequential.

Before scaling Copilot and agents, organizations should understand their information estate, classify what matters, correct excessive access, establish ownership and continuously monitor what changes.

Better AI starts with better-governed information.

Before asking what Copilot can do, make sure you understand what information it could surface based on the access your users already have.

Note: Availability and licensing for SharePoint Advanced Management capabilities vary. Organizations should validate current Microsoft licensing and prerequisites for the specific controls they plan to use.

References

• Microsoft Learn — Get ready for Microsoft Copilot and agents with SharePoint Advanced Management
• Microsoft Learn — What is SharePoint Advanced Management?
• Microsoft Learn — Copilot controls security and governance
• Microsoft Learn — Restrict discovery of SharePoint sites and content
• Microsoft Learn — Restrict SharePoint site access with Microsoft 365 groups and Microsoft Entra security groups
• Microsoft Learn — Initiate site access reviews for data access governance reports

Microsoft Ignite 2026 Is Coming. Have You Registered Yet?

Microsoft Ignite returns November 17–20, 2026 at the Moscone Center in San Francisco, with both in-person and digital options.

If you work with Microsoft technologies, this is one to keep on your calendar.

What to Expect

This year's Ignite covers Microsoft's latest direction across AI and agents, Microsoft 365, Copilot, Azure, security, data and the wider enterprise ecosystem.

I'm especially watching:

• Copilot and agents: where the platform is heading
• Microsoft 365 and the Digital Workplace: what changes for everyday work
• Security and governance: how enterprises keep AI under control
• Microsoft IQ and enterprise AI: how the different pieces are coming together

Can't Travel?

Microsoft offers a free Digital Pass with online access to keynotes, sessions and a wide range of technical content.

The session catalog is already live, so this is a good time to explore what's available and start building your list.

Event Snapshot

📅 Dates: November 17–20, 2026

📍 Location: San Francisco + Online

💻 Digital Pass: Free

Get Ready for Ignite

Whether you're attending in San Francisco or joining online, Ignite is a good opportunity to hear directly from Microsoft, explore what's changing across the technology landscape and identify what matters for your organization.

Register, explore the session catalog and start building your agenda.

I'll be following Ignite and sharing the updates that matter to the enterprise workplace and AI community here.

Read Here to Know More

• Microsoft Ignite 2026 — Registration and event details
• Microsoft Ignite 2026 — Session Catalog
• Microsoft Events

Stay tuned for more updates...

Understanding Microsoft IQ: Work IQ, Fabric IQ, Foundry IQ and Web IQ

As Copilot and AI agents become more connected to enterprise work, context becomes just as important as the AI model itself.

A capable model that doesn't understand how people work, how the business operates, what the organization knows or what is happening outside it will still give generic answers. The more we expect agents to act, the more that context matters.

Microsoft's answer to this is Microsoft IQ, an intelligence layer designed to ground Copilot and agent interactions in a shared understanding of the organization.

This article explains how its four capabilities fit together and what they mean for the people responsible for the workplace.

One Layer, Four Types of Context

Microsoft IQ is the umbrella. Underneath it, four capabilities each provide a different kind of context.

Work IQ provides a live understanding of how employees work, with context on people, collaboration and workflows across Microsoft 365, such as meetings, emails, files and conversations.

Fabric IQ provides the live state of the business. It helps agents understand business entities and their relationships, properties, actions and rules, so enterprise data carries business meaning instead of being a set of disconnected tables.

Foundry IQ provides curated institutional knowledge: policies, authoritative documents and reusable knowledge bases that agents can draw on.

Web IQ provides fresh, real-world information from across the web, so agents aren't limited to what exists inside the organization.

A Simple Way to Remember Them

Each one answers a different question:

Work IQ → How do we work?

Fabric IQ → How does the business operate?

Foundry IQ → What does the organization know?

Web IQ → What's happening outside the organization?

The value comes from bringing these different types of context together.

An Illustrative Example

This example is hypothetical and simplified. It shows why the four capabilities complement each other and doesn't describe a specific product configuration.

Imagine an account manager asking an agent to help prepare for a customer meeting.

Work IQ can bring in recent meetings, email threads and shared documents involving that customer.

Fabric IQ can add the business picture: orders, performance and account status.

Foundry IQ can supply contract terms, pricing policies and approved guidance.

Web IQ can add recent news about the customer's company or industry.

No single source is enough. The agent needs the work context, business state, organizational knowledge and outside view to prepare something genuinely useful.

Why This Matters for Digital Workplace Leaders

The value of Copilot and agents won't depend only on how capable the underlying models become. It will also depend on how well they understand the people, business, knowledge and external context around the work.

For anyone responsible for the workplace, that has a practical consequence.

Each context source has its own owners, permissions and quality considerations. Work context depends on how information is shared and organized. Business context depends on data quality and common definitions. Institutional knowledge depends on whether policies and documents are current and trusted.

In other words, the foundations I wrote about in my earlier articles matter even more. Identity, permissions, information architecture, data quality and knowledge management will influence how useful this intelligence layer becomes.

Better context also raises governance questions. Which sources should an agent use? Who owns their quality? How do we verify what an agent relied on?

A Note on Availability

Microsoft IQ is an umbrella, and its components and individual capabilities don't necessarily share the same availability, licensing or maturity.

Before planning around a specific capability, check Microsoft's current documentation for availability, pricing and requirements.

Closing Thoughts

AI agents are moving from answering questions to taking part in work. That makes context increasingly important.

Microsoft IQ is one indication of where enterprise AI is heading: toward systems that understand the people, the business, organizational knowledge and the world around the work.

Better context won't replace good foundations. It will depend on them.

That's why Microsoft IQ is worth watching—and why the groundwork inside the enterprise matters as much as the next model release.

References

• Microsoft Learn — Microsoft IQ documentation

• Microsoft Learn — Work IQ overview

• Microsoft Learn — What is Fabric IQ?

• Microsoft Learn — Foundry IQ FAQ

• Microsoft — Microsoft IQ: Unified Enterprise Intelligence for AI

Related Reading

• The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven't Changed
• From AI Adoption to Business Value: What Should Digital Workplace Leaders Measure?AI 
• Atlas: AI Ecosystem Guide

From AI Adoption to Business Value: What Should Digital Workplace Leaders Measure?

Making deliberate AI investments, matching capabilities to people’s needs, and validating the business value they deliver.

Listen to a short audio summary (5 min)

Prefer reading? The full article continues below.

In my recent articles, I explored what changes as the Digital Workplace becomes an AI Workplace, and how work and people’s roles evolve in AI-enabled service management.

Both lead to a practical question:

How do we make sound AI investments, and know whether they are delivering value?

Adoption figures are a useful starting point. But they are only the beginning.

Licences assigned show access. Prompts submitted show activity. Sustained use shows adoption. Better work outcomes show improvement. Business value requires evidence—and someone accountable for validating it.

This article reflects my perspective as a Digital Workplace and service management leader. It offers a practical approach to investment and measurement; outcomes will depend on the organization, its workflows and how the capabilities are implemented.

Business Value Starts Before the Investment

Value is usually discussed after a rollout. It starts earlier.

Before buying or enabling an AI capability, we need to ask:

• What business problem are we trying to solve?
• Which users and workflows need support?
• Can existing capabilities already meet the requirement?
• What improvement do we expect?
• Who owns the outcome, and how will it be verified?

New AI features arrive constantly. Each should trigger an evaluation, not an automatic investment.

A capability can be impressive without addressing a priority business need. It may also overlap with something the organization already has.

The governance approach I discussed in Building an Agentic Center of Excellence applies here: involve the existing governance structure and relevant owners, assess the requirement, and make a deliberate decision.

The investment should follow the need.

The Right Capability and License for the Right User

Licensing should follow the work.

Someone handling complex, frequent workflows may need different capabilities from a person who uses AI occasionally. Role, task frequency, required features, existing entitlements and approved data access all matter.

Paid AI licences do not necessarily need to go to the entire organization.

Start with users and workflows where there is a clear requirement and a credible opportunity to improve outcomes. Choose the capability and licensing option that meet that need.

A targeted pilot can establish who benefits, what support they need, and whether wider investment is justified.

The approval should connect the user, the capability and the expected outcome.

Move Up the Measurement Ladder

Activity is often the easiest starting point. The harder question is how far up the ladder the evidence actually reaches.

Stage	What it tells us	Example evidence
Activity	People have access and are trying AI	Licences assigned, active users, interactions
Adoption	AI is becoming part of relevant work	Sustained use in defined workflows
Work outcome	The work is improving	Quality, handling time, effort, rework
Business value	The improvement supports organizational goals	Capacity used, service improvement, validated savings or risk reduction

Each stage answers a different question.

An assigned licence shows access. Repeated use suggests adoption. Neither establishes whether the work is better.

High usage may reflect useful support. It may also reflect experimentation, repeated attempts or outputs that require correction.

To connect adoption with value, establish a baseline: how the work performed before the change, and what improvement would justify the investment.

Tools Help Build the Evidence

In my earlier Analytics Hub article, I explored resources for understanding Copilot adoption, licence utilization and potential impact. That discussion also included Copilot Analytics Labs and Microsoft365 Analytics Insights – Copilot Adoption.

These resources can help teams investigate usage patterns, identify adoption gaps and inform licence reviews.

Microsoft’s Copilot Dashboard in Viva Insights provides readiness, adoption, impact and sentiment insights. The measurement ladder in this article is my framework for connecting those signals with workflow outcomes and business value.

Microsoft’s own documentation describes Copilot assisted hours as a general estimate, using activity data and research-based assumptions. Its current methodology applies six-minute assistance factors to search or summary actions and creation actions; meeting-related assistance is calculated differently.

These are broad approximations, not direct measurements of the time each employee saved. Microsoft also notes that seasonality, role shifts and organizational changes can influence metric changes.

The important step is connecting telemetry with actual work.

Combine tool-generated insights with workflow measures, employee feedback and validated costs. Check metric definitions and known data issues before relying on a baseline.

Tools help assemble the evidence. Accountable owners determine whether it supports the investment decision.

Who Owns the Evidence?

An AI business case needs a clear answer to this question.

Someone must establish the baseline, validate the results and decide whether to scale. Several groups contribute:

Contributor	Responsibility
Business or process owner	Defines the expected outcome and confirms its relevance
Service or platform owner	Coordinates measurement, adoption and ongoing optimization
Employees	Validate the practical benefit and review effort
Finance	Validates financial benefit claims where applicable
AI CoE, security and governance teams	Support evaluation and appropriate controls

Several teams contribute evidence, but a named business or service owner should remain accountable for the outcome and the decision to scale.

One distinction matters: time saved does not automatically become financial savings.

It may create capacity, reduce employee effort or improve service responsiveness. Each is a potential benefit, but it should be measured and described accurately.

If capacity is redirected into resolving recurring problems or improving knowledge, show that connection. If the benefit is reduced workload, evaluate it directly rather than converting every saved minute into a cash-saving claim.

An Illustrative Example: AI-Assisted Service Desk Work

This example is hypothetical. The directional changes illustrate how to assess a pilot; they do not represent measured or expected results.

Consider a common category of collaboration tickets where AI could help analysts retrieve knowledge and prepare responses.

1. Establish the baseline. Record active handling time, end-to-end resolution time, reopen rates, quality and analyst effort. Compare tickets of similar categories and complexity.

2. Select the right users and capability. Choose analysts who regularly handle the workflow and identify the capability they need.

3. Run a limited pilot. Define its scope, duration, review requirements and success criteria.

4. Measure more than speed. Track quality, rework, analyst effort and the experience of people receiving support.

5. Validate the benefit. Include relevant costs and the time spent checking and correcting AI output.

6. Decide. Expand, adjust or stop based on the evidence.

The pilot might produce a mixed result:

Measure	Before	During pilot
Active handling time, including review	Established baseline	Lower
Reopened tickets	Established baseline	Slightly higher
AI-output review effort	No AI-specific review	Additional effort within handling time
Analyst experience	Established baseline	Mixed feedback

Faster handling is promising, but additional reopened tickets could reduce the overall benefit. Review effort should be included in handling time and tracked separately for understanding, without counting it twice.

The next step may be to improve knowledge sources, training or the review process before expanding access. Other changes during the pilot—such as staffing or ticket complexity—should also be considered before attributing the result to AI.

A pilot is useful when it improves the decision, including a decision to adjust the approach.

Review, Optimize and Scale

Licence optimization starts at approval and continues throughout the service lifecycle.

As needs evolve, review whether licences remain assigned to the right people and whether outcomes justify renewal or expansion.

Do users need training? Has the workflow changed? Would another approved capability meet the requirement more effectively?

When usage is low, investigate before reassigning licences. The cause may be missing skills, access barriers, an unclear use case or a workflow that gains little from AI.

Frequent usage should also be assessed against outcomes before expanding investment.

Licence and consumption costs belong in the evaluation, alongside implementation, support and human review. My AI FinOps article explores cost management in more detail.

Here, the focus is whether those costs are justified by verified benefits. Where financial ROI is claimed, use validated financial benefits and relevant costs over a defined period. Report service quality, employee experience and risk benefits separately unless there is a defensible basis for monetizing them.

Closing Thoughts

Digital Workplace leaders need to connect AI investment with user needs, service outcomes and organizational priorities.

That means looking beyond deployment and usage to understand whether the capability improves work—and whether that improvement justifies continued investment.

Before asking how many people are using AI, ask which people need which capabilities, what outcome the investment should improve, and who will verify that it did.

Define the need. Approve deliberately. Validate the benefit. Use the evidence to optimize or scale.

Related Reading

• The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven’t Changed
• AI-Enabled Service Management: Automating Work, Evolving People’s Roles
• Building an Agentic Center of Excellence: Do We Really Need Another CoE?
• Analytics Hub: Microsoft’s Free Toolkit to Measure Copilot Adoption, Impact & ROI
• FinOps for AI: Understanding Tokens, Copilot Credits and the Real Cost of AI

Reference

• Microsoft Learn: Microsoft Copilot Dashboard in Viva Insights — Official documentation covering dashboard metrics, assisted-hours methodology, interpretation limitations and known data issues.

AI-Enabled Service Management: Automating Work, Evolving People’s Roles

How AI-enabled service management can improve operations, build people’s skills, strengthen accountability and support responsible workforce change.

Listen to a short audio summary (4 min)

Prefer reading? The full article continues below.

Recently, I wrote that AI can make service management more intelligent, but it doesn’t make it unnecessary.

That raises a practical question:

When AI takes on more of the execution, how do we help people contribute more value?

Organizations have hired and developed people to support services, resolve incidents, manage changes and keep operations running. As AI becomes part of that work, some activities will require less manual effort. Others may be automated entirely.

The opportunity to optimize is real. So is the concern among people whose work is changing.

Both deserve attention in the same conversation.

This article reflects my perspective on how AI and people can work together in service management. Many of these considerations are common across organizations, but the right approach will vary with the service, its risks and the people involved. Other approaches may deliver even greater value—the aim is to open a practical conversation and learn from each other.

A Familiar Scenario

A recurring issue affects a collaboration service.

Tickets arrive. Several describe the same symptom differently. Some reach the wrong team. An incident is raised, engineers review logs, someone prepares stakeholder updates, and a change is proposed.

Much of the effort goes into gathering information, documenting it and passing it between teams.

AI is already supporting these activities. ServiceNow’s current ITSM documentation lists incident summaries, resolution-note generation, change-request summaries and change-risk explanations among its generative AI capabilities.

But a summary alone does not tell us whether a critical business process is interrupted, whether the proposed fix addresses the cause, or whether releasing it now is sensible.

Those questions require technical knowledge, business context and judgment.

As execution becomes more automated, organizations need to develop that capability alongside it.

Where the Work Can Evolve

Here is a practical way to think about the balance.

Area	AI and automation can help with	People can focus more on
Ticket management	Classification, routing, summaries and execution of approved fixes	Complex diagnosis, exceptions and employee impact
Incident and problem management	Gathering evidence, suggesting investigative steps and preparing timelines	Coordinating recovery, validating causes and preventing recurrence
Change and CI/CD	Preparing records, supporting test creation and executing controlled workflows	Defining release criteria, assessing business risk and managing exceptions
Continual improvement	Identifying recurring patterns and repetitive manual work	Choosing improvements and measuring their effect
Agent-driven operations	Executing actions within defined permissions	Setting boundaries, monitoring performance and intervening when needed

The balance will depend on the service and its risks. It should evolve as the organization gains evidence that the automation works reliably.

Optimization Should Include People Development

Organizations will naturally look at AI through cost and productivity.

If work can be completed reliably with less effort, preserving the manual process simply because it is familiar makes little sense.

But there is usually more useful work waiting.

Recurring incidents need investigation. Knowledge articles need updating. Monitoring gaps remain unresolved. Recovery procedures need testing. Service improvements stay in the backlog because daily operations consume the team’s time.

Automation can create room to address some of these weaknesses.

The question is what the organization will do with that capacity—and whether people are equipped to use it.

This makes learning and development part of the transformation roadmap.

A service desk analyst needs to know how to check an AI-generated summary and recognize an unsuitable recommendation. An engineer needs to validate generated code and tests. A service owner needs to understand how agent permissions, escalation paths and failures affect the service.

NIST’s AI Risk Management Framework explicitly addresses AI risk-management training, leadership responsibility and defined roles for human oversight.

Training should connect to actual responsibilities, with protected time to practise and opportunities to apply new skills.

Employees should also participate in automation design. They know the exceptions, workarounds and operational details that process documentation often misses.

For me, this is a stronger value proposition: use AI to improve execution while developing people to investigate, improve and govern the service.

Employees have a part to play in developing their skills. Organizations have a part to play in making that development achievable.

Touchless Change Still Needs Ownership

Change management is a useful example.

Continuous integration and continuous delivery or deployment—CI/CD—already support automated testing and deployment workflows. Azure Pipelines provides approvals and checks that control whether deployment stages proceed. AI can assist with surrounding activities, but the pipeline controls themselves are established automation.

For a repeatable, lower-risk deployment, a workflow could proceed when defined tests and policy checks pass, with exceptions routed for review.

Someone still needs to decide which changes qualify, what evidence is required, when execution must stop and how recovery will work.

ITIL guidance supports AI-enabled service management while emphasizing oversight, accountability and risk management.

Touchless doesn’t mean ownerless.

Reducing manual intervention should go together with clear service ownership and tested controls.

An Honest Conversation About Jobs

People are understandably concerned when activities they were hired to perform become easier to automate.

I do not think we can promise that AI will never replace anyone.

Some tasks will disappear. Roles may change significantly. Some organizations may reduce staffing.

The ILO’s 2025 occupational-exposure index identified job transformation as the most likely impact of generative AI. Its June 2026 evidence review finds that large-scale job displacement remains limited in the evidence reviewed, while highlighting uneven productivity gains and risks to employment opportunities and job quality. Neither finding guarantees security for an individual role.

What leaders can offer is a responsible transition: explain what is changing, involve the people affected, provide relevant learning and identify realistic opportunities in revised roles.

“Move into higher-value work” is only useful advice when people have somewhere to move and the support to get there.

Measure What Actually Improves

Time saved matters, but the service should tell us whether the investment is working.

Are repeat incidents decreasing? Is recovery faster? Are releases more reliable? Are employees receiving better support?

Incorrect routing, unsuccessful automated fixes, rework and unnecessary rollbacks also need attention. Faster execution has little value if it creates more problems downstream.

For the workforce, course completion is an early indicator. The stronger measure is whether people can apply what they have learned, assess AI outputs and manage the revised workflows confidently.

That gives leaders a fuller picture of optimization.

Closing Thoughts

AI creates an opportunity to rethink how service work gets done.

Organizations can reduce repetitive effort and improve operations while developing the people who understand their services.

That requires deliberate choices about investment, roles, learning and accountability.

The automation roadmap and the people-development roadmap should move together.

That is where I would start. Role design, learning pathways and the operating model for agents deserve a deeper discussion in a future post.

References

• ServiceNow — Using ITSM Generative AI Skills — Official documentation, updated 10 September 2026.

• Microsoft Learn — Azure Pipelines Approvals and Checks — Official deployment-control documentation.

• PeopleCert — Official ITIL Frequently Asked Questions — Current guidance on ITIL, AI-enabled environments and governance.

• NIST — AI Risk Management Framework Core — Foundational guidance from AI RMF 1.0 (2023); GOVERN sections 2.2, 2.3 and 3.2 cover training, leadership responsibility and human oversight.

• ILO — Generative AI and Jobs: A Refined Global Index of Occupational Exposure — Published 20 May 2025.

• ILO — The Impact of GenAI on Jobs, Productivity and Work Organization: A Review of the Empirical Evidence — Published 1 June 2026.

Related Reading

AnywhereExchange —The Digital Workplace Is Becoming an AI Workplace

The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven't Changed

The digital workplace is evolving as people, copilots and agents work together. AI adds new possibilities, while identity, security, governance and employee experience remain essential foundations.

Listen to a short audio summary (4 min)

Prefer reading? The full article continues below.

For years, the Digital Workplace has been built around a simple goal: give employees a secure, reliable and productive experience wherever they work.

What sits behind that experience has changed a lot.

Devices moved from domain-joined desktops to cloud-managed endpoints. Applications moved from data centers to SaaS. Identity became the control plane, with SSO, MFA, Conditional Access and Zero Trust. Microsoft 365 brought messaging, meetings, chat and content together. Digital Employee Experience brought greater focus to device health, application performance and proactive support. Security and compliance became part of workplace design rather than controls added afterwards.

The Digital Workplace became the combination of devices, applications, identity, connectivity, collaboration, data, security, employee experience and the services supporting all of them.

Now another layer is being added.

Artificial Intelligence (AI).

Copilots are becoming part of everyday applications. Agents are beginning to go further, interacting with enterprise data, applications and tools to complete work.

But that doesn't make everything we built before less important. I think it's the opposite.

From Digital Workplace to AI Workplace

The journey hasn't happened in one step.

Each stage built on the one before it.

Moving to the cloud didn't remove endpoint security. SaaS didn't remove access management. Microsoft 365 didn't remove information governance. Better DEX didn't remove service management.

Adding AI doesn't remove any of them either. Instead, AI depends on all of them working together.

Having worked through most of these stages over the years, one pattern keeps repeating: every new layer exposes how well the previous one was built.

One Agent, Five Foundations

Here's a simple scenario.

A manager asks an agent to summarize the status of a project and draft an update.

To do that, the agent needs:

An identity. Who is this agent, and who owns it?

Permissions. What is it allowed to access, and on whose behalf?

Trusted data. If the project site has outdated documents and over-shared folders, the summary could be wrong or expose something it shouldn't.

Security and audit. Can we see what it accessed and what it produced?

Operational ownership. If it fails, returns a bad result or can't reach a dependent service, who responds?

That one request touches identity, data, security, service management and governance.

None of these are new disciplines.

What's new is that a single AI interaction depends on all of them at once.

Identity Matters Even More

We already think about authentication, least privilege and lifecycle management for employees.

Now imagine hundreds or thousands of agents interacting with enterprise systems.

Who is the agent? What can it access? Who owns it? What happens when it's no longer needed?

These are familiar IAM questions applied to a new type of identity.

Microsoft is already moving in this direction with Microsoft Entra Agent ID, extending identity, access and lifecycle governance to AI agents.

The technology may be new. The principle isn't.

Give an identity only the access it needs, for only as long as it needs it.

AI Is Only as Useful as the Information Around It

An AI assistant can be extremely capable, but it still needs the right enterprise context.

If SharePoint is full of outdated documents, permissions are poorly managed, knowledge is scattered or important information lives only in people's heads, AI doesn't magically fix that.

It surfaces it faster.

This is why information architecture, Microsoft Graph, SharePoint, OneDrive, data quality and knowledge management become more important, not less.

Microsoft's Work IQ direction is interesting here because it connects Copilot and agents with organizational knowledge and work context.

We spent years building the Digital Workplace.

AI is now trying to understand it.

Security, Compliance and Governance Have to Work Together

AI doesn't create a separate security universe.

The same questions remain.

What can this user or agent see?

Is sensitive information protected?

Can we audit what happened?

Do retention and compliance requirements still apply?

As agents gain more autonomy, identity governance, Zero Trust, data protection, DLP and auditing matter even more.

And governance has to connect all of it.

Devices have policies. Applications have owners. Identities have access controls. Data has classification and retention requirements. AI adds models, copilots and agents.

But employees experience all of this as one workplace, so governance can't become a separate conversation for each technology.

The challenge isn't simply deploying more AI.

It's introducing AI without losing control of the environment around it.

That doesn't mean nothing is new. AI brings new cost models, new identities and new regulatory considerations. But these are extensions of the foundations we already have, not replacements for them.

Employee Experience and Service Management Still Matter

Digital Employee Experience now has another dimension:

How effectively can an employee work with AI?

Making Copilot available doesn't mean people know when or how to use it.

Deploying agents doesn't mean employees will trust them.

Adoption, training, change management and feedback still decide the outcome.

AI will also change how services are operated.

Incidents can be summarized faster. Recurring problems can be spotted earlier. Knowledge can surface inside the workflow. Routine requests can increasingly be fulfilled through automation and agents.

But someone still needs to own the service.

Someone still needs to understand the business impact when something fails.

We still need incident, problem and change management, service levels and clear accountability.

AI can make service management more intelligent. It doesn't make it unnecessary.

And when agents become part of business processes, an agent failure becomes an operational issue like any other.

The service model needs to evolve with the technology.

The Technology Changes. The Fundamentals Remain.

We are moving from employees interacting primarily with applications to a workplace where people, copilots and agents increasingly work together.

That's a significant change.

But underneath it, the same foundations remain:

Devices and applications.

Identity and access.

Security and compliance.

Trusted data and knowledge.

Connectivity and collaboration.

Employee experience.

Service management.

Governance and lifecycle management.

And most importantly, people and accountability.

The organizations that move best with AI may not be the ones with the most models, copilots or agents.

They may simply be the ones with strong foundations and the ability to extend them into this new way of working.

The Digital Workplace is becoming an AI Workplace.

We don't need to rebuild everything from scratch. We need to make sure the foundations are ready for what comes next.

References

• Microsoft Learn: Work IQ overview

• Microsoft Learn: Microsoft Entra Agent ID

EWS Deprecation Is Here — Is Your Exchange Online Environment Ready?

After years of discussion and preparation, Exchange Web Services (EWS) in Exchange Online is entering its final phase.

Microsoft has started the phased disablement of EWS from October 2026, with EWS scheduled to be fully disabled in Exchange Online in April 2027.

For many organizations, this isn't new. Those that started preparing early have already been identifying applications using EWS to access Exchange Online, working with application and business owners, engaging vendors and moving supported workloads towards Microsoft Graph.

But there may still be work to do.

Finding the Remaining Dependencies

From my experience with large enterprise messaging environments, knowing that a technology is being retired is the easy part.

EWS has been part of the Exchange ecosystem since Exchange Server 2007, and many applications have used it over the years.

For this retirement, the focus is specifically on applications using EWS to access Exchange Online.

Some of those applications may already have moved to Microsoft Graph. Others may still be in transition, waiting for application changes or vendor support, particularly where there isn't a straightforward Graph equivalent.

That's why identifying the remaining Exchange Online EWS dependencies is important. Application owners, business stakeholders, messaging teams and vendors may all need to work together to complete the migration.

The Next Few Months Matter

The EWS disablement isn't happening across every tenant at exactly the same time. Microsoft is rolling out the change tenant by tenant, starting with Worldwide (WW) tenants, with other environments following their respective rollout timelines.

If your organization has already started the migration, now is a good time to revisit the landscape.

A few things worth checking:

• Review the EWS Usage Report — identify applications still making EWS calls to Exchange Online.

• Check the Graph migration status — confirm what's already moved and what's still in progress.

• Revisit vendor-blocked applications — check whether vendors now have a migration path or updated support.

• Look for anything missed — older integrations and less-visible applications can easily remain in the environment.

Microsoft also provides migration guidance and tools to help developers assess existing EWS applications and potential Graph migration paths.

If you haven't started yet, start with discovery. Identify the applications, understand why they're using EWS, find the owners and build a migration plan.

The phased rollout through April 2027 provides some time to work through the remaining dependencies, but I wouldn't treat that as time to wait.

I'd treat it as time to finish the job.

One Important Distinction

This retirement applies to EWS in Exchange Online.

EWS isn't being retired from on-premises Exchange Server as part of this change.

Hybrid organizations should therefore look specifically at applications and scenarios interacting with Exchange Online mailboxes, including any relevant hybrid or cross-organization dependencies.

Final Thoughts

EWS has served the Exchange ecosystem for almost two decades.

Its retirement is another reminder that legacy dependencies can remain long after the technology landscape around them has changed.

Having worked through these kinds of enterprise messaging transitions, one thing continues to stand out for me:

The technology change is often the easier part. Finding the dependencies, getting the right people involved and moving every application safely is where the real work happens.

If you're already on the EWS migration journey, now is the time to close the remaining gaps.

If you haven't started, now is the time to understand your landscape.

References

Microsoft Exchange Team — EWS Deprecation Is Here – What This Means To You

Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online

Microsoft Learn — Exchange Web Services (EWS) Usage Report

Microsoft Graph — Migrate Exchange Web Services (EWS) apps to Microsoft Graph

Microsoft Exchange Team — Impact of Exchange Online EWS Deprecation on Hybrid Rich Coexistence and Cross-org Sharing

Enterprise AI Is Evolving Fast: Are We Ready for a Multi-AI Workplace?

The enterprise AI landscape is moving quickly.

Listen to a short audio summary (3 min)

Prefer reading? The full article continues below.

Microsoft recently introduced its evolving Copilot experience around Home, Code and Autopilot, with Chat and Copilot Cowork coming together within Home. OpenAI's DevDay introduced Dots, alongside further developments across ChatGPT and Codex. Anthropic continues to evolve Claude, Claude Code and Managed Agents, and is now bringing its Chat and Cowork experiences together into a unified Claude experience.

These aren't the only platforms and models enterprises are evaluating. Google Gemini is another significant part of the enterprise AI landscape, while Microsoft is expanding its own MAI model family alongside its partnerships with other model providers. Meta continues to develop its AI ecosystem, and xAI's Grok is expanding its business and enterprise presence. Platforms such as AWS Bedrock and IBM watsonx also play important roles in building, deploying and governing enterprise AI.

For this article, I'm focusing specifically on Microsoft Copilot, OpenAI and Anthropic, and how their increasingly overlapping capabilities could shape the multi-AI workplace.

Looking across these developments, one thing stands out to me:

AI is rapidly moving beyond chat.

We started by asking AI questions. Then we started using it to create content and complete tasks. Now we are moving toward AI that can take on larger pieces of work — and increasingly, continue working toward an objective.

For organizations investing across multiple AI platforms, this creates both opportunity and complexity.

Three Platforms, Increasingly Overlapping Capabilities

Microsoft Copilot, OpenAI and Anthropic have different strengths and starting points, but their capabilities are increasingly overlapping.

Here is a simplified view:

Enterprise capability	Microsoft	OpenAI	Anthropic
AI assistant	Microsoft 365 Copilot	ChatGPT	Claude
Delegated knowledge work	Copilot Cowork	ChatGPT work/agent capabilities	Claude / Cowork capabilities
Persistent / asynchronous work	Autopilot (private preview)	Dots (rolling out)	Managed Agents (beta)
Developer AI	GitHub Copilot	Codex	Claude Code
Building/customizing agents	Copilot Studio	OpenAI agent development tools	Claude Agent SDK
Enterprise context & connectivity	Microsoft 365 context, Work IQ and connectors	Apps, plugins and connected enterprise data	MCP, connectors and integrations
Enterprise strength	Deep M365, identity and governance integration	General-purpose AI, cross-platform work and agents	Knowledge work, coding and flexible agent development

These are not exact product equivalents, and they shouldn't be treated as such.

Microsoft's Autopilot, previously known as Scout, is being positioned as a persistent, proactive digital teammate with its own identity, memory, computer and workspace. That is particularly interesting from an enterprise perspective because persistent agents introduce new questions around identity, permissions, governance and accountability.

OpenAI's Dots similarly moves beyond a traditional chat session. A Dot can be given a goal, connected to the applications it needs and continue making progress between conversations using its own cloud computer.

Anthropic's Managed Agents, currently in beta, provides managed infrastructure for long-running and asynchronous agent workloads with persistent sessions.

There is also an interesting relationship between the two Cowork experiences.

Microsoft's Copilot Cowork and Anthropic's Claude Cowork share more than a name. Microsoft says it worked closely with Anthropic to bring the technology powering Claude Cowork into Microsoft 365 Copilot. They remain separate products, delivered and governed through their respective platforms.

Anthropic is now also bringing its Chat and Cowork experiences together into one Claude experience, beginning with Pro and Max users.

Microsoft's Code is another capability worth watching separately. It is aimed at knowledge workers rather than traditional developers, enabling people to create apps, dashboards, widgets and automations using natural language. That makes it different from GitHub Copilot and is why I haven't grouped the two together as developer AI.

Multi-AI May Become Normal

Many organizations are already invested in Microsoft 365 and Copilot while also evaluating ChatGPT Enterprise, Claude and other AI platforms for different business requirements.

That doesn't necessarily mean choosing one and removing the others.

But the growing overlap does make capability and licence optimization increasingly important.

Copilot itself can incorporate technology and models from other AI providers. Copilot Cowork's relationship with Anthropic is a good example. An organization separately licensing multiple AI platforms should therefore look beyond vendor names and understand which capabilities, models and business outcomes it is actually paying for.

That doesn't automatically make overlapping platforms unnecessary. Different products can provide very different enterprise context, user experiences, governance, security and integration even when some underlying AI technology overlaps.

The question is whether that overlap creates additional business value.

Use the Governance Structure You Already Have

This connects with something I wrote about earlier on building an Agentic CoE.

Every new AI platform doesn't require another Center of Excellence.

If your organization already has a dedicated AI or Agentic CoE managing AI workloads, align these evaluations with that team.

If AI governance already sits across Digital Workplace, Architecture, Cloud, Data, Security, Automation or Innovation teams, build on that existing model.

And if that capability doesn't exist today, establishing an appropriate AI governance and evaluation structure becomes increasingly important.

The name of the team matters less than having the right people around the table.

Bring the Capabilities to the Table First

Before taking every new capability to thousands of users, bring it to the table first.

Let the AI CoE or existing governance structure work with platform teams, security, architecture and the champions community. Give selected capabilities to representative business users and test them against real business use cases.

Understand:

• What business problem are we solving?

• Which platform is best positioned for that workload?

• Where do capabilities overlap?

• What enterprise data does it require?

• What are the identity, security and compliance implications?

• What does it cost?

• What measurable value does it produce?

• Who actually needs access?

Instead of asking:

                            "Which AI platform is better?"

perhaps the better question is:

                            "Which AI capability is right for this business use case?"

Some employees may need Copilot. Others may benefit more from ChatGPT or Claude. Developers may require a different combination, while power users and AI champions may genuinely benefit from access to multiple platforms.

                               Not everyone needs everything.

Governance May Also Cross Platform Boundaries

Another interesting development is that these ecosystems don't necessarily have to remain completely isolated.

OpenAI has indicated that specialist Dots are planned to integrate with Microsoft Agent 365, bringing another dimension to cross-platform agent governance.

It is still early and worth watching rather than drawing conclusions from today.

But as enterprises adopt agents from multiple vendors, the ability to discover, govern, secure and monitor them through common enterprise controls could become increasingly important.

A multi-AI workplace may eventually involve multiple AI providers while maintaining common governance around them.

ROI Needs to Follow the Use Case

Adoption alone isn't ROI.

Knowing that employees activated an AI tool tells us something about adoption, but not necessarily whether the investment is delivering business value.

I would look at something closer to:

Use Case → Platform → Cost → Adoption → Time Saved → Quality → Business Outcome

If AI materially reduces effort while maintaining or improving quality, there is a value story.

If the same employee has three AI licences but consistently uses only one, there may be an optimization opportunity.

And as persistent agents consume resources while performing asynchronous work, AI FinOps and observability become increasingly important.

The objective shouldn't be to give every AI product to every employee.

It should be to put the right capability in the hands of the people and processes where it creates measurable value.

A Note on Availability

Many of these capabilities are still evolving.

Microsoft Copilot Cowork is already generally available, while the newer Home, Code and Autopilot experiences are still progressing through their respective rollout stages. Microsoft says Home will begin reaching its Frontier program in the coming weeks, with Code following at the end of the month and wider access afterward. Autopilot is currently in private preview.

OpenAI Dots is rolling out gradually to eligible users, while Anthropic Managed Agents remains in beta. Anthropic is also progressively bringing Chat and Cowork together, starting with Pro and Max plans. For Enterprise customers, Anthropic says admins will hear from it at least 30 days before anything changes for their organization.

Features, licensing and availability will continue to change, so organizations should validate current vendor guidance before making platform or rollout decisions.

What This Means for Enterprises

Microsoft Copilot, ChatGPT and Claude are all evolving beyond conversational AI toward delegated work, agents, coding, application integration and increasingly persistent execution.

For enterprises, that doesn't mean deploying everything.

If you already have an AI CoE, use it. If you have an established governance model, build on it. Bring your champions and representative business users into the evaluation, test real use cases and understand the overlap before scaling.

The technology will keep changing, and today's differentiator may become tomorrow's standard feature.

So perhaps the question is no longer:

"Which AI should we buy?"

but:

"Which AI capability creates the most value for this work?"

Three Practical Takeaways

If I had to reduce this to three things for enterprise teams:

Map capabilities, not just vendors. Understand where the platforms overlap and where each genuinely adds value.

Use the governance you already have. Extend your existing AI CoE or governance model rather than creating another structure for every new platform.

Pilot before you scale. Test real business use cases with representative users, measure the value and understand the governance implications before expanding access.

From AI Cost to AI Capacity

Microsoft's Jared Spataro recently added another interesting dimension to the FinOps for AI discussion: as agentic AI becomes increasingly consumption-based, the question isn't only how much AI costs, but which business priorities should receive that capacity in the first place.

This shifts the conversation from simply managing AI consumption toward allocating AI capacity based on business value.

Central teams can provide governance, visibility and common controls, while business leaders closer to the work can help determine where that capacity should be invested. The important part is connecting the investment to an expected outcome, measuring whether it delivered, and then scaling what creates value and retiring what doesn't.

For me, this reinforces a simple principle:

AI FinOps shouldn't stop at measuring consumption. It needs to connect consumption to business outcomes.

Read here to know more

Microsoft — Copilot: Home, Code and Autopilot

Microsoft — Copilot Cowork

OpenAI — Dots / ChatGPT updates

Anthropic — Claude and Cowork

Anthropic — Managed Agents

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

Jared Spataro — Who decides which business priority earns agent capacity?

Quick Update: OpenAI DevDay 2026 – What Was Announced

OpenAI has wrapped up DevDay 2026, with more than 20 announcements across ChatGPT, models, agents and developer tools.

Rather than going deep into each announcement, here are a few that stood out:

• Dots – persistent AI agents designed to keep working toward a goal between conversations, using their own cloud computer and connected tools.

• ChatGPT Space and Pages – shared workspaces where people and agents can collaborate around files, context, documents and ongoing work.

• GPT-6.1 Sol – OpenAI's latest model aimed at complex coding, computer use and professional workflows.

• Agents API updates – including computer use and capabilities for building more sophisticated agent-based workflows.

• Codex Cloud – enabling delegated coding tasks to continue in isolated cloud environments, even when the user's computer is offline.

• ChatGPT integrations – including deeper ways for ChatGPT to work within collaboration environments such as Microsoft Teams and Slack.

There are several other announcements covering models, APIs, developer tooling and enterprise capabilities.

The complete announcement list is available in OpenAI's official recap below

OpenAI DevDay 2026 Recap

When Will These Features Be Available?

Not everything announced at DevDay is available to everyone immediately. OpenAI is rolling out GPT-6.1 Sol in ChatGPT Work and Codex, starting with Pro and expanding to Plus, Business, Enterprise and Edu. Dots are initially rolling out to eligible Pro and Business Premium users, with an Enterprise beta, and OpenAI says access may take several days even for eligible accounts.

Other capabilities announced at DevDay are also being introduced progressively, so availability will depend on the feature, plan and region.

For the latest rollout details, check the OpenAI ChatGPT Release Notes alongside the official DevDay recap.

Connecting This to My Earlier Posts

One thing is becoming increasingly clear from these announcements: AI is moving beyond simply answering prompts.

Earlier, I wrote about the evolution of Copilot, autonomous agents, AI governance and FinOps for AI. DevDay adds another piece to that journey — AI systems that can increasingly take actions, use tools and continue working asynchronously.

The individual products will continue to evolve, but the broader direction is worth watching.

We are moving from AI that assists with work toward AI that can participate in the work itself.

I'll explore some of these announcements individually as they mature and as their enterprise implications become clearer.