Usable data: the raw material of AI

What usable data is

Artificial intelligence never starts from a blank page. It learns, summarizes, or decides based on what it is given to read: files, historical records, contracts, machine logs, reports. This raw material has a simple name: data. And not all data is equal: some moves a project forward, some brings it to a stall.

Usable data is data that an AI can actually use to produce a useful result. Three conditions must hold at once. The data must be available: its location is known and it can be accessed. It must be reliable: it is accurate, current, and free of the gaps or duplicates that throw everything off. It must be sufficiently structured and documented: organized in a machine-readable format, with enough context to understand what each field means. Without all three conditions in place, even the most advanced tool produces a result that is, at best, vague, and at worst, wrong.

Appetite is not the problem. Among executives at French SMBs and mid-market companies, generative AI use rose from 31% to 55% in a year. The question is no longer whether AI is useful, but why so many promising projects stall. The answer is rarely the model. It is almost always the data.

Company size matters a great deal, less because of budgets than because of the state of the data. The more an organization has organized and made reliable its historical records, the more an AI finds to work with.

Available, reliable, structured

Consider the three conditions one at a time, along with a fourth that ties them together: documentation. These are the four dimensions to check before launching any project.

Available. The data exists and can be read. That sounds obvious; it is often the first obstacle. A sales history locked inside software no one still knows how to query, know-how that lives only in a shop floor supervisor's head, contracts scanned as images no machine can read: all of it exists, yet remains out of reach. Making data available is sometimes the longest part of the job.

Reliable. The data tells the truth. A customer file where the same customer appears three times under three different spellings, amounts in two currencies with no label, dates in the wrong format: an AI does not correct these errors, it propagates and amplifies them. The rule is blunt and well known: bad data in produces a bad result out.

Structured and documented. The data is organized in a readable format, and its meaning is known. A column named "stat_3" tells no one anything, neither a person nor a machine. Documentation — what each field contains, where it comes from, when it was last updated — turns a pile of files into a usable database.

These criteria are not just a matter of technology. They also depend on people who know how to read, correct, and document a database. That skill remains rare. In hospitals, only 6% of staff report having been trained in AI at their institution (Ifop / Acteurs Publics / UniHA): the raw material is missing, and so are the hands that prepare it.

One good way to test these criteria is to turn them into concrete questions. For each data source under consideration, ask who can access it, when it was last checked, what format it comes out in, and whether a newcomer would understand what it contains without a verbal explanation. When even one of these answers is unclear, the data is not yet ready, and the AI will show it.

Data ≠ useful information

Here is the confusion that costs the most. Many executives think they own "data" and are therefore ready for AI. What they actually own is files, spreadsheets, emails, folders. Raw data is not yet useful information: between the two lies all the work of preparation. Confusing the two means promising a result on a foundation that cannot support it.

No clean data, no useful AI. The tool never makes up for defective raw material.

When data is missing, AI does not stay silent: it fills the gap. A consulting firm delivered a report to an Australian government agency, priced at AU$290,000, that contained citations and references invented by generative AI, which led to a partial refund. The model did not have the right sources on hand; it produced information that was plausible and false. That is exactly what comes from data that is missing or poorly documented: apparent confidence, with no substance behind it.

Speed is deceptive too. In trials run by an international law firm across 411 participants in 23 offices and 14 countries, first drafts written by AI came out markedly faster — up to 80% time saved on certain documents. But their average accuracy remained lower than a human's: 3 out of 5, compared with 3.5 out of 5. Moving fast on a fragile foundation means producing quickly something that will need to be redone.

The overlooked cost line

When it comes to pricing out an AI project, attention goes to the tool: which license, which model, which vendor. That is the most visible line item, rarely the heaviest one. The real cost and the real timeline play out upstream, in data preparation: making data available, correcting errors, structuring it, documenting it. In most projects, this work exceeds that of the tool itself — often the heaviest line in both the budget and the schedule (YPrtnrs Institute estimate).

Return-on-investment figures confirm this indirectly. A study of more than 4,000 executives found an average return of $3.70 for every dollar invested in generative AI, and up to $10.30 for the most advanced organizations. But these gains arrive after a delay: average deployment in under eight months, value realized at thirteen months. That delay is, in large part, the time it takes to get the data into shape.

This gap explains a paradox. AI is adopted everywhere, yet few organizations gain real value from it. According to a global barometer, 88% of organizations use AI in at least one function, but only about one in three has moved past the pilot stage, and few report a net effect on their bottom line. Between a successful trial and a profitable deployment stands the data wall.

By contrast, organizations that invested early in their data reap the benefits for the long haul. At one tire manufacturer, the return from data and AI projects exceeds €50 million a year, built on more than 200 use cases in production. This result does not come from a miracle tool, but from years spent making production data available and reliable.

Recognizing ready data

How can one tell, before starting, whether an organization has data that is ready? A few signs do not lie. They have less to do with technology than with habits of organization and rigor established over the long term.

The first good sign is often the existence of a single place where data has been consolidated. Several major hospitals have built a health data warehouse, a centralized platform that consolidates data from different departments ahead of any analytical use. This foundation is not yet AI: it is what makes AI possible afterward.

The second sign is a well-defined and well-described dataset. When a consulting firm built its internal assistant, it did not connect it to the entirety of its files: it grounded it in more than 40 curated knowledge sources and more than 100,000 selected documents. As a result, 72% of teams use it every month. The quality of the scope produced the quality of the tool.

The third sign is the ability to make good use of data that is already well kept. At one pharmaceutical company, drafting clinical study reports went from fifteen weeks to ten minutes: a dramatic gain, but one that was only possible because the underlying clinical data was already structured and standardized. AI did not replace data discipline; it reaped its rewards.

Preparing the data

Preparing data is not an IT project reserved for specialists. It is first and foremost an executive decision: choose a narrow scope, bring it to a good standard, then expand. A small, impeccable dataset beats a vast, approximate warehouse.

1. Choose a useful use case. A precise, measurable need with a clear payoff. The use case determines which data to prepare, and nothing more.
2. Map the data that is needed. List what the use case requires, where it is, who is accountable for it, and what condition it is in.
3. Make it available and reliable. Extract it, correct errors, remove duplicates and gaps. This is the longest part of the job: plan for it as such.
4. Structure and document it. Organize it in a readable format, name and define each field, record its origin and dates.
5. Test, then expand. Verify the result on this scope, put it into service, then reuse the foundation for the next use case.

Over time, an AI project rarely looks like what people imagine. Choosing the tool and setting it up is only part of the timeline. Most of it happens beforehand, in data preparation.