For three weeks this newsletter has been taking apart AI projects that didn't work.

Issue #10: a chatbot that passed every test and got rejected, because buyers wanted a search bar, not a conversation. Issue #11: the projects nobody can kill, because no one was ever given the authority. Issue #12: a model that was right and still never reached production, because the people holding the finding couldn't explain it to anyone who asked.

Three different failures. I've been treating them as three problems. I don't think they are.

New survey data from RSM's 2026 Middle Market AI Survey — 129 manufacturing respondents, so squarely our part of the market, puts a number on what I think is actually one problem wearing multiple costumes:

  1. 88% of manufacturers agreed they have the right in-house AI expertise.

  2. Only 22% said their AI investments are concentrated on training internal talent.

Read those together. Nearly nine in ten believe the capability is already in the building. Roughly one in five is paying to put it there.

“So what?”

The obvious reading is that 88% are wrong — that there's a skills gap and they can't see it. I think that's half right and it misses the more useful half.

The same survey found that only 24% named talent and skills gaps as a barrier to broader AI deployment. It ranked below security, data quality, and legacy integration. So this isn't a case of manufacturers knowing they have a problem and underfunding it. They don't believe they have this problem at all.

And why would they? By their own account it's going well. 98% said they're satisfied with the business value AI has delivered, 70% of them very satisfied.

That combination is the trap. Satisfaction is high, confidence is high, and the enablement line item is small, and none of those three facts is going to correct the others, because nothing in the reporting connects them. The projects that stall don't fail loudly. They fail the way #12 failed: quietly, in proof of concept, with everyone agreeing it was interesting.

What the 22% is actually measuring

Let me be clear about this, because the number is easy to overstate.

The 22% is not "only 22% do any training." It's that among manufacturers investing in AI, only about a fifth have concentrated that investment on training their own people. The money is going elsewhere, and the survey says exactly where: AI software and embedded solutions (61%), data platforms and infrastructure (45%), AI research and innovation (44%).

Look at that ranking honestly. It's a sensible list. Every item on it is defensible in a budget review. Every item on it is also a thing, and things are easier to fund than people, because a thing has a vendor, a quote, a delivery date, and a demo. Training has none of that. It's a line item with no artifact at the end of it.

So it loses. Not because anyone decided it was unimportant — because it never had to compete on equal footing.

The gap that shows up in the room

There's a third number that connects the survey to what any of us have actually watched happen: 84% agreed that executive leadership is more enthusiastic about AI than employees.

That's the whole thing in one line. Enthusiasm at the top, funded as technology. Ambivalence at the point of use, unfunded as capability.

And that gap is precisely where issues #10, #11, and #12 happened. The chatbot in #10 was specified by people excited about AI interfaces, for buyers who wanted fewer steps. The zombie project in #11 survives because nobody close enough to the work was ever given standing to end it. And #12, the one I still think about (could it have been different?), is this exact statistic in miniature: a system built by people who understood it, handed to people who were never funded to.

Self-Admission: I’m not immune and I'm not exempting myself. In #12 I spent our budget on scoring, correlation, and text analysis, and close to zero on the interpretation layer. I ended up being the 88% and the 22% simultaneously, and I didn't notice until the thing died on the vine.

The Framework

The fix isn't "do more training." That's the advice that gets nodded at and never funded, because it has no owner, no artifact, and no number.

Four things that give enablement the same standing as the software:

  1. Put enablement on the same requisition as the platform.

    Not a follow-on phase, not a Q3 initiative — a line inside the same approval. If the platform gets funded and the enablement doesn't, you didn't underfund training. You approved a system with no one qualified to operate it, and that should read as an incomplete purchase.

  2. Budget it as a percentage of the build, agreed in advance.
    Pick the number before you know what the software costs — ten percent, fifteen, whatever survives your finance function. Deciding afterward means deciding when there's nothing left.

  3. Name the person who has to be competent, not the group that has to be trained.
    "Train the quality team" is unmeasurable and nobody owns it. "By go-live, this named analyst can explain any flag this system produces to a skeptic, unaided" is a test with a pass and a fail.

  4. Make the enablement gap a documented reason a project can be stopped.
    This is where #11's kill criteria sheet earns its second use. If the named person can't pass the test above, that's a threshold breach — same as a missed usage number. Otherwise the project ships anyway and dies quietly six months later, and the model takes the blame.

The Cost (aka The Easy Target)

Here's what the last three issues cost, added up: Not the engineering hours. The credibility.

Every AI capability that stalls after launch makes the next proposal harder to fund, and the postmortem almost never names the real cause. It names the model. It names the vendor. It names user resistance. It doesn't say we bought a system and didn't buy the ability to run it, because that sentence implicates the budget, and budgets are written by the same 88% who were confident the expertise was already in the building.

Four Tuesdays, one argument. The deployment that earns money is the one that matches how the user behaves (#10). Somebody has to own the decision to stop (#11). Accuracy buys consideration, explainability buys adoption (#12). And underneath all three:

We are funding AI as a technology purchase when it is a capability purchase. The software arrives on the delivery date.

The capability has to be built, and almost nobody is buying it.

Plant Floor to Cloud goes out every Tuesday.

Pull up your last AI approval. What percentage of it was enablement? If the answer is zero, you already know which of the last three issues you're heading for. Reply, I read every one.

Reply

Avatar

or to participate