A pilot demo, in most enterprises, ends with applause. Twenty-five queries scrolled across the boardroom screen. The model answered all twenty-five. The CFO nodded. Someone clapped. The slide deck closed with "next steps" and a thank-you.
Twelve months later, the same project is a ZIP file on a senior engineer's laptop. The steering committee is meeting again, but the meeting is now about why the AI strategy "did not deliver." Nobody in the room asks to see the twenty-five queries.
This is not a bad-luck story. It is the modal outcome.
McKinsey's QuantumBlack team published an essay in April 2026 on what they call the future-proof enterprise agentic platform, and it opens with a single statistic, dressed as a paradox: widespread adoption, limited measurable impact. The number that travels with the paper is starker. Ninety-five percent of enterprise AI pilots fail at the deployment phase. Not at the model. Not at the demo. At the part where the system has to live inside the business.
We have shipped seven deep-dives on cmdev over the last six weeks, each one a slice of the same problem from a different angle. This piece is the connective tissue between them. Five reasons enterprise AI deployments collapse between the demo and the desk — each one mapped to an engineering pattern we have published in detail.
Key takeaways
- McKinsey's gen-AI paradox: 95% of enterprise AI pilots fail at the deployment phase. Not at the model, not at the demo — at the part where the system has to actually live inside the business.
- The five failure modes are boring, not exotic: eval scored at vibe quality on a curated demo set, day-two reliability never engineered, knowledge bases leaking across permission boundaries, architectures that cannot survive the security review, and unit economics that only worked in the pilot environment.
- Each failure is preventable with a specific engineering pattern shipped in advance — distribution-aware eval harnesses, drift monitoring and kill switches, RBAC-integrated vector filtering, air-gapped Bedrock from sprint one, cost models on production volume with cascade routing.
- The connective tissue is the same in every failure: the demo was a system out of context — no security review, no production input distribution, no IAM model, no cost ceiling, no day-two failure surface to push back. Production is the moment all five push back at once.
- A pilot that only works in the demo environment is not a 90%-finished system. It is a 0%-finished system that runs in one specific lab. The engineering ahead is not the last 10% — it is the actual work.
The boring middle of the breakage
The failure modes are not exotic. They are boring. That is what makes them dangerous — they do not look like risks until you are halfway through the migration window and the timeline has slipped twice.
The eval suite was a glamour shot
A pilot demo runs on a curated input set. Twenty-five queries the engineer hand-picked because they show the model at its best. Three reviewers nod. The system advances to staging. This is not evaluation. This is a glamour shot — picked the way an estate agent picks the angle of the kitchen photograph.
Production sees a different distribution. The long tail of edge cases — adversarial prompts, malformed PDFs, ambiguous policy questions — never made it into the demo set because they did not photograph well. The model's answer-quality on the demo set was ninety-two per cent. Its answer-quality on the real-world distribution is sixty-one. Nobody knows this for six weeks because the eval suite is still the demo set. By the time someone runs an honest distribution test, customer trust is already gone.
The pattern that prevents it is a programmatic evaluation harness scored against the production input distribution, not the demo one. Faithfulness, citation accuracy, LLM-as-judge across stratified buckets — the eval suite treated as a production artefact, version-controlled, regression-tested on every deploy. The architecture sits in Beyond the API: Custom Evaluation Frameworks for Enterprise LLMs.
Day two was a hope, not a design
Demos run on the happy path. Production runs into a different weather system entirely. Retrieval returns three near-duplicate chunks and ranks them wrong, sending the model into a hallucination spiral. A prompt injection lodged in an uploaded PDF reroutes the agent into an action it does not have permission to take. The model provider quietly deprecates a version, and your eval suite misses the regression because it was checking the wrong thing. A new prompt turns a two-hundred-token job into a four-thousand-token one, and the cost graph climbs for a week before anyone notices.
None of these are exotic. They are the modal failure pattern after the second sprint in production — like commercial aviation, where the dangerous moments are not the takeoff and the landing but the slow accumulation of small things going slightly wrong in cruise. You do not survive cruise with optimism. You survive it with instruments.
The pattern that prevents it is day-two operational design baked in from sprint one. Drift monitoring. Structured logging on every model call. Kill switches wired to specific failure signatures. Evaluation triggered on every model-version change. The shape lives in Mitigating Non-Deterministic AI Failures in Production Systems.
The knowledge base became a sieve
The demo retrieves from a single corpus. Beautiful. Twelve weeks later the corpus has quietly ingested HR policies, legal contracts, M&A drafts, and regulator filings. The model is now retrieving from all of it for every user, regardless of clearance. Think of it as a library where the rare-books room never installed a door — anyone wandering the stacks finds whatever the shelves happen to hold.
A junior analyst asks an innocuous question. The retrieval returns a chunk from the unreleased Q3 layoff plan. The model summarises it cleanly. The audit log shows the analyst's account was the principal. The CISO finds out from the analyst's manager. This is not security theatre risk. It is the most common reason audit-led enterprises kill AI rollouts before production.
The pattern that prevents it is strict RBAC mapped from the company's existing IAM directly into vector-store filtering rules, with metadata filtering applied before the embedding search, not after. The vector store never returns a chunk the requesting principal is not authorised to see. The architecture and the IAM Identity Center wiring are in Designing Strict RBAC for Enterprise Knowledge Bases.
The security review walked in and broke the chair
The pilot ran on public Bedrock endpoints because that is what the engineers had AWS Activate credit for. The information security review arrives six weeks before launch with a clipboard and a series of polite refusals. Bedrock public endpoints? No. Egress to model providers you do not control? No. Customer-managed keys on prompts and responses? Required. Forensic trail on every model invocation? Required. Auth via IAM Identity Center? Required. SSO into the agent dashboard? Required. CloudTrail data events on Bedrock? Required. VPC flow logs proving no leakage to non-AWS endpoints? Required.
The pilot architecture meets none of this. The team rebuilds for the security review. The launch slips by a quarter. The business sponsor goes quiet. The project enters the ZIP-file phase. This is the most expensive form of late discovery in enterprise software — the equivalent of building the house and then learning the foundations cannot hold the weight of the roof.
The pattern that prevents it is assuming the security review at the architecture phase, not the launch phase. PrivateLink, KMS CMK, audit-grade observability, IAM Identity Center as the only authentication path — all of it non-negotiable for regulated enterprise work, and bolting any of it on after a pilot is roughly three times the original engineering cost. The full architecture lives in The Blueprint for Air-Gapped LLM Deployments on AWS Bedrock.
The economics were a lab effect
The pilot ran on Sonnet for every query. The cost on the pilot dataset was reasonable. Production volume is forty times the pilot volume. The cost is now eight times what the business case projected.
The first engineering response is to cut everything down to Haiku. Quality regresses. The business sponsor escalates. The team adds caching layers, then a custom embedding tier, then runs into multimodal RAG cost economics nobody modelled. This is the single most common reason production AI gets paused: the unit economics never made sense, and the demo was the only environment they were ever true in. It is the same shape as a chef who quotes a menu price from a tasting batch and then has to feed three hundred covers a night without doubling it.
The pattern that prevents it is modelling the cost shape against the production input distribution before the architecture is committed. Model-tier cascade — Haiku for the routing, Sonnet for the reasoning, Opus for the edge cases — like a triage system in a busy emergency department, sending most patients to the right station first. Prompt caching designed in, not retrofitted. Storage tiering for the multimodal corpus tuned to the cold-warm-hot access pattern of actual queries, not the demo's. The full cost-shape modelling is in Optimising Cold-Start Latency and Cost of Multimodal RAG Pipelines, and the cascade pattern is laid out in the Bedrock series cost-optimisation piece.
The shape beneath the five shapes
Read those five failure modes together and a single shape emerges from underneath them.
In every case, the demo was a system out of context. It ran without the security review, without the production input distribution, without the IAM model, without the cost ceiling, without the day-two failure surface. The pilot succeeded because nothing it would eventually encounter was actually there to push back. Production is the moment all five push back at once.
This is also the operating definition of what an enterprise AI deployment engineer actually does. Not training models. Not orchestrating prompts. The job is keeping the system standing under simultaneous contact with security, data quality, eval drift, cost, and stakeholder politics — which is to say, contact with the real institution. The job is closer to a bridge engineer than a model engineer. The model is the steel; the bridge is everything that keeps the steel from falling into the river when the traffic and the wind and the temperature change all at once.
McKinsey calls this the glue layer — the interoperability and governance fabric that connects a prototype to a business with policies, auditors, and a CFO. Their argument is that the failure happens because most pilots are built to demo, not to integrate, and that the difference is structural, not effort.
We agree. We would put it more bluntly. A pilot that only works in the demo environment is not a ninety-percent-finished system. It is a zero-percent-finished system that runs in one specific lab. The engineering ahead is not the last ten percent. It is the actual work.
What the survivors have in common
The pilots we have seen ship to durable production all had four things in common before they left the pilot stage.
An honest eval suite on the production input distribution, with a regression budget defined and enforced. The security review architecture assumed from sprint one — PrivateLink, KMS CMK, IAM Identity Center, audit-grade observability — not retrofitted later. A cost model on production volume, with a cascade pattern and caching designed in. A day-two playbook with monitoring, drift detection, kill switches, and a defined escalation path before launch.
The pilots that did not have these — even when the models were better, the demos prettier, and the engineers sharper — are the ones now sitting in the ninety-five per cent.
If your enterprise AI programme is approaching the deployment gate, the question worth asking is not whether the model is good enough. The question is whether any of those four are real artefacts on someone's roadmap, or whether they are still phrases people say in meetings. That difference is the difference between a system that ships and a story your CTO tells next year about a failed initiative.
So before the next demo gets applause, ask which of the four artefacts is currently writable on a whiteboard — and which is still being mistaken for a conversation.
FAQs
Why does the eval suite need to track production distribution rather than a curated demo set?
Because the demo set was hand-picked to show the model at its best. Production sees the long tail — adversarial prompts, malformed PDFs, ambiguous policy questions — that the demo set never sampled. The eval gap between curated and production distribution is routinely 30 percentage points. Treating the eval suite as a production artefact, version-controlled and regression-tested on every deploy, is what catches this before the customer does.
What is "leaky RAG" and why is it the most common reason audit-led enterprises kill rollouts?
The vector store ingests HR policies, legal contracts, M&A drafts, regulator filings — and starts returning chunks to every user, regardless of clearance. A junior analyst asks an innocuous question and gets the unreleased Q3 layoff plan back as a summary. The CISO finds out from the manager. Strict RBAC mapped from the existing IAM into vector-store metadata filtering — applied before the embedding search — is the fix; the chunk the user is not authorised to see never enters the model's context.
Why is retrofitting the security review architecture so expensive?
Roughly three times the original engineering cost. PrivateLink, KMS CMK, audit-grade observability, IAM Identity Center as the only authentication path — each of these reshapes the network topology, the identity model, and the data flow. Bolted on after a working pilot, every existing integration has to be reworked. Assumed at the architecture phase, they are just the default shape of the system.
What is the cascade pattern and why does it fix the cost problem?
Cheap, fast models (Haiku) handle the routing and the easy cases; mid-tier models (Sonnet) handle the reasoning the cheap model could not; the expensive model (Opus) only sees the edge cases. Combined with prompt caching designed in (not retrofitted) and storage tiering tuned to the actual cold-warm-hot access pattern, the unit economics survive contact with production volume. Running everything through Sonnet is the most common path to a paused project.
What four artefacts should a pilot have before approaching the deployment gate?
An honest eval suite on production input distribution with a defined regression budget. A security-review architecture (PrivateLink, KMS CMK, IAM Identity Center, audit observability) from sprint one. A cost model on production volume with cascade routing and caching designed in. A day-two playbook with monitoring, drift detection, kill switches, and a defined escalation path. Pilots that have all four ship. Pilots that have phrases people say in meetings instead of artefacts on a roadmap are in the 95%.
Companion content
Each failure mode above is treated in depth in a standalone deep-dive:
- Beyond the API: Custom Evaluation Frameworks for Enterprise LLMs — the eval architecture that catches the production distribution gap
- Mitigating Non-Deterministic AI Failures in Production Systems — day-two monitoring, drift, kill switches
- Designing Strict RBAC for Enterprise Knowledge Bases — IAM-mapped vector store filtering, leak prevention
- The Blueprint for Air-Gapped LLM Deployments on AWS Bedrock — PrivateLink, KMS, IAM Identity Center, audit observability
- Optimising Cold-Start Latency and Cost of Multimodal RAG Pipelines — cost shape under production volume
- Cost Optimization on Amazon Bedrock — the cascade pattern and prompt caching
- Case Study: Compliance Automator — the open-source reference architecture that bakes the four patterns above into a runnable system
How to engage
We build the engineering layer enterprises actually need to clear the deployment gate — eval harnesses, air-gapped Bedrock architectures, strict-RBAC knowledge bases, day-two playbooks. Talk to us about your deployment at creativeminds.dev/contact, or fork the compliance-automator reference architecture and run a real diagnostic on your own pilot.