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

> Before choosing a model, test whether the information needed for a specific decision is usable, current, authoritative, and worth preparing.

> 💡 **TL;DR: Key Takeaways**
> - **“Is our company's data ready for AI?” is too broad to be useful on its own.** Readiness is not a company-wide grade. It is whether the information and evidence required by a specific decision are sufficient for that decision.
> - **The relevant data is not limited to rows used for model training.** Documents, live transaction records, business rules, examples, permissions, and records that prove the outcome are different inputs to the same decision.
> - **A gap does not automatically justify a large data-platform programme.** The better response may be to narrow the scope, prepare one named source, retain human judgment, run a non-consequential experiment, or stop.

I have argued that an AI project should [start with the business problem rather than the model](/start-with-the-business-problem-not-the-ai-model). First define the outcome that should change, the system's action boundary, and the evidence that would show success. Then test [whether AI is the right intervention at all](/when-process-automation-actually-needs-ai) against the simplest alternative that could deliver the same result.

Even after those decisions, we are not ready to open a model shortlist.

Suppose a procurement team wants to evaluate supplier bids more quickly. The goal may be clear: reduce the time spent comparing bids, avoid contract and budget mistakes, and prepare the purchasing decision with better information.

A model may extract price, delivery time, and warranty terms from the bid documents accurately. The system may still be unable to make a sound recommendation.

Can it read the current approval status of each supplier? Which system holds the available budget and existing commitments? Does “delivery risk” have an agreed definition, or does its meaning live only in the judgment of experienced buyers?

Are past selections useful examples of good decisions, or records of habits that no longer apply? Do representative cases exist to test whether a recommendation is actually good?

A more capable model does not close these gaps. The business problem may be well chosen while the information needed to support the decision remains inadequate.

[Making Your Data Ready for Agentic AI](https://martinfowler.com/articles/making-data-ready-for-agentic-ai.html){.dofollow target="_blank" rel="noopener"}, by Pramod Sadalage and Prem Chandrasekaran on Martin Fowler's site, helped me see this missing step. The authors make an important point: an agent cannot be expected to know the tacit context of an experienced employee or become suspicious of questionable data on its own. They propose mechanisms such as data contracts, quality controls, shared definitions, access boundaries, and monitoring.

Those mechanisms may be necessary. Before choosing them, however, we need to answer a more basic question: what information does the work require for a sound decision, and is that information actually usable today?

That question comes after deciding that AI is an appropriate intervention, but before choosing the data architecture or model.

## The right problem can still lead to the wrong preparation

Data discussions in AI projects often move towards one of two extremes.

One side says, “The model already knows a great deal; we can connect our data later.” The other says, “First we need to clean all company data and bring it into one place.”

Both can be as premature as choosing the model first.

The first assumes that the current, company-specific facts behind a business decision will somehow be available. The second starts a large preparation programme before identifying which decision needs which information.

These problems do not necessarily remain isolated. Sambasivan and colleagues describe this accumulation as [“data cascades”](https://research.google/pubs/everyone-wants-to-do-the-model-work-not-the-data-work-data-cascades-in-high-stakes-ai/){.dofollow target="_blank" rel="noopener"}. Through interviews with 53 practitioners across four continents, they examine how apparently small data problems spread into later model and system decisions.

This qualitative study does not establish a failure rate for all AI projects. It supports a narrower point: information with an unresolved source, meaning, or owner does not correct itself through later technical choices.

Data work is therefore not merely technical preparation that begins after model selection. It is part of the business decision about whether model selection should begin at all.

## “Is our data ready?” is the wrong starting question

A company's data cannot be declared “ready” or “not ready” in isolation.

The same customer records may be adequate for a weekly sales report and inadequate for a real-time credit decision. A maintenance manual may answer a technical question but cannot reveal current stock. Historical sales may support general demand forecasting while misleading a specific planning decision if they do not show how many sales were lost when products were unavailable.

Readiness has meaning only in a particular use context:

- Which decision or work step must it support?
- Who will be affected by the decision?
- At what moment must the information be valid?
- What happens when it is missing or wrong?
- Will the system explain, influence a decision, or execute a transaction?
- Which example or record would show that the result is good enough?

The standard is not perfect data. It is information sufficient for the intended decision and the consequences of getting it wrong.

## Data here means more than training data

“Data preparation” often brings to mind cleaning tables, filling missing fields, and training a model. The information base of an operational system is broader.

One decision may require all of the following:

1. **Written knowledge:** A policy, contract, product document, or technical manual.
2. **Current operational state:** A balance, price, stock level, order, entitlement, or approval record.
3. **Explicit rules and definitions:** A spending limit, eligibility condition, or the agreed meaning of “active customer” or “revenue.”
4. **Examples from which to learn:** Historical observations, labels, and feedback used for prediction, classification, or inference.
5. **Identity and access:** Which user may see which information for which purpose.
6. **Evidence:** Representative cases and authoritative records used to test the model's task, the completed action, and the business result.

These inputs do not all need to be copied into one central data platform. They may have different owners and remain valid for different lengths of time.

An employee's remaining leave balance should be read from the HR system at the time of the request. The carry-over rule may live in an approved policy. An HR specialist may still own the interpretation of an exception. Whether the employee may see only their own record is a separate authorization boundary, not a data-quality issue.

The [distinction between written knowledge, explicit rules, and patterns to be learned](/does-enterprise-ai-really-need-fine-tuning) matters here. First identify the kinds of input the decision requires and whether they are usable. Only then does it make sense to decide whether written knowledge belongs in direct context or search, current state should arrive through an API or query, or a learned relationship needs a statistical method.

## Six questions before model selection

Instead of scoring all of the company's data, answer these questions for one decision or work step:

1. **What exactly must be known for this decision to be made well?** List the document, live field, rule, example, and outcome record separately.
2. **Who owns the meaning and current state of that information?** If the same field means different things to two teams, the immediate problem is definition and ownership, not the model.
3. **How does the decision change when the information is missing, old, or disputed?** Does the system stop, give a narrower answer, or continue without noticing?
4. **Is the information accessible for the required identity and purpose?** The fact that data exists does not mean the system or user is allowed to see it.
5. **Which representative examples or external records would show that the result works?** A few impressive demos do not reveal the real distribution of errors or prove that the work was completed.
6. **Do the cost and time required to prepare the missing piece fit the expected value?** Repairing a source system, assigning ownership to definitions, preparing a test set, and monitoring the result are part of the real project cost.

This is not a scorecard. A restricted price source cannot be offset by high marks for current documents. If no record can prove completion, strong inputs elsewhere do not prove the outcome.

The purpose of these questions is not to define another method. It is to expose a gap early enough to change the design.

Product documentation may be current and clean, for example, while the system cannot read a customer's contracted price from an authorized source. A large sales history may not represent the audience for a new product. Every input to a transaction may be available, while the system has no source that can prove the transaction was completed.

In the [article about when enterprise AI needs RAG](/when-does-enterprise-ai-need-rag), I examine how required information should reach the system. The question here comes first: can that information path be built and tested for this decision? If so, comparing direct context, search, RAG, and live queries becomes useful.

## The answer is not always “prepare the data first”

Finding an information gap and automatically starting a large data programme can be as misguided as rushing into model selection.

The decision may be to:

- **Continue:** The information and evidence are sufficient to compare architectures and mechanisms. This is not approval to deploy.
- **Narrow the scope:** Reduce the document types, user group, product family, consequences of error, or system authority.
- **Prepare one named piece first:** Complete a missing definition, source connection, rule, or test set.
- **Keep the decision with a person:** The system may gather information and prepare a draft, while a named person retains the uncertain or consequential decision.
- **Run an experiment only:** Learn from a limited set of cases without affecting operational decisions.
- **Stop this path:** Abandon the AI intervention when preparation costs exceed the expected value or the required source and authority cannot be established.

“Prepare first” is not a decision by itself. Which document, definition, source connection, or test set will be prepared? Who owns it? When will it be complete? What will prove completion? What happens if the preparation does not work? Without those answers, the company has not made a decision; it has started an open-ended data project.

An invoice-entry system does not require the company to clean and convert its entire invoice archive. The first release can accept machine-readable PDF invoices from a defined set of suppliers while employees continue to process scans and irregular invoices through the existing method. If a new product has too little history, the team can drop the claim of a definitive demand forecast and use scenario planning with explicit assumptions. If the system answers from one approved maintenance page, it can use that source directly without building RAG, a semantic layer, or a data platform.

Complexity earns its place only when it closes a named gap.

## Sufficient information does not grant authority

Access to correct and current information does not give a system authority to make a decision or complete a transaction on behalf of the company.

A procurement system may compare every bid correctly while supplier selection, budget approval, and purchase-order creation remain with different people. An employee's leave balance may be correct; that does not mean the system may approve the leave request.

[How much authority AI should have](/how-much-authority-should-ai-have) is a separate design decision. Information sufficiency tells us which inputs can support reliable work. Authorization determines who may see what and which actions may change the outside world.

Correctly comparing supplier bids in a test set does not by itself show that the system creates business value. First test whether the recommendation is sound. Then verify that the selected supplier or purchase order was actually recorded in the procurement system. Finally, observe whether evaluation time or error rates change over time.

I discuss [how to measure model output, completed work, and the business result separately](/is-your-ai-system-delivering-business-results) in the next part of the series.

## Model selection is delayed twice

Delaying model selection does not make the model unimportant. The right model can change quality, cost, latency, and the kinds of work the system can perform.

The choice becomes useful only after two stages.

First define the business result you want to change and the work step where it appears. Then distinguish the intervention the work actually needs: AI, conventional software, process change, or something else.

Next show that the information and evidence required by that work step are sufficient, accessible, and economically reasonable to prepare.

Only then does it make sense to compare which model or other mechanism can perform the work without adding complexity the job does not require.

It is easy to label all company data “ready” or “not ready.” A more useful question is:

> What must we know for this decision, and is the information available today reliable enough for the consequences involved?

You can find the other decisions about models, information, authority, and evidence in the [guide to designing an AI system for your business](/designing-ai-systems-for-business).

---

Language: English
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/is-your-data-ready-for-ai