Your Data Isn’t Ready for AI Yet, and That’s the First Thing to Fix

Every AI proposal has a line for "data integration," and almost every one underestimates it. The demo works because it runs on a clean sample: twenty well-written help articles, a tidy product spreadsheet, a handful of test customers. Then the build connects to the real systems and the real data arrives — duplicated, outdated, inconsistent, and scattered across tools that were never designed to talk to each other. The agent starts quoting last year's return policy, recommending discontinued products, and greeting one customer by three different names. Nobody changed the model. The model is doing exactly what it was asked to do: answer from the data it was given. This post is the data discipline for AI projects: why data is the real bottleneck, the specific problems that break agents and assistants, what "ready" actually means, and how to find and fix the gaps before you pay for a build that depends on them.

The core argument in one paragraph: an AI system is only as accurate as the data it reads, and it has no way of knowing which of two conflicting records is true, which document is current, or which field someone left blank on purpose. So it picks one, sounds confident, and moves on. That makes data quality the single biggest predictor of whether an AI project works in production — more than model choice, prompt quality, or budget. The good news is that "AI-ready" doesn't mean perfect. It means the specific data one use case depends on is accurate, current, consistent, and accessible. That's a scoped, fixable problem, and it's far cheaper to fix in a two-week audit before the build than in a three-month cleanup after launch.

Why data, not the model, is where AI projects stall

For most business use cases, the model is no longer the hard part. Today's models can read, summarise, classify, and reason well enough for support, sales, operations, and internal search. What they can't do is know things your business never wrote down correctly. Retrieval systems, the RAG setups behind most AI assistants, pull whatever text best matches the question, not whatever text is true. Agents connected to your CRM or ERP through MCP read the record that comes back, not the one your team would have chosen. The model has no context for which spreadsheet the finance team actually trusts.

Messy data has always been a problem, but people worked around it. A support rep knew the old policy PDF was outdated. A salesperson knew that "Acme Ltd" and "ACME Limited" were the same account. A warehouse manager knew which stock column was real. That knowledge lived in people's heads, and it quietly corrected the data every day. AI removes that human filter. It reads the data literally and serves the result to customers, often with no one checking in between. Problems that cost a few minutes of human judgement per day become wrong answers repeated at scale.

Six data problems that break AI projects

We see the same six patterns in almost every pre-build audit:

Duplicates and conflicting records. The same customer exists three times with different emails, the same product has two SKUs with different prices, the same supplier has two bank details on file. A person spots the duplicate; an agent picks one, and it may well be the wrong one.

No single source of truth. Prices live in the ecommerce platform, the ERP, and a sales spreadsheet, and they don't match. Stock levels differ between the warehouse system and the storefront. Until someone decides which system wins for each field, the AI will answer from whichever one it happens to read.

Outdated documents that never got deleted. Shared drives and help centres keep everything: the 2022 return policy, three drafts of the onboarding guide, a pricing sheet from before the last increase. Retrieval doesn't know which is current. If the old version matches the question better, the old version wins.

Missing and inconsistent fields. Product descriptions without dimensions or materials, customer records without a country, tickets without a category, dates written four different ways. AI can't recommend a product by size if half the catalogue has no size, and it can't route tickets by type if nobody filled in the type.

Knowledge trapped where systems can't reach it. The real answers to many customer questions live in email threads, WhatsApp chats, scanned PDFs, and the head of the person who has been there longest. If it isn't written down somewhere the AI can access, the AI doesn't know it — and it will often fill the gap with a plausible guess.

Sensitive data mixed in with everything else. Salary sheets sit next to sales decks, customer ID scans sit in the same folder as product photos, internal notes about a client sit in the shared CRM field. Connect an AI to that folder and it can surface anything inside it to anyone who asks the right question. Permissions that were "good enough" for humans are rarely good enough for an assistant that reads everything instantly.

What AI-ready actually means

The phrase "get our data ready for AI" sounds like a company-wide transformation programme, and that's exactly why it gets postponed. It doesn't need to be. Data readiness is always relative to one use case. A support agent needs current policies, accurate order status, and a clean product catalogue. It doesn't need your historical finance data, your HR files, or your marketing archive. Scope the readiness work to what the first use case actually reads, and a vague multi-year problem becomes a list of specific fixes.

For that scoped set of data, four tests decide whether it's ready. Accurate: the records are correct, and duplicates have been merged or flagged. Current: outdated documents are removed or clearly archived, and there's a process to keep them current after launch. Consistent: one source of truth is agreed for every field the AI uses, and formats are standard. Accessible: the data lives somewhere the AI can reach through an API, an MCP server, or a document store, with permissions that expose only what this use case needs.

If the data passes those four tests, build. If it fails one, fix that first — or narrow the use case until it passes. A support agent that only answers order-status and shipping questions on clean data will outperform one that tries to answer everything from a messy help centre.

The two-week data audit before you build

You don't need a data team to find out whether your data is ready. A focused audit of one use case fits into two weeks and costs a fraction of a stalled build.

Days 1–2: Map what the use case reads. Write down the twenty or thirty questions or tasks the AI must handle, then trace each one to the exact system, document, or field that holds the answer. Most teams discover at this step that a few answers live nowhere at all, only in people's heads.

Days 3–5: Sample and score. Pull a real sample from each source — a hundred customer records, the fifty most-viewed help articles, a slice of the product catalogue. Count duplicates, blank fields, outdated content, and conflicts between systems. Real counts on a real sample beat any amount of guessing about "how messy" the data is.

Days 6–8: Decide the source of truth. For every field the AI will use, agree which system wins when two disagree, and who owns keeping it correct. This is a business decision, not a technical one, and it's the step most projects skip.

Days 9–12: Fix the critical gaps. Merge obvious duplicates, archive outdated documents, fill the fields the use case can't work without, and write down the answers that only lived in someone's head. Leave everything outside the use case alone for now.

Days 13–14: Test with the real questions. Run the questions from day one against the cleaned data, by hand or with a quick prototype, and check whether a correct answer is now findable for each. The questions that still fail tell you exactly what to fix next, or what to leave out of version one.

What AI can clean for you, and what it can't

There's a useful irony here: AI is very good at a lot of the tedious cleanup work that makes data ready for AI. Used well, it can cut weeks of manual effort down to days.

What AI does well. It can spot likely duplicates that exact-match rules miss, like "Acme Ltd" and "ACME Limited" at the same address. It can extract structured fields from messy text, pulling dimensions, materials, and colours out of free-text product descriptions — the same approach behind our product descriptions at scale post. It can standardise formats for dates, addresses, phone numbers, and units. It can flag documents that contradict each other or look outdated, and it can turn email threads and scanned PDFs into clean, searchable text.

What AI can't do. It can't decide which system is the source of truth, because that's a business decision about how your company runs. It can't know which of two conflicting prices is correct, or whether a policy change last month was ever written down. It can't invent the missing knowledge that only lives in a long-time employee's head. And it shouldn't be trusted to make bulk changes to live records unsupervised.

The right pattern is AI proposes, humans approve. Let AI generate the merge suggestions, extracted fields, and flagged conflicts in a review queue. Have the person who owns that data approve them in batches, spot-check a sample, and only then write the changes back. It's the same principle as approval gates for agents: speed from automation, judgement from people, and nothing irreversible without a human click.

The pragmatic version for a small business

If you run an SMB and want to start an AI project this quarter, keep it simple. Pick one use case with clear value, such as order-status questions, product recommendations, or invoice processing. List the questions it must answer and where each answer lives. Pull a small sample from each source and count what's broken. Agree one source of truth per field and one owner for keeping it right. Fix only the gaps that block that use case, using AI to speed up the cleanup and a person to approve the changes. Then build, and keep the data owner involved after launch, because data that was clean on day one drifts within months if nobody owns it.

When you're reviewing an AI proposal, ask the vendor one question: what data does this depend on, and how will we know it's good enough before we build? If the answer is vague, the data work is either missing from the quote or about to arrive as a change request in week three.

The strategic point underneath: as models become more capable and more interchangeable, your data becomes the part of your AI system that's genuinely yours. Any competitor can use the same model you use next month. They can't use your clean product catalogue, your accurate customer history, your up-to-date policies, or the know-how your team finally wrote down. Businesses that treat data readiness as the first phase of every AI project get systems that are accurate on day one and improve over time. Businesses that skip it get impressive demos, disappointing launches, and a cleanup project they never budgeted for. The fix isn't glamorous, but it's the most reliable way to make an AI investment pay back.

Every AI project we take on starts with this data audit — mapping what the use case reads, scoring a real sample, agreeing a source of truth, and fixing the gaps that matter — because the best model in the world can only be as right as the data you give it.