Skip to content
Guide · Lead & measure

Data readiness for AI: the checklist that decides the project before the model does

Retrieval systems answer from your documents and predictive models learn from your records. If the data is not ready, no model choice can rescue the project. This guide shows what ready means and how to get there in weeks.

Updated 6 Nov 2026 · 9 min read · By Teksmobile AI practice

Why data decides the project

Ask an engineer who has shipped a few LLM systems where the time went and the answer is rarely "the model". It went into getting access to the documents, discovering that half of them were scanned images, finding three versions of the same policy, and negotiating what could be used with whom. The model work was a fortnight; the data work was a quarter.

This is structural. A RAG system can only answer from what was indexed, so every defect in the source is a defect in the answers. A predictive model can only learn from the history it is given, so every gap and bias in the records becomes a gap and bias in the predictions. Model choice moves quality by small amounts; data readiness moves it by large ones.

The good news is that readiness is assessable in days and fixable in weeks, for one source at a time. You do not need a data platform. You need the checklist below, applied to the one source the first project depends on.

The five-part checklist

Data readiness checklist in five groups, each with three checks: access (reachable, owner says yes, permissions known), quality (text extractable, duplicates removed, errors understood), structure (document boundaries, metadata present, common keys), governance (personal data mapped, retention agreed, lawful basis), freshness (update path, deletions propagate, version of record) Access Reachable by API or export Owner has said yes Permissions known Quality Text is extractable Duplicates removed Error rate understood Structure Clear document boundaries Metadata present Common keys across systems Governance Personal data mapped Retention agreed Lawful basis for the use Freshness Update path exists Deletions propagate One version of record
Fifteen checks in five groups. Apply them to the one source the first project depends on, not to the whole estate.

The five groups in detail

Access

Can an engineer get the data this week, through a route that will still work in production? An export someone emails you is fine for a readiness check and useless for a live system. The owner's agreement matters as much as the technical path; a source whose owner is reluctant will be withdrawn at the worst moment. Know the permission model too: if different users may see different documents, retrieval must respect that, and you need to know the rules now.

Quality

Open a random sample of fifty documents or records and look. Is the text actually text, or an image of text? Are tables tables, or rows of words? How many near-duplicates and superseded versions are there? For records, what is the error rate on the fields you care about, and is it random or systematic? Ten minutes of looking beats a week of assuming. Our document Q&A work always begins with this sample.

Structure

Retrieval works on chunks, so documents need boundaries and internal structure that chunking can follow: headings, sections, titles. Metadata such as owner, date, product and audience is what makes filtering possible later. For records across systems, a common key (customer id, order number) decides whether the data can be joined at all.

Governance

Know where the personal data is, which fields are sensitive, how long you may keep derived data such as embeddings, and on what basis the new use is lawful. This is not a reason to stop; it is a reason to design the pipeline with masking and retention from the start. Our AI data privacy page sets out the questions.

Freshness

A knowledge base that was accurate on launch day decays from then on. There must be a path for updates to reach the index, for deletions to propagate, and for one version to be the version of record. If the source changes weekly and the index is rebuilt quarterly, the assistant will be confidently out of date.

Common traps

What stalls projects at the data stage

Scanned PDFs. Thousands of documents with no text layer. OCR is solvable, but it must be budgeted and its output checked.

Three versions of everything. The 2021 policy, the 2023 draft and the current one, all indexed. The assistant quotes whichever ranks higher.

No owner. A shared drive nobody is responsible for cannot be governed, cleaned or kept fresh.

Personal data discovered late. HR records in the "general" folder, found after embedding. Map it first.

Access via a person. The only route to the data is asking Sam. Sam goes on leave.

Perfectionism. Waiting for a clean, complete corpus. Start with the subset that passes the checklist.

Scoring a source

Score each group from 0 to 3 for the specific source and use. The lowest group score, not the total, tells you what to fix first.

Group0 — blocked1 — manual2 — workable3 — production-ready
AccessNo route; owner unknownOne-off export via a personAPI or scheduled export; owner agreedAutomated, permission-aware, monitored
QualityMostly images or garbageExtractable with heavy clean-upClean text; duplicates manageableValidated, deduplicated, error rate known
StructureNo boundaries or metadataSome structure; no metadataHeadings and basic metadataRich metadata; keys join across systems
GovernancePersonal data unknownKnown but unmappedMapped; basis agreed for this useMasking, retention and audit in place
FreshnessNo update pathManual re-exportScheduled refresh; deletions manualEvent-driven updates and deletions

A score of 2 in every group is enough for a pilot. Production needs 3 on access and governance at least. If any group is 0, the readiness sprint comes before the project, not alongside it.

A four-week data readiness sprint

  1. Week 1

    Find and sample

    Identify the source, secure the owner's agreement, pull a representative sample and score it against the five groups with the people who know it.

  2. Week 2

    Open the route

    Establish the production access path: API, scheduled export or connector. Map personal data and agree masking and retention rules.

  3. Week 3

    Clean and structure

    Extract text, run OCR where needed, deduplicate, resolve versions, attach metadata. Build the pipeline so it can run again, not as a one-off script.

  4. Week 4

    Prove it

    Index a subset, run fifty real questions through retrieval, and measure whether the right passages come back. Agree the refresh schedule. Re-score.

By the end, the source is at 2 or better across the board, the pipeline is repeatable, and you have the first evaluation cases for the project itself. If you are moving an existing knowledge base rather than starting from source systems, the knowledge base migration service follows the same four weeks. For larger estates, AI data engineering turns the sprint into a programme.

Beyond the first source

Resist the urge to make every source ready at once. The second project will need a second source, and by then you will have a repeatable pipeline and a team that knows the checklist. Readiness compounds. The broader organisational picture, of which data is one dimension, is covered in the AI readiness guide.

Key takeaways

  • Data readiness moves quality more than model choice; assess it before choosing a model.
  • Check one source at a time against five groups: access, quality, structure, governance, freshness.
  • Look at a real sample of fifty documents or records before believing any description of the data.
  • The lowest group score sets the plan; a 0 means the sprint comes first.
  • Map personal data before embedding anything.
  • Design the update and deletion path from the start; knowledge bases decay.
  • A four-week sprint gets one source to pilot grade and produces the first evaluation cases.
FAQ

Frequently asked questions

Do we need a data warehouse or data platform before starting with AI?

No. You need one well-understood source for the first project, accessible through an export or an API, with an owner who agrees to its use. Platforms are built from the second and third project's needs, not before the first.

Our documents are mostly scanned PDFs. Is that a blocker?

It is a cost, not a blocker. Scanned documents need OCR and quality checks before they can be chunked and embedded, and tables and forms need special handling. Budget for it in the readiness sprint and test retrieval quality on the output before committing. See document processing.

How much data do we need?

Less than people assume for retrieval-based systems, which answer from documents rather than learning from examples. A few hundred well-maintained documents can power a useful assistant. For predictive models, the question is history and labels, and the answer depends on the task. Quality and ownership matter more than volume in both cases.

Who should own data readiness?

The team that owns the source system and the business process, with engineering support. Data readiness owned solely by IT produces clean data nobody has agreed to use.

Ready to make AI work in production?

Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.