Microsoft AI Center of Excellence - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work stakes the AI problem teams can't see yet. Copilot pilots are spreading through M365 Power Platform and Azure faster than most organizations can map them. One team uses copilot to prepare meetings, another builds a low code agent somewhere else. A developer connects an Azure AI app to business data. Because the demo worked and the pressure to move feels real. The problem isn't the AI tool, it's the operating model around it. Leaders often can't answer a few basic questions who owns this agent? What data can it reach? Which problem does it solve? What happens when the person who built it changes roles? Meanwhile, duplicate builds appear. Permissions stay wider than they need to be, and trust starts to slip before the organization even sees a return.

0:44 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. We're going to turn scattered AI experiments into controlled, useful work. First, we need to define the team that makes that possible. What an AI Center of Excellence actually is an AI center of excellence, often called an AI, Coe is a cross-functional team and a repeatable way of working. It helps your organization choose AI use cases, build them safely, protect the data around them, and scale the work when it proves useful. Think of it as a shared service for AI decisions. It gives people a clear place to bring an idea. Test whether it solves a real problem, choose the right Microsoft platform and learn from work that other teams already completed.

1:24 That doesn't mean a room full of AI experts controls every prompt. Nobody needs a committee meeting before they ask copilot to rewrite an email. A Coe focuses on AI that touches business processes, shared data, customer information, or systems where a bad answer could create a real problem. Picture a familiar situation. Marketing builds a copilot that helps create campaign briefs. Finance builds a separate tool to explain budget changes. HR starts testing an assistant that helps staff find policy answers. Each team has a good reason for doing it. Each team wants to remove slow, repetitive work. Then the friction starts. Marketing pays for one set of tools, finance pays for another. HR connects to a different data source and follows a different rule. Nobody has one record showing which AI tools exist.

2:05 What they can access or who owns the result. The work doesn't fail because people lack good ideas. It becomes hard to support, hard to secure, and hard to repeat. An AI code creates the bridge between business teams, IT security, data, legal and the people helping employees change how they work. Business teams bring the problem. Technical teams bring the platform knowledge, security and legal teams help set safe boundaries. Change leaders help people use the new process without guessing what they're allowed to do. You might think the central group takes control away from departments, but it does the opposite. When it works well. The Co handles the shared work that every department would otherwise repeat. While the department keeps ownership of its own business problem and outcome. Air traffic control is a useful comparison.

2:46 Controllers don't fly every plane. They set routes, check conditions, keep people aware of what's moving, and stop collisions before they happen. Your Co doesn't need to build every AI solution either. It sets the routes that let many teams build with less waste and fewer surprises. It's day to day work usually starts with use case intake. Someone explains the problem, who faces it, and what a better outcome would look like. The Co helps assess risk, choose a platform and reuse patterns that already work. It can also provide training, shared guidance and a way to measure whether the use case actually helped. In Microsoft terms, that may mean using Microsoft three hundred sixty five copilot for daily work across documents, meetings, email, and teams. It may mean power platform when a business team needs a low code app flow or agent.

3:26 It may mean Azure AI foundry when developers need a more custom AI application with deeper control over models, data testing and monitoring, the platform changes with the job. The operating model stays consistent early on. A small central team may handle most AI work because the organization still needs shared knowledge and clear direction. As demand grows, many organizations move to a hub and spoke model. The Co becomes the hub for standards and support, while trained people in business areas become the spokes that bring local needs and build local solutions, mature organizations may give more freedom to local teams, but shared controls still connect the work. So the Co owns the rules, shared services and learning loop. The business team owns the problem it wants to solve.

4:06 Once that job becomes clear, we can see why informal AI work starts to break down. Why organizations need one before AI spreads further. One co-pilot pilot can stay simple. A team tries it, learns where it saves time and decides whether to continue. But when ten departments each build tools, agents and flows without a shared path, the organization doesn't have an AI program. It has a growing pile of unknowns. That pile gets expensive fast. People solve the same problem twice because they can't find work another team already built. Someone chooses a tool that doesn't fit the data rules. Security finds out about an agent only when it needs access to a sensitive system. Leaders hear that AI is everywhere, yet nobody can show what work improved, what it cost, or whether people trust the output.

4:46 Shadow AI grows in that gap. It isn't always someone trying to avoid the rules. Often it's a busy employee trying to fix a real problem before the next deadline. Imagine an employee builds an agent to help the service team prepare customer updates. They connect it to SharePoint for product documents, outlook for past messages, and a business system for case details. At first, it helps the team, saves time and starts relying on it. Then that employee moves to another role. Nobody knows whether the agent still runs, which connections it uses or who should approve a change. A document library gains new files, a system permission changes. The agent may still work, but nobody can explain its boundaries. That isn't a small admin issue. It's an ownership problem that grows quietly. A wrong AI answer can confuse a person. An AI action can change a record, send information outside the company, or trigger a workflow that reaches hundreds of people.

5:30 Agents shift the risk because they can search across connected systems, reason over what they find, and take the next step through a tool or flow that brings three groups into the same tension. Builders want enough freedom to solve problems while the need is fresh. Security teams need to know what connects to company data and what access it receives. Leaders need proof that time, money, and employee effort are producing a business result without a shared process, each group pulls in a different direction. Builders work around controls security adds late reviews. Leaders approve more licenses and hope use turns into value. A Co gives them a common path instead of a permanent approval queue. Low risk ideas can move quickly through a light review. Higher risk work receives more attention before it reaches people or systems.

6:12 The goal isn't to treat every use case like a major software release. The goal is to match the review to the risk. Start with discovery. List the co-pilots agents, power automate flows and AI apps already in use for each one. Record the data source, the owner, the users, and what the tool can do. You may find a few approved experiments, some useful work nobody told Itay about, and several items with no clear owner that inventory changes the conversation. You stop arguing about AI in general and start looking at real work. Next, rank the ideas. Ask what business outcome the use case targets, how sensitive the data is, how many people it affects, how much effort it needs, and what could go wrong. A meeting summary assistant and an agent that changes finance records don't belong in the same review lane. Measure from the first release track time saved fewer errors.

6:54 Repeat use user confidence running cost and incidence avoided. If a tool doesn't improve the work, the CEO needs the confidence to stop it, not keep it alive because someone built it. But a policy document can't run this process on its own. The Co needs three working pillars that people can use every day. Governance sets the rules of the road. Pillar one governance decisions, guardrails and proof. Governance means deciding who can build what, which data they can use, which rules apply, and who answers when the AI produces a bad result. It sounds formal, but it solves a very practical problem. People need to know where their freedom starts and where their responsibility starts. You might think governance means every AI idea moves through a slow approval process, but a good governance model does the reverse.

7:36 It gives low risk work a fast path, while work that could affect people, money, regulated data or business systems gets a deeper review. Take a simple drafting assistant. It helps the team turn rough notes into a first draft, and a person checks the result before sharing it. That usually belongs in a lighter review lane. Compare that with an agent that helps rank job candidates, recommends financial action. Read sensitive health data, or updates records on its own. That work needs more questions before anyone releases it. The first control is a simple intake form, not a forty page document, just enough information to understand the work. What problem are we trying to solve? Who will use it? What results should improve? Which data does it need? Can it only answer questions or can it take actions? And who is the named business owner? That last question matters more than most teams expect.

8:18 A builder may create the solution, but the business owner accepts responsibility for whether it solves the right problem and whether people use it properly. If nobody owns the outcome, nobody feels the pain when it quietly stops helping. From there, the Co can sort the use case by risk drafting. Summarizing and brainstorming usually sit at the lower end when people review the output and sensitive data stays out of the prompt. Hiring decisions, credit decisions, regulated records, and agents with the power to act sit much higher. The more impact the AI has on a person or a system, the more proof you need before release Rolls need to stay clear. Executives set direction and approve funding. The Coe sets standards and keeps the process moving. The business owner owns the outcome. Security and legal teams review risk where needed.

8:59 Builders create, test and maintain the solution when these roles blur review stalled because everyone assumes someone else will decide. Microsoft's responsible AI principles give this work a common baseline. Fairness asks whether people receive unequal treatment, reliability and safety. Ask whether the system behaves as intended. Privacy and security protect data and access inclusiveness considers people with different needs and abilities. Transparency means users understand what the AI can and cannot do. Accountability keeps a real person or team responsible for the result. Those principles become useful when they enter the AI lifecycle. Start by mapping the use case and its data. Measure risk and quality before release. Fix gaps through controls, design changes or narrower permissions.

9:40 Operate the solution with monitoring and named owners. Then manage changes in retirement when the tool no longer fits the job. Keep a record for every AI solution record its name, owner, data sources, model or copilot service permissions, risk level, approval status, and monitoring plan. This is your AI inventory, but it's also a memory system. Six months later, someone should be able to see what the AI does without hunting through old teams chats before release. Test for failure on purpose. Ask whether it gives wrong answers with confidence. Check whether it pulls poor source material. Try unsafe requests. Test prompt injection where hidden text in a document tries to change the AI's instructions. If the solution can use tools, test whether it attempts an action it shouldn't take. Human oversight closes the gap between a helpful assistant and an uncontrolled system.

10:23 Decide where a person reviews output, approves actions, handles exceptions, and can stop the system. An agent doesn't become safe because it worked in a demo. It becomes safer because people know exactly when to step in. And governance doesn't end at launch. If an agent gains a new data source, new users, another connected tool, or more freedom to act, reassess it. The use case changed even if the agent kept the same name. Rules only work when your access and data controls can enforce them. Pillar two security protecting data identity and AI actions. Security starts with a simple rule you can't protect an AI system you can't see. If nobody knows an agent exists, who owns it, what it connects to, or which actions it can take. Security teams can't judge the risk.

11:04 They can only discover it after something breaks. Start with identity. Every user and every agent needs a known owner, access tied to a real job, and only the permissions that job needs. This is least privileged access. An agent that summarizes service cases doesn't need permission to edit customer records. An agent that drafts a report doesn't need access to every SharePoint site in the company. Treat an agent like an active worker. It may read data search systems. Call a tool, trigger a flow, or send a message. The chat box feels harmless because you type into it, but the work behind that chat can reach far beyond a single conversation. Once an agent can act, its identity and permissions need the same care you'd give a new employee account. Data control comes next. Classify and label sensitive files so people and systems can understand what needs more protection.

11:48 Keep existing permissions in place, limit AI retrieval to approved sources and protect the output as well as the prompt. A confidential answer copied into the wrong place can create the same problem as a confidential file shared by mistake. Microsoft three hundred sixty five copilot follows a simple permission model. It should retrieve content that the signed in user already has permission to access. Copilot doesn't magically grant someone access to a private document, but that creates a headache for many organizations. Copilot can expose oversharing that already existed. Maybe a large SharePoint folder stayed open to a broad group for years because nobody searched through it carefully. A person might never find the wrong file manually. AI can search and summarize much faster, so weak permissions become easier to notice.

12:29 AI didn't create that access problem. It brought the problem into view. The real tension here is that AI introduces risks that older controls weren't built to handle alone. A document might contain hidden instructions that try to redirect an AI system that's prompt injection. Someone may attempt a jailbreak trying to push the system past its intended limits. A malicious request may try to trick an agent into using a connected tool in the wrong way. Even stored contacts can become poisoned if bad information enters the source material. You don't solve that with one setting. You use layers. Choose models that fit the work and your risk level. Apply content filters. Give the application clear system instructions. Ground responses in approved data rather than letting the model guess. Design the user experience so people can review important results before an action happens.

13:11 Then monitor how the AI behaves after release. Because a system can face different inputs on a busy Tuesday than it faced in a test environment, Microsoft has controls that map to these layers and helps manage identity access and sign in conditions. Purview helps classify data, apply sensitivity labels, and reduce data loss. Defender brings threat signals and security investigation into the picture. Azure AI foundry gives development teams a place to evaluate AI applications, test behavior, and monitor them as they run. None of these tools removes the need for ownership. They give the CEO a way to turn security decisions into controls people can check. Keep a central record of your agents, their connections, permissions, and owners. Record the prompts or actions that need review while respecting privacy and policy.

13:53 Watch usage patterns and incidents if an agent suddenly starts calling a tool far more often than normal, or begins reaching data it rarely used before, someone needs to see that signal and plan for failure before failure arrives. If an agent acts in a way you didn't intend, pause it. Remove access if needed. Review logs. Notify the owners, find the cause, fix the control or design problem, and retest before switching it back on. Speed matters, but restarting an untested agent only repeats the incident. Secure AI that nobody trusts or knows how to use still fails. Adoption turns protected capability into work. People choose to do pillar three adoption, turning AI access into useful habits. Adoption means more than buying licenses and watching a usage dashboard. It means people use AI safely for work that actually improves, then choose to use it again because they can feel the difference in their day.

14:38 Many organizations miss this point. They buy copilot licenses, send one launch email linked to a training page, and wait for the usage chart to rise. Instead, it climbs for a week, then levels off. People tried a few prompts, got mixed results, and returned to the work habits they already knew. You might think people need more AI features, but low adoption usually starts somewhere else. The work problem isn't clear or people don't know where to ask for help when the first result feels wrong. A tool can be available to everyone and still feel like it belongs to nobody. Start with roles and real tasks. A sales team might use copilot to prepare for a customer meeting by pulling together notes, emails, and open questions. A service team may use it to create a first draft of a case summary. Finance may use it to explain a variance before an analyst checks the numbers.

15:20 HR may help staff find the right policy while it can use it to surface support knowledge faster. Each scenario needs a boundary and a result people can recognize. Use AI more gives nobody a useful next move. Cut meeting preparation from thirty minutes to ten while checking the source material gives a team something concrete to test. That's where a champion network helps find trusted people inside each department, not just the people who love new tech. Give them early access, role based examples and a simple way to send feedback back to the CEO. Their job isn't to become AI support staff. They help colleagues see how the tool fits work they already do, and they give people a familiar person to ask when they get stuck. Training must include judgment, not just prompts. People need to verify output, check the source, protect sensitive data, and recognize when AI isn't the right tool for the job.

16:05 If a response affects a customer, a financial decision, or a person's employment, the human responsibility didn't disappear because a copilot drafted the words. Start small enough that the result is visible. Pick one task, one team, and one measure. Maybe a service team spends less time writing case notes. Maybe an account team reaches customer meetings better prepared. Share the before and after result in plain language. Because a real example travels further than a generic training slide. Then listen closely. Users will tell you where the AI gives poor answers, misses the right data, creates confusing steps, or opens a useful new idea. Feed that back into the Co backlog. Some feedback leads to better guidance, some points to a data problem. Some ideas deserve a new use case. The loop matters because adoption doesn't finish on launch day.

16:47 People also need clarity about what changes and what stays human. Explain who owns decisions, which tasks AI can support, and how work quality gets checked. When leaders leave those questions unanswered, employees fill the gap with caution or fear. Measure behavior, not just access. Look at active use in the roles you targeted. Repeat use time saved task completion, user confidence, training, completion, and help requests. Those signals tell you whether the work improved or whether people simply opened the tool. Once governance, security and adoption now join in one repeatable operating rhythm. Build the first version of your Coe. You don't need a huge department to begin. Start with an executive sponsor who can clear blockers and connect the work to business priorities, add a program lead to run the process, then bring in business security data platform and adoption leads.

17:31 One person can cover more than one role at first. If the scope stays small during the first thirty days, find out what's already happening. Build an inventory of current AI tools, co-pilots, agents, and automated flows. Look for sensitive data gaps. Choose one shared intake form and name an owner for every item you find. Unknown ownership deserves attention first. Over the next sixty days, choose two or three business use cases with clear outcomes. Set risk levels. Publish which tools people can use and where they can find guidance, then capture baseline measures before the pilot changes the work without a baseline claims about time saved. Stay vague. The next ninety days. Focus on practice. Run the reviews, test the controls, train champions and track the results. Retire pilots that don't help reuse the patterns that do, because each successful use case should reduce the effort needed for the next one.

18:16 Keep the paperwork simple an AI register, a risk checklist, a decision log, an architecture pattern, an adoption plan, and a scorecard. These aren't documents for their own sake. They answer the questions people ask when a use case grows beyond its first team. Don't build a giant committee or a policy binder that nobody reads. You also can't predict every future AI use case on day one, build a working path, learn where it slows down and improve it. That gives low risk work. A faster route gives higher risk work. A clearer review reduces surprise data exposure and makes business outcomes easier to see. The goal isn't a perfect AI program. It's a system that keeps learning as AI changes implementation, challenge, and next step, an AI center of excellence becomes the shared operating system for governance, security, and adoption.

19:00 It gives people a way to move with purpose instead of letting AI spread without ownership. This week, list every AI tool, copilot, agent, and automated flow already touching business work. For each item, name one owner and one data source. Flag anything that has neither because that's where uncertainty turns into risk. Then pick one low risk use case with a measurable outcome and send it through a simple intake and review path. AI use will keep growing, whether your organization plans for it or not. Subscribe to M365 FM to master the tools and the mindset shaping the future of work. Because governing copilot and agents without blocking the people building them is the next tension your Co will need to solve.