Most conversations about adopting AI eventually arrive at the same place. The use case is clear, the model is capable, the demo was convincing, and then the project stalls on the state of the underlying data. The technology is ready. The data is not.
This is the least exciting part of any AI initiative and, more often than not, the decisive one. Data engineering is the plumbing beneath everything else: messy, invisible when it works, and the cause of most failures when it doesn’t.
The proof of concept talks to a clean sample
A demonstration is built against a tidy extract: one well-formed table, a few hundred rows, no contradictions. It works, and everyone concludes the data is fine.
Production is a different world. There, the same question is answered by several systems that disagree, by exports in incompatible formats, and by records that were entered inconsistently for years. A proof of concept that succeeds on a clean sample has told you almost nothing about whether AI can operate on the data you actually hold. The clean sample is the exception; the mess is the data.
Most businesses don’t have one version of the truth
Walk into a typical company and the real operating data lives in spreadsheets, emailed between people, because the official systems never quite fit how the business actually works. Expensive software is purchased, partially adopted, and then quietly bypassed while the real work happens in a workbook on someone’s desktop.
The result is that there is no single view of the business to point an AI system at. There are several overlapping views, maintained by different people, that don’t fully agree. Before any model can reason over your operations, something has to resolve which version is correct, and that is a question about how the business is run, not a question about technology.
The column nobody can explain
Even in well-run companies, data accumulates history. A report goes out every month containing a column named something like adj_rev_final_v2, pulling from a system that was retired years ago, measuring something nobody can now define. It keeps going out because it always has.
AI is unusually unforgiving of this. A person accepts inherited ambiguity and moves on; an automated process needs to know what a field means before it can use it. Getting data AI-ready forces these questions into the open, and answering them (deciding what the business actually measures and writing it down) is most of the value, often before any AI is switched on. That work deserves its own treatment: see single source of truth.
What “AI-ready” actually means
In practice, getting data ready for AI comes down to three plain questions.
The first is structure. Is the data organised so a given fact lives in one defined place, with a known meaning, or is it scattered across systems and spreadsheets in conflicting forms? The second is movement: does data flow between systems reliably and automatically, or does someone copy and paste between tools to keep things in sync? The third is accuracy. When two systems report the same number, do they agree, and if they don’t, is it clear which one is authoritative?
None of this is glamorous, and none of it requires AI to fix. It is ordinary data engineering and ordinary decision-making about how the business defines itself. But it is the work that determines whether an AI initiative reaches production or joins the large pile that didn’t.
The order matters. Choosing where to start with AI comes first; getting the data beneath that task into shape comes immediately after. If the data layer is where you suspect you’re stuck, that diagnosis and the work to fix it is what our data solutions practice does.
