AI-Ready Data: What It Actually Takes

When an AI project runs late, the model is rarely the cause. The delay is almost always in the data: nobody is sure who owns it, access takes weeks to approve, the documents are scattered across shared drives, or the numbers turn out to mean different things in different systems. AI-ready data is the unglamorous precondition for everything else, and most organisations discover its absence after the project is funded.

The usual response is to propose a large data programme and ask the AI work to wait. We think that is the wrong answer. Data becomes AI-ready one use case at a time, against a specific need, and the foundations you build for the first use case should make the second one cheaper. This article describes what that takes.

Why most AI delays are data delays

A proof of concept hides data problems. It runs on an extract that someone cleaned by hand, with permissions waived for the demo and a friendly subject expert on call. Production removes all three comforts.

The problems that surface at that point are rarely technical in origin. They are questions nobody had to answer before. Who is allowed to see this? Which of these two customer records is correct? Is this the current version of the policy? Who fixes it when it is wrong? AI did not create these questions. It made them urgent, because a model will use whatever it is given, confidently.

What AI-ready data means for a specific use case

"Is our data ready for AI?" has no useful answer. "Is this data ready for this use?" does. Three things decide it.

Ownership

Every data source feeding an AI system needs a named owner in the business who can make decisions about it: what it means, who may use it, and what gets fixed first. Without an owner, every data question becomes an escalation. This does not require a large governance office. It requires a name against each source that matters.

Quality for the purpose

Data quality is not an absolute. A forecasting model may tolerate gaps in customer addresses and be ruined by inconsistent product codes. A support assistant may not care about either, and depend entirely on whether the knowledge articles are current. Define quality by asking what would make this use case produce a wrong or harmful result, then test for those conditions specifically. That produces a short, fixable list.

Access and permissions

This is the most underestimated item. An AI assistant connected to company content will surface anything its permissions allow, including the files that were always technically open but that nobody ever found. Before connecting a source, check that access controls reflect who should see what, and make sure the AI system enforces the permissions of the person asking, not a broad service account. Overshared folders, stale groups and inherited rights need attention first.

Unstructured content for retrieval

Much of the near-term value in AI comes from documents: policies, contracts, manuals, proposals, tickets, emails. Retrieval-augmented generation, the pattern behind most enterprise assistants, answers questions by finding relevant passages and giving them to a model. The quality of the answer is bounded by the quality of what can be found. Our article on grounded enterprise AI search with RAG explains the pattern. The data work behind it is specific.

• Curate before you index. Decide which repositories are authoritative. Exclude drafts, duplicates and superseded versions, or the assistant will quote them.
• Make currency visible. Each document needs an owner, a date and a status, so that outdated content can be retired and the system can prefer the latest version.
• Respect structure. Tables, scanned pages, headers and appendices often break when documents are split into passages. Test extraction on your real files, not on clean samples.
• Build a test set. Collect real questions from real users with the answers the experts would accept. This is the only reliable way to know whether retrieval is working.
• Assign content owners. Someone must be responsible for correcting the source when the assistant exposes an error. The fix belongs in the document, not in the prompt.

A model will use whatever it is given, confidently. The discipline is in deciding what it is given.

Metadata, lineage and privacy

Three further foundations matter more with AI than they did with reporting.

Metadata tells people and systems what data is: its meaning, owner, sensitivity, freshness and permitted uses. A modest catalogue covering the sources your priority use cases depend on is far more valuable than an ambitious one that is never finished.

Lineage records where data came from and what happened to it on the way. When an AI output is challenged by a customer, an auditor or a regulator, you need to show which data informed it.

Privacy has to be designed in. Under GDPR, personal data needs a lawful basis and a defined purpose, and using it for a new AI purpose is a decision to be assessed, not assumed. Minimise what goes into prompts and training sets, mask or remove personal data where the use case does not need it, know where your suppliers process and retain it, and carry out impact assessments where the risk warrants. Confirm the specifics with your data protection officer and counsel.

A use-case-first approach: where to start

A multi-year data programme that must finish before AI begins will lose its sponsor long before it delivers. The alternative is to let priority use cases pull the data work, while insisting that each piece of work is built to be reused. This is the principle behind a modern data strategy, and it fits the argument in our piece on building a data strategy that works.

• Pick two or three use cases with real owners. Choose ones that matter to the business and that touch different data, so you learn broadly.
• Trace the data each one needs. List the sources, the owners, the access route and the known problems.
• Assess readiness against the use. Score each source on ownership, fitness for purpose, permissions, freshness and privacy. Fix only what blocks the use case.
• Build reusable pieces. Pipelines, a catalogue entry, access patterns and quality checks should serve the next use case too. Name and document them.
• Fix permissions early. Start the access clean-up at once, because it takes longest and depends on people outside the project.
• Keep a foundations backlog. Record the wider problems you find, such as master data and duplicate systems, and fund them on the evidence from real use cases.

After three or four use cases, the shared foundations worth investing in become obvious, and the case for them rests on delivered value.

Common questions

What does AI-ready data mean?

It means the data for a specific AI use case has a named owner, is good enough for that purpose, can be reached through properly controlled access, is described by usable metadata, and can be used lawfully. It is a judgement about a use, not a badge for the whole organisation.

Do we need to fix all our data before starting with AI?

No. Waiting for a complete data overhaul is a common and costly mistake. Start with a small number of valuable use cases, fix the data they depend on, and build those fixes so they can be reused. Wider foundations should then be funded on the evidence those projects produce.

How do we prepare documents and unstructured data for RAG?

Decide which repositories are authoritative, remove duplicates and outdated versions, and make sure each document has an owner, a date and a status. Check that permissions are correct and that the assistant will enforce them per user. Then test retrieval with real questions and expert-approved answers before launch.

Where Ganexa can help

Ganexa helps organisations find out quickly what stands between their data and their priority AI use cases, then fix it in the right order. Our AI data readiness service assesses sources against specific use cases, and our RAG and enterprise search work covers the content, permissions and evaluation behind trustworthy assistants. If you would like a clear view of your own position, book a free consultation.