Insight · Data and AI readiness

10 Data Foundations Missing Before AI Can Deliver

AI projects rarely fail on the model. They stall on data that was never prepared for anything beyond the reports it was built for.

For IT and finance directors All sectors 13 min read

In brief

Most AI programmes discover their data problem after the business case has been approved, which is the most expensive moment to find it.
The ten foundations below are what has to be true before AI can work reliably. None of them are technically difficult. Most are ownership questions nobody has answered.
The position worth reaching is not “we have a lot of data”. It is “we know, for this use case, whether the data exists, can be trusted, can be reached, is owned, and should be seen”.

Every mid-market AI programme eventually meets the same obstacle. The model is fine. The use case is sound. The data is not ready, and nobody knew until the work started.

This is rarely because the firm lacks data. Most have plenty. It is because the data was built to produce reports and run transactions, not to feed something that has to make a decision reliably, at volume, on records it has never seen before.

Those are different requirements. Reporting tolerates gaps because a human reads the output and applies judgement. A model does not. It takes what it is given and produces something confident, whether or not the input deserved confidence.

The ten foundations below are what has to be true first. Almost none of them are technically hard. Most are questions of ownership that nobody in the business has been asked to answer.

01

Somebody owns each significant data set, by name

Ask who owns customer data and the answer is usually a system or a department. The CRM. Marketing. IT. None of those is a person, and none of them can make a decision about it.

Ownership means someone specific who decides what a valid record looks like, who can change the definition, who is accountable when quality slips, and who says yes or no to a new use. Without that, every data question in an AI project goes to a committee or to nobody.

This is the foundation everything else rests on, and it costs nothing but a decision. The fix is to name an owner for each significant data set, write down what they decide, and tell the organisation. Most firms have never done it because nothing forced the question.

02

The same thing means the same thing everywhere

Sales counts a customer one way. Finance counts it another. Operations has a third definition. Each is right for its own purpose and they produce different totals.

For reporting that is survivable, because the people reading know which version they are looking at. For AI it is not. A model trained on one definition and deployed against another produces answers that look plausible and are wrong in ways nobody detects for months.

The fix is a small agreed set of core definitions — customer, order, product, transaction — written down and used consistently. It is a governance exercise rather than a technology one, and it usually surfaces disagreements between functions that have been quietly costing money for years.

03

Duplicate records are found and resolved rather than tolerated

Every firm has the same customer recorded more than once. Different spellings, different systems, an old email address, a name that changed. It accumulates and nobody clears it, because the cost of tolerating it is spread thinly across everything.

For AI it stops being thin. A model that sees one customer as four learns the wrong pattern about all four. Personalisation goes to the wrong record. Value calculations understate the relationship. Risk scores are built on a fragment of the history.

The fix is a matching process that runs continuously rather than a one-off cleanse that decays. The one-off is the more common choice and it buys about eighteen months.

Reporting tolerates gaps because a person reads the output. A model does not. It takes what it is given and answers confidently either way.

04

You can tell where a number came from

When a figure appears in a report, can anyone trace it back? Which system, which transformation, which rule applied along the way?

In most mid-market firms the answer is partly. The path exists in someone’s head or in a script nobody has read for years. That is uncomfortable for reporting and disqualifying for anything a regulator, auditor or customer might ask about.

Once AI is making or informing decisions, the question changes from curiosity to obligation. Explaining a decision means explaining the data behind it. The fix is to record where data comes from and what happens to it, at least for the sets that feed decisions. It is unglamorous and it is what makes everything else defensible.

05

Someone measures quality before a project needs it

Data quality gets assessed when a project requires it. The team investigates, discovers the state of things, and reports it as a finding. Every project rediscovers the same problems independently.

What rarely exists is continuous measurement: completeness, accuracy, timeliness, tracked over time against agreed thresholds, with someone accountable when they slip. Without it, quality is a surprise every time and each project pays to discover it again.

The fix is monitoring on the sets that matter, reported like any other operational measure. Then a project asking whether the data is good enough gets an answer in an afternoon instead of a month.

Where do you sit?

Knowing whether the data is ready is cheaper before the business case than after it.

A free Executive AI Opportunity Assessment. Forty-five minutes, online, with your leadership team. We arrive with a model of how firms in your sector make money and where AI has moved those numbers — and you tell us where it is wrong.

Book a free assessment

06

Personal data is classified, so you know what AI may see

The firm holds personal data. Some of it is sensitive. Regulation applies. Everyone knows this in general.

What frequently does not exist is a specific record of which fields, in which systems, hold what kind of personal data, and what each may lawfully be used for. Without it, every AI proposal produces the same conversation: can we use this data for that, and nobody can answer quickly.

The consequence is either delay while it gets worked out, or a decision made on assumption. Neither is good. The fix is classification done once and maintained — which turns a three-week legal question into a lookup.

Where AI programmes lose time on data — a pattern, not a measurement

Most

Of the project effort

Goes into finding, cleaning and joining data rather than into the model itself.

Months

Added to the timeline

Between approval and the point where the data is actually usable at production quality.

Repeated

Across every project

Each one discovers the same problems independently, because nothing was fixed at source.

Higher

Cost of doing it later

Retrofitting governance onto something already in production is far more expensive than building it in.

This describes a pattern rather than a measured dataset. The useful number is your own: take your last AI project and work out what share of the elapsed time went on data. Most firms are surprised, and it is the figure that changes how the next business case gets written.

07

The data a model needs can actually be reached

The data exists. That is not the same as being able to get at it. It may sit in a system with no usable interface, in a format that needs manual export, or behind a supplier who charges for access.

Projects discover this late, because everyone assumes that data which appears in a report can be extracted at will. Often it can — once a month, by a person, for reporting. Not continuously, at volume, for something running in production.

The fix is to check reachability at the point the use case is scoped, not at build. It is one question — can we get this automatically, at the frequency and volume required — and asking it early saves months.

For the IT and finance directors

Three questions before the next AI business case

For the data this use case needs, can you name the owner, the quality position and whether it can be reached automatically? If any of the three is unknown, the timeline in the case is optimistic.
What share of your last AI project went on data work? If it was most of it, that should be in the next case as a line rather than a surprise.
If a customer asked how a decision about them was made, could you trace the data behind it? If not, that gap will find you eventually.

08

Historical data is good enough to learn from

Models learn from history. The firm has years of it, which sounds like an advantage.

The question is whether that history is usable. Were the definitions consistent over the period? Did a system migration change how things were recorded? Are there gaps where a process changed? Does the data reflect how the business works now, or how it worked before a reorganisation?

Inconsistent history produces a model that learns patterns from a business that no longer exists. The fix is to assess the usable window honestly before building — and to accept that it may be much shorter than the data you hold.

09

Somebody watches the data after go-live, not just before

Data quality gets attention while a project is being built. Once it goes live, attention moves on.

But the data keeps changing. A source system gets updated. A field starts being used differently. A supplier changes a format. A process change alters what gets captured. The model carries on producing confident answers based on inputs that have quietly shifted underneath it.

This is how AI degrades without anyone noticing, and it is the failure mode that damages trust most, because by the time it is visible the outputs have been wrong for a while. The fix is monitoring on the inputs, not just the outputs, with alerts when something moves.

10

Data investment is funded as infrastructure, not inside project budgets

The most structural of the ten. Data work gets funded inside individual projects. Each one builds what it needs, in the way it needs, on its own timeline.

So the same work gets done repeatedly, slightly differently each time, and nothing accumulates. The third project pays for the same cleansing the first one did, because the first one fixed it in a copy rather than at source.

The fix is to fund the foundations separately, as infrastructure with a continuing budget and an owner, so each project can draw on them rather than rebuild them. That is a difficult case to make, because the benefit is spread across future projects rather than attributable to this one. It is also the difference between AI getting cheaper with each use case and getting more expensive.

What this means

None of these ten are technically difficult. Most are ownership questions that nobody in the business has been asked to answer, and they stay unanswered because nothing forces the question until an AI project is already underway.

That timing is the whole problem. The data position gets discovered after the business case is approved, which is the most expensive moment to find it — the money is committed, the expectations are set, and the honest answer is that the timeline was written before anyone checked.

Five questions cover most of it. Does the data exist? Can it be trusted? Can it be reached? Who owns it? Should AI be allowed to see it? Asking those before the case is written costs a fortnight. Asking them afterwards costs the case.

Which is the argument in one line. Change the work before you change the technology — and know what the data can actually support before anyone commits to what the AI will do.

The next step

Do you know whether your data can support what the case promises?

Forty-five minutes with your leadership team, online, at no cost. We bring a working model of how firms in your sector make money and where AI has moved those numbers. You tell us where it is wrong. Then we tell you what we think — including “don’t invest”, if that is the honest answer.

Book a free assessment

45 minutes · online · no cost · nothing to prepare

Related insights