The Leader's Guide to Implementing AI

When I work with organizations on AI, executive use is one of the first things I look at. I want to know whether the people setting expectations have used the tools on work they understand, checked the results and seen where the tools fall short.

The roadmap I use with clients starts with leadership taking responsibility for how the work changes. That includes the outcome, the time people need to learn and the decisions about what's allowed. It also includes the technical work. Permissions, integration and unreliable outputs are real implementation problems, and somebody has to own them.

Put a named internal owner in charge, choose a worthwhile workflow and fund a focused trial. Agree on what success means before the team starts. Expand when the result is useful and repeatable, and stop uses that can't justify their cost or consequences.

Start there, learn from the completed work and decide where to expand.

Use the Five C's to choose the next move

Our Five C's model describes AI adoption through Curious, Chaotic, Capable, Creating and Compounding. Use it to discuss your organization's current practices and what needs to improve next. Use the stage descriptions to choose the next practice your team needs to build.

Look for evidence before assigning yourself a stage. Ask what people actually use, whether the use is approved, whether they can check the output and whether useful practices survive beyond an enthusiastic individual. Different departments may be at different stages, and practices need to be maintained or they can deteriorate.

For a team still experimenting independently, the next move may be agreed boundaries and practical training. For a team already using approved tools consistently, it may be redesigning a recurring workflow. For a team running useful systems, it may be improving support, measurement or reuse.

Don't make agents or custom software a compulsory destination. Choose the next investment according to the work. A well-used assistant can be the appropriate solution, while another workflow may justify an integration or a system built for a specific purpose.

Use the activities below to put that decision into practice.

Name an owner and give managers a real job

Name one internal AI owner who keeps the plan current, coordinates decisions and brings unresolved issues to the leadership team. Choose someone with access to the people who can approve priorities, spending and controls. Give them access to the people who will build and support the tools.

Each participating team's manager is the sponsor. Give that manager responsibility for choosing useful work, making time for practice and reviewing what the team produces. They should use the approved tools themselves and make it safe for people to report mistakes, confusion and uses that have developed without clear approval.

Champions help colleagues learn and improve everyday practice. Give them protected time, access to support and a way to pass recurring problems to the owner. Adjust their other commitments so they have time to do the job. Appointing an enthusiastic employee while leaving their workload untouched is a poor implementation plan.

These responsibilities remain inside the business even when an outside partner helps. The provider can build or operate a system, but your managers must still decide which work matters and whether the outputs are acceptable.

Bring technology, privacy and other relevant specialists into decisions that need their judgment. Give each question an owner and a decision date. A small working group with a defined task can be useful; an open-ended discussion without decision authority is unlikely to resolve the next practical obstacle.

Agree on what the team can do

Write down the exact product and account the team will use, the information it may process and the actions it may take. Specify who reviews the output and where a person must approve the next step.

Check the boundary against the actual configuration. A document that says restricted information is excluded does little if the connected account can retrieve it. Review permissions before enabling connections, and test with a user whose access matches the pilot participants.

Microsoft's enterprise Copilot documentation covers permissions and administrative controls. It also describes separate data handling for web queries and tells customers to check agent terms. Ask your technology owner to check each part you plan to use. Read the Microsoft guidance.

I'd begin with the least access needed to test the workflow. Keep excluded information out, avoid unnecessary connections and require a fresh review when the proposed scope changes. Give the team a named contact for questions and a clear route for reporting a mistaken disclosure or unexpected action.

The US National Institute of Standards and Technology's 2024 Generative AI Profile recommends deployment thresholds, ongoing review and mechanisms to deactivate systems when necessary. Read the NIST profile.

Before the pilot begins, answer this question: if the system produces an unacceptable result tomorrow, who can pause its use and how will the work continue? Test that answer with the person responsible.

Choose a workflow worth the effort

Ask teams where an improvement would matter to customers or free capacity for higher-value work. Then examine the workflow with the people who actually perform it. Understand its inputs, decisions, handoffs, exceptions and acceptance standard before choosing what AI should do.

Choose work that happens often enough to test, uses information you can share with the tool and produces something your team can check. Avoid beginning with a use where a plausible error would be difficult to detect or costly to reverse.

For a professional services firm, candidates might include preparing a research briefing from approved sources, drafting a proposal from an agreed scope or producing an initial action list from approved meeting notes. Try the most promising task with the person who does it, and count the time they spend checking the result.

Also examine the simpler alternatives. A clearer intake form, better template or ordinary software rule may solve the problem. Select AI when it improves the proposed process enough to justify the added work of checking and maintaining it.

Choose one priority for the quarter and explain why it matters. Keep other ideas in a visible list with a decision about whether to test them, plan them for later or leave them parked. Don't ask the same small group to run every appealing experiment simultaneously.

Put the pilot on one page

The pilot brief should be short enough for the manager and participants to use during the work. Fill it in together before building anything substantial.

• Outcome: State the business result you want and the quality condition that must hold.
• Scope: Describe the starting input, finished output and cases excluded from the trial.
• Ownership: Name the manager accountable for the result and the person maintaining the workflow.
• Data and access: Identify the approved account, allowed information and necessary permissions.
• Baseline: Record the current time, cost, quality and volume using comparable work.
• Trial: Set the participants, budget, review date and way results will be recorded.
• Decision: Define what supports expansion, what needs revision and what stops the trial.
• Continuity: State how the work continues if the tool is unavailable or the trial is paused.

Here is a hypothetical example. A consulting team wants to reduce the time spent turning agreed meeting notes into a client follow-up. The trial covers drafting only. The account owner checks decisions, commitments, dates and recipients, then sends the final message through the normal process.

The team records total preparation and review time, corrections and whether the completed follow-up reaches the client when needed. If the draft regularly misstates commitments, the manager pauses that use and examines the input and instructions. If it consistently helps, another colleague tries the documented method before the team expands it.

The manager can bring the completed follow-ups to the review, show what needed fixing and recommend whether the team should keep using the method.

Teach people on the work, including the checks

Use approved examples from the selected workflow in training. Show participants how to give context, state the required result, supply an appropriate example and revise an inadequate answer. Then have them do the task themselves while somebody is available to help.

Include an output with a meaningful error. Ask participants to explain how they would find it and what they would do next. For a briefing, that might mean opening a source that contradicts a claim. For a follow-up, it might mean spotting a commitment that was never agreed.

Give managers a way to see whether people can complete the workflow, including the review. Ask participants to bring a finished example and explain the corrections they made.

Public research offers a useful example of looking beyond individual drafting speed. In a company-specific product-development workshop study at Procter & Gamble, published in 2026, individuals using AI matched the performance of two-person teams without it, but the authors caution that one-day virtual collaborations don't capture ongoing team relationships and rework. The study compared people working individually and in pairs, with and without AI. Read the published paper.

Look at who needs to contribute at each step of your own workflow. Test whether better preparation gives the reviewer more time to focus on the decision. Ask that reviewer what helped and where they still needed to get involved.

Keep a short practice review after training. Ask where people needed help, which instruction improved the result and what should be excluded. Update the workflow note so the learning becomes available to the next person.

Decide who will build and maintain it

Some useful workflows need only approved tools, a documented method and capable staff. Others need software, integrations or automation. When building is justified, decide whether your own people will do it or whether an outside team will build and run it for you.

Choose based on capability and ongoing capacity. An internal build needs a person who can maintain it, time in their workload and access to the necessary review. An external build needs a clear agreement about support, access, changes and what happens when the engagement ends.

Ask to see how the system will be tested, who can release a change, how problems are reported and how the business can recover its information. Write down who owns the accounts and who keeps the instructions up to date. Include support and maintenance in the cost comparison.

Don't let a successful demonstration settle those questions by default. A tool that helps its creator may still need work before colleagues can rely on it. Test it with ordinary users and normal exceptions, then decide whether the additional investment is worthwhile.

If you want an outside team to build and run the system, see our build-and-run work. Keep an internal owner responsible for the outcome and the decisions about how your team uses it.

Give delegated actions a separate approval

A tool drafting text and a system acting on that text require different operating decisions. When you consider an agent that can use other systems, list the actions it may take and the consequences of getting them wrong.

For an initial trial, I'd keep human approval for external messages, spending, deletion, changes to access and material updates to customer records. Allow only the permissions needed for the approved task. Set spending or usage limits where relevant, keep a record of actions and make it possible for an accountable person to stop the system.

Test failure cases deliberately. What happens if an input is missing, a request is duplicated or a connected service is unavailable? What happens when retrieved material contains instructions that conflict with the assigned task? Require the system to keep untrusted content from becoming authority to take an action.

Also decide what happens after a partial failure. If a system completes an initial step and then stops, the person taking over needs to know what already happened. Include that recovery effort in testing, especially before allowing actions that affect customers.

Before you give a system more authority, test the new actions and review the results with the person responsible. Decide what it can do on its own, what needs approval and how you'll reverse an error.

Review the result and maintain what works

Keep a monthly leadership review tied to the AI Plan. Bring the outcome measures, the cost of operating the approved uses, completed examples and the most important unresolved issue. Assign the next decision before the meeting ends.

Measure the whole workflow, including preparation, review, correction, support and recurring fees. Distinguish released capacity from cash savings, and say where that capacity is being used. AI Is Here. Where Are the Productivity Gains? gives a worked example and a measurement sheet.

Expand a useful practice by giving the next team its purpose, owner, approved inputs, instructions, checks and fallback method. Ask that team to verify that it works in their setting. Record any changes they need, since a different customer group or type of work may require a different approach.

Retest relevant examples when the model, instructions, source material or connected systems change. Remove uses that no longer justify the effort, and keep the inventory current enough that someone can find an owner when a problem occurs.

What I'd do over the next quarter

In the opening weeks, name the owner, agree on what the team can do and choose the first workflow. Measure how the work gets done today and make time for you and your team to practice. Then run the trial, look at the finished work and decide whether to continue, revise or stop.

Use the remaining time to document and maintain a useful result, and to decide whether the next investment should extend that use or address another priority.

At the next leadership meeting, I'd ask for a one-page AI Plan naming the current position, this quarter's priority, who will do the work, the evidence needed for the next decision and the open issues. Give the owner the authority and time to act on it, and book the review now.

Research checked September 26, 2026. The publication date above is the original article date.

Sources

Enterprise data protection in Microsoft Copilot and Microsoft Copilot Chat
Microsoft Learn. Updated August 18, 2026; checked September 26, 2026.

Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
National Institute of Standards and Technology, NIST AI 600-1. July 2024.

The Cybernetic Teammate: A Field Experiment on Generative AI and Teamwork
Fabrizio Dell'Acqua and colleagues, Organization Science, INFORMS. Published online June 12, 2026.

The Five C's of AI Adoption
The Work Smarter Company. Undated public model page; checked in the site source September 26, 2026.