Is Your Organization Investing Enough in Testing Before Production?

Why investing in testing, change governance and observability is essential for operational stability, better employee experience and continuous innovation.

Listen to a short audio summary (6 min)

Prefer reading? The full article continues below.

Organizations continue to invest in cloud transformation, automation, AI and modern technology platforms. Product vendors are accelerating their roadmaps, while Agile, DevOps, CI/CD and Touchless Change Management are enabling faster technology delivery.

However, an important question deserves attention:

Are organizations investing sufficiently in testing environments and operational readiness to keep pace with these changes?

Based on my experience in enterprise IT service ownership, I continue to observe gaps in how some organizations invest in and prioritize their development, UAT and pre-production environments. While investments are being made, there is still room to strengthen testing capabilities, particularly as technology changes accelerate and delivery timelines become increasingly demanding.

Investing in testing, monitoring and operational readiness is not simply an additional IT expense. It helps organizations maintain stable services while creating more opportunities to focus on innovation.

Testing Environments Are an Essential Investment

Development, integration, UAT and pre-production environments play an important role in validating changes before they reach production.

These environments should adequately represent critical production configurations, dependencies, security controls and business workflows. They do not necessarily need to replicate every production component, but they should help identify risks relevant to the services being changed.

Testing should also cover appropriate failure scenarios, not just successful outcomes.

Testing environments should also use appropriately protected test data, with production credentials and sensitive information kept out of non-production environments wherever possible.

A change that works in isolation may behave differently when introduced into a complex enterprise environment.

Investing in suitable environments, test automation and skilled resources can help organizations strengthen validation practices and reduce avoidable disruptions.

Align Your Testing Roadmap with Technology Roadmaps

Technology vendors continuously introduce new features, security updates, platform changes and capabilities. Organizations may have limited control over these external release schedules, but they can establish their own approach to testing and deployment.

An organization's testing roadmap should evolve alongside the product and technology roadmaps it depends on.

This involves understanding upcoming changes, assessing dependencies, planning validation activities and allowing sufficient time for testing before broader deployment.

Not every change can be deferred, particularly when urgent security remediation is required. However, appropriate risk-based validation and deployment safeguards should remain part of the process.

Just because a new capability becomes available does not necessarily mean it needs to reach the entire organization immediately.

Pilot groups, phased deployments and clearly defined acceptance criteria can help teams evaluate changes before introducing them to larger user populations.

Change Management Is Evolving, but Validation Remains Essential

Traditional change management practices often relied on documented testing results, risk assessments, implementation plans and approvals before production deployment.

With DevOps, CI/CD and touchless change management, many of these activities can now be integrated into automated delivery pipelines.

Testing evidence, security checks, deployment results and approvals can be captured automatically, helping reduce manual effort while maintaining traceability.

Touchless change management should not mean testing-free change management.

Whether changes are deployed manually or automatically, organizations should maintain appropriate validation, risk-based controls and documented evidence.

The delivery approach may evolve, but the responsibility to protect production services remains.

Connecting Testing, Deployment and Observability

A reliable operating model should connect testing with deployment, monitoring and continuous improvement.

Stage	Key Considerations
Development and UAT	Validate functionality, integrations, security, business workflows and relevant failure scenarios using representative environments and appropriately protected test data.
Roadmap and change governance	Align testing with upcoming releases, assess risks, automate quality gates and retain validation evidence.
Production deployment	Use pilot groups, phased rollouts, health checks and appropriate rollback or recovery procedures.
Monitoring and observability	Monitor service health, performance, dependencies and unexpected behavior through relevant telemetry and alerts.
Remediation and improvement	Maintain response procedures, document findings and use production lessons to strengthen future testing.

These practices become increasingly relevant as organizations introduce AI agents and automation into enterprise workflows.

Beyond functional testing, teams should consider agent permissions, access to enterprise data, connected tools, unexpected actions and mechanisms for human intervention.

These considerations also connect with my earlier article, Who Owns an AI Agent After It Goes Live?

Testing Does Not End at Production Deployment

Even well-designed testing environments cannot reproduce every production condition.

This is where continuous monitoring and observability become essential.

Organizations need appropriate visibility into application and infrastructure health, integrations, performance and unexpected behavior through relevant logs, metrics, traces and alerts.

Equally important are clearly defined service ownership, incident response procedures and remediation capabilities.

Testing results, deployment records, approvals and operational documentation should also be retained to support troubleshooting, audit readiness and continuous improvement.

Production observations should feed back into testing strategies, helping teams address previously unidentified risks and strengthen future validation.

This complements the perspective shared in Observability Is Taking Center Stage

Three enterprise scenarios illustrating how testing, phased rollouts and continuous monitoring help reduce operational and security risks.

Update — 18 October 2026: When Trusted Applications Become a Security Risk

Illustration by the author, based on reporting from Huntress and ConnectWise.

The recent ConnectWise Cloud Backup (formerly SkyKick) incident highlights an important risk in Microsoft 365 environments: compromised vendor application credentials can provide access to customer tenants without compromising user passwords or triggering user MFA.

Huntress reported unauthorized application sign-ins across 162 tenants as of 16 October 2026. In one investigated tenant, a related application reportedly gained Global Administrator privileges and added credentials to other applications.

The lesson: Third-party application consent is not a one-time approval. Application identities, permissions and credentials require continuous governance, validation and monitoring.

Organizations should review:

• Application access: Identify affected applications by Application ID and follow vendor guidance on disabling them.
• Sign-in activity: Examine service principal sign-in logs, not just user sign-ins.
• Privilege changes: Investigate unexpected credentials, certificates and directory role assignments.
• Log retention: Preserve relevant logs promptly, especially where retention is limited.

This reinforces why testing, change governance and observability must work together, including for vendor-managed integrations and automated services.

References: Huntress Investigation | ConnectWise Trust Advisories

Final Thoughts

As enterprise technology continues to evolve, organizations should periodically reassess whether their investments in testing environments, validation processes and operational readiness remain aligned with their technology ambitions.

Where gaps exist, now is an appropriate time to revisit testing and operational strategies.

Testing roadmaps should evolve alongside product roadmaps, with teams having suitable environments, resources and time to validate changes before introducing them to larger user populations.

While strengthening these capabilities may require additional investment, it can help reduce avoidable production issues, minimize end-user disruption and improve service stability.

A stable IT environment with fewer recurring issues gives teams more time to focus on innovation, improve digital employee experiences and deliver greater business value.

Modernizing technology delivery should not mean rushing changes into production. It should mean enabling innovation with the testing, governance, observability and operational safeguards needed to support it.

Additional Resources — Microsoft Guidance

The perspectives shared in this article are based on my experience in enterprise IT service ownership, change governance and operational readiness. The following Microsoft Azure Well-Architected resources provide additional guidance for cloud workloads, with principles that are also relevant to Microsoft 365, endpoint management and broader enterprise IT operations.

1. Operational Excellence Design Principles — DevOps practices, operational excellence and reliable delivery.

2. Architecture Strategies for Testing — Testing strategies, validation and quality assurance.

3. Architecture Strategies for Designing a Monitoring System — Observability, telemetry and monitoring practices.

Windows Autopatch Adds Policy-Driven Update Approvals

Managing Windows updates across an enterprise requires balancing security, stability and employee experience.

Microsoft has introduced policy-driven update approvals in Windows Autopatch, allowing IT teams to choose which updates are approved automatically and which require manual review.

Microsoft targeted October 15, 2026, for rollout completion. Administrators can check their Microsoft Intune admin center for availability.

Scope clarification: These Windows Autopatch capabilities apply to eligible Windows client devices managed through Microsoft Intune. Windows Server operating systems are not supported by these Intune-based Autopatch policies and require separate server patch management solutions, such as Azure Update Manager or Microsoft Configuration Manager.

Figure: Microsoft 365 Message Center announcement MC1478956, published September 24, 2026, highlighting Windows Autopatch update approval enhancements. Illustrative recreation based on the announcement.

What's New in Windows Autopatch?

Capability	What It Means
Update approvals	Automatic or manual approval for monthly security, non-security preview and out-of-band updates
Flexible policies	Combine automatic and manual approval methods within one policy, including supported .NET Framework updates
Default behavior	Security updates default to automatic approval, other categories default to manual
Deferral periods	Delay automatically approved updates by 0–30 days
Pause controls	Pause individual update releases when issues arise
Quick machine recovery	Configure approval and deferral behavior for recovery updates that help repair Windows devices unable to boot after critical large-scale failures
Device reporting	Monitor update status, device readiness, assigned policies and deployment alerts. Report data refreshes approximately every four hours

These controls give endpoint teams more flexibility to automate routine security updates while retaining oversight of releases that need additional validation.

Three Important Things to Know

1. Pausing doesn't mean rolling back.

Pausing an update prevents further deployment but doesn't remove it from devices where installation has already completed. Microsoft notes that a pause can take up to eight hours to reach devices.

2. Hotpatch requires careful planning.

When hotpatch is enabled, devices won't receive approved non-security updates because installing them would interrupt the hotpatch servicing path. Administrators must disable hotpatch in the quality update policy to deploy those updates.

3. Approval methods cannot be changed after policy creation.

Switching between automatic and manual approval requires creating a new policy. This makes the initial policy design important.

What Does This Mean for Digital Workplace Teams?

The bigger change is not simply automation. It's how endpoint teams manage updates.

From manual approvals to policy governance: Teams can focus on defining approval rules, deployment rings, deferral periods and exceptions instead of repeatedly reviewing routine releases.

From reporting to action: Device-level visibility helps identify endpoints that require attention and supports targeted remediation. This aligns with the operational principles discussed in Observability Is Taking Center Stage.

Supporting AI-ready endpoints: As Windows evolves to support AI agents and intelligent workflows, maintaining secure, updated endpoints becomes increasingly important. I explored this broader direction in Windows Is Becoming a Platform for AI Agents.

Before You Enable It

Review Microsoft's prerequisites, device eligibility and update policies before enabling broader automation.

For example, .NET Framework update policy control applies to Windows 11, while Windows 10 devices enrolled in Extended Security Updates continue using client-side settings.

Organizations should also maintain pilot validation, deployment monitoring and clear ownership of failed updates or exceptions.

Final Thoughts

Windows Autopatch's latest enhancements offer a practical way to reduce repetitive update administration while improving deployment control and visibility.

Automating approvals removes repetitive work. It doesn't remove the need for someone to own what happens when an update goes wrong.

Resources

• Microsoft Learn — Windows Quality Updates and .NET Framework Updates
• Microsoft Learn — Quality Update Status Report
• Microsoft Learn — Quick Machine Recovery Updates
• Microsoft 365 Message Center — MC1478956: Windows Autopatch Enhancements (September 24, 2026) (Microsoft 365 admin sign-in required)

Stay tuned for more updates...

Who Owns an AI Agent After It Goes Live? Building the Enterprise Agent Operating Model

Deploying an AI agent is only the beginning. Clear ownership determines how it is supported, secured and improved after go-live.

Listen to the audio summary (8 min)

Prefer reading? The full article continues below.

Imagine an AI agent has successfully completed its pilot and is now supporting a real business process.

Everything looks promising until one Monday morning, when the agent produces an incorrect response, loses access to a connected application or starts consuming more resources than expected.

Who takes ownership of the problem?

Is it the business team, the developers, IT operations or the AI governance team?

This is where I believe organizations need to think beyond building and deploying AI agents.

From AI Governance to Operational Ownership

In my earlier article, Building an Agentic Center of Excellence, I discussed why enterprises need common standards, guardrails and governance as AI adoption grows.

But setting standards is only part of the journey.

What happens after an AI agent moves into production?

Having worked across enterprise service management, platform governance and digital workplace transformation, I've seen how important clear ownership becomes once a service is operational.

Ownership gaps often become visible during incidents, changes or escalations—not when a service is first launched.

I believe the same principle applies to AI agents.

An AI agent shouldn't be treated as something we simply build, deploy and forget. Once it supports a business process, it becomes part of the enterprise operating environment.

Who Owns What?

AI agents may involve several teams, but their responsibilities should be clearly defined.

Role	Primary responsibility
Business Owner	Business purpose, expected outcomes and continued need
Technical Owner	Agent design, integrations, dependencies and technical fixes
Platform / Governance Team	Enterprise standards, inventory, approvals and lifecycle controls
Security & Compliance	Identity, permissions, data protection and risk oversight
Service Operations	Monitoring, incidents, support and escalation

These responsibilities can overlap depending on the organization's operating model.

Microsoft Entra Agent ID uses the terms sponsor for the accountable business representative and owner for technical administration. Other platforms may use different terminology.

However, every production agent should have an identifiable, accountable business representative and clearly assigned technical and operational responsibilities.

A shared team mailbox or department name alone isn't enough.

The AI Agent Lifecycle

I see the agent lifecycle as an extension of the service lifecycle disciplines that enterprises already understand.

Business Need → Build → Approval → Production → Operate → Monitor → Improve → Retire

The first few stages usually receive the most attention. Teams define the use case, develop the agent, test it and obtain approval.

But the real operational questions begin after deployment.

• Approval: Who validates its purpose, identity, permissions and access to enterprise data?

• Production: Who accepts the agent into the operational environment and confirms support readiness?

• Operate & Monitor: Who tracks availability, response quality, incidents, usage and cost?

• Improve: Who approves changes to instructions, integrations, permissions or underlying models?

• Retire: Who decides the agent is no longer needed and ensures its access is removed?

Without these decisions, organizations risk creating agents that remain active without sufficient oversight.

Running AI Agents Like Enterprise Services

From my perspective, we don't necessarily need to reinvent service management for AI agents.

We need to extend existing practices to address their different behaviors and risks.

• Incident management: An agent giving an incorrect recommendation, performing an unintended action or becoming unavailable should have a defined support and escalation process.

• Change management: Changes to prompts, tools, knowledge sources and permissions may affect agent behavior. They need appropriate testing, approval and rollback planning.

• Security and identity: Agents require controlled identities, least-privilege access and traceability. This includes ownership of credentials used by approved applications, periodic access reviews and the ability to revoke compromised credentials promptly.

• Observability and quality: Monitoring an agent isn't just about whether it's running. We also need to understand whether it is producing reliable outcomes. This connects with my recent article, Observability Is Taking Center Stage, where I discussed how operational intelligence and AI-assisted remediation are evolving.

• Financial accountability: Consumption-based AI services also introduce cost considerations. As discussed in my FinOps for AI article, organizations need to connect usage and spending to measurable business value.

The objective isn't to introduce unnecessary governance. It's to make sure agents remain reliable, secure and valuable as their usage grows.

What About Agent Identity and Governance?

The technology ecosystem is starting to reflect this thinking.

Microsoft Entra Agent ID distinguishes technical administration from business accountability.

Technical owners manage aspects such as configuration and credentials, while sponsors represent the business and are accountable for the agent's purpose and lifecycle.

Microsoft requires at least one sponsor for each agent identity, while technical owners are optional.

There's another practical consideration: what happens when the sponsor leaves the organization?

Microsoft's model supports automatically transferring sponsorship to the departing sponsor's manager, helping maintain accountability.

These capabilities have licensing prerequisites. Microsoft identifies Microsoft 365 E7, or Agent 365 together with qualifying Microsoft Entra or Microsoft 365 licensing, as options for agent identity governance. Organizations should verify the requirements applicable to their environment.

But identity controls alone aren't an operating model.

Organizations still need clear responsibilities across business ownership, security, service operations and change management.

Governance should also reflect the agent's purpose and risk. For example, Microsoft's Copilot Studio guidance describes different governance zones, with stronger operational expectations for agents supporting professional or business-critical processes.

Not every agent needs the same level of control, but every production agent needs appropriate accountability.

Who Decides When an Agent Should Retire?

This is one area I believe deserves more attention.

An agent might be created for a valid business requirement, but that requirement may eventually change.

The process could be redesigned, the application replaced or the original owner moved to another role.

What happens to the agent then?

Does it remain active? Does it still retain access to enterprise systems? Is anyone reviewing its usage?

Automatic sponsor reassignment can help preserve accountability when someone leaves, but it doesn't replace the need to review whether the agent is still required.

Every agent should have a defined review and retirement process—not just a deployment process.

Retirement should include confirming that the business no longer needs the agent, disabling its access, handling retained data appropriately and updating the enterprise inventory.

Closing Thoughts

As enterprises move from AI experimentation to production adoption, I believe the conversation needs to evolve.

Building AI agents is becoming easier. Operating them responsibly at scale is a different challenge.

The Agentic CoE can establish the standards and guardrails. The enterprise operating model ensures those standards translate into everyday ownership and accountability.

For me, the principle is simple:

An AI agent going live isn't the finish line. It's where accountability begins.

And an agent without a clear owner is not just a technology gap. It's an unmanaged business risk.

Stay tuned for more updates...

Update (October 12, 2026): Satya Nadella on AI Models as Insider Risks

In his personal essay, “Models as Insider Risks in the Super Intelligence Era,” Satya Nadella argues that powerful AI models should be treated as potential insider risks, not because they are inherently malicious, but because they can make mistakes or be compromised.

His central message is that security controls must operate independently of the AI model, including access restrictions, audit trails, continuous verification and the ability to stop agent actions.

My Perspective

This reinforces why AI agent ownership cannot end at deployment. Organizations need clear accountability, independent monitoring and operational controls throughout an agent's lifecycle.

AI agents may act autonomously, but accountability must remain with the organization.

Update — October 16, 2026: Who Owns the Knowledge and Actions Behind AI Agents?

Microsoft recently introduced SharePoint team knowledge bases, currently in Frontier preview, where Copilot can help organize enterprise content into shared knowledge that people and AI agents can reference.

This raises an important operational question: Who ensures that AI-curated knowledge remains accurate, appropriately accessible and up to date? Automated, ongoing knowledge curation remains on Microsoft's roadmap, making clear accountability and periodic review especially important.

In a related development, Microsoft announced new capabilities for persistent and proactive agents in Copilot Studio, including organization-managed agent accounts, business process memory and proactive triggers for recurring workflows. These capabilities are being introduced through the Frontier program, with availability varying by feature.

Together, these developments reinforce the central message of this article: enterprise AI governance must cover both the knowledge agents rely on and the actions they perform. As agents become more autonomous and persistent, organizations need clear ownership, appropriate access controls, monitoring and lifecycle management.

Update — October 18, 2026: GPT-6.1 Astra and the Limits of AI Autonomy

OpenAI reportedly shelved GPT-6.1 Astra, its planned October release, following internal safety evaluations in late September. Testing raised concerns about whether the model consistently respected authorization boundaries and accurately reported its actions.

According to the Wall Street Journal, as reported by Reuters, OpenAI's head of safety systems, Saachi Jain, said the model “didn't quite meet the bar.”

Successful task completion does not guarantee that an AI agent acted within its permissions. Every production agent needs a clearly accountable owner who can define its boundaries, review its actions and intervene when necessary.

References

• Microsoft Learn — Governing Agent Identities
• Microsoft Learn — Administrative relationships in Microsoft Entra Agent ID (Owners, sponsors, and managers)
• Microsoft Learn — Implement a zoned governance strategy
• Satya Nadella — Models as Insider Risks in the Super Intelligence Era
• Microsoft — Introducing a team knowledge base, curated by Copilot and agents
• Microsoft — Delegate shared business processes to persistent and proactive agents with Copilot Studio
• Reuters — OpenAI shelves new AI model after internal safety tests

Microsoft-Decision-1: Why AI Agents Need Decision Models, Not Just LLMs

As AI agents become part of enterprise workflows, an interesting question is emerging.

Do we really need a large language model for every decision an AI agent makes?

Not necessarily.

Microsoft recently introduced Microsoft-Decision-1, a specialized AI model designed to make structured decisions quickly and at a lower cost.

It's an interesting development, particularly as organizations explore how to make AI agents more efficient, reliable and economical.

What Makes Microsoft-Decision-1 Different?

Traditional large language models are designed for a broad range of tasks, including understanding language, generating content and reasoning.

Microsoft-Decision-1 focuses on something more specific: evaluating choices and returning probability scores.

Think about everyday enterprise scenarios:

• Should an IT incident be escalated?

• Which support team should receive a request?

• Does an AI-generated response meet defined quality criteria?

• Should an automated workflow proceed or request human review?

These are examples of where specialized decision models could be useful.

Microsoft developed Microsoft-Decision-1 by post-training the open-weight Qwen3.5-9B model. Microsoft also plans to rebase the model on other foundations, including its own MAI models and OpenAI models.

This highlights an important point: the right AI model depends on the task, not necessarily its size.

What About Performance and Cost?

Microsoft reports that Microsoft-Decision-1 achieved the highest accuracy in its comparison across 36 benchmarks covering nearly 150,000 questions.

It also reported:

• Approximately 35 times faster median latency than GPT-6 Sol in its evaluation.

• 4.5 times faster than the next-fastest specialized decision model.

• In an Xbox Research use case, over 14 times faster and 200 times less expensive, with competitive quality.

Microsoft lists pricing at $0.042 per million input tokens, with output tokens free.

These are Microsoft-reported results, and actual performance will depend on the workload.

It's also worth remembering that comparing a small decision model with a large general-purpose LLM isn't necessarily a like-for-like comparison.

Where Does This Fit in Enterprise AI?

Consider an IT service management scenario.

An AI-enabled workflow receives an incident. A decision model could help classify the issue, recommend the appropriate support team or identify whether escalation is needed.

This connects with my recent article on observability and AI-driven remediation, where better operational intelligence can support faster investigation and recovery.

But there's an important distinction.

A model recommending an action doesn't automatically mean it should be allowed to execute it.

Microsoft emphasizes confidence-based decisions, where applications can act, defer or request review. It also reports robustness testing in which decisions changed on approximately 1.3% of tested input variations.

Organizations still need to validate accuracy, confidence thresholds and risks against their own business requirements.

What Should Enterprises Take Away?

Microsoft-Decision-1 doesn't mean every AI agent needs another model.

Some workflows may work perfectly well with existing business rules, automation or general-purpose LLMs.

But as enterprise AI evolves, we may increasingly see different capabilities working together:

• LLMs for language understanding and reasoning.

• Decision models for evaluating structured choices.

• Workflow engines for executing approved processes.

• Governance and monitoring for maintaining accountability.

The opportunity is to choose the right approach for the problem, rather than introducing AI everywhere.

Closing Thoughts

Microsoft-Decision-1 is another example of how the AI landscape is becoming more specialized.

For enterprises, the real opportunity isn't simply faster or cheaper models. It's designing AI workflows that are reliable, cost-effective and appropriately governed.

Not every task needs a large model. Not every decision needs AI. And not every AI recommendation should become an automated action.

Stay tuned for more updates...

References

• Microsoft — Introducing Microsoft Decision-1
• Microsoft Foundry — Microsoft Decision-1
• Related Reading — Observability Is Taking Center Stage

Observability Is Taking Center Stage: What AI-Driven Remediation Changes, and What It Doesn't

Digital services now span endpoints, networks, cloud platforms, applications and, increasingly, AI agents. When something slows down, users don't care which layer failed. They just know they can't work.

That's why observability deserves renewed attention. Organizations need to understand problems faster, identify emerging issues earlier and, where appropriate, explore automated recovery.

But does that mean investing in more monitoring tools? Not necessarily.

Many Tools, One Question

Most large organizations don't rely on a single monitoring tool.

Different tools provide visibility into different layers: the network, the employee's device, applications, cloud services and the infrastructure underneath.

Each answers part of the question.

The harder question is what is actually happening to the employee, and why?

A service might appear healthy from an infrastructure perspective while employees continue to experience slow applications, connectivity issues or interruptions.

This is where Digital Employee Experience (DEX) and workplace observability intersect.

DEX focuses on understanding and improving employees' technology experience, while observability provides the underlying technical signals needed to investigate performance and reliability issues.

Together, they help organizations move beyond infrastructure availability toward understanding the experience employees actually receive.

That's why connecting signals across systems can be more valuable than simply collecting additional telemetry.

The objective isn't more dashboards. It's a clearer understanding of service health and its impact on users.

Observability as a Service: Worth Considering?

Another concept receiving attention is Observability as a Service (OaaS).

Rather than every team managing its own monitoring capabilities independently, organizations can consider delivering observability as a shared service, supported by common standards, centralized visibility and clearly defined ownership.

This could involve existing enterprise platforms, cloud-delivered services, managed providers or a combination of approaches.

The potential value lies in reducing fragmentation, improving consistency and making operational insights more accessible across teams.

Grafana Labs' 2026 Observability Survey reported that 77% of respondents had saved time or money through centralized observability. As a vendor-run survey, this is a useful indication of practitioner experience rather than proof of industry-wide outcomes.

However, shared observability also brings considerations around integration, data ownership, security and the cost of collecting, processing and retaining telemetry.

The question isn't whether every organization needs OaaS. It's whether its existing capabilities provide the visibility and coordination required to manage increasingly interconnected services.

From Detecting Problems to Fixing Them

Monitoring and scripted automation aren't new.

For years, organizations have used telemetry, alerts, scripts and workflows to detect and respond to operational issues.

What AI introduces is the potential to connect these capabilities more intelligently.

AI-assisted tools can help correlate signals across systems, identify patterns, support investigations and recommend corrective actions.

In some scenarios, they can also initiate approved remediation workflows.

Consider an employee experiencing repeated application failures.

Signals might exist across endpoint monitoring, application telemetry and service management systems. Individually, they may appear unrelated. Together, they could indicate a broader issue affecting multiple employees.

Better correlation can help teams investigate faster, while controlled automation may reduce repetitive troubleshooting and accelerate recovery.

But these capabilities have limitations. AI-generated findings may be inaccurate, integrations may be incomplete and automated actions can introduce additional risks.

Not every issue requires an AI agent, and not every remediation should happen without human approval.

The opportunity is worth exploring, but the outcomes must be validated.

Two More Areas Worth Understanding: AIOps and AI Observability

As observability evolves, two related concepts are also worth exploring.

AIOps (Artificial Intelligence for IT Operations) uses AI and analytics to help IT teams identify anomalies, correlate events, investigate incidents and support operational remediation.

AI Observability, on the other hand, focuses on understanding how AI applications and agents themselves perform.

Are they responding reliably? Are their outputs accurate and relevant? Are their actions succeeding? What are the latency and consumption costs?

The distinction is useful: AIOps applies AI to improve IT operations, while AI observability helps organizations monitor and evaluate their AI systems.

Both deserve consideration as enterprises introduce more AI into their technology environments. Neither removes the need for governance, validation or clear ownership.

What Changes, and What Doesn't

What changes:

• Detection: Moving beyond isolated alerts toward identifying patterns, anomalies and potential service degradation earlier.
• Investigation: Using AI-assisted analysis to connect operational signals and reduce repetitive manual triage.
• Remediation: Linking insights to approved workflows, established runbooks and, where appropriate, automated corrective actions.

What doesn't change: Ownership.

Someone still needs to determine which actions can be automated, define the boundaries, assess the risks and confirm that recovery has actually happened.

An automated response might restart a service, execute a script or initiate a recovery workflow.

But what happens if the action fails? What if the problem returns? What if the remediation creates another issue?

Service ownership, change management, operational governance and human oversight remain essential.

An automated fix isn't a resolved problem until recovery is validated. And it isn't governed until someone owns the outcome.

Questions Worth Asking

For organizations exploring observability and AI-driven remediation, a few questions are worth considering:

• Visibility: Do our existing monitoring capabilities provide an end-to-end understanding of service health and employee experience?
• Integration: Where are the gaps between tools, teams and operational data?
• Ownership: Who is accountable for correlating insights and coordinating service recovery?
• Automation: Which operational issues can be safely automated, and which require human approval?
• Validation: How will we confirm that automated remediation actually resolved the issue?
• Cost and value: What will telemetry collection, retention and automation cost, and how will we measure the benefits?

These questions matter just as much as selecting the technology.

Bottom Line

As enterprise environments become more interconnected, observability deserves greater attention.

Whether delivered through existing monitoring platforms, a shared observability service or a combination of capabilities, the objective should remain the same: better visibility into service health, earlier identification of issues and more informed operational decisions.

AI-assisted investigation and automated remediation introduce new possibilities, but they are not substitutes for sound service management, engineering practices or governance.

Organizations don't necessarily need more tools. They need to understand whether their existing capabilities provide the visibility, intelligence and response mechanisms their services require.

The opportunity is worth exploring. The outcomes still need to be demonstrated.

The way we address problems is changing. Accountability isn't.

Stay tuned for more updates...

Further Reading

• Grafana Labs — Observability Survey 2026
• OpenTelemetry — Documentation
• Microsoft Learn — Automation in Microsoft Sentinel
• Microsoft Learn — AIOps and Agentic Operations
• OpenTelemetry — Generative AI Observability
• Dynatrace — Observability
• Datadog — Observability
• Riverbed — Digital Experience Management
• Nexthink — What Is Digital Employee Experience (DEX)?
• Microsoft Learn — Endpoint Analytics Overview

Windows Is Becoming a Platform for AI Agents: What It Means for the Digital Workplace

Microsoft's October 7 announcement positions Windows as a platform for hybrid intelligence, where AI agents can run locally when appropriate, access cloud intelligence when needed, and operate within enterprise security and management controls.

For Digital Workplace teams, the important shift isn't simply the introduction of AI agents. It's that agents are becoming something the endpoint must contain, identify and manage.

What's New?

1. Microsoft Execution Containers (MXC)

Now generally available on Windows 11, MXC introduces policy-driven containment for AI agents. Organizations can define which files and networks agents can access, with those restrictions enforced at runtime.

In simple terms: MXC provides a controlled execution environment for AI agents, restricting their access to endpoint resources based on policies enforced outside the agent's control.

This helps establish security boundaries rather than allowing unrestricted access to files, networks and other resources.

2. Hybrid Intelligence: Local and Cloud AI

Microsoft is bringing together local AI models, cloud intelligence and intelligent routing to determine where supported workloads should execute.

Beyond performance, this approach has financial implications. Running appropriate workloads locally could help organizations optimize cloud AI consumption and manage token-related costs.

What is GitHub HydraFusion?

GitHub HydraFusion is an intelligent model-routing capability designed to select an appropriate AI model for a task. Microsoft is extending this approach to support routing between local models running on Windows PCs and cloud-based models.

For example, a supported coding task could use a local AI model instead of consuming cloud AI tokens, while more demanding tasks could continue using cloud intelligence.

This hybrid capability is expected to enter experimental preview later in October 2026 across the GitHub Copilot app, GitHub Copilot CLI and Visual Studio Code.

3. More Context-Aware Copilot Experiences

Microsoft also outlined upcoming Copilot capabilities for Copilot+ PCs, including access to relevant PC context with user permission, supported device actions and local AI models.

What are Copilot+ PCs?

Copilot+ PCs are Windows devices equipped with dedicated AI processing capabilities, including a Neural Processing Unit (NPU), enabling supported AI workloads to run locally rather than relying entirely on cloud services.

Microsoft expects these new Copilot experiences to begin rolling out over the coming months. They should not be considered generally available today.

Why This Matters for Enterprises

Microsoft describes three important foundations for securing and managing agents on Windows:

• Containment: Defining and enforcing boundaries around agent access to files, networks and resources.

• Identity: Distinguishing agent actions from human activity to support security, auditing and accountability.

• Manageability: Extending enterprise policies, monitoring and governance to agent workloads, including integration with management capabilities such as Intune and Agent 365. Microsoft notes that governance at scale may require additional services.

For Digital Workplace teams, this also introduces new service management considerations: agent ownership, monitoring, incident handling and operational support.

A practical question organizations should begin asking is:

Who approves what an AI agent on an employee's laptop can access, and who owns that policy?

My Perspective

In my earlier article, The Digital Workplace Is Becoming an AI Workplace: But the Foundations Haven't Changed, I discussed why identity, security, governance and service reliability remain essential as AI adoption grows.

Microsoft's latest announcement reinforces that direction.

The future Digital Workplace will increasingly involve people, applications and AI agents working together across endpoints and cloud services.

The technology to contain and manage agents is evolving, but accountability must still come from the organization.

As Windows becomes more agent-aware, Digital Workplace leadership will need to extend existing endpoint, security and service governance practices to this new operating model.

Reference

Microsoft — Building Windows for Hybrid Intelligence (October 7, 2026)

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.