Why successful AI pilots do not yet prove enterprise value

Widespread AI use has not become enterprise-scale value

An AI demonstration can show that a task works while leaving the investment decision unresolved. Individual employees may save time, but expansion requires evidence that the whole operation improves business results. McKinsey’s 2025 global survey shows the gap between widespread use and enterprise impact, measured through earnings before interest and taxes, or EBIT. McKinsey sells advisory services, including help with AI adoption, so demand for AI strategy and implementation benefits its business.

Moving from experimentation to production also presents difficulties beyond generative AI, which creates content such as text and images. Gartner found that an average of 41% of generative AI prototypes reached production, compared with 42% of nongenerative AI prototypes. Gartner sells research and advice to technology buyers, giving it a commercial interest in helping organizations make these investment decisions. The similar production rates suggest both categories face deployment challenges: a successful pilot still leaves questions about how the organization will operate the system.

Scaling requires a business case for the whole workflow

Those deployment questions change how leaders should assess a pilot’s productivity gains. A scaling case needs to account for the return from the complete workflow, including controls, integration, validation, and ownership. Experimentation can move quickly because a small team selects inputs, handles exceptions manually, and judges outputs directly. In production, the organization must provide those conditions repeatedly during ordinary operations.

Repeated operation therefore changes the assessment across six dimensions: data, workflow, review, integration, evaluation, and access. A demonstration may show that an output is useful while leaving unresolved how current records reach the system, who may access them, who reviews the result, and how it returns to operational software. Each unresolved question creates work that someone must fund and own. Savings for one user can therefore create obligations elsewhere.

A better model can improve output quality or lower generation costs, but the workflow still needs dependable information, controls, evaluation, and clear authority. Before approving expansion, leaders need to identify who supplies the information, who accepts the output, and who responds when the system fails. These responsibilities determine whether the demonstrated task can become a repeatable operation. They belong in the business case because they affect approval, ongoing cost, and accountability.

Reliable output starts with dependable live data

The first operating requirement is information that remains usable when the pilot moves to live systems. The 2026 RSM Middle Market AI survey ranked data quality as the leading reported inhibitor, followed by security and privacy concerns. Legacy integration and talent gaps also featured prominently. RSM provides consulting services, including technology implementation support, so businesses investing in solutions to these problems represent a commercial opportunity for the firm.

Data preparation also appears in Gartner’s research and NVIDIA’s 2026 State of AI research. The findings concern different populations and questions, so each needs to retain its own scope. NVIDIA supplies AI computing hardware and software, and benefits commercially when organizations expand AI deployment.

Gartner’s abandonment forecast concerns projects without AI-ready data. For a funding decision, the question is whether the proposed workflow can obtain consistent, sufficiently current information under actual operating conditions. A pilot can leave that question unanswered by using a clean export, a selected knowledge base, or a small sample of tickets.

The gap becomes visible when an illustrative team connects its successful pilot to live systems containing duplicate records and incompatible definitions. Some information sits behind a fragile SOAP service, an interface for exchanging structured messages, while other records reside in a 15-year-old enterprise resource planning system. Work that took two weeks to prototype can then require a multi-quarter integration effort. The model’s task remains the same, but supplying its inputs has become a substantial engineering commitment.

That commitment changes what the demonstration has established. A prepared export can show that a model performs a task while leaving continuous access to comparable information unresolved. Teams with limited access or integration capacity therefore face a disadvantage when approval starts with a demand for a demonstration. Producing the proof may be straightforward even though reproducing its input conditions in production remains difficult.

Continuous access also requires agreement about what records mean. If two systems define the same customer differently, adjusting the prompt cannot establish which definition the business considers authoritative. Duplicate records can cause retrieval, the process of fetching relevant information, to return conflicting information, while outdated records can make a clearly written answer operationally wrong. Answer quality can therefore change even when the prompt stays the same.

To control that variation, establish an authoritative source for each important entity, such as a customer or account. Define a data contract: an agreement covering the structure and meaning of exchanged information. Keep the retrieved context current and set expectations for retrieval latency, the time needed to obtain the required records. These requirements make record meaning and access time predictable enough for the workflow to depend on them.

Predictable access must also survive changes to the systems supplying the records. When an upstream application changes a field or interface, applications using that information need a controlled way to keep operating. Maintaining the interface becomes part of delivery once AI connects to systems of record. That upkeep consumes engineering capacity and affects release planning throughout the system’s operation.

Governance determines permitted behavior

Dependable access raises the next operating question: which records may the AI system retrieve and use? Consider a support-agent copilot that works well in a sandbox but requires personally identifiable information, or PII, in production. Its suggestions need to be traceable, and someone must maintain its prompts, policies, and evaluations. These obligations affect both initial approval and continued operation.

Customer-response drafting shows how those obligations cross application boundaries. The system may combine a customer relationship management, or CRM, record with ticket history and then write a draft into a system of record. Approval therefore depends on which fields it may read, which information requires masking, and which records of prompts and outputs must be retained. Choosing a model leaves those access and responsibility decisions to the organization.

The organization can make these decisions open to inspection by expressing governance as operating requirements. Engineering and risk teams need to see the permitted behavior and the controls that enforce it before routine use begins. Each control also needs an owner who maintains it and responds when it fails.

These controls become especially consequential with agentic AI, systems that retrieve information, invoke software tools, and take actions across applications. Permissions limit their actions, while logs record what they actually did. Assigned owners then investigate and respond when an action causes a problem. Governance therefore needs to shape the architecture and its operation from the start.

Validation must continue after deployment

Permission to operate still leaves the question of whether the system behaves acceptably in its intended workflow. NVIDIA’s 2026 State of AI research found that 38% identified a shortage of AI experts as a leading challenge. RSM’s separate talent-gap finding concerns a different survey population. For an implementation team, staffing needs to include people who can test, judge, and maintain AI behavior during operation.

Without that capability, Security, Legal, and Risk struggle to determine whether the system meets organizational requirements. Unclear expectations also complicate incident response because people may disagree about whether an output was an error or intended behavior. Time pressure, incomplete test coverage, and limited access to representative data increase this uncertainty. A demonstration cannot settle the question if its examples omit failures that matter to the workflow.

An illustrative large language model, or LLM, drafting release notes from Jira records and pull requests shows the consequence. Pull requests propose code changes, and the generated summary may read well while omitting a breaking change that requires users to alter their implementations. Support then receives the resulting problems. Review time therefore becomes a budget decision because automating the draft leaves the checking work and its risks in place.

To make checking repeatable, assign an evaluation owner and define pass/fail thresholds based on the consequences of failure. Measures can include accuracy, groundedness (how well an answer is supported by its underlying records), response latency, and how often people override the system. The workflow’s risks and intended use should determine which measures matter. Validation then becomes recurring engineering work with an explicit staffing requirement.

Recurring evaluation needs a response process after release. When behavior drifts, meaning performance changes from the accepted level, the team must know what action a failed threshold triggers. A small group spanning product, engineering, security, and the domain owner can translate business risks into measurable checks. The group must update those checks as prompts, models, and policies change, because approval of one configuration does not establish continuing acceptability.

Measure the complete cost and fund the conditions for value

Recurring evaluation adds to the cost of the customer-support drafting workflow introduced earlier, alongside routing, redaction, quality-assurance sampling, and urgent correction of confidently incorrect drafts. Together, these activities can consume the time saved in drafting each ticket. The investment decision therefore needs a measure of the complete process. Measuring the automated step alone leaves the organization unable to judge its operational return.

The first development sprint after a demonstration may expose integration, review, and incident-handling work omitted from the pilot budget. Usage measures can obscure that change: prompts per day, demonstrations completed, and seats purchased show activity while leaving permission handling and human review outside the count. A heavily used system can therefore appear successful before its operating cost is understood. The business case needs to connect that activity to a defined outcome.

Research records this difficulty in assessing financial value. Project-manager responses in Q3 2025 research identified unclear return on investment, or ROI, and limited resources as obstacles to adoption. NVIDIA’s 2026 State of AI research separately found that 30% identified unclear ROI as a leading challenge. Both findings concern the difficulty of establishing a worthwhile return from implementation.

Gartner’s April 2026 research adds a spending comparison. Only 39% of surveyed technology leaders were confident that their current AI investments would improve financial performance. Organizations reporting successful AI initiatives invested up to four times more in foundations, as a percentage of revenue, than those reporting poor outcomes. Gartner included data quality, governance, people prepared to work with AI, and change management among those foundations.

The comparison concerns investment relative to revenue and reported outcomes; it does not establish that higher foundational spending causes success or compare absolute budgets. For a particular workflow, leaders still need to judge what the spending enables. Data preparation can support repeatable delivery, governance can permit approved use, and prepared teams can sustain the operation. These requirements consume resources while creating conditions in which the application can deliver value.

Funding those conditions is compatible with strict financial evaluation. Treating every foundational cost as an expense to reduce can undermine the workflow the organization intends to operate. Yet a well-prepared organization can still choose a poor use case. The decision must therefore account for both the necessary foundations and the value of the specific application.

Three strategic errors prevent that assessment. A team may choose an appealing application without connecting it to a measurable operational constraint. It may omit integration, review, monitoring, and exception handling from its estimate. Or it may leave the evidence for expansion, revision, or termination undefined, allowing activity to continue without a decision standard.

To establish that standard, begin with a known bottleneck and one primary outcome measure. Record a pre-AI baseline so the existing workflow and the proposed one can be compared using the same definition of success. The baseline gives time savings or quality improvements business meaning. It also makes clear which operational result the investment is intended to change.

With the result defined, decide which foundations to deliver this quarter and which work to defer. The next deliverable might be dependable data access, an evaluation harness (a repeatable setup for running tests), monitoring, or a review process. Choose it according to what the next meaningful test requires. This sequence makes the investment concrete and exposes the work needed before another release can be evaluated.

Before funding that release, agree on a kill gate: a decision point at which results are compared with predefined outcome and economic criteria, with authority to stop. The operating package should include bounded data access with logging, a dependable integration interface, staffed evaluation, and an accountable workflow owner. The funding request must explain how the organization will sustain these responsibilities alongside the feature. It should also state how the baseline and kill gate will govern the next decision.

Use those criteria to authorize expansion when measured workflow results justify the full investment. Revise when an identified change has a credible chance of improving the result, and stop when the workflow cannot meet the agreed outcome and economic requirements. This gives foundational spending a specific purpose: enabling a fair test of repeatable value. Applications that remain uneconomic after those costs are counted should end.

Clear responsibility gives employees a usable workflow

An accountable owner also needs to define how employees may use the system during consequential work. RSM’s 2026 Middle Market AI Survey found that 36% of organizations had AI fully embedded in core processes. Individual productivity gains can therefore occur while broader operating arrangements remain unchanged. Tool access alone leaves employees needing rules for reviewing outputs and acting on them.

Workflow redesign addresses that operating question directly. McKinsey’s 2025 research found that 21% of respondents using generative AI said their organizations had fundamentally redesigned at least some workflows. Among the organizational attributes McKinsey tested, workflow redesign had the strongest relationship with enterprise-level EBIT impact. The relationship does not establish causation, but it gives leaders a reason to examine how work is authorized alongside decisions about access.

When authorization remains unclear, avoidance and concealed use can occur together. Some employees decline tools whose risks they cannot resolve, while others use them outside supported oversight. Engineers may paste snippets into public chat tools, with security discovering the behavior afterward. This is shadow AI: use outside auditable, supported organizational processes, which can arise from the same missing rules that discourage visible adoption.

An illustrative on-call or support copilot shows how missing rules affect decisions during an incident. The tool recommends an action, but the operator cannot substantiate it because runbooks and escalation rules have not changed. Under pressure, the incident commander rejects the recommendation. Users may then judge the AI ineffective even though the workflow never established whether the recommendation was advisory, whether execution was permitted, or what evidence either decision required.

Resolving that uncertainty starts with permitted users, acceptable output, review responsibilities, and incident handling. Change-control and response processes must distinguish suggestions people may consider from actions they may execute. Runbooks and escalation routes need to reflect those decisions. Training can explain the resulting rules, but assigning authority and evidence requirements is an organizational responsibility.

A lightweight usage policy linked to data classes helps employees apply those boundaries during ordinary work. The workflow owner should be accountable for quality and adoption, so employees have a supported process for handling risk. When uptake is low, investigate whether that process is workable and authorized. Asking for greater enthusiasm leaves the responsibility gap unresolved.

Match the next intervention to the blocked release

The responsibility gap is one possible constraint, so the first intervention should follow the evidence about what is stopping delivery. Consider three pilots running in parallel: one keeps circulating through approval reviews, another fails when joining live records, and a third lacks a definition of success. Giving all three the same improvement program delays the work each needs. Their different symptoms require different starting points.

To choose a starting point, examine incident logs and SOC 2 audit findings, which come from an assessment of organizational controls. Identify the symptom, establish what prevents release, and select an intervention that addresses it. The five categories below provide a diagnostic structure; an individual pilot may face only some of them.

Use the diagnosis to select the smallest foundational change that enables a meaningful test in the next release. One team may need a stable interface before it can test live operation; another may need an evaluation owner before further development is useful. Teams with limited access, integration capacity, or validation staffing can then direct scarce effort to their specific constraint. The next funding request can name the blocked test, the intervention that enables it, and the person responsible for delivery.

Recap

A successful AI pilot establishes that a task can work under selected conditions. Expansion requires a different judgment: whether the organization can operate the complete workflow reliably and at a worthwhile return. That judgment must include the cost of supplying live data, maintaining controls, reviewing outputs, and handling exceptions.

For leaders, the next decision is therefore less about how quickly to scale AI than which constraint to resolve before committing more capital. A pilot blocked by inconsistent records needs a different investment from one awaiting access approval or lacking an agreed measure of success. Funding should address the specific barrier and produce evidence for the next decision.

Require each expansion request to name the accountable workflow owner, the outcome measured against a pre-AI baseline, and the full operating cost. Agree in advance on the results that justify expansion, revision, or termination. This gives teams room to learn without allowing experimentation to become an indefinite commitment.

Dependable foundations make a fair test possible; they do not guarantee a worthwhile application. Scale when measured results justify the complete investment, and stop when they do not.