Ask why a business hasn't started an AI project and "our data isn't ready" comes up a lot. It sounds responsible, like the kind of thing a careful operator says before committing budget. And sometimes it's true. Some deployments won't work until someone has done the unglamorous work of sorting out what's in your systems.
For a lot of businesses, though, "our data isn't ready" stands in for "we haven't tried it yet, and tidying everything up feels safer than starting." The data cleanup becomes the thing that has to happen before the real project can happen. Cleanup projects are open-ended by nature, so they absorb the calendar and nothing ships.
This happens because "data readiness" gets treated as a single requirement. Whether a deployment needs clean, structured, consistent data depends on the job you're asking the AI to do. For much of the work SMEs want AI to do, the data is already ready enough.
Two different jobs, two different requirements
Most AI deployments fall into one of two categories, and they have almost opposite relationships with data quality.
The first category is interpreting unstructured content. Reading inbound support emails and triaging them. Searching contracts, policies or past correspondence to answer a question. Drafting a first pass of a proposal from scattered notes. Summarising a long thread so someone doesn't have to read all of it. In this category, the mess is the input. The model's job is to read human language, which is inconsistent, informal and occasionally contradictory, and make sense of it. That's what it's built for. A support inbox where three people phrase the same request five different ways is the normal shape of the problem.
The second category is aggregating or writing into structured systems. Pulling numbers out of a CRM to forecast pipeline. Rolling up deal stages across a sales team to report on conversion. Syncing a record from one system into another where both expect specific fields in specific formats. Here, inconsistency is dangerous, because the output looks authoritative whether or not it's correct. If half your sales team calls a stage "Proposal Sent" and the other half calls it "Quoted", a model asked to report on pipeline by stage will quietly give you a wrong number with complete confidence. Nobody will notice until the forecast misses badly enough to go looking.
In that second category, the "our data isn't ready" instinct is usually correct, so audit before you build. In the first category, it's usually an excuse, and it's costing you a working system you could already have.
Why this gets missed
People picture "an AI project" as one undifferentiated thing, and then reason from the hardest version of it. Someone hears about a business that spent months reconciling CRM fields before an AI reporting tool could trust them, and concludes that every AI deployment needs that same foundation. A tool that drafts replies to customer enquiries from your existing email history never touches your CRM stages, so it doesn't care that they're a mess.
The practical fix is to ask "is our data ready" separately for each deployment. Does this task require the AI to aggregate or write structured records? Or does it require the AI to read and interpret content that already exists, in whatever state it's in? The answer changes what work, if any, needs to happen first.
Sequencing the work
Once you've separated the two categories, the sequencing mostly follows.
For unstructured-content deployments, start building against your real data as it exists today. Point the tool at the actual support inbox, the actual contract folder, the actual meeting notes. Whatever breaks tells you what, if anything, needs fixing, and it's often narrower than you'd fear. The model might struggle with one document format, or get confused by an abbreviation your team uses. Each of those is a scoped fix you can make while the tool is already in use.
For structured-output deployments, do the audit before you build, and scope it to the fields the deployment touches. Pipeline forecasting needs consistent deal stages and consistent date fields, and those are the fields the audit has to cover. Start with the three or four fields the deployment reads, and make them consistent across the team that owns them.
AI is also good at the normalising work itself. Mapping "Proposal Sent" and "Quoted" to the same underlying stage, flagging duplicate records, and extracting structured fields from messy free-text notes are pattern-matching tasks a model handles well. They can be the first phase of the deployment.
What this doesn't let you skip
Data quality still matters. If your system of record has no reliable key fields at all (no consistent customer ID, no consistent date format, records duplicated across three spreadsheets with no way to tell which is current), that's real foundational work, and no model will paper over it convincingly for long. Structured reporting built on top of that will look like it's working until someone checks the numbers against reality.
So for each piece of foundational work, ask which deployment needs it. If you can't name one, it can wait.
Where to start
Before you defer a project on data grounds, work out which category it falls into. If the AI needs to read and interpret content that already exists, such as tickets, documents, notes and correspondence, you can probably start now with what you have and let the results show you what needs tidying. If the AI needs to aggregate across records or write into a system of record, audit the specific fields that deployment touches, and leave the rest of your data alone for now.