AI Transformation Is a Knowledge Problem

Every organization I work with wants AI. Almost none of them are actually held back by the technology.

The models are good. The tools are available. The budgets exist. What's missing is something quieter and harder to buy: the organization's own knowledge, in a form AI can use.

That's the part nobody puts on the slide. AI transformation gets sold as a technology problem. It's really a knowledge problem.

Processes tell you how work should happen

Walk into any mid-market retailer and someone can hand you a process document. Here's how we forecast. Here's how we handle a return. Here's how an order moves from placed to delivered.

Those documents describe how work is supposed to happen. They don't describe how it actually happens.

The person who's run demand planning for twelve years knows which SKUs lie to you in December. The order desk knows which customers always change their mind, so you sit on the order a day before you release it. None of that is in the process doc. It lives in someone's head. We call it tacit knowledge — judgment, experience, the exceptions, the unwritten rules.

Processes describe the workflow. Tacit knowledge explains the outcomes. AI needs both, and most organizations have only written down the first.

There are two ways to adopt AI. Most pick one.

The first is to hand your people better tools. Give the analyst, the planner, the merchandiser AI that makes them faster. That's real, and it's worth doing.

The second is harder and worth more: capture what those people know and turn it into something the whole organization can use. Not just a faster expert — a shareable one.

Here's what most people miss. These two reinforce each other. When an expert uses AI on real work, they have to make their thinking explicit. They correct the model. They say "no, not that customer" and "that number's wrong, it's the returns." Every correction exposes a rule, an assumption, a piece of judgment that was invisible five minutes earlier. Using AI surfaces the knowledge. Capturing the knowledge makes the AI better. The loop feeds itself.

Data analysis is the way in

If you want to find tacit knowledge, look at the data.

Data analysis is one of the best mechanisms we have for surfacing what an organization actually knows. A number looks wrong. A trend doesn't match what the team expected. You put a metric on a screen and someone says "that can't be right" — and then they tell you why. The why is the knowledge.

This is the part I want people to sit with. The value isn't the dashboard. It's the conversation the dashboard starts.

Every time a team reviews its numbers, you're watching decisions get made in real time. Why we treat this region differently. Why that's the number we trust and this one we ignore. Why "on time" means something different depending on who's asking. Those conversations are where the real business rules live. Most organizations have that conversation every week and capture none of it.

The analyst's job is changing

This changes what a data analyst is for.

The old job was reporting. Pull the number, build the view, send the deck. The new job is knowledge discovery. The analyst sits with the business, watches the anomalies, asks why, and writes down the answer. They turn what one person knows into something the organization owns.

That's not a reporting function. It's an organizational memory function — and it's one of the most valuable roles in an AI-era business, even though it rarely has that title yet.

You have to be embedded

You can't get this from a workshop.

Tacit knowledge doesn't come out in a two-hour session with sticky notes. People can't tell you what they know, because they don't know they know it. It only shows up in the work — in the exception, the override, the "actually, hold on." You find it by being there. By watching, iterating, and working alongside the team over weeks, not by interviewing them once.

This is why we work embedded. Not because it's a nicer engagement model. Because tacit knowledge is discovered, not extracted, and discovery takes proximity and time.

Context engineering is knowledge engineering

There's a lot of talk right now about prompts. How you phrase the request. How you structure the context.

That matters less than people think. The quality of an AI system depends far more on the quality of the knowledge behind it than on how cleverly you ask. A perfect prompt sitting on top of a definition nobody agrees on gives you a confident wrong answer.

Context engineering, done seriously, is organizational knowledge engineering. The prompt is the easy part. The hard part is having captured, agreed-on knowledge to put behind it.

Trust in AI starts with trust in your own knowledge

Before an organization can trust AI to act on its behalf, it needs shared definitions, metrics people believe, business rules everyone agrees on, and decision logic that's actually written down.

Autonomous AI on top of contested knowledge is just a faster way to be wrong. Get the knowledge trustworthy first. The autonomy comes after.

The future of AI isn't about replacing human expertise. It's about systematically capturing, scaling, and augmenting the tacit knowledge an organization already has.

So here's where I've landed. The goal isn't a handful of smarter individuals. It's an organization whose knowledge can be shared, reused, and made better by AI — instead of walking out the door every time someone retires.

Every organization wants AI. The ones that get there start by taking their own knowledge seriously.