Your AI Has
No Raw Material

So what he actually doesn't understand is something else: if all of that was already handed over, why does AI keep coming back with answers that aren't usable?

It's a fair question. But underneath it sits something nobody's gone back to check: having a lot of data, and AI actually having something to work with, are two different things.

01AI read every file you have

Say you actually do it. Feed AI three years of procurement records, every vendor's quotes, every contract, every acceptance form. Technically, this isn't hard anymore — the tools are everywhere.

Then you ask it a very practical question: for this batch, who should we order from this time?

It gives you an answer that looks thoroughly professional. Three vendors' quotes laid out side by side — Vendor A is lowest, seven percent cheaper than Vendor B. It attaches two years of order history, average lead times, the rate of acceptance issues. Every number checks out, every source is traceable to a file you gave it, and the logic holds together. The conclusion: go with A.

You take that conclusion to your procurement lead — fifteen years on the job. He looks at it for three seconds and says: no.

You ask why. What he says next, you won't find in any file.

The difference isn't that he saw more data than the AI did. It's the opposite — the AI saw far more than he did. It read three full years; he probably remembers a handful of things clearly. The difference is that he has something AI can't get its hands on.

That's exactly the problem. It's not that AI isn't smart enough. It's that the judgment simply doesn't exist anywhere in the terabytes you fed it.

02Systems store the outcome, not the reasoning

Open any award record at random and look at what fields it has.

Vendor name. Quoted price. Award date. Approver. Payment terms. Promised delivery date. Maybe a notes field that says "selected after price comparison."

Every single field answers the same kind of question: what happened.

Not one field answers the other question: why not the cheaper vendor.

The system faithfully records the outcome of every decision. Not one field is built to hold the reason behind it.

The version in that procurement lead's head goes roughly like this: the vendor with the lowest quote doesn't actually have the capacity for this volume. They're taking the order just to keep their machines running, and the moment peak season brings in more profitable orders, your batch gets pushed back. Push it once, that's two weeks. Push it twice, and your production line stops. The seven percent you'd save doesn't come close to covering one day of downtime.

That chain of reasoning has five links, and every single one is judgment, not data: underpriced bid to win the order → capacity gets reallocated to more profitable orders → your batch gets pushed to the back → the delivery date slips → your production line stops.

He wasn't born knowing this. He knows it because it happened to him exactly this way six years ago. Production stopped for three days that time, and he spent two hours in a room explaining himself. That experience stayed with him. It never made it into the system. All the ERP recorded that year was: delivery delayed, fourteen days later than promised. Why it was delayed, and what early warning sign to watch for next time — there was no field for that.

This isn't unique to your company. Every management system — ERP, CRM, inventory, project management — was designed for one purpose: recording what happened, so you can look it up later, reconcile the books, and trace accountability. They're excellent at this. "Explaining why" was simply never in their job description.

And that's exactly what AI needs.

This isn't unique to procurement, either.

A sales director glances at how a customer phrases a question and instantly knows whether this person is genuinely buying, or just gathering quotes for a competing vendor. A project manager looks at a schedule and can tell which milestone is scheduled a little too cleanly — cleanly enough to be impossible.

Ask them how they can tell, and the answer is almost always the same: you just... can tell. You learn it over time.

That's probably the real reason this kind of knowledge never gets written down. It's rarely a lack of time, and rarely anyone deliberately hoarding it. It's that the people who hold it don't even register it as knowledge — to them, it's just common sense, something anyone in this line of work should already know. Nobody writes a manual teaching people how to breathe.

So it just stays where it is — inside a handful of people, with no backup, no version history, no handover document. And it's leaving your company at the exact rate people retire each year.

03The layer that got skipped

This gap sits in a fixed spot within the system. One common way of breaking it into layers makes this clearest — not the only framework out there, but the one that shows most plainly which part is human work: a stack for enterprise AI, built up from the bottom, has roughly seven layers.

The bottom two layers ingest files and clean up formatting. Machines handle that. The top layers do retrieval and reasoning, producing the question-and-answer interface you actually see. Tools handle that. The middle layer turns knowledge into something AI can actually read — and only a human can do that.

Map that onto the procurement example and it's immediately clear. The three years of quotes, contracts, and acceptance records you fed in — those all stop at the bottom layer. The price comparison AI produced is the output of the top layers. And the thing the procurement lead said in three seconds — that belonged in the middle. That layer was empty, so it never made it into the analysis.

Most of what companies spend money on lands in the top layers: chatbots, AI assistants, smart customer service. Those are all good products, and they genuinely work. The problem is, once they're running, the raw material they need to read comes from that middle layer — and most companies simply don't have one.

So what you're getting back isn't garbage — it's a faithful summary of your own files. Your files only contain outcomes, so all it can hand back is an organized version of those outcomes. Your AI isn't malfunctioning. It's just being honest.

Why does this layer keep getting skipped? Because it's the only one that can't be outsourced to software. The bottom layers have tools. The top layers have vendors. Only this middle layer requires someone who genuinely understands the business to sit down and pull what's in their head out onto the page. There's no shortcut for this, and nobody sells it.

You've already bought everything that's for sale. The layer that isn't for sale is still empty. So the question was never whether to buy AI — it's whether anyone is willing to sit down and write the judgment out.

04Start with one person, one thing

The most dangerous reaction to hearing all this is to go announce a "company-wide knowledge audit."

Don't. You already know how that story ends: hold a kickoff meeting, send out a template, get one representative from every department, and three months later the files are sitting in a shared folder that nobody opens again.

The opening move should be small enough to start before you leave the office today: pick one person, pick one judgment call they make every week. Then ask three questions. Notice none of these three ask about process:

One: what's the last thing you rejected, and why? A rejection carries more information than an approval. Approving is often just "nothing looked wrong." A rejection always has a reason — and that reason is the judgment itself.

Two: what makes you feel "something's off" about a situation? This one digs out risk signals. A veteran's instinct is usually a specific, identifiable set of signals — they've just never listed them out.

Three: if a new hire took over this job, where would they most likely go wrong? This is the most useful question of the three. It forces the person to step outside themselves and turn something they've fully internalized as "common sense" back into something that needs explaining.

After those three questions, you'll end up with something that barely looks like a document: a handful of judgment principles, a few warning signals, a few cases where things went wrong. It won't be long — maybe two or three pages. In the procurement example, it might come out as something like this: if a quote comes in more than ten percent below the batch average, and the vendor treats you as a small account, require them to show this quarter's capacity schedule; if they can't, they don't make the final round. A threshold, a reason, and an action. A new hire following that won't fall into the same hole from six years ago.

You might be thinking: if three questions and two or three pages is all it takes, then this was never anything more than nobody having asked — what does it have to do with whether the system can store it?

The difference is scope. Back to the procurement lead — the thing he actually based his decision on was who else the vendor's machines were booked for this quarter. That's not your data. That's someone else's order book. No matter how finely your ERP fields are designed, no matter how clean your data is, that field will never exist, because it was never inside the boundary your systems can even see.

It can be written down precisely because right now it still lives inside one person. It was never left out of the system by accident, or because someone forgot to fill in a field.

One more thing needs saying clearly first, or these three questions won't get you honest answers. Veterans usually carry an unspoken worry: if I say all this out loud, what's left that's still mine? So before you ask, make the terms explicit: this isn't an evaluation, and writing it down won't become evidence that someone is replaceable. What actually tends to happen is the opposite — the person whose judgment gets documented moves from "everyone has to ask him" to "he's the one who sets the rule." This conversation is best held by the owner personally — not a form, not delegated to HR. Two or three pages, over the length of one cup of coffee, is enough.

A process standardizes actions. What you're writing standardizes judgment — not "how to do it," but "on what basis this decision gets made."

There's a distinction worth being precise about here, because it determines whether what you write actually does anything. Most companies have already written SOPs — operating manuals: step one, log into the system; step two, fill out the form; step three, submit for review. That kind of document standardizes actions, making sure everyone follows the same steps.

What you're writing now is a different kind of thing entirely. It standardizes judgment — making sure different people, facing the same situation, decide on the same basis. The first is a manual. The second is raw material.

One role, one judgment at a time. Once this one is working — once someone is actually using what got written down — add the next one. Only after this is done do you actually have something worth feeding to AI.

A lot of data isn't the same as having something AI can read

Back to what that owner said.

"We have plenty of data" is true. It just isn't an answer to the actual question. What he has is ten years of outcomes. What AI needs is the reasoning that produced those outcomes. The two look equally heavy sitting on a hard drive. To AI, they're not remotely the same thing.

So before you shop for a tool, there's a more fundamental question worth answering first: which handful of people are your company's most important judgment calls currently living inside?

You already have the data. What's left to build is everything that's never been written down.

Rooted in craft. Built for the new wild.