Why Enterprise Leaders Hesitate on AI — and Why It’s Rational
Enterprise IT, HR, and finance leaders have all started to ask the same kind of question whenever a new platform program comes across their desk. They want more rigor in the business case before approving a pilot. They want proof points before allocating budget. They want to see what the exit cost looks like if the pilot doesn’t deliver. Vendors sometimes read this as obstruction. What it actually reflects is pattern recognition built up over many prior implementations: a confident pitch, a tight timeline, and an ending that arrived later, cost more, and delivered less than what was implied at the start.
For the leaders being asked to approve AI investment specifically, the pattern is acutely familiar. Three-year implementations where the requirements documented at kickoff are outdated by go-live. Teams so worn down by the rollout that launch day feels less like a milestone and more like an exhale. The Q3 steering review where the business case approved in Q1 is unrecognizable. The realization, halfway through year two, that the consulting fees have crossed the original software license cost. Most enterprise rollouts look like this in retrospect.
The gap between an enterprise vendor’s pitch and the post-implementation reality is usually larger than the pitch suggests.
Why the hesitation is rational
The hesitation comes from evidence accumulated over years of working alongside vendors whose deployment models consistently overran their promises. It also lines up with what the broader market data is now showing. Gartner Q2 2026 found that 59% of IT leaders see little or unclear value from current AI investments, and a 2026 Nokod report showed that only 39% of tech leaders are confident in a positive return on AI spending. Deloitte’s 2026 research put 38% of enterprises in AI pilots that have not moved into production, with only 11% running agentic AI at any meaningful scale. Gartner has separately projected that more than 40% of agentic AI projects will be cancelled or abandoned outright.
Against that backdrop, the leader who asks for proof points before approving the next AI program is making the responsible call. The same instinct has also become one of the largest internal obstacles to enterprise AI adoption right now. The technology is far enough along to deliver real value, the use cases are well understood, and the funding is sitting on the balance sheet. The decision-maker has simply learned, over time, that the gap between an enterprise vendor’s pitch and the post-implementation reality is usually larger than the pitch suggests.
The cost of that pattern is not only financial. HR leaders especially remember the goodwill the last major system implementation consumed — eighteen months of productivity disruption, two rounds of change management consulting, and a workforce that learned to expect the next big program to be just as disruptive as the last. That goodwill takes longer to rebuild than the budget overrun took to absorb.
Why most AI pilots have stalled
A common reaction to past implementation pain has been to look for a smaller, lower-commitment entry point. The pilot. Pick one team, give them an AI tool, let them prove value before the organization commits at scale. In principle this is the right instinct. In practice, the pilots have not been scaling.
The usual reason is that the pilot hits the boundary of what one system can execute. A pilot can show that an AI tool reads invoices accurately, drafts a service response well, or summarizes a contract reliably. What it cannot do on its own is move the result of that work across the multiple systems an enterprise actually runs — into the ERP, through the approval chain, into the audit log, back into the system of record. The coordination required to take the pilot from “this works in our test environment” to “this runs in production every day” is precisely the coordination work the pilot was supposed to demonstrate the AI could absorb.
When that coordination ends up landing on the same people the pilot was meant to help, the pilot quietly stops. Not because the technology failed, but because the infrastructure to put the technology to work was not in place. The pilot-stall figures many leaders have read this year — the meaningful gap between AI tools being purchased and AI tools being used at production scale — reflect missing execution infrastructure as much as any immaturity in the AI category itself.
The pilot hits the boundary of what one system can execute.
What a different deployment model has to look like
The way through this gap is a different shape of deployment, one that respects the experience the buyer is bringing into the room.
For NEWWORK, that has meant building the entry model around a single bounded workflow rather than a program. The workflow has a quantified baseline — manual steps, systems touched, time per cycle — established before deployment begins, so the value at the end is measured rather than asserted. It does not require a rip and replace of the systems already in place. It does not lock in commitments about what the organization will buy next. It runs on a timeline measured in weeks rather than quarters, requires a small number of approvers, and is contained by a clear scope that limits the exit cost if the workflow does not deliver.
Consider what this looks like applied to a specific case: an invoice-to-payment workflow. Today, that process typically requires finance to coordinate manually across email-based intake of invoices, an extraction or OCR tool, the ERP for vendor master matching, an approval chain spanning approvers who may be in different systems, and posting back into the ERP at the end. Each handoff can introduce a delay, an error, or a missed exception. Deloitte’s 2026 research found that only 4% of finance teams have fully automated AP despite decades of ERP investment, which is one of the clearest data points on how stubborn cross-system coordination remains in a typical enterprise.
A bounded workflow deployment starts there. Before anything is built, the baseline is measured: how many manual steps, how many systems touched, how much time per invoice, how many exceptions caught versus missed. The deployment then orchestrates the workflow across the existing systems without replacing any of them, and measures the same numbers afterward. The board does not have to take the value claim on faith. The before-and-after numbers are the proof.
What the leader is being asked to approve is one specific operational outcome, not a transformation program. It is the kind of bet a CIO, CHRO, or CFO who has been through too many three-year implementations can actually sign off on.
The board does not have to take the value claim on faith. The before-and-after numbers are the proof.
Meeting leaders where the evidence has put them
The pattern that produced this hesitation will only fade as deployment models change in ways that make the hesitation unnecessary. Talking about it differently won’t be enough. The path to enterprise AI adoption runs through deployments small enough to learn from and bounded enough to walk away from if needed. Anything larger has to earn the right to be approved by clearing that gate first.
Respecting that gate is how vendors turn hesitation into action. It is also how enterprises get to discover what governed AI execution can actually do in their environment before committing to anything that resembles the implementations they remember.
