The story leadership tells about slow AI adoption is a capability story. The model isn't quite good enough, the prompts need work, people need training, give it another quarter. Inside a team that's actually trying to use these tools on real work, that's not what kills them.
What kills them is that nobody can answer who owns the output when it's wrong. I push a number to an exec deck and it's off, that's my name on it, and I knew exactly which join produced it. The tool generates the same number and it's off, and the chain of accountability dissolves into "the model said." No one wants their name on an output they can't fully reconstruct, so for anything that carries real consequence, people quietly route around the tool and use it only for low-stakes scaffolding they'd have been fine doing by hand. Adoption metrics look fine because everyone's "using" it. Nobody's trusting it with anything that would actually hurt to get wrong.
I've watched this with code suggestions, with generated SQL, with draft analysis. The capability was there. The thing missing was a story for who's responsible, and in the absence of that story the rational move is to keep the tool away from anything load-bearing. That's not resistance to change. That's people correctly noticing that "the model wrote it" is not a sentence you can say in a postmortem.
The teams that actually adopt aren't the ones with the best model. They're the ones where someone decided, explicitly, that a human owns the output regardless of how it was produced, and built the review step to make that ownership real. Until that's settled, capability is irrelevant, because the blocker was never whether the tool could do it. It was whether anyone was willing to sign their name under what it did.