“Your data needs to be clean before you can do anything with AI” is the most repeated advice in this field and one of the least actionable. Clean by what standard, in which systems, to what threshold, and in what order? Without answers to those, it functions mainly as a reason to postpone.
It is also, taken literally, wrong. Cleaning all of your data before an AI project is an unbounded task that will outlast the project, the budget, and possibly the strategy that prompted it. The useful version is narrower and has an order to it.
The trap: cleaning everything
Data cleansing sold as a service is often scoped as a sweep — the estate goes in, a cleaner estate comes out. That scope is attractive because it is easy to describe and it is a poor fit for what an AI project actually needs, for two reasons.
First, the system will read a fraction of what you hold. Cleaning the rest is real work producing no effect on the outcome you are paying for. Second, and worse, a sweep has no completion criterion. There is always another inconsistency, so the work ends when the budget does rather than when the data is fit for purpose — and nobody can tell you which of those happened.
The alternative is to invert it: decide what the system will read, then clean backwards from there.
The order that matters
These are ordered by dependency, not by effort. Doing them out of sequence means redoing them.
1. Scope — what does the system actually read?
Name the fields. Not the tables and not the systems — the fields, and for each one, what decision it participates in. This is unglamorous, takes a day or two, and is the single highest-leverage hour in the whole exercise, because it converts “clean the CRM” into a finite list.
It also surfaces the fields nobody can justify, which are usually a meaningful share. A field the system reads that no decision depends on is scope you can delete rather than clean.
2. Identity — is one thing one thing?
Duplicate and fragmented entities come first among the actual defects, because everything downstream inherits the error. If the same customer exists three times, then completeness, consistency and accuracy are all being measured against the wrong denominator, and any aggregate the system produces is wrong in a way that looks plausible.
This is also the defect most likely to be systemic rather than incidental — it usually traces to two systems that were never reconciled, or to a form that never checked. Which leads to the point below about fixing the source.
3. Completeness, on the fields that carry the decision
Only now, and only for the fields from step one. The question is not the fill rate; it is whether the blanks are random or patterned. A field that is empty for a fifth of records more or less at random is a tolerable gap. A field that is empty for a fifth of records because one team never filled it in, or because it did not exist before a migration, is a different animal entirely — the absence carries information, and a system trained or driven on it will learn the pattern of the gap.
4. Consistency — the same thing written the same way
Formats, units, encodings, categorical values that drifted. Dates stored three ways. A status field with values that were renamed but never backfilled. This is the most mechanical layer, the most automatable, and the one people start with because it is visible — which is why it so often gets done first and then invalidated by a deduplication pass that should have run before it.
5. Timeliness
A value can be perfectly formatted, complete, unique and stale. Contact records, pricing, entitlements and org structure all decay, and none of the checks above can see it. The useful question per field is how long a value stays true, and whether anything currently refreshes it.
6. Accuracy, against something
Last, because it is the most expensive and it needs the others done first to be affordable. Accuracy means agreement with a source of truth, so the real work is nominating one per field — and discovering that two systems both claim the role for the same field is one of the more useful findings the whole exercise produces.
The one that saves the most money: fix the source
Every defect above is either a one-off or a production line.
A one-off — a bad migration, an import gone wrong — is worth cleaning, because it is finished producing errors. A production line is not: if a form accepts free text where it should constrain, or two systems write the same field with no reconciliation, cleaning the output means doing it again next quarter and every quarter after.
So for each material defect, ask what produced it and whether that is still running. The answer changes the work from cleansing to a small change at the source plus a one-time correction, which is usually cheaper and always more durable. This is the part most likely to be left out of a fixed-price cleansing quote, because it is a change to somebody else's system.
What AI changes about the standard
The tolerance is different from a reporting project, and in a way that surprises people.
Model-driven systems are comparatively forgiving of random noise. Scattered typos and occasional missing values degrade quality gently. What they handle badly is systematic error — a defect concentrated in one region, one product line, one period, one team's records. Random noise makes a system slightly worse for everyone. Systematic error makes it confidently wrong for a specific group, and it does so quietly, because the aggregate accuracy still looks acceptable.
The check that matters most, and it is cheap: take your error rate per field and break it down by segment — region, product, source system, and time. If the rate is roughly flat, you have noise and you can proceed. If it spikes somewhere, you have a bias with an address, and it is worth fixing before anything is built on top of it.
That single breakdown is more informative than any overall quality score, and it is the one measurement a generic cleansing engagement is least likely to produce, because it requires knowing what the data will be used for.
What “clean enough” means
It means the defects that remain are known, measured, and do not concentrate in a segment the system will make decisions about. That is a threshold you can actually hit, unlike perfection, and it is a threshold you can write into an agreement.
Two things to insist on in a quote: the scope expressed as fields rather than systems, and a stated completion criterion per field. A cleansing engagement without a completion criterion is priced by duration, and you will find that out at the end.
Where this work sits
This is labor and judgment. The platforms holding the data — the CRM, the ERP, the warehouse — stay in your name and you pay for them directly; nothing here is resold or licensed through us. What AI integration work adds is the scoping, the segment breakdown, and the argument about which defects are worth fixing at the source rather than in the output.
The order above is most of the value. If you take nothing else from this: name the fields first, deduplicate before you standardize, and break your error rate down by segment before anybody declares the data ready.
Related reading: What API integration costs you after it ships — because “fix the source” usually means changing something on the other side of a seam. And legacy modernization without a rewrite, for when the system producing the defects is the one nobody wants to touch. And custom AI or off the shelf? — the decision this work feeds, which lands the same either way.