Is your business data ready for AI?

An AI data readiness checklist should begin with real work. Take the last 50 cases from the process you want to improve. Count what is missing, what conflicts and what only an experienced employee can understand.

That sample will tell you more about the likely first phase than a company-wide declaration that your data is “mostly clean”.

Data readiness for AI belongs to a workflow

A business can have suitable data for one AI project and poor data for another.

An accounts-payable process may have structured invoices, consistent supplier records and a clear approval history. The sales team may keep customer commitments across email, personal notes and an inconsistently updated CRM. A company-level readiness score hides that difference.

Start by writing one sentence:

We want the system to use [named sources] to produce [specific output] for [named reviewer or action].

For example: “Use purchase orders, delivery records and incoming invoices to prepare a matched invoice record for an accounts assistant to review.”

The sentence shows which records matter, what the system should produce and who will check it. If the proposed job takes a page to explain, make it smaller before reviewing the data.

The AI data readiness checklist

Use 50 recent cases where possible. A sample that only contains successful or neatly completed records will make the assessment look better and teach you less.

Can the system access the source?

List every place an employee opens while doing the work. Include spreadsheets, shared drives, inboxes and messages to colleagues. Record who owns each source, how it can be accessed and whether access is appropriate for the proposed use.

Digital information can still be difficult to use. The system may read a PDF attached to an email, while an approval buried in a private message is hard to find and easy to lose.

Does each field have an agreed meaning?

Definitions cause more trouble than file formats. “Active customer”, “qualified lead” and “delivery date” can each mean different things across teams.

Take the important fields in your 50 cases and ask two people to explain them. Disagreement is useful evidence. Settle the definition, document it and decide which system owns it.

This work can expose a process problem. If sales treats a signed proposal as a committed order while operations waits for a deposit, no model can reconcile the two definitions without a business decision.

Are the records complete enough for the job?

Mark required inputs as present, missing or found somewhere else. Pay attention to information employees retrieve from memory. A worker may know that a certain supplier uses two invoice formats or that one customer always places orders through a parent company.

That knowledge needs a home. It may become a reference table, a process rule or an exception that requires review.

How often is the data wrong?

Count observable defects: duplicates, invalid dates, mismatched identifiers, stale contact details and totals that do not reconcile. Keep each defect type separate because the repairs differ.

Do not reduce everything to one accuracy score. Some errors barely affect the proposed job. A missing marketing preference matters little to invoice matching, while a wrong bank account matters a great deal.

May the system use this information?

Access inside the company does not automatically make every use appropriate. Record personal data, confidential material, contractual limits and retention requirements. Decide which fields the system needs, then remove or mask the rest.

The NIST AI Risk Management Framework recommends recording where outside data and software come from, what the system is meant to do, who checks it and how it will be tested. An SME can keep this as a short working record for the chosen process.

Can you detect a bad result?

Data readiness includes the answer key. If the system classifies enquiries, you need examples of correct routing. If it prepares invoice matches, you need completed cases and the final reviewer decision.

Past decisions are not always correct. Review the sample with the person responsible and fix obvious mistakes before using those cases to test the new system.

Decide what must change before the pilot

After the sample, some findings will be mechanical. Formatting errors, duplicate records and missing identifiers can usually be tied to a source and an observable fix. Assign those repairs to a person and agree when the sample will be checked again.

Other findings need a business decision. Conflicting definitions, unclear ownership and unwritten approval rules need an answer from the relevant manager. Record the decision and who made it.

Some gaps will remain. An old document may be unreadable, or a customer may use an unfamiliar format. Define how the system reports uncertainty and who receives the case. This allows a first version to operate on the well-understood portion of the workflow without pretending that every record has been repaired.

Keep the outcome in a short readiness record during the build. It should name the workflow, sources, agreed definitions, known exclusions, reviewed evaluation cases and the owner of each remaining repair. This is working material, so update it when live cases reveal something the initial sample missed.

IMDA's AI for Enterprise Impact Playbook includes data and governance as one of five readiness dimensions, alongside leadership, people, integration and value. The connection matters. Clean records will not rescue a workflow with no owner, and a willing team cannot safely use data it does not understand.

Ready enough has a precise meaning

A workflow is ready enough when the system can access the approved sources, the important terms are defined, common defects have a repair path and reviewers can recognise a poor result. Known gaps have an explicit route back to a person.

Run the sample before discussing platforms. The result may point to an AI build, a conventional data clean-up or a policy decision the business has postponed. All three are useful answers.