Model choice is the part everybody argues about and the part that matters least. The gap between an AI programme that works and one that stalls almost always lies in the state of the underlying data – and that gap can be diagnosed before you write a single line of code.

A predictable ritual plays out at the start of every enterprise AI initiative: weeks of debate about which model to use. It is the wrong debate. The models are close enough in capability that the choice rarely decides the outcome, and they all get better every few months whichever one you pick. What decides the outcome is whether your data is in a state the AI can actually use – and that is usually where a project quietly loses six months it never budgeted for.

We have watched well-funded AI programmes fail, not because the model was wrong, but because the knowledge they needed sat in inconsistent PDFs, in a CRM full of free text, and in three systems that disagreed about the same customer. Data readiness is the prerequisite nobody wants to own – and the one that governs everything downstream.

The real problem: AI exposes data debt you have been carrying for years

Your organisation has been accumulating data debt for a decade – duplicate records, missing fields, undocumented meanings, conflicting sources of truth – and getting away with it because people bridge the gaps. A person reading a messy record works out what was meant. An AI system does not work out your tribal knowledge; it takes the data at face value and produces confident output from faulty input. The AI does not create the data problem. It removes the human buffer that was hiding it.

That is why “let’s just point an LLM at our documents” disappoints so often. The documents contradict each other, the latest version is unclear, and half the institutional knowledge was never written down. The model faithfully reflects the mess.

A maturity model for data readiness

Before you commit to an AI use case, place the relevant data on five levels. The use case can only be as good as the weakest level it depends on.

1. Accessible. Can you get the data out programmatically, or is it trapped in a system without an API, in scanned images, or in somebody’s inbox? If you cannot retrieve it reliably, nothing else matters.
2. Sufficiently structured. Is it in a form the AI can process – clean text, parseable tables, consistent formats – or is it free-text chaos with fragmented tables? Most enterprise data sits here and needs work.
3. Correct and current. Is it accurate and up to date, with a clearly identifiable current version? An AI grounded in stale or duplicate data is confidently wrong.
4. Semantically clear (documented). Are field meanings, codes and edge cases documented, or does it take a long-serving employee to interpret “status = 7”? Undocumented semantics turn into AI errors.
5. Governed. Do you know provenance, sensitivity and permitted uses? This is needed for quality as well as compliance – and so that retrieval can respect access rights.

A use case resting on data that is accessible and structured but neither current nor documented is a use case that shines in the demo and fails in production. Diagnose that first and you will re-prioritise your roadmap in favour of the use cases whose data is genuinely ready.

A worked example: sequencing a roadmap by data readiness

An industrial company wanted three AI capabilities and intended to start with the most strategically important one: an assistant on top of its engineering knowledge base. We measured each of them against the maturity model first.

• Engineering assistant – data accessible, but 40% of the documents were scanned drawings, versions were unclear and field semantics undocumented. Readiness: low. An estimated 4–5 months of data work before AI value is possible.
• Supplier email triage – structured, current, well understood. Readiness: high. AI value in around 6 weeks.
• Quality report summarisation – structured and current, some documentation gaps. Readiness: medium.

We resequenced: ship supplier triage first (a fast, visible win that bought credibility), deliver the quality summarisation in parallel, and start the data clean-up of the engineering base as its own funded workstream, rather than discovering the five-month gap halfway through the project. The strategic use case still came – but on a realistic timeline where the data work was named and budgeted instead of ambushing the project.

The lesson the executive team took away: data readiness should determine the order more than strategic ambition does. Starting with the most important use case on the least ready data is how programmes lose their first year and their sponsor’s patience.

RAG does not rescue bad data – it amplifies it

A dangerous assumption has taken hold: that retrieval-augmented generation makes data work unnecessary, because the model simply reads your documents at query time. The opposite is true. RAG makes data quality even more consequential, because the system’s answers are only as good as the documents it retrieves, and it has no way of knowing that document A is the superseded version and document B the current one. Point RAG at a folder where three versions of a policy sit side by side and it will confidently cite whichever one the retriever ranked highest – and that is just as likely to be the obsolete one. The model does not adjudicate truth; it surfaces text.

That is why “we’ll just do RAG over SharePoint” disappoints so reliably. The corpus contains duplicates, drafts, contradictions and orphaned pages that a human navigates because they know which source to trust. RAG has no such judgement. Before a retrieval system can be trusted, somebody has to decide which sources are authoritative, retire or quarantine the stale ones, and make versioning explicit so that the index can favour current content. That curation is data work – and precisely the work teams hope RAG lets them skip. It does not.

The practical consequence for sequencing: a RAG use case is only as ready as its corpus is curated, and corpus curation usually stays invisible until you measure retrieval quality against a real question set. We regularly find that the decisive task in a knowledge assistant is not building the assistant – that takes a few weeks – but getting the underlying document estate into a state where “the most relevant chunk” is also “the correct chunk”. Budget for that explicitly and a RAG project becomes predictable; assume the model will sort it out and the project stays stuck on the same accuracy plateau in the high seventies that has nothing to do with the model and everything to do with the data underneath.

What to fix first

• Access before anything else. If you cannot get the data out reliably, solve that first; no amount of model quality compensates.
• Document the semantics of the data your use case touches. You do not have to document the whole estate – only what the AI will process. This has enormous leverage and is routinely skipped.
• Designate a source of truth. Where systems contradict each other, decide which one wins before the AI has to.
• Fix structural problems at source where you can. A one-off parsing pipeline helps; fixing the reason the data is unstructured helps for ever.

Decision checklist

1. Where does the data for this use case sit on the five-level maturity model?
2. Which is the weakest level, and how long does it take to lift it before AI value is possible?
3. Can we retrieve the data programmatically and reliably today?
4. Is there a clear, current source of truth, or do the systems contradict each other?
5. Are field meanings and edge cases documented for what the AI will process?
6. Have we sequenced the roadmap by data readiness and not just by strategic priority?
7. Is the necessary data clean-up a named, funded workstream – and not a hidden assumption?

The gridz view

The most valuable thing we do at the start of an AI mandate is often unglamorous: assess the data, not the models. It reorders roadmaps, brings the hidden months into the open, and turns “why is this taking so long?” into a plan everybody agreed to from the outset. Pick the use case whose data is ready for the first win, fund the data work for the strategic use case explicitly, and stop letting the model debate distract you from what actually decides the outcome. We assess data readiness before a single prompt is written – because the model is the easy part, and projects are won or lost on the data. If you would like to settle this for your next initiative, talk to us.

Before your next AI initiative reaches the model-choice debate, assess the specific data it depends on against the five levels and be honest about the weakest one. That one hour of assessment tells you whether you are six weeks or six months from value, which use case to start with, and which data work you need to fund explicitly rather than discover halfway through. It is the least glamorous slide in the deck and the one most likely to stop an AI programme losing its first year – and its sponsor’s confidence – to a data problem nobody had planned for.