The AI pullback is not an AI problem.

Buying was easy. Installing was hard.

Almost none of the pullback coverage describes a model that was too weak. It describes a project that was bought instead of installed. A partner who left after go-live. A tool nobody was trained on. A bill nobody capped. An output nobody could grade, so the only test was whether it felt right.

Four symptoms of one missing thing. Nobody defined the job.

You bought a project, not a result

The pattern doesn't change. A vendor sells a build. The build ships. The invoice clears. Then the person who understood why it was built moves to the next engagement, and the thing sits there doing something adjacent to what you needed.

I've seen this from the other side. When we audit a codebase, the architecture is rarely the problem. The problem is that nobody can tell me what the system was supposed to decide. So every screen ends up defending against a state the database should never have allowed, and every bug becomes a negotiation about what the feature was for.

A project has a delivery date. A result has an owner and a number. If your AI initiative has a delivery date and no number, you bought a project.

The obvious answer is to build it yourself. The MIT study has an uncomfortable finding for that too: internal builds fail about twice as often as bought ones. The failure is not in who writes the code. It is in whether anyone owns the outcome once the code exists.

Nobody trained the person who has to use it

Every tool has a person on the other end who has to change what they do on a Tuesday. If that person wasn't in the build, they'll use the tool the way they used the old process, and the tool will look broken.

The evidence for this is sitting in the same study, and it is almost funny. Employees are already getting value out of AI, just not from the official programme. The MIT researchers call it the shadow AI economy: personal tools, adopted without permission, quietly delivering better returns than the enterprise initiatives.

Read that as an adoption finding rather than a compliance one. People finish what they own. A tool handed over from a programme nobody asked for is somebody else's project, and it gets used until it is inconvenient.

So it isn't an AI literacy problem in the abstract. It's specific. Who checks the output. What they do when it looks wrong. Where they escalate. If those three answers aren't written down, the tool is one bad week away from being quietly ignored.

The cost was never bounded

Token spend is the first line item in the history of software that scales with usage and has no natural ceiling. Companies sign a contract with a monthly platform fee, then discover the real bill is the per-call cost multiplied by however many people found the button.

Thirty to forty billion dollars went in. Five percent of organisations can point at the return. Whatever the average bill was, somebody signed it without a number on the other side of the page.

I'm not going to pretend we predicted every bill either. What we do now is put a boundary on it before anyone logs in. What this is allowed to cost per month. What happens when it hits that. Which jobs are worth paying for and which aren't. A tool without a ceiling gets switched off the first time finance looks.

Nobody could grade the output

AI quality collapsed in a lot of organisations because nobody defined good. Not in a slide. In a test.

We build evaluation sets for the same reason an accountant reconciles a bank account. You need twenty real examples with the right answer written down. Otherwise you've got no way to know whether the model improved or just changed. And without that, every complaint turns into a debate, and the loudest person in the room wins.

This is the cheapest item on the list and the one most often skipped. Twenty examples cost less than one bad month.

A government framework will not do this for you

There is a temptation to treat governance as paperwork and buy your way past it. The National Institute of Standards and Technology is blunt about that in its own AI Risk Management Framework. Organisations, it says, need to establish and maintain accountability mechanisms, roles and responsibilities, culture, and incentive structures for risk management to be effective, and using the framework alone will not produce those changes.

A standard tells you what a good control looks like. It cannot tell you who answers the phone at 9pm when the thing misbehaves. That is a name, and it is written down, or the project is already dead and nobody has told finance.

What the pullback actually tells you

Nobody's winding back because a model got worse. They're winding back because those four things were never done. The organisation looked at a tool with no owner, no training, no ceiling and no test, and correctly decided it was a liability.

I've told clients not to automate a step. Sometimes the process is the product. Sometimes the volume is too low to justify it. Sometimes the mistake would be too expensive to catch. That conversation is worth more than a build, and it's the one most vendors won't have, because it doesn't invoice.

The shorter version

Before you buy anything else, write down four things.

The one step that's broken, in a sentence an owner would recognise. The person who owns it after go-live. The number it has to move. The ceiling on what it's allowed to cost.

If you can't fill those four in, you don't have an AI problem. You have a definition problem, and no vendor on earth can install their way out of it.

AI didn't fail. It got bought instead of installed. Those are different problems, and only one of them is expensive.