Who owns it, what it delivers, and how to tell if yours is working

If your company bought AI licenses, ran a training session, and is still waiting for work to change, you are asking the question AI enablement is meant to answer. How do you get from “people have the tools” to “teams work differently because of them”? AI enablement is the ongoing work of helping people and teams use AI well in their real jobs. It covers skills, shared practices, workflow redesign, guardrails, and feedback loops. Unlike a tool rollout, which ends when the licenses go live, AI enablement is a standing function with an owner, a mandate, and outcomes it is accountable for. That difference matters more than it sounds. Most organizations already have access. McKinsey’s 2025 State of AI survey found that 88% of organizations use AI in at least one business function, but only about 6% qualify as high performers seeing meaningful EBIT impact. The gap between those two numbers is the territory AI enablement covers.

What AI Enablement Means in Plain Language

Think of AI enablement as the difference between giving someone a gym membership and helping them build a training habit. The membership is necessary. It is not the result. In practice, AI enablement answers four questions on a recurring basis:

1. What work should change? Which workflows, decisions, and handoffs could be done differently with AI, and which should stay human.
2. Who needs what capability? Not everyone needs the same skills. A finance analyst, a product manager, and an engineering lead each need a different kind of fluency.
3. How do teams learn together? Individual skill is not enough when the work is shared. Teams need common practices, language, and norms.
4. Is it working? Enablement tracks whether behavior and outcomes are actually shifting, not just whether people logged in.

A tool rollout answers a much narrower question: “Does everyone have access, and do they know which button to press?”

Why a Tool Rollout Is Not the Same Thing

Tool rollouts are projects. They have a start date, an end date, and a checklist. Licenses get provisioned, an announcement goes out, a training video gets recorded, and the project closes. AI enablement is different in three specific ways.

It does not end

AI capabilities change every few months. The prompting approach a team learned in January may be outdated by summer, and a workflow that needed three tools may collapse into one. A function that is built to keep adapting can absorb that change. A finished project cannot.

It is measured on behavior, not access

A rollout succeeds when people have the tool. Enablement succeeds when the way work gets done changes. BCG’s 2025 research on the AI adoption puzzle found that only 25% of leaders report significant value from AI despite widespread usage, and that AI success depends roughly 70% on people and processes, 20% on technology infrastructure, and 10% on algorithms. A rollout focuses on the 30%. Enablement is built for the 70%.

It works at the team level, not just the individual level

Rollouts usually train individuals. But most valuable work happens in teams, and when one person on a team uses AI heavily and the rest do not, coordination gets harder, not easier. Enablement treats the team and its workflows as the unit of change. This is where human AI collaboration becomes a design question rather than a personal preference: who does what, which steps involve an AI agent or assistant, and where human judgment is required.

The Five Components of an AI Enablement Function

Organizations that run AI enablement well tend to build the same five components, whatever they call them.

1. A named owner

Someone has to be accountable. In some organizations this is an AI transformation leader or AI lead reporting to the COO, CTO, or Chief People Officer. In others it is a small enablement team inside operations or L\&D. The title matters less than the mandate: this person or team is responsible for adoption outcomes, not just tool availability. Without a named owner, AI enablement becomes everyone’s side project. IT owns the licenses, HR owns training, each department experiments on its own, and nobody owns whether the organization is actually getting better at working with AI.

2. Workflow redesign

This is the component most often skipped and the one that matters most. McKinsey’s survey identified fundamental workflow redesign as the single strongest predictor of enterprise-level AI impact among the factors it tested (McKinsey, The State of AI, 2025). Workflow redesign means sitting down with the people who do the work and asking how a specific process should run now that AI is available. Which steps disappear? Which ones need a human checkpoint? What does the handoff between a person and an agent look like? This is facilitation work as much as technical work, because it requires getting a cross-functional group to agree on a new way of operating.

3. Role-based capability building

Generic AI training gives everyone the same content. Enablement builds capability around roles and real tasks. A sales team learns to use AI for account research and call prep using their own accounts. An engineering team works through code review and documentation workflows in their own repositories. Practicing on real work is what turns a training session into a habit.

4. Shared practices and peer learning

People learn AI from each other more than from formal programs. BCG’s research found that 69% of employees rank peer-to-peer learning among their top three ways to build AI skills (BCG, 2025). An enablement function builds the structures that make peer learning happen on purpose: champion networks, show-and-tell sessions, shared prompt and workflow libraries, and regular team retrospectives on what is and is not working.

5. Guardrails and feedback loops

Enablement includes the rules of the road: an acceptable use policy, data handling guidance, and a clear path for escalating questions. It also includes feedback loops that let the function learn. That can be as simple as a quarterly pulse survey on AI use, a review of which workflows changed, and a running list of where teams got stuck.

DELETE ME · AI photo · Google Gemini 3 Pro

AI Enablement vs. a Tool Rollout: Side by Side

Who Should Own AI Enablement

There is no single right reporting line, but three patterns show up most often.

Under operations or the COO. This works well when the main goal is workflow and process change across functions. Operations leaders already own how work moves through the organization.

Under technology or the CTO. This works when AI use is heavily tied to engineering, data, and platform decisions. The risk is that enablement gets treated as a technical problem and the people side gets underfunded.

Under people or L\&D. This works when capability building is the main gap. The risk is the opposite: strong training programs with no authority to change workflows. Many organizations end up with a hybrid: a small central enablement team with a clear owner, plus a network of embedded champions in each department. The central team sets direction, builds shared resources, and measures progress. The champions translate it into the daily work of their teams. Some organizations also bring in an outside AI transformation consultant to help stand the function up, run the first round of workflow redesign sessions, and train internal leads. That works best when the goal is to build internal capability rather than to outsource the function permanently.

Common Pitfalls Teams Hit

These five patterns are among the most common reasons AI enablement efforts stall.

Measuring logins instead of outcomes

Usage dashboards are easy to build and easy to misread. High login counts can mean people are using AI for trivial tasks while the important workflows stay unchanged. Pair usage data with a small number of outcome measures tied to specific workflows.

Training everyone the same way

A single company-wide course is efficient to deliver and rarely changes behavior. If the content does not connect to someone’s actual job, it fades within weeks.

Leaving leaders out

When senior leaders do not use AI themselves, they struggle to imagine how their teams’ work could change, and they send mixed signals about whether experimentation is welcome. Leaders need hands-on time, not just a briefing.

Skipping psychological safety

People will not experiment openly if they worry about looking incompetent or about AI replacing their role. Enablement has to make it safe to try, fail, and share what did not work. Without that, usage goes underground or stops.

Treating enablement as a one-time program

The most common pitfall is the core one this article addresses. A launch with a kickoff event and a training series feels like enablement, but if there is no owner and no cadence after month three, it was a rollout.

How to Get Started: Practical Steps for Leaders

If you are a director or VP being asked to “drive AI adoption,” these steps give you a workable starting point.

Step 1: Name an owner and write a one-page mandate

Decide who owns AI enablement and what they are accountable for. Keep the mandate short: the outcomes you expect, the teams in scope, the budget, and how progress will be reviewed.

Step 2: Pick two or three workflows to redesign first

Choose workflows that are frequent, cross-functional, and painful today. Bring the people who do the work into a facilitated session to map the current process and design the AI-assisted version together. Start small so the team can learn the redesign process before scaling it.

Step 3: Build role-based learning around those workflows

Train the people involved in those workflows on the specific skills they need, using their real work. Avoid generic courses at this stage.

Step 4: Stand up a champion network

Identify a few people in each team who are already experimenting. Give them time, a channel, and a regular forum to share what is working. Their job is to make peer learning visible.

Step 5: Set a measurement baseline

Before changing anything, capture a baseline for each target workflow: cycle time, error rate, hours spent, or whatever matters most. Run a short survey on how people currently use AI and how confident they feel. Measure again after 60 to 90 days.

Step 6: Establish a regular cadence

Put a monthly or quarterly review on the calendar. Review what changed, what stalled, and what new capabilities have appeared. This cadence is what turns a project into a function.

Making AI Enablement Stick

AI enablement is less about the tools and more about how an organization learns. The companies pulling ahead are not necessarily the ones with the most licenses. They are the ones that named an owner, redesigned real workflows with the people who do the work, and built a habit of revisiting both as the technology changes. For an AI transformation lead or a leader just handed the mandate, the most useful shift is to stop asking “Did we roll it out?” and start asking “Is the way we work actually changing?” If you are building an AI enablement function and want help designing the workflow sessions, champion structure, or measurement plan, Voltage Control’s AI transformation program and AI training are built for exactly this work. Book a free intro call with our facilitation team to talk through where your organization is today and what a practical next step looks like.

The post AI Enablement Is an Operating Function, Not a Tool Rollout appeared first on Voltage Control.

Why one-off sessions fade within a week, and how to design training that sticks

If your company has rolled out AI tools and run training sessions, and people still aren’t using the tools much, the question is: what does AI training for employees need to look like so that it actually changes how people work? The short answer is that it has to be built around real workflows, practiced in teams, and reinforced for weeks after the first session.

What AI Training for Employees Actually Means

AI training for employees is the structured work of helping people use AI tools well in their own jobs: knowing when to reach for a tool, how to prompt and check it, and how to fit it into the tasks they already do. Good training is measured by behavior change, not attendance. If the way a team writes, analyzes, plans, or decides looks the same a month later, the training did not work, no matter how well the session was rated. That definition matters because most programs are designed around the wrong unit. They teach features (“here is how to summarize a document”) when the real goal is a new habit (“our team drafts every customer brief with AI first, then edits”). Features are easy to demo. Habits form only when people practice on their own work, with the people they work with, over time.

Why the gap is so wide right now

The demand side is clear. Microsoft and LinkedIn’s 2024 Work Trend Index (May 2024, 31,000 people in 31 countries) found that 75% of knowledge workers already use AI at work, yet only 39% of AI users had received AI training from their company. People are figuring it out on their own, often with tools they brought themselves. The supply side is thin. BCG’s AI at Work 2025 survey of more than 10,600 workers across 11 countries found that only 36% of employees feel adequately trained in AI use, and only 51% of frontline employees are regular users, a number BCG describes as stagnant. Licenses are in place. Usage is not.

Why One-Off AI Training Sessions Fade Within a Week

The lunch-and-learn, the recorded demo, and the two-hour kickoff all share the same design flaw: they treat learning as an event. People leave with a few ideas and some enthusiasm, then go back to a full inbox and the deadlines they already had. The old way of working is faster in the moment because it is familiar, so it wins. Researchers have studied this decay for a long time. Carnegie Mellon’s Linda Argote documented that knowledge in organizations depreciates when it is not used, in Organizational Learning: Creating, Retaining and Transferring Knowledge (Springer, 2nd ed. 2013). Skills that are not practiced fade, and so do skills that only one person on a team holds. There are 3 reasons one-off sessions fail to change behavior:

1. The examples are generic. A demo built on a sample marketing email does not tell a finance analyst what to do with a variance report on Tuesday.
2. Nobody practices. Watching someone else prompt a tool is not the same as getting a bad answer yourself and learning how to fix it.
3. Nothing changes after the session. The meeting cadence, templates, and review steps that shape daily work stay exactly the same, so the new behavior has nowhere to live.

The 4 Components of AI Training That Changes Behavior

Programs that move usage tend to share four components. Each one targets a reason training decays.

1\. Anchor training in real workflows

Start with the work, not the tool. Before designing any session, identify 2 or 3 recurring tasks per team where AI can save time or raise quality: drafting a status update, summarizing customer interviews, writing test cases, preparing for a one-on-one. Then build training around those exact tasks, using the team’s own (appropriately sanitized) materials. This is where human AI collaboration becomes concrete. Instead of an abstract idea, it becomes a specific division of labor: the AI drafts the first version, the person supplies context, judgment, and the final edit. Teams that write down that division of labor for each workflow have a shared human AI collaboration model they can teach, critique, and improve.

2\. Give people enough hours, in the right format

Time matters. BCG’s AI at Work 2025 found that employees who receive five or more hours of training are significantly more likely to become regular users, especially when that training is in person and includes coaching. A single 60-minute webinar falls well short of that threshold. Five hours does not need to be one long day. It works better spread across several weeks: a hands-on kickoff, then short practice sessions tied to real deadlines, then coaching when people get stuck.

3\. Practice in teams, not just as individuals

Most AI habits are team habits. If one person on a team drafts project plans with AI but the review process still expects the old format, that person gets friction instead of credit. Training a whole team together lets people agree on shared norms: which tasks use AI by default, what has to be checked by a human, and how to flag AI-assisted work. Team practice also spreads skill faster. People learn more from watching a peer solve a problem they recognize than from a vendor demo. It also protects against the knowledge loss Argote describes, because the skill no longer lives with a single early adopter.

4\. Reinforce for at least 30 days after the session

Reinforcement is the component most programs skip. Plan for at least 30 days of follow-through after any formal session:

• A short weekly check-in where teams share one thing that worked and one thing that did not
• Updated templates and checklists that build the AI step into the workflow
• Office hours or a named go-to person for questions
• A simple before-and-after measure, such as time spent on a recurring task

Leadership involvement belongs here too. BCG found that just 25% of frontline workers say their leaders provide enough guidance on AI, and that adoption and employee optimism are markedly higher where leaders are engaged. When a manager asks “how did you use AI on this?” in a regular meeting, the habit gets reinforced without any extra training at all.

DELETE ME · Unsplash photo

One-Off Sessions vs. Behavior-Change Training

Common Pitfalls Teams Hit

Even well-funded programs run into the same 5 problems.

Treating training as a launch event

When training is tied to a tool rollout date, it gets scheduled for the launch and then forgotten. The rollout is the start of the learning curve, not the end of it.

Measuring the wrong thing

Course completion rates and post-session surveys are easy to collect and say almost nothing about behavior. Track whether specific workflows changed: are status reports drafted faster, are customer summaries more consistent, are engineers using AI in code review?

Ignoring the frontline

Executives and early adopters often get the most attention, while frontline teams get a recording. BCG’s finding that frontline regular usage has stalled at 51% is a warning sign. The people doing the highest-volume work often have the most to gain and the least support.

Skipping the “what not to do” conversation

People hesitate to use AI when they are unsure what is allowed. Clear guidance on data, review requirements, and acceptable use removes a quiet barrier that no amount of feature training will fix.

Leaving managers out

If managers are not trained alongside their teams, they cannot coach, and they may unintentionally signal that AI-assisted work is less legitimate. Managers need their own session on how to lead teams through the change, not just how to use the tool.

How to Get Started: A Practical Plan for Leaders

Whether the work is owned by an L\&D lead, an engineering manager, or a designated AI transformation lead, the steps are similar.

Step 1: Pick two teams and three workflows each

Start small. Choose two teams with a willing manager and identify three recurring tasks per team where AI could clearly help. This gives a contained pilot with real work behind it.

Step 2: Measure the baseline

Before any training, capture how those workflows run today: time spent, steps involved, quality issues. A short survey on confidence and current AI use adds a second baseline. Without a “before,” nobody can show an “after.”

Step 3: Run a hands-on kickoff on the team’s own work

Hold the first session in person or live, with the whole team. Spend most of it on practice using the selected workflows. End by agreeing on a few shared norms for how the team will use AI over the next month.

Step 4: Schedule the reinforcement before the kickoff ends

Put the weekly check-ins, office hours, and template updates on the calendar before people leave the room. If reinforcement is not scheduled, it will not happen.

Step 5: Review at day 30 and decide what to scale

Compare the workflows against the baseline. Keep what changed behavior, drop what did not, and use the two pilot teams as peer coaches when the program expands.

When outside help makes sense

Some organizations run this entirely in-house. Others bring in an AI transformation consultant when internal teams lack facilitation capacity, when adoption has already stalled once, or when leadership alignment is the real bottleneck. An experienced AI transformation leader, inside or outside the company, is most useful for designing the workflows, facilitating the team sessions, and coaching managers, not for delivering another slide deck.

Frequently Asked Questions

How long should AI training for employees take?

Plan for at least five hours per person, spread over several weeks, plus 30 days of reinforcement. BCG’s research ties five or more hours of training to a much higher likelihood of regular use.

Should AI training be different for each team?

Yes. The tools may be the same, but the workflows are not. A shared foundation on safe use and checking AI output works well across teams, and the hands-on practice should use each team’s own tasks.

How do you know if AI training worked?

Look at the workflows you targeted. If recurring tasks take less time, produce more consistent output, or have a new AI step built into the template, behavior changed. Attendance and satisfaction scores alone cannot tell you that.

Who should own AI training inside a company?

Ownership often sits with L\&D, an AI transformation lead, or a cross-functional group. What matters most is that line managers are involved, because they shape the daily habits training is trying to change.

The Bottom Line

AI training for employees works when it is treated as a change in how teams work rather than a session people attend. Anchor it in real workflows, give it enough hours, practice as a team, and reinforce for at least a month. The tools will keep changing. Teams that have learned how to learn together will keep up. If you are planning AI training for your teams and want it to stick, Voltage Control’s facilitators design and run hands-on programs that build human AI collaboration into everyday work. Book a free intro call with our facilitation team to talk through where your rollout stands and what would move it forward.

The post AI Training for Employees That Actually Changes How People Work appeared first on Voltage Control.

Who gets access first, where human review stays mandatory, and which metrics prove it works

A Claude Code enterprise rollout is the plan an engineering organization uses to take Anthropic’s agentic coding tool from a few individual experiments to a governed, org-wide capability. A good rollout answers three questions before the licenses go out: who gets access first, where human review stays mandatory, and which metrics will show whether the tool is actually improving delivery. Most engineering leaders asking about Claude Code at enterprise scale are not asking whether the tool works. They have already seen a senior engineer close a gnarly refactor in an afternoon. The real question is how to spread that across fifty or five hundred engineers without flooding code review, weakening security posture, or ending up six months later with a line item nobody can justify.

What a Claude Code Enterprise Rollout Actually Covers

Claude Code is a coding agent that runs in the terminal, in IDEs like VS Code and JetBrains, and in the desktop app. Unlike an autocomplete tool, it can read a repository, run commands, edit multiple files, and open changes for review. That autonomy is the whole value, and it is also why an enterprise rollout looks different from turning on a chat assistant. An enterprise rollout typically covers four layers:

1. Policy. Organization-wide rules that individual developers cannot override, such as which commands the agent may run and which files it may never read.
2. Project conventions. Shared, version-controlled instructions and permissions that every engineer on a repository inherits.
3. Review gates. The points in the delivery pipeline where a human must approve agent-written work before it moves forward.
4. Measurement. A small set of delivery and quality metrics, baselined before the rollout and tracked after it.

Claude Code is built to support this layering. According to Anthropic’s Claude Code settings documentation, managed settings sit at the top of the precedence stack, and “nothing in your own settings files or \–settings overrides a managed key.” Below that, a shared project file at .claude/settings.json lets a team commit permissions and hooks so everyone who clones the repository gets the same rules. That structure maps neatly onto the policy and project layers above.

Why the Rollout Plan Matters More Than the License

It is tempting to treat AI coding tools as a pure productivity unlock: buy seats, measure adoption, declare victory. Public research suggests leaders should be more careful than that. Google’s DORA research program, in its 2024 Accelerate State of DevOps report announcement (October 22, 2024), found that “as AI adoption increased, it was accompanied by an estimated decrease in delivery throughput by 1.5%, and an estimated reduction in delivery stability by 7.2%.” That is a correlation across survey respondents, not proof that AI tools cause instability, but it is a clear signal that adoption alone does not guarantee better delivery. A separate randomized controlled trial from METR, published in July 2025 as Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, studied 16 experienced developers working on 246 tasks in mature codebases they knew well. Developers expected AI tools to cut their completion time by 24 percent. In the METR trial, measured completion time actually rose by 19 percent. The authors caution that the result may not generalize to other tools, tasks, or later model generations, and agentic tools have changed considerably since then. The useful lesson for leaders is the gap between perceived and measured speed: engineers can genuinely feel faster while the system they work in gets slower. Both findings point to the same conclusion. The outcome of a Claude Code enterprise rollout depends less on the tool and more on the access model, review discipline, and measurement the organization wraps around it.

Decision 1: Who Gets Access First

The instinct in many organizations is either to give everyone access on day one or to restrict it to a hand-picked few indefinitely. Neither works well. A better approach is to sequence access by repository risk, not by seniority or enthusiasm.

Sort repositories into three risk tiers

• Tier 1, low risk. Internal tools, test suites, documentation sites, developer scripts, and prototypes. Mistakes are cheap and easy to roll back.
• Tier 2, moderate risk. Customer-facing services with solid test coverage, mature CI, and clear ownership.
• Tier 3, high risk. Payment flows, authentication, infrastructure-as-code, regulated data paths, and anything with thin test coverage.

Start the pilot in Tier 1\. Expand to Tier 2 once review metrics hold steady. Treat Tier 3 as a deliberate later decision with additional controls, not as an automatic next step.

Pick pilot teams for range, not just enthusiasm

A pilot staffed only with early adopters will produce glowing anecdotes and very little transferable learning. A stronger pilot includes at least one skeptical senior engineer, one newer engineer, and the engineering manager who will own the review process. Teams that apply enterprise design thinking to the pilot, treating engineers as the users whose real workflow the rollout must fit, tend to surface friction early, while it is still cheap to fix. For a primer on that approach, see Voltage Control’s guide to what enterprise design thinking is.

Set a defined pilot window

Give the pilot a fixed duration, commonly six to eight weeks, with a scheduled review at the end. Without a defined window, pilots drift into permanent semi-adoption and nobody ever makes the expansion decision on evidence.

Decision 2: Where Human Review Stays Mandatory

Review gates are where most Claude Code enterprise rollouts succeed or quietly fail. The agent can produce more change than a team has ever had to review. If review capacity does not scale with it, quality slips or the backlog grows.

Encode policy in managed settings

Organization-wide rules belong in managed settings, which Anthropic’s documentation describes as the right scope for “security policy and compliance requirements.” Typical managed policies include denying the agent read access to secrets files such as .env, restricting which shell commands it can run without asking, and limiting which models are available. Because managed settings cannot be overridden by developers, they give security and compliance teams a single place to verify the controls. The Claude Code permissions documentation explains the three rule types: allow (runs without asking), ask (prompts the developer), and deny (blocked). A sensible starting posture is narrow allow lists for routine commands like linting and tests, ask for anything that changes state outside the working tree, and deny for secrets and production credentials.

Encode team conventions in the repository

Each repository should carry a committed .claude/settings.json and a CLAUDE.md file that tells the agent how the codebase works: build commands, testing expectations, architectural boundaries, and naming conventions. These files make agent output more consistent and make review easier, because reviewers see changes that already follow house style.

Keep three review gates non-negotiable

1. Every agent-written change goes through a pull request. No direct pushes to protected branches, regardless of who prompted the agent.
2. A human who did not prompt the change approves it. The engineer who drove the session is the author, not the reviewer. This mirrors the separation most teams already apply to human-written code.
3. Tier 3 changes require a domain owner’s approval. Changes to authentication, payments, infrastructure, or regulated data paths need sign-off from someone accountable for that system.

The principle underneath all three: agent-written code should land exactly like any other contribution. It earns no shortcuts and faces no special suspicion. It goes through the same gates.

Decision 3: What to Measure

Vanity metrics are the most common trap in AI coding rollouts. Lines of code generated, number of sessions, and percentage of engineers with access all go up and to the right, and none of them say whether delivery improved. A stronger measurement set tracks flow, quality, and the review burden the tool creates. Baseline each metric for four to six weeks before the pilot starts so there is something to compare against.

Change failure rate and lead time for changes are two of the four classic DORA software delivery metrics, which makes them easy to explain to executives who already know that framework. Pairing them with review time and rework rate captures the specific risk of AI-assisted development: more code produced, but not necessarily more value delivered. Developer sentiment matters for a different reason. The METR study showed that perceived speed and measured speed can diverge. Collecting both lets leaders spot that gap instead of discovering it in a quarterly incident review.

Common Pitfalls in Claude Code Enterprise Rollouts

Engineering organizations tend to hit the same five problems:

1. Licensing before policy. Seats go out before managed settings exist, and security ends up retrofitting controls onto habits that have already formed.
2. Measuring adoption instead of outcomes. Dashboards show usage climbing while review time quietly doubles.
3. Skipping repository conventions. Without CLAUDE.md and shared settings, every engineer configures the agent differently and output quality varies wildly across the team.
4. Letting PR size balloon. An agent can touch forty files as easily as four. Large pull requests slow review and make defects harder to spot. Teams that set a soft limit on PR size keep review manageable.
5. Treating it as a tooling project. A rollout changes how engineers plan, review, and pair. Organizations that leave out the people side, such as working agreements, review norms, and team-level retrospectives, often see adoption stall after the first wave of enthusiasts.

Practical Steps for Getting Started

For a Director or VP of Engineering planning the first ninety days, a workable sequence looks like this.

Step 1: Baseline your delivery metrics

Pull four to six weeks of review time, change failure rate, rework rate, lead time, and PR size for the repositories in scope. Without a baseline, any later claim about impact is a guess.

Step 2: Write the managed policy with security

Agree on the deny list, the ask list, and the model allowlist with your security and compliance partners before anyone gets access. Deploy it as managed settings so it applies everywhere.

Step 3: Tier your repositories

Classify repositories into the three risk tiers and publish the list. Engineers should be able to look up whether a given repository is in scope.

Step 4: Launch a Tier 1 pilot with a mixed team

Choose two or three teams, include skeptics alongside enthusiasts, and commit CLAUDE.md plus shared settings to each pilot repository in week one.

Step 5: Run a structured mid-pilot retrospective

Around week three or four, bring pilot teams together to compare metrics against the baseline and share what is working. A facilitated session surfaces friction that never shows up in dashboards, like reviewers quietly rubber-stamping large agent PRs because they are overwhelmed.

Step 6: Make the expansion decision on evidence

At the end of the pilot window, decide whether to expand to Tier 2, extend the pilot, or adjust policy. Write the decision down along with the data behind it. That record is what you will show finance and security when they ask what the investment returned. For broader context on sequencing AI adoption across an organization, Voltage Control’s 2026 enterprise AI adoption roadmap covers the phases beyond engineering, and Govern AI Like You Hire offers a governance framework that pairs well with the review gates above. Teams rolling out Claude beyond engineering can also use how to roll out Claude across your company without losing control.

Bringing Your Engineering Org Along

A Claude Code enterprise rollout succeeds when engineers trust the guardrails, reviewers can keep up, and leaders can point to delivery metrics that moved in the right direction. The technology is ready. The harder work is the alignment: agreeing on access, review norms, and what success looks like, then giving teams a structured way to learn as they go. Voltage Control is a Claude Certified Solutions Partner that helps engineering and product organizations design and facilitate AI rollouts that stick, from pilot design to the working sessions that turn early results into team-wide practice. If you are planning a Claude Code rollout, book a free intro call with our facilitation team to talk through your plan.

The post Claude Code Enterprise Rollout Guide for Engineering Leaders appeared first on Voltage Control.

How to pick an enterprise AI assistant based on your data, workflows, and risk tolerance

The Copilot vs Claude question is usually framed as “which AI assistant is better?” For an enterprise, the more useful question is “which assistant fits how our data, workflows, and accountability already work?” Microsoft 365 Copilot is built to work inside the Microsoft 365 tenant your company already governs. Claude is a general-purpose AI assistant and model family from Anthropic that teams use across tools and clouds. Picking between them is less about benchmark scores and more about governance. Feature lists change every quarter. The governance questions behind the decision do not. This guide puts the two side by side on the points that hold up, then walks through a short decision process a leadership team can run before it signs a contract.

Copilot vs Claude at a glance

The table below compares the two on governance factors, not on model quality. Model quality shifts with every release. These factors shift much more slowly.

Neither column is a winner. Each one describes a different set of trade-offs that your IT, security, and business leaders have to agree on.

Why a feature comparison goes stale so fast

Most Copilot vs Claude articles line up context windows, model versions, and pricing tiers. That information has a short shelf life, and the line between the two products keeps blurring. Here is a concrete example. In September 2025, Microsoft announced that Anthropic’s Claude models would be available inside Microsoft 365 Copilot, starting with the Researcher agent and Copilot Studio, with admins opting in . The same post noted that the Anthropic models are hosted outside Microsoft-managed environments and are subject to Anthropic’s terms. So “Copilot or Claude” is not even a clean either/or anymore. A team can use Claude models through Copilot, Claude directly, or both. When the products overlap like this, the lasting decision is not “which model.” It is “which environment do we trust with which work, and under whose rules.”

The four governance questions that decide it

Every enterprise AI assistant decision comes down to four questions. Answer them honestly and the right choice usually becomes obvious.

1\. Where does your data already live?

Microsoft 365 Copilot’s biggest strength is that it works inside the Microsoft 365 boundary. Microsoft’s documentation states that Copilot “operates within the Microsoft 365 service boundary and honors the same data protection, access control, and compliance capabilities that apply across Microsoft 365,” and that it “can only summarize or reference content that the user is authorized to access.” If your email, documents, meeting notes, and intranet already sit in Microsoft 365, that is a real advantage. You are not standing up a new data environment. You are extending the one you already govern. Claude starts from a different place. It works with what users and admins choose to give it: uploaded documents, project knowledge, and integrations with tools like code repositories. Anthropic states for its enterprise offering, “We do not train Claude on your conversations and content.”. For organizations whose work spreads across Google Workspace, Slack, GitHub, data warehouses, and Microsoft 365 all at once, a tool that is not tied to one suite can be an advantage. The question to ask: is the work you want to improve mostly inside Microsoft 365, or does it cut across many systems?

2\. Which workflows will the assistant touch?

Daily productivity work and deep work are different jobs. Copilot is built for work that happens in the flow of Microsoft apps: summarizing a Teams meeting, drafting a reply in Outlook, building a first-pass deck from a Word document. The value comes from being right there, with no context switch. Claude tends to be chosen for longer, heavier tasks: analyzing a long contract set, drafting and revising complex documents, writing and reviewing code, or running multi-step agent workflows. Teams that pick Claude for these jobs usually care more about reasoning quality and long-document handling than about being embedded in email. List the five to ten workflows you most want AI to help with. Then sort them into “in the flow of Microsoft 365” and “deep work across systems.” The ratio tells you a lot.

3\. How much autonomy will you hand it?

An assistant that drafts a reply for a person to review is a different risk than an agent that takes actions on its own. As both Microsoft and Anthropic push further into agents, this question matters more every quarter. Decide up front what level of autonomy each workflow gets:

• Suggest only. The assistant drafts, a person decides and acts.
• Act with approval. The assistant prepares an action, and a person approves it before it runs.
• Act and report. The assistant acts within set limits and logs what it did for review.

Whichever tool you choose, the autonomy level should be a policy decision, not a default setting someone accepted during setup.

4\. Who owns the outcome when it gets something wrong?

This is the question most teams skip. When an AI assistant produces a wrong number in a board report or sends a poorly worded message to a customer, someone has to own that. Copilot’s accountability story leans on Microsoft Purview, where Microsoft says Copilot prompts, responses, and referenced content can be captured for auditing, eDiscovery, and retention. Claude’s enterprise plan provides role-based permissions, single sign-on, and activity logging that admins configure in the Claude workspace. The tooling matters less than the agreement behind it. A useful approach is to govern AI the way you already govern people: give each use a defined role, grant the least access it needs, onboard it deliberately, and name a human owner who answers for the result.

Which one for which situation

With those four questions answered, most organizations land in one of three places.

When Microsoft 365 Copilot is the better fit

• Most of your work happens in Outlook, Teams, Word, Excel, and SharePoint.
• Your Microsoft 365 permissions and sensitivity labels are in reasonable shape, or you are willing to clean them up first.
• Your main goal is broad, everyday productivity across a large workforce.
• Your security team wants one compliance stack, and that stack is Microsoft Purview.

When Claude is the better fit

• Your highest-value AI work is deep analysis, long-form writing, coding, or agent workflows.
• Your work spans many systems, not just one productivity suite.
• You want to give specific teams, such as engineering, research, legal, or strategy, a strong tool for heavy work.
• You are building AI into your own products or internal tools through an API.

When running both makes sense

Many organizations end up using both: Copilot for broad productivity inside Microsoft 365, and Claude for specific teams doing deeper work. That can be the right answer, but only if it is a deliberate choice. Running both without a plan doubles your governance surface. Running both with a plan means each tool has a clear job, a clear owner, and clear rules about what data goes where.

Common pitfalls teams hit

These are the five mistakes that show up most often when organizations make this decision.

1. Deploying Copilot on top of messy permissions. Because Copilot surfaces what each user can already access, years of overshared SharePoint sites and “anyone with the link” files suddenly become easy to find. Microsoft’s own guidance points admins to oversharing controls, sensitivity labels, and data loss prevention for this reason. Fix the permissions before the rollout, not after an incident.

2. Treating the choice as an IT purchase. If IT picks the tool alone, the business finds out what it got at rollout. If the business picks alone, security finds out at audit time. This decision needs IT, security, legal, and the business leaders whose teams will use it, in the same room.

3. Ignoring the tools people already use. Employees are not waiting for an official decision. In a WalkMe survey of 1,000 U.S. working adults who use AI on the job, 78% said they use AI tools not provided by their employer. If the approved tool does not fit the work, people will keep using the one that does, and that use stays invisible to you.

4. Standardizing too early, or too late. Mandating one tool for everyone before you understand the workflows creates workarounds. Waiting too long lets shadow AI harden into habit. A short, time-boxed pilot with clear decision criteria avoids both.

5. Comparing demos instead of real work. A vendor demo shows the best case. Test both tools on your own documents, your own workflows, and your own messy edge cases, with the people who will actually use them.

How to make the Copilot vs Claude decision: a five-step process

This process fits into two or three working sessions and gets the right people aligned before money changes hands.

Step 1: Map the work, not the tools

Have each participating team list the workflows where AI could save time or improve quality. Capture who does the work, what data it touches, and where that data lives. This becomes the foundation for every later step.

Step 2: Classify data and set the boundaries

For each workflow, label the data involved: public, internal, confidential, or restricted. Decide which classes each tool is allowed to touch. This is where security and legal earn their seat at the table, and it is far easier to do now than to unwind later.

Step 3: Set autonomy levels for each workflow

Using the suggest, approve, or act-and-report levels above, agree on how much independence the assistant gets for each workflow. Write it down. This becomes part of your AI usage policy.

Step 4: Run a side-by-side pilot on real tasks

Pick three to five representative workflows and run both tools against them for a set period, often two to four weeks. Score each on output quality, time saved, fit with existing tools, and how well it stayed inside your data boundaries. Include skeptics in the pilot group, not just enthusiasts.

Step 5: Decide, assign owners, and set a review date

Make the call: one tool, the other, or both with clear lanes. Name an owner for each tool and each high-risk workflow. Then set a review date, six months out is common, because both products will change, and your decision should get a regular check against reality.

The decision that lasts

The Copilot vs Claude debate will keep changing as both companies ship new models and features. The organizations that get this right are not the ones that pick the “best” model in any given month. They are the ones that answer the governance questions first: where the data lives, which work the assistant touches, how much autonomy it gets, and who owns the outcome. Get those answers on paper and either tool can succeed. Skip them and neither will. Voltage Control helps leadership teams run exactly this kind of decision: getting IT, security, legal, and the business aligned on how AI will be adopted and governed, before the contract is signed. If your team is weighing Copilot vs Claude, or trying to bring shadow AI into the open, book a free intro call with our facilitation team.

The post Copilot vs Claude Is a Governance Decision, Not a Feature Comparison appeared first on Voltage Control.

A buyer’s guide for leaders who need adoption, governance, and change, not just licenses.

Claude consulting is outside help for rolling out Anthropic’s Claude across an organization. That covers choosing use cases, setting governance, enabling teams, and measuring whether people actually change how they work. A strong engagement leaves your teams able to run Claude on their own. A weak one leaves you with seats, a kickoff deck, and a usage dashboard nobody checks. If you are a Director or VP evaluating partners, the hard part is that both kinds of firm use the same words. This guide breaks down what a real Claude consulting engagement should include, the signs you are talking to a reseller, and how to run a selection process that surfaces the difference early.

What Claude Consulting Actually Means

Most enterprise AI efforts do not fail because the model is weak. They stall because the organization around the model never changes. MIT Project NANDA’s The GenAI Divide: State of AI in Business 2025 reported that roughly 95 percent of enterprise generative AI pilots showed no measurable financial return (Healthcare IT News coverage, August 2025). The study is preliminary and not peer reviewed, built on 52 interviews, 153 survey responses, and a review of 300+ public initiatives, so treat the exact number with care. The direction matches what most leaders already see: access is easy, and adoption is hard. Claude consulting exists to close that gap. In plain terms, a Claude consultant helps you answer four questions:

1. Where should Claude do real work here? Which workflows, which teams, and in what order.
2. What are the rules? Data handling, acceptable use, human review, and who owns decisions about agents and integrations.
3. How do people get good at it? Not a single demo, but practice inside their actual work.
4. How will we know it is working? Baselines, measures, and a feedback loop that informs the next wave.

A reseller answers a fifth question, “How many licenses do you need?”, and stops there. That question matters. It is just the smallest of the five.

The 5 Components of a Real Claude Consulting Engagement

A credible Claude consulting engagement includes five components. Scope and duration vary, but if any of these is missing, ask why.

1\. Use-case discovery with the people doing the work

Good discovery happens in working sessions with frontline teams, not only in interviews with executives. The people who process the invoices, write the specs, or answer the support tickets know where the friction is. A partner should facilitate structured sessions where those teams map their workflows, identify where Claude could take on real tasks, and rank opportunities by value and feasibility. The output should be a short, prioritized list of use cases with owners, not a 60-slide inventory of every idea anyone mentioned.

2\. A governance model that fits how your teams operate

Governance is where many rollouts quietly break. Leaders are not confident here: Grant Thornton’s 2026 AI Impact Survey found 78 percent of business executives lacked confidence they could pass an independent AI governance audit within 90 days (Grant Thornton, April 2026). A real partner helps you define:

• Which data can and cannot go into Claude, and under which plan and settings
• Where a human must review output before it ships
• Who approves new agents, connectors, and integrations
• How usage and incidents get reported

The best governance models look less like a policy binder and more like an operating agreement teams helped write. When people shape the rules, they follow them.

3\. Hands-on enablement inside real workflows

Enablement means people practicing on their own work with someone who can coach them through it. Look for a partner who runs working sessions where a team brings a live task, such as a quarterly report, a code review, or a customer escalation, and leaves with it partly done in Claude and a repeatable approach. Ask how the partner builds internal capability. A strong answer includes identifying and developing internal champions who can carry the practice forward after the engagement ends.

4\. Change management and leadership alignment

Claude changes who does what. That raises questions about roles, workload, quality standards, and trust. A partner who skips this part is betting the technology will carry the change on its own. It rarely does. Real change work includes aligning the leadership team on why the organization is adopting Claude, what will be different for each function, and how leaders will talk about it with their teams. It also includes creating space for people to raise concerns early, before resistance goes underground.

5\. Measurement that goes beyond seat utilization

Login counts tell you who opened the tool. They do not tell you whether work got better. A credible partner sets a baseline before rollout and measures outcomes after, for example cycle time on a specific workflow, rework rates, time spent on low-value tasks, or employee confidence using AI on core work. The measures should be agreed up front and reviewed at set intervals, so the next wave of rollout is informed by evidence rather than enthusiasm.

Partner vs. Reseller: How to Tell the Difference

Many firms offer both licensing and services, and that is fine. The question is where their effort and incentives actually sit. This comparison helps you tell quickly.

A firm can sit somewhere in the middle. The point is to see which column their proposal leans toward.

6 Warning Signs You Are Talking to a Reseller

These six signals show up often in early sales conversations. One alone is not disqualifying. Three or more is a pattern.

1. The proposal is priced per seat with services as a line item. Services exist to move licenses, not outcomes.
2. Discovery is a questionnaire. No one plans to sit with your teams.
3. The governance deliverable is a document, not a process. You get a policy PDF and no plan for how decisions get made.
4. Enablement is a fixed number of webinars. Nobody asks what your teams actually do all day.
5. Success is defined as adoption rate. A line like “most seats are active” is a usage number, not a business result.
6. They cannot describe what happens after they leave. No champion network, no handoff plan, no internal owner.

The Consulting Mindset That Separates Partners From Vendors

The biggest difference is not the deliverable list. It is the consulting mindset behind it. A partner with a real consulting mindset starts from your problem and treats Claude as one of several tools to solve it. They will tell you when a use case is a bad fit, when a workflow needs redesign before AI touches it, and when your organization is not ready for the next wave yet. A vendor mindset starts from the product and works backward to your problem. That shows up in subtle ways: every answer leads to more usage, every risk gets framed as a feature, and the conversation stays on what Claude can do rather than what your people need. Ask a candidate partner to describe a time they recommended a client slow down or not use AI for something. A partner with the right mindset will have a specific answer. A reseller usually will not.

Common Pitfalls Teams Hit With Claude Consulting

Even with a good partner, teams tend to fall into four predictable traps.

Starting with tools instead of workflows

Teams buy access, then go looking for problems. The result is scattered, shallow use. Start with three to five workflows that matter, then decide what Claude should do in each.

Treating governance as a blocker to clear

If governance is something legal signs off on and then forgets, it will either be ignored or will freeze adoption. Treat it as a living operating model with a named owner and a regular review.

Running a pilot with no path to scale

A pilot that succeeds in one team often dies because nobody planned how to extend it. Before any pilot starts, define what success looks like, who decides to expand, and what the second team will be.

Outsourcing the change instead of building capability

If the consultant does all the facilitation, all the training, and all the measurement, the organization learns very little. The engagement should shift work to internal owners over time so the capability stays when the partner leaves.

How to Choose a Claude Consulting Partner: 5 Steps

Use this process to structure a selection and surface the partner versus reseller difference early.

Step 1: Define the outcomes you need

Write down two or three business outcomes you expect from Claude in the next six to twelve months, tied to specific workflows. This gives every candidate the same target and makes proposals comparable.

Step 2: Ask each candidate to describe their discovery process

Ask who they will talk to, how sessions run, and what comes out. Listen for facilitated sessions with frontline teams and a prioritized output. Be cautious if discovery is a survey or a single executive workshop.

Step 3: Request a sample governance artifact and process

Ask to see an anonymized governance model from a past engagement, and ask how it was built. You want evidence of decision rights, review points, and a process for approving new agents and integrations, not just an acceptable use policy.

Step 4: Probe how they build internal capability

Ask how they develop champions, what the handoff looks like, and what your team will be able to do without them at the end. A partner should be able to describe this in concrete terms.

Step 5: Agree on measures before you sign

Settle on two or three outcome measures and a baseline method before the engagement starts. If a candidate resists measuring anything beyond usage, that tells you where their incentives sit.

Questions to Ask in Your First Call

Bring these to the first conversation with any Claude consulting firm:

• What does the first 30 days of an engagement look like, week by week?
• Who from our organization needs to be involved, and how much of their time?
• How do you decide which use cases to start with?
• What does your governance work produce, and who owns it afterward?
• How do you measure success, and what baseline do you set?
• Tell us about a time you advised a client not to use AI for something.
• What does our team own when you leave?

The answers will tell you more than any capabilities deck.

Getting Started

The organizations getting real value from Claude are not the ones with the most seats. They are the ones that treated the rollout as an organizational change, with clear use cases, shared rules, hands-on practice, and honest measurement. The right consulting partner helps you do that and then steps back. If you are planning a Claude rollout and want a partner focused on how your teams work, not just what they license, Voltage Control can help. Voltage Control is a Certified Claude Partner that designs and facilitates AI transformation programs, from use-case discovery and governance design to team enablement and measurement. Book a free intro call with our facilitation team to talk through where you are and what a useful next step looks like.

The post What Claude Consulting Should Include, and How to Spot a Reseller appeared first on Voltage Control.

Why most rollouts stall after week one, and the team rituals that keep usage alive

Claude training is the work of helping a team build shared, repeatable habits for using Claude in real tasks, so that usage holds up after the launch excitement fades. Good Claude training teaches prompting, but it also changes team routines: who uses Claude for what, where good examples are kept, and how wins get shared. If your organization bought Claude seats and the usage dashboard spiked in week one and flattened by week three, the problem is rarely the tool or the people. It is usually the training model. This guide explains why one-time prompt workshops fade, what habit-based Claude training looks like, and how a team lead can set it up in the next 30 days.

What Claude Training Actually Means

Most organizations hear “Claude training” and picture a single session: an hour or two of prompt tips, a demo of Projects and Artifacts, maybe a shared slide deck of example prompts. That session has value. It gets people past the blank-page problem and shows them what the tool can do. But a session is an event, and adoption is a behavior. The gap between those two things is where most rollouts stall. A more useful definition treats Claude training as three layers working together:

1. Skill: individuals know how to give Claude context, iterate on output, and check results.
2. Habit: individuals reach for Claude at specific, predictable moments in their week without being reminded.
3. Team practice: the team shares what works, agrees on which tasks go to Claude first, and keeps a common library of prompts and Projects.

Prompt workshops cover the first layer. The second and third layers are where usage either sticks or disappears.

Why Claude Usage Drops After Week One

The week-one drop is predictable once you look at what a new habit requires. In a University College London study of everyday habit formation, participants who repeated a new daily behavior took an average of 66 days for it to become automatic, and the time varied widely by person and behavior (Lally et al., “How are habits formed: Modelling habit formation in the real world,” European Journal of Social Psychology, 2010; UCL summary). A one-hour workshop sits at day one of that curve. Nothing in the format carries people through the next nine weeks. Three patterns show up again and again when teams stall.

No trigger in the workflow

People leave training with skills but no cue for when to use them. On Monday morning they open the same tools, follow the same process, and Claude sits in a browser tab they forget about. Without a defined moment (“every first draft of a customer email starts in Claude”), the old workflow wins by default.

Private experiments, no shared learning

Early users discover good uses on their own and keep them to themselves. Not on purpose; there is simply no place to put them. Each person repeats the same trial and error, and the people who had a bad first experience never see the good examples their colleagues found.

Unclear permission

Many employees are not sure what they are allowed to put into Claude, whether using it on client work is acceptable, or whether their manager sees heavy use as a shortcut. Uncertainty pushes people toward the safest option, which is not using it at all. A clear usage policy helps, and the companion guide on rolling out Claude across your company without losing control covers that governance layer in detail. Training has to make the policy feel usable, not just available.

Prompt Training vs. Habit Training

The difference between the two approaches is easier to see side by side.

Neither column is wrong. Prompt skill is a prerequisite. The point is that prompt training alone rarely changes how work gets done, because the conditions for a habit are set by the team, not by the individual. This matches what broader research says about AI adoption. BCG argues that the gap between rising AI usage and flat business impact comes from treating AI as a technology deployment instead of focusing on how employees actually integrate it into their ways of working, and it names limited time to upskill as one of the most common barriers (BCG, “The AI Adoption Puzzle: Why Usage Is Up but Impact Is Not,” 2025). Prompt tips alone do not close that gap.

The 4 Team Habits That Make Claude Usage Stick

Habit-based Claude training is built around a small number of team rituals. These four do most of the work.

Habit 1: A first-move list

The team agrees on three to five specific tasks where Claude is the default first step. Examples: first drafts of status updates, summarizing customer call notes, turning meeting transcripts into action items, writing test cases from a spec, or reviewing a document for gaps before it goes to a stakeholder. The list has to be concrete. “Use Claude for writing” is too vague to change behavior. “Every weekly project update starts as a Claude draft from your notes” is a trigger people can act on.

Habit 2: A weekly show-and-tell

Fifteen minutes in an existing team meeting, where one or two people show something they did with Claude that week. It works best as a live demo, not a description: the prompt, the output, what they changed, and how long it took compared to before. This ritual does three things at once. It spreads good techniques faster than any training deck. It makes use visible and normal, which removes the “is this cheating” worry. And it gives hesitant team members a low-risk way to learn from peers instead of experimenting alone.

Habit 3: A living team library

Good prompts and setups need a home that the team owns. Claude Projects work well for this: a Project per recurring workflow, with the background documents, style guides, and instructions already loaded, so anyone on the team gets a strong starting point instead of a blank chat. Assign one person to curate it. Anything shown at the weekly show-and-tell that worked should land in the library within a day. Anything that no one has used in a month gets archived.

Habit 4: A monthly retro on what moved

Once a month, the team spends 30 minutes on three questions:

1. Which tasks have actually moved into Claude, and which are still done the old way?
2. Where did Claude output need heavy correction, and why?
3. What is the next task to add to the first-move list?

This keeps the practice growing instead of plateauing at the first few easy wins. It also surfaces quality problems early, before someone ships a confident but wrong Claude output to a customer.

Common Pitfalls in Claude Training

Teams that try to build these habits tend to run into the same five problems.

Training everyone at once

A company-wide session is efficient to schedule and weak at changing behavior. People sit with colleagues who do completely different work, so the examples feel generic. Train by team, using that team’s real tasks, even if it takes longer.

Measuring logins instead of tasks

Weekly active users is a useful early signal, but it does not show whether work has changed. A person who opens Claude daily to ask trivia questions counts the same as a person who moved their entire reporting workflow. Track which named tasks have moved, and ask people to estimate time returned.

Leaving the manager out

If the team lead does not use Claude visibly, the team reads that as a signal. Leaders do not need to be the most skilled users, but they should be at the show-and-tell, share their own attempts (including the failed ones), and ask about Claude use in one-on-ones.

Treating champions as unpaid help desks

Most rollouts identify early enthusiasts as champions, which is a good instinct. The pitfall is giving them the role without time or recognition. A champion who spends hours answering questions on top of a full workload burns out within a quarter. Protect a few hours a week for the role and make it visible to leadership.

Skipping the quality conversation

Teams that only celebrate speed eventually ship a Claude error that embarrasses someone. Build review norms into training from the start: what needs a human check, what a good check looks like, and when Claude output should not be used at all. The framework for safe Claude adoption offers a way to think about this as gradually extending trust rather than flipping a switch.

How to Start Claude Training for Your Team in 30 Days

A team lead can set up habit-based Claude training without a large program. Here is a practical sequence.

Step 1: Pick the team and the baseline (days 1 to 3\)

Start with one team of 5 to 12 people who do similar work. Before training, record a simple baseline: how many people use Claude in a typical week, and which tasks, if any, they use it for. A five-minute survey is enough.

Step 2: Map the candidate tasks (days 3 to 7\)

In a 45-minute working session, have the team list the recurring tasks that eat the most time each week. Then sort them: which ones involve drafting, summarizing, analyzing, or reviewing text or code? Those are the candidates. Pick three for the first-move list.

Step 3: Run a hands-on kickoff on real work (days 7 to 10\)

Replace the generic prompt workshop with a 90-minute session where each person completes one of the three chosen tasks in Claude, live, using their actual work. Set up the first shared Project during the session so the library exists from day one.

Step 4: Launch the weekly show-and-tell (week 2 onward)

Add 15 minutes to an existing team meeting. Ask for volunteers for the first two weeks, then rotate so everyone presents at least once in the first two months.

Step 5: Name a champion and protect their time (week 2\)

Choose someone who is curious and respected, not necessarily the most technical person. Give them ownership of the team library and a small, explicit time allocation.

Step 6: Hold the first retro and expand the list (day 30\)

At the end of the first month, run the retro described above. Compare usage and tasks moved against the baseline. Add one or two tasks to the first-move list and decide whether the next team is ready to start. After 30 days the team will not be finished. Habits take longer than that to settle. But the rituals will be in place, and the rituals are what carry people through the remaining weeks of the curve.

What Good Looks Like at 90 Days

By the end of the first quarter, a team with working Claude habits usually shows a few clear signs:

• Most of the team uses Claude in a typical week, for named tasks rather than ad hoc questions.
• The first-move list has grown from three tasks to six or more.
• The team library has active Projects that new hires use in their first week.
• The show-and-tell still happens, and people volunteer for it.
• Quality problems get caught in review and discussed in the retro, not discovered by customers.

If those signs are missing, the fix is usually to go back to the rituals, not to schedule another prompt workshop.

Get Help Building Claude Habits Across Your Teams

Moving from bought seats to changed work is a facilitation problem as much as a technology one. It takes well-run working sessions, honest retros, and leaders who model the behavior. Voltage Control is a Claude Certified Solutions Partner and helps organizations design and run the team rituals that turn Claude access into lasting practice, as part of its AI transformation program. If your Claude rollout has stalled after the first few weeks, book a free intro call with our facilitation team to talk through where your teams are and what would help them build the habit.

The post Claude Training for Teams That Builds Habits, Not Just Prompts appeared first on Voltage Control.

What It Takes to Lead an Organization Through the AI Shift

Most conversations about AI inside companies start with the technology: which model, which vendor, which use case. The ones that actually change how an organization works start somewhere else, with leadership. AI leadership is the discipline of guiding your people, your decisions, and your governance through a shift that touches almost every role at once. The tools are moving faster than any leadership team can keep up with, and that is precisely why the human side of the equation is where the advantage now lives. If you are a leader trying to make AI real across your company, this is the capability that decides whether it compounds or quietly stalls.

What is AI leadership?

AI leadership is the practice of leading an organization through AI adoption as a change to be managed, not a product to be bought. It means getting your leadership team fluent enough to make real decisions about AI, setting governance that lets people move safely, and building an operating rhythm that turns early experiments into how work actually gets done. The distinction matters because AI is not a departmental tool. It reshapes what people do day to day, what gets automated, what stays human-led, and who is accountable for the output. That makes it a leadership problem first and a technology problem second. A more capable model does not fix an adoption problem. If you drop better AI into an organization that has not changed its operating model, you get the same stalled result with a better logo.

Why does AI leadership matter more than the technology?

Because the technology is now the easy part. The models are extraordinary and widely available, which means the differentiator is no longer access, it is how well an organization absorbs the change. The companies pulling ahead are not the ones with the best tool. They are the ones whose leaders created a clear, sanctioned path for people to use AI well. When that leadership is missing, a familiar pattern sets in. Leaders buy the capability, security reacts by locking it down, and the people who would benefit most never get a clear way to use it. Innovation happens in isolated pockets that cannot scale, and everyone else either gives up or quietly turns to consumer AI in the shadows. The root cause is almost always the same: there is no clear path, so people improvise.

What AI leadership skills do executives actually need?

The hardest truth for most leadership teams is that they are, as one client put it, coaching a sport they have never played. You cannot direct AI well if you have never done the work with it yourself. The core AI leadership skills are less about technical depth and more about judgment:

• Fluency to decide. Enough hands-on understanding to call what to automate, what to augment with a human in the loop, and what stays human-led.
• Governance judgment. The ability to set boundaries that enable rather than just restrict, so adoption can move without creating risk.
• Change leadership. Naming the human stakes honestly, because people adopt AI faster when they trust that it is meant to make them more capable, not more replaceable.
• Prioritization. Choosing the few high-value use cases that prove the point, instead of spreading thin across dozens of experiments.

Fluency is the one leaders most often skip and most need. Direction without it produces vague mandates that teams cannot execute.

DELETE ME · AI photo · Google Gemini 3 Pro

What does a practical AI leadership framework look like?

We structure the work as Align, Build, Run. It is the same shape you would use to lead any significant organizational change, applied to AI.

Align: get leadership fluent and agreed

Change starts at the top. Before you roll anything out, your leaders need to be fluent enough to make real decisions, and they need to agree on the governance model and the roadmap so the whole team points the same direction. Alignment is what keeps a transformation from fracturing into competing pet projects.

Build: prove value with a scoped use case

Have your teams build department-level roadmaps and ship one tightly scoped, high-value use case. The goal is a win that is undeniable, so nobody can say “we are different.” People believe what they can see working in their own workflow far more than what they are told in a kickoff.

Run: install an operating rhythm

Roll out to the wider workforce with a real cadence, not a one-time training video. Certification, standing check-ins, a visible request path for new use cases, and ongoing enablement are what turn early energy into a durable habit. Adoption is a habit, not an event, and the Run phase is where most transformations either compound or quietly die.

How does governance fit into AI leadership?

Governance is what makes AI adoption safe enough to scale, and the most useful frame we have found is simple: govern AI like you hire. You already know how to bring a capable newcomer into your company responsibly. You give them a defined role, least-privilege access to the systems that role needs, an onboarding path, and an accountable owner. Do exactly that with AI. This is the move that earns trust with your security team, because it maps AI onto governance structures the business already understands. Strong AI leadership uses governance to say yes to adoption with clear boundaries, rather than defaulting to the reflexive no that kills momentum. For a deeper look at the operating side, see our guide to enterprise AI governance, and on the cultural side, why shadow AI happens when leadership leaves a vacuum.

How do you know your AI leadership is working?

Measure adoption and impact, not activity. License counts and login numbers tell you almost nothing. The signals that matter are whether real workflows have changed, whether your scoped use cases are delivering measurable value, whether leaders are making confident decisions about automation, and whether shadow AI is shrinking because the sanctioned path is now the easy one. The human metrics matter as much as the output. A healthy AI transformation leaves your team more fluent and more confident, not quietly worried about their relevance. If your people are getting more capable, your AI leadership is working. For the change-management discipline underneath this, see our framework for adopting AI-driven change management and how to lead AI business transformation without losing your team.

Getting started

AI leadership comes down to leading the human side of AI with the same rigor you bring to the technology. Get your leaders fluent and aligned, set a govern-like-you-hire policy, prove value with a scoped use case, and install an operating rhythm that keeps adoption alive. The tools will keep getting better on their own. The leadership is the part only you can provide, and it is where the return lives. Voltage Control helps leaders make AI stick, governance-first and facilitation-led. Book a discovery call to build the AI leadership capability your organization needs.

The post AI Leadership appeared first on Voltage Control.

What actually changes for your people, and the calls to make before anyone logs in.

Claude for business is Anthropic’s set of paid workplace plans for Claude, its AI assistant. The plans add shared workspaces, admin controls and organization-level data handling on top of the individual product. The question most leaders actually face is not “should we buy it” but “what has to be true about our team before we turn it on,” because the license is the easy part and the team change is the hard part. This guide is for directors and VPs who have been handed a Claude rollout and want to get it right the first time. It covers what Claude for business changes inside a team, the five decisions to make before anyone logs in, the pitfalls that show up when those decisions get skipped, and a practical 30-day start.

What Claude for Business Actually Is

At the plan level, Claude for business means the Team and Enterprise plans rather than individual Pro subscriptions. Individual accounts are owned by the person. Business plans are owned by the organization, which is the difference that matters most for a leader. In practical terms, an organization-owned plan gives a company three things an individual account does not:

1. Central administration. Someone inside the company controls who has access, which features are on, and what happens when a person leaves.
2. Shared context. Teams can build shared projects, reference documents and instructions that everyone on the team works from, instead of each person rebuilding the same context in a private chat.
3. Organizational data terms. Business plans come with commercial terms for how company data is handled, which is usually the first thing legal and security will ask about.

That is the definition. The more useful question is what those three things change about how a team works.

Why It Is a Team Decision, Not a License Purchase

Most AI rollouts are run like software procurement. Someone negotiates seats, IT provisions accounts, a launch email goes out, and the rollout is declared done. Usage climbs for a few weeks, then plateaus with a handful of enthusiasts and a long tail of people who tried it twice. The research on this pattern is consistent. Faros AI studied more than 10,000 developers across 1,255 teams and found that heavy AI users completed 21% more tasks, but the gains did not show up at the company level in throughput or quality metrics (Faros AI, The AI Productivity Paradox, 2025). BCG reached a similar conclusion from the other direction: in its 2025 research, only about 25% of leaders reported significant value from AI, and BCG attributes roughly 70% of AI success to people and processes, 20% to technology infrastructure and only 10% to the algorithms themselves (BCG, The AI Adoption Puzzle, 2025). Read together, those findings point at the same gap. Individual productivity goes up. Team output does not, because the work still moves through handoffs, reviews and decisions that nobody redesigned. Claude for business is built for shared use, which means the value is mostly locked inside the team decisions that come with it.

What Changes for a Team When Claude Turns On

Before deciding anything, it helps to name what actually shifts. Four changes show up in almost every team.

Context becomes a shared asset

With individual accounts, each person teaches the assistant about the product, the customer and the house style, then loses that work when the chat ends. Shared projects turn that context into something the team maintains together. That is a real gain, and it creates a new job: someone has to keep the shared context accurate. Stale instructions in a shared project quietly make everyone’s output worse.

Handoffs change shape

When one person can draft a spec, a customer email or an analysis in minutes, the bottleneck moves to whoever reviews it. Teams that do not plan for this see review queues grow while drafting speeds up, which is the same pattern Faros measured in engineering teams. The handoff, not the draft, becomes the place to design.

Ownership gets blurry

If Claude drafted the first version, a teammate edited it and a manager approved it, who owns the result? Teams need a simple, shared answer: the person who sends or ships the work owns it, regardless of how it was produced. Without that answer, quality problems become nobody’s problem.

Skill gaps widen before they close

Early adopters pull ahead fast. Without a deliberate way for the team to learn together, the gap between the most fluent and least fluent person grows in the first few months, and the less fluent people quietly stop trying. This is the change most rollouts underestimate.

License Purchase vs Team Decision: A Side-by-Side

The difference between the two approaches is easiest to see in a table.

Most organizations need both columns. Procurement still has to happen. The point is that the right column is where the return comes from.

5 Decisions to Make Before Anyone Logs In

These five decisions are the core of a Claude for business rollout. Each one is quick to make and expensive to skip.

Step 1: Set data boundaries in plain language

Decide what kinds of information people may bring into Claude and what stays out. Write it as a short list people will actually remember, for example: customer names yes, customer payment data no, unreleased financials only in the finance project. A one-page policy beats a twenty-page one nobody reads. For a fuller template, see Govern AI like you hire: a framework for safe Claude adoption.

Step 2: Pick two or three starting workflows

Choose a small number of specific, recurring workflows rather than “use it for everything.” Good candidates are frequent, text-heavy and currently slow: drafting first versions of customer responses, summarizing research or interviews, turning meeting notes into decisions and owners. Name the workflow, the team and the person accountable for it.

Step 3: Assign owners for shared projects and instructions

Every shared project needs a named owner who keeps its reference material and instructions current. Treat this like owning a shared document or a team wiki page. It is a small job, and leaving it unassigned is the fastest way for shared context to rot.

Step 4: Decide how review works

Agree on what gets reviewed, by whom and how fast, before drafting speeds up. Some work can ship with a light check. Some needs the same review it always had. Making that call up front keeps review queues from becoming the new bottleneck.

Step 5: Build a habit for learning together

Put a recurring, short slot on the calendar where the team shares what worked, what failed and what they changed in a shared project. Thirty minutes every two weeks is enough. This is the step that closes the skill gap instead of widening it, and it is the one most likely to be cut when calendars get busy.

Common Pitfalls Teams Hit

The same four pitfalls show up again and again when the decisions above get skipped.

1. Shadow workflows. People keep using personal accounts for real work because the company setup feels slower or more restricted. The organization then has paid seats and an unmanaged data problem at the same time. Clear data boundaries and a genuinely useful shared setup are the fix, not tighter blocking.

2. Usage as the success metric. Weekly active users is easy to report and says very little. A team can have high usage and no change in how fast or how well work gets done. Measure the specific workflows chosen in Step 2 instead.

3. Everyone, everywhere, all at once. A company-wide launch with no starting workflows spreads attention thin. People try it on whatever is in front of them, get mixed results and decide it is not for their job. Starting narrow produces visible wins that the rest of the organization can copy.

4. No owner for the change itself. IT owns the tool. Legal owns the policy. Nobody owns how the team’s work actually changes. Without a named leader for that, the rollout stalls at “available” and never reaches “useful.”

Claude for Teams: A Practical First 30 Days

For a leader starting with a single team, a simple 30-day plan keeps the rollout grounded.

Week 1: Decide. Make the five decisions above with the team, not for it. A 90-minute working session is usually enough. The output is a one-page agreement covering data boundaries, starting workflows, project owners, review rules and the learning cadence.

Week 2: Set up. Build the shared projects for the chosen workflows, load the reference material and write the first version of the instructions. Have each project owner run a few real tasks through it and adjust.

Week 3: Run. The team uses Claude on the starting workflows as part of normal work. Keep a simple running note of what helped, what produced bad output and where review slowed things down.

Week 4: Review and adjust. Hold the first learning session. Look at the running notes, compare cycle time and quality against how the workflow ran before, and decide what to change, expand or drop. Then pick the next workflow. For the broader company rollout that follows a successful first team, including sequencing across departments and admin setup, see How to roll out Claude across your company without losing control.

Frequently Asked Questions

Is Claude for business different from a personal Claude account?

Yes. Business plans are owned and administered by the organization, support shared projects across a team and come with commercial data terms. Personal accounts belong to the individual, which leaves the company with no visibility or control over how work data is used.

Who should own a Claude for business rollout?

A business leader should own how the team’s work changes, with IT and security as partners on access and data. When IT owns the whole rollout, it tends to stop at provisioning.

How do you measure whether Claude for business is working?

Measure cycle time and quality on a few specific workflows chosen before launch. Usage numbers are a useful early signal, but they do not show whether work is getting faster or better.

Do teams need training before using Claude for enterprise work?

A short orientation helps, but the bigger factor is regular practice on real work with the team. A recurring session where people share what worked tends to build fluency faster than one-time instruction.

Make the Rollout a Team Change, Not a Tool Launch

Claude for business pays off when a team decides together how its work will change: what data goes in, which workflows come first, who owns shared context, how review works and how everyone keeps learning. Those decisions take days, not months, and they are the difference between paid seats and better work. Voltage Control helps leadership teams design and facilitate exactly these decisions as part of our AI transformation program. If you are about to turn Claude on for your team, book a free intro call with our facilitation team and we will help you plan the first 30 days.

The post Claude for Business Is a Team Decision, Not a License Purchase appeared first on Voltage Control.

How to decide where people approve AI work and where they supervise it

Should a person approve every action your AI system takes, or only watch it and step in when something looks wrong? That is the whole human in the loop vs human on the loop question, and the answer decides how fast your AI work moves and how much risk it carries. Human in the loop (HITL) means a person must approve an AI system’s output before it takes effect. Human on the loop (HOTL) means the AI system acts on its own while a person monitors it and keeps the power to intervene, override, or stop it. The difference is when the human judgment happens: before the action, or alongside and after it.

Where the terms come from

The vocabulary comes from debates about autonomous weapons, not office software. A 2012 Human Rights Watch report sorted robotic systems into three groups: human-in-the-loop systems that act only on a human command, human-on-the-loop systems that act under the oversight of a human operator who can override them, and human-out-of-the-loop systems that act with no human input at all. The same report made a point that matters for any business deploying AI agents: an on-the-loop system with supervision so limited that nobody can realistically intervene is, in practice, out of the loop. A name on an oversight chart is not oversight. A person who can actually see, understand, and stop the system is. Today the terms show up in AI governance policies, vendor documentation, and regulation. They are a useful shorthand for a human AI collaboration model, meaning the agreed rules for which decisions people make, which decisions AI makes, and how the two hand off.

Human in the loop vs human on the loop: side-by-side comparison

Neither model is “safer” in the abstract. Each one fails in a predictable way, and the job of a leader is to pick the failure mode the organization can live with for each specific decision.

What human in the loop actually requires

Human in the loop sounds like the cautious choice, and for many decisions it is. It also has a cost that shows up quickly once AI output volume grows.

Reviewers need time and context

An approval step only protects you if the approver has enough time and context to say no. When a reviewer receives dozens of AI drafts a day, review quality drops. Research on automation has documented this for years: people who monitor reliable automated systems tend to become complacent and over-trust the system’s output, a pattern known as automation bias. The EU AI Act names this risk directly. Article 14, the human oversight article for high-risk AI systems, requires that the people assigned to oversight remain aware of “the possible tendency of automatically relying or over-relying on the output” of the system.

The bottleneck moves to people

The second cost is throughput. If every AI action waits for a human approval, the AI can only go as fast as the slowest reviewer. Teams that put a human in the loop on everything often find that the AI saved effort in drafting and then lost it all in an approval queue.

When it is worth it

Human in the loop earns its cost when a mistake is expensive, public, or hard to undo. Customer-facing commitments, legal and financial actions, and decisions about people (hiring, performance, compensation) usually belong here.

What human on the loop actually requires

Human on the loop is not “let the AI run.” It is a different kind of control, and it needs real infrastructure to work.

Visibility into what the system is doing

A supervisor can only intervene in what they can see. That means logs of AI actions, dashboards or digests that surface unusual activity, and alerts that reach a person who knows what to do with them.

A real way to stop it

Article 14 of the EU AI Act lists the abilities oversight should give a person, including the ability to “disregard, override or reverse the output” of the system and to “interrupt the system through a ‘stop’ button or a similar procedure.” Even for systems the Act does not classify as high-risk, that list is a practical checklist for any on-the-loop setup. If nobody can pause the agent, nobody is on the loop.

Reversibility

On-the-loop oversight assumes that some mistakes will get through and be caught after the fact. That only works when those mistakes can be undone. Drafts, internal tags, and routing decisions are easy to reverse. A sent email to 5,000 customers is not.

Which one for which situation

Most organizations need both models, applied decision by decision rather than system by system. Three questions sort nearly every AI-assisted decision into the right bucket.

Question 1: Can the action be reversed cheaply?

If the AI’s action can be undone in minutes with no lasting harm, it is a candidate for human on the loop. If undoing it requires an apology, a refund, a legal review, or a correction notice, keep a human in the loop.

Question 2: How far does a mistake spread?

Call this the blast radius. A mistake that affects one internal document is small. A mistake that reaches customers, regulators, or the public is large. The larger the blast radius, the stronger the case for approval before action.

Question 3: What is this system’s track record on this task?

New AI workflows have no history. Before you have seen how a system behaves on a task, you have no basis for trusting it on that task. As the system builds a record of accurate work, the case for moving from approval to supervision grows. A simple way to apply all three:

Govern AI like you would onboard a new hire

The third question is where most governance policies go wrong. They set an oversight level once and never revisit it. Think about how a manager treats a new hire. In the first weeks, the manager reviews their work before it goes out. As the new hire proves reliable on specific tasks, the manager stops checking every draft and starts spot-checking. Eventually the person owns those tasks outright, and the manager only hears about exceptions. Nobody would call that reckless. It is how trust is earned at work. A good human AI collaboration model follows the same arc. A new AI workflow starts with a human in the loop. When it has a measured record of accurate output on a defined task, it moves to human on the loop for that task, with sampling review. The promotion is task by task, not system by system, and it can be reversed if quality drops. Voltage Control has heard a version of this shift in its 2026 executive dinners across several cities. Leaders described their own role moving from reviewing every AI output to supervising AI work the way they supervise a team. Several noted that the change felt less like adopting a tool and more like becoming a manager. That is a Voltage Control observation from facilitated conversations, not a survey finding, but it matches the pattern the in-the-loop to on-the-loop framework predicts.

Common pitfalls teams hit

Pitfall 1: One rule for everything

Choosing “human in the loop for all AI” or “human on the loop for all AI” is easy to write in a policy and wrong in practice. It either drowns reviewers or under-protects the decisions that matter. Oversight should be set per decision type.

Pitfall 2: Approval without capacity

Adding an approval step without giving the approver time, context, or authority to reject creates the appearance of control without the substance. If a reviewer approves 100 percent of what they see, check whether they are actually reviewing.

Pitfall 3: Supervision without signals

Moving to human on the loop without logs, alerts, or a stop mechanism is the “effectively out of the loop” problem from the original Human Rights Watch framing. If the supervisor would not know something went wrong until a customer complained, the system is not supervised.

Pitfall 4: Never promoting, never demoting

Oversight levels that never change waste reviewer time on proven tasks and leave no response plan when a model update degrades quality. Put a review date on every oversight decision.

Pitfall 5: Treating it as a technical decision only

Oversight rules change people’s jobs. A reviewer who becomes a supervisor has a different role, different skills to build, and often different feelings about the work. Leaders who make the switch without talking to the people affected tend to get quiet resistance instead of real oversight.

Practical steps for a leader getting started

Step 1: List the decisions, not the tools

Write down the specific decisions AI is making or drafting in your area: “drafts customer replies,” “categorizes support tickets,” “proposes sprint priorities.” Oversight attaches to decisions, not to products.

Step 2: Score each decision on the three questions

For each decision, record whether it is reversible, how large the blast radius is, and how much track record the system has on it. Use the table above to assign a starting model.

Step 3: Name the human for each decision

Every decision needs a named owner, whether that person approves or supervises. “The team” is not an owner. Confirm that the owner has the time and the authority to say no.

Step 4: Build the on-the-loop basics before you need them

For anything set to human on the loop, confirm there is a log of actions, a way to surface anomalies, and a tested way to pause or reverse the system. NIST’s AI Risk Management Framework treats this kind of ongoing monitoring and response planning as part of governing AI risk across the system’s life, not a one-time check.

Step 5: Set promotion and demotion criteria

Decide in advance what evidence moves a decision from in the loop to on the loop, such as a set number of reviewed outputs with no significant corrections. Decide what moves it back, such as a quality drop or a model change.

Step 6: Review on a schedule

Revisit the full list quarterly with the people doing the reviewing and supervising. They will know before anyone else which approvals have become rubber stamps and which supervised tasks need a closer look.

The bottom line

Human in the loop and human on the loop are not competing philosophies. They are two settings on the same dial, and the right setting depends on the decision, its consequences, and how much the system has earned your trust on it. The organizations that get AI governance right treat that dial the way good managers treat delegation: start close, step back as trust is earned, and step back in when something changes. Getting there is as much a people problem as a policy problem. Deciding who owns which decisions, and getting reviewers, supervisors, and leaders to agree on the rules, takes structured conversation. If your team is working through how to set up a human AI collaboration model that people will actually follow, book a free intro call with Voltage Control’s facilitation team. For more on how roles are shifting as AI takes on execution work, see what human-AI collaboration looks like in practice and The New Friction.

The post Human in the Loop vs Human on the Loop in AI Governance appeared first on Voltage Control.

Govern AI like a new hire, moving from unsupervised experiments to earned autonomy in five stages

Where does your organization actually stand on AI governance, and what has to change to get to the next level? An AI governance maturity model answers that question by describing the stages an organization moves through, from scattered, unsupervised AI use to a system where each AI tool or agent has a defined role, a named owner, and autonomy it has earned through performance. A maturity model is not a policy or a framework you adopt. It is a diagnostic. It gives leadership teams a shared language for where they are today, which makes it far easier to agree on what to fix first.

Why AI Governance Needs a Maturity Model Now

The gap between AI adoption and AI oversight is widening, and most leaders can feel it even when they cannot measure it. Three public data points show the shape of the problem:

• Confidence is low. In Grant Thornton’s 2026 AI Impact Survey of roughly 1,000 US senior leaders, 78 percent lacked full confidence that their organization could pass an independent AI governance audit.
• Confidence is also misplaced. In an August 2026 survey of 202 IT and security leaders at large enterprises, 94 percent said they were confident their AI agents did not have more access than they needed. Only 33 percent actually provisioned agents with least-privilege access, and 65 percent had already seen an agent act outside its intended scope.
• The volume is about to jump. Gartner predicts that 40 percent of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5 percent in 2025\.

Gartner also predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. Two of those three reasons are governance problems. Without a maturity model, governance conversations tend to collapse into two unhelpful positions: “we have a policy, so we’re fine” or “we’re nowhere, so we need a big program.” A maturity model replaces both with a more useful question: which stage are we in, and what is the one move that gets us to the next one?

The Hiring Lens: Govern AI Like a New Hire

Most AI governance maturity models borrow their stage names from software process models (initial, repeatable, defined, managed, optimizing). Those names are accurate but abstract. Leaders nod at them and then struggle to say what “managed” looks like on a Tuesday. A more practical lens is one every manager already knows: hiring. Organizations have a well-tested system for bringing in capable, unproven newcomers. A new hire gets a job description, access scoped to the role, a manager who reviews their work, and more responsibility as they prove themselves. Nobody gets admin rights to the finance system on day one. The same logic applies to AI tools and agents, and it is the core of Govern AI Like You Hire. Seen through that lens, AI governance maturity is really a measure of how well your organization onboards, supervises, and promotes its AI systems. It also keeps accountability where it belongs. An agent can have a role, but a named person stays responsible for its work, a point made sharply in AI Is Not a Legal Shield.

The 5 Dimensions an AI Governance Maturity Model Measures

Before looking at the stages, it helps to know what is being measured. This model scores an organization on five dimensions, each with a direct hiring parallel:

1. Inventory: Do you know which AI tools and agents are in use? (Do you know who works here?)
2. Role definition: Does each AI system have a written purpose, scope, and escalation rule? (Does each person have a job description?)
3. Access: Are permissions scoped to the task, or granted for convenience? (Did the new analyst get the access the job needs, or everything?)
4. Ownership and review: Is a named human accountable for each system’s output, with a regular review? (Does every new hire have a manager?)
5. Learning: Do incidents and wins change the rules, and does autonomy expand or contract based on evidence? (Do people get promoted, coached, or reassigned based on performance?)

The 5 Stages of AI Governance Maturity

Here is the model at a glance. Most organizations are not at a single stage across all five dimensions, and that unevenness is itself a useful finding.

Stage 1: Unsupervised

AI is in the building, but nobody can say exactly where. Teams sign up for tools on their own, connect them to whatever data is easiest, and share prompts in chat threads. Signals you’re here: Leadership cannot produce a list of AI tools in use. Security learns about new tools from expense reports. People use personal accounts for work tasks. Microsoft and LinkedIn’s 2024 Work Trend Index found that 78 percent of AI users were bringing their own AI tools to work, which is what Stage 1 looks like at scale. The move to Stage 2: Find out what is actually being used. An anonymous, no-penalty survey surfaces more than an audit, because people will tell you about tools they are not afraid to lose.

Stage 2: Policy on Paper

An acceptable use policy exists. It lists approved and banned tools and probably went out in an all-hands email. But it is a document, not a practice. Nobody checks it, and nobody owns the outcomes of the tools it approves. Signals you’re here: The policy is more than six months old. It talks about tools but not agents. Approval requests sit in a queue for weeks, so people work around them. Governance mostly shows up as “no.” The move to Stage 3: Shift from rules about tools to roles for systems. Pick the five highest-impact AI uses and write a one-page role description for each: what outcome it owns, which systems it can touch, which human owns its work, and when it escalates instead of acting.

Stage 3: Onboarded

Every AI system in meaningful use has the equivalent of a job description and a manager. There is a maintained register. Access is scoped to the task. When something goes wrong, someone can say whether the system did what it was supposed to do, because someone wrote down what it was supposed to do. Signals you’re here: You can answer “who owns this agent?” for any system in under a minute. New AI requests go through a defined intake path. Least privilege is the default rather than the exception. The move to Stage 4: Add a review rhythm. Onboarding without supervision decays quickly, because roles drift, access accumulates, and owners change jobs.

Stage 4: Supervised

AI systems get regular performance reviews, just like people do in their first year. Owners look at output quality, error patterns, and scope creep on a set schedule. Access is reviewed and pruned. Incidents are logged and, more importantly, change the rules. Signals you’re here: There is a standing cross-functional forum (not a one-time committee) that reviews AI performance and policy together. Review findings regularly lead to role or access changes. Teams treat the review as useful rather than as paperwork. The move to Stage 5: Connect review results to autonomy decisions. If a system has performed reliably for two quarters, what does it earn? If it has not, what does it lose?

Stage 5: Earned Autonomy

Governance has become the thing that lets the organization move faster. Low-risk systems with a strong track record get more scope and lighter review. High-risk systems keep a human in the loop. Autonomy is something a system earns through evidence, the same way a strong performer earns a bigger role. Signals you’re here: Teams ask governance for help instead of avoiding it. Risk tiers drive review effort, so the fast path really is fast. Leaders can point to specific cases where an AI system was given more scope, and specific cases where scope was pulled back. Stage 5 is not a finish line. New models, new agents, and new regulations reset parts of the picture, which is why the learning dimension matters most.

How to Assess Your Organization’s AI Governance Maturity

A maturity assessment works best as a facilitated working session, not a survey filled out by one person in compliance. The goal is a shared, honest picture, and the most valuable output is often the disagreement between functions. This is where human AI collaboration gets real: the people closest to the work know where the AI actually is.

Step 1: Invite the right cross-functional group

Bring together 6 to 10 people: an executive sponsor, someone from IT or security, legal or compliance, two or three business owners whose teams use AI heavily, and whoever is acting as AI transformation lead. If people only hear about governance from one function, they will assume it belongs to that function.

Step 2: Score each dimension independently first

Have each participant silently score the five dimensions from 1 to 5 before any discussion. Silent scoring prevents the most senior voice in the room from anchoring everyone else, a technique borrowed from the same design thinking model facilitators use to separate idea generation from judgment.

Step 3: Reveal and discuss the gaps

Put the scores side by side. Where security scores access a 2 and a business owner scores it a 4, you have found something important. Spend most of the session on the largest gaps, not on the averages.

Step 4: Agree on one stage per dimension

Converge on a single stage for each dimension. Expect an uneven profile, such as Stage 3 for inventory and Stage 1 for learning. That shape tells you more than a single overall score would.

Step 5: Pick the next move, not the end state

Choose one or two moves that advance the weakest dimension by a single stage within 90 days. Assign an owner and a date. Then schedule the next assessment for one quarter out.

Common Pitfalls When Using an AI Governance Maturity Model

Treating the model as a scorecard. If teams are rewarded for higher scores, they will inflate them. The model is useful only if people are honest about where they are.

Jumping stages. Organizations at Stage 1 often try to build a Stage 5 system with risk tiers, automated monitoring, and a full council before they know what tools are in use. That effort usually stalls. Move one stage at a time.

Confusing a policy with maturity. Writing an acceptable use policy moves an organization from Stage 1 to Stage 2 at most. It does not create owners, scoped access, or reviews.

Governing tools instead of systems. “Is ChatGPT approved?” is a Stage 2 question. “What is this agent allowed to do, and who owns its output?” is a Stage 3 question. Agents are where the access and accountability risks are concentrated.

Leaving it to one function. When governance lives only in legal or security, it tends to become a brake. When it is shared, it tends to become an enabler.

Where Established Frameworks Fit

A maturity model complements, rather than replaces, the major frameworks. The NIST AI Risk Management Framework, released in January 2023, organizes AI risk work into four functions: Govern, Map, Measure, and Manage. ISO/IEC 42001, published in December 2023, specifies requirements for an AI management system that organizations can be certified against. Those frameworks describe what a mature system should contain. A maturity model tells you how far you are from it and what to do next. Many organizations use NIST or ISO 42001 as the target and a maturity assessment as the quarterly progress check. For the structures that sit underneath a Stage 4 or 5 organization, such as decision rights, intake paths, and standing forums, see our companion piece on building an enterprise AI governance operating model.

Frequently Asked Questions

What is an AI governance maturity model?

An AI governance maturity model is a staged framework that describes how an organization’s oversight of AI evolves, from unmanaged use to a system where every AI tool or agent has a defined role, scoped access, a named owner, and autonomy based on its track record. It is used to diagnose current state and choose the next improvement.

How many stages should an AI governance maturity model have?

Most models use four or five stages. Five stages, as in this model, give enough resolution to see real progress quarter over quarter without becoming so granular that teams argue about the difference between neighboring stages.

How often should we reassess AI governance maturity?

Quarterly is a good default. AI adoption moves fast enough that an annual assessment is out of date before the next one, and quarterly matches the review rhythm a Stage 4 organization should already be running.

Who should own the AI governance maturity assessment?

An executive sponsor should own the outcome, and an AI transformation leader or a neutral facilitator should run the session. Ownership by a single function such as legal or IT tends to skew the scores toward that function’s view.

Do we need an AI transformation consultant to run this?

Not necessarily. Any organization can run the five-step assessment above. An outside AI transformation consultant or facilitator is most useful when functions disagree sharply or when the most senior people in the room would otherwise dominate the scoring.

Find Your Gaps and Pick Your Next Move

An AI governance maturity model is only as useful as the conversation it starts. The point is not to reach Stage 5 on paper. It is to get the right people in a room, agree honestly on where you stand, and leave with one concrete move and an owner. Voltage Control helps leadership teams run exactly these working sessions as part of our AI transformation program, designing the human AI collaboration practices that let governance speed adoption instead of slowing it. If you want help assessing where your organization stands, book a free intro call with our facilitation team.

The post How to Use an AI Governance Maturity Model to Find Your Gaps appeared first on Voltage Control.