Ask a leadership team what their AI initiative needs and the answer usually involves a model. Ask the engineers six weeks in and the answer is always about data. That gap — between where attention goes and where the work actually is — is the most reliable predictor of whether an AI project will struggle.
The uncomfortable truth is that for most enterprise use cases, the model is close to a solved problem. Frontier models are extraordinarily capable straight out of the box. What they do not come with is your data — clean, current, governed, and reachable. Supplying that is the real project.
Why model choice matters less than it seems
Five years ago, picking and tuning the model was where projects were won or lost. Today, several providers offer models good enough for the large majority of enterprise tasks, and switching between them is often a configuration change. Capability has, for practical purposes, become abundant.
When one input becomes abundant, the constraint moves elsewhere. For applied AI, it has moved decisively to data. A capable model fed poor data produces confident, well-written, wrong answers. A modest model fed excellent data produces useful ones. The leverage is in the data.
A capable model fed poor data produces confident, well-written, wrong answers.
The three data problems that actually stall projects
Quality you have not measured
Most organisations do not know their data quality. They assume it is adequate because the reports look fine — but reports tolerate gaps and staleness that AI systems surface immediately. Missing values, duplicates, inconsistent definitions of basic terms, and out-of-date records all degrade output in ways that are hard to spot because the model keeps producing fluent text regardless. The first engineering task on most AI projects is simply measuring how good the data is.
Lineage you cannot trace
When an AI system produces an answer, someone will eventually ask where that came from. If you cannot trace an output back through the model to the specific records and pipelines that produced it, you cannot debug it, audit it, or defend it. Lineage is not paperwork — it is the mechanism that makes an AI system explainable and fixable. Retrofitting it is painful, so we build it in from the first pipeline.
Access that does not exist yet
Pilots run on extracts. Production needs live, governed access to data that often sits in systems never designed to be queried by anything else — legacy databases, third-party platforms, departmental tools. Building reliable, secure, monitored access to those sources is frequently the largest single piece of work in the project, and it is almost always underestimated because it is invisible during the pilot.
What to do about it
None of this argues against AI ambition. It argues for sequencing the work honestly.
- Assess data readiness before scoping the model work. A short, focused audit of quality, lineage, and access for the specific data a use case needs will tell you more about timeline and cost than any model benchmark.
- Treat the data pipeline as the primary deliverable. The model is a component. The governed, monitored flow of data into it is the system. Resource it accordingly.
- Fix data at the source where you can. Cleaning data inside the AI pipeline patches one use case. Improving it upstream raises the ceiling for every future initiative.
- Build lineage and monitoring from day one. They are far cheaper to include early than to retrofit, and they are what make the system supportable.
The organisations getting durable value from AI are not the ones with the best models — almost everyone has access to those. They are the ones that treated their AI initiative as the data initiative it always was, and did the unglamorous work first.