Published 3 Jul 2026

AI readiness before build

By Richard Lilley, Customer Operations and Transformation Director

A useful AI project begins before the model, interface or vendor choice. It begins with the work.

A pattern we often meet: a team has budget approved, a shortlist of platforms and a demo booked, but nobody has written down which task the system will actually take on or how they will know it worked. The result is usually a pilot that impresses in the meeting and quietly dies afterwards. Readiness is what prevents that, and it comes down to five areas: the work, the data, governance, the adoption path and the measures of value. Each one is a short set of questions. If you can answer them, build. If you cannot, the answers are cheaper to find now than after the invoice.

Map the actual process

Teams often describe an ideal workflow. The system has to serve the real one. That means mapping the handoffs, exceptions, workarounds and informal knowledge that keep the organisation moving.

The gap between the documented process and the lived one is where AI projects fail. The questions to ask:

Which specific tasks would the system take on, step by step?
Where does the time actually go today, and who spends it?
What are the exceptions, and how often do they really occur?
Who holds the informal knowledge that never made it into a manual?
What happens today when this work goes wrong?

Check the data boundary

AI readiness depends on knowing what data exists, who can access it and what should never leave a controlled environment.

Most organisations find out the real state of their data during the build, which is the most expensive possible moment to learn it. Ask first:

What data does this workflow rely on, and where does it live?
Who owns it, and who is currently allowed to see it?
Is it accurate and current enough to act on, or does the team quietly correct it as they go?
Which of it is personal data, and what is the lawful basis for using it this way?
What must never leave your controlled environment, whatever the vendor promises?

Agree the governance early

Governance tends to be treated as a document you produce after launch. In reality it is a set of decisions about responsibility that shape the design itself. Whether an action needs a person's approval, for instance, is an architectural choice rather than a policy footnote, so these questions need answers before the build starts:

Who is accountable for what the system produces?
Which actions may the system complete on its own, and which need a person's approval?
How are mistakes reported, corrected and learned from?
Who reviews the system's behaviour, and how often, once the launch excitement has faded?
What regulatory or contractual constraints apply to this work?

Plan the adoption path

A technically sound system that nobody uses is a failed project with good engineering. Adoption needs a plan, and that plan starts with the people whose working day actually changes. If they first hear about the system at launch, they will treat it as something done to them rather than for them:

Who will use this in week one, and have they been involved?
What does each person gain, in their own terms, not the organisation's?
What training and support exists for the first month?
How does the old way of working get retired, and when?
Who are the sceptics, and what evidence would win them over?

Define the first measurable win

The first build should prove a specific value: time saved, fewer errors, better retrieval, faster onboarding or clearer reporting.

"It will make us more efficient" is not a measure; it is an aspiration. Pin it down:

What single, specific value will the first build demonstrate?
What is the baseline today, and has anyone measured it?
How and when will the result be measured after launch?
Who decides whether it worked, and against what threshold?
What result would make you stop, and would you actually stop?

None of this needs a six-month programme. For most organisations it is a few structured weeks of honest answers, and it is the difference between a system built for the work you have and a platform bought for the work you wish you had. It is also the first thing we do in any technical strategy engagement, because everything downstream depends on it.