Is Your Data Ready for AI? Start With the Decision It Must Support

A company's customer records can be both sufficient and insufficient.

That is not a contradiction. The same records may be enough for a weekly sales report and insufficient for a real-time credit decision.

The first task uses past sales to show a trend. The second needs identity, current income and debt information, the organisation's risk rules, limits that apply at that moment, and records that can later show whether the decision was sound.

Data sufficiency depends less on the data itself than on the decision it is expected to support.

That is why “Is our data ready for AI?” is too broad on its own. First define the work step you want to change, the decision you expect to improve, and the consequence of getting it wrong.

Data readiness is not a company-wide status

It is tempting to label a company's data as ready or not ready. The label does not tell you what to do next.

Historical sales data may help explain a monthly demand trend. The same data may not be enough to predict which customers are most likely to buy next month. That prediction may also need customer interactions, the state of the sales pipeline, lost opportunities, and an outcome record that shows whether the prediction was accurate.

The distinction is not limited to predictive systems. A maintenance manual may answer a technical question but say nothing about current inventory. A product catalogue may be enough to prepare a proposal but not to quote a binding price to a customer.

The aim is not perfect data. It is having enough information for a specific decision, the level of error the business can tolerate, and the outcome at stake.

Start by naming the decision that will change

Before starting a data initiative or an AI project, clarify four questions:

1. Which decision or work step will change? Producing a report, prioritising customers, preparing a proposal, and making a credit decision are different data problems.
2. When must the information be valid? Yesterday's price, stock level, or limit may be wrong today.
3. What happens when the information is missing or wrong? Will the system prepare a draft, make a recommendation, or initiate an action with real consequences?
4. How will we know the result is good enough? A few impressive demos are not enough. You need representative cases and records that show whether the decision was sound or the work was completed.

These answers matter more than asking whether data exists. They reveal which gaps actually change the design.

Consider a sales team deciding which customers to contact first. Historical sales amounts may be enough to create an initial ranking. But if a sales representative will allocate time based on that ranking, they also need to know whether the customer is still active, whether the recorded contact is the right person, and when the last interaction took place. Without that context, the system may prioritise customers who mattered in the past but have since lost interest. What is missing is not model capability. It is the context the decision requires.

Data means more than rows used for training

The information that supports an operational decision rarely comes from one table. It usually combines several kinds of input:

• Current state: a price, stock level, balance, order, approval, or customer record.
• An explicit rule: a spending limit, eligibility condition, discount policy, or definition of an active customer.
• Historical examples: observations and feedback that can support prediction or classification.
• An outcome record: evidence that shows whether a recommendation was right, work was completed, or the business result changed.

These sources do not need to live in one system. What matters is that each source has a clear meaning, a known owner, and can be accessed when the decision requires it.

A proposal system, for example, may extract technical specifications from a product document. A customer-specific price must come from the authorised commercial system. A discount exception may sit in a written policy. If the system cannot distinguish among those sources, having more data will not solve the problem.

This is why the distinction between written knowledge, explicit rules, and patterns that must be learned is a business-design question before it becomes a technical one.

Missing data does not always justify a large data programme

Two reflexes are common when information is missing: assume that the model will know the answer, or begin cleaning and centralising all company data.

Both can be premature.

Sometimes the right move is to narrow the scope. An invoice-entry system might initially accept only machine-readable PDFs from selected suppliers. Scanned or irregular invoices can remain in the current process.

Sometimes the missing ingredient is not more data. Clarifying what a record means, assigning an owner to a source, or improving the process for keeping it current may create more value.

Sometimes the cost of preparing the information does not justify the expected outcome. Process change, better use of existing software, or leaving the work unautomated may be the better intervention.

Data preparation is not a checklist to complete. Which information is missing? Which decision does that gap undermine? Who owns the fix, and what will it cost? Without answers, you have not made a decision. You have started an open-ended preparation programme.

Sufficient information does not grant decision authority

Access to accurate information does not mean that a system should make decisions on the company's behalf.

A procurement system may compare bids while supplier selection, budget approval, and purchase-order creation remain with people. Information sufficiency describes the inputs a system needs to work reliably. Authorisation determines what it is permitted to do.

Those are separate decisions. How much authority AI should have requires its own design.

Model selection becomes useful only after both questions have been answered. First define the business result you want to change and the information needed to support it. Then compare AI, conventional software, process change, or another intervention for the simplest fit. That is why I have argued that an AI project should not start with model selection.

Company data is not simply ready or not ready for AI. A more useful question is:

What do we need to know for this decision, and is our information good enough for the consequences if we get it wrong?

You can find the wider set of decisions about models, information, authority, and evidence in the guide to designing AI systems for your business.