The Data Readiness Problem in Enterprise AI

Enterprise AI programmes rarely stall because a team cannot call a model. They stall because the organisation cannot establish what its data means, whether it is current, which record is authoritative, who may act on an output, or how a result will be measured. We use a six-part readiness framework to resolve those questions before model selection: provenance, freshness, duplicates, baselines, action rights and outcome measurement.

The model is usually not the first constraint

The visible part of an AI system is the model. The operational part is everything around it: source systems, identifiers, business definitions, permissions, review queues, write paths and feedback. A capable model placed on unreliable operational data produces fluent uncertainty. A modest model placed inside a well-defined decision system can create dependable value.

This distinction matters at executive level because model procurement is easy to budget and announce. Data readiness is distributed across functions. Operations owns process reality, technology owns systems, finance owns important definitions, legal and security constrain usage, and business teams control many of the actions that create outcomes. No single team can declare the data ready on its own.

The evidence supports treating this as an operating problem. RAND's research on AI project failure, based on interviews with experienced practitioners, identifies unsuitable data, weak infrastructure and misalignment with the business problem among the recurring failure patterns. It also notes that datasets collected for reporting or compliance may not preserve the context required for a new analytical purpose. The Stanford AI Index 2026 economy chapter documents rapid enterprise adoption and investment, but adoption is not the same as measurable operational return. Together, these findings point to a practical conclusion: readiness must be tested against a decision and workflow, not inferred from data volume or executive enthusiasm.

Start with a decision contract

Before inspecting tables, we write a short decision contract. It names the recurring decision, the actor responsible for it, the allowed actions, the time available, the evidence required and the business outcome to observe. “Use AI for product data” is not a contract. “Recommend missing attribute values to a catalog steward before the weekly publication cutoff, without overwriting approved records” is.

The contract prevents a familiar failure: a team optimises an offline metric that has no reliable route into operations. It also reveals whether AI is necessary. Some decisions are deterministic lookups, threshold checks or reconciliations. They should remain rules. AI earns a place when the input is ambiguous, unstructured or variable enough that rules alone become brittle.

We then assess readiness across six gates. A gate is not a maturity slogan. It has evidence, an owner and a pass condition.

Gate 1: Provenance

Provenance answers: where did this field come from, under which definition, through which transformations and under whose authority?

For every input used by the system, we want a trace from the presented value back to its source. That includes source system, extraction time, record key, transformation version and any human correction. If two reports show different revenue, inventory or status values, the problem is not solved by choosing the larger table. The definitions and transformation paths must be reconciled.

Builders should make lineage queryable. A prediction or generated recommendation should retain references to the source records and version of the processing logic that produced it. Executives do not need to inspect every lineage event, but they do need an accountable owner for each critical data domain and a documented escalation path when definitions conflict.

The extraction boundary matters as much as the warehouse. A repeatable operational data-extraction workflow records what was requested, what arrived and what failed, so absence is not mistaken for a zero.

A useful pass condition is simple: a reviewer can select a material output and reconstruct its origin without asking the original developer. If that requires tribal knowledge, the gate is not passed.

Gate 2: Freshness

Freshness is not a universal timestamp target. It is the maximum age at which data remains fit for a specific decision. A monthly classification may tolerate days. An availability decision may not tolerate hours. The decision contract determines the service level.

We define freshness at three points: when the event occurred, when the source recorded it and when the AI workflow consumed it. These timestamps expose delayed integrations and late-arriving updates. We also distinguish “pipeline succeeded” from “data is current.” A job can complete successfully while copying yesterday's unchanged snapshot.

The production control is a freshness budget with explicit behaviour when exceeded. The system may warn, abstain, fall back to a deterministic value or block a write. Silent operation on stale data is not acceptable. A dependable data warehouse and ingestion layer is therefore part of the decision product, not preliminary plumbing.

Gate 3: Duplicates and identity

Duplicates are often identity failures disguised as cleaning tasks. The same supplier, product, order or location can appear under different identifiers; conversely, an identifier may be reused across regions or systems. A model cannot repair an undefined entity model.

We first state the business identity rule: what makes two records the same entity, and under what scope? We then preserve both raw identifiers and a canonical identifier, with the match method and confidence. Deterministic keys should take precedence. Probabilistic entity resolution may propose matches, but uncertain merges belong in a review queue because a false merge can contaminate every downstream feature and outcome.

Readiness requires measured duplicate rates by source and segment, not a single global percentage. It also requires reversible merge decisions, survivorship rules for conflicting fields and monitoring for new collision patterns. If the team cannot explain which record wins and why, it is not ready to automate a decision based on that entity.

This is one reason complete operational data ownership matters: retaining raw history and stable identifiers makes later reconciliation and replay possible even when upstream interfaces change.

Gate 4: Baselines

Without a baseline, an AI result becomes a demo rather than an intervention. We document current performance before changing the workflow: error rate, cycle time, review effort, coverage, exception volume and the business outcome the decision is intended to influence.

Where confidentiality matters, we publish internal evidence as a normalised index. The pre-intervention state is Baseline = 100. Subsequent periods show relative movement against that reference, while the underlying absolute values remain inside the authorised measurement environment. The same denominator, population and time window must be maintained; otherwise an index creates false comparability.

Baseline design also needs segmentation. An overall improvement can hide deterioration in a high-risk market, product class or customer group. We predefine the slices that matter and record concurrent changes such as promotions, policy updates or staffing shifts. This does not create perfect causal inference, but it prevents the most obvious attribution errors.

The pass condition is that the baseline can be reproduced from versioned data and definitions. A screenshot from a dashboard is not enough.

Gate 5: Action rights

Data access does not imply permission to act. An application may be allowed to read an order but not cancel it, inspect a product record but not publish it, or calculate a recommendation but not change a price. We map authority at the level of each action.

The map includes the system of record, permitted actor, approval requirement, value or risk limits, segregation of duties and rollback path. The initial mode should usually be read-only or recommendation. A dry run can then compare proposed actions with human decisions. Approved writes follow only when identity, validation, logging and recovery controls are proven.

This gate connects governance to software design. Credentials should expose the minimum scope; tools should separate reads from writes; high-impact actions should require an explicit approval token; every mutation should be idempotent where possible and carry a correlation ID. “Human in the loop” is too vague unless we know which human, at which point, with what information and response time.

Gate 6: Outcome measurement

Model quality is necessary but insufficient. Precision, recall or task-success scores describe behaviour on an evaluation set. The operating question is whether the system changed a decision and whether that change improved the intended outcome without unacceptable side effects.

We instrument the chain from input to recommendation, review, action and outcome. Each stage needs a stable identifier so that an eventual result can be joined back to the version of the model, rules and source data involved. We record abstentions and rejected recommendations, not only accepted outputs. Otherwise the feedback set becomes biased toward easy cases.

The measurement plan defines a primary outcome, guardrail metrics and a review cadence. Guardrails may include error severity, override rate, complaints, policy breaches, latency or workload transferred to another team. A system that reduces one queue by creating a larger hidden queue has not improved operations.

A practical readiness scorecard

We use the framework as a decision record, not a decorative score. Each gate receives one of four states:

State	Meaning	Release consequence
Unknown	Evidence has not been collected	No pilot with operational claims
Defined	Owner, definition and test exist	Offline evaluation only
Verified	Test passed on representative data	Controlled workflow pilot
Monitored	Production threshold and response exist	Eligible for bounded scaling

Averages are misleading. Five monitored gates do not compensate for unknown action rights. The release level is constrained by the weakest gate that can cause material harm or invalidate measurement.

For builders, the scorecard becomes an acceptance-test backlog: lineage queries, freshness assertions, uniqueness tests, baseline jobs, permission checks and outcome joins. For executives, it becomes a portfolio filter. It shows which initiatives need data work, which can proceed to a controlled pilot and which should stop because the decision itself is poorly specified.

Sequence investment before selecting a model

Once the gates are visible, investment becomes more rational. We can fix an identifier problem before buying more inference capacity. We can add event context before commissioning a prediction. We can negotiate action rights before building an agent that has nowhere to act. We can establish the baseline before a process change destroys the comparison period.

Only then do model choices become meaningful. The evaluation set should be drawn from the verified operational population, including known exceptions. Candidate models can be compared on task success, calibration, latency, privacy constraints and cost. A stronger model cannot compensate for an unobservable outcome or an unauthorised write path.

This is also how pilots become production systems. Readiness is not a one-time data-cleaning phase. Sources drift, identifiers change, permissions expire and business definitions evolve. Each gate therefore needs an owner, automated checks where possible and a documented response when thresholds fail.

The executive question to ask

The most useful question in an enterprise AI review is not “Which model are we using?” It is: “Show us the chain from source evidence to authorised action to measured outcome.”

If the team can show that chain—and reproduce it—the programme has a foundation for learning. If it cannot, more model capability will usually increase the speed and confidence of an unverified process. Data readiness is not a prerequisite to finish before the interesting AI work begins. It is the core design of the operating system in which AI can be trusted.