Enterprise AI Without the Hype: Lessons From Jet Engines

For ten years, I built software for jet engines.

In that world, one rule is never broken: a system that cannot explain its own decision does not fly. Every output traces to a source. Every decision survives an audit. "It usually works" is not an answer you are allowed to give — three hundred people are sitting behind it.

Then I joined McKinsey, advised large technology and telecom firms on their enterprise AI strategy, and watched them do the opposite. They deployed AI into their most consequential workflows — pricing, support, underwriting, compliance — with no source of truth and no audit trail.

Here is the answer this post is built on: enterprise AI does not fail at the model. It fails at the discipline layer — ownership, source of truth, and evidence — that the demo never shows you. The implication for any leader is direct. If you are judging AI by the quality of the demo, you are measuring the wrong thing, and the gap surfaces in production, where it is most expensive to fix.

Three forces explain that gap, and they are the spine of this post:

1. You are buying a business outcome, not a tool — and outcomes need context the model does not have.
2. The demo controls the context; production does not.
3. The fix is sequence — People, then Process, then Tools — the order aviation settled decades ago.

Related from the series: the buyer's-eye view of what leaders are actually buying when they say "enterprise AI".

What this post covers

The decision this post helps you make: whether a specific AI project is ready for a vendor conversation, or whether the real work is still upstream in your own organization.

• What you are actually buying when you buy "enterprise AI"
• Why the demo systematically understates the work
• The People → Process → Tools sequence, and why the order is non-negotiable
• The AI memory layer that makes answers trustworthy: truth, memory, audit
• A nine-question AI-readiness test to run before any vendor call

Enterprise AI is an outcome you buy, not a tool

When a leader says "we need to move on AI," they have named a technology, not a decision — and you cannot hold a vendor accountable to a technology.

Strip away the vendor language and every enterprise AI investment is really the purchase of one of four outcomes. The column that matters is the last one.

None of the right-hand column is a model feature. All of it is discipline the business has to bring before the AI arrives. Most vendor conversations skip it and go straight to the demo. That is the first mistake.

The demo lies because it controls the context

An enterprise AI demo looks clean because the context is staged: one cooperative user, a handful of curated documents, a narrow workflow, a friendly question. Your business is none of those things. It has conflicting documents, stale policies, permission boundaries, half-complete records, and exceptions that depend on human judgment.

A support demo shows an AI drafting a refund reply in four seconds. Production has to answer a different set of questions before that reply is safe to send:

• Which refund policy is current, and which version was superseded last quarter?
• Is this item final-sale, and does this customer's region carry a billing constraint?
• Is this user even allowed to see the account record the answer depends on?
• Does a manager need to approve the exception before it goes out?
• And if the customer disputes it next quarter, can you reconstruct exactly what the AI saw and why?

The demo answered none of those. That is not deception — it is the distance between a proof of concept and a system you can stand behind. In aviation we had a name for the staged version: a bench test. Passing it was table stakes. Nobody confused it with being cleared to fly.

Aviation solved this: people, then process, then tools

Here is what the aircraft industry settled forty years ago, and what I keep watching enterprises rediscover at great expense.

A safe system is not a better machine. It is the right people, running a rigorous process, who happen to use a certified tool — in that order. The tool is the last and least interesting part.

Enterprise AI has that order exactly backwards. The headline says buy the tool. The reality is three levers that only work in sequence.

People — first. Who owns this workflow? Who owns the source of truth it depends on? Who is accountable when the answer is wrong? If those roles are informal or contested today, no model resolves that. It only automates the confusion at scale.

Process — second. What does a correct answer look like? What triggers human review? Where is the AI allowed to decide, and where must it escalate? In aviation this is written down before anything ships. In most enterprises it lives in one person's head.

Tools — last. Now, and only now, evaluate vendors. You have a named owner, a defined workflow, and a measurable success condition. The evaluation becomes an engineering decision instead of a demo reaction.

This is not the popular sequence, and tool vendors do not profit from it. But it is the line between AI that scales into the business and AI that stalls the day the pilot ends. Don't believe the headline: the tool fits on a slide, the discipline does not — which is exactly why it gets skipped.

Trustworthy answers need an AI memory layer: truth, memory, audit

People and process decide what the AI should do. The remaining question is how the system earns trust on every answer — and that is an engineering layer, not a prompt.

I call it the AI memory layer, and it has three parts. Each one answers a production question the demo dodged.

• Truth layer. One agreed system of record, kept current by managed ingestion. A draft policy and an approved policy can read almost identically; relevance alone will not tell the system which one wins. The truth layer does.
• Memory layer. Deterministic retrieval, scoped to the asking user's permissions. The same question should return the same context on two different runs, and never surface a record the user is not allowed to see.
• Audit layer. A receipt for every answer — which documents, which chunks, which permissions shaped it. This is what turns "the AI said so" into something you can defend to a customer, an auditor, or a board.

This is the part of enterprise AI governance that gets skipped because it is invisible in a demo and unavoidable in production. It is also the thing I left consulting to build. Inherent is a memory system for AI agents — the truth, memory, and audit layers as managed infrastructure — for teams tired of confident, generic, unverifiable answers.

Run this AI-readiness test before any vendor call

If your leadership team cannot answer these nine questions about a specific workflow in thirty minutes, you have an AI readiness gap — the project is not ready for a vendor. It is ready for a whiteboard.

1. What workflow should become faster, clearer, or more reliable?
2. What business outcome improves if the AI works?
3. Who owns this workflow today?
4. What does a correct answer or action look like?
5. Which sources decide whether the answer is correct?
6. Which one of those is the system of record?
7. Which permissions or approvals apply?
8. What evidence would we need if the answer were challenged?
9. What must the AI never do without human review?

The questions are simple on purpose. Their job is to surface the gaps that will break the project in production — before the contract is signed. If no one owns the source system, if the authoritative policy is unclear, if the approval path is informal, you have just found the real work. It is not a model problem, and a vendor cannot fix it for you.

What to do this week

Pick one AI project your organization is evaluating or already running.

Write the outcome in a single sentence: "We want AI to help [team] do [workflow] so that [business result] improves."

Then name the five sources that decide whether the AI's answer can be trusted. If those sources are stale, unowned, or permission-sensitive, that is the actual project. The technology decision comes after that map exists, not before.

If you want the engineering view of the truth-and-memory layer underneath all of this, read next: Production RAG Needs Truth and Memory.

Then write your one-sentence outcome and the five sources behind it. If you cannot finish the sentence cleanly, that is the most useful diagnosis you will get all week — it tells you exactly where the project really stands. DM Flow on X with the source that fails first. That failure is your real starting point.