Why enterprise AI stalls after the demo

Dana: Here’s a situation a lot of leaders will recognize. The AI demo went well. People clapped. Someone said, let’s roll this out. And then, a few months later, nothing has shipped, or it shipped and nobody uses it.

Marcus: And usually nobody can say exactly why. The model still works. The demo still works. It just never became something people rely on.

Dana: That’s the subject of today’s episode. We’re walking through a short paper from RJL Solutions by Richard White, called Why Enterprise AI Stalls After the Demo. Richard has led data and AI at McKinsey, New York Life, the Federal Reserve Bank of New York and Citigroup. I’m Dana.

Marcus: And I’m Marcus. A quick note before we start: we’re AI narrators. The script was written from the paper and reviewed by Richard. Everything we say comes from his published work, and the example we use is illustrative, not a client story.

Dana: So, Marcus. Start us off. Why does the demo work and the rollout stall?

Marcus: The paper’s opening line is the whole argument in one sentence: the demo proves a narrower claim than the one you are about to fund.

Dana: Narrower how?

Marcus: A demo proves the model can answer a question. It doesn’t prove the business has settled which information the AI may use, what that information means, who owns the work, or how the service gets supported. And the demo has hidden helpers. Someone picked the right documents. The presenter knows what every term means. And it often runs on a service account that can reach everything.

Dana: So the people in the room are quietly filling in the gaps.

Marcus: Exactly, and usually without noticing. Production takes those helpers away. Now the users expect consistent answers, and they can’t see the assumptions underneath. Picture an assistant that helps a claims examiner pull together the context on a case. In the demo, it returns a status and a procedure. Looks great. But in real use, the examiner needs the status of the right claim, a procedure that applies to that specific policy and date, and only information they’re actually allowed to see. A confident answer can hide a failure on any one of those.

Dana: So what should a team actually do with that?

Marcus: There’s a simple exercise in the paper that I’d recommend to anyone listening. Ask your team to trace one real request, from the user’s purpose, through the sources and controls, to the answer and the business outcome. Wherever the explanation turns into an assumption, the release still has work to do.

Dana: The paper’s subtitle names three things: information, authority and operating ownership. Then it adds value. Let’s take them one at a time. Information first.

Marcus: The point here is that AI can make messy information easier to consume, and it can also hide the mess behind a fluent answer. Take the claims example. A person connected to a claim could be the insured, the policyholder, a beneficiary, the employer or a representative. Link the wrong role to the case and you get a summary that’s coherent, and wrong.

Dana: That’s not a technology problem.

Marcus: No. The paper is clear that identifiers and relationship rules are business decisions, and they need an accountable owner. Same with metrics. Counting open claims needs an agreed status definition, a reporting date, a record grain, and a rule for reopened or transferred cases. And here’s a line I like: expanding the model’s context does not resolve a disagreement about which definition the business accepts.

Dana: So a bigger model doesn’t fix an argument between two departments.

Marcus: Right. That’s a decision for the business, not the model.

Dana: OK. Gap two, authority.

Marcus: This is about who is allowed to do what, all the way through the request. The paper makes a distinction that’s easy to miss: a user who’s allowed to read a case has not automatically authorized an agent to update it, issue a payment or contact a customer. So you identify both the caller and the agent, and you give the agent narrow tools, like a status lookup, rather than an open-ended query or update tool. And the paper calls out a specific risk: a document can contain text that tries to redirect the assistant. OWASP calls that indirect prompt injection. Retrieved content should supply evidence. It should never grant authority or change what tools are allowed.

Dana: How do you know the controls actually hold?

Marcus: You test the failures before release. What happens when access is revoked? When a source or policy service fails? When sources conflict? When a document asks for something unauthorized? The expected behavior for each is written down in advance. And you should be able to reconstruct one real request afterwards: who asked, which sources and versions, which policy decisions, which tool calls, and what happened.

Dana: Gap three, ownership. This one sounds like where most programs really get stuck.

Marcus: It often is. A pilot can deliver an interface while nobody has the authority to settle a definition dispute, change the business workflow, or fund maintenance. The paper lists five responsibilities that each need a named owner who can actually make the decision: the business process, the product lifecycle, domain meaning and data, security and controls, and service operation.

Dana: And you don’t need a reorganization to do that.

Marcus: No. The first capability can set up those relationships. Give the delivery team access to the decision holders, an escalation route and an agreed time frame. And record disagreements as decisions to resolve, instead of burying them in a technical backlog. The test of readiness is a good one: the receiving team runs the runbook without the builders in the room.

Dana: And the fourth gap, value.

Marcus: A pilot can get enthusiastic feedback without improving the business process, once you count review, corrections and exceptions. So the paper says to measure completed useful work at acceptable cost and risk, inside the workflow. Not response quality, and not how many people tried it. And time saved is available capacity. It only becomes a cash saving when staffing, overtime or purchased capacity actually changes. And count the full cost: model use, retrieval, integration, human review, support and keeping the information current, divided by completed useful tasks. An assistant can cut the time to draft an answer and increase the time to check it.

Dana: So if I’m a leader with a promising pilot on my desk, what does the paper tell me to do?

Marcus: The recommendation is deliberately narrow. Fund one complete governed workflow. That means a bounded capability with real users, approved information, enforced authority, measurable outcomes and continuing ownership. Deliver the information, the controls and the operating responsibilities together, then reuse what you proved in the next capability.

Dana: One, not ten.

Marcus: One. And choose it carefully: a valuable task with a business owner, identifiable users, accessible dependencies and a boundary you can test. The paper lays out four steps: frame the deciding constraints, prove the complete path with real data and real users, build and hand over the service, then make the next investment decision.

Dana: And that decision has three possible answers.

Marcus: Expand, reshape or stop. Expand when business results, control evidence and operating capacity support the next scope. Reshape when the workflow or the assumptions need to change. Stop when the value or the path no longer supports the investment. Making those three outcomes explicit means a pilot can produce a useful result even when the answer is not to scale it.

Dana: I like that. A stopped pilot isn’t automatically a failure.

Marcus: Not if it taught you something on evidence. The failure is the pilot that drifts for months with no decision at all.

Dana: If you take one thing from this episode, what should it be?

Marcus: Run the trace. Pick one real request and follow it from the user’s purpose to the business outcome. Every place where your team says “we assume” instead of “we know” is a piece of work between your demo and a capability people can rely on.

Dana: The full paper is eight pages, free, with no form to fill in, at rjlsol.com.

Marcus: And if you’d like to work through your own pilot, Richard offers a free sixty-minute working session. You leave with a one-page summary and three next questions. That’s at rjlsol.com.

Dana: Thanks for listening. I’m Dana.

Marcus: And I’m Marcus. This episode was narrated by AI voices, written from Richard White’s work and reviewed by him.