Picture this: you've picked a reputable AI vendor, signed the contract, and handed the project to your technical team. Six months later, the pilot is technically functional and organizationally dead. Nobody uses it. The promised productivity gains look nothing like the case studies in the sales deck. Your team shrugs. The vendor blames edge cases.
It's not the vendor's fault. It's not really your team's fault either.
Stanford's Digital Economy Lab recently published The Enterprise AI Playbook, a 116-page empirical study of 51 real production AI deployments across 41 organizations, nine industries, and seven countries. The research team, led by economist Erik Brynjolfsson, interviewed executives and project leads who deployed AI at scale and measured actual results — not forecasts, not demos, not vendor-written case studies. Real production systems, real business outcomes, real failures.
The headline finding is blunt enough to be uncomfortable: organizational context matters more than the technology. The same model, deployed by the same vendor, into different organizations produced outcomes that bore almost no resemblance to each other. For mid-market leaders who've been told that picking the right platform is the hard part, this means the vendor selection process is the wrong place to spend most of your energy.
The 77% Problem Nobody Talks About
The study found that 77% of the hardest challenges practitioners faced were not technical. They were change management, data quality, and process redesign. The technology was consistently described as the easiest part.
The vendor selection process that consumed three months of your leadership team's attention addresses roughly 23% of where deployments actually break down. The majority of failure risk lives inside your organization, not inside the tool.
The Stanford team also found that 61% of successful AI projects included at least one prior failure. Those failed experiments represent sunk costs that rarely appear in a successful project's ROI, invisible in the final numbers but often essential to eventual success. The pattern across those failures is consistent: teams treated AI as a technology project instead of a process and change management project. First attempts failed when applied to broken workflows, when led by technical teams without business ownership, or when organizations assumed the model would fix problems that actually required redesigning the work itself.
The recruiting case study on page 25 of the playbook illustrates this clearly. A translation services company, explicitly labeled mid-market in the study, tried to automate recruiting twice. The first attempt failed for two reasons: they didn't account for bias in their screening algorithms, and they assumed AI would fix broken processes without addressing the underlying workflow problems. An executive at the company put it plainly: "They thought AI would just fix processes instead of also stepping back and making sure everything was working as expected."
The second attempt took one month and delivered 83% improvement in candidate intake efficiency and 75% improvement in candidate conversion. Same company, same goal.
The difference wasn't the technology. The CEO took direct ownership, the process was fixed before AI was applied, and the team stayed focused on the business problem rather than the technical implementation.
Five Questions the Study Raises
Are you applying AI to a working process or a broken one?
The study's most consistent finding is that AI amplifies what's already there, including dysfunction. Organizations that succeeded fixed their workflows before deploying AI, not after. Those that failed assumed the model would sort out the mess.
Before the vendor conversation happens, it's worth mapping the exact process you want to automate and being honest about its current state. Broken processes don't get fixed by adding a model on top. They get automated in their broken state, which creates a different and harder problem.
Who actually owns this project, and what does that mean in practice?
The Stanford study found that similar use cases took weeks at one organization and years at another. The variable wasn't budget, headcount, or model quality. It was executive sponsorship, and specifically, the type of sponsorship.
Passive support wasn't enough. Effective sponsors in the study did four concrete things: they allocated resources, linked AI work to business objectives, communicated its importance, and removed blockers. That's a different job from telling a team to "explore AI opportunities and report back next quarter." If the project is owned by IT with a VP nominally kept in the loop, the timeline is going to stretch considerably.
The 71% Gain Most Companies Leave on the Table
The study found that escalation-based models, where AI handles 80%+ of volume and humans review exceptions, delivered 71% median productivity gains. Approval-based models, where humans approve every AI action, delivered 30%. The difference isn't just efficiency. It reflects a fundamentally different philosophy about where human judgment belongs in the workflow.
Escalation-based design only works if people trust the system enough to let it run, and if there's a clear, well-understood path for exceptions. Without that, staff insert themselves into every decision, effectively turning an escalation model back into an approval model. Most of the productivity gain disappears.
Think about what this means concretely: a frontline employee at 2pm on a Tuesday gets an AI-generated result they're unsure about. What do they do? If your team can't answer that quickly, you've got a change management gap that will surface at the worst possible time. The 71% gains in the study didn't come from better models. They came from organizations that had already answered that question.
The practical implication: before you deploy, design the exception path. Not as an afterthought. Before launch.
How well do you actually know your data?
The playbook pushes back on the conventional wisdom that you need pristine data before deploying AI. LLMs handle messier inputs than most organizations expect. They can connect fragmented datasets and compensate for incomplete data in ways traditional software can't. That finding should remove "we need to clean up our data first" as a reason to delay indefinitely.
That said, organizations that scaled successfully were significantly more likely to have invested in data infrastructure: 61% of "strategic scalers" possessed a large, accurate dataset, compared to 38% of non-scalers. Clean data isn't a prerequisite. But knowing where your data lives, how fragmented it is, and what it would take to connect it determines whether your first deployment attempt fails at the data layer or the model layer.
Have you actually talked to legal, HR, and compliance yet?
Legal, HR, risk, and compliance teams were the most frequent sources of early resistance in the organizations studied. Most companies' instinct is to work around these functions or get leadership to override them. Most companies who did that ended up with delayed rollouts, scope cuts, and projects that technically launched but were never fully adopted.
The organizations that succeeded brought these stakeholders in early, addressed their concerns directly, and turned former resisters into internal advocates. The playbook is specific about this: resistance from staff functions can convert into support when their concerns are taken seriously rather than steamrolled.
Model Choice Is Becoming a Commodity
There's one more finding that changes how mid-market executives should approach vendor selection.
In 42% of the cases studied, the choice of foundation model was essentially interchangeable. The competitive advantage in successful deployments came from the orchestration layer: how workflows were designed, how data was connected, how humans and AI divided responsibility. Not from which model sat underneath.
Benchmark debates are a distraction. The organizations in the study that got results spent that energy on workflow design and change management instead.
Orgvue's survey of over 1,100 senior decision-makers found that 78% of organizations have seen AI projects fail or stall at the pilot stage. The Stanford study effectively explains why: most organizations invest their attention in the 23% of the problem while the 77% goes unmanaged.
What the Study Won't Tell You Directly
For mid-market executives who've stalled on AI initiatives, the study's message isn't "you picked the wrong tool." It's closer to: the organizational work the tool required never got done, and no one pointed at that clearly enough.
The market has spent three years fixated on model selection. The actual drivers of ROI sat in the organizational layer the whole time.
The gaps the Stanford study identifies are all things a mid-market company can audit before committing budget: process readiness, active sponsorship, exception design, data accessibility, stakeholder alignment. None of them require a bigger spend.
The study doesn't tell you which model to buy. It tells you what to fix before you spend anything. Given that 61% of successful deployments needed a failed first attempt to get there, learning that lesson from your own failure is the expensive version.