Most commercial teams have stopped arguing about whether AI belongs inside the work. That fight is over. Nobody I talk to defends the idea that AI is a productivity add-on bolted onto the side of the real process anymore. And most of those same teams still are not moving. The pilot that looked ready in the spring is still a pilot now. The tool everyone agreed was good sits mostly unused. The rollout that should have taken a quarter is heading into its third.
Some of that is a process failure. Teams retrofit AI onto the work they already do instead of redesigning the work itself, and the result looks like progress for a quarter before it quietly dies. Call that Copilot disease. It is real, and it accounts for some of the stall. It does not account for most of it.
Most of the stall is not technical and it is not procedural. It is human. I embedded AI into a Novartis commercial marketing framework, and I watched some version of all three of the reflexes below happen inside that same building, sometimes in the same week. Three groups of people, in almost every commercial organization I have worked in or advised, have a rational reason to slow this down, and almost no leader has given any of them a real answer.
The person who fears for their job. The person whose default answer to any AI request is "security won't allow it." And the executive who watched the last hype cycle burn someone and is quietly waiting this one out.
None of this showed up when AI was still optional. It shows up now, because the case is closed and the stakes are higher. A team that agrees AI belongs in the work but cannot get anyone to actually run it is worse off than a team that never had the argument, because the old excuse, that nobody had figured out where this fits, is gone. What is left standing in the way is a person, not a decision.
You cannot govern your way past any of these three. You cannot buy a platform that fixes them. You cannot reorganize around them. Each one needs a leader who names it out loud and hands the affected person a real plan, not a reassurance. Here is what each of those three plans actually has to contain.
The fear closest to home
Start with the one closest to the individual. Somewhere in a building like yours right now, there is a working AI tool sitting unused because the person who built it knows that if it works, somebody's job changes, and maybe it is theirs. That is not paranoia. It is an accurate read of the incentives most organizations actually run, and it is the fastest of the three fears to name because everyone already senses it is there.
A leader does not fix this by promising AI will not cost anyone their job. Everyone in the room knows that promise is either false or temporary, and making it burns the last bit of trust available for the harder conversations still to come. The fix is a plan with real contents, delivered before anyone has to guess at what happens to them.
Say out loud, specifically, what happens to the roles the tool touches. Not "we will figure it out as we go." Name which tasks the tool absorbs, which tasks stay human, and which roles change shape as a result. Vagueness is what people fill in with worst-case assumptions, so filling the silence yourself is the first move a leader has to make, and it has to happen before the tool ships, not after someone asks.
Commit to redeployment paths, not headcount math. Headcount math is what a leader says to a board. Redeployment is what a leader says to the person whose job the tool touches: here is the seat you move into, here is roughly what it looks like, here is when the move happens. If you cannot say that sentence today, you are not ready to roll the tool out today either, and rolling it out anyway is exactly how a working prototype ends up hidden.
Assign ownership of the new work the tool creates. Every AI system that actually works generates a second layer of work nobody had before it. Someone has to tend the model, own the exceptions it cannot handle on its own, and keep it honest as the business changes underneath it. That is a real role, not a favor being extended to whoever is willing to take it. Name who owns it before launch, and the team sees a next seat instead of a cliff.
And make surfacing a working tool the visible, rewarded move, not a risk the builder absorbs alone. Right now, in most organizations, the safest thing to do with a tool that works is hide it. Reverse that incentive, and reverse it in public, where the rest of the team can watch it happen and update their own read of the room.
The test for whether any of this landed is simple. Ask everyone on the team the same question: what happens to you if this works. If the honest answer is silence, adoption is not the problem yet. Trust is the problem, and it will show up disguised as an adoption problem later.
The reflex wearing a policy costume
The second blocker sounds like a policy problem. It is a courage problem wearing a policy costume.
I have watched a request for an AI tool get denied for data-security reasons when the tool in question never touched anything but public, already-published marketing content. Website copy. Approved sales aids. Campaign assets that had already cleared medical, legal, and regulatory review and were live on the internet for anyone to read. The tool posed no more risk than a search engine indexing the same page it was already indexing. It got a no anyway, filed under security.
The stated reason and the real reason are usually different things. Nobody in that room wanted to be the name attached to the decision if something went wrong later, so the request got routed to security, because security is the one function nobody argues with. "Security will not allow it" ends a meeting fast. Nobody has to own the call. That is the actual function the reflex is serving, and it has almost nothing to do with the sensitivity of the data in question.
The fix is not a memo reminding people to be reasonable. It is structural, and it has three parts.
First, separate your real data-sensitivity tiers on paper, before the next request lands. Public marketing content that has already cleared review is not patient data, is not protected health information, and should not travel through the same approval speed as either. If an organization's default posture treats an already-published press release with the same caution it applies to a clinical dataset, it has built one lane where it needs at least two, and every low-risk request pays a tax that should only apply to the high-risk ones.
Second, pre-approve a fast lane for that low-risk tier, so the default answer to a tool touching only public assets is yes, by design, not a fresh debate every time someone asks. This is the part most organizations skip, because it feels like giving something up. It is the opposite. A fast lane for the genuinely low-risk category is what protects the credibility of caution on the tier that actually deserves it. When every request gets the same slow no regardless of what it touches, people stop believing any of the no's are actually about risk. They start routing around the process entirely, building the same tool quietly on a personal account instead of a sanctioned one, which is a far worse outcome for the organization than the tool it was trying to gate in the first place.
Third, name the actual owner of the risk decision. Not a committee. A person. Diffuse ownership is exactly what produces the reflexive no, because nobody wants to be the name on a yes that goes wrong later, and a committee lets everyone share that exposure by defaulting to no as a group. A named owner, with the standing to actually say yes to the low-risk tier and mean it, changes the incentive completely. The decision gets made on the merits of the specific request instead of deflected to the one function nobody is willing to argue with.
None of this requires new technology or a new vendor. It requires a leader willing to draw the tiers, build the fast lane, and put a name on the risk decision instead of letting "security" absorb every request regardless of what it actually touches.
The executive who already got burned
The third blocker sits at the top of the org chart, and it is the one most outside advisors misdiagnose worst, because they mistake it for stubbornness.
I have sat across from executives who say some version of the same thing: whoever bet big on AI two years ago regretted it a year later. That is not an irrational position. It is scar tissue from a real experience. Somewhere in that executive's career, a vendor demo looked extraordinary in a conference room, the organization committed real budget and real headcount to it, and eighteen months later the tool was quietly retired and nobody wanted to be the one who had championed it. That memory is doing exactly what memory is supposed to do. It is protecting the organization from repeating a specific, expensive mistake.
A pep talk makes this worse, not better. Telling a skeptical executive that this time is different is the same sentence the last vendor used on the way in, and the executive has already heard it once. Enthusiasm is not evidence to someone who has watched enthusiasm fail to become results. If anything, a confident pitch reads as a warning sign to this particular audience. The last tool that failed them looked just as confident.
You can usually spot this blocker before anyone says a word about it. Budget for the pilot moves, then moves again. The person who owns the go-ahead keeps asking for one more data point that was never going to change the decision. None of that is obstruction for its own sake. It is a rational person managing risk to their own credibility, the same way they would manage risk to a launch timeline.
What a skeptic actually responds to is evidence built the way they already build evidence everywhere else in the business. Pharma commercial teams know how to do this better than almost any other industry. Nobody green-lights a molecule on a demo. Nobody approves a claim on enthusiasm. The organization runs a control, measures against a baseline, and only scales what the data actually supports. That discipline exists inside every one of these companies already. It has simply never been pointed at the company's own AI work.
So point it there. A skeptical executive does not need a pep talk. They need a control arm: a measured pilot, run against a real baseline, that produces a number they can defend to their own boss, not a demo that looks good in a conference room. At the scale of a single commercial team, that means picking one defined piece of work, measuring how it performs today, running the AI-enabled version against that same measure, and reporting the delta honestly, including on the first pass if the delta is small or even negative. I have built exactly this kind of measurement discipline before, and the mechanics of it are their own subject for another day. The point here is narrower. Give a skeptic a real number, measured the way they already measure everything else that matters to the business, and they stop being a skeptic and start being a sponsor, because you handed them the one thing the last hype cycle never did: a way to be wrong safely and find out cheaply.
That builds compounding trust, too. The second pilot gets an easier hearing than the first, because the executive now has a track record of your numbers holding up under their own scrutiny, not a track record of your enthusiasm. That is the actual asset a skeptic is worth once they are on your side. They stop being the blocker and start being the person nobody else can talk your idea past.
That is the whole ask. Not belief. A control arm.
The plan, all three parts, together
Put the three side by side and the pattern is the same shape three times over. The person protecting their job needs to know what happens to them specifically, and needs to see a next seat instead of a cliff. The person routing every request through security needs a tiered system and a named owner, so caution attaches to the risk that is actually there instead of to every request equally. The executive who got burned needs a control arm, not a pitch.
Notice, too, that the three are not really separate problems stacked on top of each other. They are the same organization reacting to change at three levels: the person doing the work, the function protecting the company, and the executive protecting the budget. A leader who fixes one and ignores the other two has not solved adoption. They have only moved the stall to wherever they did not look.
None of the three fixes is a mandate. None of them is a platform purchase. A leader who responds to job fear by mandating adoption anyway just teaches people to hide their working tools more carefully. A leader who responds to the security reflex by buying a bigger compliance product without fixing who owns the decision ends up with a bigger, slower no. A leader who responds to executive skepticism by pushing harder on enthusiasm gets exactly the reaction that memory has already trained the room to give back.
What actually moves all three is the same posture applied three separate times: name the specific fear out loud, and hand the specific person or group a credible plan built for that fear, not a general one borrowed from somewhere else and pasted over all of them. That is not a change-management program with a kickoff deck. It is three concrete, on-the-record conversations a leader has to be willing to have with the people actually holding the reflex, in language specific enough that everyone in the room knows exactly what was promised and by when.
The reason so few leaders do this is not that it is hard to design. It is that all three conversations require the leader to say something that could turn out to be wrong, in public, to a person who will remember it. That is the actual courage this moment asks for. Not a bigger AI budget. A leader willing to be specific and be held to it.
The one move to make this week
None of this is an information-technology conversation. Every quarter your team spends stuck on one of these three reflexes is a quarter your competitor's commercial team, running some version of the same tools, is not stuck on. That team is not smarter than yours. It is not better resourced. It is simply less afraid, because someone above them did the work of naming the specific fear and handing over a specific plan, while your team is still deciding whether it is safe to say the fear out loud.
The number that gets missed while this sorts itself out is not an AI number. It is the commercial number underneath it. The campaign that launches a quarter late because the tool that would have compressed the timeline sat unused. The market a leaner competitor reaches first. The capacity that stayed locked in a drawer because nobody made it safe to open it.
That gap compounds every quarter it goes unaddressed. A team that is six months ahead on adoption is not simply six months ahead. By the time you notice the gap, they are running a faster commercial cycle on a lower cost structure, and closing that distance takes longer than the six months it took to open it.
Here is the one move to make this week. Find the AI tool in your building that gets blocked most often, the one people quietly agree is good but nobody is actually running at scale, and ask one direct question about it: which of the three fears is actually stopping this. Not "why is adoption slow." Ask the narrower question. You will get an honest answer faster than you expect, and it will tell you exactly which plan you owe someone, and to whom.