Data Quality Before AI: The Unglamorous Work That Decides Whether It Works

Most failed AI projects were data projects that nobody scoped as data projects. The model was fine. The build was fine. The information going in was inconsistent, incomplete or wrong, and the outputs were confidently useless.

This is the least interesting article in this cluster and the one most likely to save you money.

This article is part of our guide to the data you already own.

The wrong target

The instinct is to aim for clean data. That is a project with no end, and pursuing it is how businesses spend two years on a data programme and never ship anything.

The right target is clean enough for this specific decision. Which means you cannot assess data quality in the abstract. You assess it against a question.

The same customer list can be entirely adequate for sending statements and entirely inadequate for analysing churn. Neither assessment is wrong.

The six dimensions that matter

For any given question, check these. Most projects fail on two or three, and it is rarely the ones people expect.

Completeness. What proportion of records have the fields you need? Not the record count, the field-level fill rate. A CRM with 12,000 contacts and industry populated on 900 of them cannot answer anything by industry.

Consistency. Is the same thing recorded the same way? "Ltd", "Limited", "LTD". Dates as text. Free-text status fields with nineteen variations of "closed". This is the most common failure by a distance and the most tedious to fix.

Accuracy. Does it match reality? Harder to test, and the practical method is to take a sample of thirty records and verify them by hand against something authoritative. Thirty is enough to tell you whether you have a 2 per cent problem or a 30 per cent problem.

Timeliness. How current is it? A customer database where a third of contacts have left their companies is not wrong exactly, it is expired.

Uniqueness. Duplicates. Every business has them and almost every business underestimates them. They inflate counts, split histories and corrupt any per-customer analysis.

Lineage. Do you know where each field came from and when? This matters most when two systems disagree, which they will, and you have to decide which to believe.

How to test in a day

Pick the question. "Which job types do we underprice."

List the fields required to answer it. Job type, quoted value, actual cost, date. Four fields.

For each field, measure the fill rate. One query, or a column count in a spreadsheet. Below 70 per cent on a required field and the question cannot be answered reliably without remediation.

For each field, count the distinct values. A job type field with 340 distinct values in 1,800 records is free text, not a category, and it will need mapping before anything works.

Sample thirty records and verify by hand. Against paper, against the client, against another system. Tedious, and it is the only way to test accuracy.

Count duplicates. Match on the most obvious key and see what comes back.

A day, and it will tell you whether your project is three weeks or three months. Skipping it is why estimates are wrong.

What to fix and what to leave

Fix only what the question requires. This is the discipline that separates a data project that ships from one that does not.

Fix: the fields you need, for the period you need, to the standard the decision requires.

Do not fix: everything else, however much it offends you. Note it, and move on.

Never fix by hand at scale. If remediation requires manually correcting thousands of records, the approach is wrong. Either map the variants programmatically, narrow the question, or accept a lower confidence answer.

The bit that gets skipped

Cleaning an archive is a snapshot. If nothing changes about how records are captured, the same problem returns.

The fix is almost always small: constrain a free-text field to a dropdown, make one field mandatory, add a single field to something people already complete. It costs very little and it is forgotten in the great majority of projects, which is why businesses clean the same data twice.

What good enough looks like

Rough guidance, and it depends on the decision.

For a directional answer such as which service line is underpriced: 70 per cent fill rate on required fields, consistent categories after mapping, and duplicates under 5 per cent.

For an operational answer feeding a system that acts: 95 per cent plus on required fields, enforced consistency, duplicates resolved, and a rule for what happens when data is missing.

For anything affecting individuals, such as pricing, credit or hiring: the above plus documented lineage, plus a human review step, plus the ability to explain any specific decision after the fact. See AI regulation in the UK.

Key Takeaways

• Clean data is not the target. Clean enough for a specific named decision is. Quality cannot be assessed in the abstract.
• Six dimensions: completeness, consistency, accuracy, timeliness, uniqueness, lineage. Consistency fails most often.
• Test in a day: fill rates, distinct value counts, thirty records verified by hand, duplicate count. This is what makes estimates accurate.
• Fix only what the question needs. Note the rest. Manual correction at scale means the approach is wrong.
• Change how data is captured going forward, or you will clean the same data again in three years.

Frequently Asked Questions

Can AI clean the data for us?

It is genuinely good at some of it, particularly mapping inconsistent free text to consistent categories, which used to be the most tedious part. It cannot tell you that a field is wrong when the wrong value is plausible, and it cannot decide what the correct categories should be. Use it for the tedium, not for the judgement. See AI literacy for non-technical leaders.

How long does data remediation usually take?

For a defined question on a few thousand records, two to six weeks. Estimates that come in much lower usually have not run the day of testing above. Estimates much higher are usually trying to clean everything rather than what the question needs.

Our data is in five systems that disagree. Where do we start?

Pick one as the source of truth for each field, deliberately, and write the decision down. Not one system for everything, one system per field. Customer address from the accounts package, contact details from the CRM, job status from the job system. That single decision resolves most of the conflict.

---

About to start an AI or data project and unsure whether your data supports it? Talk to Halo Technology Lab. Our strategy and scoping service includes the day of testing above, and we will tell you when the answer is that the data is not there.