Is your data ready for AI?

When a company reaches out about an AI project, the first question is almost always about the model: GPT or Claude, cloud or open-source, agent or plain assistant. That is the second right question. The first one, the one that decides whether the project will stand up, almost no one asks: can your data actually feed this AI? The model, today, comes off the shelf and it is excellent. Your data does not. Here is how to tell whether it is ready, before you pay anyone to write code.

Why does an AI project fail upstream of the model?

Because the model has become the easy part. A few years ago, building the intelligence was the real challenge; today you rent it by the minute. What stays hard is giving it clean material to work on. An AI project rarely fails because the model lacked power: recent models mostly go wrong when you feed them badly. It fails because the data was incomplete, scattered across ten tools that do not talk to each other, or unreadable by a machine. That is step 0: the one people skip because it is less exciting than a demo that answers on the first try, and it is exactly where success is decided. Before writing a line of code, I look at your data. Not to judge it, but to know what we can actually build on, and at what price.

What does data-ready actually mean?

Ready does not mean perfect. No company has perfect data, and waiting to tidy all of it before you start means never starting. Ready means: reliable enough for a machine to lean on without talking nonsense. Four questions are enough to check, and you can already answer them off the top of your head for your first use case.

• Is it complete, or full of holes the model will fill by inventing?
• Is it up to date, or frozen on a state from three years ago?
• Is it gathered in one place, or scattered across ten tools that do not talk to each other?
• Can a machine use it, or is it buried in scanned PDFs and screenshots?

None of these answers is a dealbreaker on its own, but each has a cost. The first is the most insidious: data full of holes does not block the project, it degrades it silently, because the model fills the gaps with something plausible. That is one of the mechanisms that make it hallucinate. The fourth is the most common, and the most underestimated: the information exists, but in a format nothing can read automatically.

Why does format matter as much as content?

Because data that is correct but unreadable by a machine is worth nothing until you make it readable. Your contracts, your invoices, your meeting notes all exist, but often as scanned PDFs, cobbled-together spreadsheets, or email threads. The information is there, trapped in a format the model cannot use as is. The good news: that barrier is falling. Vision models now read a badly scanned document better than yesterday's OCR, and turning your invoices and contracts into clean data now costs a fraction of what it used to. The bad news: almost no one measures the size of the job before diving in, and that is where the budget goes wrong.

How do you know what is actually usable today?

By looking, not assuming. That is the whole point of a data audit: I go through your sources, I test what a machine can really extract from them, and I sort. What comes out is three clear piles instead of a vague hunch.

• What is usable right away: we start the first use case on it, without waiting.
• What becomes usable with light cleanup: a few days of focused work, not a six-month project.
• What is better left aside for now: too costly to fix for what it would return.

This sorting is not academic. It sets the scope of the first project, its real budget, and the order in which you move. You stop guessing and start deciding on facts.

What do you gain by measuring it before you code?

Everything. Measuring it before you code turns three uncertainties into decisions.

• You rule out the doomed cases from the start, instead of discovering them after three months of development.
• You put a real number on the project, data included, with no nasty surprise halfway through.
• You begin with the minimal useful cleanup, not a full rebuild of your information system.

It is also what avoids the most common trap: a brilliant POC that never reaches production because it ran on demo data, hand-picked and clean, that reality will never supply. You invest in what is ready, not in a dream that collapses at the first real piece of data.

Do you have to tidy everything before you start?

No, and that is the most expensive misreading. You do not need a big data project, a brand-new warehouse, or perfect governance before launching your first use case. You need to know what is usable today, and where to begin. We aim for the minimal useful cleanup for that first case, we ship something that works, and we expand later with the data that this first success justifies preparing. The reverse, tidying everything first, is expensive, takes months, and drains everyone's morale before a single result. Data gets prepared at the pace of the uses it serves, not the other way around.

You do not build AI on data that is not ready. You would be building on sand.

In the end, the question is not whether your data is perfect, but what you can do with it right now. An audit answers that in a few days: what is usable straight away, what needs cleaning first, and the shortest path to a first result, before you commit a single euro to code. If you want to know where to start with your data, let's talk: a first conversation is often enough to see clearly, with no commitment.