Implementing AI: why it almost always stalls on your data

Nearly every organisation has run an AI pilot that impressed people. Far fewer have one in production. The difference is almost never the model.

The order that works

Start with a decision that costs money or time. Not with a technology that happens to be available.

Pick one decision that comes back weekly and costs money or time: which order to prioritise, which stock to write down, which delivery to replan. Make the data around that decision trustworthy: one source that counts, one definition, one owner. Only then let the model work on it, and measure whether the decision improves.

This order feels slow and is the fastest. The reverse, building an assistant first and checking the data later, produces a demo nobody dares to use.

Why the pilot impressed and production did not

A pilot on an export is a demonstration. A live source with lineage is a way of working.

A pilot often runs on a manual export, with a definition someone invented for the occasion. That works exactly once. In production every answer must be retellable, access rules must apply per user, and someone must own the terms inside the answer.

Four things to settle up front

• A source that counts. Not three systems contradicting each other. See master data management.
• Definitions with an owner. Otherwise the assistant produces a number nobody defends. See what is data governance.
• Lineage on every answer. Without a source underneath it, an answer is a confident guess.
• Access that travels along. What someone may not see in the system, the assistant may not tell them either.

The invoice people forget

An agent that re-reads every source for every question costs money per question. Work you do once underneath the assistant, you pay for once. See the invoice of an agent and connect once, not per agent.

In short

Implementing AI is ninety percent work on your data and your agreements. The model is the last piece, and anyone can buy that piece.