AI is rarely the starting point

The conversation about AI inside organisations almost always follows the same path: it starts with the technology and only then looks for somewhere to apply it. It is a quiet inversion, and it is why so many pilots stall halfway.

The pressure is real and understandable. Nobody wants to explain to the board why they did nothing. But the bigger risk is rarely falling behind. It is spending a year and a budget on demonstrations that never reach the operation.

Why do so many AI pilots stall halfway?

Because they were designed to prove the technology works, not to change a specific decision. Those are different objectives, and only the second one survives the end of the initial enthusiasm.

A pilot that proves capability ends with a demonstration and an open question: “and now?”. A pilot that changes a decision ends with someone doing the work differently the following Monday. The first is interesting. The second is the only one you can defend when it is time to budget the next phase.

There is also a less comfortable reason. Many pilots stop because, halfway through, it becomes clear the problem was not a technology problem but one of process, accountability or data. And nobody wants to be the person who says so after the project has been announced.

Which questions should be asked before starting an AI pilot?

Three: which decision does this change, and whose; what happens if it goes well; and how do we know it failed. They fit on one page, and if any of them stays blank there is no use case yet, only an intention.

• Which decision changes, and whose? The answer has to have a name and a job title. “Improving efficiency” is not a decision; “the operations manager no longer has to reconcile two lists on Monday” is.
• What happens if it goes well? If nobody can describe the operation the next day (who does what, with which system, with which control), the pilot has nowhere to go and technical success converts into nothing.
• How do we know it failed? A failure criterion defined before starting is worth more than any report written afterwards. Without one, a pilot never formally fails: it simply stops being mentioned.

In which situations does AI actually change an organisation’s results?

When there is a large volume of repeated judgement, made by experienced people, over information that is scattered but reachable. It is at that intersection that AI stops being a demonstration and becomes installed capability.

All three conditions count. The judgement has to be repeated, because if every decision is unique there is no pattern to capture. The people have to be experienced, because it is their criteria that give the result its value; without that, you automate a decision that was already bad. And the information has to be scattered but reachable, because the work the technology saves is precisely the work of gathering it, and if it exists nowhere there is nothing to gather.

When all three are present, the effect is measurable and it lasts. When one is missing, the pilot works in the lab and disappears in the operation.

What data do you need before using AI?

You do not need perfect data. You need data that exists consistently at the moment the decision is made. A lack of volume is rarely what stops a project; what stops it is each team using the same field with different meanings, or the relevant history sitting in emails and loose notes.

There is a simple test for whether the data is enough: give an experienced person only the information the system would have and ask them to make the decision. If they cannot, neither will the AI, and the first job is to put the information in order, not to choose a model.

How long should an AI pilot run?

Long enough to cover at least one full cycle of the decision you want to change, and no longer. If the decision is monthly, the pilot has to cross a month end; if it is daily, a few weeks are enough to see whether it works.

More important than the duration is who uses it. A pilot run by a parallel team, far from the people doing the work, measures the technology and not the operation. If the people who will use the tool day to day do not use it during the pilot, the result says little about what will happen afterwards. And if a pilot needs more than a quarter to show anything, the scope is most likely too wide.

How do you know a problem needs no AI at all?

If the same difficulty would disappear with a written rule, an assigned responsibility or a mandatory field on a form, then it is not an intelligence problem, it is a design problem. Solving it with AI costs more, takes longer and leaves the cause intact underneath.

It happens often, and saying so is part of the work. Saying it to a client who has already announced an AI project internally is uncomfortable. But it is the only way not to spend their budget on what will change nothing, and to keep it available for what will.

The questions we are researching

How do you start a technology project from the problem, not the tool?

You start from a decision, not from a system. You pick one concrete decision that is made with difficulty today, identify who makes it and describe what they are missing at that moment: information they do not have, time they do not have, or a criterion that is written down nowhere.

Only then do you ask which technology closes that gap. The answer may be AI, it may be a simple automation, and it may be a meeting that starts existing. None is nobler than the others; the one that serves is the one that changes the decision.

We do not start with the technology. We start with the problem. Not as a principle, but because it is the order that works.