Your team sends you a report on an AI pilot. The people who used the tool did better than before, and they liked it. The last page asks for budget to roll it out across the business.

When a team tells me a pilot worked, my first question is a short one: compared with what?

I don't ask it to be difficult. A pilot is a test, and a test is only as useful as the comparison it makes. "It worked" tells me the team is pleased with the result. It doesn't yet tell me what the business should do next.

So before I'd agree to scale a pilot that worked, I want three questions answered. Here they are, and what I won't claim for them.

Compared with what?

Suppose the pilot compared people using the AI tool with people doing the work the old way. The people with the tool did better. That's a real result, and it's good news.

But it answers a narrower question than the one you now have to decide.

There is useful research here. In a review of 106 experiments, Vaccaro, Almaatouq and Malone (2024) found that people with AI did better than people alone. They also found that a person and an AI working together did worse than the better of the two on its own, most of all on decision tasks.

So a pilot that beat the old way has shown one thing: people with the tool did better than people working alone. It hasn't shown that a person with the tool did better than the better of the two. Those are different findings. When the decision is how a piece of work should be done across the whole business, I want to know about the second one as well.

That research is about experiments, not about your pilot. I use it for one purpose: it tells me which comparison to ask for.

Who checked, and will they still check?

The second thing I want to know is who checked the AI's output during the pilot, and how they did it.

Checking isn't something I'd assume. I would ask the team to show which AI outputs they checked and what they compared them with. Scaling the tool doesn't scale the checking unless someone plans for it.

Who owns it when it goes wrong?

The third thing is ownership. In a pilot, the answer is usually clear: the team that ran it.

At scale, the tool is used by many more people, and most of them weren't part of the pilot. When the AI is wrong and someone acts on it, a few things need an answer. Who decides what happens next? Who is told? Who owns the outcome: the person who used the tool, their manager, or the team that bought it?

If those answers aren't agreed before the rollout, you will have to settle them after something has gone wrong, at a time you didn't choose.

Underneath all of this is a question I come back to often.

"Do you know how your people are deciding with AI?"

In a pilot, you can usually find out by asking the team. At scale, if nobody can see how people are deciding, I don't see how anyone can say they own the outcome.

What I'd ask for before scaling

When a team asks me to scale a pilot that worked, these are the questions I want answered first.

  1. What did we compare it with? Did the pilot test a person with the tool against the better of the two, or only against the old way of working?
  2. Who checked the AI's output, and will they keep checking? Name who checked in the pilot. Then say how that checking will continue when the tool is part of everyone's working day.
  3. Who owns it when it goes wrong? Write down who decides, who is told and who owns the outcome, before the rollout starts.

None of these questions says no to the pilot. They ask the team to show what the result means before the business commits to it. A good result is worth having. But a result is not the same as progress. The pilot gave you a result; scaling it is a decision about what the business does every day after that.

What I won't claim

I won't claim that a pilot, even a good one, tells you what will happen at scale. It tells you what happened in the pilot.

I also won't claim that these three questions make a rollout safe, because no set of questions can do that. What they do is make sure the person who approves the rollout has asked them and can explain the answers.

The research I've cited is not about your pilot, and I don't use it as if it were.

I give keynotes, briefings and workshops on this.

Tell me about the event.