White Paper
 

AI-ready data: Why your data foundation determines whether AI delivers or disappoints

Enterprise AI is facing its newest constraint: context. As someone who has spent years urging companies to build stronger data strategies, align data investments with product development, and treat the data ecosystem as a core business capability, I think this may finally be the industry’s wake-up call.

AI-ready data: Why your data foundation determines whether AI delivers or disappoints

Author: Kurt Knaub (Head of Data and AI, Nortal Americas).

AI is exposing a problem that has been easy to tolerate for years; most enterprise data was built to support transactions, applications, and reporting, not to help intelligent systems understand the business. Today, the issue is whether the organization has given data enough meaning, structure, relationships, and context to make it useful to AI.

Recent industry research reinforces the pattern. McKinsey found that only 7% of organizations have fully scaled AI, while more than two-thirds of high-performing companies identify data as the primary obstacle to scaling it. A 2026 study found that 42% of leaders rate their strategy as highly prepared for AI adoption, while only 40% self-rated preparedness for data management and 43% for technical infrastructure, both down from the previous year. The research attributes the drop to the challenge of modernizing systems at the speed of innovation.

We see the same sequence often enough to predict it. A company modernizes its applications, stands up a data lakehouse, consolidates a decade of records, passes its governance audit, and declares itself ready for AI. Then the first real production use case arrives and the foundation buckles. The trouble runs deeper than dirty data: the estate lacks shared meaning across systems and contracts between producers and consumers. It also carries no guarantee that the model is consuming real-time, accurate information.

Well-organized data and AI-ready data are different things. Well-organized data is built for people who can spot oddities and ask follow-up questions. AI-ready data is built for systems. This distinction explains the difference between a pilot that impresses a steering committee and an AI system that runs part of the business.

This white paper covers what comes next after going through a legacy modernization process: what AI readiness requires at the implementation layer, how to tell where your data estate stands, and what to fix first.

What engineering leaders need to understand about AI data readiness

AI readiness is an engineering discipline rather than a maturity score. It's easy to mistake for one because the artifacts look similar: quality dashboards, a catalog, a governance policy, and an owner named in a spreadsheet. Those are inputs. You can measure readiness by whether a production AI system can consume your data without a human standing behind it to interpret, reconcile, or apologize for what it finds.

In practice, four capabilities decide that outcome.

The first is a governed semantic layer, where terms like revenue, active customer, on-time delivery, and unit cost have one set definition regardless of which pipeline serves them. The second is reusable data products: governed datasets published with a schema contract, a refresh guarantee, and an owner, so the next AI use case consumes what already exists instead of rebuilding a pipeline from scratch. The third is metadata that makes every dataset discoverable, classified, and traceable back to the source, which makes it auditable. The fourth is ingestion that keeps context current at the latency the use case needs, which is rarely the nightly batch window that a reporting layer was designed around.

Four capabilities that make data AI-ready

Governed semantic layer

Terms like revenue, active customer, and unit cost have one set definition, whatever pipeline serves them.

Reusable data products

Governed datasets. The next use case consumes what exists instead of rebuilding a pipeline.

Traceable metadata

Every dataset is discoverable, classified, and traceable, so it can be audited.

Latency-matched ingestion

Context is kept current at the speed the use case needs.

For asset-intensive industries, the reality is messier. A manufacturer's data estate is usually an ERP core surrounded by machine telemetry, a quality system, a maintenance history, and a warehouse layer, each built in its own era by its own team under its own assumptions. Generic readiness frameworks assume a clean starting point. That assumption is where most of them fail. So here is a practitioner’s view: how to define readiness precisely, how to assess it honestly, and how to close the gap in an order that unblocks value early.

What AI-ready data is, and what it is not

Beyond data quality: The AI readiness distinction

Data quality answers a narrow question: is this record accurate and formatted the way we expect? That question matters, and it's not the one AI asks.

Let’s consider an example. Picture a dataset that performs beautifully in a quarterly margin dashboard. An analyst opens it, notices that one business unit reports margins before freight and another reports after, adjusts for it in about 40 seconds, and moves on. The dashboard is fine. Now point a forecasting model or a copilot at the same dataset. The model has no way to know that the two figures mean different things. It has no instinct for discrepancy and no mechanism to resolve it. It will learn from them or confidently report one as the other.

AI-ready data clears a higher bar on four counts:

  1. It’s semantically consistent, so a term means the same thing everywhere it appears.
  2. It’s contextually complete for the specific use case, carrying the surrounding facts the model needs.
  3. It’s accessible at the latency the use case demands.
  4. It’s governed in a way that stays auditable across the full lifecycle, from training data through inference output.

If you read those requirements against the labels most organizations use, the gaps become obvious. Reporting-ready data is optimized for a fixed set of known questions. BI-ready data adds dimensional structure and self-service access but still assumes a human is there to interpret what the data means. AI-ready data must meet a higher standard: it must be consumable by systems that cannot pause to ask for clarification. We see that distinction increasingly reflected in industry research, which finds that traditional data foundations built for reporting and human interpretation often lack the context, semantic consistency, governance, and timeliness that advanced AI systems require.

Beyond an ongoing vocabulary feud, this is the reason some projects reach production and others stall in the pilot phase.

 

GenAI vs. Predictive AI: Different data requirements

Treating AI as a single data problem is the most expensive oversimplification in enterprise architecture right now, because it guarantees over-building for some use cases and under-building for others in the same program.

A fraud or failure prediction model needs historical depth and disciplined feature engineering. It needs labeled outcomes over time and enough volume to learn from. It can run on a batch pipeline. It breaks when the training data includes information that would not have been available at the time of prediction.

It breaks when you assemble the training set with hindsight.

A retrieval-based copilot needs a chunked, curated knowledge corpus, embedded and wrapped in retrieval metadata good enough that the system can tell a current policy from a superseded one. Its failure mode is a fluent, plausible answer drawn from a document that expired 18 months ago. Freshness and provenance carry more weight here than volume.

A fine-tuned model needs a smaller set of high-quality, representative examples and a labeling process a person owns. Here, volume helps far less than consistency.

An agentic system raises the bar again. When AI completes an action rather than producing an answer, it needs low-latency access to live state, hard schema contracts, and clear boundaries on what it's permitted to touch. A schema change that would break a dashboard breaks an agent in a way the business notices.

Map use cases to these modalities before funding the data work. The requirements diverge sharply, and the cost of getting the match wrong shows up late.

The AI-ready data foundation: Architecture and components

Semantic models and enterprise data products

The semantic layer is the most skipped part of an AI-ready foundation, largely because skipping it can be survivable for years. Reporting absorbs semantic drift. Someone reconciles the numbers before the board meeting or adds a footnote, and the organization adapts. The cost is real but distributed and invisible.

AI removes that tolerance. When the same metric resolves three ways depending on which pipeline produced it, a model can’t adjudicate between the versions. It has no context for which definition the business intended, so it treats all three as equally true. Whatever is produced will be defensible on its own terms and wrong in ways that are hard to trace.

A governed semantic model fixes the definition once: the calculation, grain, filters, exclusions, and the owner who signs off when it changes. Every consumer, either human or machine, resolves through it.

Enterprise data products carry the same discipline into delivery. Instead of each project extracting and reshaping source data for itself, a data product publishes a governed dataset with a schema contract, a stated refresh cadence, a quality guarantee, and an accountable owner. The contract is the part that matters. It converts an informal dependency into a commitment, which means a producer can no longer quietly change a column and discover the consequences from a downstream incident.

The compounding effect is what makes this worth funding. The first AI use case pays for the data product. The fifth one gets it for free.

 

AI-ready data infrastructure and metadata management

Infrastructure for analytics and infrastructure for AI are not the same build, even when they share a platform.

A lakehouse on Microsoft Fabric, Databricks, or Snowflake gives you the storage and compute substrate, and choosing between them is a smaller decision than most procurement processes suggest. What separates an AI-ready estate from a well-equipped one is the metadata layer sitting above the substrate.

We identify three mechanisms that do the work. A catalog makes datasets discoverable and classified, so a team building a new use case can find what exists and know what sensitivity rules apply before they touch it. Lineage tracks every transformation from source to consumption, which is what lets you answer the question that always arrives after an AI system produces a surprising output: where did this come from, and what changed? Automated quality monitoring watches continuously for schema drift, distribution shifts, and freshness violations.

Venn diagram showing how a discoverable data catalog, automated quality checks, and transformation lineage combine to create an AI-ready data estate above a lakehouse.

This is the machinery that makes data trustworthy enough for a system to consume without a person validating each step. Skip it and the effort doesn’t disappear; it moves to a human reviewer sitting between the model and the decision, which is exactly the bottleneck the AI was supposed to remove.

Assessing data infrastructure readiness for AI implementation

The AI data readiness assessment framework

Before committing architecture budget to remediation, you need to know which parts of your data estate are already production-grade, which are close, and which need foundational work. Most organizations skip this and remediate everywhere at once, which spreads effort thin and delays every use case equally.

A useful assessment runs domain by domain, not enterprise-wide, and scores six dimensions.

  1. Semantic consistency: Are key business terms and measures defined consistently across the systems the use case depends on?
  2. Quality: Is the data accurate, complete, and consistent enough for the intended use, with checks to detect material errors?
  3. Context: Does the data include the business meaning, relationships, and supporting information needed for the AI use case — not just for reporting?
  4. Accessibility: Can authorized applications retrieve the data reliably, in the required format and within the required time? This includes streaming or event-driven access where needed.
  5. Governance: Are ownership, permitted uses, access controls, and sensitivity classifications defined and enforced?
  6. Lineage: Can the data and its transformations be traced back to their sources, including the inputs used to produce an AI output?

Here is what an example could look like, for illustrative purposes:

Illustrative AI data readiness matrix comparing HR/workforce, finance/ERP, customer/CRM, product/service, and operations/supply chain across semantics, quality, context, accessibility, governance, and lineage. Ratings distinguish production-grade readiness, limited remediation, and foundational work.

The assessment should produce a prioritized remediation roadmap, supported by the readiness ratings. The roadmap identifies which domains need work, the order of remediation, and the AI use cases each improvement enables. Sequence the work so the first remediation cycle delivers a use case into production and demonstrates the value.

Enterprise data maturity and the pilot trap

The gap between AI pilots and AI production is well documented. MIT Project NANDA’s 2025 research describes a pronounced “GenAI Divide” between widespread enterprise experimentation and initiatives that deliver measurable business value. The research points to familiar challenges such as workflow integration, organizational learning, and demonstrating ROI. While these are certainly common issues in AI programs, the underlying constraint is harder to see and diagnose: the data foundation itself is not mature enough to support AI reliably at scale.

We see this trap being built into how pilots are run, and it's nobody's fault. To prove a concept quickly, a team picks a narrow scope and prepares the data by hand. They pull one region, clean it, resolve the definitional conflicts in a spreadsheet, and stand up a dataset that behaves. The pilot works, as it should: the conditions were curated to make it work.

Then scaling begins, and every assumption that held up for one region fails across 14. The manual cleanup doesn’t generalize. The definitional conflicts that one analyst resolved by judgment now need a governed answer the business has yet to settle. The pipeline that ran fine as a scheduled notebook needs monitoring and an owner. What looked like a deployment task turns out to be the foundational data work the pilot deliberately postponed, now with a live commitment attached and a sponsor asking why it's taking so long. In fact, this 2026 report notes that use cases estimated at three months can stretch to 18 when integration complexity surfaces. The important thing to note is that the foundation work gets done either way. Doing it after commitment costs more, because the rework arrives with a deadline attached to it.

Organizations that build maturity first move slower at the start and considerably faster after the second use case, because governed models, reusable products, and standardized ingestion patterns are exactly the assets that make each subsequent case cheaper.

Here’s how it works in practice. For a U.S. mid-sized engineering and consulting firm, we established a governed Microsoft Fabric foundation before scaling individual analytics and AI use cases. By integrating five core applications into reusable data models with standardized access controls and automated ingestion, they delivered three high-impact analytics products (including an AI-driven RFP and résumé recommendation capability) on a common platform rather than building each as a standalone pilot. This foundation cut repeated integration and governance work, and their internal teams now support and scale new analytics and AI products on their own.

AI-ready data for manufacturing, distribution, and logistics

Industry-specific data readiness challenges

Asset-intensive industries make the gap between reporting-ready and AI-ready data especially visible.

Reporting can often tolerate fragmented systems, inconsistent identifiers, delayed updates, and a degree of human interpretation. AI systems have much less room for ambiguity. A model that predicts a failure, recommends inventory, or optimizes a route must resolve what it sees, understand how the relevant data relates, and commit to an answer.

In manufacturing, operational technology and information technology were never designed to meet. Machine telemetry arrives as high-frequency time series with vendor-specific tag names, often without a consistent asset identifier and with clocks that drift. The ERP holds transactional records at a completely different grain, updated by people rather than sensors. Quality management runs in a third system with its own part numbering. Maintenance history lives partly in free-text work-order notes, which is often where the most valuable failure context sits.

Building a predictive maintenance model means reconciling asset identity, time, operating state, maintenance history, and quality events across all of them before meaningful modeling can begin. In many cases, that reconciliation is the project.

The work we did for Valmet shows what the OT/IT crossing looks like in practice. The company is a global developer and supplier of technologies, automation, and services for the pulp, paper, and energy industries. A fire during a roll test at one of its factories destroyed a test rig, and the plant recovered only the most recent runs from storage sitting beside the operator's room. In six months, we built the integration for the replacement rig: 3,000 sensor tags covering temperature, speed, pressure, flow, and vibration, streamed into Real-Time Intelligence in Microsoft Fabric. The same platform can carry other test rigs and other Valmet factories.

Distribution and logistics have the same problem in a harder form. Order management is often split across systems inherited through acquisition. Carrier data arrives in whatever format each carrier provides, at whatever cadence they choose. Inventory position sits in several systems and matches none of them. Reporting tolerates that, but a demand forecast or a route optimizer doesn’t, because it must commit to a number and act on it.

The architectural response starts with resolving identity, since an asset, a part, a shipment, and a customer each need one canonical key before anything downstream can be trusted.

Real-time analytics capabilities for AI systems in production

AI systems that run on stale data produce stale decisions, and they do it confidently. The model is not the issue.

The examples are unglamorous and common. A predictive maintenance model trained on high-frequency vibration data, deployed against a pipeline that lands data once a day, will miss the failure signature it was built to catch because the signature developed and resolved inside the batch window. A copilot retrieving policy documents from a knowledge base refreshed weekly will tell a customer service agent something that stopped being true on Tuesday. An inventory agent acting on a position that is four hours old will promise stock that is already committed.

What fails silently in these cases is the latency of the surrounding pipeline. A broken pipeline raises an alert; a slow one just degrades the quality of decisions in a way that is hard to attribute.

Streaming ingestion, event-driven architecture, and continuous refresh of model context are the baseline for AI systems that operate inside a live business process. Systems don't need real-time capability everywhere, and building them on that foundation wastes resources. What you need to understand is which decisions are time-sensitive enough. Settle that per use case and the architecture follows.

How to make your data AI-ready: A practitioner's roadmap

From lakehouse deployment to governed data foundation

Deploying a lakehouse is the start of an AI readiness program. The progression from platform to production-grade foundation runs through four stages, and knowing which one you are in prevents a lot of wasted effort.

  1. Consolidation puts the data in one place. It unifies storage, lands your sources, and gets the platform live. Most organizations reach this stage and mistake it for readiness.
  2. Standardization establishes shared meanings. Agree on definitions, make schemas consistent, and resolve identity across systems, so the semantic layer works as an enforced artifact rather than a document.
  3. Productization packages governed datasets as products with contracts, SLAs, quality guarantees, and named owners. Here, AI use cases stop paying their own data tax.
  4. Operationalization adds what production demands: real-time pipelines where you need them, continuous quality monitoring, drift detection, and governance built for AI-specific risks such as training data provenance and output auditability.

Most organizations we work with sit at stage one or two. The useful move is not to attempt all remaining stages across the whole estate. Pick the two or three domains that unblock your highest-value use cases and take them fully to stage four, then reuse the patterns. Depth in a few domains beats a thin layer everywhere, and it produces something to point at.

Four stages of a governed data foundation: consolidation unifies data in one place; standardization enforces shared meaning; productization publishes governed datasets as products; operationalization supports production and AI. Most organizations are at the first two stages.

The organizational dimension: Ownership, buy-in, and change

No data architecture survives organizational ambiguity, and AI readiness is unusually exposed to it.

The mechanism is simple. When data engineering, business units, and enterprise architecture each hold partial accountability for the estate, nobody has the authority to settle a definition. The semantic inconsistency that comes next is because the disagreement is about what the business wants the numbers to mean.

How it’s solved in practice:

  • A clear mandate, held by a CDO or a data product owner with real authority to arbitrate definitions and enforce standards.
  • Federated stewardship, where domain teams own their data products because they understand the domain, while a central function owns the standards those products must meet.
  • A change approach that treats skepticism as reasonable rather than obstructive, because most of it comes from people who have watched a previous platform program under-deliver.

In our experience, the hardest part is moving an organization from treating data as a byproduct of running systems to treating it as an asset that has owners, contracts, and consequences when it breaks. That shift is what makes the rest durable, and it takes longer than any technical stage in the roadmap.

Modernizing applications for AI-ready data

AI-ready data is only one side of the modernization problem. Many organizations are simultaneously dealing with legacy applications whose business logic and undocumented behavior are just as difficult to understand as the data they produce.

The two efforts are complementary: one makes legacy applications easier to understand and modernize, while the other makes those systems’ produced data trustworthy and reusable for analytics and AI.

For enterprises modernizing both layers, there is an opportunity to coordinate them deliberately. Legacy application archaeology can expose hidden business rules, source-system dependencies, and data transformations that inform semantic modeling and lineage, while an AI-ready data foundation provides a cleaner target architecture for the modernized applications that later replace those systems.

Diagram linking legacy code modernization with data readiness for analytics and AI. Business rules, data definitions, and source mappings inform data; required data, quality standards, and access needs shape code. Together they produce modern applications with trusted, usable data.

Clarity before commitment

Our AI-driven modernization work addresses that application layer by using AI-assisted techniques to uncover and reconstruct legacy code, business rules, and system dependencies.

Find out how it works

The road ahead: Where AI-ready data goes next

Lasting advantage comes from the structural work done before the models arrive: governed definitions, data products with contracts, resolved identity, and ingestion that matches the decision speed of the business. While this work is hard to show off, it decides whether anything else reaches production.

Deferring the foundation gets more expensive from here. Agentic systems are moving from experiment to default deployment pattern, and those systems act inside live processes without a person reviewing each output. A weak schema contract used to cause a reporting error. Now it causes an incident. At the same time, real-time context is becoming a baseline expectation, and tolerance for data that arrives stale or carries ambiguous meaning is heading toward zero. A recent study found that a $20 billion enterprise loses roughly $140 million a year to AI irregularities, and about half of that traces back to governance gaps.

Our position is straightforward. AI readiness is a data discipline, and it belongs in the enterprise architecture from the start rather than retrofitted after a pilot fails to scale. We would rather have the uncomfortable conversation about foundational gaps earlier than be brought in to explain a stalled program 18 months later.

Frequently asked questions about AI-ready data

What is AI ready data, and how does it differ from high-quality data?

How do I assess my organization's data infrastructure readiness for AI implementation?

What are the most common reasons AI pilots fail to reach production?

How do data requirements differ between generative AI and predictive AI models?

What does an AI-ready data foundation need to include for manufacturing or logistics organizations?

References

Challapally, A., Pease, C., Raskar, R., & Chari, P. (2025). The GenAI divide: State of AI in business 2025. In MLQ.ai. MIT NANDA. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf

IBM Institute for Business Value. (2026). AI in motion: Orchestrating AI at scale for sovereignty and resilience. In IBM.com. IBM. https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-orchestration-layer

State of AI in the enterprise. (2026). In Deloitte.com. Deloitte. https://www.deloitte.com/content/dam/assets-shared/docs/about/2025/state-of-ai-2026-global.pdf

Tavakoli, A., Goodman, B., Kayvaun Rowshankish, & Reddin, S. (2026, June 23). AI data readiness: The key to scaling impact. McKinsey & Company. McKinsey.com. https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/ai-data-readiness-the-key-to-scaling-impact#/

Tung, T., Lancaster, M., & Bansal, A. (2026, May 26). AI-ready data. Accenture. Accenture.com. https://www.accenture.com/en/insights/ai-data/ai-ready-data

Kurt has spent 25 years on enterprise data problems. He works with CDAOs, CIOs, CTOs, and VPs of analytics across Fortune 500s, mid-market firms, and government agencies. His argument, built over hundreds of client engagements, is that most data programs stall for reasons that have little to do with tooling.

Kurt Knaub Nortal

Kurt Knaub

Head of Data and AI, Nortal Americas 

Get in touch

Talk with our data and AI team about preparing your data foundation for AI in production.