Your data is the project. The AI is the reward at the end, and nobody audited the data before you signed.
You are about to sign for an AI build. The supplier has seen a demo of your process, a screenshot of the system it lives in, and a spreadsheet somebody exported last Tuesday. The contract has a section on scope, a section on milestones and a section on payment. It does not have a section on your data.
It should. That is where the project will be won or lost, and neither of you has looked.
The reward and the work
Everyone budgets an AI project as if the AI were the work. It is not. The AI is the reward at the end. The work is finding out what your data actually contains, as opposed to what everyone assumes it contains, and fixing the gap between the two before a model is allowed anywhere near it.
That is not a fashionable thing to say, because it is unglamorous and nobody bidding for a build wants to lead with it. But the research is unusually consistent on the point.
Through 2026, organisations will abandon 60% of AI projects unsupported by AI-ready data.
That is Gartner, in February 2025, from a survey of 248 data management leaders in which 63% said they either did not have, or were not sure they had, the right data management practices for AI. Six months earlier the same firm had predicted that 30% of generative AI projects would be dropped after proof of concept, and poor data quality was the first reason listed.
How many organisations actually have AI-ready data?
Very few, and far fewer than believe they do. In Precisely and Drexel University's survey of 565 data professionals, published in late 2024,, only 12% said their data was of sufficient quality and accessibility for AI, 77% rated their own data quality as average or worse, and 64% named data quality as their single biggest data problem. Cloudera's April 2026 index of 1,270 IT leaders found 84% confident in the accuracy and completeness of their data, while only 18% could say it was fully governed and nearly four in five admitted their AI work was constrained by data they could not get at.
Read those two together. Most people are confident in their data. Almost nobody's data is ready. Those are not the same organisations being asked different questions; they are the same organisations answering both.
Informatica's January 2026 survey of 600 data leaders closes the loop. 65% believe most of their staff trust the data they are feeding to AI. 57% say data reliability is a key barrier stopping AI projects moving from pilot to production. A year earlier the same series found two-thirds of organisations had failed to get even half their generative AI pilots into production.
Why the process you want to automate has the worst data
Here is the uncomfortable part.
You want AI for a process because it is slow, manual and nobody enjoys it. Those are the same reasons nobody has been looking at its data. The processes that get attention have clean data because attention is what cleans data. The processes that get ignored accumulate exactly the problems that make automation hard, and they do it quietly, for years, because the humans doing the work absorb every inconsistency without writing it down.
The field marked "category" has 14 official values and 140 actual ones, because for a decade people typed what they meant. The date field is sometimes the date the form arrived and sometimes the date it was processed, depending on who was on shift. The reference number is in the notes field about a third of the time. Half the records from before the system migration have a customer ID that no longer joins to anything. None of this is in a data dictionary, because there is no data dictionary. It is in the heads of three people, one of whom retires in March.
A person handles all of that without noticing they are doing it. A model does not. It will confidently process the 140 categories as if they were 140 real things, and the output will look fine right up until somebody checks it.
The sample is not the population
This is where suppliers get caught, and it is worth understanding the mechanism because it will be presented to you as bad luck.
The pilot runs on a sample. Somebody exports a few hundred records, or a folder of recent documents, and the demo is built against that. It works, because samples are chosen by people who know where the good records are, and because a few hundred of anything hides the edge cases that appear at a few hundred thousand.
We built a pipeline that turns bank statements into structured transactions. A generic extraction pass handled the sample beautifully. Run across the real population it hit statements from a dozen banks with a dozen layouts, multi-line descriptions, running balances in different columns, and scanned pages at an angle. The project succeeded because we treated each of those as a data problem to be characterised and handled, not as a model problem to be prompted around. We have written elsewhere about why pilots fail at the integration boundary. The data boundary sits right next to it, and a pilot that touches nothing real has tested neither.
Why nobody audited it before you signed
Because the answer might have been "don't".
A supplier bidding for the build has no commercial reason to spend unpaid days finding out that your data will not support the thing they are quoting for. The polite version is that data discovery is "part of phase one". The honest version is that phase one is after the contract, and whatever it finds arrives as a change request, priced by the people who now hold the contract. This is not dishonesty. It is the incentive, and everyone in the room can see it.
You are also, at that point, the one who has to explain to the board why the £60,000 project now needs £25,000 of "data remediation" that was nowhere in the original case.
What to do before you sign
Pull the real population, not the sample. Ask for an extract of a full year, or the whole table, and have somebody count the distinct values in every field that the AI is supposed to reason about. If a field with a dropdown has more than twice as many values as the dropdown, you have found your first month of work.
Find the field that is really two fields. Every long-lived system has one: a date that means two things, a status that was repurposed, a notes field where the important part lives. Ask the people who do the job today where they look when the obvious field is wrong.
Name the owner. If nobody owns the data, nobody has the authority to say a value is wrong, and the supplier will end up guessing. Guessing is what change requests are made of.
Ask what happens to the 140 categories. Not whether the model can cope, but what the business wants them collapsed into, and who decides. That is a business decision, not a technical one, and it cannot be delegated to a supplier or a model.
Ask whether it needs AI at all. A surprising share of the value in these projects is in the data clean-up itself. Once the categories are consistent and the reference numbers are in the right field, the automation often turns out to need no AI whatsoever, which is cheaper to build and, as we set out last time, far cheaper to run.
The business point
The data audit is a bounded piece of work. It takes days, not months, and it is the single highest-return thing you can do before spending real money, because it is the only step that can save you the whole budget.
Our sanity check is one day at £1,250, with no code and a written verdict at the end: build it, don't build it, or here is the cheaper thing to do first. A meaningful share of the time the cheaper thing is "fix the data, then see whether you still need the AI". That is not the answer anybody bidding for the build is going to volunteer, which is rather the point of asking somebody who isn't.