Data Intelligence Depends On Capturing The Knowledge Analysts Already Carry

Enterprise AI programs get budgeted around data access. Teams inventory the systems they have, connect a model to them, and wait for the outcomes to arrive. What often gets overlooked is the knowledge held by the people who have run those systems for years. Enterprises scaling past their first pilots are finding that the volume of data on hand predicts very little about what they can build with it.

Robert Alvarez, PhD, is a Principal AI Solutions Architect at Everpure, where he designs AI systems for enterprise customers. He previously led AI projects at NASA's Frontier Development Lab, developing computer vision models for radiation detection, and built data science curricula at universities and bootcamps. Today, his work centers on what an organization has to capture about its own operations before a model can use its data well.

"It's not just about having a little bit of data that you use for AI, but leveraging all the data as long as it's context-aware. You need that context for it to be useful, otherwise you're just going to get gibberish out," says Alvarez. He treats the missing context as a documentation problem. A model with access to every system in the company still has no way to tell which one answers the question.

Recording tribal knowledge

For Alvarez, context is the reasoning behind a choice of data. "You've got business analysts that know exactly what table to query for some specific function, even though there are three other tables that look like they have the exact same data, but they can tell you why it's that one and not the other two," he says.

He points to project documentation as the place that knowledge can live, under a reading pattern that has changed completely. A document written for the new pattern has to carry what a human reader would once have inferred, because anything left implicit never reaches the model. "An engineer would read that maybe once or a few times while they were starting up, but then they got a sense of it," Alvarez notes. "You've got to remember that now for AI, that doc is being read every single time AI does a query."

A document read that often can't remain a one-time deliverable. Alvarez describes a standing artifact, revised whenever a team or agents learn something worth keeping. A spec written once and closed leaves the model working from the business as it looked on the day it was written. "Whenever you're going to do any analysis, read this doc first," he says. "This doc is going to be a running version of that team's knowledge or that organization's knowledge."

Design backward from the outcome

A team can agree a running document is worth building and still not know what belongs in it. Alvarez answers that from his background in education, where a teacher who builds the course before writing the exam finds the gap only after the material has been taught. "The way I think about it is backward design for curriculum," he explains. "It's basically start with the test, and then go back to the syllabus, and then build the curriculum."

Applied to AI work, the exam is the spec document and the build is everything a team assembles to satisfy it. Alvarez wants the sequence proven on one project first. "Before you start having AI build, spend a sprint with your engineering team designing all of the features that you want out of that project and writing them down in a doc," says Alvarez. "From there you can figure out how you scale that out to many more projects running in parallel, but small bites at first."

Sensitivity decides the route

Alvarez treats the specification as one half of the problem and the location of the model as the other. An enterprise operating its own data center still sends requests outward unless something inspects them first. "If you've got very sensitive data and you're making a request to do some analysis on it with AI, you need to have an on-prem model that you trust and can route that to it," says Alvarez.

Routing depends on open models being close enough in capability to take the work, and Alvarez puts the remaining distance below what most people assume. Cost enters the same decision, since a large share of enterprise requests don't need frontier-scale inference to answer well. "Your inference stack as enterprises grow and AI matures is going to be leveraging this hybrid of both frontier models and open models," he notes. "I don't think people are going to be fine-tuning models the way they were a year and a half ago. Models are much more capable now that they just need the right context, the right data and a good prompt."

Owning the intelligence layer

A model that needs the right data depends on someone knowing the data is there. Access frequency counts too, since a table queried constantly signals where a model should look first. "The team or the person building the functionality and AI may not have known about that data," Alvarez says. "But being able to have an MCP server or some sort of integration with an enterprise data intelligence layer allows you to find the data that you need, using role-based access control, so that those AI initiatives have a lot more weight and a lot more context."

Asked where accountability for the intelligence layer belongs, Alvarez names the security dimension first, which pulls the CIO and CISO in before the data organization takes it on. "The Chief Data Officer and an AI VP are kind of the two tag teams," he says. "The VP of AI helps with the infrastructure and building of that knowledge base using LLMs, but the Chief Data Officer surfaces all the data they need for each of those organizations."

Siloed data limits what any layer above it can return. An intelligence layer can only index the systems it can reach. "Unify your data silos, get an intelligence layer, and then have that additional context from your subject matter expertise, because they're the ones who understand the business, not the AI," Alvarez concludes.