Is Your Business Data Ready for AI? A Founder's Guide to Preparing Data Before an AI Project

Overview

AI does not need all your data. It needs the right data, described clearly, checked for the job in hand, and handled within rules you can explain. Settling that first is the practical meaning of data readiness.

Key Points

• Start from the decision the AI must support, then work backwards to the records that decision needs.
• AI-ready data is understandable: named, defined, owned, and traceable to its source.
• If you train or fine-tune a model, clean for the job in hand, check for leakage and under-represented groups, and keep a held-out set for honest testing.
• Documents used for retrieval need their own preparation: version and effective-date information, a named authoritative source, and access rules enforced for each user.
• Readiness is ongoing: ownership, freshness checks, and re-checks after every meaningful change.

The short answer

Data is ready for AI when four questions have clear answers. Can the system find the records it needs? Can it understand what each field and document means? Can you trust the records to represent the cases the AI will meet? And are you allowed to use those records for this purpose? Volume alone answers none of these.

This guide covers the checks a founder can lead. Microsoft Digital describes readiness as an ongoing business capability, not a one-time cleanup; the framing works at a smaller scale too.

Start with the decision, not the dataset

Write the decision in one sentence before gathering anything: route each support request to the right team and priority, or draft a first answer from your help documents. Then name the outcome to judge: category, priority, or answer given. Google Cloud makes the same point: the problem first, because it informs what data you need, as set out in the Google Cloud AutoML beginner's guide.

Also decide how answers will be checked, and what role a person plays; if nobody can say how an answer will be judged, data work cannot be scoped. iCodeLTD's AI Solutions service covers use-case discovery and workflow design.

Take stock of what you actually have

List the sources that could feed the decision, where each one lives, who owns it, and how fresh it is. Work through your systems one by one — CRM, inbox, spreadsheets, helpdesk, accounting tool, shared drives — and note each source the decision could draw on. Note whether each source holds structured records (rows with named fields) or unstructured material (free-text notes); they need different preparation.

For each source, ask whether it has a named owner, whether records trace to their origin, and when it was last updated. Microsoft Digital's readiness characteristics cover the same ground. A short written inventory with an owner per source is a genuine start, as described in Microsoft's AI-ready data characteristics.

Make the data understandable to a machine

People fill gaps with context machines do not have: a human knows an internal code refers to a product line, or that a status changed meaning last year. An AI system can take internal shorthand literally: without explicit business context, it may misinterpret your terminology even when the records are accurate. Microsoft Digital reports an example: an internal system name was read literally, not as a system name.

For each field, write a short definition: what it means, what values it can take, and what it does not mean. Record units and any change in meaning over time. Do the same for documents. Record version and effective-date information too, so the current authoritative version and the one that applied earlier are both clear.

Clean for the job, not for perfection

Cleaning means making records consistent enough for the decision in hand, not perfect. Start with checks that change answers: missing values, duplicates, inconsistent formats, impossible values. Correct what you can from a reliable source, and record what you could not.

Amazon's guidance groups this work into cleaning, partitioning, scaling, balancing and unbiasing, and augmentation. Its cleaning step covers duplicates, outliers, and missing data, with imputation chosen to minimise bias. Treat duplicates and outliers as checks, not automatic deletions: each may be an error, or a legitimate repeat or valid rare case. Every cleaning choice is a judgement; write it down, as set out in the AWS Machine Learning Lens on data preprocessing.

For trained or fine-tuned models: leakage and test sets

Leakage happens when information unavailable at decision time slips into the data a model is trained or tuned on. Hypothetically: predicting whether a ticket will escalate using its resolution time, which is only known afterwards. Such a model can look excellent in testing and fail in real use. Google Cloud's guide warns about both this and training-serving skew, as described in Google Cloud on leakage and training-serving skew.

Hold some records aside, so the final check uses unseen cases. Remove exact duplicates before splitting, so no record appears twice, but keep legitimate repeated observations. Choose the split to match the deployment question: random for stable cases; grouped, keeping one customer's records together; or chronological, testing on a later period. The Google Cloud tabular guide notes a default 80/10/10 split; treat it as a convention, not a rule. Fit anything learned in preparation (imputation, scaling, encoding) on the training data only, then apply it to the held-out sets; fitting it on the whole dataset leaks test information.

Check who the data represents

A dataset describes the cases recorded, not the cases it will meet. If one group, channel, or region dominates your records, a system trained on them may perform unevenly for everyone else. For each important group, ask whether it appears in reasonable numbers and at similar quality; rare or single-channel appearance is a warning sign. In testing, check errors separately by group, not just overall.

The US National Institute of Standards and Technology's AI Risk Management Framework (a voluntary framework, January 2023) identifies three bias categories: systemic, computational and statistical, and human-cognitive. Bias, it notes, is broader than demographic balance, and can arise without prejudiced intent, as set out in the NIST AI Risk Management Framework 1.0.

Documents need a different kind of preparation

Many founder AI projects do not train a model at all. They connect a language model to the business's own documents and answer from them. This pattern, often called retrieval-augmented generation, still depends on preparation: documents are split into passages for retrieval. Wrong or outdated passages raise the risk of unsupported, incomplete, or incorrect answers — and the right passages do not guarantee a correct answer either.

Three choices matter most. First, versioning: record version and effective-date metadata, name the authoritative source, and set retrieval rules: current-policy questions draw on the current version; historical questions can reach the version that applied then. Second, structure: passages should respect document boundaries, not mix sections or cut sentences. Unstructured's chunking guide gives around 250 tokens per chunk as a starting point for experimentation, adjusted through evaluation; fixed-character splitting, it warns, ignores structure. Third, context: each passage should carry its title and section.

Check retrieval and answers separately. Write test questions independently of the documents, note the evidence each answer needs, and check whether retrieval returns it; the documents stay in the corpus. Then check each answer follows from the retrieved passages and adds nothing unsupported. Where evidence is insufficient, the system should say so, or pass the question to a person, as your design specifies. Re-run both checks after every document update. Our guide to measuring AI performance after launch covers ongoing checking once a feature is live.

Decide what the AI should not see

More data is not always better. Exclude what is unnecessary for the decision, or what you have no right to use for this purpose — not personal or commercially sensitive material as a whole. List the minimum fields and documents needed; anything beyond needs a reason. Necessary personal or confidential material can be used with a lawful basis, the right permissions, and suitable safeguards. Enforce each document's restrictions for the person asking, before restricted content reaches the model; a prompt telling the model to respect restrictions is not enforcement.

Under the UK GDPR, the Information Commissioner's Office explains, each distinct use of personal data in an AI system needs an identified purpose and lawful basis, decided before processing and documented; development and deployment may need different bases, as set out in the ICO's guidance on lawfulness in AI. Its principles guidance adds that personal information must be adequate, relevant, limited to what is necessary, and kept only as long as needed; see ICO on UK GDPR data protection principles. These are UK rules; other jurisdictions differ. This guide is general information, not legal advice.

A practical sequence for the next month

• Write the decision in one sentence, name the outcome, and agree who checks answers.
• Inventory your sources, name an owner for each, and mark the authoritative source where systems disagree.
• Write plain-language definitions for the fields and documents you plan to use.
• For trained or fine-tuned models, clean what changes answers, check duplicates before removing any, fit preparation on training data only, and split to match deployment.
• Check representation for the groups that matter; review errors by group.
• For document answers, record versions and effective dates, name the authoritative source, set rules for current and historical questions, and test retrieval and answers separately.
• Exclude material you do not need or have no right to use; confirm purpose, lawful basis, and safeguards for necessary personal data; test permission enforcement per user.
• Set a review rhythm: an owner, freshness checks, and re-running test questions after change.

Frequently asked questions

Do we need perfect data before starting?

No. You need data that is understood, checked for the decision in hand, and honest about its limits. Starting narrow is usually more useful than delaying until every record is clean. Do not start a build on data nobody can define, trace, or test.

How much data is enough?

There is no universal number. The amount needed grows with the decision's complexity and how varied real cases are. A practical test: can you hold aside unseen cases, chosen to match how the system will be used, and check results on them? If not, you need more, or narrower, evidence before scaling.

Can we start from spreadsheets?

Yes, if treated like any source: an owner, column definitions, consistent formats, and a record of corrections. Spreadsheets often hide duplicates and mixed formats, so the checks still apply.

What if the data sits with a supplier or partner?

Then preparation includes an agreement, not just a file transfer: permitted uses, refresh frequency, correction ownership, and what happens when the arrangement ends. Test partner data with the same checks as your own.

Sources

Microsoft Digital — AI-ready data: Building the foundation for enterprise AI at Microsoft (company-published internal account; published 15 October 2026; accessed 29 October 2026).

Google Cloud — AutoML beginner's guide (accessed 29 October 2026).

Google Cloud — Prepare training data (accessed 29 October 2026).

Amazon Web Services — Data preprocessing — Machine Learning Lens (accessed 29 October 2026).

National Institute of Standards and Technology — Artificial Intelligence Risk Management Framework (AI RMF 1.0) (January 2023; accessed 29 October 2026).

Unstructured — Chunking Strategies for RAG: Best Practices and Key Methods (vendor guide; published 17 July 2024, updated 2 July 2026; accessed 29 October 2026).

Information Commissioner's Office — How do the data protection principles help us avoid accidental breaches? (UK GDPR principles; accessed 29 October 2026).

Information Commissioner's Office — Guidance on AI and data protection (UK regulator guidance; lawfulness chapter, updated 28 October 2024; accessed 29 October 2026).

If you are scoping an AI project, the project cost calculator gives an indicative cost and timeline range from scope and complexity. For broader planning, see the SaaS development planning guide. To talk through your data and first decision, use the contact page.