Why AI Output Metrics Mislead and What to Track Instead

Sixteen experienced software developers sat down to work. They had access to the best AI coding tools available. They had been told, reasonably, to expect a 20 to 25 percent productivity boost. When the study ended, they believed, on average, that AI had made them 20 percent faster. They were 19 percent slower. That is from METR’s July 2025 randomized controlled trial, the most rigorous study of AI’s effect on experienced developer productivity published to date. The 39-point gap between what developers believed about their performance and what actually happened is not a rounding error. It is a measurement failure at scale. And it should be the first thing any executive reads before reviewing their organization’s AI productivity numbers.

The Metrics We Default To

Most organizations are measuring the wrong things. Not because their teams are careless, but because the wrong things are easy to count. Tokens consumed. Lines of code generated. Pull requests merged. Tool adoption rates. Story points completed. Time-to-first-response in customer service queues. Meeting transcripts enabled. These are the metrics that appear on AI dashboards across the enterprise right now. Every one of them produces a number. Every one of them trends over time. Every one of them can be presented in a board slide. None of them tell you whether your AI transformation is creating value. This is output accounting. It measures what happened: how much AI was used, how many tasks were touched, and how fast certain activities were completed. It does not measure whether the right things happened, whether the quality of work improved, or whether the organization can now do anything it could not do before. The appeal is understandable. Output metrics are fast, cheap, and unambiguous. In a transformation that feels uncertain and fast-moving, the comfort of a trending dashboard is real. That comfort is the problem.

When Output Metrics Lie

The clearest proof is Klarna. In 2024, Klarna announced that AI had replaced approximately 700 customer service agents. By Q3 2025, the company claimed its AI agent was doing the work of 853 full-time employees and saving $60 million annually. The volume metrics looked excellent: faster resolution times, higher tickets-per-hour throughput, and lower cost-per-interaction. Then, quietly, in early 2026, Klarna began rehiring humans. What the output metrics had not captured was quality deterioration on complex interactions. Customer satisfaction scores on difficult cases had declined. The conversations that mattered most, the ones where customers were frustrated and needed real understanding, were getting worse. The metrics that declared success had optimized for speed in the cases where speed was least important. Klarna’s reversal is not a story about AI failing. It is a story about measurement failing. The organization tracked what was easy to track. The things that were hard to track, judgment quality on complex cases, customer trust in sensitive interactions, brand perception over time, deteriorated while the dashboard numbers climbed. This is not unique to Klarna. It is the predictable outcome of any measurement system that optimizes for outputs rather than outcomes.

The Counter-Signal Nobody Expected

Triumph Financial runs one of the largest payment networks in trucking, moving roughly $18 billion a year to carriers who often wait up to 90 days to get paid by brokers and shippers. In 2023, working with KUNGFU.AI, the company set out to speed up invoice funding with AI. It would have been easy to make speed the headline metric. Triumph didn’t.

Earlier attempts at automation, using rigid, hard-coded rules, had already failed once, rejecting too many good invoices to be useful. So this time, before anyone touted a faster approval time, the team agreed on three specific numbers to watch: disputed invoices, short pays, and write-offs. Not throughput. Not approval speed. The things that would reveal whether the model’s decisions were actually as good as a human’s, not just faster than one. Those numbers were put on a shared dashboard everyone could see, and the model wasn’t scaled up until a staged rollout, moving from historical data testing to a dark launch to a 100-day pilot, showed it held up.

Only after that did the speed numbers get to matter. And they mattered a great deal: invoice approval time fell from an average of 178 minutes to about 10 seconds, with more than $4 billion in invoices now running through the model and over half auto-approved. But the figures Triumph’s CTO Jason Heilig points to first aren’t the speed ones. Short pay is down 57 percent. Chargebacks are down 65 percent. Disputes are down 25 percent. The company didn’t get fast at the expense of getting careless. It got fast because it insisted on being careful first.

That is the inverse of Klarna. Klarna’s dashboard celebrated speed and volume while the quality of the hardest conversations quietly eroded underneath it. Triumph made quality the metric that had to clear the bar before speed was allowed to become the story at all.

What the Dashboard Cannot See

Output metrics fail for a structural reason. They measure what was done. What leaders actually need to know is whether things are getting better. That distinction sounds simple. It produces completely different questions. Counting tokens consumed is easy. Asking whether the judgment underlying those tokens improved is hard. Counting PRs is easy. Asking whether the engineering organization is now capable of work it could not previously do is hard. Counting tool adoption is easy. Asking whether the team’s AI outputs are being accepted, revised, or rejected, and learning from the pattern, is hard. The organizations that stay in output-accounting mode past the early adoption phase are not being prudent. They are deferring accountability. McKinsey’s November 2025 “State of AI” report found that 88 percent of organizations now use AI, but only 6 percent qualify as high performers with measurable EBIT impact. Only 39 percent report any measurable business effect at all. The gap between having AI and benefiting from AI is the gap between output accounting and outcome accounting. High performers, in McKinsey’s data, are 2.8 times more likely to have fundamentally redesigned workflows. That is not a technology finding. It is a measurement finding: the organizations that ask deeper questions build different systems.

Three Questions That Change the Frame

Output metrics answer the question “did we use AI?” The questions leaders actually need are harder and closer to the truth. The first: how many agents do you have running? This measures the scale of actual deployment, not licenses activated or employees who opened a tool. Agents running against real problems are a more honest indicator of organizational AI maturity than any adoption metric. The second: how long can those agents run without human intervention? This is a proxy for quality. An agent that requires correction every five minutes signals weak prompting, poor context engineering, or an immature tool setup. An agent that completes substantive work over hours signals a team that has genuinely learned to work with AI. Autonomy duration is a quality metric dressed as a timing metric. Anthropic’s internal research found that human interventions per Claude Code session fell from 5.4 to 3.3 between August and December 2025\. That four-month trajectory is more revealing than any adoption curve. The third: what novel work are you unlocking that was not feasible before? This is the one that matters most to leaders, investors, and boards. Not “we are shipping the same roadmap 20 percent faster” but “we stood up a customer-segmentation pipeline that had been on the backlog for two years because we could never justify the engineering cost.” Novel work is opportunity creation. It is the metric that corresponds to what organizations are actually hoping for when they invest in AI. None of these three questions are easy to put on a dashboard. That is the feature, not the bug. A metric that is easy to optimize is a metric that will be gamed. Consider what happened in the rooms where CEOs set personal token-consumption targets for their teams: staff ran purposeless prompts to hit the number. Output metrics corrupt the behavior they are meant to measure. Outcome metrics resist that corruption because they are attached to something real.

The Cost the Dashboard Hides

There is a second blind spot, and it sits on the other side of the ledger. The three questions above measure whether the work is getting better. They do not measure what it now costs to deliver it, and that is the other half of any honest ROI. For two decades, software ran on an economic assumption so reliable that most leaders stopped noticing it. The marginal cost of serving one more user was effectively zero. Build the product once, and the ten-thousandth user cost almost nothing more than the thousandth. Engagement was therefore an unalloyed good. More usage meant more value, more retention, more expansion, and almost no additional cost to carry it. AI breaks that assumption. Every interaction now consumes tokens, and tokens cost money in direct proportion to use. Jeff Gothelf, who co-authored Lean UX, put the consequence plainly: your most engaged users can quietly become your least profitable ones. The power user running fifty AI queries a day is the user you celebrated under the old economics and the user who erodes your margin under the new one. The dashboard that shows engagement climbing may also be showing cost climbing faster, and a usage metric will never tell you which. This is why measurement for AI cannot stop at value. It has to track cost-to-serve at the unit level: cost per successful task, gross margin per active user, model cost as a percentage of revenue. These are not finance-team afterthoughts to reconcile at quarter end. They are leading indicators of whether an AI product or workflow stays economically sustainable as it scales. An organization can be creating genuine value, clearing every outcome bar in this piece, and still be quietly building something that gets less profitable with every new power user it celebrates. The discipline is the same one this entire piece argues for. Measure the thing that is hard to see, not the thing that is easy to count. On the value side, that means outcomes over outputs. On the cost side, it means cost per successful result over raw usage volume. A serious AI scorecard holds both, because a transformation that creates value while quietly destroying margin is not a success the dashboard is equipped to catch.

Innovation Accounting: The Closest Precedent

The intellectual framework that comes closest to what is needed already exists. Eric Ries built it for a different context: startups trying to measure progress when traditional indicators, revenue, customers, and profitability, are all effectively zero. His answer was innovation accounting. Instead of revenue, measure validated learning. Instead of units shipped, measure hypothesis tests completed. Build, measure, learn is the loop. The goal is not to produce a big number. The goal is to reduce uncertainty faster than the competition. Nobody has operationalized innovation, accounting for enterprise AI transformation in a published, replicable form. That gap is confirmed across every major measurement research program. DORA has extended its software-delivery metrics toward AI. Anthropic has published a primitives framework that measures how AI is being used at the task level. Accenture and Wharton have built a skills-shift index tracking 150 million professional profiles. None of them answer whether the organization is learning faster, producing better work, or doing things it could not do before. The practitioner community is ahead of the published literature on this. Six consecutive executive dinners across Dallas, Houston, Boston, Boulder, Portland, and Raleigh surfaced innovation accounting independently, without anyone being prompted. In every room, leaders described the same measurement problem and reached for the same frame. In no room did anyone have an operationalized version to point at. That convergence is not a coincidence. It means the field is ready for a framework, and the gap is structural, not a matter of individual companies being slow.

The Objection Worth Taking Seriously

The obvious counter-argument is that outcomes are unmeasurable. That output metrics are at least something, while outcome metrics are a vague ambition. This is a legitimate critique of poorly defined outcome goals. It is not a reason to abandon outcome measurement. Anthropic published the AI Fluency Index in early 2026, analyzing nearly 10,000 human-AI conversations to measure the quality of collaboration, not just the quantity. They identified 24 specific behaviors associated with effective AI use across four dimensions. Quality measurement is not an aspiration. It is an active research program producing real findings. The staged-measurement argument has something to it. Token consumption is a reasonable early proxy when the goal is normalizing AI use across a skeptical organization. Cultural adoption does need to come first. But most large organizations are past that phase now. Adoption is widespread. The question is no longer “will people use this?” It is “are we getting better because of it?” The Goodhart’s Law argument cuts both ways. Yes, any metric will eventually be gamed. That is a reason to rotate metrics deliberately, to pair quantitative measures with qualitative judgment, and to build measurement systems that are harder to optimize against than a single dashboard number. It is not a reason to accept measurements that are actively misleading. Outcomes can be defined. What novel work did your organization do this quarter that was not feasible last quarter? What percentage of AI outputs required human revision, rejection, or acceptance? How has autonomy duration changed over six months? These are measurable. They require judgment to interpret, as all meaningful metrics do. That is not a bug. That is what accountability looks like.

Where to Start

Auditing your current AI measurement against a single question produces clarity quickly: does each metric measure what happened or whether things got better? Tokens consumed, meeting transcripts enabled, PR counts, story points completed: these measure what happened. Replace them with counter-metrics that track quality alongside volume. If PR count goes up, track average PR complexity alongside it. If resolution time goes down, track customer satisfaction on complex interactions alongside it. At one roughly 1,000-person software company, the PR count told one story and average PR size told a different one. Both were necessary to understand what was actually happening. Then introduce the three questions as a leadership review practice. Not a dashboard, but a quarterly conversation: how many agents are running, how long can they run unattended, and what novel work did AI unlock in the last 90 days that was not on the roadmap before? The answers will be uneven and sometimes uncomfortable. That is the point. The organizations that build the discipline now, before their output metrics lock them into the wrong optimization, are the ones that will join the six percent achieving real EBIT impact. Not because outcome accounting is easy, but because it is honest.

The Measurement That Matters

Stanford HAI named this moment the shift from the era of AI evangelism to the era of AI evaluation. The question is not whether AI is transforming your industry. That question is answered. The question is whether your organization is learning from that transformation or simply counting it. Output accounting produces numbers that trend upward while the business-critical questions go unanswered. Klarna had great numbers until it did not. The engineering executive had a disappointing PR count until someone looked at PR size. The METR developers believed they were 20 percent faster until the data showed they were 19 percent slower. The dashboard that looks best right now may be hiding your Klarna moment. Outcome accounting is not optional for leaders who want to know what is actually happening. It is the discipline that makes the difference visible before it becomes irreversible. Want to explore what an outcome-accounting framework looks like for your organization? We work with leadership teams on exactly this question.

The post Measuring What Matters appeared first on Voltage Control.

Which Friction to Remove, and Which to Design Back In

For most of the last two decades, removing friction was the whole job. Every extra click, every approval step, every handoff that made a customer wait was waste, and the work of good leadership was to find it and delete it. We built entire disciplines around it. Lean. Six Sigma. Growth. Conversion-rate optimization. Design thinking, in its most reductive form, became a hunt for anything that slowed the user down. The companies that got smoothest fastest won, and they deserved to. AI has now made friction removal nearly free. Whatever obstacle is left in a workflow, there is a tool that will dissolve it this quarter. The drafting step, the research step, the first-pass review, the scheduling back-and-forth, the synthesis of twelve documents into one. The reconciliation, the summary, the first draft of nearly anything. Gone, or going. And that is the trap. When removing friction costs almost nothing, the temptation is to remove all of it. But not all friction is waste. Some of it was the only thing developing your people. Some of it was the only thing keeping a human close enough to the work to notice when something was about to go wrong. Strip that out along with the rest, and you get an organization that runs beautifully right up until the moment it needs judgment it no longer has. The discipline leaders need now is not friction removal. That skill is commoditized; the tools do it for you. The new discipline is friction discernment: the ability to tell the difference between the friction that drains people and the friction that develops them. Remove the first kind without mercy. Design the second kind back in on purpose. Everything else in the new friction follows from getting this one distinction right.

The two kinds of friction

Draining friction is friction that costs effort and returns nothing. The approval that exists because someone got burned in 2014 and no one has revisited it since. The status meeting that could have been a sentence. The reformatting of a report from one template into another. The manual data pull that a script does in a second. The form that asks for information the system already has. This friction does not build skill, protect quality, or surface insight. It just taxes attention and demoralizes the people subjected to it. AI should eat all of it, and you should let it. There is no virtue in preserving busywork, and no one should confuse what follows with nostalgia for it. Developmental friction is different. It costs effort and returns capability. The junior analyst who has to build the model by hand the first ten times, and only then earns the right to have a tool build it, because now they can tell when the tool is wrong. The reviewer is forced to articulate why an output is flawed before they are allowed to reject it. The team that has to argue its way to a decision instead of accepting the first plausible recommendation that appears on the screen. The new hire who sits in on the hard customer call instead of reading the AI summary afterward. This friction is slow. It feels like waste in the quarterly numbers. And it is the entire mechanism by which expertise, judgment, and trust get built. Here is what makes discernment hard, and why it is a discipline rather than a checklist. The two kinds of friction look identical on a process map. Both are steps that slow things down. Both show up in a time-and-motion study as cost. You cannot tell which is which by measuring duration, because duration is not the variable that matters. You can only tell by asking what the friction is producing. A leader who optimizes purely for speed has no way to see the difference, and will remove both with equal enthusiasm.

Why we are getting this wrong right now

The error is not stupidity. It is a structural asymmetry in what leaders can see. Efficiency is legible. It shows up in the dashboard the week after you automate something: fewer hours, lower cost, faster cycle time, a clean line that goes the right direction. You can put it in a board deck. You can attach your name to it. Judgment loss is illegible. It shows up nowhere, for a long time. It hides inside the year-over-year improvement metrics and the reduced headcount and the deliverables that ship faster and look clean, right up until a situation arrives that needs taste, or context, or the ability to know what is not in the data. By then the people who would have caught it have either atrophied the capability or never built it at all. JoAnna Vanderhoef gave this hidden cost a name: capability debt, the widening gap between an organization’s apparent efficiency and its actual adaptive capacity. Like technical debt, it accumulates quietly and charges interest later. Unlike technical debt, most organizations are not even tracking it. They are removing developmental friction at speed, booking the efficiency, and treating the judgment that disappears as if it were free. It is not free. It is borrowed, and the loan comes due on the worst possible day.

The evidence that friction can be load-bearing

This is not a motivational point. It is measurable. In a controlled study presented at the BIG.AI@MIT conference this year, Renee Gosline’s MIT team gave people cognitive tasks with AI assistance. In one condition, the AI made a recommendation and the person accepted or rejected it. In the other, the person first had to articulate their own reasoning, or predict what the AI’s reasoning was, before deciding. That single step took about thirty seconds. It measurably reduced over-reliance on the AI and preserved the person’s own critical thinking. Thirty seconds of deliberate friction kept the human’s judgment intact. Remove it, and the judgment quietly erodes until the day the AI is confidently wrong and no one in the room has kept the muscle to notice. The mechanism behind where this damage concentrates was formalized by a team of researchers at MIT, Yale, and Microsoft led by Mert Demirer. They studied what they call AI chains: sequences of work steps where the automatable steps are contiguous, so a human only has to verify the final output. The economic incentive is to keep extending the chain until the marginal cost of an error overwhelms the saved verification. The jobs that automate fastest are the ones where AI-suitable steps cluster together. Those are also, and this is the part that matters, the jobs where learning loops used to live. The junior who once did the research, drafted the slides, and watched a senior edit them loses three apprenticeship cycles per deliverable when the whole chain collapses into one automated unit. The work still gets done. The person stops getting made. So the friction you are tempted to remove fastest, the long contiguous chain, is frequently the exact friction that was developing your bench. Efficiency and capability erosion are not opposing forces you can balance. In the most automatable workflows, they are the same move

The test

Before you remove a piece of friction, run it through three questions. They take a minute, and they are the discipline in practice. First: what is this friction producing? If the honest answer is nothing, it is draining friction. Remove it without hesitation. If the answer is a skill, a judgment, a relationship, or a moment where someone learns to catch what a system would miss, you are looking at developmental friction, and removal has a hidden cost you need to price. Second: who was getting developed here, and where will they get developed instead? Most automation quietly deletes an apprenticeship without anyone deciding to. If you cannot name where the replacement reps come from, you are not saving time. You are borrowing capability from your future bench, and the interest rate is high. Third: what happens on a bad day? Efficiency holds until something breaks, and then recovery runs on the slack and the judgment you preserved, not the slack and judgment you optimized away. If removing this friction means no human is left who could step in when the system is confidently wrong, the friction was load-bearing, and you are about to knock out a wall. Run a concrete case through it. A team proposes to fully automate the first draft of every client proposal. Question one: what is the drafting producing? Not just a document. It is where account managers learn the client’s business well enough to defend the recommendation in the room. Question two: if the AI drafts them all, where do new account managers build that fluency? No one has an answer. Question three: when a client pushes back hard in a meeting, who has internalized the reasoning well enough to respond? The honest run-through does not say “never automate this.” It says automate the formatting and the boilerplate, and keep new managers writing the core argument by hand until they have earned the shortcut. That is friction discernment producing a different, better decision than “remove it” or “keep it.”

The moves

Discernment becomes real when it changes what leaders actually do. Three moves follow directly. Stop automating contiguous chains to the end without asking what skill the chain was building. The most automatable workflows are exactly where capability debt compounds fastest, because they are where whole apprenticeships used to live. Automate them deliberately, and keep a human in the loop where the learning was, not only where the legal liability is. The liability checkpoint protects the company this quarter. The learning checkpoint protects it in five years. Start designing developmental friction on purpose. Route a deliberate fraction of automatable work to humans anyway, so the capability stays alive. Require a thirty-second reasoning step before anyone accepts an AI output on a decision that matters. Run novelty drills, where work that could be automated is occasionally done by hand to keep the skill warm. Sample AI outputs not for quality assurance but for drift. Bring in someone who has not been close to a pipeline to ask whether it is still doing the right thing. None of these are productivity moves. All of them are capability moves, and the point is not to make the system slower. The point is to keep it teachable. Change what you celebrate. When a team automates forty percent of someone’s job, the reflex is to bank the savings and move on. The better move, which we have watched work, is to make the freed capacity a deliberate conversation: what harder, more developmental, more human work does this person now get to do? Organizations that celebrate only efficiency teach their people that the goal is to automate themselves toward the exit. Organizations that celebrate the redeployment teach them that AI is how they grow into more valuable work. Friction discernment is not anti-efficiency. It is efficiency pointed at the right target.

Why this is the leadership job now

When execution was expensive, leadership’s job was to clear the path: remove the blocker, approve the budget, unstick the review cycle. That job is mostly done, and the leaders still doing only that are optimizing a bottleneck that has already moved. The new job is friction discernment, and it cannot be delegated to a tool, because it is precisely the judgment about which judgments to keep. It is the one decision the AI cannot make for you, because the AI’s entire bias is toward removing friction, and the question in front of you is when not to. The organizations that get this right will look slower for a few quarters and less impressive in the efficiency reports. They will also still have, when the situation changes, the people who can do the work the model cannot. The organizations that remove every obstacle they can afford will discover, on the worst possible day, that they removed the ones holding the building up. Stop removing every obstacle. Learn to tell the difference. Remove the friction that drains your people. Design the friction that develops them. That is the discipline, and everything else in the new friction follows from it.

The post The Friction Discernment Test appeared first on Voltage Control.

Why Your AI Case Studies Aren’t Working

Your organization has done the work. You have accuracy benchmarks, SLA guarantees, pilot results, case studies with named clients and documented ROI. Your vendor has third-party audits. Your legal team reviewed the data handling. Your IT team certified the security posture. And your employees still are not using it. This is not a failure of evidence. It is a category error. You have been building trustworthiness. You needed to be building trust. These are not the same thing, and conflating them is why most enterprise AI adoption efforts stall at exactly the moment they should be accelerating.

Trustworthiness Is About the System. Trust Is About the Person.

Trustworthiness is what the evidence shows: accuracy rates, compliance certifications, SLAs, pilot results, and audit trails. It is an attribute of the AI system itself. You can measure it, document it, and present it in a deck. Trust is different. Trust is a psychological act that happens inside a person. It is the moment someone decides to rely on something they cannot fully verify. And that decision is not primarily driven by evidence. It is driven by experience, context, identity, and social proof from people they respect. The distinction matters because the interventions are completely different. Loading more evidence into your adoption campaign, another case study, another ROI breakdown, another compliance badge, does not move the needle on trust if the underlying psychological conditions are not met. You are solving for trustworthiness while employees are asking a different question. The question is not “Is this AI trustworthy?” The question is “Do I trust this AI, here, in my role, for this kind of work?”

The Robotaxi Paradox

Here is the pattern that reveals this most clearly. A knowledge worker who hails a robotaxi and lets software navigate them through city traffic at 40 miles per hour is the same person who refuses to accept a Copilot-generated first draft without rewriting it from scratch. Objectively, the stakes do not compare. A robotaxi error could injure them. A hallucinated summary wastes fifteen minutes. But their trust behavior inverts what the evidence would predict. Why? Because the psychological conditions are entirely different. With the robotaxi, the role boundaries are clear. The car drives; they sit. The system is visibly working in real time. Social proof from colleagues who have used it accumulates passively. And critically, their professional credibility is not on the line. If the robotaxi takes an odd turn, they observe it. They do not own it. With Copilot, everything changes. The output lands in their document, under their name, in their domain of expertise. If the summary is wrong and they forward it, that is their error. The AI did not fail. They failed to catch the AI failing. Their reputation as someone who knows their material is at stake in a way it simply is not when they are a passenger. Trustworthiness is similar across both systems, or arguably higher for Copilot given its output transparency and audit trail. Trust diverges completely because the psychological stakes differ. This is not irrational. This is exactly how trust works. The lesson for AI leaders is specific: the trust gap your employees have with enterprise AI is not primarily about the model. It is about the context in which they use it and what failure costs them professionally. An employee who trusts AI to help draft internal updates may not trust the same AI to help draft client recommendations, even if the capability is identical. The context changes the psychological stakes. The psychological stakes change the trust response. Treating both contexts as equivalent, and responding to the skepticism in the second context with more evidence from the first, is the mistake most adoption programs make.

Why More Evidence Backfires

The conventional response to adoption resistance is to produce more evidence of trustworthiness. Refine the accuracy stats. Commission an independent audit. Write up a case study from a similar organization. Schedule a lunch-and-learn to walk through how the model works. This is understandable. It is also almost always wrong. Craig Roth at Gartner’s Digital Workplace Summit named what actually happens: organizations deploy AI rapidly, loading employees with technical information about the system, and create trust deficits precisely because speed and data-loading leave no room for the gradual, experience-based trust-building that works. Speed is a trust deficit. Evidence is not trust. Research on what actually drives psychological trust identifies three factors: perceived ability (can the system do what it claims?), benevolence (does it act in the user’s interest?), and integrity (does it behave consistently and honestly?). Evidence addresses ability. It barely touches benevolence and integrity, which are primarily established through direct experience, not documentation. Worse, detailed technical explanations often activate a risk mindset rather than a trust mindset. Walking through the training data surfaces concerns about bias. Explaining confidence intervals surfaces concerns about accuracy in edge cases. Describing the audit methodology surfaces questions about what the audit did not cover. You have made the system more transparent, which improves trustworthiness. You have also made the failure modes more vivid, which suppresses trust. The information is accurate. The effect is the opposite of what you intended. This is the core tension: the moves that build trustworthiness and the moves that build trust operate through different mechanisms. Most organizations invest heavily in the former and wonder why it does not produce the latter.

What Actually Builds Trust

Trust in AI builds the same way trust in anything builds: through repeated exposure, positive experience, social modeling, and calibrated stakes.

Small starts, visible wins.

The organizations seeing genuine AI traction are not the ones who launched enterprise-wide mandates backed by polished training programs. They ran tight pilots in one team, let people experiment with low-stakes tasks, and let word of mouth carry the initial momentum. When someone uses AI to draft a rough first cut of a weekly update and it saves them an hour, they tell people. That conversation transfers more trust than any case study. You cannot engineer the conversation directly, but you can create the conditions for it: start small, start where the AI clearly succeeds, and give people room to discover it themselves.

Top-down permission, bottom-up testimonials.

Both matter, and they serve different functions. Leadership commitment, when an executive uses AI visibly in their own work and says so, creates permission. It signals that experimentation is safe and that the organization values the output even when it is imperfect. Bottom-up testimonials from actual practitioners, not trainers or IT leads but respected domain experts who talk about specific ways AI helped them, create desire. They answer the question employees are actually asking: “Does this work for someone like me?” Top-down without bottom-up is a mandate. Bottom-up without top-down is shadow AI, happening outside governance, invisible to the organization and to any accumulated trust benefit. You need both.

Sequence use cases to build a track record.

Not all AI use cases carry the same trust-building or trust-destroying potential. A rough first draft on an internal update is low stakes and often succeeds visibly. A client-facing analysis output is high stakes and will be scrutinized in ways that compound skepticism if it fails. The sequencing of early experiences matters enormously. Start where the AI succeeds clearly, with work that is iterative and internal, where recovery from error is easy and the user stays in control. The trust you build in those contexts transfers to harder ones. The distrust from an early public failure also transfers, and it spreads faster.

Address the identity question directly.

This is the piece most adoption strategies miss entirely. Knowledge work AI almost always has professional identity stakes embedded in it. Am I still the expert if the AI writes the first draft? Am I still the analyst if the AI runs the summary? Am I still the strategist if the AI builds the framework? These questions are not irrational objections to be overcome. They are prior to the trustworthiness question. Answering “yes, the model is 94% accurate” does not address “yes, you are still the expert.” The leaders building AI fluency that holds are addressing this directly. Not by reassuring people that their jobs are safe, which most people do not believe, but by making the new shape of expertise visible. Directing a tool well is a skill. Editing a first draft to a high standard is a skill. Knowing when to override the output is a skill. Recognizing what the AI missed requires knowing your domain deeply. The expert who uses AI well is more capable, not less. Making this visible and valued is not an HR exercise. It is a trust-building move.

What to Stop Doing

If you have an adoption problem, the instinct is to add more proof. Resist it. Ask instead what is driving the psychological conditions that make trust difficult. The answers are usually specific. If employees feel AI is happening to them rather than with them, involving them in defining what good output looks like makes a material difference. People trust systems they helped shape more than systems deployed at them. Letting practitioners set the quality bar for what AI-assisted work needs to meet is not a political gesture. It changes how they relate to the system. They will defend the standard they set. If the social modeling in your organization is skeptical, one champion in the right position is worth more than a hundred case studies. Not a trainer. Not an IT lead. A respected domain expert who uses AI openly and talks about what it changed for them. Their credibility transfers to the tool. If you are building the business case around accuracy stats and ROI figures, understand that you are building a trustworthiness case. That case needs to be made to procurement, to legal, to the board. It is not the case employees need. The case employees need is not about whether the AI is reliable. It is about whether they can rely on it, in their context, for their work, in a way that protects their credibility rather than threatening it.

The Real Work

Trustworthiness is table stakes. It gets you through the governance gate and into the pilot. Trust is what gets you to adoption. Adoption is where the value is. The organizations that figure this out are not producing better case studies. They are building different conditions: room to experiment without professional exposure, social proof from real practitioners, early use cases where success is obvious, and an explicit reframing of what expertise looks like when AI is in the room. The ones that do not will keep wondering why employees who nodded through the AI launch presentation still open a blank document and start typing. If you are working through this in your organization and want to talk about where you are stuck, the gap between trustworthiness and trust is usually where the most interesting questions live. Start that conversation here.

The post Trustworthiness Is Not Trust appeared first on Voltage Control.

What Two Real Cases Reveal About AI Governance

Joe Mariano said something at the Gartner Digital Workplace Summit and it should be on a poster in every AI governance committee in the country. “AI is a tool. It is not a legal shield.” Two recent cases prove him right. In both, an organization deployed an AI system, the system did exactly what it was designed to do, the organization got sued, and the organization lost. Not because the model misbehaved. Because nobody on the human side was watching. These are not abstract risks. They are the first two real precedents we have for AI liability in the enterprise, and they both turned on the same thing: a monitoring and data gap that the legal system treated as the company’s responsibility, not the AI’s. If you are a leader thinking about AI governance, you are no longer thinking about it in theory. You are thinking about it inside the ruling that other companies have already lost.

The Air Canada Chatbot Case

In November 2022, Jake Moffatt visited Air Canada’s website to book a last-minute flight to attend his grandmother’s funeral. He asked the airline’s AI chatbot whether bereavement fares were available. The chatbot told him yes, that he could book the flight at full fare and apply for a bereavement refund within ninety days of travel. He booked. He flew. He filed for the refund. Air Canada denied the claim. The actual policy required bereavement-fare requests before travel, not after. The chatbot had hallucinated a refund window that did not exist. Moffatt took the airline to the British Columbia Civil Resolution Tribunal. Air Canada’s argument was the part that should make every AI governance lead pay attention. The airline argued that the chatbot was, in their words, “a separate legal entity that is responsible for its own actions.” The tribunal rejected that argument flatly. In Moffatt v. Air Canada, 2024 BCCRT 149, the tribunal ruled that Air Canada was responsible for all information on its website, regardless of whether it came from a static page or a chatbot, and ordered the airline to pay damages. The decision is short, the legal reasoning is clean, and the precedent is simple: if your AI tells a customer something false, your company said it. The chatbot does not have its own lawyer. It does not have its own bank account. It does not have legal standing. It is a tool you deployed, and the output is your output. Air Canada’s failure was not that the chatbot hallucinated. Hallucination is a known property of generative systems, and any organization deploying one in a customer-facing context should plan for it. The failure was that nobody checked. There was no monitoring layer, no review pipeline, no human in the loop verifying that high-stakes policy claims matched the airline’s actual policy. The model behaved as models behave. The organization behaved as if the model would not.

The iTutorGroup EEOC Settlement

In August 2023, the U.S. Equal Employment Opportunity Commission settled a case against iTutorGroup, a tutoring company that had used an AI-driven recruitment system to screen applicants for tutor positions. The system was configured to automatically reject women aged 55 and over and men aged 60 and over. More than two hundred qualified applicants were filtered out before any human ever saw their applications. The EEOC argued, and iTutorGroup agreed in a consent decree, that the company had violated the Age Discrimination in Employment Act. iTutorGroup paid $365,000 in damages and committed to anti-discrimination training and oversight changes. It is widely cited as the first EEOC enforcement action targeting algorithmic discrimination, and it set the regulatory tone for what was to come. The interesting thing about this case is that the AI did not malfunction. It did exactly what its rules told it to do. Somewhere in the configuration, somebody had set age thresholds. The AI applied them. Hundreds of times. What was missing was the question of whether anybody should have set those thresholds in the first place. There was no review of the screening logic against employment law. There was no monitoring of who was being filtered out and why. The data quality, the rule design, the oversight layer, all of it sat inside an AI deployment that nobody thought needed governance because the AI itself was working. That is the iTutorGroup pattern, and it is more dangerous than the Air Canada pattern because it does not look like an AI failure. It looks like an AI success.

The Pattern: Monitoring Gaps, Not Bad Models

Joe Mariano walked through both of these cases at Gartner DWS 2026, and the framing he landed on is worth repeating: the failures here were not in the technology layer. They were in the layer above the technology, where humans decide what the AI is allowed to do, what data it sees, and who is watching when it is doing it. The Air Canada chatbot worked as a generative chatbot works. It produced a plausible answer to a question it did not have grounded knowledge to answer. The failure was that the airline deployed it on a high-stakes policy page without a verification pipeline. The iTutorGroup recruiter worked as a rules-based filter works. It applied the configuration it was given. The failure was that the configuration had been set by humans without legal review, and there was no monitoring on the output to flag the discriminatory pattern. Both failures, in other words, traced to the same place: the human-decision system around the AI was not designed. The technology was deployed faster than the governance scaffolding around it could catch up, and the legal exposure that resulted was real. This is the part most AI governance conversations skip. They focus on the technology, on which model, on which vendor, on which compliance certifications, when the actual exposure lives in the workflow. Who reviews high-stakes outputs before they go to customers. Who audits the rules the AI is using. Who is watching for patterns that look fine inside the model but look discriminatory in aggregate. The Gartner data backs this up. There are over 1,000 proposed AI rules and regulations worldwide right now, and not one of them has the same definition of AI. The regulatory landscape is going to get harder, not easier. Companies that are still treating AI governance as a policy document, rather than as an active facilitation problem inside their organization, are going to keep producing the next Air Canada and the next iTutorGroup.

Why AI Does Not Absorb Accountability

There is a comforting fiction that some leaders are still telling themselves about AI deployment, which is that the model carries some of the liability. It does not. Across multiple jurisdictions, in multiple legal frameworks, the rulings are converging on the same answer: the deploying organization is accountable for the output, full stop. This makes sense the moment you say it out loud. The AI did not sign a contract with the customer. The AI did not file a lawsuit. The AI did not get sued. Your company did all three of those things. The model is a tool the company chose to deploy, and the output of that tool is the company’s output, the same way that an internal email written by a junior employee is the company’s email. What this means in practice is that the conversation about AI governance has to move from “is the model trustworthy” to “is our deployment of the model accountable.” Those are different questions. A trustworthy model deployed without governance is still a liability. An imperfect model deployed with rigorous governance is, in many cases, fine. The trustworthy-but-ungoverned configuration is what produced both cases above. The Air Canada chatbot was, by industry standards, a perfectly normal AI product. The iTutorGroup recruiter was, by configuration standards, perfectly capable of being used legally. Neither model was the problem. The deployment around it was.

Four Governance Patterns That Actually Work

If the technology is not the gap, what closes the gap? Mariano’s session offered four patterns, and they map cleanly to what we see when we walk into client governance work. Brain-first deployment. Before AI is brought into a workflow, the team uses human judgment to define the goal, the boundary, and the success criteria. The AI is then brought in to assist a human-defined process, not to replace the human-definition step. Air Canada skipped this. The chatbot was deployed on a policy page without anyone defining what counted as an acceptable policy answer. Human in the loop for quality control. Some volume of AI output gets reviewed by a human before it goes to a customer or a decision. The exact percentage depends on the stakes, but the principle is non-negotiable: zero human review on high-stakes outputs is a deployment, not a governance posture. iTutorGroup ran a recruitment AI with apparently no auditing of the rejection pattern. That is the failure case. Data quality management. AI systems accessing wrong, stale, or biased data will produce wrong, stale, or biased outputs with full confidence. Both Air Canada and iTutorGroup had data quality problems at the root. The chatbot was answering questions about a policy it had not been grounded in. The recruiter was applying rules that had not been audited against current law. Neither case was a model problem. Both were data problems wearing model clothing. Continuous skill and process maintenance. Governance is not a one-time training. It is an ongoing practice, with periodic reviews, audits, and skill refreshes for the people running the system. The model evolves. The regulations evolve. The use cases evolve. A governance framework that was designed twelve months ago and has not been touched since is, by definition, stale. These four patterns are not novel. They are the basic discipline of any high-stakes deployment, applied to AI. What is new is that the legal system is now treating them as the standard of care, and organizations that ignore them are losing the cases.

The Real Move: Treat Governance as Facilitation

Here is the move most organizations miss. AI governance is not a document. It is a set of ongoing agreements between security, legal, business, and operations about what the AI can do, who is watching, and what happens when something goes wrong. Those agreements have to be negotiated. They cannot be written by one team and handed to the rest. This is where the work gets uncomfortable, because it requires the same cross-functional conversation that most organizations are structurally bad at. Legal does not want to talk to Engineering. Security does not want to talk to Marketing. The business unit that wants to deploy the chatbot does not want to slow down for a review. And so the governance conversation never happens, and the deployment goes out, and somebody loses a tribunal. The organizations getting this right are the ones that treat AI governance as a facilitated, recurring practice, not a sign-off process. They have a standing forum, with the right people, that meets often enough to keep up with what is being deployed. They produce decisions, not policy documents. They review the deployments that have shipped. They ask, every time, what would happen if this output ended up in front of a regulator or a tribunal. That is the New Friction. AI eliminated the old friction, which was execution time. The new friction is the human-decision layer that has to keep up with what AI now lets you ship. Organizations that do not invest in that layer ship faster, get sued more, and lose the cases. Organizations that do invest in it ship slightly slower, ship better, and stay out of the tribunal. If you are building or refreshing your AI governance posture right now, the question is not which model you trust. The question is which decisions your organization can keep up with, and which conversations you are willing to have to keep up with them. That is the work. That is the entire work. If your organization is in the middle of that conversation, or trying to start one, that is where Voltage Control comes in. Read our New Friction primer for the full framework, or reach out if you want to talk about where your governance posture is stuck.

Frequently Asked Questions

Can companies be held liable for AI mistakes?

Yes. Both the Air Canada and iTutorGroup cases establish that the deploying organization is responsible for AI output, regardless of whether the output came from a human or an AI system. Air Canada explicitly argued that the chatbot was a separate legal entity. The tribunal rejected the argument. Across jurisdictions, the legal direction is consistent: the company that deploys the AI owns the consequences.

What happened in the Air Canada chatbot case?

A customer asked Air Canada’s chatbot about bereavement fares. The chatbot hallucinated a refund policy that did not exist. The customer relied on it, booked the flight, and was denied the refund. He took the airline to the British Columbia Civil Resolution Tribunal, which ruled in Moffatt v. Air Canada, 2024 BCCRT 149, that the airline was responsible for the chatbot’s output. Air Canada paid damages.

How do organizations govern AI systems effectively?

Effective AI governance is a recurring facilitation practice, not a static policy document. The organizations doing this well bring legal, security, business, and operations into a standing forum that meets often enough to keep up with deployments, audits real outputs, and produces decisions. The four operating patterns are brain-first deployment, human in the loop for quality control, data quality management, and continuous skill maintenance.

What is AI accountability in the workplace?

AI accountability is the principle that the organization deploying the AI is responsible for what the AI produces. That responsibility cannot be delegated to the model, the vendor, or the AI system itself. It lives with the humans who decided to deploy the system, configured it, fed it data, and chose how much oversight to give it.

Who is responsible when AI makes wrong decisions?

The deploying organization. In every major AI liability case to date, including Air Canada and iTutorGroup, the courts and tribunals have held the company responsible for the AI’s output. The model is treated as a tool, and tool failures attach to the operator, not to the tool.

The post AI Is Not a Legal Shield appeared first on Voltage Control.

How AI Is Quietly Breaking Your Senior Bench

“We’re worried because there are fewer entry-level jobs right now, and in five years, there will be fewer intermediate or senior-level designers. There’s going to be a gap.” That is a working landscape architect, one of 722 interviewed for a new Cornell study presented at the BIG.AI@MIT conference last month. The quote is not about a dystopian future. It is about what the practitioner is watching happen, month by month, in her own firm. The headline narrative on AI and work is about entry-level job loss. That is real, and it matters. But the more consequential story, the one that is almost invisible in quarterly earnings calls, is quieter and slower: the people who would have been senior in five years are not getting trained now. The junior did not lose the job. The junior lost the reps.

What the study actually found

Jose Antonio Guridi and Cristobal Cheyre, researchers at Cornell, spent the last eighteen months studying how landscape architecture firms across North America are adopting generative AI. They did 25 semi-structured interviews, spent time observing operations at a prominent firm, and ran a survey of 722 practitioners. That is one of the largest datasets on AI adoption in a real profession that has been published. Three findings stand out. First, the adoption is uneven in a specific pattern. Juniors are driving it. Seniors are holding the judgment that decides whether the AI output is right. In firms that have not designed for this reversal, the junior uses AI to produce something the senior reviews. The senior edits the output. The original work the junior would have done, the intermediate steps where skill used to form, quietly disappears. Second, most of the adoption is hidden. 73% of the practitioners who use AI at work do not disclose that use to their firm. They use personal devices. They treat restrictive firm policies as an obstacle to route around rather than a signal to stop. The work gets done. The firm does not know how. Third, the firms that are handling this well have all done the same thing: they have made the adoption explicit. Structured workshops. Shared documents. Senior oversight built into the workflow, not as policing, but as a design feature. The distinction between the three patterns is where the story is.

Passive, hidden, explicit

Guridi and Cheyre name three adoption patterns. Each one produces a different organization five years from now. Passive adoption. AI arrives through software updates. The design tool adds a new button. The email client starts suggesting full paragraphs. The research database surfaces AI-generated summaries above the actual sources. Nobody decided. The practitioners absorb the change as background noise. Skill formation is whatever it would have been, minus the steps the software now does automatically. Passive adoption is the modal case. Most organizations are in it right now and do not realize it. Hidden adoption. The firm has a restrictive AI policy. The practitioners need to produce the work anyway. They open ChatGPT on their phones, paste the brief, and keep the output in their personal notes. They know they are not supposed to. They do it because the alternative is not doing the job. The 73% disclosure-gap statistic is this pattern, captured at scale. Hidden adoption looks like conformity from the outside. From the inside, it is an underground apprenticeship running in parallel with the firm’s official one, except the underground one is entirely unsupervised and invisible to every senior person who might intervene. Explicit adoption. The firm has decided, out loud, how AI fits into the work. There are designated workflows where AI is expected. There are designated workflows where AI is not welcome. There are senior reviews built into the AI-assisted paths, not as gates, but as teaching moments. Juniors get exposure to the AI-generated output. They also get exposure to the senior’s reasoning about why the output is right or wrong. This is the only one of the three patterns that preserves apprenticeship.

The mechanism: where the learning moments go

A team of economists at MIT, Yale, and Microsoft, led by Mert Demirer, gave this phenomenon a structural name. They call it AI chains.

An AI chain is a sequence of production steps in which each automated step flows into the next without a human in the middle. Verification happens once, at the end of the chain. The economics are obvious: verification is expensive, so fewer verifications are better. Organizations will push toward longer chains whenever the AI is good enough.

The consequence is that jobs where AI-suitable steps sit next to each other are the jobs where chains form fastest. Research, drafting, and rendering are adjacent. So are summarization, synthesis, and first-pass review. Chain the three together and you have converted what used to be a six-hour junior assignment into a thirty-second prompt and a five-minute senior review. The efficiency gain is real. So is the apprenticeship cost, which does not show up anywhere on the quarterly report.

In landscape architecture, Guridi and Cheyre watched this happen inside the firm they observed. Rendering production used to be the junior’s job. It was slow, iterative, and humbling. You started something, showed it to a senior, received criticism, started again. After two years, you had internalized the senior’s taste. After five years, you had your own.

The rendering step is now in a chain. The junior writes a prompt. The AI produces four variations. The senior picks one and edits it. The junior has watched, but has not done. The internalization does not happen the same way. The taste does not form. One practitioner put it to the researchers this way: “If you’re using something to generate everything, you miss all of these moments to be iterative and review your own work.”

The pattern is not unique to design. In May 2025, Moderna’s Chief People and Digital Technology Officer Tracey Franklin described to the Wall Street Journal a system of more than 3,000 internal GPTs, including a broad HR GPT that routes employee questions to specialized GPTs for performance management, equity, and benefits. Her own description of the workflow: “It’s like your virtual HR, AI agent. It’s what would normally be a junior-level HR analyst type, we’ve now converted into a GPT.” Same chain. Different industry. The intermediate work that an HR analyst would have done on the way to becoming a senior HR partner is gone.

Why executives don’t see it

The reason this pattern is so hard to see at the executive level is structural. It is not a failure of leadership attention. It is a failure of legibility. The metrics you have are the metrics that matter. Revenue per employee. Project cycle time. Client satisfaction. None of these show apprenticeship. All of them might actually improve in the short term when AI chains form, because the outputs ship faster and the staff count drops. The disclosure gap compounds the invisibility. 73% of AI users are hiding the use from the firm. Senior leaders cannot see what they cannot see. The firm’s governance layer is responding to a world where AI use is still occasional. The actual daily reality has moved past that. And the time horizon is precisely the wrong length. Five years is long enough that the consequence is somebody else’s problem, probably the problem of whoever succeeds today’s CEO. Five years is short enough that the seniors who exist today will still exist and can still cover the gap, right up until they retire. We name this pattern “Experience Starvation,” after the term coined by Gartner’s Tori Paulman at last year’s Digital Workplace Summit. Experience starvation is what you get when the workflow around the AI strips out the intermediate work the junior used to do on the way to becoming the senior. The organization continues to function. The talent pipeline quietly thins. Paulman’s framing has a sharp corollary: AI is not taking entry-level jobs. Senior people are.

What the firms getting it right are doing

The explicit-adoption firms in the Guridi study are not slower. They are not abstaining from AI. They have just designed the adoption so that apprenticeship survives. The most teachable pattern in the research is one Paulman calls the Option 3 workflow. It has three moves. The expert builds the template. The senior practitioner, who has the taste, captures her reasoning in a reusable form. The template is the artifact. It encodes the judgment. The rookie executes with AI. The junior runs the template, feeds it the project context, and gets the output. They see the template working. They see where it breaks. They do the adaptation work the template did not cover. The expert reviews the insights. The senior does not edit the output. The senior reviews the judgment the junior exercised when the template was not sufficient. The feedback is on reasoning, not on rendering. The workflow preserves three things at once. The firm gets AI leverage on the routine work. The junior gets exposure to the senior’s reasoning, not just the senior’s output. The senior spends her scarce time on the decisions that only she can make. This is what Guridi and Cheyre observed in the firms that were explicit about their AI adoption. It is not a program. It is a set of working conventions that the senior partners enforced because they had decided, out loud, that training the next generation was part of the firm’s product. The firms that had not made that decision were not using any of this. They were using AI chains that removed the work and the learning together.

What to do this month

Three moves that do not require a transformation program. Make disclosure safe. The 73% who hide AI use are not malicious. They are responding to incentives you set. If the penalty for disclosing AI use is higher than the penalty for hiding it, you will get hiding. Change the incentive. A one-line policy update (“we encourage AI use in designated workflows; here is how to propose a new one”) can move the whole distribution. You cannot design around a pattern you cannot see. Route some work through juniors even when AI could do it. Not all of it. Some. The criterion is whether the work teaches something the junior needs to know in five years. If the answer is yes, the junior does it. The efficiency loss is the training budget, reclassified. You are already paying for training; now you are spending it on practice instead of on certificates. Audit your senior bench replacement rate. Not headcount. Replacement rate. For every senior who will retire or exit in the next five years, who is on track to replace them? If the answer is “unclear,” you have the gap already. The only question is whether you find out now, when you can still do something, or in three years, when your best seniors are announcing and the bench is empty. None of these require new hires. None require new tools. They require the decision to design for apprenticeship at a moment when every incentive is telling you to optimize it away.

What is at stake

The five-year gap is not a forecast. It is a trajectory measurement. The apprenticeship loss is happening now. The consequence is scheduled to arrive in 2030\. The organizations that will have the senior bench they need in 2030 are the ones that decided, in 2026, that apprenticeship was a design problem. They built Option 3 workflows. They made disclosure safe. They kept routing work through the junior even when the AI was right there and faster. The organizations that will have the gap in 2030 are not doing anything wrong, exactly. They are optimizing for the metrics they have. The metrics they have do not measure apprenticeship. Apprenticeship erodes silently. By the time it shows up as a capability gap, the people who could have been trained have moved on to firms that trained them. The juniors are not losing their jobs. They are losing the work that would have made them senior. That is a different problem, and it hides better, and it bills later.

Ready to close the gap?

If your organization is watching AI chains form and is not sure whether apprenticeship is surviving, three places to go deeper. Talk to us. We help leadership teams design the workflows that keep AI leverage without losing the learning cycles. Learn more Our pillar page lays out why apprenticeship loss is one of the new frictions AI has relocated into the center of your organization. Build the capability. Our facilitation certification teaches the skills senior leaders need to run Option 3 workflows at scale.

Frequently Asked Questions

Is AI taking entry-level jobs?

The headline narrative says yes, but the more consequential pattern is different. AI is enabling senior workers to do entry-level work themselves, which removes the on-ramps for skill development. The junior role often still exists; the work that used to fill it has been compressed into AI chains. The Cornell study of 722 practitioners shows this pattern clearly. The junior did not lose the job. The junior lost the reps.

What is experience starvation in AI adoption?

Experience starvation is a term coined by Gartner’s Tori Paulman to describe the systematic removal of the low-stakes, high-repetition work that builds professional judgment. When AI handles the steps where skill used to form, the junior misses the iterative cycles that produce taste. The organization keeps shipping. The talent pipeline quietly thins. By the time the gap shows up, the people who could have been trained are five years past the moment when training mattered.

How does AI break the apprenticeship model?

AI chains the production steps where junior workers used to learn. Research, drafting, rendering, review: each one used to be a discrete moment where a junior practiced and a senior critiqued. When those steps chain together, the junior writes a prompt and the senior edits the final output. The intermediate work, where taste forms, disappears. Most organizations have not noticed because their metrics do not measure apprenticeship. Cycle time and revenue per employee actually improve in the short term.

What is the Option 3 workflow for AI in the workplace?

The Option 3 workflow, also from Paulman’s research, has three moves: the expert builds a reusable template that encodes her judgment, the rookie executes the template with AI on real project context, and the expert reviews not the rendered output but the reasoning the rookie applied when the template was insufficient. It preserves AI leverage on routine work while giving juniors exposure to senior reasoning. It is the only workflow pattern in the Cornell research that survives apprenticeship.

How do you protect your talent pipeline from AI-driven erosion?

Three moves: make AI disclosure safe so you can see what is actually happening (the Cornell data shows 73% of users hide their AI use from their employers); route some work through juniors even when AI could do it, with the criterion being whether the work teaches something the junior needs in five years; and audit your senior bench replacement rate, not headcount but replacement rate, so you know where the pipeline is actually broken before it shows up as a capability gap.

The post The Five-Year Gap appeared first on Voltage Control.

Something strange is happening inside organizations that have invested heavily in AI. Leadership reports productivity gains. Dashboards show adoption metrics trending upward. The transformation appears to be working. And then you talk to the people doing the work. Gartner’s 2025 AI in the Enterprise Survey found that executives are four times more likely to report high AI productivity gains. Individual contributors are five times more likely to say AI made no difference at all. This is not a minor variation in optimism. These are two fundamentally different versions of reality operating inside the same organization, at the same time, about the same technology. That gap is the single most important thing standing between your AI investment and actual transformation. Not the model. Not the license. Not the training curriculum. The fact that the people making AI strategy decisions and the people living with those decisions are not even looking at the same picture.

Two Realities, One Organization

The numbers tell a story that most AI strategies are not designed to hear. 78% of employees do not know whether they will lose their job to AI. Only 12% feel involved in decisions about how AI gets deployed in their work. And only 14% of leaders believe their employees are effectively using the AI tools they have already been given. Sit with that combination for a moment. Leadership is looking at underutilization and concluding the workforce needs more training, better tools, clearer mandates. The workforce is looking at the same AI rollout and wondering whether the whole point is to make them redundant. Both sides are interpreting the same set of facts. Neither is wrong, exactly. But they are operating from different starting assumptions, and those assumptions are shaping behavior in ways that no amount of change management communication can override. When employees believe they are being replaced, they do not experiment with new tools. They protect their territory. They withhold the institutional knowledge that makes AI implementations actually work. They comply with the minimum requirements of training programs and then return to their existing workflows. The dashboards still show adoption because the licenses are being opened. But the transformation is not happening.

The Psychology Nobody Is Talking About

Most analysis of the exec/IC gap treats it as an information problem. Leadership has data that employees do not. Or a communication problem. The message is not getting through. Or a training problem. Employees just need more hands-on time with the tools. Tori Paulman, the Gartner analyst who authored the perception gap research, offers a different and more uncomfortable explanation. The gap is not informational. It is psychological. Executives authorized the AI investment. In many cases, they championed it to their boards. They have staked credibility and budget on the claim that AI will make the organization more productive, more competitive, more efficient. They have cognitive skin in the game. The investment has to be working, because if it is not, that reflects on the decision to make it. Frontline workers live in a different psychological reality. They read the headlines about displacement. They watch colleagues get reassigned or laid off.

They hear the word “transformation” and parse it, correctly, as a word that means someone’s job is about to change in ways they did not choose. They have cognitive skin in the game too, but the stakes point in the opposite direction. AI cannot possibly be as good as leadership claims, because if it is, the implications for their own role are terrifying. This is cognitive dissonance operating at organizational scale. Not ignorance. Not resistance to change. Two groups of people filtering identical information through fundamentally different personal stakes, and arriving at conclusions that are perfectly rational given their respective positions. No training program resolves cognitive dissonance. No town hall presentation bridges a gap that is rooted in what people need to believe in order to feel safe.

The biggest threat to your AI strategy is not the technology. It is that your executives and employees are looking at the same data and seeing completely different things.

The Evidence Is Piling Up

The perception gap is not a theory. It is showing up in behavioral data, not just surveys. Anthropic’s Economic Index, built on over one million real conversations with Claude, found that experienced AI users, those with six or more months of regular use, have a measurably higher success rate in their interactions. The gap is not trivial. It is the difference between using AI as a basic task executor and using it as a genuine thought partner for strategy, planning, and complex problem-solving. That finding maps directly onto the perception divide.

The people who have had enough sustained exposure to move past the anxiety and into genuine fluency are extracting compounding value. The people who are still in the “comply with the training but don’t actually trust it” phase are getting almost nothing. And they are interpreting that lack of value as confirmation that AI does not work, which reinforces the very behavior that prevents them from discovering that it does. Meanwhile, 75% of knowledge workers are already using AI in some form, often through unsanctioned shadow tools their organizations do not know about. The workforce is not anti-AI. They are anti-being-replaced-by-AI. When they choose the tool themselves, on their own terms, for problems they define, adoption is not a problem. When the tool is handed to them by the same leadership team discussing “efficiency gains” and “headcount optimization,” every interaction carries the weight of an existential question.

Why Communication Strategies Fail

The default organizational response to the perception gap is communication. Town halls. FAQ documents. Executive memos about the exciting future of AI. Internal newsletters with success stories and productivity metrics. This approach fails for a specific reason: it treats the gap as an information deficit when the actual problem is a trust deficit. Consider what a typical AI communication strategy sounds like from the frontline perspective. Leadership says: “AI is going to transform how we work. It will make you more productive. It will free you up for higher-value activities.” The employee hears: “We are changing your job. We have already decided. You were not consulted. The framing assumes this is good for you.

If you disagree, you are resistant to change.” The more polished the communication, the wider the gap becomes. Because polished messaging signals that the narrative has been constructed, and constructed narratives are exactly what people distrust when their livelihood is on the line. The organizations that actually close the perception gap do not communicate their way across it. They involve people in the decisions before there is anything to communicate.

What Closing the Gap Actually Looks Like

The organizations making real progress share a pattern that looks nothing like a communication strategy. They start by asking different questions. Not “how do we get employees to adopt AI?” but “what work do you want to do? What work do you hate? Where do you lose time to tasks that do not require your judgment?” Vizient, the healthcare performance improvement company, took this approach before deploying any AI tools. They built personas and playbooks around what their workforce actually wanted their roles to become. The result was not just higher adoption. It was genuine ownership. People adopted the tools because the tools were designed around their preferences, not imposed despite them. This is not a soft approach. It is structurally different from the standard deployment model. The standard model decides what AI will do, then tells the workforce. The alternative decides with the workforce what problems are worth solving, then selects tools accordingly. The difference in adoption, trust, and sustained behavior change is not marginal. It is categorical. The practical moves are specific: Involve employees in identifying which tasks AI should augment.

Not as a feedback exercise after the strategy is set, but as a design input before it begins. When people participate in defining how their work changes, the perception gap closes because the gap was never about information. It was about agency. Make leadership’s AI use visible. One of the strongest findings from practitioners working on AI adoption is that visible leadership modeling, leaders demonstrating their own AI workflows, their own struggles, their own learning curve, does more for adoption than any training program. When a VP shares how they used AI to prepare for a board meeting and what it got wrong, that single act of vulnerability communicates more than a hundred slides about the future of work. Create reflection loops, not just training sessions. The research on AI fluency is clear: people who verbalize what they learned, who connect the AI use case to their own work out loud, retain and apply the skill. People who sit through a demo and return to their desk forget 50% within a day and 90% within a week.

The difference is not the content. It is whether the person had to think about what it means for them, specifically. Stop using the word “transformation” without naming what stays the same. The perception gap is partly a fear gap, and fear responds to specificity. When leadership can articulate not just what is changing but what is not, what roles are protected, what skills remain essential, what institutional knowledge becomes more valuable rather than less, the anxiety that drives the gap begins to lose its grip.

The Real Stakes

The perception gap is not just an adoption problem. It is a strategy problem. Organizations making AI investment decisions based on executive perception of success are allocating resources against a version of reality that their frontline workforce does not share and may be actively undermining. The dashboards say adoption is at 80%. The actual behavior says adoption is performative. The training metrics say 500 employees completed the AI certification. The workflow data says those 500 employees are still doing their jobs the same way they did six months ago. Every week this gap persists, it compounds. Executives become more confident in a narrative that is increasingly disconnected from operational reality. Employees become more entrenched in protective behaviors that prevent the very transformation leadership is measuring. And the organization loses the one thing that makes AI adoption work: the institutional knowledge, contextual judgment, and domain expertise that only comes from a workforce that is genuinely engaged rather than performatively compliant.

This is not a technology problem. It is not even a change management problem, at least not in the way most organizations practice change management. It is a trust problem that lives in the gap between what leadership believes is happening and what the workforce experiences every day. The organizations that close this gap will not just have better AI adoption metrics. They will have something far more valuable: a workforce that is actively participating in its own transformation rather than bracing against it. And in a world where human consensus is becoming the primary constraint on organizational speed, that difference is the difference between an AI strategy that works and one that just looks like it does. Want to close the perception gap in your organization? Let’s talk about how our facilitated sessions can surface the real barriers to AI adoption and build the trust that no training program can manufacture.

Frequently Asked Questions

What is the AI perception gap?

The AI perception gap is the measurable divide between how executives experience AI in their organization and how individual contributors experience it. Gartner’s 2025 data shows executives are four times more likely to report high productivity gains; ICs are five times more likely to say AI made no difference. The gap is not a misunderstanding. It is two groups of people filtering the same data through different stakes and arriving at incompatible conclusions.

Why do executives and employees see AI so differently?

Because they have different cognitive skin in the game. Executives authorized the AI investment and have to believe it is working. Frontline workers see the displacement headlines and have to believe it is not as transformative as leadership claims. Both responses are rational given the position. The gap is psychological, not informational, which is why communication strategies fail to close it.

How do you close the AI perception gap?

Not through better communication. Communication treats the gap as an information deficit when the real problem is a trust deficit. The organizations closing it involve workers in the decisions before there is anything to communicate. They ask which tasks people actually want AI to help with, design around those answers, and build visible leadership modeling and reflection loops into the rollout. The mechanism is agency, not messaging.

What does the perception gap mean for AI strategy?

It means most AI strategy decisions are being made against a version of reality the frontline workforce does not share and may be actively undermining. Adoption metrics look fine because licenses are being opened. Real behavior tells a different story. Strategy that does not close the gap optimizes for the wrong picture and underdelivers on the investment.

Is the AI perception gap getting worse?

Yes, on current trajectories. Every week the gap persists, executives become more confident in a narrative that is increasingly disconnected from operational reality, while employees become more entrenched in protective behaviors that prevent the transformation leadership is measuring. The compounding effect is the reason the gap shows up as a strategy problem, not just an adoption problem.

The post The Perception Gap appeared first on Voltage Control.

In 2017 I gave a talk at Facilitation Lab on language models in facilitation. Most people in the room had not heard of GPT. The thesis I put on the screen was simple: the technology side would outrun every organization’s ability to absorb it, and the human side would become the bottleneck. Around the same time I was advising Kungfu.ai with Stephen. His bet was on building AI. Mine was on building the human capability that would have to grow around it. I founded Voltage Control to make that second bet, and I have made it every year since. Eight years later the thesis is no longer abstract. Organizations are not choosing between using AI and not using it. They are being pulled into two different futures, and the middle ground is disappearing. One future is deep tech: organizations that have built genuine infrastructure, deployed agents at scale, automated workflows end to end, and are operating with AI as a core organizational capability, not a feature. The other future is deep human: organizations that have recognized that the hard part was never the technology, that it was always the people, the trust, the identity questions, the way groups make decisions under uncertainty. They are investing in the human capability that makes any technology productive. The space between these two positions is collapsing. You can see it in the data now. I have been waiting for the research to catch up to the pattern. It has.

The Evidence of the Split

Gartner’s Digital Workplace Summit this year surfaced a finding that should land harder than it has: executives are four times more likely to report high AI productivity gains from their AI investments, while individual contributors are five times more likely to say AI made no difference to their work. That is not a technology gap. The tools are the same. The gap is in how the technology is being experienced, and it maps almost perfectly onto the structure of most enterprise AI programs: leadership makes the decision, licenses get purchased, individuals get trained once and then largely ignored, and the two groups live in completely different realities about what is happening. Four out of five employees believe their organization is trying to replace them with AI. Only 12% feel involved in the decisions about how AI gets used in their work. 78% do not know whether they will lose their job to AI. These are not the stats of an organization that is integrating AI. These are the stats of an organization that has deployed AI at its leadership layer and left the rest of the workforce in the dark. And when 14% of leaders believe employees are effectively using the tools they have been given, the people making deployment decisions and the people living with the consequences are not operating from the same reality. This is what the bifurcation looks like from the inside.

What Is Actually Happening

The technology is not the problem. The technology, in most enterprise contexts, is working. 72% of IT leaders say Copilot users struggle to integrate it into their daily routine, but the failure mode there is not the tool. It is the design of how adoption happens. The World Economic Forum projects that 59% of the workforce needs brand new skills in the next two to three years. Gartner estimates that 32 million jobs will be transformed per year due to AI, and that managing this transformation requires 20 times more organizational effort than managing job losses. The effort ratio is 20 to 1. That 20:1 figure is the one that should reorient every AI strategy. Organizations are allocating budget and attention as though this were a technology problem, when the data says it is primarily an organizational problem. The work of transformation is not writing code or buying software. It is the human work: the alignment conversations, the role redesigns, the trust-building, the change management, the process of getting a 40,000-person organization to operate differently. That work does not scale through typical training programs. Without application and practice, half of what people learn from a one-time training session is gone within 24 hours. 90% is gone within six days. Learning decay does not care how good the content was.

Two Organizations, Same Technology

The split is easier to see in examples than in statistics. At Gartner’s Digital Workplace Summit, Ivanti presented their approach to internal AI transformation. They built a centralized AI platform called Ivy and created AI pods, cross-functional environments where subject matter experts, senior DBAs, network engineers, storage specialists, rotate through and imbue AI models with their domain expertise. The output is what Gartner called “cybernetic teammates”: AI agents that carry the actual knowledge and judgment of specific senior practitioners, available to everyone in the organization, not just to the people who happen to sit near the expert. They surfaced approximately 700 AI use cases this way. The mechanism was not a training program. It was a structured process for capturing and distributing human expertise at scale. In Manchester, University NHS Foundation Trust deployed Microsoft Dragon Copilot to give doctors back something they had been losing: full attention on the patient in front of them. The voice AI handles transcription and note-taking in real time. The doctor reviews, edits, and approves. The consultation, the actual human work, is now uninterrupted. Manchester’s Chief Executive has estimated that at full rollout, the trust could see up to 250,000 additional patients per year. That number is a projection, not a measured result, and it depends on redesigning scheduling, staffing, and workflow to convert freed-up minutes into actual appointments. The technology is the easy part. The organizational redesign is the work. These two cases look different on the surface. One is an IT infrastructure vendor restructuring how expertise flows across their organization. The other is a hospital trust giving clinicians room to be clinicians. But they are both illustrations of the same underlying logic: AI works when it is designed around what humans do best, not when it is deployed as a replacement for the conversation about what that even means.

The Wrong Approach

The organizations going in the wrong direction are not doing obviously foolish things. They are doing reasonable things, badly sequenced. They buy licenses before they understand the work. They run training programs before they have addressed the trust deficit. They announce AI strategies without involving the people those strategies will affect. And then they are surprised when license usage stays flat, when the productivity gains are invisible to the people on the ground, when the AI-fluent individuals they develop become isolated experts rather than multipliers. 56% of CEOs plan to use AI to de-layer middle management within five years. The question is not whether that flattening is coming. It is whether anyone is designing what replaces the development pathways that disappear when it does. Middle management is not just overhead. It is the layer through which expertise gets transferred, context gets communicated, and junior people get the reps that build them into senior people. Remove the layer without replacing the function and you have an experience starvation problem: senior experts absorbing work that used to be the proving ground for the next generation. The pipeline for building bench strength quietly breaks. AI is not taking entry-level jobs. Experts are. That is a subtly different problem that requires a subtly different response.

Where Facilitation Lives

I keep coming back to this: there needs to be a function in organizations that lives at the intersection of all the functional groups. Not IT. Not HR. Not change management as it is currently practiced. A function that understands how groups make decisions under uncertainty, how trust is built and broken, how to create conditions where people can learn through doing rather than just through instruction. That is a facilitation function. And AI does not make it less important. It makes it more important. When you deploy AI at speed, you compress the timeline for every organizational friction. Decisions that used to take weeks get made in hours. Alignment gaps that used to surface slowly become visible immediately. The process problems that were tolerable before, the meetings where nothing gets decided, the strategies that make sense to leadership and mean nothing to the people executing them, those problems do not disappear with AI. They get louder. More inputs and faster inputs can slow alignment down if the process is broken. The organizations getting real value from AI have not solved a technology problem. They have figured out how to have the conversations that the technology makes urgent: about what work means, about who has agency over it, about how expertise flows and gets recognized, about what you are actually trying to do when you say you want to be AI-ready. The dotted line between deep tech and deep human is not a gap to be closed by more tools. It is where the work happens.

The Choice

The bifurcation is not a prediction. It is already underway. The organizations making real investments in both the technology and the human infrastructure to absorb it are pulling ahead. The ones waiting for the technology to prove itself before investing in the organizational side are falling behind, and the gap is compounding. You cannot address the organizational side with the same logic you used to deploy the technology. You cannot train your way to psychological safety. You cannot mandate your way to trust. You cannot run a workshop that solves the identity questions AI raises for the people whose work is changing. What you can do is design environments where those questions get answered through practice, where people learn by doing in conditions that are structured enough to be safe and real enough to matter. Where the facilitation is not an add-on to the AI strategy but the architecture that makes the AI strategy possible. That is the choice. Deep tech alone will get you capability without adoption. Deep human alone will get you culture without leverage. The organizations that understand both, and that have someone whose job it is to hold the space between them, are the ones that will compound the gains. Everything else is just expensive licensing. If you are building AI strategy and finding that the human side keeps creating more problems than the tools solve, let’s talk.

Frequently Asked Questions

What is the difference between deep tech and deep human organizations?

Deep tech organizations have built real AI infrastructure, deployed agents at scale, and treat AI as a core capability rather than a feature. Deep human organizations have recognized that the hard part was never the technology; it was always the trust, identity, and decision-making capacity that lets any technology produce value. The two are not opposed. The bifurcation is happening because most organizations are investing heavily in one side and ignoring the other, and the middle ground is collapsing.

Why is the middle ground collapsing for organizational AI strategy?

Because AI compresses the timeline on every organizational friction. When the technology was slower, organizations could afford to ignore the trust gap, the identity questions, and the decision-rights ambiguity. AI makes those frictions immediate. The 20:1 ratio Gartner reported, that managing AI-driven transformation requires twenty times more organizational effort than managing job losses, is the quantitative version of this collapse. Half-measures stop working.

How do you build organizational trust during AI transformation?

By involving the workforce in how AI reshapes their roles before deployment, not after. Organizations that get this right, like Ivanti’s AI pods or Manchester NHS’s Dragon rollout, are not announcing AI strategy and asking people to comply. They are bringing subject matter experts and frontline workers into the design of how the technology gets used. The mechanism is structural, not communicative; trust comes from agency, not from town halls.

What does “deep human” mean in organizational AI strategy?

Deep human means investing in the human capability that makes any technology productive: facilitation skills, decision rights design, trust-building practices, role redesign, and the developmental experiences that build judgment over time. It is not the soft side of AI strategy. It is the architecture that makes deep tech work. Organizations that go deep tech without deep human get capability without adoption.

Should organizations invest in AI technology or human capability?

Both, in sequence and in proportion. Most organizations are 95% tech investment and 5% human investment, and that ratio is what produces the executive/IC perception gap, the experience starvation pattern, and the 70% IT-leader concern about agent governance. The organizations pulling ahead invest in both at roughly the level the 20:1 effort ratio implies: most of the work is the human work, and treating it as a side-project alongside the technology budget is the failure mode the bifurcation reveals.

The post Deep Tech or Deep Human appeared first on Voltage Control.

Most organizations are spending real money on AI adoption and getting almost nothing back. Not because the tools are bad. Because the approach is broken. The pattern is predictable at this point. An organization buys licenses, schedules training sessions, maybe runs a webinar series, and waits for transformation to happen. Gartner’s research shows what comes next: within a day, employees have lost 50% of what they learned. After six days, 90% is gone. License counts rise. Active daily usage stays flat. This is not a training problem. It is a design problem. And the organizations figuring that out are doing something fundamentally different from the rest.

Why Training Doesn’t Work (And What the Data Actually Says)

The evidence against one-time AI training is now overwhelming, and it comes from multiple directions. Gartner’s Digital Workplace Summit data shows that 72% of IT leaders say Copilot users struggle to integrate it into their daily routine. When Gartner surveyed what happens after AI training events, they found the same pattern across enterprises: usage spikes briefly, then drops to near zero. The classroom model produces AI literacy at best. It does not produce fluency. Anthropic’s Economic Index, drawn from over a million real conversations, found that experienced AI users get measurably better results than newcomers, and the gap compounds over time. People who have used AI for six months or more have a 10% higher success rate. The difference is not explained by what tasks they do or what tools they use. It is explained by how they interact.

Experienced users iterate, push back, validate, and treat AI as a collaborator. New users delegate and accept. That gap does not close with more training sessions. It closes with practice. The organizations that participated in our first AI Ways of Working executive mastermind confirmed this from the practitioner side. Leaders from enterprises spanning education, healthcare, gaming, and automotive all reported the same thing: training events produce a temporary spike, not a lasting change. The organizations seeing real traction are doing something structurally different. What emerged from that conversation, reinforced by Gartner’s research and confirmed by Anthropic’s behavioral data, is a three-part framework. Not a training program. A design pattern for how organizations build AI fluency that actually sticks.

Step 1: Leadership Modeling

The first step is the one most organizations skip entirely: leaders must visibly use AI themselves. This sounds obvious. It is not happening. In most organizations, the executives who approve AI budgets and mandate adoption are not demonstrating their own use. They talk about AI strategy in all-hands meetings. They do not show their team what it looks like when they use AI to prepare for a board meeting, draft a strategy document, or pressure-test a decision. The gap between what leaders say and what leaders do is the single biggest reason AI adoption stalls. When employees see their manager using AI as a genuine part of their work, not as a demo or a gimmick, it does two things simultaneously. It signals that AI use is safe, removing the fear that experimenting with the tool will be perceived as incompetence or laziness. And it makes the abstract concrete. A leader showing how they used AI to restructure a presentation or challenge their own assumptions about a market entry gives their team a mental model for what “good” looks like. Gartner’s keynote research named this as one of three cultural pillars for AI adoption: leaders use tools and share stories, not mandates.

The distinction matters. A mandate creates compliance. A demonstration creates curiosity. Cynthia Phillips, an industrial psychologist who presented at Gartner’s Digital Workplace Summit, found that 70% of employees are unsure whether they will lose their job by adopting AI technology. They will not voice this fear publicly. They make a silent calculation: “Is this story going to work out well for me?” When leaders model AI use, they are not just showing a workflow. They are answering that silent question. They are showing that AI is part of how this organization works, not a threat to how people work in it. The standard objection is that senior leaders do not have time to become AI power users. That is the wrong frame. Leaders do not need to be the most fluent AI users on their team. They need to be visible ones. A five-minute story in a team meeting about how AI helped them rethink a problem is worth more than a month of training content.

Step 2: Guided Practice

The second step replaces open-ended exploration with small, specific assignments. Most AI training programs make the same mistake: they give people access to tools and tell them to experiment. This sounds empowering. In practice, it produces paralysis. When someone who has never used AI sits down in front of a blank prompt window, the most common response is to try something trivial, get a mediocre result, and conclude the tool is not useful for their real work. Guided practice means giving people five specific things to try, not fifty. It means designing prompts that connect directly to their actual workflows, not generic demonstrations. It means scoping the initial experience so that success is likely and the connection to real work is immediate. Tori Paulman, the Gartner analyst who authored the executive/IC perception gap research, calls this the difference between AI literacy and AI fluency. Literacy means you can use the tool functionally. Fluency means you can operate in context without consciously thinking about the tool.

Generic training produces literacy at best. Fluency requires daily applied use in the context of real work. Her recommended approach is what she calls the “Option 3” workflow: an expert builds the prompt or template, a less experienced team member executes with AI, and the expert reviews the output. This preserves learning for the person developing skills while capturing the efficiency of AI. It is slower than having the expert do everything with AI alone. It is the only approach that does not hollow out your talent pipeline in the process. The guided practice step is where most organizations fail because it requires design work. Someone has to identify the five most valuable AI applications for a specific role, build the prompts or templates, and create the conditions for people to try them with low stakes. That is not a training department function. It is a facilitation challenge: designing an experience where people can build capability through practice, not instruction. The practical difference is stark. An organization that sends employees to a 90-minute AI workshop gets a usage spike that decays within a week. An organization that gives a team of five a set of role-specific AI exercises to complete over two weeks, with a shared debrief at the end, gets durable behavior change. The content matters less than the structure.

Step 3: Reflection Loops

The third step is the one that makes the first two compound: structured reflection after practice. This is the piece that separates organizations with scattered AI adoption from organizations where fluency is spreading. After a demonstration, after a guided exercise, after someone tries something new with AI, there is a moment where the learning either sticks or evaporates. That moment is the reflection loop. A reflection loop is simple in concept: after experiencing AI in action, teams are prompted to connect what they just saw to their own work. Not “what did you think of that demo?” but “where in your workflow would this apply?” Not “was that impressive?” but “what would you need to change about how you work to use this?” The mechanism is verbalization. When someone articulates out loud how an AI capability connects to their specific context, they are doing the cognitive work that transforms observation into intention. Without that step, demonstrations stay abstract. People walk away thinking “that was interesting” without building a bridge to their own practice. This is not new learning science. It is how skill development works in every domain. Athletes review film. Musicians rehearse, then debrief with their instructor. Surgeons do morbidity and mortality conferences after complex cases. The pattern is always the same: do the thing, then reflect on the thing, then do it again better. AI fluency follows the same pattern.

What makes reflection loops particularly powerful in the AI context is that they surface the real barriers to adoption. When a team discusses where AI would apply in their work, the conversation inevitably surfaces the actual obstacles: “I do not trust the output enough to send it to a client without heavy editing.” “My manager has not said whether it is okay to use AI for this.” “I tried it once and the result was useless because it did not have access to our internal data.” These are not training problems. They are organizational design problems. And they only become visible when people reflect together on their experience. The enterprises in our executive mastermind who are seeing real traction are running these loops consistently. Not as formal programs. As a practice embedded in how teams already work: five minutes at the end of a team meeting to share what someone tried with AI that week and what they learned. A monthly session where a team reviews their AI experiments and decides what to scale and what to drop. A quarterly retrospective where leadership hears directly from practitioners about what is working and what is not. The cadence matters more than the format. Weekly is better than monthly. Monthly is better than quarterly. Quarterly is better than never. The point is not perfection. The point is creating a recurring structure where AI fluency develops through shared experience rather than individual trial and error.

Why This Framework Works (And Training Programs Don’t)

The reason these three steps work where training fails comes down to a fundamental misunderstanding about what AI fluency actually is. Most organizations treat AI adoption as a knowledge transfer problem: teach people how to write prompts, show them the features, quiz them on best practices. But AI fluency is not knowledge. It is a practice. It is closer to fitness than education. You do not get fluent by attending a lecture. You get fluent by showing up consistently and doing the work. The three steps, modeling, guided practice, and reflection, create the conditions for practice to happen. Modeling removes the fear barrier and provides a mental model. Guided practice gives people a specific, low-risk entry point connected to their real work. Reflection loops turn individual experiments into shared learning that compounds across the team. This is also why the “train the champions” approach that many organizations default to consistently underperforms. Champions without a collaborative model become isolated experts. They develop fluency on their own, but they cannot embed what they are learning back into the team. The team’s processes, meetings, and decision-making structures have not changed. The champion ends up on an island. The three-step framework avoids this trap because every step is inherently collaborative. Leaders model in front of their teams. Guided practice is designed for specific roles within a team context. Reflection loops are group activities. AI fluency spreads through the team, not around it.

The Stakes

The urgency here is not abstract. Anthropic’s data shows that the gap between experienced and new AI users is hardening into something structural. The people who started early are pulling further ahead. Gartner projects that by 2027, 75% of hiring processes will include AI proficiency testing. The workforce is bifurcating between people who can work with AI as a genuine collaborator and people who either cannot use it effectively or have let it do their thinking for them. 59% of the workforce needs fundamentally new skills in the next two to three years. That number does not get solved by scaling up existing training approaches. It requires a different design. The organizations that treat AI adoption as a training problem will keep buying licenses that do not get used, running workshops that do not stick, and watching the gap between their most fluent employees and everyone else widen. The organizations that treat it as a practice problem, one that requires visible leadership, structured entry points, and shared reflection, will be the ones where AI fluency actually takes root and compounds. The tools are ready. The question is whether your organization is designed to help people use them. If you are rethinking how your teams build real AI fluency and want to explore what a practice-based approach looks like, let’s talk.

Frequently Asked Questions

How do you successfully implement AI in an organization?

Successful AI implementation is a practice problem, not a training problem. The organizations that get it right design three things: visible leadership use that signals AI is safe and valuable, guided practice that gives people specific role-relevant prompts to try, and reflection loops that turn individual experiments into shared learning. Training programs alone produce a usage spike that decays within a week. The three-step design produces durable behavior change.

What role do leaders play in AI adoption?

Leaders do not need to be the most fluent AI users in the room. They need to be visible ones. When employees see their manager using AI to prepare for a board meeting or pressure-test a decision, it answers the silent question 70% of employees are quietly asking: “is this story going to work out well for me?” Modeling is the single biggest determinant of whether AI adoption sticks at scale.

Why do most AI initiatives fail to scale?

Most AI initiatives fail because organizations buy licenses and schedule training, then expect adoption to happen on its own. Gartner data shows employees lose 50% of what they learn within a day, 90% within a week. License counts rise while active daily usage stays flat. The failure mode is structural: organizations are treating fluency as a knowledge problem rather than a practice problem.

How can teams build AI fluency together?

AI fluency builds through shared practice and shared reflection, not through individual training. Teams that build fluency together typically run a recurring structure: leaders show their own AI use in team meetings, team members try role-specific prompts in low-stakes contexts, and the group debriefs together on what is working. The cadence matters more than the format. Weekly beats monthly beats quarterly beats never.

What is the best framework for AI transformation?

The framework that works is one that treats AI fluency as a designed practice rather than a delivered curriculum. Three steps consistently separate organizations where AI sticks from those where it does not: leadership modeling (visible, not mandated), guided practice (specific, role-tied, low-stakes), and reflection loops (recurring, team-based, focused on what to keep doing). All three are required. Skipping any one of them produces the standard failure mode.

The post Three Steps to Make AI Actually Stick appeared first on Voltage Control.

“Collaborative AI” is the buzziest term of 2026. Vendors use it. Analysts use it. LinkedIn thought leaders use it. Most of the time it means almost nothing, because the term has been stretched to cover three completely different things at once. A diagram of multiple agents handing tasks to each other gets called collaborative AI. A single user prompting ChatGPT for help gets called collaborative AI. A team using a shared model in a meeting gets called collaborative AI. Three different things, one term. And the thing that actually matters, the thing that is genuinely new about how teams are starting to work with AI, gets buried under the other two. This piece is a working definition. Not the marketing one. The one that lines up with what we actually see when we walk into rooms where teams are doing this well, and what is missing from the rooms where they are not.

The shallow definition (and why it does not help you)

The most common use of “collaborative AI” right now describes a multi-agent architecture. One AI agent generates a draft, hands it to a second agent for review, hands the result to a third for formatting. The agents are collaborating with each other. The diagram is impressive. The phrase has obvious appeal. This is a useful technical pattern. It is not collaboration in any sense that matters for how people work. There are no humans in the loop. The collaboration is between models. Calling this “collaborative AI” is like calling a pipeline “collaborative software.” The work flows through stages, but no one is collaborating. The shallow definition gets worse when it is applied to a single person using a chatbot. Someone types a prompt, the model returns text, the person edits it, sends another prompt. This is not collaboration. It is iterative tool use. Useful, fast, and individual. The output reflects one person’s thinking improved by a model. No one else’s perspective is in the room. If you are looking for what actually changes when AI shows up in a team’s workflow, neither of those definitions will help you.

The working definition

Here is the one that holds up in practice. Collaborative AI is the practice of bringing AI into the room with a team, where it influences collective thinking and output in real time, with shared visibility into how the model is contributing. Three pieces matter, and all three have to be present. In the room with a team. Not one person alone with a chat window. A group, working together, with an AI participating in the work. This could be a workshop, a strategy session, a stand-up, a planning call. The AI is on the screen, not in someone’s pocket. Shapes the team’s collective output in real time. The model is generating, summarizing, surfacing patterns, drafting alternatives.

Whatever the team is producing is being changed by the AI as the team works. Not after the meeting, in someone’s editor. During. Shared visibility into how the model is contributing . This is the part that gets skipped, and it is the part that determines whether the AI helps the team or quietly hurts them. Everyone in the room knows the model is contributing, knows what it has produced, can see what is generated AI versus team thinking, and has the chance to push back. The AI is a participant, not a hidden assistant. When all three are present, you get something that does not happen with individual AI use or multi-agent pipelines. You get a team that can think faster together, with a shared artifact that captures what the model contributed and what the people contributed, and a record of where they pushed back. That is collaborative AI. Everything else is either delegation (one person and a model) or automation (models talking to models).

What collaborative AI looks like when it works

A leadership team gathers to align on a strategic question. The question is on the screen. So is a model. The facilitator runs the team through a structured divergence: each person types a position privately, the model surfaces themes across the responses, the themes go up on the wall. The team sees the patterns the model found and the dissents the model missed. They argue with the model’s framing. They edit the themes. They re-run the synthesis with their corrections. Two hours in, the team has alignment on a position they could not have produced in two hours without the AI. They also have a record of what the model contributed and where they overrode it. The output is theirs. The model accelerated the path to it. Now imagine the same team, same question, without collaborative AI. Three options.

Option A. Each person prepares their position alone, with their own AI assistant. They come to the meeting with polished drafts that look similar because the underlying models trained on similar content. Discussion devolves into refining the most articulate draft instead of surfacing the real disagreement. The model contributed to each person individually. It did not contribute to the team.

Option B. They run the meeting without AI, fill the wall with sticky notes, take photos for the recap, and the synthesis happens later, in someone’s editor, with a model. The synthesis returns from the model and people argue about whether it captured the room. The model is reading, not collaborating.

Option C. They run a multi-agent system that takes meeting transcripts, summarizes them, drafts strategic options. The output looks like collaboration. No one is in the room with the model. The team is consuming AI output, not shaping it. Each option uses AI. Only the first is collaborative AI as the term should be used.

What it requires from teams (and most teams do not have)

The reason collaborative AI works in some rooms and not others has nothing to do with the model. The model is the same. What changes is what the team brings. A facilitator who can hold the room with AI in it. Most facilitation training assumes the facilitator’s job is to manage human dynamics. With AI in the room, the facilitator’s job expands. Who decides when to use the model? When does the model’s output get accepted, and when does it get pushed back on? Who notices when the model is steering the conversation toward a generic framing the team would not have chosen on its own? These are facilitation moves that did not exist three years ago. Teams that have someone who can run them get collaborative AI. Teams that do not, fall back to one of the three options above. Shared norms about transparency.

The team has to agree, before the session, on what AI use looks like in the room. Is everyone using it? Are some people privately using it while others are not? Is the model running publicly on the screen, or quietly assisting one person? When AI use is visible, the team can engage with it. When it is hidden, it distorts the room. A working understanding of what the model is good at and what it is not. Models are excellent at synthesis, summarization, divergent generation, and surfacing patterns across text. They are bad at judgment under uncertainty, weighing competing values, and noticing what is missing from a conversation. Teams that know this use the model where it helps and override it where it does not. Teams that do not, drift toward whatever the model recommends. These three capabilities are not technical. They are practices. And practices are slow to build, because they require facilitated repetition.

The branding problem

Most “collaborative AI” content you will read in 2026 will be one of the two shallow definitions, dressed up in language that makes it sound like the working one. Vendors have an incentive to call any AI feature collaborative because the word is selling well. The diagram is collaborative. The chatbot is collaborative. The agent network is collaborative. None of them require what real collaboration requires, which is more than one person in the same room making decisions together. The risk for buyers is straightforward: you procure something labeled collaborative AI, deploy it across the organization, and discover that it is a productivity tool for individuals. People use it alone, at their desks, between meetings. The team-level capability you were trying to build never materializes, because the tool was never going to build it. The capability is built by humans, not software. The good news is that the actual practice of collaborative AI does not require a particular vendor. The model layer is a commodity. What is scarce is the facilitation layer on top, and that is what teams have to build for themselves.

Where this fits in the broader shift

This is one piece of a larger pattern. The friction that matters in 2026 is no longer execution speed. AI eliminated that friction. The friction that matters is consensus, alignment, and trust at the team and organization level. AI accelerates execution; it does not, on its own, build alignment. In some configurations it makes alignment harder, because individual users move so fast that the team cannot keep up. Collaborative AI is the response to that. It is what happens when teams refuse to let AI become a private productivity boost and instead bring it into the room as a shared participant. The benefit is real: faster alignment, better synthesis, decisions that more people genuinely own. The cost is that someone has to facilitate it, and most organizations have not built that capability yet. That is the work in front of leadership teams right now. Not picking the right collaborative AI vendor. Building the team practices that make any AI collaborative.

What to do this quarter

If you are leading a team and want to start moving toward collaborative AI:

Pick one recurring meeting. Not a high-stakes one. A regular planning or review session where the team is already aligned on the format. This is your test environment.

Put a model on the screen. Shared, visible, running. The output of the model goes up where everyone can see it, edit it, push back on it.

Name AI use explicitly. When the model contributes something, say so. When someone overrides it, say so. The transparency is what makes the next session better.

Run it for four weeks. The first session will feel awkward. The second will be better. By the fourth, the team will start to develop instincts about when to invoke the model, when to override it, and how to use it without losing their own judgment. After four weeks, you will know if you have built the practice. You will also know what you need from a facilitator, from governance, and from team training to scale it.

The teams that build this capability now will compound on it for the next decade. The teams that wait for the right vendor or the right tool will still be looking for the right vendor when the friction has moved somewhere else. That is the difference between collaborative AI as branding and collaborative AI as a capability. The branding will keep shifting. The capability is yours once you build it.

The post Collaborative AI appeared first on Voltage Control.

Most writing about AI change management is about using AI to do change management work. AI-powered surveys, AI-coached stakeholder communications, AI-generated resistance reports. That angle dominates the top results on this search term. McKinsey, Prosci, IBM, ICAgile, Udemy all lean there.

We mean the inverse: managing the human and organizational change that AI adoption requires.

This is not a semantic distinction. The gap between those two framings is exactly the gap between organizations that get AI working and organizations that stall for two years wondering why. When you treat AI change management as a tooling problem, you solve for the wrong variable. The tool is rarely the reason transformation fails.

The case that makes this concrete involves two trucks and a container port.

Two trucks break down in a port. They are thirty meters apart, on the same lane, carrying the same cargo. One port zone recovers from the disruption in seventy minutes. The other takes more than two hours. The zones share everything that matters: the same bridges, the same lane widths, the same weather, the same sixty-second mechanical fault. The only difference is coordination. In the slow-recovery zone, a single algorithm dispatches every vehicle. In the fast-recovery zone, that same algorithm shares infrastructure with a fleet of trucks driven by independent logistics companies, each operating under its own objectives.

That is the finding M. Dalbert Ma, a researcher at London Business School, reported to the BIG.AI@MIT conference this year, after studying approximately one year of operations at one of the world’s largest container terminals. The autonomous zones ran 3.8% more efficiently under normal conditions. A single sixty-second fault cost them a 12.2% delay on the operations that followed. Rain, which forces every vehicle to slow and creates temporal buffer between sequential operations, erased the fragility entirely.

This is what most AI transformation stories leave out. The efficiency gain is real. So is the cost you pay when something disrupts it. Real AI change management is the work of managing that tradeoff before the fault arrives, not after.

The 5 Frictions of AI Transformation

Every AI transformation engagement we have worked runs into the same five blockers. Not technology failures. Human and organizational frictions that the tool vendors do not mention and the training programs do not cover.

We call this the 5 Frictions framework. Each friction is distinct, each stalls transformation in a different way, and each requires a different response.

The Identity Friction. When knowledge workers are asked to share their specialized knowledge with AI systems, a real fear surfaces. The fear is not irrational. Their expertise is the basis of their value. AI that learns from their domain know-how threatens the moat they have spent years building. At one of our executive dinners this spring, the framing that landed cleanest was this: when people are asked to give their knowledge away, they experience it as becoming disposable. Identity work is not soft. It is the most operational blocker on your AI adoption agenda, and leaders who skip it discover the passive resistance later, when workflows are technically live but adoption stays flat.

The Leadership Friction. Leaders who are not personally using AI cannot guide teams that are. If you are not using AI on the order of every hour, you cannot evaluate which of your teams’ experiments have merit, which are theater, and which represent a genuine capability gain. You are coaching a sport you have never played. The practitioners in the room can tell immediately. This framing has now come up at every executive dinner we have run across Boston, Boulder, Houston, and Dallas, without prompting. The corollary the Boulder room added sharpens it: even when the CEO mandates AI adoption, if there is no facilitation and no design behind the rollout, the burden falls on already-overwhelmed individual contributors and the initiative fails.

The Capability Friction. Every AI-first workflow your organization designs makes a structural tradeoff. When execution time collapses, coupling tightens. When coupling tightens, buffer disappears. The same mechanism that produces the efficiency also produces the fragility. And beneath the efficiency numbers, something is accumulating invisibly: the growing gap between your organization’s apparent capacity and its actual adaptive capacity. JoAnna Vanderhoef named this Capability Debt at the BIG.AI@MIT conference in 2026. We will return to it in detail below, because it is the friction with the most solid research base and the most counterintuitive implication.

The Measurement Friction. The metrics organizations reach for first, time saved, tokens consumed, story points closed, either cannot be measured cleanly or create perverse incentives. At three consecutive dinners this year, we asked the room what they were measuring and whether it was working. Not once did a satisfying answer emerge. What surfaced instead were stories about measurement going wrong: algorithms that extrapolated to billions of hours saved, CEOs who set token-consumption targets that had teams running meaningless jobs at night just to hit the number, story-point metrics that broke down the moment AI made commits larger. The measurement problem is real, and the solution is not a better metric. It is a different understanding of what counts as progress during early-stage AI adoption.

The Sequencing Friction. Who does what, when, in what order? Most organizations have not answered this. They have an AI strategy document and a handful of enthusiastic early adopters and no clear answer to the role questions: who is the AI champion, who is the AI lead, what decisions belong to an AI governance council, what does AI ops mean for their context. Without those answers, every initiative stalls at the first ownership dispute. The sequencing friction is often invisible until it surfaces as a conflict, and by then it has already cost the organization months.

These five frictions do not appear on procurement spreadsheets. They are not solvable with a training event. They are the actual work of AI change management.

What the Evidence Shows

The Capability Friction is worth dwelling on, because it has the most solid research base and the most counterintuitive implication for how organizations should design their AI adoption roadmaps.

JoAnna Vanderhoef’s concept, Capability Debt, describes the growing gap between an organization’s apparent efficiency and its adaptive capacity. It accumulates subtly, as absence. Absence of novelty detection. Absence of the junior employee who stumbled into the strange request and learned how to triage it. Absence of the reviewer who noticed the model’s output was technically correct and strategically wrong. Absence of the senior whose judgment was trained on edge cases the automated pipeline now handles without them.

You do not see the debt until you need to do something the system was not built for. By then, the people who would have done it have atrophied the capability, or have never built it at all.

This is the part of AI transformation that is easy to underweight in a board deck. Efficiency is legible. Judgment loss is not. It hides inside the year-over-year improvement metrics and inside the reduced headcount and inside the deliverables that ship faster and look clean until a situation arrives that needs taste, or context, or the ability to know what is not in the data.

A team of researchers at MIT, Yale, and Microsoft, led by Mert Demirer, formalized the mechanism for where the debt accumulates fastest. They call it AI chains. An AI chain is a sequence of production steps in which the automated steps are contiguous. The human at the end verifies only the final output. The economic incentive is to keep adding steps to the chain until the marginal failure probability overwhelms the saved verification cost.

The jobs that get automated fastest are the ones where AI-suitable work clusters together. Lecture preparation is one such job. Research, drafting, slide generation, and example synthesis are all AI-suitable, and they are sequential. A single verification at the end is sufficient. The chain collapses into one unit of human work.

Tutoring is the opposite. AI-suitable steps are interleaved with diagnostic steps that require real-time human judgment. The chain cannot form.

The second consequence is more important than the first. Jobs that form long AI chains are also the jobs where learning loops get shortest. The junior who used to do the research, draft the slides, and watch the senior edit them loses three apprenticeship cycles per deliverable. What was formerly a sequence of moments where skill formed now happens inside the model.

When your team maps its AI automation roadmap, the blocks to be careful about are the contiguous ones. They are where the efficiency gain is largest. They are also where the Capability Debt compounds the fastest.

What We Actually Saw in the Field

Research describes the mechanism. The practitioners in our dinner rooms describe the texture.

Two patterns showed up without prompting at every table this spring.

The first is the training blip. John Ippolito, at the time VP of Enterprise at Miro, shared a Gartner workplace-event graph at our Boston dinner that became the anchor reference for the rest of the evening. The graph shows a flat line of token consumption over time, with a single one-day spike coinciding with formal AI training, then an immediate return to baseline. Adoption of tools is rising. Real usage is not. Every practitioner at the table confirmed it independently. Rachel Brown from CIBC described what works instead: an every-other-week internal showcase where early adopters demonstrate live, the most junior employees show what they have built, and the room asks questions in a safe space. Not training. Social learning, designed and facilitated deliberately.

The most wasted line item in most AI transformation budgets is the training event that produces a one-day blip and nothing durable. The replacement is cheap and repeatable. But it requires someone willing to design and facilitate it, and that role has no title yet in most organizations.

The second pattern is measurement going wrong, and the stories are consistent enough across cities to treat as a pattern rather than an anomaly. Rachel’s head-of-AI at CIBC built a time-savings algorithm that extrapolated to billions of hours saved company-wide. Obviously wrong, and obvious only after the number became absurd. Jason Fournier, CEO of Imagine Learning, described a split his team lives with cleanly: they can measure curriculum creation precisely (from eighty thousand dollars and eight months down to four hundred dollars and four weeks), but cannot measure knowledge-worker productivity gains with any confidence the numbers mean what they appear to mean. Morgan Brown from Wayfair measured AI coding tools by story points, found the metric broke down, and discovered on further investigation that commits were growing in size even as counts fell. Ben Tao from Rockwell put the early-KPI trap cleanly: codify performance targets too soon, and you suppress the experimental behavior that would have surfaced the valuable patterns. “Do that too early, you’re suppressing the good seed.”

A third pattern, specific to organizations that have worked through the early frictions: the role redesign. At our Boulder dinner, one attendee described a customer service team that celebrates publicly when someone automates a meaningful portion of their work, specifically the phrase “automated 40%” landing in a team all-hands, followed by a deliberate conversation about what that person should do with the freed capacity. Two emergent role shapes are forming in that team: a white-glove tier for the most escalated and complex customer interactions where human judgment is irreplaceable, and an agent-orchestrator tier for the people who supervise and maintain agentic workflows. Those are not job titles they inherited from an org chart. They are shapes the team discovered by working through the frictions rather than around them.

For how to structure measurement that accounts for the phase your organization is actually in, rather than where you wish it were, see our piece on how to measure AI transformation success beyond productivity.

The Design Move Most Organizations Skip

Here is what separates the organizations that stall from the ones that scale.

Renée Gosline, in a MIT study presented at the BIG.AI conference, calls it beneficial friction. Her team ran a controlled experiment. Participants worked on cognitive tasks with AI assistance. In the control condition, the AI made its recommendation and the participant accepted or rejected it. In the treatment condition, before accepting or rejecting, the participant was asked to articulate their own reasoning, or to predict what the AI’s reasoning was. That small intervention, which took thirty seconds, measurably reduced over-reliance on AI and preserved the participant’s critical thinking.

This is the design move most organizations skip. They treat friction as waste. They are correct that some friction is waste. They are wrong that all friction is waste. The friction that forces a human to articulate their own judgment before anchoring on the AI’s output is the friction that carries the capability forward.

At the organizational level, beneficial friction looks like this. Decision rights reviews before an AI pipeline goes into production, where the team has to name who owns the outcome the pipeline is producing. Novelty drills, where a percentage of the work that could be automated is routed to humans anyway, so the capability stays alive. Signal sampling, where humans regularly review a random sample of AI outputs not for QA but for drift. Shadow-session reviews, where someone who has not been in the pipeline’s daily operation comes in and asks whether the pipeline is still doing the right thing.

None of these are productivity moves. All of them are capability moves. The point of beneficial friction is not to make the system slower. The point is to keep the system teachable.

AI Change Management Is a Leadership Problem

The organizations navigating this well understand something the organizations that are stalling do not. The new friction is not a technology problem. It is a leadership problem.

When execution was expensive, leadership’s job was to clear the path: remove the blocker, approve the budget, unstick the review cycle. That job is largely done. The organizations still doing it well at the leadership level are optimizing a bottleneck that is mostly already gone.

The new job is different. When execution is cheap and judgment is scarce, leadership’s job is to carry the organization’s judgment capacity forward. That means designing the decisions that matter, surfacing the dissent that would otherwise stay hidden, ensuring that the people who will need the skill later are getting the practice now. Getting executive buy-in for AI initiatives before the first pilot, not as damage control after, is one of the clearest signals we see between transformation programs that sustain and ones that die in the third quarter.

This is facilitation work. Not facilitation in the narrow sense of running meetings well, although that is part of it. Facilitation in the broader sense of helping groups think together, decide together, and build the shared judgment that a single expert, however capable, cannot hold alone. Why AI amplifies the need for great facilitation is something we return to across multiple pieces in this series, because it is the most consistently underweighted factor in every transformation program we have seen.

The organizations that treat AI change management as a tool rollout are solving for the wrong variable. The tool is the easy part. The hard part is building the organizational muscle that keeps judgment distributed across the people who will need to exercise it when the situation changes. And situations always change.

The port example makes this visceral. The efficiency advantage held until the sixty-second fault. Then the organization that had preserved coordination independence recovered faster, because it had not consumed the slack the recovery required. Your organization is running the same experiment right now. You will not know the outcome until the fault arrives.

What to Do About It

The organizations working through this well share three habits.

They take Capability Debt seriously as an accounting category. Not formally on the balance sheet, but in the same way a good engineering team takes technical debt seriously. They know where it is accumulating. They know what they are choosing to trade for it. They revisit the decision when the debt load feels wrong. How to structure an AI transformation roadmap that actually works is fundamentally a question about which automations to sequence in which order, and that sequence question is not just a technical planning decision. It is a capability preservation decision.

They clarify roles before the conflict forces the issue. The question of whether you need an AI champion versus an AI lead, and what an AI governance council actually owns, is not administrative. It is the answer to who is accountable when the model produces something strategically wrong, and who has the standing to say so before it ships. Most ownership failures in AI transformation are not failures of intent. They are failures of structure that nobody bothered to define in advance.

They treat facilitation as infrastructure, not as a soft skill. The change management framework for AI adoption in the enterprise we work from is built around this premise. It is not a template. It is a diagnostic. Where is the Capability Debt accumulating? Where is the Identity Friction blocking adoption? Where is the Leadership Friction showing up as strategy without the fluency to back it? Running a cross-functional AI alignment workshop before a pilot goes into production costs a day. Running a post-mortem after the pilot fails costs a quarter and the trust of the team that ran it.

The capacity to carry judgment through an organization is the durable advantage. Tools will change. Models will change. The organizational capacity to decide well under uncertainty will not.

What Is at Stake

The organizations that hold the line on beneficial friction will move slower in the short term. They will look less impressive in the quarterly efficiency reports. Their AI transformation stories will be harder to tell in press releases.

They will also move further in the long term, because they will still have the people who can do the work the model cannot yet do, and the judgment that closes the gap when the data does not.

The organizations that optimize everything for speed will discover the fragility on the worst possible day. Not because the AI failed. Because the people who were supposed to catch what the AI missed have atrophied the capability to catch anything.

The new friction is not a problem to be eliminated. It is a signal telling you where your organization’s judgment is concentrating. Work with it, and the organization gets stronger. Optimize it away, and you are running Dalbert Ma’s automated zone, waiting for rain.

Frequently Asked Questions

How is AI change management different from using AI in change management? The dominant interpretation of this phrase, the one that fills the top search results, treats AI as a tool that improves how change management is done: faster surveys, smarter stakeholder analysis, AI-generated communication plans. Our interpretation is the inverse: AI change management is the practice of managing the human and organizational change that AI adoption itself requires. The tool is not the problem. How organizations navigate identity, leadership development, capability preservation, measurement, and role sequencing is the problem.

Why do most AI transformation initiatives fail? Most stall because organizations treat AI as a technology rollout when it is actually a leadership and facilitation problem. The tools work. What breaks is the judgment capacity of the organization, the shared decision-making the model cannot replicate, and the distributed expertise that gets quietly hollowed out when contiguous workflows are automated end-to-end.

What is Capability Debt in AI adoption? Capability Debt, named by JoAnna Vanderhoef in 2026, is the growing gap between an organization’s apparent efficiency and its adaptive capacity. It accumulates when AI absorbs work that used to build human judgment. The debt is invisible in productivity metrics and only shows up when the situation changes and the people who would have handled it have atrophied the skill.

How does beneficial friction improve AI outcomes? Beneficial friction is a small intervention that forces a human to articulate their own reasoning before accepting an AI output. Renée Gosline’s 2026 MIT study showed a thirty-second reasoning step measurably reduced over-reliance on AI and preserved critical thinking. At the organizational level, beneficial friction looks like decision-rights reviews, novelty drills, signal sampling, and shadow-session reviews of automated pipelines.

What role does leadership play in AI transformation? When execution was expensive, leadership cleared the path. Now that execution is cheap and judgment is scarce, leadership’s job is to carry organizational judgment capacity forward: design the decisions that matter, surface dissent, and ensure the people who will need a skill later are getting the practice now. That is facilitation work, not project management.

How do you maintain judgment when automating workflows? Treat AI automation roadmaps as capability preservation decisions, not just efficiency decisions. Be most careful with contiguous AI-suitable steps, since those are where Capability Debt compounds fastest. Build beneficial friction into the workflow as a structural feature rather than a removable safety check. Keep humans in the chain even when the model could handle the step, because the capability is the thing the organization is actually buying.

Ready to work the new friction?

If your organization is navigating these frictions, there are ways to go deeper.

Talk to us about the AI Transformation Program. We will help you map where your organization is accumulating Capability Debt, where the five frictions are showing up, and what to do about it.

Read the full frame. Our pillar page lays out the thesis and the three pillars: New Friction, Multiplayer, and Spark.

Build the capability. Our facilitation certification teaches the skills that matter most when the bottleneck is judgment, not execution.

The post The New Friction appeared first on Voltage Control.