Decision Simulation · 4 min read

AI adoption fatigue: regaining trust after failed pilots

Many companies are worn out by repeated failed AI pilots. The cure is not a bigger project but a smaller proof: the 'Wizard of Oz' approach that manually simulates the decision before building the system. Prove the value first, automate second.

In many companies there is now a new feeling: AI adoption fatigue. The excitement of a few years ago has turned, after a series of failed or half-finished pilots, into a cautious weariness. “Another AI project?” “The last one also got stuck at the demo stage.” “Budget was spent, we saw no result.”

This fatigue is real and cannot be ignored. Because once trust has eroded, even the best next project is met with suspicion. Proposing a bigger, more ambitious AI project to a tired organization is adding fuel to the fire.

Counterintuitive as it seems, the cure for AI fatigue is not a bigger project. It is a smaller, faster and more concrete proof. Instead of building an AI system for months and saying “let us see if it works,” you first manually simulate the decision that system would produce and prove its value.

The right question is not “which big project should we do to regain trust?” It is:

Before building this AI, can we manually simulate the decision it would produce, at small scale, and show its value?

Why does fatigue grow with a big project?

After a failed pilot, the reflex is usually “let us do it better this time” — and a bigger, more comprehensive project is proposed. This grows the fatigue.

Because a big AI project shows its value late. It is built, integrated, trained for months; and its value becomes clear only at the very end, when it goes into production. A tired organization cannot carry this long uncertainty. As each month passes, suspicion grows, support shrinks, and the project is often cut before it can show its value. The result: one more failure, and a deeper fatigue.

The problem with a big project is that it puts risk and proof in the wrong order: first the big investment, then (maybe) the value. In a tired organization, this order does not work.

Wizard of Oz: proof first, automation second

The “Wizard of Oz” approach reverses this order. It takes its name from a system run by a person behind the curtain but appearing automated from the outside. The idea is simple: before building the AI system, produce the decision it would generate manually — with an analyst, a framework, some effort — and see its value.

For example, before building a “risky customer early warning” AI: an analyst, for a few weeks, applies the same logic by hand. Which customers are signalling risk, which action is recommended? This manual simulation shows the value the system would produce — without automation. If the manual version works, automating it creates value. If even the manual version does not work, a million-dollar automation will not either — and you have learned this cheaply.

This proves the value before automation. The risk is small, the proof is fast, and the tired organization sees a concrete result. (↔ 10 not a demo but a system, 06 AI pilots)

Why does a mini-simulation regain trust?

A Wizard of Oz or mini-simulation heals AI fatigue in three ways.

A fast concrete result: It produces a proof in weeks, not months. A tired organization wants not a long promise but a short indicator. A manual simulation gives this.

Low risk: Value is tested without a big investment. If it fails, the loss is small and one more “failure story” is not added; only a hypothesis has been eliminated.

The right order: Value is proven first, automation comes after. This is the fatigue-antidote version of the “decision first, technology second” principle. Automation is built on top of a decision whose value is proven — not into a vacuum.

This way, the next AI investment rests on a proof, not a hope. And proof is the best antidote to fatigue.

A manual simulation is not the final stop

A misunderstanding should be prevented: Wizard of Oz is not rejecting AI or doing everything manually. It is a starting strategy, not a final stop.

A manual simulation does not scale; an analyst cannot track hundreds of thousands of customers by hand. The goal is not to stay manual, but to prove the value before moving to automation. When the manual version shows value, automation steps in — but now not as a blind bet, but as an investment that scales a proven decision.

So the order is: prove with a manual simulation first, then scale with automation. With this sequence, a tired organization both reduces risk and regains trust.

Closing

AI fatigue is a real result of repeated failed pilots and cannot be ignored. But its cure is not proposing a bigger AI project to a tired organization — that puts risk and proof in the wrong order and deepens the fatigue.

The cure is Wizard of Oz or mini-simulation: manually simulating the decision the AI would produce, at small scale, and proving its value fast, cheaply and concretely. When the value is proven, automation steps in. This sequence both reduces risk and produces the proof that is the best antidote to fatigue.

The right question is:

Are we proposing a bigger AI project to regain trust, or proving the value cheaply by simulating the decision manually first?

We can help set up a Wizard of Oz / mini-simulation that manually simulates the decision an AI would produce before you move to the investment. →

← All Lab posts