Every enterprise AI program I've watched stall has the same conversation about 6 weeks in. Someone from the data team says, with total sincerity, "but it's all in the warehouse." And they're right. It's all in the warehouse. That's precisely the problem.
Here's the thing about your data warehouse. It's probably the single most successful infrastructure investment your organization made in the last decade. It consolidated the reporting mess. It gave finance a number everyone agreed on. It survived three CIOs. And now it's being asked to do a job it was never designed for, by people who assume that because it holds the data, it must hold the answer.
It doesn't. The warehouse doesn't actually hold all of your data, and the portion it does hold is good for historical reporting, forecasting, and model training rather than for operational success in the moment. The sooner your AI program admits that, the sooner it stops burning quarters. So with that in mind, my job over the next few paragraphs is to show you where the gaps are and what you can do about it.
What question was your data warehouse actually built to answer?
A data warehouse is an answer to a specific question. Literally what happened, expressed in numbers that we agreed on in advance. Every design decision follows from that. You define the schema up front. You decide which fields matter. You transform messy source data into clean rows. You throw away everything that doesn't fit the model, because everything that doesn't fit the model is noise.
That discipline is exactly why warehouses work. Aggregation requires agreement. You can't sum a column that means three different things in three different systems. So you force it to mean one thing, and you accept the loss.
There's a second loss that gets far less attention. The model has to fit the source data, and frequently it doesn't. Warehouse teams are staffed with data engineers rather than subject matter experts in the systems that produced the data. So the schema encodes an outsider's reading of what those fields mean.
Then the upstream system changes, or a record refuses to fit the very rigorous warehouse model. And the mismatch gets quietly ignored rather than resolved. The nuance dropped at that moment doesn't disappear. It becomes a known unknown sitting underneath every report you run and every AI inference built on top of them.
Enterprise AI asks a fundamentally different question. Not what happened, but what does this mean, in this situation, for this decision. That question doesn't resolve into rows. It resolves into context. Who wrote this, what were they responding to, which version superseded it, what did the customer actually say in the call that the CRM field summarized as "pricing concern."
The warehouse can't answer that, and not because it's badly built. It can't answer that because answering it would require keeping everything the warehouse was designed to discard.
Why does your warehouse only know about data that has stopped moving?
Because a data warehouse is a source of truth for data that's already reached a settled state. Most enterprise data has state, and becomes immutable only once it gets to the warehouse. For example, a financial transaction is pending before it's cleared. An opportunity is open before it's closed. A support case is active before it's resolved. There are a few data points that are stateful at the moment of creation, like events from digital analytics being the obvious example. But the majority move through stages first.
The warehouse is excellent at the settled version of that record but structurally late to the unsettled one. That’s because almost every warehouse installation carries some delay in data load. Couple those two facts together, and you reach a conclusion most data teams resist. For anything still in flight, the real source of truth isn't the warehouse. It's the third party system that captured the data point in the first place. Whether that's the web analytics platform, the CRM, or the ledger.
Plenty of warehouse vendors sell real-time capability, and those capabilities are real. What I've never seen is a warehouse with complete real-time coverage of every source feeding it. Partial real-time coverage is a useful thing to have. But it isn't the same as having the go to source of truth for all things at all times. And enterprise AI programs get into trouble when they treat the two as equal.
So the split is a use case question rather than an architecture preference. If you need to deal with something in real time, like a human in the loop interaction, you're usually better going directly to the stateful source. If you're building analytics, reporting, or training machine learning models for prediction, the warehouse makes a great deal of sense.
Why is most of your enterprise data missing from the warehouse?
Because it was never structured, and structure was the price of entry. The number that should end this debate comes from Gartner. Speaking at the Gartner Data and Analytics Summit in London this May, Distinguished VP Analyst Mark Beyer put the share of organizational data that's unstructured at 70–90%. He described documents and multimedia files as the bulk of what enterprises actually hold.
Sit with that implication. Your warehouse, the system of record for enterprise truth, was built to hold the 10–30% of your data that arrives in tidy columns. The contracts, the call transcripts, the support threads, the engineering design docs, the emails where the actual decision got made… none of it is in there. Some of it is referenced. Almost none of it is present.
For business intelligence that was a reasonable trade. You don't need the contract to chart renewal rates. For enterprise AI it's close to fatal, because the unstructured material isn't supporting evidence. It's the substance. It's where the reasoning lives.
Gartner's own forecast reflects the correction. Principal Analyst Nina Showell told the Orlando summit in March of this year that by 2027, multistructured data management will account for 40% of total IT spend on data management technologies and services. And that the share of AI spend devoted to data readiness will grow 7x between 2025 and 2029. That's not a market discovering a new product category. That's a market paying late, and at a premium, for the data it decided not to keep.
What does a schema delete that AI needs?
Three things, and they matter more than the structured versus unstructured framing. When you model data into a warehouse, you make three deletions:
- You delete provenance, because the row no longer knows which system it came from, who entered it, or what they were looking at when they did.
- You delete relationship, because the join key preserves that two records are connected while discarding what the connection meant.
- And you delete intent, because the field captures the decision but not the argument that produced it.
Provenance, relationship, and intent. Those three are overhead in a reporting system, but they're the entire product in an AI system. A model asked to reason about a renewal risk doesn't need a cleaner churn number. It needs to know that the account manager flagged a concern in March, that the concern referenced a support incident, that the incident was resolved but the customer never acknowledged it, and that a similar pattern preceded two departures last year. None of that is a row. All of it is context. And a warehouse that faithfully preserved it wouldn't be a warehouse anymore.
Is retrieval on top of a warehouse the same as a context layer?
No, though the two have unfortunately become synonymous. The common response is to bolt retrieval onto the existing stack. Vectorize the documents, stand up a search index, point the model at it, call it solved.
That's not solved. And the failure mode is specific. Retrieval finds passages that resemble the query. It doesn't know which passage is authoritative, which is superseded, which the asker is permitted to see, or how any of them relate to the structured record. You get plausible answers assembled from fragments, with no way to distinguish the current contract from the draft that was never signed.
What actually closes the gap is a context layer. Or in other words, a system that sits above the warehouse, the document stores, and the operational systems, and maintains the relationships, permissions, and provenance those systems individually discard. It doesn't replace the warehouse. The warehouse remains the best thing ever built for the job it does. The context layer does the job nobody assigned to anything.
The context layer is the fast system. It reaches the stateful sources, assembles what matters right now, and supports the decision while it's still live. The warehouse is the slow system, holding the considered and agreed version of the record. The relationship runs in both directions. A well built fast layer uses what's already in the warehouse whenever the warehouse is genuinely the right source. And it finishes the workflow by loading the outcome back into the warehouse as a stateful entry.
The build instinct here is strong and expensive. Gartner's Showell warned that through 2028, leaders in AI, data science, and data management attempting to build their own unstructured metadata solutions will incur costs more than 300% higher than they would by using existing document and records technologies, skills, and practices. That’s 3x the cost for infrastructure that's not your differentiator.
How should your AI program treat the warehouse instead?
The most useful move available to most enterprise AI programs is also the least satisfying. Stop treating the warehouse as the destination and start treating it as one input among several. That means accepting that some of your most valuable material will never be consolidated, and building a layer that reaches it where it lives. Rather than waiting for a migration that won't finish.
It means measuring AI readiness by how much context a system can assemble rather than how much data a repository can hold. And it means being honest in the steering committee about which use cases the warehouse genuinely serves, and which ones were never going to work no matter how clean the tables got.
Your warehouse isn't the problem. The expectation placed on it is. It was built to tell you what happened, and it does that better than anything that came before. Enterprise AI needs to know what things mean, and meaning was the first thing the schema threw away.
So the question worth asking at the next review isn't how do we get the AI to use our data. It's simpler and more uncomfortable than that. Of the decisions you want AI to support, how many depend on information that never made it into a column?
If the honest answer is most of them, you don't have a data problem. You have an architecture problem, and no amount of warehouse tuning will touch it.
Let's talk soon if you're evaluating tooling and want a second opinion on what it will prove.
.png)
.svg)