Get Your Data Ready for AI: The Unglamorous Work That Decides Everything

There’s a quiet truth behind almost every AI project that disappoints: the model was fine. The demo worked. What broke was the data — incomplete, scattered across systems that don’t talk, full of inconsistencies nobody noticed until a machine started reading it literally.

AI doesn’t fix messy data. It exposes it, at scale, with confidence. An assistant grounded in a half-correct customer record will give half-correct answers in a convincing tone — which is worse than no answer at all. So before the exciting part, there’s unglamorous work: getting your data into a state where AI can actually be trusted with it. This is what that work is, and how to do the useful 20% without a year-long data programme.

Why data, not the model, is the bottleneck

The models are extraordinary and getting better every few months — and they’re a commodity. You and your competitor can call the same one. What you have that they don’t is your data: your customers, your orders, your history, your documents. That’s the moat, and it’s also the constraint. The ceiling on what AI can do for your business is set by what your data can tell it.

Put differently: a brilliant model on bad data is a confident liar. A modest model on clean, accessible data is a useful colleague. Almost every business would get more value from improving the second factor than from chasing the first.

The five things “ready” actually means

“Data readiness” sounds like a megaproject. It isn’t — it’s five concrete properties, and you only need them for the data the AI will actually use.

1. Accessible. Can a system reach the data at all, through an API or a database — or does it live only in a PDF, a desktop spreadsheet, or someone’s inbox? AI can’t use what it can’t reach. This is often the first real blocker, and it’s why connecting your tools with APIs and protocols like MCP is frequently step zero.

2. Accurate. Does the data reflect reality? Stale prices, duplicate customers, contacts who left two years ago. Humans silently work around this every day (“oh, ignore that record”). AI doesn’t know to.

3. Consistent. Is “Acme Ltd”, “Acme Limited” and “ACME” the same company to your systems, or three? Are dates, currencies and units written the same way everywhere? Inconsistency is invisible to people and catastrophic for machines.

4. Complete enough. Not perfect — enough for the job. A churn predictor needs usage history; a support assistant needs your actual help articles. Know which fields matter for the task and make sure they’re populated.

5. Governed. Who’s allowed to see what? An AI assistant that can read everything will happily surface a salary or a confidential contract to whoever asks. Permissions and a basic record of what data is used where aren’t bureaucracy — they’re what makes AI safe to deploy.

The honest assessment: where’s your data right now?

Before any project, do a one-page audit of the data it will touch. For each source, answer four questions:

• Where does it live, and can a system get to it programmatically?
• How clean is it, roughly — pristine, usable, or a known swamp?
• Who owns it, and who’s allowed to use it?
• Is it structured (database fields) or unstructured (PDFs, emails, scanned docs)?

You’ll usually find the same pattern: the data exists, but it’s trapped, inconsistent, or split across tools that were never meant to share. That’s normal. The audit’s job isn’t to depress you — it’s to turn a vague “our data’s a mess” into a short, fixable list.

Structured vs unstructured — and why it matters now

For years, the unstructured pile — contracts, emails, scanned invoices, meeting notes — was effectively dark data. Too expensive to read, so it sat unused.

That equation has flipped. Modern AI reads unstructured documents well enough to pull out the structured facts hidden inside them — which is the whole premise of automating document-heavy work. The practical consequence: data you’d written off as unusable may now be your richest source. Don’t scope it out of habit. Some of the best AI projects start by switching the lights on in that dark pile.

Start small: the thin-slice approach

The wrong move is a “data transformation programme” — eighteen months, a six-figure budget, a data lake nobody asked for. By the time it lands, the business has changed and the appetite is gone.

The right move is a thin slice. Pick one valuable use case — answer support questions from our docs, flag invoices that don’t match orders, predict which trials will convert — and get only the data that use case needs into shape. Clean those three sources, not all thirty. Ship it. The working result earns the budget and the patience for the next slice, and you learn what “ready” really means for your business by doing it once, cheaply.

This mirrors how we approach automation generally: prove value on something small and real, then expand. A data lake delivers value on the day it’s finished; a thin slice delivers value in week three and pays for the rest.

A minimum data-readiness checklist

For the specific use case you have in mind, you’re ready to build when:

• The data the AI needs is reachable by a system (API/database), not locked in files.
• The key records are deduplicated and broadly accurate.
• Names, dates, currencies and IDs are consistent across the relevant sources.
• The fields the task depends on are actually populated.
• You know who can see what, and the AI respects those permissions.
• There’s a person who owns each data source and can answer questions about it.

If most boxes are ticked for your one use case, build. If they’re not, that gap is the first project — and it’s a cheaper, lower-risk place to start than the AI itself.

Frequently asked questions

Do we need a data warehouse or data lake before we can use AI? Usually no — and treating it as a prerequisite is how AI projects get delayed by a year. Most SME use cases need a handful of sources connected and cleaned, not a central platform. Build the warehouse later, if and when several projects justify it.

How clean does the data really have to be? Clean enough for the specific task, no cleaner. A customer-facing assistant has a high bar because mistakes are public; an internal draft-generator can tolerate more noise because a human reviews the output. Match the effort to the stakes.

Our data is spread across many tools. Is that a dealbreaker? No — it’s the normal starting point. The job is to connect the relevant ones, which is an integrations project, often using APIs or MCP. You don’t need everything in one place; you need the AI able to reach the right things.

Isn’t this just a way to sell us a bigger project? The opposite. Honest data-readiness work usually makes the AI project smaller and more likely to succeed, because you’re not building on sand. We’d rather scope a thin slice that works than a grand programme that stalls — and so would your finance team.

---

The unglamorous truth is that “doing AI” is mostly “getting your data in order for one good use case.” Do that, and the model almost takes care of itself. If you want a clear-eyed read on where your data stands and the smallest project that would prove value, we offer a free assessment — see our AI integrations and API integrations pages, or start a conversation.