Why enterprise AI pilots fail

Almost every organization is now using AI somewhere, and very few are getting paid for it. McKinsey's most recent State of AI survey found that 88 percent of organizations use AI in at least one business function, yet only 39 percent attribute any enterprise level EBIT impact to it, and most of those say the impact is below five percent of EBIT. MIT's NANDA initiative put it more bluntly: after an estimated 30 to 40 billion dollars of enterprise spending on generative AI, about 95 percent of pilots produced no measurable profit and loss impact.

That gap is not a model problem, because the models work. It is a decision problem, and most of the decisions that sink an AI initiative are made before anyone writes a line of code: which problem to pick, what data to ground it in, how to measure whether it works, who owns it when it misbehaves, and what happens to the workflow around it.

This guide is the pre-commitment checklist we wish every team had before their first AI budget line. It synthesizes what BCG, McKinsey, Deloitte, Gartner, RAND, MIT, OpenAI, and Anthropic have published about enterprise AI adoption, and it adds the production lessons that only show up after systems meet real users. It is long because the subject deserves it. Read it before the kickoff meeting, not after the post-mortem.

What the failure data actually says

Start with the numbers, because they discipline everything else. Several major studies have measured AI initiative outcomes, and they measure different things, which matters when someone quotes a scary statistic at you.

Three honest caveats. The RAND figure is RAND citing external estimates, not its own measurement. The MIT 95 percent measures pilots without P&L impact, which is a higher bar than "the project shipped." And Gartner's number was a prediction, though its follow-up research found that by the end of 2025 at least half of generative AI projects had in fact been abandoned after proof of concept.

The caveats do not change the picture. Every serious measurement, by every methodology, lands in the same place: pilots are easy and value is rare. BCG's segmentation is the most useful framing. Only 26 percent of companies have built the capabilities to get beyond proofs of concept. Only 4 percent generate significant value consistently, with another 22 percent beginning to. The other 74 percent are paying for AI and not yet getting paid back.

The derisking question is therefore not whether the model will work, because in a demo it usually will. What separates the 26 percent from the 74 percent is the better question, and the research is unusually consistent about the answer.

Why pilots fail: the root causes

RAND interviewed 65 experienced AI engineers and leaders and identified five recurring root causes of failure. In order: the organization misunderstands or miscommunicates the problem that needs solving, it lacks the data to make the system effective, it cares more about using the latest technology than solving a real user problem, it lacks the infrastructure to manage data and deploy models, and it points AI at problems the current technology cannot solve.

Notice what is absent from that list: the model itself. RAND's interviewees cited leadership decisions and expectations as the primary failure driver in 84 percent of cases. Wrong problem, inflated expectations, underestimated timelines, priorities that shift before the system can prove itself. RAND notes a fair caveat, that engineers may be predisposed to blame leadership, but the finding matches everything else in the literature.

MIT calls the same phenomenon the learning gap: organizations fail not because the technology is weak but because they cannot integrate it into workflows, structures, and culture. Tools that do not learn from feedback, do not fit how work actually happens, and do not improve after deployment get quietly abandoned, regardless of how impressive the demo was.

BCG quantifies the distribution of difficulty with its 10-20-70 rule. About 10 percent of the challenge is the algorithms, 20 percent is technology and data, and 70 percent is people and process. Companies that succeed allocate effort in those proportions. Companies that fail spend 70 percent of their energy on the 10 percent, which vendors have already mostly solved.

So the failure modes you are actually derisking are these five, in plain language:

1. Wrong problem. The use case was chosen by enthusiasm, not by value or fit.
2. No ground truth. Nobody can say what a correct output looks like, so nobody can measure quality.
3. No data. The documents, labels, or context the system needs do not exist, are stale, or cannot legally be used.
4. No production path. The pilot lives in a notebook and the organization has no infrastructure for evals, observability, or controlled rollout.
5. No workflow change. The system ships, the surrounding process stays identical, and adoption quietly dies.

Everything that follows in this guide is a countermeasure to one of those five.

Readiness before roadmap

The instinct after an executive offsite is to write a use case roadmap. Resist it for two weeks and run a readiness audit first, because the audit changes the roadmap. Readiness for LLM based systems has six dimensions, and a weak score on any one of them shapes which use cases are safe to attempt.

Data readiness, redefined. In the classic machine learning era this meant training data. For LLM integration it mostly means retrieval data, because the dominant grounding pattern is RAG: the model answers from your documents rather than from its weights. So the questions change. Are the documents that contain your institutional knowledge accurate, current, and deduplicated? Do they carry access permissions the retrieval layer can enforce? Is there one authoritative version of each policy, price list, and procedure, or do four conflicting versions live in four systems? An LLM grounded in contradictory documents will answer confidently and inconsistently, and users will correctly stop trusting it. We wrote a full guide on this failure class: Why RAG Systems Fail in Production.

Ground truth capacity. For each candidate use case, can a domain expert look at an output and judge it correct or incorrect in under a few minutes? If not, you cannot build evals, and a use case without evals is a use case you cannot derisk. This single test eliminates more bad use cases than any prioritization framework.

Workflow clarity. Can you draw the current process the AI is supposed to improve, with its inputs, outputs, exceptions, and owners? RAND's first root cause, the misunderstood problem, almost always traces back to a workflow nobody actually mapped.

Security and compliance posture raises three questions: what data the model is allowed to see, where it may be processed and under which jurisdiction, and who reviews outputs that leave the building. If legal and security learn about the project at launch, the project will relaunch later and slower.

Engineering capability. Production LLM systems need people who can build evaluation harnesses, retrieval pipelines, guardrails, and observability, not just call an API. Be honest about whether that capability exists in house today, because the build versus buy decision below depends on it.

Executive sponsorship and patience. McKinsey's correlation analysis across 25 organizational attributes found that CEO oversight of AI governance was among the factors most correlated with bottom line impact from AI. Sponsorship is measurable: is there a named executive owner, a budget that survives one disappointing quarter, and an agreed definition of success?

Score yourself honestly on all six before debating use cases. If you want a structured starting point, we built a free AI readiness assessment that walks through these dimensions and maps the result to the kinds of use cases your organization can responsibly attempt today.

Choose fewer use cases, and choose forgiving ones

The single most counterintuitive finding in BCG's research: AI leaders pursue about half as many AI opportunities as everyone else, scale more than twice as many products from the ones they do pursue, and expect more than twice the return. Breadth is the failure pattern. The 50 item use case backlog signals ambition to the board and guarantees that nothing gets the engineering depth needed to reach production.

Pick a small number, three is plenty for a first wave, using three filters in order.

Value comes first, meaning time saved, revenue enabled or risk reduced, in numbers someone in finance would sign. If you cannot quantify it roughly you cannot later prove it happened, and unproven value gets initiatives cancelled. Gartner's stated reasons for the abandonment wave are poor data quality, inadequate risk controls, escalating costs and unclear business value, and two of those four are measurement failures rather than technology failures.

Feasibility comes next: does ground truth exist, does the data exist, and is the task within what current models do reliably? RAND's fifth root cause, pointing AI at problems it cannot solve, is entirely preventable at selection time.

Blast radius is the third filter, and it asks what happens when the system is wrong rather than if. Every LLM system has a nonzero error rate, and derisking asks whether the workflow absorbs those errors cheaply.

The top left quadrant, high value with cheap errors, is where first wave use cases belong: drafting that a human reviews, triage that routes rather than decides, summarization with links back to sources, internal research assistance. A system that is right 90 percent of the time is a liability in the top right quadrant and an asset in the top left, purely because of what surrounds it.

One more selection principle: prefer workflows over agents for the first wave. A workflow calls a model inside a path your code defines. An AI agent lets the model choose its own next action, which buys adaptability and costs predictability. Anthropic's own guidance on building effective agents says to find the simplest solution possible and only add autonomy when the task path genuinely cannot be scripted. We cover the full decision in The Practical Guide to AI Agents.

Build, buy, or partner

MIT's GenAI Divide report contains the most quoted derisking statistic of the cycle: externally purchased tools and partnerships reached deployment about 67 percent of the time, while internally built tools succeeded only about a third as often. The lesson is not "never build." The lesson is that most organizations underestimate what building means, because the model call is 10 percent of the system and the other 90 percent is retrieval, evals, guardrails, observability, and integration.

Two warnings for the buy column. First, Gartner estimates that of thousands of vendors marketing agentic AI, only about 130 offer substantial agentic capability; the rest are rebranded chatbots and RPA, a practice Gartner calls agent washing. Ask vendors for their eval results, their hallucination rates on your document types, and a pilot scoped to your data. A vendor who cannot show evals is selling you a demo. Second, check integration depth: MIT found the tools that survive are the ones that embed into existing workflows and improve with feedback, not the ones that open in yet another tab.

And one warning for the build column: the question that decides it is not "can our team call the API," it is "can our team build the evaluation and observability layer that makes the system trustworthy." If the answer is not yet, partner first and build the capability alongside. That is the model we run at BigCircle: our engineers ship the production system and your team inherits the eval harness, the runbooks, and the skills, so the second use case is yours to build.

For anything customer facing or high stakes, also ask who carries the liability for wrong outputs, in the contract, not in the slideware.

Plan for hallucination, because it is a property, not a bug

Large language models generate plausible text, and most of the time plausible and true coincide. Sometimes they do not, and the result is hallucination: fluent, confident, wrong. No model version removes this, because it is a statistical property of how these systems work, and your architecture either accounts for it or inherits it.

The data says this is the risk that actually bites. In McKinsey's latest survey, 51 percent of organizations using AI report experiencing at least one negative consequence, and inaccuracy is the most common, reported by nearly a third of all respondents. Organizations now actively mitigate an average of four AI risks, up from two in 2022, so the industry is learning, but inaccuracy keeps leading the table.

Treat reliability as an engineering budget with five line items.

Grounding. Constrain the model to answer from retrieved, cited sources rather than from memory. This is the core argument for RAG in enterprise settings: not that it makes models smarter, but that it makes answers checkable. Citations users can click change hallucination from invisible to auditable.

Constrained output. Wherever the output feeds another system, use structured output with schemas instead of free text. A wrong value in a typed field is detectable by code. A wrong sentence in a paragraph is detectable only by a careful human.

Confidence routing. Not every query deserves the same treatment. Route easy, well covered queries to the fast path and ambiguous or out of scope queries to a stronger model or to a human. The system saying "I cannot answer that from the documents I have" is a feature, and you have to design for it explicitly, because the model's default is to answer everything.

Human review tiers match review intensity to blast radius. Internal drafts can ship with spot checks, customer visible answers get sampled review with feedback loops, and anything contractual or regulated gets approval before sending. Write these tiers down before launch, because adding review after an incident is how AI programs end.

Output guardrails are programmatic checks that run on every response: does the answer cite a real document, does it stay inside the permitted topic scope, does it leak data the user should not see, does it contain commitments the company has not approved. Guardrails do not make the model honest, they make dishonesty cheap to catch.

Evals are your primary derisking instrument

If you take one operational practice from this guide, take this one. The first lesson in OpenAI's own enterprise guidance, AI in the Enterprise, drawn from its largest deployments, is: start with evals. Not with prompts, not with a vendor shortlist. Evals.

An eval is to an LLM system what a test suite is to software: a versioned, repeatable measurement of whether the system does what you need on the cases that matter. Without evals, every model upgrade, prompt edit, and retrieval change is a gamble, and every quality debate is two people trading anecdotes. With them, AI development becomes boring in the best sense: change, measure, compare, ship or revert.

A practical eval stack for an LLM integration has four layers.

1. A golden set. 50 to 200 real cases from the actual workflow, each with an expert verdict on what a good output contains. Building this is unglamorous and is the single most valuable week of the entire project. It also forces the ground truth conversation that RAND found most projects skip.
2. Automated grading. Deterministic checks where possible: did the answer cite the right document, is the extracted field exactly right, did the format validate. For subjective qualities, LLM as judge grading works, with one rule: calibrate the judge against human verdicts on a sample before trusting it, and re-calibrate when models change.
3. Pre-deployment red teaming. Adversarial testing before users do it for you: prompt injection attempts, off topic requests, attempts to extract other customers' data, the angriest customer message your support team has ever seen.
4. Online monitoring. Production observability: trace every request, sample outputs for ongoing review, track correction rates and escalation rates, and watch unit cost per task. Quality drifts as data, users, and models change, and only instrumented systems notice.

Evals also answer the procurement problem from the build versus buy section. The same golden set that grades your build grades a vendor's demo, and running it during the sales cycle is the fastest honest signal you can buy.

Security and the new attack surface

LLM integration creates attack surface that traditional application security does not cover, because the system's instructions and the system's data travel in the same channel: text.

The canonical risk is prompt injection, number one on the OWASP Top 10 for LLM applications. Any text the model reads, an email, a support ticket, a webpage, a PDF, can contain instructions that try to override yours: ignore your guidelines, reveal the data you were given, send this to an external address. This is not exotic. It is the everyday consequence of feeding untrusted text to a system that follows textual instructions, and it has no complete fix today. Mitigation is structural: separate trusted instructions from untrusted data, never let retrieved content authorize actions, and put hard limits on what the model can do regardless of what it reads.

Which leads to the central rule of LLM security: enforce permissions outside the model. If the system can take actions through tool calling, every tool needs least privilege scoping, read and write separation, and human approval for irreversible operations. The prompt that says "you must never issue refunds above 100 dollars" is a wish. The API that rejects such refunds is a control. Protocols like MCP make connecting tools to models dramatically easier, which is exactly why tool governance, knowing what is connected to what, with which credentials, now belongs on the security review checklist.

Round out the surface with three more items. Data leakage: decide which data classes may reach which model providers, pin processing regions, and turn off training on your data in vendor agreements, then verify it. Shadow AI: employees are already pasting company text into consumer chatbots; the fix is providing a sanctioned alternative quickly, paired with clear policy, because prohibition without alternative just hides the usage. And data poisoning: if your system learns from documents or feedback at scale, ask what happens when someone malicious contributes to that corpus deliberately.

Governance that regulators will recognize

AI governance has a deserved reputation for theater, meaning committees that meet quarterly to approve nothing, and the evidence says the opposite of theater is valuable. McKinsey's analysis of 25 organizational attributes found CEO level oversight of AI governance among the factors most correlated with EBIT impact from AI. Governance done properly is not a brake, and it lets you ship faster because the approval path is known in advance.

The regulatory floor is now concrete, and as of mid 2026 it looks like this.

Note the May 2026 development, because much published advice predates it: EU legislators provisionally agreed to push the high risk compliance deadlines back by roughly 16 months, while adding new prohibitions and accelerating transparency rules for AI generated content to December 2026. If you sell into Europe, somebody on your team should own tracking this as it finalizes.

For most mid market organizations, sufficient governance is four artifacts, not forty.

1. A system inventory. Every AI system in use, including embedded vendor features, with its owner, data access, and risk class.
2. A risk classification rule. A simple tiering, low, medium, high, keyed to blast radius and data sensitivity, that decides how much review each use case needs. Borrow the EU AI Act's risk logic even where it does not legally apply; it is a sane taxonomy.
3. A pre-deployment gate. Evals passed, red team done, guardrails in place, rollback plan written, named owner assigned. One page per system.
4. An incident path. Who gets told when the system produces a harmful output, what gets logged, what triggers shutdown. McKinsey's finding that explainability is among the most experienced risks but not among the most mitigated is exactly the kind of gap an incident path closes.

Cost, ROI, and the lock-in question

AI initiatives die of cost surprise as often as quality failure. Gartner lists escalating costs among the top reasons for project abandonment, and the pattern is consistent: the pilot costs little, then usage scales, context grows, and the inference bill compounds monthly.

Derisk the economics with unit math from day one. Define cost per task, the all-in inference spend divided by completed units of work, and track it next to your quality metrics. Then use the levers, roughly in order of effort. Right size the model: frontier models for hard reasoning, small fast models for classification and extraction, decided by evals rather than by vibes. Add model routing so easy cases take the cheap path automatically. Use prompt caching for repeated context, which can cut the cost of long shared prompts dramatically. Trim what you stuff into the context window, because tokens are the meter that is always running. And only reach for fine-tuning or distillation when prompting and retrieval have plateaued on a measured eval, not as step one. The mechanics behind these levers are covered in How LLM Inference Actually Works.

On ROI, set expectations honestly, because the data is sobering. Deloitte's latest State of AI survey of 1,854 executives found only 15 percent report significant measurable ROI from generative AI today, with 38 percent expecting it within a year of investing. S&P Global found 46 percent of GenAI adopters report no single enterprise objective strongly improved. The implication is not that returns are imaginary. It is that returns follow workflow integration and measurement, which is precisely the work most pilots skip. Define the ROI metric and its baseline before building, instrument it, and review it at a fixed date with pre-agreed kill criteria. A killed pilot with a clear reading is a cheap lesson. A zombie pilot is an expensive one.

On vendor lock-in, the practical view: model capability is commoditizing at the frontier, with multiple providers leapfrogging each other every few months, so the binding lock-in is rarely the model API, which is a few hundred lines to swap. The durable asset and the durable dependency is everything around it: your golden sets, your retrieval pipeline, your guardrails, your traces. Keep those in your own stack and portable, run your evals against a second provider quarterly so switching stays a real option, and be more cautious with proprietary fine-tunes and deeply vendor specific orchestration than with raw API usage.

The 70 percent: people and process

Return to BCG's 10-20-70 rule, because it is the most actionable statistic in this guide: 70 percent of the challenge is people and process. The organizations capturing value spend their effort there. The 74 percent without value to show treat AI adoption as a procurement exercise and skip the operating model entirely.

What the 70 percent looks like in practice:

Redesign the workflow, not just the tooling. McKinsey found that fundamental workflow redesign has the biggest effect of any attribute on whether AI delivers EBIT impact. If the process after deployment is identical to the process before, with an extra AI step bolted on, you bought software, not an outcome. The redesign conversation, what stops being done, what gets reviewed instead of produced, what the freed hours go toward, is the conversation most initiatives never have.

Put the system in expert hands first. MIT found adoption succeeds when line managers and frontline experts drive it, not only a central AI lab. Your best underwriter, support lead, or analyst will discover failure modes and use cases no central team can.

Train for judgment rather than for prompts, because the skill users need is calibrated trust rather than prompt phrasing. That means knowing what the system is reliable for, how to verify its claims, and when to escalate. Build it with examples of the system being wrong, not just a highlight reel of it being right.

Measure adoption like a product, tracking weekly active use, correction rates, time saved per task, and what users do with the time they save. Deployment is not adoption and adoption is not value, so each of the three needs its own number.

Tell people what it means for them. Ambiguity about whether the tool is a colleague or a replacement kills adoption quietly. The teams that adopt fastest are the ones told plainly what the tool changes about their job and what it does not.

Agentic AI: where ambition outruns controls

The current frontier, and the current bubble, is agentic AI: systems that plan and act through tools rather than just answering. The strategic data points are striking in combination. Deloitte finds 74 percent of executives expect their companies to be using AI agents at least moderately by 2027, while only 21 percent say they have a mature governance model for agentic AI today. McKinsey finds 62 percent of organizations experimenting with agents but no single business function where more than 10 percent have scaled them. And Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear value, and inadequate risk controls.

Read those three together and the derisking posture writes itself: the upside is real, the timeline is hyped, and the governance gap is the actual risk. Agents multiply every risk in this guide because an AI agent that hallucinates does not just say something wrong, it does something wrong, and a compromised one can be steered by prompt injection embedded in the content it reads.

The derisking rules for agents are an extension of everything above. Do not deploy an agent where a workflow suffices; autonomy is a cost, spent only where the task path genuinely cannot be scripted. Enforce permissions outside the model with least privilege tools and approval gates for irreversible actions. Roll out in three stages, shadow, assist, act, where the agent first proposes silently, then proposes visibly, then acts within a narrow boundary it must earn evidence to expand. And budget every run: steps, tokens, time, and spend, because an agent without budgets is an unbounded liability attached to your systems. The full playbook is in The Practical Guide to AI Agents.

A 90-day derisking sequence

Strategy documents do not derisk anything, and shipped thin slices with measurement do. What follows is the sequence we run with clients, compressed into a single quarter.

Weeks 1 to 2 are for auditing and selecting. Run the six dimension readiness audit, then shortlist three use cases through the value, feasibility and blast radius filters. Pick one, the most forgiving one with real value, and write a one page brief: the workflow today, the workflow after, the metric, the baseline, the kill criteria.

Weeks 3 to 4 put ground truth before code. Domain experts build the golden set while engineering sets up the eval harness and tracing, and security and legal review the data flows now rather than at launch. If the golden set proves impossible to build, you have just saved a quarter: the use case lacked ground truth, which is the second root cause on RAND's list.

Weeks 5 to 10: thin slice in shadow. Build the narrowest end to end version: real data, real retrieval, real guardrails, no users yet. Run it in shadow against live cases, grade outputs against the golden set weekly, and red team it before any human sees it in their workflow. Resist scope. Every feature added before quality is proven is risk, not progress.

Weeks 11 to 13 are a limited rollout and an honest reading of it. Ship to a small expert group in assist mode, then measure quality, adoption, correction rate and unit cost. At the review, three outcomes are all wins: scale it with evidence, fix the named gap and re-test, or kill it and take the documented lesson into use case two. The only loss is the zombie pilot that survives without a verdict.

This sequence works because it front loads the cheap failures. The wrong problem dies in week two on paper, not in month nine in production. By the end of a quarter you have either a system earning trust or a precise, inexpensive lesson, and either way you have built the eval and governance muscle that every subsequent use case reuses. That compounding is the real output of the first 90 days.

The questions to settle before you sign anything

A closing checklist. If your team can answer all twelve in a sentence each, your AI initiative is better derisked than the large majority described in the failure statistics. If three or more draw blanks, that is the work to do first.

1. What specific workflow does this change, and who owns that workflow today?
2. What is the metric, the baseline, and the number that counts as success?
3. What does a correct output look like, and who can judge one in under five minutes?
4. Do the documents and data this system needs exist, and are they accurate and access controlled?
5. What happens when the system is wrong, who catches it, and what does the catch cost?
6. What is in the golden set, and what eval score gates the launch?
7. What can the system see and do, and what enforces those limits outside the model?
8. Which risk tier is this, which regulations touch it, and who approved it?
9. What is the cost per task today, and what is the path if usage grows tenfold?
10. How do we switch model providers, and when did we last test that this is true?
11. What changes in the team's process after launch, and who is telling them?
12. What are the kill criteria, and what date is the verdict?

The pattern across the research is uncomfortable but useful: the organizations capturing value from AI are not the ones with better models, bigger budgets, or earlier starts. They are the ones that picked fewer problems, defined what correct meant, measured relentlessly, governed visibly, and changed the work around the system. None of that is glamorous. All of it is learnable, and most of it costs less than a single failed pilot.

That discipline, evals first, guardrails outside the model, thin slices that earn their rollout, is the entire reason BigCircle exists. Our engineers build production AI systems this way for a living, and you can see the receipts in our work. If you want a grounded read on where your organization actually stands before committing budget, start with the free AI readiness assessment, or just talk to us about the use case you are weighing. Bring question twelve. We will help you answer the other eleven.

Production takeaways

• Run the readiness audit before the use case roadmap, because the audit changes the roadmap.
• Pursue fewer use cases. BCG found AI leaders chase about half as many opportunities and scale more than twice as many.
• Filter candidates on value, feasibility and blast radius, in that order.
• Buy or partner before building in-house. MIT put external tools at roughly 67 percent deployment against 33 percent for internal builds.
• Treat hallucination as a property of the system rather than a defect the next model version removes.
• Evals are the derisking instrument. Without them a team cannot tell a real improvement from a lucky demo.
• Seventy percent of the difficulty is people and process, and the failing organizations spend seventy percent of their effort on the algorithms instead.
• Set unit economics on day one. Cost surprise kills as many initiatives as quality failure.