Context-Aware Data: Why AI Needs More than Just Volume

The last two years of enterprise AI were all about experimentation, and it was easy to stay there. Models kept changing, so production timelines slipped, and each improvement surfaced new capabilities teams wanted to fold in, which meant more scope, more testing, more delay. A vicious cycle, with model progress itself as the reason nothing shipped. That cycle is breaking and enterprises are ready to move from experimentation to AI that actually delivers value to the business. What matters most in that shift is not which model you pick, and not even how much data you have, but whether your data carries the context a model needs to be accurate.

Model choice matters less now because the best open weight and frontier models have converged. Kimi K3 and Claude Fable 5 are already close enough that for most enterprise work you’d struggle to tell them apart, the open model costs a fraction as much, and the next release will only get you an incremental gain, not leaps like in previous years. The engineering effort has moved to the harness: the tools, memory, evals, and guardrails wrapped around the model, where the hard problem has shifted to keeping agentic workloads running for hours with minimal human oversight. Winning is now about building for flexibility that is invisible to the user, where the workflow that ran yesterday runs the same way today while the harness switches models underneath to optimize for cost, performance, or any other KPI that matters. The model becomes an implementation detail.

That flexibility rests on the most important layer that enterprises can leverage – the data underneath. Remember that the oldest adage in computing still applies here: garbage in, garbage out. The best harness in the world runs on what you feed it, and the most important data you can feed it is your own. It has always been the enterprise differentiator in AI, and now that everyone runs essentially the same models, it’s the only one left. Every enterprise is sitting on volume, decades of tables, documents, and tickets, but volume alone makes a model worse, not better. What makes a model accurate is knowing which table is canonical, which document is current, and how the customer in one system relates to the customer in another.

Data quality decides AI success

In an IDC survey of enterprise leaders on what determines AI success, 94% said data quality is decisive. Survey research rarely comes that close to unanimous. The report also names the top causes of poor quality, and it’s the usual suspects: redundant data, siloed data, and obsolete data. I’ll note that model capability does not appear on that list, neither does model harness. The problems undermining enterprise AI today are the same ones that have been undermining analytics for the last 20 years. What has changed is how they appear, because each of these three data issues makes a model’s answers worse in its own way.

Obsolete data produces answers that look like hallucinations but are not. The retrieval pipeline serves up last year’s return policy, the agent quotes it to a customer fluently and confidently, and the company is now on the hook for refund terms it retired months ago. The engineers reviewing the incident log it as a hallucination, but the model did its job correctly. It’s the inputs that were wrong.

Redundant data introduces randomness. When six near-identical copies of a table exist and two of them disagree, there are two ways this goes wrong. If retrieval surfaces only one copy, which copy the model receives is a matter of chance, i.e., answer quality now carries a random variable. If retrieval surfaces both, the model should catch the contradiction, but in a sea of context, it may focus on one copy and ignore the other altogether. Either way, the same question asked on two different days can return two different answers, and neither the user nor the engineer can explain why without tracing the retrieval.

Siloed data turns shared knowledge into local knowledge. A silo is rarely a deliberate restriction. More often, the way a system was implemented means data that should be viewable by everyone only surfaces for a few teams. As a result, a general enterprise knowledge question returns disparate answers depending on which slice of the data the model can see. Two employees can ask the same question, receive two different answers, yet both answers are faithful to the partial data behind them. The problem compounds as more AI tools are built on top of the enterprise’s data. A tool one team builds on its slice will reach different answers, and eventually different decisions, than the tools other teams build on theirs, and what starts as two employees receiving inconsistent answers ends as automated systems acting on conflicting information, with the enterprise carrying the cost of that conflict.

This combination leads to a predictable misdiagnosis. When a capable model runs on poor data, engineers see wrong answers and conclude the model is at fault, teams respond by evaluating a replacement, and the experimentation cycle starts all over again. Replacing the model changes nothing, because the data underneath stays the same.

Data is not context

If bad data makes a model’s answers worse, then fixing it requires knowing what good data provides that a capable model does not already have. The answer is context, and I can explain the difference between data and context with an analogy from everyday life. Let’s say a friend sends you a photo from his vacation: He is on a boat, on a lake, and the sun is out. You now have data, and you can describe the scene accurately to anyone: a person, a boat, a lake, roughly midday.

Then you call him, and you get context. The wind was blowing 20 knots that day, strong enough to make the whole crossing rough. The motor died halfway across, and the family drifted for an hour. His kids decided the drifting was the best part of the entire trip, and it’s the story they’ll be telling at Thanksgiving for the next decade. It’s the same scene, but you now know very different things about it. The photo tells you what is visible, while the friend tells you what happened, why it mattered, and what it connects to.

The mapping to the enterprise is direct: Your data is the photo, and your employees are the friend. Somewhere in your organization, an analyst knows that of two revenue tables that look interchangeable, only one carries the corrected Q3 numbers. Someone in finance knows that “customer” in the billing system means the legal entity while “customer” in the product system means the end user, and that conflating the two once produced a churn number wrong enough that it had to be corrected in front of the CEO. This is where enterprise knowledge actually comes from: people who can tell you why this data set is the right one for the analysis and not the other data set that superficially captures the same information. The model sees none of this; it only sees the photo.

Context-aware data is how you get the friend’s account into a form a machine can use. It has two main components. Knowledge graphs encode relationships and provenance: this table supersedes that one, this metric derives from these three sources, this account in the sales system is the same entity as that account in billing. Semantic layers take the definitions your employees carry around informally and make them explicit and governed: what “revenue” means, which customer field is canonical, and which pipeline the finance team actually trusts.

Context-aware data is also the substance behind the industry’s shift in vocabulary from prompt engineering to context engineering. Prompt engineering was about phrasing the question well. Context engineering is about deciding what the model can see at the moment it answers, and that’s an architecture problem and not a writing skill.

Figure: Two-layer stack. Top layer: Interchangeable models, swapped freely. Bottom layer: The durable context layer (knowledge graph + semantic layer) feeding every model the same institutional knowledge. 

The next model will not fix bad data

Readers who work close to the model layer usually raise the same objection at this point. If context windows have grown past a million tokens and reasoning improves with every release, why won’t scale eventually compensate for messy data? It’s a fair question, and scale does help. A longer window means fewer arbitrary cuts to what the model can see, and better reasoning catches more contradictions than it used to. What scale cannot do is repair inputs that are wrong.

A stale document in a million-token window is still stale, you’re just paying more to process it. Better reasoning applied to contradictory tables does not resolve the contradiction; it produces a more articulate defense of whichever copy the model chose to trust. The adage mentioned earlier in this article has survived six decades of exponential compute growth, and it will survive this one too.

AI quality is a data intelligence problem

When answer quality disappoints, the instinct of a technically deep AI leader is to work at the model layer (fine-tune on the company’s corpus, distill, evaluate harder) or at the harness layer (add retries, tighten the guardrails). Neither works, because neither touches the data. Fine-tuning on redundant, stale data moves the problem into the model’s weights, where it no longer shows up in any retrieval log an engineer can audit. A stronger harness does not fix it either since it only makes the agent fail more gracefully.

The context layer is where that effort should go instead. Models get replaced and harnesses get rebuilt, but the context layer stays, and everything you add to it builds on what is already there. Every relationship you encode, every definition you make explicit, and every piece of institutional knowledge you move from an analyst’s head into a graph improves every model that runs on it—the one you deploy today and the one you swap in next quarter. 

A model starts losing value the day it ships because a better one is already on the way. As I write this, three points separate the leading frontier model from its open source challenger on the Artificial Analysis Intelligence Index, and the order will change in a few short weeks. The context layer moves in the opposite direction. It gains value with everything you add to it, and every model you ever run inherits that value.

Building that layer is a data intelligence problem, not a model problem. Cataloging, lineage, entity resolution, and governed semantics are the machinery that captures what your people know and puts it where the model can use it. I won’t pretend this is solved; encoding tacit human knowledge at enterprise scale is genuinely hard. But it’s the hard problem worth working on, because it’s the one part of the stack that does not commoditize.

The models will keep trading places at the top, and that is fine, because a flexible harness lets you swap them in an afternoon. What you cannot swap in is what your organization knows. Any model can look at the photo, but only your context layer knows what happened that day on the lake.