Enterprise AI Has a Data Readiness Problem: The Missing Layer Before AI Deployment

Data availability is not deployment readiness

According to Eurostat, 19.95% of EU enterprises with at least ten employees or self-employed persons used AI technologies in 2025, within the economic sectors covered by its enterprise ICT survey. That measures adoption—not the suitability of the data supporting each application. [1]

Consider a different question: when an AI system answers an operational question, can the organisation establish which information it used, whether that information was current, and whether the user was entitled to receive it?

This article argues that answering those questions requires an explicit data-readiness responsibility between operational systems and AI applications. Model capability remains important. It cannot, however, substitute for information that the application never receives or business definitions that nobody has established.

The importance of data work is not new. Sambasivan and colleagues documented how data problems can compound into downstream failures in high-stakes AI. Their qualitative research involved 53 practitioners across several countries; it should not be interpreted as a failure-rate estimate for European enterprises. Its relevance here is the mechanism: upstream data decisions can shape downstream system behaviour. [2]

When accurate records produce an incomplete answer

Consider a hypothetical operations assistant asked:

“Which production services require attention today?”

Its source systems contain incident records, infrastructure measurements and maintenance schedules. Each dataset may be accurate in isolation. Yet the assistant receives yesterday’s incident export, cannot distinguish production assets from test environments, and retrieves a maintenance procedure that has been superseded.

The resulting answer could be coherent but operationally misleading. The issue is not necessarily an invented fact. It may be a missing relationship, an outdated record or a lost distinction between operational environments.

This example illustrates why readiness must extend beyond successful ingestion. The preparation process should preserve the relationships, timestamps, definitions and applicability conditions needed to interpret the evidence.

It also shows why a successful demonstration is insufficient. A prototype tested against a selected snapshot has not demonstrated how it behaves when records change, sources fail or permissions are withdrawn.

Define readiness for a particular use case

A useful working definition is:

AI-ready data is data that has been assessed and prepared for a specified AI task, with documented meaning, provenance, access conditions, quality expectations and maintenance responsibilities.

This is a proposed operational definition, not a certification.

A dataset might support document discovery while remaining unsuitable for a consequential operational recommendation. NIST’s AI Risk Management Framework similarly emphasises evaluating AI in its intended context and addressing risks throughout its lifecycle. [3]

For enterprise teams, I propose four practical questions.

Dataset documentation offers a useful foundation. The Datasheets for Datasets proposal recommends recording matters such as collection, composition and intended use. Enterprise teams can adapt that approach to maintain an explicit agreement between data producers and AI consumers. [4]

The missing layer is a responsibility—not another database

An AI data-readiness layer should be understood as a coordinated set of controls, not necessarily as a new product or repository. Existing integration platforms, catalogues, databases and access-management services may implement much of it.

Its purpose is to make the transition from source information to AI input explicit:

• what is selected;
• how it is transformed;
• which checks it passes;
• under what conditions it is released for use.

Retrieval-augmented generation illustrates this distinction. The original RAG research combined a generative model with retrieval from an external knowledge index. This provides an architectural route for supplying information beyond a model’s parameters; it is not a guarantee that the retrieved information is complete, current or appropriate for a particular enterprise task. [5]

Nor should readiness be equated with converting everything into embeddings.

Embeddings are numerical representations used in approaches such as semantic retrieval. An exact operational total may instead require a controlled database query; a changing service state may require an authorised API. The representation should follow the task.

For a document-based assistant, preparation might include curation, document generation, segmentation, indexing and retrieval evaluation. For another application, a validated structured dataset may be more appropriate.

The common requirement is an accountable route from source evidence to application input.

Readiness must survive operational change

A useful acceptance test is not simply whether a pipeline can ingest data. It is whether the application remains dependable after that data changes.

For the hypothetical operations assistant, test:

• an updated incident;
• a deleted record;
• a renamed field;
• a superseded procedure;
• a revoked permission.

Define the expected response before running the test.

Where a source becomes unavailable, require the system to expose the limitation or use a controlled fallback rather than silently imply full coverage.

In retrieval systems, the design should address the propagation of changes into derived documents, indexes and caches. Preserving an audit history should not mean continuing to serve obsolete content as current.

NIST’s Generative AI Profile includes recommendations to track dataset modifications and maintain post-deployment monitoring. [6]

Freshness should also be proportionate.

“Current enough” for an incident assistant may differ from “current enough” for a quarterly knowledge review. Define a maximum acceptable delay for each use case and measure it, instead of assuming that every workload requires real-time processing.

Validate the data and the application separately

Three questions should remain distinct:

• Did the pipeline run?
• Did it preserve the required information?
• Did the AI application use that information correctly?

A completed transformation does not establish semantic correctness.

Traceability shows where information came from; it does not prove that the source is correct.

A retrieval match does not establish that the selected passage supports the answer.

Validation should therefore examine source-to-output fidelity, retrieval relevance, generated claims and failure behaviour as separate concerns.

NIST’s Generative AI Profile recommends verifying sources and citations in generated outputs, checking the provenance of relevant data, and avoiding broad capability claims based on narrow or anecdotal evaluations. [6]

For a bounded pilot, I would assess:

• source traceability;
• compliance with freshness targets;
• retrieval coverage on a reviewed question set;
• citation correctness;
• access-control test results.

I would also record unsupported answers and cases where the system correctly declines to answer.

Critical access or provenance failures should not disappear inside an attractive average score. Readiness controls support deployment decisions; they do not prove the absence of hallucinations or replace broader security, privacy and human-oversight assessments.

A practical architectural perspective

This separation of responsibilities informs our work on CIRMS.

GL3 focuses on automation and operational data acquisition.

GL4 provides the data-preparation path through metadata processing, acquisition, curation, document and chunk generation, vectorisation and semantic validation.

GL5 is the planned applied-AI layer, intended to build on that foundation. [7]

An important architectural distinction is that CIRMS itself is not divided into separate PROD, TEST or DEV product variants.

A CIRMS release is one product build.

If an organisation requires a test deployment, the same CIRMS version can be deployed on test infrastructure. A production deployment uses the same CIRMS version on production infrastructure.

Environment labels associated with source systems describe the operational context of those sources. They should not be confused with different CIRMS editions, builds or product versions.

The distinction is equally important inside the AI data-readiness pipeline.

A deterministic mechanism used to validate end-to-end pipeline behaviour is not a separate “development version” of CIRMS. Nor should it be confused with a semantic embedding model used to evaluate real retrieval quality.

Pipeline validation and semantic-retrieval validation are different responsibilities, even when both operate within the same CIRMS product version.

The broader architectural lesson is independent of CIRMS: distinguish operating the source environment, preparing usable information and consuming that information through AI.

Each responsibility needs clear inputs, checks and accountable owners.

Start with a bounded, testable commitment

For an enterprise beginning this work, I recommend selecting:

• one operational question;
• a limited set of sources;
• a clearly defined user group.

Agree on acceptable errors, freshness, access boundaries and escalation procedures before extending the application’s reach.

The deliverable should be more than a demonstration.

It should be evidence that the chosen information supports the intended task, that changes are handled predictably and that limitations remain visible to the people relying on the system.

This does not require perfect data across the organisation or a replacement of the entire technology stack.

It requires proportionate controls for the actual use case and a plan for maintaining them.

The question is not only “Which AI model should we deploy?” It is also “What evidence shows that the information we provide is fit for this task—and will remain so tomorrow?”

That is where enterprise AI data readiness becomes an operational discipline rather than a one-time preparation exercise.