Your Data Is Not Ready for AI. Start Anyway.

Photo: Watty62, via Wikimedia Commons · CC BY-SA 4.0
One of the most common reasons SMEs give for not starting with AI is that their data is not ready. The master data is out of date, article codes are inconsistent, half the customer records spell the same company three different ways, and the ERP is full of fields that were repurposed for something else back in 2015.
All of that is usually true. It is also true of nearly every company, including large ones with a dedicated data team. If clean data is the entry ticket, nobody gets in.
Cleaning without a purpose does not stick
The standard answer is a data quality project. Someone is asked to clean up the article master, reconcile customer records and fill in the missing fields. It is hard work, and it tends to run out of energy after a few months, because nobody downstream is visibly waiting for the result.
Then the data slowly degrades again, because the process that created the mess never changed. The same people enter the same information in the same way, under the same time pressure.

A filing room at the US Department of Justice, 1892. The tools have changed since then. Duplicates, missing fields and knowledge that lives with one clerk have not.
Photo, via Wikimedia Commons · Public domain
Let a workflow tell you what matters
The alternative is to start with one workflow that depends on the data, and fix what that workflow needs along the way. If you automate incoming quote requests, you find out very quickly which article codes are ambiguous, because the extraction stumbles on exactly those. If you connect planning to the ERP, you find the routings that are wrong, because the calculated capacity will not match what the shop floor sees.
That is a much smaller and far more motivating data project. The list of problems is concrete, it is ranked by what actually blocks work, and there is someone who genuinely cares whether it gets fixed.
Design for messy input from day one
- Expect missing values, and decide per field what happens when one is missing: ask, flag, or fall back to a default that someone signed off on.
- Keep the original text next to every extracted or derived value, so a person can always see where it came from.
- Treat the corrections people make as a to-do list for the master data. If the same customer name gets corrected every week, fix it at the source.
- Measure data problems the same way you measure the model: how often, in which fields, and what they cost.
In practice
The first version of a system should work with the data you have and make the data problems visible. The second version is where most of them get fixed, because by then everyone knows which ones matter.
What does need to be in place
Starting with imperfect data is fine. Starting with no access to data is not. Before a project begins, make sure the relevant systems can actually be read, that someone knows what the key fields mean, and that there is a person who can decide what the right answer is when the data disagrees with itself.
Those three things matter more than a spotless article master. With them in place, the data gets better because it is being used. Without them, no amount of cleaning upfront will help.