Inside Track - Data http://approjects.co.za/?big=insidetrack/blog/tag/data/ How Microsoft does IT Thu, 22 Oct 2026 16:04:34 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 137088546 Turning network configuration management into a conversation at Microsoft with Autonet AI Agent http://approjects.co.za/?big=insidetrack/blog/turning-network-configuration-management-into-a-conversation-at-microsoft-with-autonet-ai-agent/ Thu, 22 Oct 2026 15:45:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=25821 Network engineers at Microsoft rarely struggle because they lack the tools to do their work. The challenges appear when they need to access too many tools spread across too many workflows. At Microsoft Digital, the company’s IT organization, we manage an enterprise network that supports employees, services, devices, and business-critical operations around the world. Over […]

The post Turning network configuration management into a conversation at Microsoft with Autonet AI Agent appeared first on Inside Track.

]]>
Network engineers at Microsoft rarely struggle because they lack the tools to do their work. The challenges appear when they need to access too many tools spread across too many workflows.

At Microsoft Digital, the company’s IT organization, we manage an enterprise network that supports employees, services, devices, and business-critical operations around the world. Over the years, we’ve invested heavily in automation, infrastructure as code, and self-service capabilities to improve consistency and reduce operational overhead.

But as our environment has grown, so has the number of systems, workflows, repositories, and tools that our engineers have to navigate. So we decided to take a different approach. We asked, “What if engineers only needed to describe the outcome they wanted, instead of manually figuring out which tools to use?”

That idea became the foundation for Autonet AI Agent, our natural language platform for network configuration management that is saving us time and driving greater efficiency for our engineering teams.

Creating a ‘conversational front door’

In the past, our network engineers often needed to know where information lived before they could solve a problem. Different workflows required different tools, and different tasks relied on familiarity with a variety of systems.

A single network request could start a complex workflow. where engineers needed to gather information from multiple tools and systems. They might use one tool to review existing configurations, another to validate the current state, and still others to identify affected devices, generate changes, prepare rollback plans, and route updates through established governance processes.

Autonet AI Agent simplifies that process by giving our engineers a single place to start.

When engineers access the portal, they use natural language to describe the outcome they’re looking for. We describe it as a “conversational front door.”

The agentic platform gathers the required information and context, then coordinates the appropriate actions. It also alerts a human engineer for approval before making any changes.

Specialized agents support specific network configuration tasks. For example, our IP Helper Agent retrieves IP helper data. Our Core WAN agent manages configuration templates.

A photo of Tiruvuri.

“The goal was to create a conversational front door that could connect people with the right network data, workflows, and specialist capabilities without requiring them to understand everything happening behind the scenes.”

Sai Madhav Tiruvuri, senior product manager, Microsoft Digital

Agents also work together more broadly. For example, our IP Helper Agent can connect with our Intake Agent, which is responsible for handling incoming workflows. Autonet AI Agent coordinates these workflows, reducing the number of systems that network engineers manage directly.

“We wanted engineers to focus on outcomes rather than tooling,” says Sai Madhav Tiruvuri, a senior product manager in Microsoft Digital. “The goal was to create a conversational front door that could connect people with the right network data, workflows, and specialist capabilities without requiring them to understand everything happening behind the scenes.”

It wasn’t just up to our platform team to develop the agents that make up this solution. Because we’re committed to Frontier Transformation at Microsoft, we’re actively exploring ways for every team to put AI to work, build trust, and scale transformation across everyday workflows.

As a result, we’ve been empowering different network engineering teams to build their own agents. To support their work, we’ve implemented review and governance processes to ensure they meet our standards for security, privacy, and responsible AI.

As we created Autonet AI Agent, we collaborated with those teams to understand their needs. From there, we incorporated the agents they had already created into the platform by designing the portal, shell, components, and model context protocol (MCP) rules and servers that connect all of the pieces.

This approach capitalizes on the expertise of teams that know the work best while giving our engineers a simpler experience overall. It also allows the platform to accommodate new capabilities. We can add new agents for specialized tasks behind one consistent interface, and engineers will use the same entry point as new workflows and agents become available.

Building on a trusted source of truth

Before we introduced agentic AI into network engineering workflows, we focused on something more fundamental: trusted data.

We knew that any agentic experience would only be as useful as the information available to the agent in question. Rather than connecting AI to multiple disconnected systems, we grounded it in a single, governed source-of-truth repository that captures configuration data.

This repository provides a common foundation for engineers, APIs, partner tools, automation workflows, and AI-powered experiences. As a result, we can funnel trusted network data through a consistent interface.

The lesson applies beyond networking. Any organization that’s interested in agentic workflows should first focus on establishing authoritative operational data.

A photo of Mango.

“The opportunity wasn’t simply to replace our existing automations. We wanted to reduce the effort required to prepare work for automation and help engineers move more quickly from intent to action.”

Faris Mango, principal software engineering manager, Microsoft Digital

The quality of the experience depends on the quality of the underlying source of truth. From there, AI can help users find, understand, and act on information.

Combining AI with deterministic automation

Many network operations processes are deterministic by design. Validation routines, deployment pipelines, approval workflows, and configuration distribution systems all depend on predictable and repeatable outcomes.

As part of our agentic workflows, existing automation continues to perform deterministic steps. But on top of those more rigid automations, our new agents support processes that require interpretation, coordination, and connections across systems.

This division of work became an important design principle. We use AI for interpretation and coordination, and deterministic automation for predictable execution.

“The opportunity wasn’t simply to replace our existing automations,” says Faris Mango, a principal software engineering manager in Microsoft Digital. “We wanted to reduce the effort required to prepare work for automation and help engineers move more quickly from intent to action.”

Making network engineering jobs easier

Network configuration rendering and validation was one of our first use cases.

Configurations rely on templates, business logic, and facts stored in source-of-truth systems. Small changes can affect how we render configurations across multiple device types and deployment scenarios.

Traditionally, testing those changes could require significant manual effort. Engineers might need to compare template versions, validate outputs, investigate unexpected behavior, and move information between systems.

With Autonet AI Agent, users initiate those workflows in one place using natural language. Engineers can retrieve network facts, render configurations using current source-of-truth information, compare results across versions, identify differences, and investigate issues in a process that looks more like a conversation than navigating a series of tools.

A photo of Panakanti.

“The more conversational experience makes it easier to test changes, compare outputs, understand what changed, and continue iterating until the configuration behaves the way you expect.”

Pruthvish Panakanti, senior network engineer, Microsoft Digital

Imagine a network engineer who receives a ticket requesting a configuration update. Once they’ve accessed Autonet AI Agent, the platform would execute the following steps as part of an agentic workflow:

  1. Interpret the request’s intent
  2. Identify affected devices and locations
  3. Retrieve relevant configuration information
  4. Compare current and intended states
  5. Detect potential conflicts
  6. Generate proposed configuration updates.
  7. Create rollback guidance
  8. Produce reviewable artifacts

“Rendering and validating changes used to involve a lot of manual comparison,” says Pruthvish Panakanti, a senior network engineer in Microsoft Digital. “The more conversational experience makes it easier to test changes, compare outputs, understand what changed, and continue iterating until the configuration behaves the way you expect.”

The benefit extends beyond the configuration change itself. Before engineers can decide what to do, they need to assemble a reliable picture of the current environment and understand how a proposed update might affect it. That preparation can require gathering network facts, reviewing existing configurations, comparing intended and current states, and identifying potential conflicts.

A photo of Kuilan.

“A significant amount of operational work happens before we ever make a configuration change. Engineers spend time gathering context, validating information, and making sure they have what they need. That’s where these conversational workflows remove friction.”

Christopher Kuilan, senior cloud network engineer, Microsoft Digital

Autonet AI Agent brings those steps into a connected workflow. Instead of manually moving information between systems, engineers can use a conversational experience to retrieve relevant context, examine differences, and develop a proposed change for review. The platform can also prepare supporting artifacts and rollback guidance, helping engineers evaluate the change before deciding whether it should proceed.

This allows engineers to spend less time assembling the inputs needed for a decision and more time applying their expertise. The platform does not remove that responsibility. It makes the information easier to access and review while keeping engineers in control of the final decision.

“A significant amount of operational work happens before we ever make a configuration change,” says Christopher Kuilan, a senior cloud network engineer in Microsoft Digital. “Engineers spend time gathering context, validating information, and making sure they have what they need. That’s where these conversational workflows remove friction.”

Preserving governance and human review

Introducing AI into infrastructure operations requires robust governance. Throughout development, we prioritized human-in-the-loop oversight as a requirement.

For us, trust depends on transparency. Engineers need visibility into how agents generate recommendations and the ability to inspect supporting information before taking action.

A photo of Sullivan.

“We wanted to make it easier for engineers to get the information they need while keeping governance and review in place.”

Darron Sullivan, principal software engineer, Microsoft Digital

Autonet AI Agent can retrieve information, prepare recommendations, generate artifacts, and help users understand potential actions. But engineers remain responsible for reviewing recommendations and determining whether proposed changes should move forward.

When an agent proposes an action or change, the platform alerts an engineer and waits for approval.

“Agentic systems are most effective when they’re working in established operational controls,” says Darron Sullivan, a principal software engineer in Microsoft Digital. “We wanted to make it easier for engineers to get the information they need while keeping governance and review in place.”

Looking ahead

We’re currently piloting Autonet AI Agent across a relatively small set of processes, but we see it as the beginning of a broader platform approach rather than a standalone solution.

A photo of Thompson.

“When we can bring the right information, automation, and specialized capabilities together through one experience, our engineers can spend less time figuring out which system to use and more time applying their expertise to the network.”

Jason Thompson, principal group product manager, Microsoft Digital

And we’ve already seen impressive results. In some cases, IP helper data retrieval that used to take up to three weeks can now be accomplished within a day or less.

The conversational front door gives us a framework for introducing additional specialist capabilities over time while still maintaining a consistent user experience. As more workflows and domains become available, engineers can continue interacting through a familiar interface while the platform expands behind the scenes.

“When we can bring the right information, automation, and specialized capabilities together through one experience, our engineers can spend less time figuring out which system to use and more time applying their expertise to the network,” says Jason Thompson, a principal group product manager in Microsoft Digital. “That’s where we see the real value of this technology.”

Autonet AI Agent reflects how we’re applying agentic AI to our own network operations at Microsoft. Organizations interested in building similar agentic experiences can explore the Microsoft agent ecosystem to determine the right approach for their needs. Get started with Microsoft Agent 365 to manage and govern agents across your organization or explore our agent development tools to build your own solutions.

Key takeaways

Our experience building Autonet AI Agent reinforced a number of specific recommendations that can help your organization build a similar solution:

  • Prioritize AI-ready data. Establish a governed source of truth before introducing AI into operational workflows.
  • Focus on tasks and results. Design experiences around outcomes rather than tool selection.
  • Choose the right automation approach. Discern where deterministic automation makes sense, and what agentic workflows can take over. Use AI where intent interpretation, context gathering, and validation add value.
  • Keep humans in the loop. Maintain human review and existing governance controls. Prioritize transparency so users can understand and validate recommendations.
  • Future-proof your platform. Build orchestration layers that allow specialized capabilities to evolve and can include new agents over time.

Try it out

Related links

The post Turning network configuration management into a conversation at Microsoft with Autonet AI Agent appeared first on Inside Track.

]]>
25821
AI-ready data: Building the foundation for enterprise AI at Microsoft http://approjects.co.za/?big=insidetrack/blog/ai-ready-data-building-the-foundation-for-enterprise-ai-at-microsoft/ Thu, 15 Oct 2026 16:00:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=25717 For years, organizations have treated data as a critical business asset. Here at Microsoft, data powers our reporting, supports our decision-making, and helps our leaders understand what’s happening across our teams responsible for our enterprise data. But agentic AI has raised the stakes, making data quality more consequential. Frontier Firms like ours depend on high-quality […]

The post AI-ready data: Building the foundation for enterprise AI at Microsoft appeared first on Inside Track.

]]>
For years, organizations have treated data as a critical business asset.

Here at Microsoft, data powers our reporting, supports our decision-making, and helps our leaders understand what’s happening across our teams responsible for our enterprise data.

But agentic AI has raised the stakes, making data quality more consequential. Frontier Firms like ours depend on high-quality data to support agents, automation, and employee decision making.

Today’s AI models can produce sophisticated summaries, answer complex questions, and help employees work more efficiently. Agents and reasoning systems increasingly connect data across business functions, perform multistep tasks, and help automate decisions and workflows.

That shift has led our teams in Microsoft Digital, the company’s IT organization, to ask a new question: What does it mean to have data that’s fully AI-ready, and where are we on this journey?

Measuring data quality is just one part of the answer.

A photo of Tripathi.

“World-class AI agents start with AI-ready data, with the right foundation. That means more than simply making data available. It requires quality, governance, and consistent standards so that AI systems can understand the data, trust it, and use it effectively.”

Naval Tripathi, principal engineering manager, Microsoft Digital

In Microsoft Digital, we’re creating a repeatable framework for AI-ready data that combines governance, discoverability, semantics, context, ownership, lineage, security, and quality into an overall foundation. This framework helps AI systems interpret enterprise data and use it appropriately.

“World-class AI agents start with AI-ready data, with the right foundation,” says Naval Tripathi, principal engineering manager in Microsoft Digital. “That means more than simply making data available. It requires quality, governance, and consistent standards so that AI systems can understand the data, trust it, and use it effectively.”

Treating AI readiness as a business capability                         

One of the key lessons from our focus on AI-ready data here in Microsoft Digital is that readiness can’t be treated as a one-time cleanup project.

A photo of Dinde.

“We decided to focus on continuous data readiness, rather than a one-time certification process. You really can’t say, ‘OK, it’s all done now.’ We have to keep learning about and updating metadata and governance information to improve how AI uses data.”

Aishwarya Dinde, senior software engineer, Microsoft Digital

Data changes. Systems evolve. New business requirements emerge. AI capabilities continue to advance. So, we are approaching readiness as an ongoing business capability.

AI-ready data characteristics

Interoperability

Assesses whether data can be easily joined or reasoned upon across different domains and systems

Observability

Detects when pipelines break, drift occurs, or anomalies arise, so that issues surface before they impact AI models

Ethical and responsible use

Considers whether datasets are evaluated for bias, representation, and consent, ensuring responsible AI deployment

Structure and modelability

Determines whether data is organized for immediate model consumption, minimizing manual feature engineering

Documentation and context

Evaluates whether datasets carry clear business definitions, assigned owners, and documented usage guidance readable by AI models 

Accessibility and availability

Checks whether datasets meet the latency and uptime standards that AI systems require for reliable, performant access 

Governance and security

Ensures that data is used in compliance with policies and protected from misuse via labeling, access control, and audit logging

“We decided to focus on continuous data readiness, rather than a one-time certification process,” says Aishwarya Dinde, a senior software engineer in Microsoft Digital. “You really can’t say, ‘OK, it’s all done now.’ We have to keep learning about and updating metadata and governance information to improve how AI uses data.”

These data-readiness signals help determine whether the data is discoverable, reliable, understandable, and appropriate for AI-driven scenarios. Rather than just looking at a data-quality score, we’re creating a systematic way to identify where investments in data will likely have the greatest impact.

AI changed the standards for quality data

Many data platforms were originally designed to support analytics and reporting, which are human-centered activities. These platforms were designed primarily for human analysis, not for AI agents that need explicit business context.

A photo of Uribe.

“In the past, data was something humans used to get information and provide business insights. With AI, we are expecting the models to reason over the data. There is a need to ensure the data is ready for that and represents the business correctly.”

Miguel Uribe, principal PM manager, Microsoft Digital

In that era, humans supplied the context around these applications of data. Business analysts understood company terminology. Data engineers knew where information came from. Subject matter experts filled in gaps that weren’t captured inside the data itself.

AI systems have changed all this.

“In the past, data was something humans used to get information and provide business insights,” says Miguel Uribe, a principal PM manager in Microsoft Digital. “With AI, we are expecting the models to reason over the data. There is a need to ensure the data is ready for that and represents the business correctly.”

AI systems need explicit guidance about what data represents and how it should be used. Column names, metadata, ownership information, business definitions, descriptions, lineage records, and usage guidance all help AI understand what the data means and how it should be used.

In one example from our networking environment, an internal system used “Pigeon,” an internal name for a networking system, in its title. Without that context, an AI system interpreted “Pigeon” literally and incorrectly inferred that the data set was about birds rather than network infrastructure.

This is where human effort is needed to make sure that context is present and accurate.

“There’s a lot of retrofitting that needs to be done—human effort to contextualize the data,” says Diego Baccino, principal software engineering manager in Microsoft Digital. “AI doesn’t understand the business context. That’s where the human capital becomes really valuable. Once the context is added, then AI can really take it forward.”

This doesn’t mean that AI doesn’t play a role in the data-readiness process. AI-driven tools are increasingly used to detect data problems, and people decide what to do about them. We regularly run automated checks against our readiness criteria, flagging data that is stale, incomplete, or inconsistent with its documentation..

AI can also draft data descriptions for engineers to review and correct. This approach helps teams scale readiness work while keeping people accountable for accuracy and business context.

This realization about the importance of context led the Microsoft Digital data council and AI Center of Excellence—two vital aspects of our Frontier Firm move into agentic AI—to expand their focus beyond traditional governance and data-quality efforts. The goal was to create a common understanding of what AI-ready data means for the different teams that are responsible for our data across the enterprise.

“Metadata and context are part of the product at this point,” says Aira Agrawal, a product manager in Microsoft Digital. “Just having the data available isn’t enough anymore. Without that context, it’s not usable in the age of AI.”

As a result, our teams in Microsoft Digital are increasingly working to make data context discoverable and reusable, reducing the dependence on tribal knowledge that previously existed only in conversations and scattered documentation.

Measuring readiness before scaling AI

As groups across Microsoft have increased their investments in AI, our leaders are now asking questions about data readiness. Our mission in Microsoft Digital is to come up with accurate ways to make this readiness measurable.

A photo of Wan

“Our progression towards AI-ready data is going to be one of those key metrics that get looked at month over month. It’s becoming a super-critical metric for the organization, to ensure that all of our solutions are leveraging AI-ready data.”

Myron Wan, principal group product manager, Microsoft Digital

We now evaluate our data across multiple dimensions, including quality, governance, discoverability, interoperability, accessibility, observability, and contextual understanding. These dimensions help teams understand where gaps exist and where remediation efforts should be prioritized.

Historically, data quality was more of a technical concern discussed by engineering teams. Microsoft Digital is elevating data readiness to a business conversation tied directly to AI outcomes.

“Our progression towards AI-ready data is going to be one of those key metrics that get looked at month over month,” says Myron Wan, principal group product manager in Microsoft Digital. “It’s becoming a super-critical metric for the organization, to ensure that all of our solutions are leveraging AI-ready data.”

If a particular data set isn’t ready for its intended AI use, leaders can weigh the business value against the investment needed to address the gaps. “If your data score is telling you it’s not ready, then you can pose the question: Should we fast-track this and invest more in making the data AI-ready?” Uribe says. “That enables us as business decision-makers to prioritize where we’re going to put our money and our AI investments.” 

Using AI to breakdown business silos

Across Microsoft, teams are exploring scenarios where AI systems help identify problems, gather information, and support operational decision-making. Those scenarios depend heavily on trusted data foundations.

A photo of Agrawal.

“We’re moving into a world where our data sets are not going to be in silos anymore, especially as all our organizational data moves into Microsoft Fabric. Networking, HR, finance, they’re all going to have their data in Fabric. This means we can tell stories across the business with connectors and APIs, unlocking more advanced analytics.”

Aira Agrawal, product manager, Microsoft Digital

Future AI systems may increasingly operate across domains, drawing information from disparate groups such as IT, HR, finance, operations, and other areas. That requires data that’s accessible and that also meets this new, higher bar for readiness.

We’re already seeing opportunities to use AI to connect information across previously separate domains, creating richer business insights and supporting more advanced forms of analysis.

“We’re moving into a world where our data sets are not going to be in silos anymore, especially as all our organizational data moves into Microsoft Fabric,” says Aira Agrawal, a product manager on the Infrastructure Data Lake team. “Networking, HR, finance, they’re all going to have their data in Fabric. This means we can tell stories across the business with connectors and APIs, unlocking more advanced analytics. It’s a really cool thing we’re enabling.”

Our long-term goal is to give business teams trusted data and shared foundations so they can create AI-enabled workflows without depending on central teams for every solution. Instead, we want individual business teams to be able to create their own AI-enabled workflows that operate across domains, knowing that the data they’re relying on is AI-ready.

The future of AI-ready data

Our work with AI-ready data continues to evolve.

The company is still refining readiness models, governance approaches, access patterns, and future capabilities. Our subject matter experts acknowledge that some challenges remain unresolved, including how best to provide business context at scale and how readiness should continue evolving alongside AI technologies and regulatory requirements.

A photo of Baccino.

“Whatever technologies you’re using, don’t miss the boat on contextualizing your data and making it AI-ready. The longer you wait, the longer it takes to realize AI value.”

Diego Baccino, principal software engineering manager, Microsoft Digital

Yet several key lessons have already emerged:

  • Visibility matters. Organizations need to know what data they have and who owns it.
  • Governance remains critical, but governance alone isn’t enough.
  • Semantics and business context increasingly determine whether AI can use data effectively.
  • Readiness must become repeatable across teams rather than dependent on individual experts.

And perhaps one of the most important lessons: Don’t wait to get started. Data readiness is too crucial a factor for business success in the age of AI to put off dealing with the challenge.

“Whatever technologies you’re using, don’t miss the boat on contextualizing your data and making it AI-ready,” Baccino says. “The longer you wait, the longer it takes to realize AI value.”

Key takeaways

Organizations preparing for enterprise AI should keep these tips in mind as they embark on their own data-readiness journey:

  • AI-ready data requires more than making information available. AI systems also rely on business context, ownership information, lineage, and semantic meaning to reason effectively over data.
  • Treat readiness as an ongoing capability rather than a one-time project. Data, business processes, AI technologies, and regulatory requirements continue to evolve, and so should your data-readiness efforts.
  • Measure readiness before scaling AI initiatives. Readiness scoring helps identify gaps and prioritize investments where they will have the greatest impact.
  • Make business context part of the data product. Metadata, descriptions, and business definitions are increasingly as important as the data itself.
  • Build foundations that enable teams to create their own AI solutions. Trusted data, governance, and discoverability help business groups develop AI-enabled workflows without relying on central engineering teams.
  • Start your work early. Organizations that postpone making data AI-ready may find it harder to realize value from future AI investments.

Try it out

Related links

The post AI-ready data: Building the foundation for enterprise AI at Microsoft appeared first on Inside Track.

]]>
25717
Our Customer Zero guide: Enabling agent creation across Microsoft 365 Copilot, Copilot Studio, and Foundry http://approjects.co.za/?big=insidetrack/blog/our-customer-zero-guide-enabling-agent-creation-across-microsoft-365-copilot-copilot-studio-and-foundry/ Thu, 08 Oct 2026 16:00:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=25571 Generating value by empowering your employees to build agents AI agents are an increasingly important way for organizations to scale knowledge, help their employees boost productivity, and automate business processes. In Microsoft Digital, the company’s IT organization, we think of agents as more than tools that the company rolls out and employees adopt. They represent […]

The post Our Customer Zero guide: Enabling agent creation across Microsoft 365 Copilot, Copilot Studio, and Foundry appeared first on Inside Track.

]]>

Generating value by empowering your employees to build agents

AI agents are an increasingly important way for organizations to scale knowledge, help their employees boost productivity, and automate business processes.

In Microsoft Digital, the company’s IT organization, we think of agents as more than tools that the company rolls out and employees adopt. They represent a new way of working, where employees have the power to create and modify their own AI tools to help them solve problems, streamline their work, and create value in their unique roles.

As our use of AI has matured, we’ve seen employees across the company identify opportunities to create agents that help them retrieve information, answer common questions, automate repetitive tasks, and reimagine workflows. Rather than limiting agent creation to developers, we’ve made agent-building capabilities available for every employee at Microsoft. Our goal is to enable the people closest to the work to build their own agentic solutions.

Meeting the needs of different builders across the organization

As we expanded agent adoption across Microsoft, we quickly discovered that not all employees need to build the same kinds of agents. A knowledge worker who wants to create a simple retrieval agent for a project team has very different requirements from a business unit building workflow automations or an engineering organization tasked with creating enterprise-scale agentic solutions.

In the course of this journey, we’ve faced a challenge that’s becoming common for many organizations: Equipping different groups of employees to build agents without forcing everyone into the same development model.

A photo of Chand

“Frontier transformation depends on empowering every employee to turn ideas into AI-powered solutions. This democratization of AI creation can unlock new levels of productivity, innovation, and business value.”

We’ve learned that effective agent enablement is about matching the right tools to the right builders and scenarios:

  • Some employees benefit from natural-language tools that allow them to build agents with little or no technical experience.
  • Others need low-code environments that support more sophisticated workflows and integrations.
  • Still other workers require pro-code platforms that provide the flexibility, extensibility, and governance needed for enterprise-scale solutions.

Creating pathways for every type of agent builder

Our approach has been to enable a spectrum of agent-building pathways that meet employees where they are. We focus on providing clear guidance, skilling resources, governance frameworks, and tool recommendations that help people move from ideas to working solutions with the appropriate level of complexity and oversight. Crucially, this approach helps us ensure innovation can scale responsibly as agent usage continues to grow.

“Frontier transformation depends on empowering every employee to turn ideas into AI-powered solutions,” says Mohit Chand, general manager of Corporate Functions Engineering in Microsoft Digital. “This democratization of AI creation can unlock new levels of productivity, innovation, and business value.”

In this IT playbook, we’ll share how we’ve approached agent enablement across Microsoft, how we think about different agent-building audiences and tools, and the lessons we’ve learned along the way. We believe these insights can act as a blueprint for your own strategy as you empower employees to build agents with confidence, regardless of their level of technical knowledge.

Chapter 1: Choosing the right path for agent creation

Laying the foundation for different builders to meet their needs with agents

As agent creation became more widespread at Microsoft, one question stood out: How could we help employees use the tool that’s best for the problem they’re trying to solve or the opportunity for innovation they’re trying to explore?

Early on in our journey, we observed a common pattern: Employees would often gravitate toward the most powerful and flexible tools available because they seemed like the safest choice. If a platform could handle every scenario, why not start there?

In practice, that approach often introduced unnecessary complexity. Some builders found themselves navigating security, privacy, and compliance requirements that far exceeded the scope of their projects, let alone their level of technical expertise. Others invested time learning advanced capabilities they ultimately never needed to use.

A photo of Jangir

“The most successful agents often start with a practical business problem. Once builders see the results, they quickly discover new opportunities to automate and improve adjacent processes.”

We’ve learned that enabling successful agent building depends on providing the right development path. The goal is to help employees innovate quickly with AI agents while applying the right level of governance and technical complexity. When employees start with a clear objective and work backwards from there, they tend to build faster, encounter fewer obstacles, and achieve stronger results.

“The most successful agents often start with a practical business problem,” says Naveen Jangir, a principal architect in Microsoft Digital. “Once builders see the results, they quickly discover new opportunities to automate and improve adjacent processes.”

We also learned that choosing the wrong tool can have unintended consequences. Employees may run into compliance reviews they weren’t expecting. Projects might slow down as builders try to understand governance processes.

Choosing the tool that isn’t the right fit for a builder’s scenario might also direct them to the wrong model for their agent. In some cases, that could lead to using something more complex and expensive instead of a lower-cost model that’s ideal for a simpler scenario. More advanced tools often assume more advanced models that aren’t inherently necessary for every task.

In some cases, builders abandon promising ideas before they deliver value. The result is losing out on innovation, not because an idea wasn’t worthwhile, but because the path to implementation became more difficult than necessary.

To avoid these situations, we encourage builders to start by considering their problem scenario, rather than the tool itself. When evaluating an idea, we ask employees to think through a few key questions:

  • What business outcome are they intending to achieve?
  • What data does the agent need to access?
  • Is that data personal, team-based, or enterprise-wide?
  • Is the agent retrieving information, taking actions, or operating autonomously?
  • How broadly do they intend to share the agent?

Understanding the needs of different builders

Roughly speaking, we describe agents as belonging to three categories, ranging from simpler and lower risk to more complex and more reliant on sensitive or external data.

A graphic demonstrating the spectrum of simple to advanced agents, running from retrieval through task and autonomous agents.
Different agent-creation tools cover different areas of the development spectrum, ranging from simpler to more advanced agentic solutions.

As AI maturity at Microsoft has advanced, three primary sets of needs and cohorts of agent builders have emerged, based on user scenarios, needs, and technical capability.

1. Simple retrieval agents for any employee: Agent Builder in Microsoft 365 Copilot

The first cohort consists of employees solving everyday productivity challenges. These builders need agents that retrieve information, summarize content, answer questions, evaluate inputs against a declared rubric to provide feedback, and help them work more efficiently with existing knowledge sources.

For these scenarios, Agent Builder in Microsoft 365 Copilot provides an accessible starting point. Employees can use natural language to create lightweight retrieval agents grounded in their Microsoft 365 knowledge and data. It lets employees begin creating value without requiring extensive technical skills or development experience.

Many employees discover that this level of functionality meets their needs. By starting here, they can experiment quickly without introducing unnecessary complexity.

2. Citizen development without DevOps overhead: Microsoft Copilot Studio

Some employees want agents to do more than retrieve information. These builders need tools that can connect to business systems, automate workflows, orchestrate processes, and take actions on behalf of users.

Copilot Studio serves as an important middle ground for agent development, supporting retrieval, task, and autonomous agent scenarios while providing access to a broad ecosystem of connectors and integrations. It combines low-code development with broader connector capabilities, workflow automation, built-in telemetry, and evaluation tools.

These features allow employees to create more sophisticated business solutions without needing to be professional software developers.

3. Professionally developed agents that meet organizational needs: Microsoft Foundry and pro-code tools

The most complex and flexible tools are primarily the domain of professional developers and engineering teams building line-of-business or enterprise-scale solutions. These builders need architectural control, advanced integrations, specialized security requirements, and custom orchestration capabilities. For these scenarios, Microsoft Foundry and other pro-code pathways like Microsoft 365 Agents Toolkit provide the flexibility they need to design highly customized systems.

But they also introduce additional responsibility. Teams operating at this level assume ownership for architecture, compliance, privacy, security reviews, operational monitoring, and lifecycle management.

The distinction is important. Advanced development platforms create tremendous possibilities, but they’re most effective when a scenario truly requires that level of control.

A photo of Wan

“Get people excited about agents first, and then educate them. Encourage people to become builders and get their hands dirty through advocacy and education.”

These aren’t rigid boundaries, but they’re helpful in understanding what each agent creation tool can accomplish. We’ve distilled our perspective into the following list of characteristics of different agent builders and of the creation platforms most appropriate for their needs:

Agent Builder in Microsoft 365 Copilot

  • Low difficulty
  • For all roles
  • Function: information-retrieval only
  • Microsoft 365 content and web sources
  • Light governance
  • Low risk

Microsoft Copilot Studio

  • Low to moderate difficulty
  • For all roles
  • Function: task completion
  • Microsoft 365 content plus connectors to other data sources and platforms
  • Advanced governance
  • Higher potential for risk

Microsoft Foundry, Agent Toolkit

  • Highest difficulty
  • For developers
  • Function: workflow automation
  • Multiple internal and external channels
  • Advanced governance
  • Highest potential for risk
  • Highest level of capability

Whatever your potential builder’s level of expertise or needs, we’ve discovered that encouraging experimentation while providing learning opportunities is key.

“Get people excited about agents first, and then educate them,” says Myron Wan, a principal group product manager in Microsoft Digital. “Encourage people to become builders and get their hands dirty through advocacy and education.”

What IT organizations should consider

In Microsoft Digital, our objective is to enable innovation while maintaining appropriate safeguards.

Good agentic architecture starts with data

Whenever we’re considering any agent development path, data is at the center of our thinking. Where data resides, how agents access it, who can use it, and the actions agents will execute with it form the foundation of every agent-building solution. In many cases, the data itself determines the appropriate platform.

We take a “self-service with guardrails” approach to our productivity estate, which means we give employees the ability to create new workspaces across their Microsoft 365 applications while securing assets by default and expanding access based on employee needs. The same is true for agent creation. We rely on well-established governance in the form of sensitivity labels, established software development lifecycle procedures, and risk-based app and agent management policies that trigger reviews when we detect risk.

We also frame governance in terms of who owns the risk: the platform itself, the administrator, or the organization.

  • Agent Builder operates according to intrinsic governance, where the platform itself is responsible for managing risk. Users build agents within existing Microsoft 365 boundaries, which include built-in guardrails that simplify governance for lower-risk scenarios. Builders can create meaningful experiences while staying within well-understood security and compliance frameworks.
  • Copilot Studio follows a configurable governance model where the administrator owns the risk. It introduces greater flexibility through workflows, actions, and connectors. That flexibility creates powerful opportunities, but it also requires thoughtful governance around how data moves between systems and which connectors are approved for use.
  • Microsoft Foundry features explicit governance, where the organization owns the risk. That need arises from more complex capabilities like model selection, custom orchestration, architectural design capabilities, and more.

Regardless of the agent-creation platform your employees use, investing in data classification, labeling, and governance will put you in a better position to scale safely.

AI-ready data is especially crucial for more advanced agent creation tools like Foundry. It ensures secure access to the high-quality, accurate information employees need when they need it.

AI-ready data rests on five pillars:

  • Accelerating time to value through managing powerful AI models
  • Data democratization to promote informed decision-making, innovation, and continuous learning
  • Connectivity among subject matter experts across domains and regulatory divisions to accelerate innovation
  • Quality and governance to maintain data accuracy, reliability, and compliance
  • Unification, delivering accessible and scalable infrastructure by breaking down silos

Balancing risk and innovation

A risk-based approach informs one of our primary guiding principles: reviews should scale with risk.

Thanks to the guardrails we’ve established, we don’t subject a personal productivity agent created in Agent Builder to the same review process as an autonomous agent operating across enterprise systems. The result is a matrixed model of agent governance that matches the need for oversight and review to the level of risk, access, or action-taking ability an agent presents.

This principle helps employees experiment early, validate ideas quickly, and gain confidence as builders. It also helps us avoid creating unnecessary barriers that can discourage adoption before builders can realize value.

We also learned that excessive control isn’t necessarily a safe default; it’s another category of risk. Over-restriction doesn’t eliminate risk, but redirects it to shadow AI, where we lose both productivity and compliance visibility.

Before setting your employees free to create, speak with stakeholders from IT, security, privacy, legal, compliance, data, and other teams responsible for policy and protection. Together, these groups can help you work toward a cohesive but flexible approach to agents and the risks they present.

Throughout this process, it’s important to stay curious about the processes builders will face before, during, and after creating their agents. Administrators should ask several key questions:

  • What is the origin of this process, how relevant is it for agent creation, and which products are affected?
  • What can we do to remove friction and allow safer innovation?
  • Where can we get involved with processes when agents present more risk, while allowing agents that meet our standards to get built and shared broadly, with minimum friction?

Adoption through intention

We’ve invested a lot of time, strategy, and effort into adoption efforts across Microsoft. First, builders can use self-serve tools to meet their own needs. Builders Central is our internal SharePoint page dedicated to supporting agent builders at Microsoft. Crucially, it features a section that helps people understand which agent-creation tool might be best for them, along with instructions and factors to consider throughout the process.

AskMica (Ask Microsoft Intelligent Compliance Agent) is our IT agent built on top of this content. It walks makers through the decision-making process and answers questions about what tool to use, what environment to choose, how to get exceptions for security, privacy, sensitive data access, and more.

AI Skills Navigator, a program now available to customers, extends AI learning by allowing leaders to create structured paths that guide teams toward specific outcomes, such as becoming AI literate, managing agents in the enterprise, or building expertise in agent development. In Microsoft Digital, we’ve tailored AI Skills Navigator content to differentiate learning for our IT employees.

This is an essential piece of the equation, because IT teams are so integral to AI implementation efforts. As you promote AI more widely, it’s important to ensure your own IT team has the skills they need to support this technology.

Since we’ve put these efforts in place at Microsoft, the number of active makers has grown roughly 10 times, from around 2,000 to 20,000 a month. We now have about 150,000 personal development environments under governance, and we drove measured maker friction down from roughly 50% to 5%.

Letting outcomes drive platform selection

We encourage teams to focus on business outcomes first. Before selecting a platform, builders should identify the process they want to improve, define success criteria, and determine whether an agent is the best solution. We have an entire SharePoint site dedicated to helping employees navigate agent creation, including decisions around which agent tool to choose.

In some cases, a traditional workflow, existing application, or agent that someone else has already created may be the better choice. But if an employee or team sees a genuine need, starting small allows them to validate assumptions, measure impact, and expand capabilities over time.

As you consider ways to empower your own employees to create agents of their own, the lessons we’ve learned can form a foundation for creating policy, enabling workers, and protecting your organization.

Key takeaways

As you look for ways to empower your own employees to create agents, the lessons we’ve learned building our approach at Microsoft can serve as a guide:

  • Start with the business problem, not the development tool. Encourage employees to think about what they’re trying to accomplish before beginning.
  • Choose the right platform for the job. Throughout your enablement and adoption efforts, teach employees to evaluate data requirements, impact, and sharing needs before selecting a platform that meets their scenario’s requirements.
  • Reviews should scale with risk and business impact. Build systems that only create review workflows on agents that genuinely pose risk. With the right guardrails in place, simple agents may qualify for streamlined or automated review.
  • Treat governance as an enabler. Embed guardrails into platforms, data, and processes, so employees can build and experiment confidently without exposing the organization to unnecessary risk or slowing progress.
  • Tailor metrics to goals. A governance team that tracks only compliance metrics will optimize for restriction. Add adoption metrics to your security dashboard that include measures like active makers, time to production, and user friction scores, and the team’s behavior will change.

Learn more

How we did it at Microsoft

Further guidance

Chapter 2: Empowering every employee with Agent Builder

Giving employees a starting point for agent creation

As agents began to show their potential for significant impact on day-to-day work, we wanted employees across the organization to participate in creating them—not just developers and technical specialists. We found that the people closest to a business problem were often the ones best positioned to identify opportunities for AI to help. That insight helped shape our approach to Agent Builder in Microsoft 365 Copilot.

A photo of Heath.

“Everyone at Microsoft is a potential builder. The key is giving people opportunities to learn through hands-on experience, because reading about AI is very different from building with it. Agent Builder provides a safe environment where they can do just that.”

Agent Builder provides an accessible entry point into agent creation. Employees can create simple retrieval agents using natural language and ground them in approved knowledge sources, including SharePoint sites, websites, and Microsoft Graph connectors. The experience allows users to create agents that retrieve information, summarize content, answer questions, and help employees navigate organizational knowledge without requiring software development expertise.

The audience for Agent Builder is intentionally broad. It serves knowledge workers, subject matter experts, project teams, and employees looking to solve specific productivity challenges without learning advanced development tools. It also provides an important first step for employees who are new to building AI solutions.

“Everyone at Microsoft is a potential builder,” says Tom Heath, a change management lead in Microsoft Digital. “The key is giving people opportunities to learn through hands-on experience, because reading about AI is very different from building with it. Agent Builder provides a safe environment where they can do just that.”

Understanding Agent Builder’s place in the agent journey

Agent creation should scale with the complexity of the problem an employee wants to solve. Agent Builder creates agents devoted to knowledge-centric experiences: finding information, accessing expertise, navigating documentation, and surfacing insights from existing content.

We encourage employees to start with a simple question: Does this agent primarily need to help people find, understand, use, interpret, or validate information? If the answer is yes, Agent Builder is usually the right starting point.

Common use cases include team knowledge hubs, readiness and adoption resources, project-specific information assistants, meeting preparation support, and product or policy guidance. These scenarios allow employees to create immediate value without taking on unnecessary complexity.

As they experimented with agent building tools, many employees assumed they needed a more advanced platform than they actually did. In practice, we’ve observed that most use cases are knowledge-centric, and employees can address them effectively with Agent Builder.

A photo of Auguillard.

“Agents are only as good as the data behind them. Strong data governance and protection practices create the foundation for successful agent experiences.”

At the same time, it’s important to understand where the tool’s boundaries lie. Organizations should consider moving to Microsoft Copilot Studio when requirements expand beyond knowledge retrieval and begin to include higher-order capabilities:

  • Accessing data outside Microsoft 365
  • Integrating with external business applications
  • Automating business processes
  • Triggering workflows and actions
  • Including advanced telemetry and evaluation capabilities

This distinction helps employees select the right platform without overwhelming them with technical decisions: Agent Builder helps people interact with information, while Copilot Studio helps them take action on it.

The Customer Zero story: Implementing Agent Builder internally at Microsoft

Because Agent Builder is intentionally simple, most of our work enabling it within Microsoft has been organizational rather than technical.

Skilling and education

Employees understand Microsoft 365 Copilot, but they’re often less familiar with the role agents can play in their daily work. Successful adoption means helping people understand when prompting alone is sufficient and when an agent they build can deliver more value. Adoption initiatives like Agent Launchpad that feature hands-on ideation and gamified building activities have helped our employees make those leaps.

Agent sprawl

As adoption grows, organizations need visibility into what agents exist, who owns them, and whether they remain relevant over time. Ownership, automation, explicit lifecycle policy, and governance become increasingly important for monitoring the proliferation of agents. For example, we use a 60-day inactivity threshold that triggers alerts and automated cleanup. In this context, Microsoft Agent 365, the control plane for agents, is emerging as a powerful tool for observability, management, tracking, and security.

Data readiness

Agent Builder surfaces information users can already access, which means the quality of an agent experience depends heavily on the quality of the underlying data. We saw this principle in action repeatedly during our adoption efforts. Well organized, properly governed content consistently led to stronger agent experiences. Meanwhile, poorly maintained data limits an agent’s usefulness, regardless of how well it was designed. The systems we’ve put in place for governing agents provide the necessary guardrails for this level of agent.

“Agents are only as good as the data behind them,” says Ken Auguillard, a principal program manager in the Power Platform product group. “Strong data governance and protection practices create the foundation for successful agent experiences.”

We also found that many employees wanted agents to perform actions, automate workflows, or orchestrate processes across systems. Those are valuable scenarios, but they sit outside the scope of Agent Builder. Helping employees understand boundaries reduced frustration and created clearer pathways into Copilot Studio when additional functionality was needed.

Enabling Agent Builder at Microsoft

As adoption accelerated, our focus shifted from simply making Agent Builder available to helping employees use it successfully.

It may seem elementary, but people need to understand why they may want to create an agent instead of simply using Copilot. They do that by learning how agents apply AI capabilities more specifically than a broad-based assistant. Then, they need help knowing how to make their idea a reality.

We invested heavily in hands-on learning experiences. Employees learned fastest when they could experiment with real scenarios, test ideas, and refine agents in the context of their own work. Workshops, guided exercises, office hours, and peer-to-peer sharing all played important roles in helping employees build confidence. Real examples from early adopters were especially useful for encouraging people to take their first steps.

Our priority was making agent creation approachable, so we positioned Agent Builder as a capability available to everyone, not just technical users. We then encouraged employees to start with a business problem, build agents with a clear purpose, and focus on measurable outcomes rather than experimentation for its own sake.

We also emphasized thoughtful agent design. We found that employees who spent more time defining an agent’s purpose, instructions, and knowledge sources produced significantly better outcomes.

“Be direct, be descriptive,” Heath says. “Spending more time in the ‘Describe’ interface typically means spending less time troubleshooting later.”

Because Agent Builder benefited from the governance foundation already present in Microsoft 365, we had already embedded identity controls, permissions models, data loss prevention policies, sensitivity labels, and compliance protections within the environment. As a result, we didn’t need to invest too heavily in building employees’ understanding of governance structures. Instead, we could focus more on helping them understand how to use the platform effectively.

As a result, much of our enablement work centered on communication, celebrating wins, peer-led support, and helping employees understand where Agent Builder fit within the broader agent ecosystem.

Campaign Prediction Agent

Created using Agent Builder

The content team in Microsoft Digital is responsible for developing and executing content strategies that drive technology adoption, awareness, and excitement for Microsoft employees. They were looking for an easier way to predict the performance of internal communications campaigns.

Typically, people would have to sift through mountains of data to determine the potential reach and impact of a campaign. The team created the Campaign Prediction Agent to make it much easier.

The employee simply asks the agent to predict the performance of a particular internal campaign, and it returns a report that includes potential reach, overall effectiveness, and measurement confidence. The agent also breaks the data down by channel to help the team assess where they’ll make the maximum impact.

To ground the Campaign Prediction Agent in the necessary data, the team created a SharePoint folder that includes project-specific reports, multi-year and multi-channel analysis, benchmark data, and other useful information. That way, they maintain a robust grounding in data all in one place, making it easier for the agent to find what it needs and create helpful predictions in seconds.

For us, Agent Builder became an important foundation for employee agent creation. It provides a low-friction way for our employees to build, learn, and solve business problems quickly. While many builders remain within the platform long-term, others use it as a stepping stone to more advanced tools. In both cases, it helps create a culture where building with AI is accessible to everyone.

As you look for ways to empower a workforce of agent builders at your organization, consider ways that our efforts can provide a framework for secure and empowering experiences for employees who want to solve their day-to-day business challenges.

Key takeaways

As you consider using Agent Builder for employee-created agents, here are some factors to keep in mind:

  • Invest in hands-on learning. Give employees opportunities to build and test agents using real business scenarios. Practical experience is one of the most effective ways to build confidence and adoption, and Agent Builder provides a lower-complexity starting point for that kind of experimentation.
  • Help employees understand the boundaries of Agent Builder. The tool is ideal for knowledge-based and retrieval-focused experiences. More complex automation and action-taking scenarios may require Copilot Studio.
  • Prioritize high-quality instructions and knowledge sources. Clear descriptions, well-defined instructions, and trusted content sources are critical for creating effective agents.
  • Use simple retrieval agents as a springboard. Encourage employees to use Agent Builder first, then move on to more complex extensions that require a structured review process as needed.

Learn more

How we did it at Microsoft

Further guidance

Chapter 3: Leveling up citizen developers with Microsoft Copilot Studio

A bridge between simple and advanced agent development

Plenty of agentic scenarios require more than knowledge retrieval but less than a fully custom agentic application. At Microsoft, we wanted employees and teams to have the opportunity to connect their agents with business systems, automate workflows, retrieve information from external sources, and take action on behalf of users without necessarily demanding a full-featured DevOps process complete with reviews. We also wanted to provide greater capabilities while still allowing for a lightweight coding approach that accommodates citizen developers.

Copilot Studio is a low-code platform for creating agents that can automate processes, connect to enterprise systems, and extend Microsoft 365 Copilot with organizational data and business workflows. It supports both custom agent creation and agentic automations while remaining accessible to users without extensive software development experience. Everyone at the company has the freedom to create their own agents in their own Copilot Studio environment.

Unlike Agent Builder, which focuses primarily on knowledge-based experiences, Copilot Studio gives builders the tools to sync up agents to external systems through approved connectors, workflows, skills, and actions. These capabilities allow agents to move beyond answering questions and begin supporting real business processes.

“Once builders need data beyond Microsoft 365, connectors become a critical part of the solution. Copilot Studio is often the next step, because it lets teams combine enterprise data, workflows, and actions in a way that scales with business complexity.”

At Microsoft, we’ve identified several primary builder cohorts for Copilot Studio:

  • Citizen developers and makers who want to build beyond knowledge retrieval
  • Business teams that seek to automate departmental processes
  • Power Platform users who need to extend existing workflows
  • Technical teams that want low-code flexibility instead of moving to pro-code development

Understanding Copilot Studio’s place in the agent creation journey

One of the most important lessons we learned is that not every scenario requires Copilot Studio. In the simplest terms, agents created using this platform are more suited for organizational or team-level tools, or for individuals who need more complexity than Agent Builder can accommodate.

Copilot Studio becomes the natural next step when teams need more capabilities or connections:

  • Access to data that resides outside Microsoft 365
  • Connectors that provide access to external business systems
  • Workflow automation
  • Triggered or autonomous behaviors
  • Agents that perform actions rather than simply retrieving information
  • Broader publishing and sharing options

Within Microsoft, we often describe the progression between platforms as moving from knowledge to action. A retrieval agent might answer questions about policies or project documentation. A task agent built in Copilot Studio can retrieve information from multiple systems, generate reports, update records, trigger workflows, and communicate with users based on business events.

“Once builders need data beyond Microsoft 365, connectors become a critical part of the solution,” says Aisha Hasan, a principal product manager in Microsoft Digital. “Copilot Studio is often the next step, because it lets teams combine enterprise data, workflows, and actions in a way that scales with business complexity.”

Most employees only have access to a subset of approved connectors that Microsoft Digital and our Office of the Chief Information Security Officer (CISO) govern. That helps us enable the Copilot Studio experience for all employees while limiting the most advanced capabilities to qualified engineers.

Copilot Studio may not be ideal for all scenarios, which is why we have pro-code alternatives. But many business processes never require that level of complexity. We’ve consistently found that Copilot Studio can support a broad range of organizational and team-level solutions before additional development investment becomes necessary.


What our experts say:

A photo of Hasan.

“We focus on helping builders understand the risk profile of their agents as early as possible. By providing guidance during development, we can reduce friction, increase accountability, and move solutions through the process more efficiently.”

A photo of Hsu.

“Copilot Studio provides far more visibility into how agents perform over time. The evaluation and telemetry capabilities help builders improve quality, identify gaps, and build confidence that agents are delivering meaningful business value.”


The Customer Zero story: Implementing Copilot Studio internally at Microsoft

Our experience implementing Copilot Studio has helped us identify some of the key areas to carefully consider while enabling Copilot Studio at your organization.

Managing governance without slowing innovation

As capabilities increase, governance naturally becomes more important.

The reality is straightforward. When agents connect to additional data sources, integrate with external systems, and perform actions on behalf of users, organizations need appropriate safeguards.

At the outset of our journey, we already had robust systems in place for securing custom connectors, and Microsoft 365’s built-in governance capabilities ensure Microsoft 365 agents respect our labeling taxonomy and the policies it articulates. We have the power to introduce sharing limits that restrict how widely builders can distribute their agents depending on their purpose and scope.

“We focus on helping builders understand the risk profile of their agents as early as possible,” Hasan says. “By providing guidance during development, we can reduce friction, increase accountability, and move solutions through the process more efficiently.”

Three agents help us do this work:

The Risk-O-Meter

Auto-classifies submissions as green, yellow, or red based on their risk profile, then auto-approves, auto-declines, or routes them to the relevant reviewer

The Action-O-Meter

Applies the same logic to new connectors and MCP servers

The Friction Meter

Surfaces maker pain as a first-class metric

For simpler self-service agents that individual employees create and use, we define policies at the Copilot Studio environment level. Tenant administrators and partners on the security team apply data loss prevention policies to configure what individual employees can and can’t do. At this level, everyone in the company has the same configuration and tools available, and automation largely handles agent reviews and assessments based on pre-configured settings.

For more wide-reaching apps that operate at the line-of-business level or that we might publish enterprise-wide, we need to apply greater rigor. Discipline-specific professionals in security, privacy, and other spaces conduct robust reviews to ensure internal teams meet our high standards.

Governance expands through bounded, risk-based arguments, not a general philosophy of openness. Internally at Microsoft, it was more than just flipping a switch. We negotiated incrementally with the Office of the CISO, then scoped sharing. That supported the CISO’s need to only approve precise, bounded requests with measurable controls.

Telemetry and evaluation matter

As agents become more sophisticated, understanding performance is increasingly important.

Observability is one area where Copilot Studio provides significant value. Agent administrators gain access to telemetry, analytics, evaluation capabilities, and performance insights that help them understand how their organization is using agents and where improvements are necessary.

We’ve found that these features become particularly important as agents move beyond personal productivity and begin supporting larger groups of users. Data-driven evaluation helps teams improve outputs, validate business outcomes, and build trust in agent experiences.

“Copilot Studio provides far more visibility into how agents perform over time,” says Jean Hsu, a product designer for Copilot Studio. “The evaluation and telemetry capabilities help builders improve quality, identify gaps, and build confidence that agents are delivering meaningful business value.”

Consider both areas carefully as you put Copilot Studio in the hands of your employees and teams. Because it straddles both simple and more complex agents, you’ll need to consider the implications of flexibility and how to maintain proper oversight and governance.

Empowering employees to use Copilot Studio at Microsoft

As adoption grew, we worked to balance empowerment and responsibility. Our Builders Central SharePoint page provides guidance on prerequisites, agent creation environments, types of agents people can build, and more.

It’s worth noting that builders who are already familiar with Power Platform concepts like environments, connectors, and data loss prevention policies will have an advantage when they use Copilot Studio, but they typically won’t need deep technical expertise.

More broadly, we’ve implemented support systems to help our employees and teams create agents safely and effectively, without a massive knowledge burden. They include:

  • Making a wide variety of approved connectors available by default so builders can move quickly.
  • Clearly defining when builders should transition from self-service to IT-guided development.
  • Providing automated guidance during development rather than waiting until publication.
  • Using AI-assisted compliance resources to keep builders working in context.
  • Investing in maker education around connectors, data governance, and Power Platform fundamentals.
  • Encouraging teams to validate business outcomes before scaling solutions broadly.
  • Creating dedicated pathways for both self-service and enterprise scenarios.

Our experience showed that user education is just as important as technical controls. Builders need help understanding what they’re creating, what data their agents access, and what responsibilities accompany increasing capability.

We often use this statement to guide our work internally: Build compliantly, use intelligently.

DigitalMe

Created using Copilot Studio

DigitalMe is an AI-powered digital twin created at Microsoft to help change management leaders scale their expertise during large transformation initiatives.

As adoption programs grew, change management leaders found themselves spending significant time answering questions during readiness sessions and stakeholder engagements instead of focusing on delivering their content. Meanwhile, when they were traveling, in meetings, or out of office, employees often had to wait for answers, creating bottlenecks that slowed progress.

Built in Copilot Studio, DigitalMe acts as a digital representation of its human counterpart for both Microsoft Teams and Outlook. We’ve created a templatized version that anyone at Microsoft can apply to their own business context.

This agent is grounded in approved knowledge sources and previous guidance, so it can answer questions during sessions. Thanks to its access to knowledge, DigitalMe has the added benefit of supporting an employee’s colleagues even when the expert is unavailable.

So far, DigitalMe has shown enormous value for people leading sessions. In one 60-minute session, the agent handled 158 questions from participants, and its response accuracy is currently around 90%.

Read more about DigitalMe.

As you explore ways to help employees create more advanced and capable AI agents, our experience can provide an example of how low-code platforms can enable sophisticated business solutions without requiring every scenario to become a large-scale software development effort.

Key takeaways

Here are some important factors to keep in mind if you are considering Copilot Studio for agent creation at your organization:

  • Help employees know when they need Copilot Studio. Move to Copilot Studio when scenarios require external data, workflow automation, or business actions beyond knowledge retrieval.
  • Build skills to match needs. Invest in maker education around connectors, environments, data governance, and Power Platform fundamentals.
  • Observability is crucial. Use telemetry and evaluation data to continuously improve agent quality and business impact.
  • Develop a tenant-wide strategy. Create separate Power Platform environments based on what people want to build, what data they want to use, and what controls your organization needs.

Learn more

How we did it at Microsoft

Further guidance

Chapter 4: Building enterprise AI solutions with Microsoft Foundry and pro-code tools

Applying software development practices to agent creation

Some business challenges require capabilities beyond the reach of low-code development. Teams need to build solutions that can operate across complex business processes. At Microsoft, these scenarios made it necessary to cultivate a professional developer practice for building agents centered around pro-code tools, especially Microsoft Foundry. It provides a flexible environment for building sophisticated AI solutions using a broad catalog of foundation models, evaluation frameworks, orchestration tools, enterprise AI services, and unique dashboard experiences.

Foundry empowers teams to compare and evaluate models, fine-tune them for domain-specific scenarios, integrate large volumes of enterprise data, orchestrate multiple agents, build custom agentic applications, and monitor performance over time. It also allows builders to combine AI capabilities with enterprise architecture patterns, security controls, observability tools, and operational workflows.

A photo of Leung.

“Model selection is one of the most important decisions in enterprise AI. Different model families excel at different tasks, and understanding those tradeoffs helps teams build solutions that align with business goals while minimizing spend and maximizing ROI.”

Microsoft 365 Agents Toolkit provides a simplified creation path for pro-code builders. Using Visual Studio Code, developers can create agents grounded in multiple data sources, integrated with APIs, enhanced through adaptive cards, and customized through instructions, plug-ins, and manifests. The toolkit enables developers to build and deploy role-specific and task-oriented agents without creating extensive back-end services from scratch.

The primary audience for Foundry and Agents Toolkit includes software engineers, enterprise architects, IT solution owners, and advanced AI builders responsible for delivering production-grade capabilities at organizational scale.

“Model selection is one of the most important decisions in enterprise AI,” says Michael Leung, a senior software engineer in Microsoft Digital. “Different model families excel at different tasks, and understanding those tradeoffs helps teams build solutions that align with business goals while minimizing spend and maximizing ROI.”

Understanding when Microsoft Foundry and pro-code tools are right for the job

One of the most important lessons we learned is that the right platform depends on the problem we want to solve. Not every solution requires pro-code development.

In many cases, Copilot Studio provides more than enough functionality, even for agents meant to serve enterprise needs. Teams can create agents that connect to business systems, automate workflows, retrieve external information, and support business processes without requiring custom engineering. Copilot Studio supports knowledge retrieval, actions, autonomous behaviors, and extensive connector ecosystems.

Employees should consider moving to Foundry or other pro-code tools when they require greater technical depth to accomplish the following goals:

  • Fine-tune foundation models using domain-specific data
  • Compare and evaluate multiple model families
  • Build custom multi-agent orchestration frameworks
  • Implement advanced observability and evaluation pipelines
  • Develop autonomous systems that operate across multiple enterprise services
  • Integrate custom APIs, services, or proprietary architectures
  • Build solutions that require extensive engineering control and customization

The distinction between different agent-builder tools often comes down to three dimensions:

  • Low-code versus pro-code requirements
  • Solution complexity and organizational maturity
  • Short-term delivery goals versus long-term platform strategy

Don’t select Foundry simply because it is the most powerful option. Instead, start with the simplest platform that supports your business needs. That accelerates deployment and adoption while minimizing cost and operational overhead.


What our experts say:

A photo of Tripathi.

“Foundry helps us bring together data, expertise, and capabilities that often exist across separate teams. Many enterprise AI challenges are collaboration challenges, and the platform gives us a way to break down those silos.”

A photo of Mallurwar.

“Enterprise AI depends on data access and integration. The technology is powerful, but success ultimately comes from ensuring models have access to trustworthy, well-governed information.”


Enabling enterprise AI development at Microsoft

At Microsoft, our approach focuses on helping teams build responsibly while maintaining flexibility for innovation.

As organizations expand beyond information retrieval, complexity increases. AI solutions begin interacting with multiple data sources, business systems, APIs, and operational workflows. Governance, architecture, and engineering practices become increasingly important.

“Foundry helps us bring together data, expertise, and capabilities that often exist across separate teams,” says Naval Tripathi, a principal software engineering manager in Microsoft Digital. “Many enterprise AI challenges are collaboration challenges, and the platform gives us a way to break down those silos.”

Several principles guide how we enable professional developers working with agents:

  • Start with clearly defined business outcomes before selecting architecture.
  • Align development approaches with the complexity of the scenario.
  • Involve domain experts early when designing AI solutions.
  • Establish evaluation frameworks before deploying agents at scale.
  • Build governance and compliance requirements directly into development workflows.
  • Use human-in-the-loop models when introducing autonomous decision-making.

This approach helps teams focus on solving problems, rather than pursuing technology for its own sake.

The Customer Zero story: Implementing Microsoft Foundry internally

While Foundry enables powerful capabilities, it also introduces new areas for oversight. In Microsoft Digital, we play an integral role helping teams to create agents responsibly and effectively.

Security and compliance

Enterprise AI solutions often connect multiple services, models, applications, and data sources. Managing data movement securely becomes critical.

Systems need to operate within clearly defined boundaries. Models, orchestration layers, workflows, application services, and supporting infrastructure need to work together while maintaining compliance, privacy, and security controls.

In this context, it’s helpful to think of Foundry as a collaboration tool. Globally speaking at Microsoft, we work with many different solutions and manage almost everything through partner teams. Enabling Foundry depends on breaking down those silos.

Data integration and retrieval quality

One of the greatest determinants of agent success is data quality.

Enterprise AI solutions depend on retrieval pipelines, search indexes, embeddings, and grounding strategies. As IT partners with agent developers, we help them determine their data needs:

  • How to chunk and index data
  • How to refresh embeddings
  • What retrieval strategies produce the most accurate results
  • How changes to source systems propagate into AI experiences

Poor retrieval design can undermine even the most sophisticated model architecture.

Evaluation and continuous improvement

“Enterprise AI depends on data access and integration,” says Shweta Mallurwar, a senior software engineer in Microsoft Digital. “The technology is powerful, but success ultimately comes from ensuring models have access to trustworthy, well-governed information.”

As solutions become more autonomous, monitoring becomes increasingly important.

Teams need confidence that changes to orchestration frameworks, prompts, models, and workflows improve outcomes rather than introduce new issues. Foundry’s evaluation capabilities support ongoing testing, benchmarking, validation, and governance throughout the agent lifecycle. Microsoft Agent 365 is also a powerful tool for more centralized oversight and management.

MarThrive

Created using Microsoft Foundry

MarThrive is a multi-agent experience our marketing team created to help employees navigate the increasingly complex landscape of internal marketing resources, guidance, and processes.

Before MarThrive, marketers often needed to search across multiple repositories, sites, and tools to find information related to campaigns, content development, branding requirements, planning resources, and internal processes. Valuable information existed across the organization, but discovering and applying it could be time-consuming.

MarThrive brought these resources together through an AI-powered platform featuring 12 agents that help marketers quickly accomplish a variety of tasks. They include exploring our entire corpus of blogs, generating social copy, calibrating our AI-assisted writing abilities, testing quality of written outputs, generating bills of materials (BOMs), and ensuring launch readiness for campaigns.

The solution draws from multiple knowledge sources and surfaces insights through conversational interactions, creating a more streamlined way to navigate Microsoft’s marketing ecosystem and execute against our goals.

Read more about MarThrive.

Microsoft Foundry and other pro-code agent creation tools help developers bring high-value opportunities to life through agentic AI. By following our approach to enablement, management, and governance, you have a solid starting point for unlocking these capabilities in your own organization.

Key takeaways

If you want to consider pro-code development tools for agent creation at your company, here are some things to consider:

  • Ensure Foundry is the right tool. Use Foundry and pro-code tools for scenarios that require advanced customization, model tuning, orchestration, or enterprise-scale architecture.
  • Get data integration right. Build strong retrieval, indexing, and data integration strategies before scaling AI solutions.
  • Lean on expertise. Involve domain experts early to improve solution quality, evaluation practices, and business relevance.
  • Plan for management and governance from the start. Establish governance, monitoring, and evaluation frameworks from the beginning rather than after deployment. This is especially valuable for more complex agents.
  • Apply DevOps principles. Treat enterprise AI initiatives as both technical and organizational projects that require collaboration across teams.

Learn more

How we did it at Microsoft

Further guidance

  • Microsoft Foundry documentation: Get an overview of Foundry capabilities, model catalogs, evaluation tools, orchestration frameworks, and enterprise AI development practices.

Conclusion: Creating pathways for every type of agent builder

As we’ve advanced our Frontier Transformation journey, we’ve learned that successful agent adoption is not about choosing a single tool or creating a single development model. The main goal is to give employees the right pathways to solve problems at the level of complexity their scenarios require.

A photo of Kerametlian

“The future of agentic AI depends on giving people the freedom to create while providing the structure they need to do so responsibly. When organizations establish clear pathways, strong governance, and the right enablement support, they can empower every employee to become a builder and accelerate innovation at scale.”

At Microsoft, we’ve worked to create an ecosystem where every employee can participate in agent creation.

  • Some begin with Agent Builder, creating retrieval agents grounded in trusted organizational knowledge.
  • Others expand into Copilot Studio to automate workflows, connect systems, and support business processes.
  • Professional developers can build sophisticated enterprise solutions with Microsoft Foundry and other pro-code tools.

Each pathway serves a different audience, but they all share the common goal of empowering employees to turn ideas into innovation.

Throughout this guide, we’ve emphasized a principle that has shaped our own approach: Start with the business problem, not the technology, then choose the simplest tool to achieve your goal. When employees focus first on the outcome they’re trying to achieve, they’re in a better position to select the right platform, apply the appropriate level of governance, and create solutions that deliver measurable impact. We’ve found that this approach not only reduces cost but also accelerates adoption and builds confidence as employees move from simple use cases to more advanced scenarios.

Just as importantly, we’ve learned that agent enablement requires more than providing access to tools. Success depends on creating an environment where employees understand when to use each platform, how to build responsibly, and where to find support when they need it. Hands-on learning, strong data governance, clear guidance, and risk-based oversight have all played important roles in helping us scale agent creation while maintaining trust.

As agents become more capable, governance continues to evolve alongside them. Our goal is never to slow innovation. Instead, we’ve focused on creating guardrails that help employees build safely and confidently. Whether someone is creating a personal productivity agent or developing an enterprise-scale solution, the same foundational roadmap applies: Experiment, govern, scale, and optimize. All along, keep business outcomes at the center of the effort.

The AI-native organization of the future isn’t one where IT says yes to everything or no to everything. It’s one where governance is intelligent enough to know the difference and fast enough to act at machine speed.

“The future of agentic AI depends on giving people the freedom to create while providing the structure they need to do so responsibly,” says Stephan Kerametlian, a senior director for Microsoft Digital. “When organizations establish clear pathways, strong governance, and the right enablement support, they can empower every employee to become a builder and accelerate innovation at scale.”

Our experience has shown that there is no single destination in the agent journey. Employees will continue discovering new opportunities to automate work, scale expertise, and solve business challenges.

New capabilities, tools, and methods of building will emerge over time. What matters most is creating a framework that allows employees to begin where they are today and grow as their needs evolve.

As your organization develops its own approach to agent creation, we hope the lessons we’ve learned and shared can help you build a strategy that balances empowerment with oversight, innovation with governance, and experimentation with long-term value. By creating pathways for every type of builder, you can unlock the collective creativity of your workforce and help transform great ideas into lasting business impact.

Key takeaways

Here are some overall points to think about when you are picking the right AI pathway for agent creation at your organization:

  • Start with the business problem, not the tool. Encourage employees to focus on the outcome they want to achieve before selecting a platform. The most successful agent initiatives begin with a clear business need and then apply the simplest technology that can meet it.
  • Match the tool to the builder. Different employees have different needs, skills, and responsibilities. Create clear pathways that help information workers, citizen developers, and professional developers use the right agent-building experience for their scenarios.
  • Use the simplest technology solution that meets the requirement. Help employees start with retrieval and knowledge-based experiences before moving to automation, orchestration, and custom development. Complexity should increase only when the business need demands it.
  • Invest in hands-on learning. Employees learn agent creation by building. Workshops, office hours, real-world examples, and peer-to-peer learning are often more effective than documentation or training videos alone.
  • Build on a foundation of trusted data. High-quality agents depend on accurate, relevant information. Data governance, classification, permissions, and content management all play critical roles in creating useful and reliable agent experiences.
  • Treat governance as an accelerator. Establish guardrails that help employees innovate confidently while protecting organizational data. Governance should enable responsible experimentation rather than creating unnecessary friction.
  • Scale oversight with risk and impact. Personal productivity agents, departmental workflow agents, and enterprise-scale solutions should not be subject to the same level of review. Align governance, compliance, and security requirements to the potential reach and capabilities of each agent.
  • Create a journey, not a destination. Agent adoption is an evolving capability. Give employees opportunities to start small, learn, expand their skills, and move between platforms as their ideas, requirements, and business impact grow.

Try it out

Get started with Microsoft Agent 365 at your company.

Related links

The post Our Customer Zero guide: Enabling agent creation across Microsoft 365 Copilot, Copilot Studio, and Foundry appeared first on Inside Track.

]]>
25571
Boosting product manager productivity at Microsoft with AI http://approjects.co.za/?big=insidetrack/blog/boosting-product-manager-productivity-at-microsoft-with-ai/ Thu, 08 Oct 2026 15:30:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=25639 Product managers operate at the intersection of customers, engineering, strategy, and execution. They translate customer needs into requirements, prioritize competing investments, coordinate and make trade-offs with engineering teams, outline product specifications, and keep leadership informed about what is being delivered and where resources are being invested. On the Infrastructure Engineering Services (IES) team within Microsoft […]

The post Boosting product manager productivity at Microsoft with AI appeared first on Inside Track.

]]>
Product managers operate at the intersection of customers, engineering, strategy, and execution. They translate customer needs into requirements, prioritize competing investments, coordinate and make trade-offs with engineering teams, outline product specifications, and keep leadership informed about what is being delivered and where resources are being invested.

On the Infrastructure Engineering Services (IES) team within Microsoft Digital, our product managers (PMs) support the tools and services that keep Microsoft’s global network secure, resilient, and available. As Microsoft’s Customer Zero, our larger Microsoft Digital team—the company’s IT organization—is exploring how AI can accelerate individual tasks and help reshape the operating model that our PMs use to plan, govern, and communicate their work.

“One of the key things we do is make sure the most important work is getting done by the engineering teams, because our engineers are a pretty precious resource,” says Martin O’Flaherty, a principal PM manager in IES. “We need to be able to prioritize the work as it flows in. We have to understand what the engineering teams need, make trade-off decisions constantly, and make sure we’re delivering requirements and specifications that are essential for building the right thing.” 

That has led O’Flaherty and his team to experiment with AI across a broader Continuous Planning model. Rather than treat planning as a periodic exercise, this approach creates an ongoing view of the work in progress as well as upcoming priorities, deliverables, engineering investment, and strategic alignment. Planning dashboards, engineering-capacity visibility, ADO data quality, recurring leadership reviews, monthly delivery reporting, and AI-generated summaries work together as parts of the same operating model.

A photo of O'Flaherty.

“We need to make sure that we’re getting the right level of leadership visibility and support. Senior leaders understand that engineering resources are finite, so they want to make sure we’re investing the right amount of resourcing in the appropriate areas.”

Martin O’Flaherty, principal PM manager, Microsoft Digital

The objective isn’t simply to automate existing PM tasks, but to also create a better feedback loop between planning, execution, data quality, reporting, and decision making, giving our PMs more time to work directly with customers and engineering partners.

Turning planning data into leadership insight

As a product management leader, O’Flaherty often has to gather reporting on his team’s scenarios, including which are active versus closed, how the work aligns to organizational priories, and how engineering capacity is being invested. This not only helps him and his team make better prioritization and trade-off decisions but also provides crucial information for advocating with senior leadership.

“We need to make sure that we’re getting the right level of leadership visibility and support,” O’Flaherty says. “Senior leaders understand that engineering resources are finite, so they want to make sure we’re investing the right amount of resourcing in the appropriate areas.”

Most of that data already exists within systems such as Azure DevOps. The challenge is gathering the information and turning it into easily digestible insights. For O’Flaherty, that became an opportunity to use AI not simply to automate reports but also to connect planning data, data quality, and leadership reporting together into a more continuous system.

To accomplish this, O’Flaherty and his team built an AI-assisted reporting capability that can comb through all scenarios completed during the previous month, organize them around established strategic priorities, and summarize the details into leadership-ready reporting and visualizations. These show where the engineering investment is going and outcomes that the organization is delivering.

Below is an anonymized example of a dashboard O’Flaherty might use in an operational planning discussion or business review to provide near real-time visibility into planning health, delivery progress, resource allocation, and overall execution:

A screenshot showing various infrastructure engineering solutions data.
Screenshot of a dashboard showing scenario count, engineering effort, and other statistics organized by different strategic priorities.

Early on, the AI-generated reporting wasn’t always accurate or complete.

Rather than treating those missing details as an AI problem, O’Flaherty and team used them to improve the system around it. He and the team refined the reporting logic, strengthened the underlying planning data, and improved how this capability weighs the documented evidence of what was actually delivered. Human review remains an important part of the process, but the amount of manual effort required has fallen significantly.

“Last month, we had almost no feedback. We looked at the report and were like, ‘Yep, it’s good to go,'” O’Flaherty says. “We’re talking about a task that used to take weeks to do. It would be the end of August by the time you’d have July’s report. We can now send that report on the first day of August.”

During this process, O’Flaherty also learned the importance of clean, comprehensive data in getting the right outputs. Initially, missing or inconsistent information in Azure DevOps could lead to incomplete insights. And because that same planning data informs leadership reporting, improving the quality at the source became more important than improving the AI consuming it.

So, he built a second AI-assigned “hygiene” capability that continuously checks in-scope scenarios against a defined set of rules. It can identify data gaps and prompt team members with specific guidance on how to fill those gaps within Azure DevOps.

“The agent has driven the right behavior, and that’s honestly the key reason why our end-of-month reports don’t really require much human review anymore.”

Martin O’Flaherty, principal PM manager, Microsoft Digital

Together, the capabilities create a feedback loop: Better planning data produces better AI-generated insights, while AI continuously helps identify the data-quality issues that could undermine those insights.

“At the end of the day, the AI can only be as accurate as the data it has in front of it, and we were potentially making bad decisions based on that data,” O’Flaherty says. “The agent has driven the right behavior, and that’s honestly the key reason why our end-of-month reports don’t really require much human review anymore.”

Upskilling a diverse workforce

A common misconception with agents is that you need to be an AI expert to build one. O’Flaherty wanted to remove that barrier by making the process accessible to all product managers with a wide range of technical expertise. The goal was to teach people about AI and also encourage them to build capabilities against real problems in their own workflows.

As he and other team members developed their skills, they created short how-to videos of their process that broke the learning curve down into manageable steps. He began this effort by assuming the viewers knew nothing about the tools.

“We made a video on how you install Visual Studio Code, how you log into GitHub Copilot,” O’Flaherty says. “And then when you’ve done that, here’s how you access an MCP server.”

Those bite-sized explainers gave PMs a practical path into the tools and helped them to get comfortable applying what they learned directly to their own work. Rather than requiring everyone to become an AI expert first, the approach allowed people to start small, solve something useful, and build their skills through experience.

But as adoption grew, another challenge emerged: Product managers sometimes created multiple agents to solve similar problems. That presented a different scaling question: How do you encourage experimentation without recreating the same solution over and over again?

In response, the team began promoting reusable skills and encouraging PMs to build on existing work rather than starting from scratch.

“Our challenge was, how do we empower people to build without removing all the efficiencies?” O’Flaherty says. “We’ve partially solved that by creating a repository that gives people an easy way to upload stuff and encourages them to reuse where they can. Or to take the skill that’s there and customize it for their organization.”

That shift, from individual experimentation to reusable building blocks, helped turn AI adoption into more of a shared engineering discipline. PMs could still tailor capabilities to their own needs, but successful patterns could be reused, improved, and extended instead of repeatedly rebuilt.

Speeding up product planning and prototyping

For individual PM contributors, agents have made context gathering faster and simpler.

For example, Astha Sinha, a senior product manager on the IES team, says sorting through documents, meeting notes, and the various stacks her team leverages and turning that into reports could take hours every day. That was before she started using Copilot to summarize all the information for her.

Now she uses agentic skills to automate the reports that she sends to different PMs each month, further simplifying her everyday routine.

“One of the biggest benefits has been automation, which I’m empowered to achieve very easily,” Sinha says. “I support multiple partners, all with different reporting rhythms, so I created a set of skills that automatically generate reports for them on the right schedule.”

What used to be a recurring manual task for her now happens in the background. It’s reduced administrative overhead and freed up more time for strategic product work, making her workload lighter.

A photo of Khan.

“Now, by making my agent aware of the code base and incident reporting, and stitching together the logs and the data models, I can get that insight faster without using engineering time. Then I can take it back to my customers and actually get down to what really matters to them.”

Owais Khan, senior product manager, Microsoft Digital

Senior product manager Owais Khan, who also works on the IES team in Microsoft Digital, has also set up agents to analyze usage data.

Previously, it might have taken him a few hours to sit down and look at where customers are clicking, what kind of APIs they’re using, and what their call patterns look like, then actually investigate improvements on that site.

“Now, by making my agent aware of the code base and incident reporting, and stitching together the logs and the data models, I can get that insight faster without using engineering time,” Khan says. “Then I can take it back to my customers and actually get down to what really matters to them.”   

AI builder tools like Copilot Studio also provide a low-code solution for product managers that allows them to produce prototypes communicating their vision to engineers.

Nevedita Mallick, a principal product manager on the IES team, owns a lot of the UI experience on our corporate network. Her typical process for prototyping used to be to create a one-pager, then build out the idea manually in Figma.

“With Copilot Studio, it’s much faster,” Mallick says. “Things that used to take a day or two I can now be done in less than an hour, even in minutes. I can give a very rough sketch to Copilot Studio and it’s able to render the mockup really quickly. It also gives me the complete HTML with all the CSS and JavaScript, so I can just click through and explain to my developers, ‘This is what I want,’ or, ‘This is the enhancement I’m looking for.'”

Using AI-generated prototypes, PMs can also show customers interactive experiences earlier in the design cycle. This helps everyone align on requirements faster and reduces the amount of work required later in the development cycle.

The value of AI is amplified through thoughtful prompting and clear context.

“Prompting is everything,” Mallick says. “When troubleshooting a network issue, I asked Copilot to think like a network engineer so it could evaluate the problem through the lens of network topology, dependencies, and operational context. It moved from delivering generic answers to providing insights tailored to the problem at hand.”

The result, she says, is that the quality of your outcome is directly tied to the context and expertise you bring into the prompt.

A photo of Sinha.

“What once required specialized expertise and significant development time can now be done in minutes. For example, I recently created a custom skill for a specific business need in under five minutes, allowing me to move from idea to solution almost instantly.”

Astha Sinha, senior product manager,
Microsoft Digital

Practice truly does make perfect. Creating their first agents took some time, but the PMs say that the ramp-up period has significantly shortened the more they do it.

“What once required specialized expertise and significant development time can now be done in minutes,” Sinha says. “For example, I recently created a custom skill for a specific business need in under five minutes, allowing me to move from idea to solution almost instantly.”

The future of PM work

The PMs all agree that human oversight of agentic AI will always be necessary, even as they allow agents to take over some tasks.  

O’Flaherty notes that even as his agent can estimate time spent on scenarios, there are still a lot of nuances in how productivity is evaluated.

For example, while the agent can predict how many hours a specific task might take, someone also needs to factor in who’s completing the task and how fast they can work. There’s also the need for a fact-checking pass. Because of these variables, O’Flaherty believes we still need humans to gather the full picture and oversee the process.

“We’ve become agent bosses—the agents do the work and we review and approve it,” he says. “We’re almost like a governance layer for the agents in how we do our work.”

A photo of Mallick.

“The real opportunity with agents isn’t just efficiency, it’s prevention. By embedding intelligence throughout the operational lifecycle, we can identify and address issues before they become incidents, fundamentally changing how we operate at scale.”

Nevedita Mallick, principal product manager, Microsoft Digital

PMs are also already seeing how their work has changed, and that it will continue to evolve in the age of AI. Mallick observes how AI is enabling product managers to have more room for deep, critical thinking and broader product vision work. She’s excited to see how agents work proactively down the line.

“The real opportunity with agents isn’t just efficiency, it’s prevention,” Mallick says. “By embedding intelligence throughout the operational lifecycle, we can identify and address issues before they become incidents, fundamentally changing how we operate at scale.”

The team’s ultimate goal isn’t to automate product management, but to make it easier for PMs to apply their expertise where it matters most.

As Microsoft Digital continues its important Customer Zero work, that mission is helping shape how product managers use AI to scale their impact while maintaining human judgment, collaboration, and accountability.

Key takeaways

Organizations looking to improve product manager productivity with AI should:

  • Start with repetitive workflows. Begin with simple tasks that take time but don’t need heavy oversight, such as reporting, planning, status updates, and context gathering.
  • Leverage existing systems. You don’t have to create entirely new data for AI to be effective—just guide it toward existing documentation and encourage it to pull from there.
  • Be detailed in your requests. Telling AI who your audience is, how you like slides formatted, and what sources of truth should be incorporated are all important pieces of information when prompting a chatbot or creating an agent.
  • Build off available skills. Consider whether an agent created by another team member could be tailored to your own needs, rather than building one from scratch.
  • Establish governance and sharing practices early. The sooner compliance is incorporated, the more likely you’ll avoid duplication and error and be able to scale your workflows.
  • Have an open mind. Like any new technology, these tools come with a learning curve. Understand that it takes time to familiarize yourself with agents; with practice, they will become easier and faster to use.

Try it out

Related links

The post Boosting product manager productivity at Microsoft with AI appeared first on Inside Track.

]]>
25639
Transforming the data foundation behind our datacenter expansion at Microsoft http://approjects.co.za/?big=insidetrack/blog/transforming-the-data-foundation-behind-our-datacenter-expansion-at-microsoft/ Thu, 17 Sep 2026 16:00:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=25436 The team building our datacenters here at Microsoft needed to get organized. Microsoft Cloud Operations + Innovation (CO+I), our organization that plans, builds, and operates the datacenters behind Microsoft Azure, built OneMDM UniVerse to give us a centralized master data platform to manage the materials, suppliers, equipment, and locations behind our datacenter buildout. “Everyone is […]

The post Transforming the data foundation behind our datacenter expansion at Microsoft appeared first on Inside Track.

]]>
The team building our datacenters here at Microsoft needed to get organized.

Microsoft Cloud Operations + Innovation (CO+I), our organization that plans, builds, and operates the datacenters behind Microsoft Azure, built OneMDM UniVerse to give us a centralized master data platform to manage the materials, suppliers, equipment, and locations behind our datacenter buildout.

A photo of Singh.

“Everyone is focused on building really good agents and really good workflows. But all of that begins to fail at scale if you don’t have the foundation set up. Master data management is absolutely that foundation.”

Dikul Singh, principal product manager, Microsoft CO+I

Built on Microsoft Dynamics 365, the new platform has a name that addresses our challenge and our solution.

OneMDM, the first part of the name, is a single master data management system that replaces many of our disparate sources of data. UniVerse, the second part of the name, is the ambition layered on top, because our goal was never to master one data set in isolation. We needed to hold the full hierarchy of our datacenter in a single place, from the cloud it serves down to the individual co-location room.

“Everyone is focused on building really good agents and really good workflows,” says Dikul Singh, a principal product manager in CO+I. “But all of that begins to fail at scale if you don’t have the foundation set up. Master data management is absolutely that foundation.”

100 systems, 100 versions of the truth

As our Azure business grew, CO+I grew with it. More than 100 different data systems emerged across planning, supply chain, construction, and operations functions, each with its own copy and its own definitions of the data required to maintain and build new datacenters.

A photo of Nair.

“Everybody knew we had to connect everything together, but when you’re running at breakneck speed, it’s very difficult to put things together and standardize.”

Praveen Nair, principal software engineering lead, CO+I

Explosive growth meant our teams across CO+I were pursuing one goal via separate routes, and their data diverged in the same way.

“Everybody knew we had to connect everything together, but when you’re running at breakneck speed, it’s very difficult to put things together and standardize,” says Praveen Nair, a principal software engineering lead in CO+I.

Location became the clearest illustration of divergent data. One team would cite the physical address, another the Azure region, another the planning metro, another a position in the org hierarchy. Same datacenter, four different answers.

A photo of Subramaniam.

“Employees would ask, ‘Who’s the owner for this data? Who’s the steward?’ There was no governance and no data quality at all in what people were consuming.”

Kavitha Subramaniam, senior software engineer, CO+I

Inconsistent definitions were not the only problem. Even when teams agreed on what a record should say, no one was accountable for keeping it consistent.

“Employees would ask, ‘Who’s the owner for this data? Who’s the steward?’” says Kavitha Subramaniam, a senior software engineer in CO+I. “There was no governance and no data quality at all in what people were consuming.”

A photo of Albrecht.

“With Excel files, you don’t know who the data owners are, and if you’re aggregating across a whole bunch of them, it becomes very challenging.”

Karen Albrecht, director of asset inventory management systems, CO+I

On the operations side, the gaps were filled by spreadsheets across roughly 350 campuses and more than 4,000 colocations.

“With Excel files, you don’t know who the data owners are, and if you’re aggregating across a whole bunch of them, it becomes very challenging,” says Karen Albrecht, director of asset inventory management systems in CO+I.

For years, people filled the gaps by hand, reconciling systems record by record. At this size, that manual effort could no longer keep up. The answer had to be a system, not more people.

Building a platform that teams would actually use

We built OneMDM UniVerse on Microsoft Dynamics 365, which serves as the platform’s business application layer. This meant the team did not have to build the fundamentals itself.

“There are industry-standard solutions on the market, but they didn’t quite fit the way we’re structured. They would have required a lot of customization, which would become harder to manage and maintain over time.”

Venkatesh Muthiah, principal software engineering manager, CO+I

Security and permissions came built-in, along with data storage and configurable process flows the team could shape to match how each domain approves a record. Microsoft Dataverse sits underneath, making mastered data readable by other services without a custom pipeline for each one.

That freed the team to focus on the master data problem itself. The packaged products on the market couldn’t do that part for them.

“There are industry-standard solutions on the market, but they didn’t quite fit the way we’re structured,” says Venkatesh Muthiah, principal software engineering manager in CO+I. “They would have required a lot of customization, which would become harder to manage and maintain over time.”

Three principles shaped the platform: Scalability, reusability, and governance. Data enters the product through APIs, integrations, or the user interface. These patterns were built once and then reused as each new system came online.

“The most important part of my job is listening to how teams actually work and what they need the platform to do for them. We’re not asking every customer to work exactly the same way. We’re looking for the common requirements we can build into the platform while still supporting the business needs that make each domain different.”

Rajesh Yerragunta, principal technical program manager, CO+I

Building something reusable also meant understanding what different teams actually needed from it. Rajesh Yerragunta, a principal technical program manager on the OneMDM team, works directly with customers to understand their requirements and translate them into capabilities the platform can support.

“The most important part of my job is listening to how teams actually work and what they need the platform to do for them,” Yerragunta says. “We’re not asking every customer to work exactly the same way. We’re looking for the common requirements we can build into the platform while still supporting the business needs that make each domain different.”

That customer input helped the team build flexibility into OneMDM without losing the consistency it was designed to create.

Governance was designed with each domain rather than imposed on it. We set up a data governance council that named owners and stewards for each domain and defined the approval workflows so that every domain used the same process. Rogue data dumps that previously went through without approval now underwent review, first through an AI screen and then with a human review as a final check.

The team also used AI to help with ingestion. Exact-match validation had existed before, but it was imperfect—when two pieces of data appeared to be similar but were not exact duplicates, the AI review wouldn’t catch it.

“Now, the moment I try to create the record, even before governance kicks off, we check for duplicates and run a similarity check,” Subramaniam says. “Then it tells us, ‘Dublin DC already exists. Do you still want to continue?’”

Configurable quality rules run continuously, with dashboards showing business users which records are failing and why. Some are authored by the business; others are AI-generated.

Getting the team aligned came down to agreeing to use the same language.

“We had so many ways to label a location, and we still do, but OneMDM was able to connect all of them together,” Singh says. “All of our leaders speak about Azure regions, but we speak about physical locations. Now, whether it’s capital funding, planning, or procurement, there’s no cross-talking.”

The immediate relief was evident.

“Every decision we make downstream is only as good as the data underneath it. Master data isn’t glamorous work, but it is the difference between growing fast and growing well. Sponsoring OneMDM was about giving our teams a common foundation so they could stop reconciling numbers and start acting on them.”

Sameer Tarey, partner director, Cloud Infrastructure Engineering

Teams that had spent their time reconciling competing versions of the same record got that time back, and coordination that once required a translator became routine. Now the connections held, because someone owned them.

For Sameer Tarey, partner director of Cloud Infrastructure Engineering, that alignment was the objective.

“Every decision we make downstream is only as good as the data underneath it,” Tarey says. “Master data isn’t glamorous work, but it is the difference between growing fast and growing well. Sponsoring OneMDM was about giving our teams a common foundation so they could stop reconciling numbers and start acting on them.”

Standardized equipment records and bills of materials now feed our integrated business planning engine, which tells planners what to buy, where, and when.

In operations, Albrecht’s team went from updating inventory records one at a time in Excel to updating 100% of the fleet in less than two days.

“Moving CO+I business data out of Excel and into modern data mastering platforms is transformative because it turns fragmented tracking into a trusted operating system for decisions,” Albrecht says. “It gives leaders governed, real-time visibility across teams, reduces manual reconciliation, and creates the data foundation we need to scale automation, AI, and measurable business outcomes across global datacenter operations.”

The adoption challenge

Adoption turned out just as challenging as building the platform. Every team that needed to adopt OneMDM already had a working system, a backlog, and deadlines of its own. Asking them to stop, clean up years of accumulated records, and re-point their integrations meant asking them to spend today’s capacity on a payoff that may not manifest for more than a year.

The team’s first instinct was to standardize by decree. If everyone adopted one definition of region, the mismatches would disappear. But being told to abandon their established systems for something new landed badly.

A photo of Kummathi.

“I took a demo system, created sample materials, showed the entire flow to each group, and asked, ‘Is this what you want to see?’ Going from theoretical alignment to practical realization is what worked.”

Nirmala Kummathi, supply chain data manager, Microsoft Global Supply Chain

Only after working through the objection with several teams did the pattern become clear: This was not resistance; it was how each group actually ran its business. The fix was not a single definition imposed from above, but a common level in which everyone could follow the same map.

Nirmala Kummathi, supply chain data manager in Microsoft Global Supply Chain, describes a three-legged approach for solving this challenge, one that encompassed technology, process, and people. Through trial and error, Kummathi realized that agreeing in principle never worked as well as doing a demo and having a conversation face to face.

“I took a demo system, created sample materials, showed the entire flow to each group, and asked, ‘Is this what you want to see?’” Kummathi says. “Going from theoretical alignment to practical realization is what worked.”

What’s next in master data management

Adoption of OneMDM UniVerse continues across our organization, domain by domain. The foundation is already enabling us to accomplish things that weren’t practical before: predictive maintenance signals, conversational access to equipment data, and agent-based workflows built on data the organization can finally trust.

“Just because I get excited by data doesn’t mean everybody does. You have to figure out what’s in it for them,” Singh says. “If you want someone to build a ship, you don’t get them excited about building a ship; you teach them to long for the sea. I was selling OneMDM, and everybody said it was boring. So we started selling everything it could enable instead, and people got on board.”

Key takeaways

Here are some things to keep in mind as you consider a master data initiative at your own organization:

  • Treat master data as AI infrastructure. Agents and analytics inherit whatever inconsistency exists underneath them. Fixing definitions, ownership, and quality is what makes AI initiatives durable rather than just impressive for a quarter.
  • Handle data quality at the front door. Fragmentation compounds quietly when systems grow faster than governance. Audit which entities are already duplicated and where that creates blind spots and set up systems so new records are validated before they spread downstream.
  • Decide deliberately whether to buy or build. Standard MDM products carry real value, but if your core business objects are unique to how you operate, customization can cost more than building your own.
  • Make adoption a KPI. The platform delivers value only when downstream systems consume it. Track connected teams and live integrations, and plan for the reports that will break.
  • Design governance with the business. Name owners and stewards, define approval workflows for the people doing the work, and keep it configurable. Rigid workflows simply get bypassed.
  • Sell the outcome. Master data is an investment with a long payback that must compete with urgent priorities. Executive sponsorship is essential, and teams commit faster when you show them what the foundation unlocks.

Try it out

Related links

The post Transforming the data foundation behind our datacenter expansion at Microsoft appeared first on Inside Track.

]]>
25436
Empowering employees after the call: Enabling and securing Microsoft Teams meeting data retention at Microsoft http://approjects.co.za/?big=insidetrack/blog/empowering-employees-after-the-call-enabling-and-securing-microsoft-teams-meeting-data-retention-at-microsoft/ Thu, 13 Aug 2026 16:00:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=25075 Microsoft Teams meetings help our globally distributed and digitally connected employees create meaningful hybrid work experiences. When those meetings are recorded and transcribed, or their data becomes available to AI-powered digital assistants, their value extends far beyond the meeting itself. Once captured, meeting data becomes a source of organizational knowledge that helps employees catch up […]

The post Empowering employees after the call: Enabling and securing Microsoft Teams meeting data retention at Microsoft appeared first on Inside Track.

]]>
Microsoft Teams meetings help our globally distributed and digitally connected employees create meaningful hybrid work experiences. When those meetings are recorded and transcribed, or their data becomes available to AI-powered digital assistants, their value extends far beyond the meeting itself.

Once captured, meeting data becomes a source of organizational knowledge that helps employees catch up on discussions, revisit decisions, track commitments, and surface unresolved issues. AI-powered experiences such as Microsoft 365 Copilot and Work IQ can connect insights across meetings, helping teams understand how conversations, decisions, and workstreams evolve over time and ensuring important information doesn’t get lost.

Although these features have proven to be incredibly useful to our employees and our wider organization, there are also concerns about how retaining Microsoft Teams meeting data and AI insights might affect our security posture, records retention policy, and privacy. Just like any other company, we at Microsoft must balance these different factors accordingly.

At Microsoft Digital, the company’s IT organization, we’re leading cross-disciplinary conversations on this topic to help ensure that we get it right.

The value of Teams meeting data

Within a meeting, the Microsoft 365 Copilot sidebar experience helps our late-joining employees catch up on what they’ve missed, provides intelligent prompts to review unresolved questions, summarizes key themes, and creates notes or action items.

A photo of Jensen.

“The value of a meeting should not end when the meeting ends. Transcription and AI help transform conversations into durable knowledge—making decisions easier to find, commitments easier to track, and information easier to access for everyone who needs it.”

Chanda Jensen, senior product manager, Microsoft Digital

The benefits of AI in meetings extend beyond the live meeting experience as well. When meeting content is available after the meeting, AI can transform conversations into accessible organizational knowledge. Transcripts and underlying documentation—including, notes, decisions, and action items—enable participants to revisit discussions, catch up on missed meetings, verify decisions, and accelerate follow-up work.

Our Microsoft Teams meeting data retention efforts focus on three key categories of artifacts: Underlying documentations, transcripts, and the AI-generated artifacts that help power Microsoft 365 Copilot and Work IQ experiences.

Microsoft Teams meeting data and AI artifact retention

Meeting recordings

90-day Teams meeting expiration policy

  • Cloud video recording
  • Audio
  • Screen-sharing activity

Transcripts

90-day Teams meeting expiration policy

  • Transcript
  • Captions

AI-generated meeting artifacts

90-day Teams meeting expiration policy

  • Meeting summaries and intelligent recaps
  • Notes, decisions, and action items
  • Copilot interactions (queries and responses)
  • Insights and organizational knowledge derived from meeting content

Transcription provides the underlying documentation that makes these AI-powered experiences possible. By making transcription and AI capabilities available in meetings while preserving organizer, administrative, compliance, and sensitivity controls, organizations can choose how these capabilities are used while enabling users to benefit from more effective collaboration and knowledge retention.

“The value of a meeting should not end when the meeting ends,” says Chanda Jensen, senior product manager in Microsoft Digital. “Transcription and AI help transform conversations into durable knowledge—making decisions easier to find, commitments easier to track, and information easier to access for everyone who needs it.”

Policy considerations for meeting data retention

The value of these tools is clear, but data-retention obligations also play an important compliance role that organizations like ours need to consider.

A photo of Heade.

“When individuals generate recordings or other artifacts during meetings, we tend to think of them as an individual’s data, but they actually represent the company’s data. We want to empower individuals, but we have to remember the retention and volume impacts of these artifacts on the company can be substantial.”

Rachael Heade, director of records compliance, Microsoft Corporate, External, and Legal Affairs (CELA)

First, producing and retaining this kind of data can be complex if it isn’t governed properly. For us at Microsoft, this data represents day-to-day general business practices that elevate productivity, and factors such as security and privacy must be considered when managing it. Second, data-rich artifacts like video recordings require a lot of space, quickly eating up cloud storage budgets.

“When individuals generate recordings or other artifacts during meetings, we tend to think of them as an individual’s data, but they actually represent the company’s data,” says Rachael Heade, director of records compliance in Microsoft’s legal division. “We want to empower individuals, but we have to remember the retention and volume impacts of these artifacts on the company can be substantial.”

In light of these potential impacts, some organizations simply opt out of enabling Microsoft Teams meeting recordings.

Asking the right questions to assemble the proper guardrails

Leaders in Microsoft Digital and Corporate, External, and Legal Affairs (CELA), our legal division, are working to balance the benefits of Microsoft Teams meeting data retention with our compliance obligations, aiming to provide empowering experiences for our employees while also keeping company data safe.

“Organizations are always concerned about centralized control over the retention and deletion of data artifacts,” Heade says. “You have excited employees who want to use this technology, so how do you set them up so they can use it confidently?”

Like many policy conversations, getting this right starts with the governance team in Microsoft Digital and our internal partners asking employees from across the company who are responsible for data governance the right questions:

  • When should a meeting be recorded and when shouldn’t it?
  • What kind of data gets stored?
  • Who can initiate recording, and who can access it after the meeting?
  • How long should we retain meeting data?
  • Where does the data live while it’s retained?
  • How can we control data capture and retention?
  • What does this mean for eDiscovery management?

These questions help us think about the proper data-retention guardrails. Our IT perspective is only one part of the puzzle, so we’re actively consulting with CELA, corporate security, privacy, the Microsoft Teams product group, the company’s data custodians, and our business customers throughout this process.

A photo of Johnson.

“As an organization, this is about thinking through your tenant position and getting it to a reasonable state.”

David Johnson, tenant and compliance architect, Microsoft Digital

Our conversations have brought up distinctions that any organization should consider as they build policy around Microsoft Teams meeting retention:

  • The length of time a meeting’s data remains fresh, relevant, or useful
  • Consideration of the difference between AI-generated archival content versus the full meeting transcript
  • The different risks inherent with recordings compared to transcriptions
  • Establishing default policies while allowing limited variability and flexibility when employees require it

“As an organization, this is about thinking through your tenant position and getting it to a reasonable state,” says David Johnson, tenant and compliance architect in Microsoft Digital.

From sharing perspectives to crafting policy

Our policies around Microsoft Teams meeting data retention continue to evolve, but we’ve already implemented some highly effective practices, policies, and controls. Every organization’s situation is unique, so it’s important that you speak to your legal professionals to craft your own policies. But our work should give you an idea of what’s possible through the out-of-the-box features within Microsoft Teams.

The policies we’ve put in place represent a mix of technical defaults, meeting options, and empowering employees to make informed decisions about usefulness and privacy. They also build on the foundations of our work with sensitivity labeling, which helps secure data across our tenant.

Here are some of the practices we follow and features we use:

  • Transcript attribution opt-out gives employees agency and reassures them that we honor their privacy.
  • Recommending that employees “tell and confirm” before recording empowers and supports our people to speak up when they don’t believe the meeting should be recorded or don’t feel comfortable with this choice. Employees in the meeting can also stop the recording, if needed, or determine if automatic recording was set up but is not appropriate.
  • Visual indicators that a meeting is being recorded and that transcription has started, allowing users to request that a meeting stop being recorded or to leave the call.
  • User education, through an internal recording smart-use statement document, helps employees understand the implications of recording, when not to record, and when not to speak in a recorded call.
  • We do not use compliance recording. While compliance recording could enforce full consent collection, unmuting themselves, we decided that opt-outs and user notices provided sufficient agency to our employees.
  • We offer meeting labels that limit who can record, meaning only the organizer or co-organizer can initiate recordings for meetings labeled “highly confidential.”
  • Meeting labels are informed by content shared within the meeting. If content is shared in the meeting that has a higher label than the meeting itself, the organizer is prompted to re-label it.
  • Meeting labels are inherited and applied to all meeting artifacts, recordings, transcripts, and notes. This means that meeting knowledge remains protected, and any AI consumption of that recording will automatically inform the consumer of the sensitivity and required protections.
  • Only meeting organizers can download meeting recordings, keeping the meeting data contained and restricting sharing.
  • The default OneDrive and SharePoint meeting expiration is set to 90 days to ensure we minimize the risk of data leakage or cloud-storage bloat.
  • The default Meeting AI Archive is set to an 18-month retention policy. That allows questions and decisions from the meeting to be leveraged by the team for post-meeting insights but ensures that data is not kept forever.  
  • Deletion is applied in a consistent manner under the business general categories of our retention schedule. The schedule supports our designation of the Teams artifacts as productivity tools and resources, but not as official company records. This stance controls data volume, reduces review and production burden, and ultimately reduces risk (including security and privacy factors).

Balancing productivity with sensible data governance

At Microsoft, we apply different retention periods to different types of meeting data, based on their purpose and business value. Full meeting recordings and transcripts are governed by a default 90-day expiration policy, helping reduce privacy, security, and storage risks while ensuring employees can still benefit from recordings in the near term.

“The bottom line is that we rely on our employees to be good stewards of the company. Because we’ve got a good governance model in place for Teams and solid overall hygiene for our tenant, we’re well set up to deal with the evolution of the product and make these decisions.”

David Johnson, tenant and compliance architect, Microsoft Digital

Separately, AI-generated meeting knowledge—such as questions, decisions, and other insights extracted from meetings and used to support discovery and knowledge-sharing—can be retained for up to 18 months, allowing teams to benefit from the value of those insights long after the original transcript has expired.

These policies are designed to balance employee productivity with responsible data governance, ensuring that important information remains available when useful but is not retained indefinitely. They reflect the three core tenets we use to inform our governance efforts: empower, trust, and verify.

“The bottom line is that we rely on our employees to be good stewards of the company,” Johnson says. “Because we’ve got a good governance model in place for Teams and solid overall hygiene for our tenant, we’re well set up to deal with the evolution of the product and make these decisions.”

The net outcome of all of this work is that our organization is more confident in our approach to meeting knowledge, resulting in more meetings being recorded or transcribed and generating more valuable post-meeting artifacts.

We can’t specifically recommend that an organization follow our blueprint entirely, but asking questions similar to the ones we’ve outlined here can help you build a strong Teams data-governance foundation. With a firm grasp of the technology and close collaboration with key stakeholders, you can guide your own policy decisions and unlock more value for your employees.

Key takeaways

Here are some tips for approaching meeting data retention policies and practices at your company:

  • Face your fears and get comfortable with being a little uncomfortable. First establish your concerns about Teams data retention, then work toward optimizing your policy compliance.
  • Consider how to support your company’s compliance obligations while still allowing your employees to take advantage of the product’s data-retention features. Let those things live together side-by-side.
  • Connecting with your legal team is essential, because they’re the experts on assessing complex compliance questions. Leveraging legal expertise not only drives clarity on complex compliance questions but also allows you to surface opportunities and constraints around how and when to use meeting data features specific to your business or industry.
  • Investigate meeting labels and what policies you might want to apply to different meetings, based on sensitivity and other attributes.
  • Engage your security team to discuss how labeling and post-meeting protections can address any company security concerns.

Try it out

Related links

The post Empowering employees after the call: Enabling and securing Microsoft Teams meeting data retention at Microsoft appeared first on Inside Track.

]]>
25075
From data sprawl to AI-driven seller insights at Microsoft http://approjects.co.za/?big=insidetrack/blog/from-data-sprawl-to-ai-driven-seller-insights-at-microsoft/ Thu, 18 Jun 2026 15:15:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=24357 Sellers at Microsoft have access to a wide range of data to help them understand their business, identify risks, and focus on opportunities. Over time, new systems and reporting tools expanded the amount of data available to them. At first glance, helping sellers improve the way they work looks like a data challenge because we […]

The post From data sprawl to AI-driven seller insights at Microsoft appeared first on Inside Track.

]]>
Sellers at Microsoft have access to a wide range of data to help them understand their business, identify risks, and focus on opportunities. Over time, new systems and reporting tools expanded the amount of data available to them.

At first glance, helping sellers improve the way they work looks like a data challenge because we tend to believe more data equals better decisions. However, when we explored how they use data to prepare for customer meetings and internal business reviews, we saw a different pattern.

The amount of data they had available to them had increased—but so had the manual effort needed to turn it into useful and actionable insights. In fact, our sellers were spending more time looking for relevant information than they were spending engaging with customers to improve their experience.

As part of our Customer Zero approach at Microsoft, we apply our technologies internally and use that experience to understand what works at scale so we can pass that knowledge onto our customers. In this case, our discoveries unearthed a deeper issue with how our sellers interact with data in their day-to-day work.

Too much data, not enough insight

The increased amount of data available to our sellers gave them more options but also more information to process. It also introduced fragmentation.

A photo of Toomey.

“I think the big feedback pain point we got was that we have way more data than our sellers were used to. You give us a gigantic well of data, but how I use that data to execute my job is fragmented.”

Michael Toomey, revenue insights lead, Finance Data and Experience

A significant portion of our sellers’ time went into finding, interpreting, reconciling, and analyzing the information before any actual decisions or customer interactions were taking place. In some cases, sellers were navigating hundreds of reports and dashboards across multiple systems. In others, they were exporting data into spreadsheets, building their own analyses, and assembling presentations manually. They told us they were overwhelmed by the amount of data they had access to.

“I think the big feedback pain point we got was that we have way more data than our sellers were used to,” says Michael Toomey, a revenue insights lead on our Finance Data and Experience team. “You give us a gigantic well of data, but how I use that data to execute my job is fragmented.”

This tedious manual user experience didn’t match the fast pace of our work. Sellers needed to move quickly, and we needed a way to empower them to find the data and insights they needed to be able to make actionable decisions immediately.

Instead of continuing to expand the amount of data available to our sales force, we concentrated on making the existing data easier to access, understand, and use.

Beginning with a trusted data foundation

The starting point was the data itself. Our sales organization draws from many systems, each of which has its own structure, definitions, and refresh cycles. Without alignment across these systems, even seemingly simple seller questions could produce different answers depending on the data source. This created more work as our sellers hunted down which answer was the correct one.

We consolidated all this data into a unified model on Microsoft Fabric, creating a shared data foundation across the organization. It included standardized definitions, consistent metrics, and common hierarchies. Data from more than 70 systems was brought together into one governed environment.

This step required coordination across teams and ongoing attention to evolving data governance. It established trust in our data that made it easier to streamline the user experience for our sales teams down the line.

Streamlining how sellers work with data

With a consistent data foundation put into place, we turned our attention to how sellers could most effectively access and use the information.

Instead of asking sellers to navigate a portal of reports, we designed role-based dashboards that reflect how people actually work. Individual dashboards are curated based on role, workflow, and responsibilities, helping our sellers quickly find what they needed without searching across systems. We transformed the work surrounding actionable insights, too: Power BI surfaces intelligent insights to our sellers’ dashboards every morning, automatically giving them their priorities for the day and providing an overview of their funnel.

Before this transformation, building PowerPoint presentations for customers and summarizing reports were routine but tedious parts of the preparation process for our sellers before they spoke to customers. These preparatory steps have been streamlined or automated wherever possible, reducing seller time spent on repetitive manual tasks.

Empowering sellers using AI

With the data organized and cleaned and the user experience transformed, we introduced AI to overhaul how our sellers interact with the information available to them.

“A lot of what we’re trying to do is get to a native Microsoft 365 Copilot experience where we meet people where they’re working every day. And then work is optimized to be able to reason over our day to pull the data in.”

Michael Toomey, revenue insights lead, Finance Data and Experience 

To find the information they’re looking for, sellers can now ask questions in natural language and receive answers directly in the tools they already use. Insights powered by Power BI Copilot, Fabric, and AI Foundry are delivered proactively, helping sellers prioritize their day, generate summaries, and assemble materials for meetings without working through each step manually.

Insights that previously required a great deal of time to uncover are surfaced directly. The relevant reports are automatically routed to sellers based on their job description and client base. Sellers can also subscribe to continuously updated reports and have them surfaced each morning to their inbox.

These capabilities are available in the tools our people already use, which means they don’t have to spend time learning new product suites. The information they’re looking for can be surfaced through tools like email or within Microsoft Teams, which means sellers can stay focused on their work without needing to switch between systems.

Processes that once took hours can now be completed in minutes.

“A lot of what we’re trying to do is get to a native Microsoft 365 Copilot experience where we meet people where they’re working every day. And then work is optimized to be able to reason over our day to pull the data in,” Toomey says.

What changed

The most visible shift we’ve observed is how sellers spend their time. Less effort goes into finding, assembling, and reconciling information, and more attention is directed toward understanding customer needs and making decisions that actively move the business forward.

After deploying this model across our sales organization, we saw meaningful improvements in both efficiency and effectiveness, including:

  • 100,000 seller hours saved annually
  • 30% reduction in data ingestion costs
  • 10x faster insight generation
  • 1,500 reports retired and consolidated

We credit our success to building a trusted data foundation; a streamlined, intuitive user experience; and embedding AI into the flow of work to help our sellers surface insights and information with a few clicks instead of spending hours sifting through irrelevant inputs.

We learned that executive sponsorship and active change management were essential to transforming the department successfully. Concentrating on consistency and departmental alignment around a set of trusted, verified, well-governed data and shepherding people through shifting how they worked with the data were just as important as adding AI into the process.

Looking ahead

At the heart of our trusted data foundation is the semantic layer, the place where our business definitions, metrics, and data quality are standardized across the organization. It’s now the engine that powers our agents. Because those definitions live in one governed place, our agents can reason over our data products with confidence, and we can trust what they surface.

That foundation is already bearing fruit. A new generation of personal and role-based agents at Microsoft is taking on the workflows that were consuming our sellers’ time, such as meeting preparation, pipeline reviews, and customer insight generation. These processes are now running on the governed data infrastructure we built. Everything draws from the same source of truth, so everything our agents work with is consistent, reliable, and ready to act on.

This return on our platform investment is bringing us closer to becoming a Frontier Firm where our people spend less time searching for the answers and more time acting on them.

Key takeaways

If you’re looking to transform how your teams interact with data and AI, consider these lessons from our experience:

  • Start with a trusted data foundation: Standardize your definitions, governance, and ownership before layering on AI.
  • Simplify before you scale: Reduce fragmentation and rationalize your reports to eliminate unnecessary complexity.
  • Design for real workflows: Focus on how y our people work, not just how your data is organized.
  • Embed AI into the flow of work: Deliver insights where your people already are instead of requiring them to search across systems or learn a new product suite.

Try it out

Related links

The post From data sprawl to AI-driven seller insights at Microsoft appeared first on Inside Track.

]]>
24357
How Work IQ is supercharging our AI usage at Microsoft http://approjects.co.za/?big=insidetrack/blog/how-work-iq-is-supercharging-our-ai-usage-at-microsoft/ Thu, 21 May 2026 15:00:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=23773 At Microsoft, we’re constantly thinking about the future of work—how the power of AI and agents is transforming the way knowledge workers do their jobs, streamlining workflows, and boosting employee productivity. These innovations have come in many different forms across every group and function at the company. It’s impossible to capture them all in a […]

The post How Work IQ is supercharging our AI usage at Microsoft appeared first on Inside Track.

]]>
At Microsoft, we’re constantly thinking about the future of work—how the power of AI and agents is transforming the way knowledge workers do their jobs, streamlining workflows, and boosting employee productivity.

These innovations have come in many different forms across every group and function at the company. It’s impossible to capture them all in a single concept or story, but one of the ways that we’ve activated the power of AI for our workforce is Work IQ.

Work IQ isn’t a product.

It’s a shared intelligence layer that enables Microsoft 365 Copilot and AI agents to reason over and understand your organization’s work data, then use that context to generate more relevant responses and actions. This means that the entire Microsoft Graph—including rich unstructured data from your Teams chats and meetings, Outlook emails, Word documents, PowerPoint presentations, and more—is now part of your AI-powered work experience.

A photo of Hasan.

“It’s not really a brand-new capability, but more an evolution of what users already know, which is access to the grounding data in their Microsoft tenant. The difference is that Work IQ adds an additional layer to provide more context, allowing for richer and more relevant results.”

Aisha Hasan, principal product manager, Microsoft Digital

Work IQ enables Copilot to not only tailor answers to your role and responsibilities, but also to understand who your most frequent collaborators are, comprehend details about your latest projects, surface deliverables and deadlines, and intuit next steps. Additionally, Work IQ makes it easy for any AI agent to take advantage of the same rich enterprise data to return and act on more contextual results.

“It’s not really a brand-new capability, but more an evolution of what users already know, which is access to the grounding data in their Microsoft tenant,” says Aisha Hasan, a principal product manager in Microsoft Digital. “The difference is that Work IQ adds an additional layer to provide more context, allowing for richer and more relevant results.”

At Microsoft Digital, the company’s IT organization, we’ve seen firsthand how this intelligence layer is accelerating employee adoption of Copilot and agentic AI as outputs become more perceptive and valuable. Work IQ is a foundational step toward a future where AI has moved beyond isolated assistance and become a trusted professional helper—sometimes described as a digital colleague—that carries out tasks and anticipates needs in every aspect of daily work.

How Work IQ impacts everyday work

One of the most instructive aspects of Work IQ’s impact across our organization is that it happened without a traditional deployment. There was no enablement event for employees or operational playbook distributed to administrators. It didn’t require any changes to the application interfaces. Yet over time, our employee Copilot interactions improved in measurable ways.

A photo of Willingham.

“There was a period where we weren’t adding new content to Copilot, and yet I noticed our metrics for quality and user satisfaction kept going up. Why was that? It was because of all these incremental improvements that we refer to as Work IQ.”

Dodd Willingham, principal product manager, Microsoft Digital

This was a direct consequence of introducing a shared intelligence layer into a Microsoft environment that was already rich in work signals. Those work signals are extremely valuable data that was difficult to extract meaning from before the advent of AI. As the technology advanced, we could take full advantage of this data to inform and improve agentic responses.

As Customer Zero for the company, Microsoft Digital was at the forefront of measuring the impact of Work IQ. Our employees saw significant gains in relevance, grounding, and answer coherence in Copilot that were visible in the metrics, even during times when the underlying content remained relatively static. That’s the Work IQ difference.

“There was a period where we weren’t adding new content to Copilot, and yet I noticed our metrics for quality and user satisfaction kept going up,” says Dodd Willingham, a principal product manager in Microsoft Digital. “Why was that? It was because of all these incremental improvements that we refer to as Work IQ.”

At a systems level, Work IQ reasons across a broad cross-section of Microsoft 365 data, including:

  • Outlook email content, thread structure, and interaction patterns
  • Teams chats, channels, and meeting transcripts
  • Calendar events and scheduling metadata
  • Documents and files across Word, PowerPoint, Excel, OneDrive, and SharePoint
  • Signals that show who collaborates with whom, how often, and in what context

Work IQ can also access structured data in tools like Dynamics 365, Power BI, Power Apps, and other business applications. The ability to extract context and interpret structured and unstructured data in a unified intelligence layer is the reason why Work IQ is making such a difference for our employees.

Making Outlook better

Outlook provides a useful lens on how Work IQ functions because it’s both heavily used by our employees and a highly contextual tool. Although the application hasn’t outwardly changed, the way Copilot interacts with inbox and calendar data has evolved, in part due to richer context provided by Work IQ.

A photo of Marzynski.

“The intelligence works behind the scenes as you use Outlook. Your inbox just gradually feels more relevant. Outlook adapts to your work patterns, making your inbox feel more like an assistant, instead of a filing cabinet of communications.”

Matthew Marzynski, principal product manager, core experiences, Microsoft Digital

Now when you turn to Copilot in Outlook to summarize email threads, it can surface decision points, action owners, and unresolved issues. Instead of treating email as a collection of messages and providing rote summaries, Copilot perceives it as a record of decisions and commitments over time.

Calendar-related experiences are on a similar trajectory. Meeting preparation and follow‑up suggestions are now drawing on prior interactions with the same participants, relevant documents that were previously shared, and historical patterns around similar meetings.

A graphic showing the three layers of Work IQ: data layer, context layer, and skills and tools layer.
Work IQ uses AI to apply contextual reasoning over different sources of work data, improving the results generated by the skills and tools that our knowledge workers use every day, such as Microsoft 365 Copilot.

Work IQ isn’t rule-based automation layered on top of Outlook. Users aren’t configuring new filters or workflows. Instead, the system is adapting based on observed patterns, meaning user behavior can remain the same while output quality improves

“The intelligence works behind the scenes as you use Outlook,” says Matthew Marzynski, a principal product manager for core experiences in Microsoft Digital. “Your inbox just gradually feels more relevant. Outlook adapts to your work patterns, making your inbox feel more like an assistant, instead of a filing cabinet of communications.”

Applying persistent memory

Another important aspect of Work IQ is the ability to retain persistent memory of each employee’s role, responsibilities, and work context. Copilot and other agents no longer need to be continually prompted with details about who the user is and what they’re working on. It learns that information and remembers it going forward.

This feature, also called persistent understanding, builds trust and increases efficiency each time an employee turns to AI for help with their work. AI systems that depend on manual context-setting don’t scale well across large organizations, which we at Microsoft Digital learned as we tested and deployed Copilot across the company.

“The user no longer has to tell the agent, ‘I work in this area, so please tailor your response to that’ every time,” says Anishkumar Ramakrishnan, a principal PM manager in Microsoft Digital. “With Work IQ, Copilot and agents recall it going forward. It remembers things that the user doesn’t even remember themselves about their past work and actions. This is the promise of intelligent context.”

From answers to action: Work IQ and AI agents

As organizations move toward integrating AI agents into all aspects of their day-to-day work, the value of Work IQ increases. Any agent—not just a general-purpose agent like Copilot—that can interpret vast amounts of your unstructured work data is going to produce results that are far more relevant than one that simply draws on general knowledge about a topic or process.

A photo of Jangir.

“Before, a builder had to go connector by connector and be very prescriptive—calendar read, email read, meeting access—just to build an agent. Now they can simply point the agent to Work IQ, and it gains contextual access across mail, calendar, meetings, and files through a single connector (API or MCP server).”

Naveen Jangir, principal architect, Microsoft Digital

Early agent implementations relied on narrower task-specific access to data. For each agent, a developer would have to build connections to a particular document library, mailbox, or set of calendar data. Each connection required separate consent and management, which generally resulted in a more limited scope.

But with Work IQ, builders can create agents using Microsoft Copilot Studio or other development platforms (such as Microsoft Foundry) that use APIs or Model Context Protocol (MCP) servers to connect to Microsoft Graph data. This enables them to bring the full power of enterprise data to any agentic creation, not just Microsoft 365 agents.

“Before, a builder had to go connector by connector and be very prescriptive—calendar read, email read, meeting access—just to build an agent,” says Naveen Jangir, a principal architect in Microsoft Digital. “Now they can simply point the agent to Work IQ, and it gains contextual access across mail, calendar, meetings, and files through a single connector (API or MCP server).”

This shift doesn’t just simplify agent development—it fundamentally expands what agents are capable of. Instead of operating within narrow, predefined tasks, agents can now reason across a broader work context to deliver better outcomes. For example, an agent supporting a project manager can surface relevant email threads, identify key stakeholders from meeting activity, reference the latest project documents, and highlight upcoming deadlines—all within a single interaction.

Intelligence without bypassing governance

From a governance perspective, Work IQ doesn’t introduce a new security model. Instead, it operates entirely within the existing Microsoft 365 data protection boundaries that our company and our customers already rely on.

The intelligence layer can access this enterprise data, but it does so while honoring permissions, sensitivity labels, access policies, and compliance controls defined at the source. Work IQ can only surface or act on information that the user—or an agent identity acting on the user’s behalf—is already authorized to access.

This inheritance model is intentional. Governance remains rooted in the data layer, not in the AI layer. Work IQ respects established controls such as identity‑based access and tenant policies, which means agents are generally given less access than human users.

“An agent user only gets access to what is explicitly shared with it,” Jangir says. “Human users typically have broader default access. By design in Work IQ, agents can usually see less than people, not more.”

For IT and security teams, this places the emphasis squarely on data discipline and identity controls, which are complementary security layers. Work IQ amplifies the value of well‑governed data and exposes weaknesses where governance is inconsistent. Admins remain in control of access and can turn off APIs and MCP server connections if they want to limit an agent’s data access.

Work IQ, Fabric IQ, and Foundry IQ

As we’ve scaled up Copilot and agentic AI internally, one lesson has become clear: Intelligence works best when it’s part of a layered infrastructure rather than working on its own.

That’s why Work IQ is just one context layer we’re using at Microsoft. We’ve also developed Fabric IQ and Foundry IQ, which are complementary layers in our overall data strategy. Each of these addresses a different aspect of enterprise intelligence.

A graphic showing the overlap of the three intelligence layers to produce more powerful agentic results.
Work IQ combines with the Fabric IQ and Foundry IQ intelligence layers to create a shared business ontology that enables the completion of more complex agentic tasks.

The three layers serve distinct but connected purposes:

  • Work IQ focuses on unstructured productivity data, helping AI understand how people work across email, meetings, documents, and collaboration signals.
  • Fabric IQ applies similar reasoning to analytical and structured data, adding context and explanation to metrics, trends, KPIs, and other business signals.
  • Foundry IQ provides the foundation for builders to create agents that draw from both worlds, connecting intelligence across Microsoft 365, analytics platforms, and line‑of‑business systems.

Taken together, these layers also contribute to something deeper: the emergence of a shared business ontology. By extracting and aligning business entities—such as people, projects, and processes—from both structured data in Fabric IQ and the unstructured signals captured by Work IQ, the system perceives meaningful connections that previously were hidden. This unified understanding allows agents to reason across domains with greater precision, linking metrics to the real work and making insights more actionable in context.

This architecture matters because it removes artificial seams. Agents shouldn’t need to shift between separate contexts for work content, enterprise data, or application logic. The IQ layers make it possible to deliver a single agentic experience that reasons consistently, applies governance uniformly, and moves with users across environments. Just as importantly, the same controls—identity, permissions, labeling, and policy—flow through each layer, keeping trust intact as capability expands.

At Microsoft, Work IQ and the other context layers are helping Copilot and agents to accelerate beyond AI experimentation. They are now vital operational tools that make everyone more productive across the global enterprise. Context and intelligence in agentic tools are a key part of the future of work, at Microsoft and for our customers as well.

Key takeaways

Here are some things to keep in mind as you prepare your own organization to take full advantage of Work IQ:

  • Treat the technology as infrastructure, not a feature. We didn’t formally roll out Work IQ. Its value emerged gradually as it improved Copilot responses and as our agent builders could more easily tap into unstructured enterprise data.
  • Expect improvements in AI quality without changes to your data. We saw measurable gains in relevance and user satisfaction even when underlying content remained the same, driven by better contextual reasoning across existing work signals.
  • Focus on how employees work, not just what content exists. Work IQ improves AI outcomes by connecting people, relationships, and activity patterns, resulting in more actionable and grounded responses.
  • Use Work IQ to move from assistance to action with agents. By giving agents access to contextual enterprise data through a unified layer, we enabled more automated workflows without requiring developers to manage dozens of connectors manually.
  • Invest in data governance early to maximize AI value. Because Work IQ inherits permissions and policies from the data layer, its effectiveness—and safety—relies on clear labeling, intentional access design, and disciplined data management.
  • Enable self-service collaboration data so it’s available for Work IQ. WorkIQ can only ground on data that is both available and not purposefully hidden. We make sure that our meetings are AI-enabled (and often recorded) and allow self-service in Teams and SharePoint, so the data is not hidden from Work IQ.
  • Build toward a unified intelligence model across work and data. Combining Work IQ with Fabric IQ and Foundry IQ means agents can operate seamlessly across different kinds of data and incorporate more intelligence into their output and actions.

The post How Work IQ is supercharging our AI usage at Microsoft appeared first on Inside Track.

]]>
23773
How we’re tackling Microsoft 365 Copilot governance internally at Microsoft http://approjects.co.za/?big=insidetrack/blog/how-were-tackling-microsoft-365-copilot-governance-internally-at-microsoft/ Thu, 07 May 2026 16:05:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=23360 Governance in the age of AI Unlocking the next generation of productivity tools Microsoft 365 Copilot combines the power of large language models (LLMs) with your organization’s data to turn employees’ words into some of the most powerful productivity tools on the planet—all within the flow of work. It suffuses the Microsoft 365 apps your […]

The post How we’re tackling Microsoft 365 Copilot governance internally at Microsoft appeared first on Inside Track.

]]>

Governance in the age of AI

Unlocking the next generation of productivity tools

Microsoft 365 Copilot combines the power of large language models (LLMs) with your organization’s data to turn employees’ words into some of the most powerful productivity tools on the planet—all within the flow of work. It suffuses the Microsoft 365 apps your people use every day—including Word, Excel, PowerPoint, Outlook, Teams, and more—to provide real-time intelligent assistance.

Findings from workplace surveys that we did internally here at Microsoft show that AI tools are having a significant and measurable impact across some of our major business functions:

Text graphic shows the measurable impact of AI tools on different functions at Microsoft with specific data points for marketing, IT, HR, and finance.

Getting governance right

With all the opportunities AI presents, your organization might be in the process of implementing Microsoft 365 Copilot. But it’s important to do that safely.

Copilot combs through your organization’s entire data estate in the blink of an eye, so the old method of security through obscurity doesn’t cut it. You need to assert control over where data flows throughout your tenant, so Copilot knows what it can and can’t access or display.

Learn from our Microsoft 365 Copilot experience

We learned a lot as the first large enterprise to deploy Microsoft 365 Copilot. We used those learnings to create this deployment and adoption guide that you can use at your company—check it out:

To ensure that proper data hygiene extends to AI-powered workflows, Microsoft designed Copilot to respect the sensitivity labels and data loss prevention (DLP) controls that organizations configure in their Microsoft Azure environment. That way, administrators can be confident that the right people and apps have access to the data they need, and that sensitive information doesn’t appear where it shouldn’t.

Our team in Microsoft Digital, the company’s IT organization, created a company-wide governance strategy to address this challenge. In the process, we learned valuable lessons that will be useful to any organization using Copilot.

“We’re entering an age where AI amplifies human capability at unprecedented scale, and the integrity of our data determines the integrity of that transformation. Thoughtful governance ensures that we balance adoption with risk to enable the business.”

 A photo of Fielder.

This guide outlines our process for developing and implementing a governance strategy that delivers the benefits of Copilot to Microsoft employees while minimizing the risks to our data estate. We share our internal learnings so our customers can get up and running quickly while avoiding pitfalls or surprises.

Follow along to find out how you can safely and effectively deploy Copilot at your organization—backed by rock-solid governance.

“We’re entering an age where AI amplifies human capability at unprecedented scale, and the integrity of our data determines the integrity of that transformation,” says Brian Fielder, vice president of Microsoft Digital. “Thoughtful governance ensures that we balance adoption with risk to enable the business. AI accelerates possibility and does so with clarity, confidence, and unwavering trust.”

Principles for effective AI governance

Use this set of tips to ground yourself as you read through this guide:

Enable self-service. Give employees the ability to create new workspaces across your Microsoft 365 applications. By maintaining all data on a unified Microsoft 365 tenant, you ensure that your governance strategy applies to any new workspaces.

Limit the number of information protection labels. Try to limit your taxonomy to a maximum of five parent labels and five sub-labels. That way, employees won’t feel overwhelmed by the volume of different options.

Use intuitive labels that mean what they say. Make your labels simple and legible. For example, a “business-critical” label might imply confidentiality, but every employee’s work feels critical to them. On the other hand, there’s very little doubt about what “highly confidential” or “public” mean.

Capture container labels for groups and sites. Label your data containers for segmentation to ensure your data isn’t overexposed by default. Consider setting your container label defaults to the “Private: no guests” setting.

Derive file labels from parent containers. Classify files according to their parent containers. That consistency boosts security at multiple levels and ensures that deviations from the default are exceptions, not the norm.

Train employees. Train your employees to handle and label sensitive data to increase accuracy and ensure they recognize labeling cues across your productivity suite.

Trust employees, but verify their work. Trust your employees to apply sensitivity labels, but also verify them. Check against DLP standards and use auto-labeling and quarantining through Microsoft Purview automation.

Implement lifecycle management and attestation. Use strong lifecycle management policies that require employees to attest containers, creating a chain of accountability.

Consider your default link-sharing configuration. Limit oversharing at the source by allowing company-shareable links—at least as secondary options—rather than forcing employees to add large groups for access. For highly confidential items, limit sharing to employees on a need-to-know basis.

Extract inventory to detect and report oversharing. Use Microsoft Graph Data Connect extraction in conjunction with Microsoft Purview to catch and report oversharing after the fact. When you find irregularities, contain the vulnerability or require the responsible party to repair it themselves.

Learn more

How we did it at Microsoft

Further guidance for you

Chapter 1: Enable self-service

Empowering employees with secure self-service

Applying self-service principles to the way we manage labeling and governance emerged as a crucial step for us. 

Self-service is a core tenet of employee empowerment here at Microsoft. We want to give every employee the independence to create the resources they need without engaging IT. But that level of freedom relies on ensuring our Microsoft Digital governance team identifies and protects valuable data. As a result, our employees can implement and own the containers, workspaces, and content they need to do their work productively. 

A container or workspace is a logical unit of content storage associated with a designated roster of collaborators. Common containers include SharePoint sites, Viva Engage communities, Outlook groups, and Teams channels.

Self-service forms the foundation of our entire governance strategy. Employees can create workspaces and content across many of the Microsoft tools they use for their day-to-day work, including SharePoint, OneDrive, Teams, and Power Platform. That freedom enables a culture of innovation and agility, where people can work together across teams and geographies without encountering “IT gating,” the need for IT to get involved in enabling day-to-day activities.

By encouraging collaboration in place, our tenant structure frees employees from resorting to email attachments or working in overly broad and open workspaces. As an IT team ourselves, we understand the value of eliminating IT gating for minimizing the time and effort our professionals need to invest in keeping employees productive.

This kind of data hygiene isn’t just about Microsoft 365 Copilot. It maintains data security and compliance wherever employees access company content and information. But because Copilot depends on the ability to access an organization’s data estate, good governance is essential for keeping it within bounds—especially in a self-service culture.

Here are the key pillars of our asset governance:

Empower employees
  • Support self-service creation
  • Use lifecycle management
  • Offer user education and awareness/trainings
  • Implement monitoring and auditing
  • Adopt insider risk management
Identify valuable and vulnerable content
  • Require classification for containers
  • Scan with Microsoft Purview Data Loss Prevention and Information Protection services
Protect assets
  • Limit reach
  • Enforce policy
  • Use conditional access or multifactor authentication
  • Apply Microsoft Purview Data Loss Prevention and Information Protection services
Ensure accountability
  • Manage group or site ownership
  • Review external membership
  • Generate reports

Responsible self-service

Self-service container creation has abundant benefits, but it also poses some challenges for content governance and security—things like oversharing, unneeded asset sprawl, and data leakage. To address these challenges, our Microsoft Digital governance team has established self-service principles that balance the needs of employees and the company.

We empower with accountability

Accountability has responsibility. Any full-time employee can create a workspace, but they’re responsible for re-attesting its compliance every six months to ensure it meets our governance requirements. They also need to attest that they still require and maintain the resource. They need to manage their own content and ensure it’s properly classified, labeled, and secured. The content’s accountable owner makes any decisions about the workspace with respect to reach or the desire to maintain it. That removes any guesswork for IT about whether a site is still valued and cared for.

We empower with guardrails

We secure assets by default and expand access based on employee needs.

We trust, but we also verify

Microsoft Information Protection (MIP) sensitivity labels and Purview DLP act as guardrails for employee-led governance efforts.

As we in Microsoft Digital have worked to improve the company’s overall governance posture, we’ve learned several important lessons. When you consider self-service container creation, there are a few questions to ask yourself:

  • Who do you trust to create containers? At Microsoft, we reserve complete self-service capabilities for full-time employees. Then, we configure those privileges in Microsoft Entra ID to define who can create Microsoft 365 Groups. These users need to take relevant trainings, and we hold them accountable for the containers they create.
  • Where does employee self-service make sense? Different employees will require self-service in different environments. Will yours need to operate within SharePoint? Power Platform? Teams?
  • What are your lifecycle rules? Think about your policies and rule sets. Who’s accountable? What does the lifecycle look like?
  • What are your naming rules? A clear taxonomy can act as an extra signpost and organizational driver for your users. It can also be useful to think through what names are explicitly helpful or obscure. At Microsoft, we use a blocked word list, but we don’t prefix or suffix all groups or site names to avoid overloading the employee experience.

When you’ve settled on degrees of autonomy and where to apply it, you can begin your AI governance journey. Find out how to configure containers for self-service.

Key takeaways

Use these tips—which are based on what we learned here at Microsoft—to enable self-service in Copilot governance at your organization:

  • Front-end load on building your strategy. Put thought into your environment and tenant architecture, key personas, and scenarios before adoption.
  • Account for hesitancy. Understand that IT organizations have inherently cautious habits, and self-service might seem like a leap. As you lay out the business value for self-service container creation, illustrate the safety backstops as well. Also consider the risks if you don’t take this step, like employees misusing existing sites or other means not supported by IT.
  • Bring leadership on board. Make the business case and offer reassurances that greater flexibility doesn’t equal greater vulnerability.
  • Assess your current setup. Consider your existing data hygiene and how it needs to extend to accommodate AI.

Learn more

How we did it at Microsoft

Further guidance for you

Chapter 2: Establish container labels and set well-scoped, intuitive defaults

Balancing freedom with trust through an easy-to-use labeling taxonomy

Self-service container creation forms the foundation of our employee-centric governance strategy. As part of that freedom, our Microsoft Digital governance team has established baseline protections inherent to all containers, and those protections depend on sensitivity labels. Microsoft 365 Copilot respects labels, so establishing effective labeling practices extends data security into our employees’ AI usage.

Baseline labeling habits

Employees need to label every container or workspace they create using Purview Information Protection (PIP) container labels. It’s a matter of policy at Microsoft: If it isn’t labeled, we delete it. We use container labeling for data delineation and to apply consistent protection and governance policies to containers based on their sensitivity and purpose.

Microsoft labels break out into four different categories:

  • Highly confidential. This is our most critical data. Employees can only share this with specifically designated recipients.
  • Confidential. This is sensitive business data that’s crucial to achieving our goals. Employees should limit distribution to a need-to-know basis.
  • General. The “General” label includes data we use and share throughout Microsoft, like personal settings and postal codes. They’re visible internally throughout Microsoft.
  • Public. Public data is unrestricted and suitable for open, external consumption. It includes open-source code or financials the company has announced. Employees can share this data freely.

Container labels provide two things:

  • First, they drive user awareness over how to handle content. For example, if something is highly confidential, employees shouldn’t talk about it in the café.
  • Second, they illustrate what data is appropriate for which container. In other words, they signal to an employee that they shouldn’t store highly confidential documents on a general site.

Our Microsoft Digital governance team predefines and centrally manages labels to align them with broader MIP sensitivity levels used for email, files, meetings, and containers. Those include the same four categories: “highly confidential,” “confidential,” “general,” and “public,” although we don’t use the last one for containers.

Matching labels with policies and protections

Each label we’ve defined has a set of protection settings that include policies around characteristics like guest allowance and membership openness. They also drive inherited file labeling, which we use for encryption.

At its core, container classification communicates four things:

  • Privacy level: Labels determine whether the workspace is broadly available internally or it’s a private site.
  • External permissions: We administer guest allowance via the group’s classification, allowing specified partners to access teams when appropriate.
  • Sharing guidelines: We tie important governance policies to the container’s label. For example, can employees share this workspace outside Microsoft? Is this group limited to a specific division or team? Or is it restricted to specific people? The label establishes these rules.
  • Conditional access: While not implemented at Microsoft, tying identity and device verification to container labels introduces additional governance controls.

After extensive experimentation, we arrived at our current schema for how container sensitivity labels align with MIP policies. Your organization might make different choices about your labels’ relationships with information protection policies, but this graphic can give you an idea of what a healthy governance ecosystem looks like:

A chart shows the different types of data container labels and what level of access is given for each one.
Our Microsoft Digital schema clearly lays out what each container sensitivity label means and how it affects content.

Building a process around employee ownership

The labeling process works like this: When employees create a new container, they’re responsible for selecting a container label that matches the sensitivity and purpose of the content they intend to store and share. By default, we lock new containers, which means that only the owner and members can access them. Locked containers prevent unauthorized or accidental access to their content.

Container owners can unlock the container if they need to share content with a broader audience within the organization or external partners. Container owners can also change the container label if the sensitivity or purpose of the content changes over time.

At Microsoft, this process provides the right combination of flexibility and protection while empowering employees with effective self-service.

Key takeaways

Here are some of the main insights we’ve gleaned from our own data-labeling practices, which you can apply to your efforts in this area:

  • Use intuitive labels. Your employees will be the ones applying labels, so make those labels intuitive. For example, “highly confidential” is easy to understand, while “business-critical” can be interpreted many ways from a sensitivity standpoint.
  • Make use of existing defaults. Identify the security needs and regulatory compliance that are specific to your organization and use built-in governance controls available through Microsoft tools.
  • Limit the number of labels to 5×5. Keep labels minimal to avoid overtaxing your employees’ understanding. We recommend restricting your labeling schema to no greater than five main labels with five sub-labels each—and the fewer, the better!
  • Pilots are powerful. Experiment with sensitivity labeling through a small group of early champions, then roll these features out alongside an adoption and education initiative.

Learn more

How we did it at Microsoft

Further guidance for you

Chapter 3: Derive file labels from parent containers

Using default file-labeling based on container labels

We’re helping our teams stay consistent with how they create and store resources by making sure that default file-labeling happens based on container labels. Here’s how that looks for our employees:

  1. SharePoint and other containers support default library labels, which we configure to align with the container label through mapping we define in Purview.
  2. For instances where we need to define default library labels for tools that don’t have container labels, like OneDrive for Business, we create custom scripts. For OneDrive, we “secure by default” by using a default label like “Confidential\Internal-only,” which means that any file type that supports protection will remain protected–even if it’s accidentally left behind on a device, emailed externally, or purposefully shared externally. Without lowering the label, the default protection will not be decryptable by external actors.
  3. By default, new items that are unlabeled inherit the label of the container that stores them. That helps employees apply the correct label and avoid misclassification. For example, if an employee creates a new document in a SharePoint site labeled “confidential,” the document will automatically receive that label.
  4. Employees can change the item label if the sensitivity or purpose of the content differs from the container label. But that only works in one direction; they can’t store files with higher-confidentiality labels in a lower-confidentiality container. For example, they can downgrade a file in a “highly confidential” container to “general” if it doesn’t require heightened protection, but they can’t upgrade a file in a “general” container to anything above that grade. SharePoint will provide warnings to site owners when it detects label mismatches—for example, when a file label is more sensitive than its container’s.

The following graphic shows how default file-labeling is impacted by container labels and other sharing limitations:

Graphic shows the different levels of protection for different container labels at Microsoft.
By trusting employees and setting good defaults, we’re able to account for 99% of our governance needs.   

By defaulting file labels to their container labels, you can ensure that every item and collaborative space will align with both its context in your organization and your information protection policies. As a result, Copilot will respect those labels and their corresponding information protection policies.

Key takeaways

Here are some key tips for setting up container-file relationships, based on what we’ve learned through our own experience here at Microsoft:

  • Communicate the relationship between files and containers. Employees might not understand the relationship between files and their containers intuitively. When you implement your labeling strategy, be sure to include education about container-file derivation.
  • Guide through correction. Many employees learn best from practice, not instruction. Include automated messages that correct edge-case behaviors like trying to make a file in a confidential container generally available.
  • Ensure you’re comfortable with your label defaults. Employees will more often than not use the default, so ensure your defaults are correct and reflect your organization’s needs.
  • Reinforce the importance of file labels. Because a file can be moved or downloaded from its original container, the only way to protect that information is to ensure its label remains durable. Embed that durability in your object label configurations.
  • Match container and file label defaults. Whenever possible, make the container and file defaults the same from the outset. If you start with different labels or policy sets at the outset, it will be difficult to reconcile those changes later.

Learn more

How we did it at Microsoft

Further guidance for you

Chapter 4: Train employees

Empowering our employees: A joint effort between IT and users

Training your employees on how to handle and label sensitive data continues to be a critical step on our governance journey. 

Establishing a robust labeling strategy is only part of good governance. When it comes to getting employees on board, culture is as critical as policy.

At Microsoft, employee learning and development are how we move sensitivity labeling from the administrative sphere into day-to-day practice. It helps us increase the accuracy of how our labels are used and ensures that our employees recognize labeling cues when they appear across our productivity suite.

Every incoming Microsoft employee takes our Standards of Business Conduct and security trainings. As part of that process, we created an internal SharePoint resource dedicated to educating employees about their responsibilities for labeling and adhering to our governance policies. It educates employees about the philosophy behind our policies, shares a simplified overview of our sensitivity label structure, and provides practical, app-specific guidance for self-service labeling.

Text graphic shows the Microsoft labeling taxonomy that determines how employees determine what sensitivity label to use.
This quick-reference guide helps Microsoft employees understand our labeling taxonomy at a glance.

Effective learning and development assets

As you build out your employee education assets, consider emulating our content with the following elements:

1. Overview

It will be much easier for employees to act according to your governance policies if they understand what the policies do and why they’re so important. Our overview illustrates the relevance of sensitivity labeling for security and compliance and reinforces our employees’ role in maintaining them.

2. A quick-reference guide

A visual guide will help employees understand how labels relate to each other and what they accomplish. At Microsoft, we use a helpful flowchart that provides an outline of our labeling taxonomy without overloading employees with details. Placing it near the beginning of your training content grounds employees in the knowledge early, before they dive deeper into the details.

3. Technical education

Our learning material includes a section on how labeling works within our data estate. Then, it proceeds into an in-depth description of how each label or classification interacts with users’ content. Including this section will make labeling more tangible for your employees.

4. App-specific guidance

At this point, our guidance documentation progresses through the most common app-based use cases for sensitivity labeling: Microsoft 365 files, Teams, Power BI, and PDFs, as well as AIP and other file types separate from Microsoft 365. This app-by-app procedural content will help employees home in on their most common scenarios and educate themselves accordingly.

Aside from laying a solid foundation as an IT team, the most effective way to promote good governance is by bringing your workforce on board. Robust learning and development content is a powerful lever for establishing a culture of data security.

Key takeaways

Here are some of the key insights we’ve drawn from our own employee training in Copilot governance, which can guide you as you set up your own trainings.

  • Educate from day one. People will only do what they know, so ensure employees know your policies and how to enact them. Build robust education into your labeling and governance strategy, ideally as part of employee onboarding.
  • Don’t neglect in-app education opportunities. Labeling cues are an excellent opportunity for helping employees remember their responsibilities. Make label descriptions brief and tangible during in-app experiences.
  • Provide education on-ramps. Nobody’s memory is perfect. Link out to relevant information as part of label descriptions so curious employees have a chance to reinforce their knowledge.
  • Engage actively and situationally. If breaches occur or certain teams underperform, coordinate with relevant managers to refresh employee knowledge.

Learn more

How we did it at Microsoft

Further guidance for you

  • Learn more about sensitivity labels. This Microsoft Learn content provides an overview of sensitivity labels, including how they help classify, protect, and govern sensitive data across Microsoft 365.

Chapter 5: Trust employees, but verify their work

Self-service with guardrails: Backstopping our employee efforts with technology

Trusting your employees while also verifying that their actions are secure via automation is a crucial step. 

Thanks to our education efforts and intuitive labeling interfaces, we trust employees to apply sensitivity labels. But we also verify their work. It’s how we catch the 1% of edge cases where problems might arise.

We accomplish that by checking files against our data-loss prevention (DLP) standards and using auto-labeling and quarantining when we need them. Swiftly tying up any loose ends eliminates wayward items that Microsoft 365 Copilot might scoop up during the course of its work. Another way we verify employee decisions is by asking them to provide a reason when they downgrade a security label.

Data-loss prevention (DLP) is a set of technologies and practices centered around Microsoft Purview that help detect, monitor, and reduce the risk of sensitive data being inappropriately shared or accessed.

At Microsoft Digital, we use Purview DLP policies to define the rules and actions for detecting and protecting sensitive data across Microsoft 365, SharePoint, OneDrive, and Teams.

DLP policies support vulnerable data types and scenarios that require protection. They include any kind of information that might introduce inappropriate access to company data or intellectual property:

  • Access credentials like keys or tokens
  • Personally identifying information
  • Financial data
  • Non-public source code
  • Sign-in information

Reports and dashboards are available via Purview to help our team monitor and analyze content activity and compliance across the organization. They also provide insights into the volume, location, and usage of sensitive data, as well as any incidents and alerts that indicate potential data breaches or violations.

For example, an employee might label something as “General,” but it contains credentials or other sensitive end-user identification information (EUII). In those instances, Purview will automatically block the file from access beyond its owner or reapply a more appropriate label.

Automation and escalation

We’ve configured Purview to automatically remediate these kinds of issues or escalate them to our Microsoft Digital governance team for resolution when an issue is more complex. DLP remediation and escalation processes can involve several different groups of stakeholders depending on the severity and impact of the incident or alert:

  • Content owners
  • Content champions
  • The MIP team
  • Our legal team
  • Security

We use Microsoft 365 Purview to run DLP remediation operations at scale.

  1. DLP systems acquire telemetry from the Microsoft 365 activity management API. Backend processing cleanses the data to build relevant insights and surface them through Power BI dashboards.
  2. We flag information about files and aggregate it at the file level, then assign it to the last modifier for remediation action.
  3. If users don’t act on the files quickly, the DLP team scopes risky sites to quarantine any files with vulnerabilities.
  4. All activities—including sharing, labeling, and changing labels—get written into the unified audit log and into Sentinel to monitor for possible risks.

Fortunately, all these features and functionalities are available out of the box through Microsoft 365 and Purview. After you’ve established your labeling strategy and policies, it’s just a matter of adding guardrails to your self-service environment. By automating information protection through quarantining content or rightsizing its label, you can keep Copilot from making sensitive information available where it shouldn’t.

Key takeaways

Here’s what we’ve learned from our trust and verification process, which can inform your own process:

  • Consider your key escalation partners. When human intervention is necessary, it’s important to have immediate access to the relevant stakeholders. Assemble your list and build it into your process.
  • Understand DLP’s limitations. Purview DLP is a powerful set of capabilities, but it still relies on automation, which can miss things humans don’t. For example, DLP might not understand the code name for a product and fail to catch it during automated verification.
  • Identify and manage exceptions. There are very few absolutes in IT, so you’ll always need exceptions. For example, finance professionals will often need to include passwords or credit card numbers in working documents, so we exempt them from Purview DLP oversight with that team. At Microsoft, we use exemption groups to exempt certain employees.
  • Involve experts. Your legal, HR, and security teams will be key allies in this process. Engage them early to help you flesh out risk factors and vulnerabilities.

Learn more

How we did it at Microsoft

Further guidance for you

Chapter 6: Implement lifecycle management and attestation

Pairing trust with accountability: How we’re maintaining our data hygiene with attestation

We focused on strong lifecycle management policies and employee attestation to help us get our lifecycle management right. 

Attestation and self-service go hand-in-hand. In simple terms, it means employees can create what they need, but they’re accountable for its upkeep. In turn, that chain of accountability makes sure Copilot only accesses clean and appropriate data.

To support this, SharePoint now offers both activity‑based and non‑activity‑based attestations through SharePoint Advanced Management, giving organizations flexible ways to validate that their containers are being properly maintained. Microsoft Entra also provides an inactive group expiration policy that requires renewal of any inactive Microsoft 365 Group (like a team, group-connected site, or Outlook group).

At Microsoft, we follow the principle of data minimization. That means only content that’s necessary and relevant for the company’s operations and objectives should exist in storage. Data minimization reduces the risk of oversharing content that isn’t cared for by employees, minimizes asset sprawl, halts data leakage, and improves quality and usability.

To implement this principle, we require that every existing container has attestation. By extension, we delete information that doesn’t have a full-time employee to care for it or that has become stale or irrelevant.

Attestation is the process of verifying and validating the existence, ownership, and purpose of a container and ensuring it complies with content governance and security policies.

At Microsoft, we require attestation from a full-time employee for all shared workspaces every six months to confirm several aspects of their containers:

  • It’s correctly labeled.
  • Users actually care about its ongoing existence.
  • The roster of people with access is accurate and necessary.
  • Sharing capabilities are appropriately restrictive or permissive.
  • It complies with corporate retention guidelines.

If a container or an item doesn’t have attestation, we consider it orphaned or abandoned, and it’s subject to deletion. Note that we archive deleted items over an extended period, in case our employees decide they need them after the fact.

Managing exceptions

If a container is subject to a retention or hold for our legal team, that supersedes any deletion event. Generally speaking, containers where the legal team is the accountable owner aren’t subject to re-attestation because we handle those lifecycles more granularly based on Purview retention policies.

Ultimately, every organization will have to decide what makes the most sense for them. Applying these principles will help you maintain organization-wide data hygiene, which prevents over-access from Copilot.

Key takeaways

Here are some tips that come from our experience managing the product lifecycle for Microsoft 365 Copilot here at Microsoft.

  • Choose a meaningful attestation interval. The attestation interval should be short enough that it doesn’t introduce risk through neglect and long enough that it isn’t unnecessarily burdensome for employees. Think about what makes the most sense for your people by analyzing their behaviors.
  • Communication is key. Be sure that the attestation requests you create for employees contain both the objective for motivation and simple instructions. That will increase buy-in and smooth the process.
  • Base non-compliance response on severity. The severity of non-compliance will vary based on different files and containers. Some might be more relaxed, and others more strict. Determine a strategy for deciding which is which.
  • Include reasonable resolution and recovery options. Consider your resolution and recovery intervals after a lapse in attestation. You’ll need to balance between items’ sensitivity, employees’ bandwidth, and the infrastructure cost of extended archiving for recoverable items.

Learn more

How we did it at Microsoft

Further guidance for you

Chapter 7: Enable company-shareable links

Enabling fluid, secure collaboration: Extending access with company-shareable links

We’re finding that the best way to reduce oversharing is by addressing it at the source.

At Microsoft Digital, we recognize that content sharing is essential for collaboration and productivity. Employees need to share content with both internal and external audiences. But that also poses a risk of content oversharing when employees expose material to more people or for longer than necessary. It might also mean they’ve shared content without proper protection or classification.

In many cases, employees need to share content outside its container. That might include simply sharing a specific file outside of the container’s roster to enable collaboration in place without resorting to making a copy of the file. On the other hand, someone might need to email the file as an attachment.

Using company-shareable links

We limit oversharing at the source by enabling employees to directly share with users or groups, or by using company-shareable links (CSLs) for all SharePoint sites and items (except ones labeled “highly confidential”).

A CSL is a type of link that allows anyone who receives it within our organization to access the content. CSLs are convenient and easy to use, and they promote a culture of openness and transparency.

Before CSLs, employees were forced to share content with large security groups, because they didn’t know which groups contained everyone who needed access and manually adding every unique user was too cumbersome. That behavior leads to oversharing, because anyone with access can stumble on the content in Microsoft Search or via an answer from Copilot. Any Microsoft 365 discovery scenario will security-trim results, so it’s important that users can’t directly access things they don’t need.

While employees can pass a company-shareable link around within the company, it isn’t discoverable in Microsoft Search or Copilot, because only users who received the link directly via email or chat will have pre-granted access. It might seem counterintuitive that a CSL is more secure, but it eliminates the need for standing access to content and provides greater protection.

Finally, we allow content owners to modify or revoke CSLs if their sensitivity or purpose changes, or if sharing is no longer necessary. The content owner can also set an expiration date or a password for their link to enhance security and control.

Note that company-shareable links are no longer the default option, but they are still available as a sharing option for the reasons outlined here.

Extra protection for highly confidential items

Our governance team at Microsoft Digital determined that we should enable CSLs by default for all containers and items labeled “public,” “general,” or “confidential.” As a result, employees can share content with their colleagues without having to grant individual permissions or manage access requests.

There are some kinds of content that employees absolutely shouldn’t share through a company-shareable link. The risk emerges if someone copies the link into an open location like a broadly accessible document or community. You’ll have to decide where to draw that line for your organization. At Microsoft, we’ve elected to disable CSLs for all containers and items that are labeled “highly confidential.”

At Microsoft, highly confidential items require need-to-know access for specific people. For these files, employees use links they designate for specific people, which allows access to only individuals the content creator or owner explicitly identifies. In those situations, large security groups aren’t appropriate in any case.

We also want to drive broad sharing to SharePoint, so we discourage CSL use on OneDrive by automatically implementing expiration policies on OneDrive-created CSLs.

These policies compel employees to think about who needs access to content and to take deliberate action before sharing. In some ways, the policies act as an extra gate or prompt to keep our people security-conscious during the sharing process.

At Microsoft Digital, we tailored our policies to the company’s specific needs, but it provides a blueprint for other organizations to build a CSL strategy. Deciding what should be sharable and how will help you ensure robust information protection that’s still flexible enough to foster collaboration and productivity.

Key takeaways

Here are some key learnings we took from our CSL strategic work at Microsoft, which you can apply to your own efforts in this area:

  • Establish thresholds for company-shareable links or specific-people links. Align your CSL policies with the sensitivity labels that meet your organization’s security needs. Above a certain threshold, it might make sense to require links for specific people.
  • Embed education in the process. Employees will need time to get used to this structure. Create education communications early in the process, and configure your labeling interface to display information about the sharing implications of different labels.
  • Manage expectations for security teams. CSLs are counterintuitive in terms of safety. They might make security professionals uncomfortable because employees are free to share them internally with anyone. Reinforce that CSLs are safer than giant security groups, which will be the other default behavior for employees. And unlike security groups, they won’t show up in Microsoft Search.
  • Build data hygiene on good defaults. Most people will take the simple path, so make the simple path the safe path. Generally speaking, employees leave the defaults intact. If CSLs are your default, that’s the behavior it will drive for your employees.

Learn more

How we did it at Microsoft

Further guidance for you

Chapter 8: Extract inventory to detect and report oversharing

Remediating oversharing errors when they occur: Reporting on broad-access files and sites with Microsoft Graph Data Connect

When oversharing does slip through, it’s important to have systems in place to catch it. 

In spite of our Microsoft Digital governance team’s best efforts to limit oversharing at the source, it can still occur. In some ways, it’s inevitable.

Organizations are made up of people, and so will always be vulnerable to human error. Left unchecked, content oversharing can have negative consequences for an organization, including data breaches, compliance violations, or reputational damage. It will also give employees access to content through Copilot that isn’t appropriate.

To detect and mitigate content oversharing, we use Microsoft Graph Data Connect to report on every broad-access file or site with more sensitive labels. It helps us access and analyze data from Microsoft 365, SharePoint, OneDrive, and Teams using Azure Data Factory, Azure Synapse Analytics, or Azure Machine Learning. We then connect those datasets in our data estate using Azure Synapse Spark and track how many SharePoint sites and items are currently overshared based on our business rules.

One of the principal benefits of Microsoft Graph Data Connect is accessing the information we need through each of these technologies in a secure and scalable way, with control governed by our tenant admins.

Flow-chart graphic shows how Microsoft Graph Data Connect analyzes and remediates oversharing instances in our network.
We use Microsoft Graph Data Connect to detect, reveal, and remediate oversharing in the rare cases where it occurs.

Note that there will always be cases where we create exemptions to sharing limits. The policies around these exemptions are laid out as part of our Enterprise Governance, Risk, and Compliance guidelines.

Reporting for accountability

Our tenant’s data team uses Microsoft Graph Data Connect to generate reports on every file or site on the tenant with a broad access level, like a CSL or link that can be shared with anyone. It also monitors any item with a sensitive label like “confidential” or “highly confidential.”

These reports provide information and insights on the content’s owners, recipients, activity, and content protection and compliance status. They also help identify and prioritize potential cases of content oversharing.

At Microsoft, this output is helpful for several groups of stakeholders:

  • We share the reports with the content champions responsible for reviewing and validating any cases of content oversharing.
  • We use the reports to contact and educate the content owners on how to resolve oversharing issues and comply with our governance and security policies.
  • We share the reports with the legal and security teams responsible for investigating and responding to cases of content oversharing that involve legal or security risks and incidents.
  • We track our improvement over time as we enforce policies on our assets.

To help customers benefit from this kind of visibility, we’ve created a freely available reporting template. We encourage you to use this tool to track oversharing.

Beyond weaving your Microsoft Graph data connect and data export into your own data estate, you can now also use SharePoint Advanced Management in SharePoint Premium to get a list of sites that meet a set of criteria that you select. We use this capability to find all of our sites that share Highly Confidential data to more than 5,000 users. We then use the same capabilities to selectively require our site owners to fix any anomalies we discover.

Get more information on this data access functionality in SharePoint from Microsoft Learn.   

With the right controls and policies in place, you can minimize the number of oversharing errors your employees commit. But when errors do occur, a proactive detection strategy quarantines the risk from Copilot, even as your staff stays connected and collaborating.

Key takeaways

Some of the things we learned about setting up an oversharing detection and reporting system included:

  • Select the tools that work best for you. Between Microsoft 365 and Azure, it’s likely you already have access to the tools you need to set up your reporting apparatus. Explore out-of-the-box functionality before building your own solution.
  • Get reports to the right people. Collaborate with stakeholder teams to nominate point people who will receive oversharing reports and take action or communicate findings.
  • Put thought into your communication strategy. Work with internal comms professionals to determine the best communication strategy when you detect oversharing, especially when speaking with content owners.
  • Consider the content of your reports. Different stakeholders will require different information. Work with individual teams to determine what their reports should look like.

Learn more

How we did it at Microsoft

Further guidance for you

“As AI becomes woven into the fabric of how we work, governance is no longer just an operational requirement—it’s a strategic imperative.”

The way forward

Getting governance right in the age of AI

The advent of AI tools like Microsoft 365 Copilot is a once-in-a-generation development. At this point, we’re still learning all the ways that these tools can be used to unlock creativity, productivity, collaboration, and innovation.

But we can be sure of one thing: implementing them securely and effectively should be priority one.

“As AI becomes woven into the fabric of how we work, governance is no longer just an operational requirement—it’s a strategic imperative,” says David Johnson, a principal architect in Microsoft Digital. “When we pair powerful tools like Copilot with thoughtful oversight, we ensure that innovation accelerates our mission without compromising our security or our values.”

If you’re deploying Copilot to your organization, the lessons we’ve learned at Microsoft Digital can act as a roadmap for your own journey.

Ultimately, the most important thing is to consider the data implications of AI assistance and plan accordingly. Diligence and forethought will make sure your employees get all the benefits of next-generation AI technology while your organization stays protected.

Welcome to the age of AI.

Key takeaways

This guide reflects what we learned as we set up and implemented our governance processes during our internal rollout of Microsoft 365 Copilot. Here are some overall insights to keep in mind when establishing governance controls at your own organization.

  • Build governance on intentional design, not inherited habits. Thoughtfully define your tenant architecture, sensitivity labels, lifecycle policies, and container defaults to create a governance environment that is both secure and scalable.
  • Empower secure self‑service. Give employees the freedom to create the workspaces they need, backed by intuitive labeling and clear accountability for the content they manage.
  • Keep labeling simple, consistent, and enforced by defaults. Use a minimal, intuitive sensitivity label taxonomy and rely on container‑based default labeling to ensure that files stay consistently protected wherever they go.
  • Trust users—but verify with automation. Use Purview DLP, auto‑labeling, quarantining, and escalation workflows to catch exceptions and prevent sensitive data from being exposed through Copilot.
  • Maintain data hygiene with lifecycle management and attestation. Require regular re‑attestation, remove stale or unowned content, and use SharePoint Advanced Management to support both activity‑based and non‑activity‑based attestations.
  • Make collaboration safer with thoughtful sharing defaults. Use company‑shareable links (CSLs) and clear link‑sharing policies to reduce oversharing while still enabling fluid, secure collaboration.
  • Detect oversharing proactively and remediate quickly. Use Microsoft Graph Data Connect and SharePoint Advanced Management reporting to surface broad‑access content, notify owners, and correct issues before Copilot surfaces inappropriate data.

Learn more

Try it out

Get your organization and data ready for Microsoft 365 Copilot.

The post How we’re tackling Microsoft 365 Copilot governance internally at Microsoft appeared first on Inside Track.

]]>
23360
Powering the technical veracity of AI at Microsoft with a Center of Excellence http://approjects.co.za/?big=insidetrack/blog/powering-the-technical-veracity-of-ai-at-microsoft-with-a-center-of-excellence/ Thu, 16 Apr 2026 14:15:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=23147 When we launched our AI Center of Excellence (CoE) in 2023, we had a straightforward goal: Help our organization experiment with AI, learn quickly, and do it responsibly. Our teams across Microsoft Digital—the company’s internal IT organization—leaned in. We built tools, workflows, and AI enabled solutions at speed. Momentum followed, along with real enthusiasm and […]

The post Powering the technical veracity of AI at Microsoft with a Center of Excellence appeared first on Inside Track.

]]>
When we launched our AI Center of Excellence (CoE) in 2023, we had a straightforward goal: Help our organization experiment with AI, learn quickly, and do it responsibly.

Our teams across Microsoft Digital—the company’s internal IT organization—leaned in. We built tools, workflows, and AI enabled solutions at speed. Momentum followed, along with real enthusiasm and growth.

A photo of Wu.

“We did a lot of good work building community and excitement. But at some point, we needed to evolve and put more structure around what we’d built.”

Qingsu Wu, principal group product manager, Microsoft Digital

But increasing scale required us to evolve our approach.

As adoption accelerated, we began to see duplication, uneven governance, and growing gaps between strategy and delivery. What helped us move fast early on wasn’t enough to sustain impact over time.

“We did a lot of good work building community and excitement,” says Qingsu Wu, a principal group product manager who leads the AI CoE at Microsoft Digital. “But at some point, we needed to evolve and put more structure around what we’d built.”

AI agents and solutions began appearing across Microsoft Digital. Different teams solved similar problems. Standards were interpreted differently. Reporting was inconsistent, and in many cases manual.

The question was no longer, “How do we help teams try AI?” It became, “How do we turn AI into consistent, measurable outcomes at scale?”

Answering that question required a change in how our CoE operated.

Rather than acting primarily as an advisory group, the AI CoE evolved into an execution‑focused function. Its role expanded from guidance to coordination, helping set priorities, define guardrails, and connect AI work directly to business outcomes.

The goal wasn’t to slow AI innovation down, but to help it move in the correct direction with more agility and better scalability.

Evaluating AI for Microsoft

The AI CoE connects AI strategy to execution across Microsoft Digital. It operates as a cross‑functional coordination layer that sets direction and creates shared accountability for how AI work gets done.

A photo of Khetan.

“We can see patterns that a single team can’t. We’re translating AI CoE strategy and enterprise priorities into clear execution plans that work in each organization’s context. That helps us align priorities and make sure the biggest bets are actually landing.”

Ria Khetan, senior program manager, Microsoft Digital

The CoE brings our leaders and practitioners together from AI, data, responsible AI, and operations to answer questions collectively. We use that cross‑disciplinary view to operate above individual projects without losing touch with day‑to‑day reality.

The CoE looks across the organization and answers questions individual teams can’t answer on their own.

  • What AI initiatives are already in flight?
  • Which ones matter most to the business?
  • Where are teams duplicating effort?
  • Where do we need clearer standards or stronger governance?

“We can see patterns that a single team can’t,” says Ria Khetan, a senior program manager in Microsoft Digital who helps lead program management for the AI CoE. “We’re translating AI CoE strategy and enterprise priorities into clear execution plans that work in each organization’s context. That helps us align priorities and make sure the biggest bets are actually landing.”

We’ve designed the AI CoE to act as the connective tissue between leadership intent and execution on the ground. It helps ensure that AI work across Microsoft Digital moves forward with purpose, consistency, and measurable impact.

Building transformation on core pillars

The AI CoE establishes a common structure that helps our teams work toward the same outcomes, even when they are building different solutions.

A photo of Campbell.

“We use the CoE to bring consistency to how AI work gets done. It gives us a way to step back and ask whether we’re solving the right problems and whether we’re set up to scale.”

Don Campbell, principal group technical program manager, Microsoft Digital

The operating model is intentionally simple.

AI initiatives are reviewed against shared pillars that help teams think beyond individual projects. These lenses ensure the work aligns to business priorities, can scale safely, has a clear delivery path, and supports responsible adoption.

“We use the CoE to bring consistency to how AI work gets done,” says Don Campbell, a principal group technical program manager who leads AI strategy here in Microsoft Digital. “It gives us a way to step back and ask whether we’re solving the right problems and whether we’re set up to scale.”

Our CoE uses these four pillars to guide our work:

  • Strategy. We work with product and feature teams to determine what we want to achieve with AI. They define business goals and prioritize the most important implementations and investments.
  • Architecture. We enable infrastructure, data, services, security, privacy, scalability, accessibility, and interoperability for all our AI use cases.
  • Roadmap. We build and manage implementation plans for all our AI projects, including tools, technologies, responsibilities, targets, and performance measurement.
  • Culture. We foster collaboration, innovation, education, and responsible AI among our stakeholders.

These pillars are the common language that helps us connect strategy to execution and make decisions across all teams and scenarios at Microsoft Digital.

Strategy

Our CoE strategy team’s role is to step back and create clarity.

Our strategy is driven from the organization’s top level, and executive sponsorship is crucial to executing our implementation well. When our transformation mandate comes from the organization’s leader, it resonates in every corner of the organization, every piece of work, and every task. We also encourage and welcome ideas from every level of the organization, empowering individuals to contribute their AI insights.

We maintain a centralized view of AI initiatives across Microsoft Digital, including agents, workflows, and AI‑enabled solutions. That visibility allows our CoE team to identify duplication, surface opportunities to scale successful ideas, and align investments to enterprise priorities. This creates a shared intake and prioritization model.

One of our CoE strategy team’s most significant responsibilities is prioritizing the idea pipeline for AI solutions. All employees can feed ideas into the pipeline through a form that records important details. The strategy team then evaluates each idea, analyzing two primary metrics:

  • Business value. How important is the solution to our business? Potential cost reduction, market opportunity, and user impact all factor into business value. As our business value increases, so does the idea’s position in the pipeline priority queue.
  • Implementation effort. We focus on clearly defining the problem statement—what the problem is, why it matters, who the customer is, the baseline metrics, and the plan to attribute value pre‑production. This ensures we prioritize AI for the most critical business problems and can measure impact before and after deployment.

By anchoring AI work in business outcomes from the start, the strategy pillar helps ensure the organization’s energy is spent on the work that matters most.

Architecture

Our architecture pillar defines how we help teams scale AI solutions without creating security gaps, compliance issues, or technical debt they’ll have to unwind later.

“The CoE introduces a framework to enable design reviews in the early development phase. We help make sure teams are choosing the right platforms and thinking about security and compliance from the beginning.”

Qingsu Wu, principal group product manager, Microsoft Digital

Before solutions move into broader use, our architecture team helps think through data readiness, platform alignment, and governance requirements. The goal isn’t to prescribe a single architecture, but to make sure foundational decisions won’t limit scale or create risk down the line. Many times, this means doing things before development, while other times it means making improvements after the initial development is done and the product or scenario is launched and being used. We also track our efforts with measurable metrics like usage.

One common pitfall is that teams may gravitate toward the most flexible platforms with full control, without fully understanding the associated security and compliance implications. To address this, we publish clear guidance to help teams choose the right platform—one that strikes the appropriate balance between flexibility and the security and compliance effort required.

Our architecture pillar helps prevent that by reinforcing a set of common expectations. Teams still build locally and move fast, but they do so within a framework that supports reuse, interoperability, and responsible operation built on enabling teams and employees to experiment with guardrails that keep our production systems safe.

“The CoE introduces a framework to enable design reviews in the early development phase,” Wu says. “We help make sure teams are choosing the right platforms and thinking about security and compliance from the beginning.”

Teams are encouraged to build on recommended platforms and services that support enterprise‑grade security, observability, and lifecycle management. This helps ensure solutions can be monitored, governed, and supported over time.

Security and compliance are never treated as downstream checkpoints. Architectural guidance reinforces the need to design with identity, access controls, auditability, and responsible AI principles from the start.

When solutions prove valuable, we look for opportunities to reuse architectural patterns, components, or services rather than rebuilding them in isolation. This reduces duplication and accelerates future work.

Roadmap

Our CoE roadmap team examines our employee experience in the context of our AI solutions and governs how we achieve the optimal experience in and throughout AI projects. It focuses on how our employees will interact with AI. Getting the roadmap right ensures user experiences are cohesive and align with our broader employee experience goals.

We’ve recognized AI’s potential to impact how our employees get their work done.

Their experiences and satisfaction levels with AI services and tools are critical. Our roadmap pillar is designed to encourage experiences across all these services and tools that are complementary and cohesive.

We’re focusing on the open nature of AI interaction.

“We’re surfacing AI capabilities and information when the user needs them, according to their context,” Campbell says. “It makes the user experience and user interface for an AI service less important than how the service allows other applications or user interfaces to interact with it and harness its power.”

A key part of this approach is disciplined experimentation.

Rather than treating every idea as a long‑term commitment, the roadmap pillar helps teams validate value early. Our teams know when they’re in an experimental phase and when they’re expected to operationalize. This gives our leaders a more consistent view of progress and risk. The net result is that dependencies between teams surface earlier, when they’re easier to resolve.

Culture

Our culture pillar ensures that AI adoption across Microsoft Digital is intentional, responsible, and sustainable.

Culture underpins everything we do in the AI space. Ensuring our employees can increase their AI skillsets and access guidance for using AI responsibly are critical to AI at Microsoft.

“We’re driving a shift from ad‑hoc AI usage to intentional, outcome‑driven adoption,” Khetan says. “That requires clarity, education, and shared expectations.”

In practice, that means the culture pillar defines how our teams are expected to adopt AI and integrate it into their work, not just what tools they can use.

Our culture team works with AI champions across the organization to translate enterprise AI priorities into local execution. Those champions act as two‑way conduits, bringing real‑world feedback and blockers back to the CoE and carrying guidance, standards, and learnings back to their teams.

Without this structure, AI adoption tends to fragment as teams experiment in isolation.

Our culture team has published training, recommended practices, and our shared learnings on next-generation AI capabilities. We work with individual business groups at Microsoft to determine the needs of all the disciplines across the organization. That work extends to groups as diverse as engineering, facilities and real estate, human resources, legal, sales, and marketing, among others. 

Responsible AI is embedded throughout that work.

The CoE reinforces responsible AI practices as part of everyday decision‑making—during design, experimentation, and scale. Teams are expected to understand not just what they’re building, but the implications of how they build it.

In the AI CoE, culture isn’t abstract. It shows up in how teams propose ideas, how they design solutions and how they measure success.

Fostering agent innovation

The true value of the AI CoE is evident when strategy, architecture, roadmap, and culture come together around real work.

A clear example of that is how we addressed the rapid growth of AI agents across the organization.

A photo of Tiwari.

“That’s the core problem we’re trying to solve. In the past, admins had to go to multiple portals just to understand how many agents exist, and they all give different answers.”

Garima Tiwari, principal product manager, Microsoft Digital

Our teams were building agents in different platforms, for different scenarios, and at very different levels of maturity. That flexibility accelerated innovation, but it also made it difficult to answer basic questions.

  • How many agents exist today?
  • Which ones are in production?
  • Which ones touch sensitive data?

The strategy lens helped clarify what mattered most. Our goal wasn’t to inventory every experiment. It was to gain visibility into agents that were active, scaling, or depended on by others, and to ensure those agents aligned to business priorities and Responsible AI expectations.

Architecture quickly followed.

As the CoE looked at how agents were built, we quickly discovered that information about agents was fragmented across tools. Different platforms showed different numbers. Ownership wasn’t always clear. And governance signals were hard to reconcile.

“That’s the core problem we’re trying to solve,” says Garima Tiwari, a principal product manager in Microsoft Digital leading our internal strategy and adoption of Agent 365. “In the past, admins had to go to multiple portals just to understand how many agents exist, and they all give different answers.”

This is where Agent 365—which we use to govern agents here at Microsoft—became a critical enabler.

Agent 365 brings together signals from multiple agent‑building platforms into a single, consolidated view. That visibility allows the CoE and administrators to understand agent inventory, ownership, lifecycle state, and governance posture in one place.

“Agent 365 is really about accurate inventory and observability,” Garima says. “It provides one number we can trust and a way to see how agents are behaving, who they’re interacting with, and whether they’re compliant.”

That architectural clarity changed how decisions were made.

Instead of guessing what was safe to scale, the CoE could see which agents were production‑ready, which needed remediation, and which should remain in experimentation. Security, privacy, and compliance considerations moved to earlier in the lifecycle.

“We can’t scale what we don’t understand,” Wu says. “Agent 365 helps us see what’s actually running so we’re not scaling something blindly.”

The roadmap lens then brought structure to execution.

“What changed was the mindset. Teams started thinking about manageability, security, and scale much earlier, not after an agent was already deployed.”

Don Campbell, principal group technical program manager, Microsoft Digital

Rather than standardizing everything at once, the CoE helped teams sequence work. Some agents stayed in pilot. Others moved toward broader rollout, informed by architectural and governance signals surfaced through Agent 365.

Culture and enablement ran alongside that work.

Teams began factoring operational readiness into design decisions instead of treating governance as a final checkpoint. Agent 365 isn’t positioned as a control tool at the end of the process, but as part of building agents the right way from the start.

“What changed was the mindset,” Campbell says. “Teams started thinking about manageability, security, and scale much earlier, not after an agent was already deployed.”

The outcome wasn’t a single standardized solution.

It was a repeatable approach within a shared CoE framework, supported by platforms like Agent 365, that made scaling AI more visible, more manageable, and more intentional.

That’s what the AI CoE enables at Microsoft Digital.

Key takeaways

If you’re just starting to consider AI usage at your organization, or if you’re already creating a standardized approach to AI, consider the following:

  • Start with outcomes, not tools. AI work scales faster when teams align on the business problem first and select technology second.
  • Design for scale from day one. Early architectural decisions around data, security, and platforms determine whether solutions can grow—or need to be rebuilt.
  • Make experimentation disciplined. Clear paths from prototype to production help teams move fast without committing to ideas that haven’t proven value.
  • Treat governance as an enabler, not a gate. Visibility and manageability, supported by platforms like Agent 365, make it easier to scale AI responsibly.
  • Create shared accountability. Standard metrics and automated reporting turn AI activity into measurable progress.

The post Powering the technical veracity of AI at Microsoft with a Center of Excellence appeared first on Inside Track.

]]>
23147
Conditioning our unstructured data for AI at Microsoft http://approjects.co.za/?big=insidetrack/blog/conditioning-our-unstructured-data-for-ai-at-microsoft/ Thu, 09 Apr 2026 16:05:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=23020 Anyone who has ever stumbled across an old SharePoint site or outdated shared folder at work knows firsthand how quickly documentation can fall out of date and become inaccurate. Humans can usually spot the signs of outdated information and exclude it when answering a question or addressing a work topic. But what happens when there’s […]

The post Conditioning our unstructured data for AI at Microsoft appeared first on Inside Track.

]]>
Anyone who has ever stumbled across an old SharePoint site or outdated shared folder at work knows firsthand how quickly documentation can fall out of date and become inaccurate.

Humans can usually spot the signs of outdated information and exclude it when answering a question or addressing a work topic. But what happens when there’s no human in the loop?

At Microsoft, we’ve embraced the power and speed of agentic solutions across the enterprise. This means we’re at the forefront of developing and implementing innovative tools like the Employee Self-Service Agent, a chat-based solution that uses AI to address thousands of IT support issues and human resources (HR) queries every month—queries that used to be handled by humans. Early results from the tool show great promise for increased efficiency and time savings.

In developing tools like this agent, we were confronted with a challenge: How do we make sure all the unstructured data the tool was trained on is relevant and reliable?

Many organizations are facing this daunting task in the age of AI. Unlike structured data, which is well organized and more easily ingested by AI tools, the sprawling and unverified nature of unstructured data poses some tricky problems for agentic tool development. Tackling this challenge is often referred to as data conditioning.

Read on to see how we at Microsoft Digital—the company’s IT organization—are handling data conditioning across the company, and how you can follow our lead in your own organization.

How AI has changed the game

We already fundamentally understand that the power of AI and large language models has changed the game for many work tasks. The way employee support functions is no exception to this sweeping change.

A photo of Finney.

“A tool like the Employee Self-Service Agent doesn’t know if something is true or false—it only sees information it can use and present. That’s why stale or outdated information is such a risk, unless you manage it up front.”

David Finney, director of IT Service Management, Microsoft Digital

Instead of relying on human agents to answer employee questions or resolve issues, we now have AI agents trained on vast corpora of data that can find the answer to a complex question in seconds.

But in our drive to give these tools access to everything they might need, they sometimes end up consuming information that isn’t helpful.

“A tool like the Employee Self-Service Agent doesn’t know if something is true or false—it only sees information it can use and present,” says David Finney, director of IT Service Management. “That’s why stale or outdated information is such a risk, unless you manage it up front.”

Before AI, support teams didn’t need to worry as much about the buried issues with unstructured content because a human could generally spot it or filter it out manually. After we turned these tools loose, they began reading everything, including:

  • Older or hidden SharePoint content that humans would never find—but AI can
  • Large knowledge base articles with buried incorrect information
  • Region-specific content that’s not properly labeled

“For example, humans never saw the old, decommissioned SharePoint sites because they were automatically redirected,” says Kevin Verdeck, a senior IT service operations engineer. “But AI definitely could find them, and it surfaced ancient information that we didn’t even know was still out there.”

Data governance is the key

A major part of the solution to this problem is better governance. We had to get a handle on our data.

A photo of Cherel.

“We needed to determine the owners of the sites and then establish processes for reviewing content, updating it, and defining how it should be structured. I would highly encourage that our customers think about governance first when they are launching their own AI tools, because everything flows from it.”

Olivier Cherel, senior business process manager, Microsoft Digital

The first step was a massive cleanup effort, including removing decommissioned SharePoint sites and deleting references to retired programs and policies. The next step was making sure all content had ownership assigned to establish who would be maintaining it. This was followed by setting up schedules for regular content updates (lifecycle management).

Governance was the first priority for IT content, according to Olivier Cherel, a senior business process manager in Microsoft Digital.

“We had no governance in place for all the SharePoint sites, which were managed by the various IT teams,” Cherel says. “We needed to determine the owners of the sites and then establish processes for reviewing content, updating it, and defining how it should be structured. I would highly encourage that our customers think about governance first when they are launching their own AI tools, because everything flows from it.”

Content governance was also a huge challenge for other support areas, such as human resources. A coordinated approach was needed.

“HR content is vast, distributed across multiple SharePoint sites, and not everything has a clear owner,” says Shipra Gupta, an engineering PM lead in Human Resources who worked on the Employee Self-Service Agent project. “So, we collaborated with our content and People Operations teams to create a true content strategy: one source of truth, no duplication, with clear ownership and lifecycle management.”

Cherel observes that this process forces teams to think about their support content in a totally different way.

“People realize they need a new function on their team: content management,” he says. “You can’t simply rely on the knowledge found in the technicians’ heads anymore.”

Adding structure to the unstructured data

The simple truth is that part of what makes unstructured data so difficult for agentic AI tools to deal with is that it’s disorganized.

A photo of Gupta.

“Our HR Web content already had tagging for many policy documents, which helped us get started. But it wasn’t consistent across all content, so improved tagging became a big part of our governance effort.”

Shipra Gupta, engineering PM lead, Human Resources

AI works best with content that has as many of the following characteristics as possible:

  • Document structure, including:
    • Clear headers and sections
    • Page-level summaries
    • Ordered steps and lists
    • Explicit labels for processes
    • HTML tags (which AI can see, but humans can’t)
  • Structured metadata, including:
    • Region codes (e.g., US-only policies)
    • Device-specific tags
    • Secure device classification
    • Country-based hardware procurement policies and HR rules

This kind of formatting and metadata allows the AI tool to more clearly parse and sort the information, meaning its answers are going to have a much higher accuracy level (even if it might be a little slower to return them).

“A good example here is tagging,” Gupta says. “Our HR Web content already had tagging for many policy documents, which helped us get started. But it wasn’t consistent across all content, so improved tagging became a big part of our governance effort.”

Be sure that as part of your content review, you’re setting aside the time and resources to add this kind of structure to your unstructured data. The investment will pay off in the long run.

Using AI to help condition data for use

As AI tools grow more sophisticated, we’re using them to directly work on AI-related challenges. This includes using AI on the challenge of unstructured data itself.

“Right now, these efforts are primarily human-led, but we are applying AI to, for example, help write knowledge base articles,” Cherel says. “Also, we’re starting to use AI to determine where we have content gaps, and to analyze the feedback we’re getting on the tool itself. If we just rely on humans, it’s not going to scale. We need to leverage AI to stay on top of things and keep improving the tools.”

Essentially, the future of such technology is all about using AI to improve itself.

“We’re looking at building an agent to help validate content,” Finney says. “We can use it to check for outdated references, old processes, or abandoned terms that are no longer used. Essentially, we’ll have AI do a readiness check on the content that it is consuming.”

Ultimately, the better the data is conditioned, the more accurate and relevant the agent’s responses will be. And that will make the end user—the truly important human in the loop—much happier with the final outcome.

Key takeaways

We’ve highlighted some insights to keep in mind as you consider how to condition your own organization’s data for ingestion by AI tools:

  • Unstructured data becomes a business risk when AI is in the loop. AI agents consume everything they can access, including outdated, hidden, or conflicting content, making data conditioning a critical prerequisite for agentic solutions.
  • AI highlights content issues that were previously invisible. Decommissioned SharePoint sites, outdated policies, and region-specific content without proper labels all became visible after AI agents began scanning across systems.
  • Governance is a vital part of the conditioning process. Assigning clear content ownership and establishing lifecycle management are essential steps in ensuring the content being fed to AI tools is of high quality and is well managed.
  • Adding structure to data dramatically improves AI accuracy. Clear document formatting, consistent tagging, and rich metadata help AI agents return more relevant, reliable answers.
  • AI will increasingly be used to condition and validate the data it consumes. Microsoft is already exploring using AI to identify content gaps, analyze feedback, and flag outdated information, creating a continuous improvement loop that can scale faster than human review alone.

The post Conditioning our unstructured data for AI at Microsoft appeared first on Inside Track.

]]>
23020
Harnessing AI: How a data council is powering our unified data strategy at Microsoft http://approjects.co.za/?big=insidetrack/blog/harnessing-ai-how-a-data-council-is-powering-our-unified-data-strategy-at-microsoft/ Thu, 09 Apr 2026 16:00:00 +0000 http://approjects.co.za/?big=insidetrack/blog/?p=23030 Information technology is an ever-evolving landscape. Artificial Intelligence is accelerating that evolution, providing employees with unprecedented access to information and insights. Data-driven decision making has never been more critical for businesses to achieve their goals. In light of this priority, we have established a data council to help accelerate our companywide AI-powered transformation. Our data […]

The post Harnessing AI: How a data council is powering our unified data strategy at Microsoft appeared first on Inside Track.

]]>
Information technology is an ever-evolving landscape. Artificial Intelligence is accelerating that evolution, providing employees with unprecedented access to information and insights. Data-driven decision making has never been more critical for businesses to achieve their goals.

In light of this priority, we have established a data council to help accelerate our companywide AI-powered transformation.

Our data council is a cross-functional team with representation from multiple domains within Microsoft, including Microsoft Digital, the company’s IT organization; Corporate, External, and Legal Affairs (CELA); and Finance.

A photo of Tripathi.

“By championing robust data governance, literacy, and responsible data practices, our data council is a crucial part of our AI-powered transformation. It turns enterprise data into a strategic capability that fuels predictive insights and intelligent outcomes across the organization.”

Naval Tripathi, principal engineering manager, Microsoft Digital

Our data council’s mission is to drive transformative business impact by establishing a cohesive data strategy across Microsoft Digital, empowering interconnected analytics and AI at scale. Our vision is to guide our organization toward Frontier Firm maturity through a clear blueprint for high-quality, reliable, AI-ready data delivered on trusted, scalable platforms.

“By championing robust data governance, literacy, and responsible data practices, our data council is a crucial part of our AI-powered transformation,” says Naval Tripathi, principal engineering manager in Microsoft Digital. “It turns enterprise data into a strategic capability that fuels predictive insights and intelligent outcomes across the organization.”

Our evolving data strategy

Over the past two decades, we at Microsoft—along with other large enterprises—have continuously evolved our data strategies in search of the right balance between control and agility. Early approaches were highly decentralized, with different teams owning and managing their own data assets. While this enabled local optimization, it also resulted in inconsistent quality and limited enterprise-wide insight.

Our subsequent shift toward centralized data platforms brought much-needed standardization, security, and scalability. However, as data platforms grew more sophisticated, ownership often drifted away from the business domains closest to the data, slowing responsiveness and diluting accountability.

Today, we and other leading companies are embracing a more balanced, federated approach, often described as a data mesh. Rather than forcing all our data into a single centralized system or allowing unchecked decentralization, the data mesh formalizes domain ownership while embedding governance, quality, and interoperability directly into shared platforms.

With this approach, our domain teams publish data as well-defined, discoverable products, while common standards for security, metadata, and compliance are enforced through automation rather than manual processes. This model preserves enterprise trust and consistency without sacrificing speed or autonomy.

By adopting a data mesh mindset, we can scale analytics and AI more effectively across the organization while still keeping ownership closely connected to the business focus. The result is a system that supports innovation at the edges, strong governance at the core, and seamless collaboration across domains, enabling the transformation of data from a technical asset to a strategic, enterprise-wide capability.

Quality, accessibility, and governance

To scale enterprise data and AI, organizations must first ensure their data is trusted, discoverable, and responsibly governed. At Microsoft Digital, our data strategy is designed to create data foundations that power intelligent applications and effective decision making across the company.

A photo of Uribe.

“High-quality, well-governed data is essential to accelerate implementation and adoption of AI tools. Data quality, accessibility, and governance are imperatives for AI systems to function effectively, and recognizing that is propelling our data strategy.”

Miguel Uribe, principal PM manager, Microsoft Digital

By implementing a data mesh strategy at scale, we aim to unlock valuable data insights and analytics, enabling advanced AI scenarios. Our data council focuses on three core dimensions that make AI-ready data possible:

  • Quality: Making sure enterprise data is reliable and complete
  • Accessibility: Enabling secure and discoverable access to data
  • Governance: Protecting and managing our data responsibly

Together, these dimensions form the foundation for scalable innovation and AI-powered data use. They connect data silos and ensure consistent, high‑quality access across the enterprise—enabling both humans and AI systems to work from the same trusted data foundation. As AI use cases mature, this foundation allows AI agents to retrieve and reason over data through enterprise endpoints, while supporting advanced analytics, data science, and broader technology.

“High-quality, well-governed data is essential to accelerate implementation and adoption of AI tools,” says Miguel Uribe, a principal PM manager in Microsoft Digital. “Data quality, accessibility, and governance are imperatives for AI systems to function effectively, and recognizing that is propelling our data strategy.”

Quality

AI-ready data is available, complete, accurate, and high-quality. By adopting this standard, our data scientists, engineers, and even our AI agents are better able to locate, process, and govern the information needed to drive our organization and maximize AI efficiencies.

By utilizing Microsoft Purview, our data council can oversee the monitoring of data attributes to ensure fidelity. It also monitors parameters to enforce standards for accuracy and completeness.

Accessibility

Ensuring that our employees get access to the information they need while prioritizing security is a foundational element of our enterprise data strategy. Microsoft Fabric allows us to unify our organization’s siloed data in a single “mesh” that enables advanced analytics, data science, data visualization and other connected scenarios.

Microsoft Purview then gives us the ability to democratize that data responsibly. By implementing a data mesh architecture, our employees can work confidently, unencumbered by siloed or inaccessible data, and with the assurance that the data they’re working with is secure.

A graphic shows how the data mesh architecture allows employees to access data they need, with platform services and data management zones surrounding this architecture.
The data mesh architecture enables our employees to do their work efficiently while preventing the data they’re working on from becoming siloed.

The data mesh connects and distributes data products across domains, enabling shared data access and compute while scaling beyond centralized architectures.

Platform services are standardized blueprints that embed security, interoperability, policies, standards, and core capabilities—providing guardrails that enable speed without fragmentation.

Data management zones provide centralized governance capabilities for policy enforcement, lineage, observability, compliance, and enterprise-wide trust.  

Governance

As organizations scale AI capabilities, strong governance becomes essential to ensure security, compliance, and ethical data use. Data governance—which includes establishing data policies, ensuring data privacy and security, and promoting ethical AI usage—is critical, as is compliance with General Data Protection Regulation (GDPR) and Consumer Data Protection Act (CDPA) regulations, among others.

However, governance is not only a technical capability; it’s also a cultural commitment.

Responsible data use must be embedded into the way teams manage data and build AI solutions. Through Microsoft Purview, we implemented an end-to-end governance framework that automates the discovery, classification, and protection of sensitive data across the enterprise data landscape.

This unified approach allows teams to innovate confidently, knowing that the data powering their insights and AI systems is trusted and protected, as well as responsibly managed.

“AI systems are only as reliable as the data that powers them,” Uribe says. “By investing in trusted and well-managed data, we accelerate not only the adoption of AI tools but our ability to generate meaningful insights and intelligent outcomes.”

The data catalog as the discovery layer

By serving as a common discovery layer for humans and AI, the data catalog ensures that governance translates directly into speed, accuracy, and trust at scale.

A unified data strategy only succeeds if both people and AI systems can consistently find the right data. At Microsoft, this is enabled by our enterprise data catalog, which operationalizes the standards set by our data council. 

For business users, the catalog provides intuitive search, ownership transparency, and trust signals—enabling confident self‑service analytics. For AI agents, the same catalog exposes machine‑readable metadata, allowing agents to programmatically discover canonical datasets, validate schema and freshness, and respect governance constraints.

Our role as Customer Zero

In Microsoft Digital, we operate as Customer Zero for the company’s enterprise solutions, so that our customers don’t have to.

That means we do more than adopt new products early. We deploy them at enterprise-scale, operate them under real‑world constraints, and hold them to the same standards our customers expect. The result is more resilient, ready‑to‑use solutions and a higher quality bar for every enterprise customer we serve.

A photo of Baccino.

“When we engage product teams with real telemetry from how data is created, governed, and consumed at scale, we move the conversation from theory to execution. That’s how enterprise readiness becomes real.”

Diego Baccino, principal software engineering manager, Microsoft Digital

Our data council embodies this Customer Zero mindset through its Enterprise Readiness initiative. By engaging product engineering as a unified enterprise voice, the council drives strategic conversations that surface operational blockers, influence roadmap prioritization, and ensure new and existing data solutions are truly ready for enterprise use.

These learnings are then shared broadly across Microsoft Digital to accelerate adoption, reduce duplication, and scale proven patterns across teams.

“When we engage product teams with real telemetry from how data is created, governed, and consumed at scale, we move the conversation from theory to execution,” says Diego Baccino, a principal software engineering manager in Microsoft Digital and a member of the council. “That’s how enterprise readiness becomes real.”

This work is deeply integrated with our AI Center of Excellence (CoE), where Customer Zero principles are applied to accelerate AI outcomes responsibly. Together, the AI CoE and the data council focus on improving data documentation and quality—foundational capabilities that are required to make AI feasible, trustworthy, and scalable across the enterprise.

By grounding AI innovation in measurable data quality and governance standards, Microsoft Digital ensures that experimentation can safely mature into production‑ready solutions. The partnership between our data council, our AI CoE, and our Responsible AI (RAI) Council is essential to our broader data and AI strategy.

“AI readiness isn’t aspirational—it’s operational,” Baccino says. “By measuring the health of our data, setting clear quality baselines, and using those signals to guide product and platform decisions, we turn data into a strategic asset and AI into a repeatable capability.”

Together, these teams exemplify what it means to be Customer Zero: Transforming enterprise experience into action, governance into acceleration, and data into durable competitive advantage.

Advancing our data culture

Our data council plays a pivotal role in advancing the organization transition from data literacy to enterprise data and AI capability. In conjunction with our AI CoE, it creates curricula and sponsors learning pathways, operational practices, and community programs to equip our employees with the skills and mindset required to thrive in a data- and AI-centric world.

While early efforts focused on improving data literacy, our data council ’s mission has evolved to enable data and AI capability at scale together with our AI CoE—where employees not only understand data but can effectively apply it to build, operate, and govern intelligent solutions.

“Our focus is not just teaching our teams about data. It is enabling employees to apply data to create AI-driven outcomes. When teams understand how data powers AI systems, they can make better decisions, design better products, and build more responsible AI experiences.”

Miguel Uribe, principal product manager, Microsoft Digital

Our curriculum includes high-level courses on data concepts, applications, and extensibility of AI tools like Microsoft 365 Copilot, as well as data products like Microsoft Purview and Microsoft Fabric.

By facilitating AI and data training, offering internally focused data and AI certifications, and internal community engagement, our council ensures that employees develop the capabilities required to responsibly build and operate AI-powered solutions. Achieving data and AI certifications not only promotes career development through improved data literacy, it also enhances the broader data-driven culture within our organization.

“We recognize that AI capability is built when data skills are applied directly to real AI scenarios and business outcomes—not when learning exists in isolation,” Uribe says. “Our focus is not just teaching our teams about data; it is enabling employees to apply data to create AI‑driven outcomes. When teams understand how data powers AI systems, they can make better decisions, design better products, and build more responsible AI experiences.”

Lessons learned

Our data council was created to develop and execute a cohesive data strategy across Microsoft Digital and to foster a strong data culture within our organization. Over time, several critical lessons have emerged.

Executive sponsorship enables transformation

Executive sponsorship is a key element to ensure implementation and adoption of a data strategy. Our leaders are committed to delivering and sustaining a robust data strategy and culture and have been effective champions of the council’s work.

“Leadership provides support and reinforcement of the council’s mission, as well as guidance and clarity related to diverse organizational priorities,” Baccino says.

Cross-functional collaboration accelerates impact

Our council’s work has also benefited from the diverse representation offered by different disciplines across our organization. Embracing diverse perspectives and understanding various organizational priorities is critical to implementing a successful data strategy and culture in a large and complex organization like Microsoft Digital.

Modern platforms allow for scalable AI productivity

Technology and architecture also play a critical role in enabling enterprise data and AI capability. Platforms like Microsoft Purview and Microsoft Fabric provide the governance, discovery, and analytics infrastructure required to create trusted, AI-ready data ecosystems.

Combined with strong leadership support and community engagement, these platforms allow our organization to move beyond isolated data projects toward connected, enterprise-wide intelligence.

As our organization continues to evolve, our data council’s strategic work and valuable insights will be crucial in shaping the future of data-driven decision making and AI transformation at Microsoft.

Key takeaways

Here are some things to keep in mind as you contemplate forming a data council to help you manage and scale AI impacts responsibly at your own organization:

  • A data mesh strikes the balance enterprises have been chasing. By formalizing domain ownership while enforcing standards through shared platforms, you avoid both chaotic decentralization and slow, over-centralized control.
  • Governance is an accelerator when it’s automated and embedded. Using platforms like Microsoft Purview and Microsoft Fabric, governance shifts from a manual gatekeeping function to a built‑in capability that enables faster, trusted analytics and AI.
  • AI systems are only as strong as their discovery layer. A unified enterprise data catalog allows both people and AI agents to find, trust, and use data consistently—turning standards into operational speed.
  • Customer Zero turns theory into enterprise‑ready execution. By operating its own data and AI platforms at scale, Microsoft Digital provides real telemetry and practical feedback that directly shapes product readiness.
  • Building AI capability is a cultural effort, not just a technical one. Our data council’s focus on applied learning, certification, and real-world AI scenarios ensures data skills translate into durable business outcomes.
  • AI scale exposes the cost of fragmented data ownership. A data council cuts through silos by aligning priorities, resolving tradeoffs, and concentrating investment on the data assets that matter most for AI impact.
  • Shared metrics create shared ownership. Publishing data quality and AI‑readiness scores at the leadership level reinforces accountability and positions data as a core enterprise asset.

The post Harnessing AI: How a data council is powering our unified data strategy at Microsoft appeared first on Inside Track.

]]>
23030