Is your data ready for AI? Probably more than you think

The most common reason mid-size companies give us for postponing AI is some version of "our data is not ready." A data readiness assessment gets commissioned, a warehouse project gets scoped, and the AI work moves to next year. Most of the time this is a mistake built on an outdated picture of what AI needs. Data readiness for AI is not a company-wide state you reach after a two-year program. It is a question you ask about one workflow at a time, and for the workflows most companies should start with, the honest answer is usually already yes.

The outdated picture comes from the previous era. Classical machine learning needed large volumes of clean, structured, historical data, so "get the data right first" was real advice in 2018. Language models changed the entry requirements. They read what your company actually produces: contracts, emails, tickets, reports, PDFs with inconsistent formatting. Messy documents are their native habitat. The bar did not disappear, but it moved, and it is worth knowing exactly where it now sits.

What each kind of project actually needs

An assistant that answers from your documents needs the documents to exist somewhere findable, and it needs someone to say who is allowed to read what. That is the whole entry ticket. It does not need a single source of truth, a taxonomy, or consistent templates. The retrieval layer handles variety; access rules handle safety.

Document processing, extracting data from invoices, claims or contracts, needs a sample of real inputs in all their ugliness, and a person who can state what the correct output is for each. That second item is ground truth, and it matters far more than format consistency. Ugly inputs with clear right answers make an excellent first project. Clean inputs where nobody agrees on the right answer make a doomed one.

Workflow automation needs access: an API, a database connection, or at worst a reliable export from the systems the workflow touches. It does not need those systems replaced or their data centralized first.

Notice what none of these need: the data lake, the master data management program, the great cleanup. Those projects can be worthwhile on their own merits. They are not prerequisites for AI, and treating them as prerequisites is how companies stay in year zero indefinitely.

What actually blocks projects, and it is rarely quality

The real blockers we meet are decision problems wearing data costumes. Nobody can define the correct answer: if two senior people disagree on what the right output of the workflow is, no model can settle it, and this surfaces the moment you try to build ground truth. Access is politically unresolved: the documents exist but the security review of who and what may read them has never been forced to a conclusion. Two systems disagree and no one has ruled which one wins: the CRM says one renewal date, the billing tool says another, and the fix is an ownership decision, not an engineering task.

Every one of these can be resolved in a meeting. None of them is resolved by a data platform.

Messiness the system handles, and the kind it cannot

Duplicates, inconsistent formats, typos, scanned PDFs, seven versions of the proposal template: fine. Modern pipelines absorb all of it, and pretending otherwise is how vendors sell you a year of preparation.

What the system cannot absorb is wrong content presented as current. An assistant will quote your obsolete policy with total confidence, because nothing marks it obsolete. The fix is scoping, not cleaning: pick which sources count, assign an owner for freshness, exclude the rest. That is days of decisions, and it does more for accuracy than any quality program, for reasons we unpack in why RAG assistants give wrong answers.

Data readiness for AI is a per-workflow verdict

The order of operations most companies get backwards: pick the workflow first, then examine only the data that workflow touches. A readiness question scoped to one process ("are the last two years of claims accessible, and can Marie state the correct outcome for a sample of fifty?") gets answered in a week. The unscoped version ("is our data AI-ready?") is unanswerable and therefore permanent. Choosing that first workflow well is its own discipline, and the criteria are covered in how we scope an AI project.

There is also a compounding effect that the wait-first strategy forfeits: usage improves data. The first assistant surfaces the stale documents. The first extraction project forces the ground truth conversation. Companies that ship discover their data problems in priority order, sorted by what actually matters to a live workflow, instead of guessing at them from an audit deck.

If your AI plans are currently parked behind a data program, the cheapest way to test whether that is justified is a prototype on your real, imperfect data. That is deliberately how every one of our custom AI engagements starts: 2 to 4 weeks, one workflow, your documents as they are today. The result settles the readiness debate with evidence, in either direction.