One of the things that makes today's AI so compelling is fluency. Ask an LLM a question and it gives you a confident, articulate answer in seconds. It feels like knowledge.
But fluency is not provenance.
I have been spending a lot of time lately talking with very large companies about AI, and increasingly I am coming away from those conversations thinking that one of the biggest obstacles to enterprise AI isn't actually AI. It is everything that happened to the data during the 20 or 30 years before AI showed up.
You see it everywhere. Someone in procurement has an Excel spreadsheet. Another group has its own database. Someone else has a SharePoint site that became the unofficial system of record. A business process that was supposed to be standardized gradually became five slightly different processes depending on which group was doing the work. And inevitably there are a handful of people who simply know how everything actually works.
This isn't necessarily bad management. In many cases it is just what happens to successful companies. Organizations grow, systems get added and people solve the problem immediately in front of them. The architecture accumulates rather than being designed.
I saw a version of this years ago at Bloomberg. Bloomberg was, and remains, one of the great financial data companies, with extraordinary amounts of data collected and maintained by people who deeply understood financial markets. But Bloomberg had also been building products for decades, and some of the architecture dated back to a very different technological world.
As a product manager trying to build analytics, the problem was rarely whether Bloomberg had the data. Of course it had the data. The harder questions were: Where exactly is it? Which version is authoritative? What does this field actually mean? How was it calculated? When did it change? What else depends on it? Can I rely on it?
Those questions sound mundane. I think they are becoming some of the most important questions in AI.
Ontology and provenance
Two words are showing up more and more in conversations about enterprise AI: ontology and provenance. They sound academic, but the concepts are actually pretty simple. Ontology is meaning: What is this thing, what does it represent, and how does it relate to other things? Provenance is trust: Where did this information come from, who created it, what happened to it along the way, and can I trace an answer back to its source?
But there is something important sitting between those two ideas: the accumulated knowledge of the enterprise itself.
Go back to Bloomberg. Financial data wasn't simply dumped into a database. People who understood foreign exchange decided how currencies should be represented. Bond experts understood the relationships among an issuer, a security, a coupon, a maturity, a curve and a benchmark. People who had spent their careers in those markets made decisions about what mattered, what belonged together and how the information should behave.
That is knowledge. Some of it was explicitly encoded in software and data models, some was embedded in rules and processes, and some lived in the heads of the people who built and operated the systems. Every large enterprise has some version of this. We tend to look at the old databases, spreadsheets, applications and SharePoint sites and see technical debt. But buried inside them is an enormous amount of accumulated human expertise about how the business actually works.
Then along came the LLM
The temptation right now is to put an LLM on top of all of this and declare victory. And to be fair, the result can look pretty impressive. Suddenly I can ask questions in English, search across documents and summarize things that would have taken a person hours to read.
But fluency is not provenance. An articulate answer doesn't tell me whether the number came from SAP, an authoritative database, Jane's spreadsheet, a three-year-old PowerPoint or a SharePoint file somebody updated Tuesday afternoon. More importantly, the LLM doesn't automatically understand the accumulated expertise that produced that information in the first place.
I increasingly think an AI-ready enterprise needs to be able to answer five basic questions about its knowledge: What is it? What is it connected to? When was it true? Where did it come from? Who decided that this is how it should work?
That is identity, relationships, time, provenance and governance. Underneath all five is domain expertise. This is why ontology becomes much more interesting to me than simply creating another data model. A good enterprise ontology should capture the knowledge of the people who actually understand the business. Provenance should tell us not only where a piece of information originated, but how that expertise was applied to it along the way.
Looked at this way, the old enterprise data estate stops looking only like technical debt. It starts looking like an enormous repository of knowledge that hasn't yet been made fully usable. The objective isn't necessarily to replace all those systems or move everything into one giant database. It is to make the meaning, relationships, rules and provenance surrounding that information available so software and AI can reason across it.
For years, enterprises compensated for weak architecture with people. Someone knew which spreadsheet was right, whom to call, why the number changed, or that two fields with different names actually meant the same thing. We are now asking AI to do more and more of that work.
If we want AI to reason rather than simply retrieve, summarize and generate, we have to give it more than access to data. We have to give it access to the accumulated knowledge of the enterprise: the context, meaning, relationships, history, rules and provenance that turn data into something much more valuable.
There is a funny connection here to how we named SeerAI.
When my cofounders and I were sitting around trying to name the company, we kept coming back to the idea of a seer. A seer isn't someone who simply has access to more information. A seer sees what is there and understands what it means. The relationships matter. The history matters. The context matters. We added "AI" because even then we had a pretty good idea where all of this was going.
Looking back, the name was probably an ode to the problem we were trying to solve before we completely understood how to describe it.
Enterprises already have extraordinary amounts of data. More importantly, they have decades of human knowledge embedded in that data, in their systems, in their rules and in the people who built them. The opportunity now isn't simply to give an AI access to all of it. It is to let the AI actually see it.
Because fluency is not provenance. And having all the data isn't the same thing as understanding what it means.