When an AI project disappoints, the model is rarely the problem. The usual cause is the data behind it: documents that contradict each other, records that are incomplete, information nobody is allowed to share, or sources nobody owns.
The good news is that data readiness is not a giant platform programme. It is a set of specific checks, done for one use case at a time.
Start with one use case
“Get our data ready for AI” is too broad to act on. “Let our support team get accurate answers about warranty terms” is not. The use case tells you which data matters, how fresh it must be, who may see it, and what “good enough” looks like.
Write down:
- the question or task the AI will handle;
- who will use it;
- what a correct result looks like, with a few real examples;
- which sources a person would use to do the same job today.
That last list is your data scope. Everything else can wait.
1. Find and inventory the sources
List where the relevant information actually lives: shared drives, intranets, wikis, email templates, CRMs, ERPs, ticketing tools, spreadsheets, and people’s heads. For each source note its format, owner, size, how often it changes, and how it can be accessed (API, export, database, manual).
Knowledge that only exists in people’s heads is a gap to close by writing it down, not something AI can invent.
2. Check quality where it matters
You don’t need perfect data, but you need to know where it is wrong. Check the sources in scope for:
- Accuracy: do they reflect current policy, prices and products?
- Completeness: are important fields, sections or records missing?
- Duplicates and conflicts: are there several versions of the same document or record that disagree?
- Freshness: how old is the newest trustworthy version, and how quickly does it go out of date?
For knowledge assistants built on retrieval-augmented generation (RAG), the most valuable step is often deleting or archiving outdated documents so they can never be retrieved.
3. Give it structure and context
AI works better when content carries context.
- Documents: clear titles, headings and sections; effective dates and version numbers; tables kept as tables; scanned PDFs converted to real text.
- Records: consistent identifiers so customers, products and orders can be joined across systems; agreed definitions for key fields (“active customer”, “resolved ticket”).
- Metadata: department, document type, region, product and audience. These let the system filter to the right sources and respect permissions.
4. Decide who may see what
Before any data reaches an AI system, map who is allowed to see it today and make sure the AI respects the same rules.
- Carry permissions through from the source systems, rather than giving the AI one all-powerful account.
- Identify personal and sensitive data. Remove or mask what the use case doesn’t need.
- Check contracts, consent and the data protection rules that apply in your sector and country, including where the data may be processed.
- Decide what may be sent to external AI services and what must stay within your environment.
5. Label examples if you are training models
For predictive and classification models, you need labelled history: past tickets with their correct category, invoices with the right fields extracted, transactions marked as fraud or not. Check that labels are consistent (two people would label the same item the same way), that the data covers the cases you care about, including rare ones, and that it reflects how things work now rather than five years ago.
6. Keep it fresh automatically
A one-off clean-up decays. Build pipelines that pull changes from source systems on a schedule or as they happen, re-index changed documents, and flag sources that have stopped updating. Data that feeds AI should be monitored like any other production system.
7. Give every source an owner
Every source in scope needs a named owner who is responsible for keeping it correct and current, and a simple way for users to report a wrong answer back to that owner. Without ownership, quality falls the moment the project team moves on.
The readiness checklist
| Check | Ready when |
|---|---|
| Use case | One task, its users and examples of correct results are written down |
| Sources | Every source in scope is listed with an owner and access method |
| Quality | Outdated and duplicate content is removed; known gaps are recorded |
| Structure | Documents have clear sections and dates; records share identifiers |
| Access | Permissions carry through; sensitive data is identified and handled |
| Freshness | Updates flow automatically and stale sources are flagged |
| Evaluation | A test set of real questions or cases with known answers exists |
Then build, measure and widen
With one use case ready, build a pilot, test it against your evaluation set, and put it in front of a small group of real users. Their feedback will show which data problems actually matter. Fix those, then take the next use case. Each one makes the next faster, because much of the groundwork (pipelines, permissions, ownership) is shared.