Get the data foundations right and AI stops being hard.
Most AI conversations I have start in roughly the same place.
"We want to build an LLM." "We want agents running across the business." "We need an AI strategy by Q3."
Then I ask the awkward question: what problem are we solving?
Silence. Or worse, a use case reverse engineered to justify the technology someone has already bought.
Maslow's hammer, now with a metered bill
Abraham Maslow wrote it in 1966: if the only tool you have is a hammer, you treat everything as a nail. That has been the quiet failure mode in technology projects for sixty years. Service oriented architecture for a two system integration. Microservices for a team of five etc.
AI is the same trap with one important difference. The hammer now has a meter attached.
Traditional over engineering cost you a bad architecture and some regret. Over engineering with AI costs you per token, per call, per retry, per agent in the loop, forever. Most organisations do not model that properly until the second invoice lands and the finance director starts asking questions nobody prepared for.
Right job, right situation
Two examples, both real patterns.
Where it often is not the right tool: A high volume, rules based, deterministic process. Same inputs, same outputs, full audit trail required. That is classic RPA or a workflow engine. Putting a probabilistic model in the middle of a deterministic process buys you variability you did not want, an evaluation burden you did not budget for, and a regulator asking why the answer changed on Tuesday.
Where it usually is: Spec driven development and design. You write the intent, the constraints and the standards once, and the model works within them. Same challenge, same solution, whether it is code or product. The gains are not just speed. It lifts the floor. Your least experienced engineer or designer starts producing work that reflects the standards of your best one, because everyone is working from the same specification. That is throughput and consistency at the same time, which is rare.
The difference between those two is not model quality. It is fit. The right tool for the job.
The bit everyone skips
Here is the number worth sitting with. Gartner predicts that through 2026, organisations will abandon 60% of AI projects that are not supported by AI ready data. In the same research, 63% of data management leaders said they either did not have, or were not sure they had, the right data management practices to support AI.
That is not an AI failure. It is a foundations failure wearing an AI badge.
Google's research team made the same point about machine learning back in 2015 in "Hidden Technical Debt in Machine Learning Systems". The model code is a tiny box in the middle of a very large diagram. Everything around it, the data collection, verification, feature management, serving and monitoring, is the actual system. Nothing about generative AI has changed that. If anything, it made the surrounding surface area bigger.
The unglamorous checklist
Before you buy anything, be honest about these:
Accessible data. If it is trapped in on premise systems with no clean egress, your AI roadmap is really a migration roadmap with a nicer name.
Domains and boundaries. Zhamak Dehghani's data mesh work made the point well. Someone has to own a data product, define its interface and be accountable for its quality. Without ownership you have a lake with no lifeguard.
Metadata and lineage. If you cannot answer "where did this come from and who touched it", you cannot answer a regulator either.
Quality and accuracy. Gartner puts the average annual cost of poor data quality at around 12.9 million dollars, based on its 2020 research. A model does not fix bad data. It industrialises it and states it confidently.
Governance and access control. Which data can a model see? Which data must it never see? Personal data, commercially sensitive data, data with consent constraints. That decision belongs to a policy, not to whoever configured the connector.
A defined business problem. Written down. With a number attached. Before the build starts.
To be clear, I'm all in on this
I use AI every single day. It has changed how I write, how I research, how I review code, how I pull a proposal together and how quickly I can get from a blank page to something worth arguing about. The use cases are genuinely enormous and we are still early. I am not here to talk anyone out of it.
The point is narrower than that. Not every solution needs AI, and the ones that do need something underneath them.
Rubbish in, rubbish out is as old as computing. What is new is the volume and the confidence. Bad data used to produce an obviously wrong report that somebody caught. Bad data now produces a fluent, plausible, well structured answer that nobody questions, at scale, in front of customers. Good data does the opposite. It makes the model look brilliant, because it is finally working with something it can trust.
So before you build, get the foundations honest. The full list is longer than anyone's post, and it will look slightly different in every organisation. But these four turn up almost every time:
In cloud, enough of it, in the right places, to actually serve a model.
Accessible, so the people and systems that need it can reach it without a six week request.
Controlled, so you know what a model is allowed to see and can prove it.
Accurate, because everything downstream inherits whatever you feed it.
None of that is exciting. Nobody gets a standing ovation for a metadata standard or a data quality gate. But it is the entire difference between an AI programme that compounds and one that quietly disappears from the board pack.
Do the basics properly and AI stops being a project. It becomes the easy part, and then it is everywhere, because it finally works.
I would be interested to hear from others building this out. What did you have to get right in your data before AI really started paying off?