Vol. III · Essays on work after AI
Saturday, October 3, 2026
evolving.work
Org Design · Strategy · Essay № 047

Enterprise AI Will Be Slower Than the Demos

Enterprise AI is not slow because the models can't do the work.

The demo was perfect.

The model summarized the 80-page contract in eleven seconds. It surfaced two unusual indemnification clauses, flagged a non-standard governing-law provision, and offered to draft the redline. The room nodded. Procurement nodded. The CIO nodded. Someone in the back said, we should just buy this.

Six months later, it is still not in production. Not because anyone changed their mind. Because the data lives in three document repositories with different access controls, two of them on-prem; because the model risk review wants documented failure modes for a system that is non-deterministic by design; because the security team has questions about whether the inference endpoint can sit inside the bank’s network; because the attorneys who would actually use the output have not been trained on when to trust it; because somebody has to sign their name to a workflow nobody has ever signed before.

I have watched a version of this meeting four times this year, at four different companies, in three different industries. The script barely changes. And the story we tell ourselves about that gap is wrong.

The demo was never the deployment

Eighty-four percent of enterprise CIOs believe AI will be as transformative as the internet [1]. Only 11% have fully implemented it. That is not a technology readiness problem. It is an organizational readiness problem dressed up as one — and 88% of AI pilots never transition into production [2]. The technology works in the demo. The organization does not work in the demo.

Demo environments are curated by definition. A data engineer assembled the dataset by hand. Somebody granted elevated permissions for the afternoon. The use case was handpicked because it would land. Production is the opposite — fragmented legacy systems, role-based access, compliance gatekeepers, procurement queues, undocumented workflows, and a thousand small decisions the demo never had to make. The demo is a stage play; production is what happens when the audience comes home and tries to cook the meal the actors mimed eating.

Enterprises are permissioned, distributed, governed systems built for stability and control — not rapid experimentation. For most use cases they are trying to deploy, the model was never the bottleneck.

What real enterprises look like

A bank, a manufacturer, a life sciences company, an industrial firm — these are not clean software playgrounds. The constraints show up in the records people need, the systems they must connect, and the decisions someone must approve. The demos hide every one of them.

Data. Patient records across incompatible electronic patient record systems. Sensor data inconsistently labeled across shifts. Document repositories with fragmented access. “The data is available” almost always means “a data engineer assembled it for this demo.”

Legacy systems. Production systems built over decades, often without clean API surfaces. Integration requires custom middleware. Middleware requires procurement. Procurement requires security review. Security review requires architecture review. The first integration meeting is the start of a multi-quarter project, not the end of one.

Compliance. OCC SR 11-7 for model risk in banks. MHRA software-as-a-medical-device guidance. HIPAA, GDPR, data residency rules. These are not bureaucratic obstruction. They are legitimate governance frameworks demanding documented assumptions, tested failure modes, and audit trails — none of which exist for the demo, which is part of why the demo went so well.

Permissions. Role-based access means the AI system’s data access must be designed, approved, and audited across every source it touches. The thorniest cases are not whether the AI can see the data — they are whether the AI should see more than any individual human user is allowed to.

Undocumented workflows. The real workflow is not the documented workflow. Tacit knowledge held by long-tenured employees — about exceptions, workarounds, the legacy field that means something other than what it is labeled — is exactly what the AI encounters first in production, and exactly what was not in the training set.

Cybersecurity. Cloud-based AI inference is frequently incompatible with enterprise OT security; plant-floor sensor data cannot freely cross the IT/OT boundary. Sixty-seven percent of executives believe their company has already suffered a data leak from unapproved AI tools, while only 6% of organizations have an advanced AI security strategy [8]. The gap between adoption and security maturity is the actual attack surface.

Procurement. Vendor approval, data processing agreements, security questionnaires, model risk attestations — months of work that begins after the demo lands and before any code ships.

Change management. Forty percent of CIOs cite talent shortage as the top barrier to AI implementation, but the deeper diagnosis is that organizations have a work-design problem, not a skills problem [5]. You cannot train your way out of a workflow structured for a different kind of decision. Enterprise AI scales in nine-plus months for large incumbents versus around 90 days for midmarket [3] — and that gap is mostly structural.

Demos hide every one of these eight constraints because they are sales artifacts. Showing all eight would mean explaining the work still needed for deployment: closer to a status report than a demonstration.

The composite below is drawn from documented patterns in industrial AI deployments; it is not attributed to a single named company.

A large industrial company with twelve plants on three continents deployed AI-powered predictive maintenance. The demo predicted equipment failures 72 hours in advance with high accuracy. Six months into rollout, adoption sat below 15%. Sensor data was inconsistently labeled across facilities. Shift supervisors were measured on throughput, so following an AI recommendation that required taking a machine offline was individually irrational. The cybersecurity team flagged that the vendor’s cloud inference pipeline required plant sensor data to leave the OT network — a policy violation. Procurement for on-premises edge hardware took seven months. Maintenance technicians with fifteen years of tenure held tacit knowledge that conflicted with the AI’s recommendations, and there was no protocol for who wins that argument.

Total time from demo to meaningful adoption: about 30 months. The demo had implied six.

Two cases where the model was never the problem

In 2017, JPMorgan Chase rolled out COIN — Contract Intelligence — to review commercial loan agreements. Attorneys and loan officers were spending around 360,000 hours a year on boilerplate interpretation. The system could do it in seconds. Production deployment took roughly 18 months [9], and not because the model failed.

Legacy document repositories had inconsistent metadata and conflicting versions across business units. OCC SR 11-7 required a documented assumptions register, tested failure modes, and ongoing validation. Role-based access differed across business lines, and somebody had to decide which permissions the AI inherited. Defining acceptable AI-assisted review meant redesigning the attorney workflow and writing new documentation standards for it. COIN eventually scaled and the payoff was real — but every month of that 18 months was spent on something other than the model.

The NHS story is the larger version of the same shape. Between 2019 and 2023, AI diagnostic tools matched or exceeded radiologist performance for several imaging tasks in controlled trials. Population-scale deployment took three to seven years for the cases that succeeded.

Patient records sat across incompatible electronic patient record systems — System C, EPIC, bespoke legacy stacks — and the federated data layer to bridge them had to be built. Each NHS Trust required its own GDPR data processing agreement. Models trained on one Trust’s population degraded on a different demographic mix, multiplying the validation burden. MHRA approval demanded clinical evidence most pilots had not been designed to produce. Diabetic retinopathy screening eventually reached national rollout; a larger number of pilots produced strong clinical results and never made it into operational service.

In both cases, the question was never can the model do this? It was can the organization support this? That question takes years to answer, and the demo never asks it.

When individual wins don’t scale

This is where the optimistic counterargument deserves a hearing. AI super-users are real. They report 5X productivity gains on tasks they understand deeply. Copilot deployments produce measurable engineering velocity. People who learn these tools well do more work, faster. For many organizations the right near-term play may genuinely be individual enablement rather than enterprise rollout — the honest answer is to take the individual gains seriously and not mistake them for organizational gains.

Those individual gains still need to be reconciled with the enterprise results. Forty-two percent of enterprises report zero measurable ROI from their AI implementations [4], and fewer than one in five track KPIs for their GenAI solutions [7]. The productivity paradox is real at the micro level and absent at the macro level.

The connection is the work around the faster task. Individual gains do not compound into organizational returns unless that work is redesigned. A 5X faster analyst whose output flows into a workflow built for the previous pace is a backed-up queue waiting to happen. A coder who ships twice as fast into a release process gated by manual QA is just generating a longer backlog. Individual productivity converts to enterprise return only when the workflow, the measurement system, and the accountability structure all change with it. Most organizations have changed the tool and nothing else.

The shadow side of solo adoption is not subtle. Those unapproved tools leaking data [8] mean individual productivity without governance produces an aggregate negative — every user is more productive and the organization is materially more exposed than it was last year. The productivity gains are visible; the data exfiltrations are not, until they are.

But isn’t enterprise AI already accelerating?

Some claim enterprise AI is already accelerating — usage jumped from 55% to 88% of organizations within two years, so the slow narrative is out of date. The breadth is real. But “uses AI in one function” and “has deployed AI as a production capability” are different metrics the hype conflates. The 88% pilot failure rate and the 11% full implementation figure describe the depth gap the breadth number cannot see.

Some argue legacy systems and compliance are addressable, not permanent. They are. A committed, well-funded organization can modernize its data estate, rebuild API surfaces, and stand up governance in 12–18 months — assuming leadership commitment, no compliance surprises, and no competing priorities. Most large organizations have all three the way most kitchens have ants: not catastrophically, just persistently.

Some argue the thesis applies only to legacy incumbents — that cloud-native technology companies deploy at demo speed. Fair. But the thesis is sharpest in financial services, healthcare, pharma, manufacturing, energy, and government, which collectively account for most enterprise employment and capital. Dismissing the gap by pointing at cloud-native outliers is selection bias against the firms whose mistakes are most consequential.

Some argue that framing all constraints as organizational lets AI vendors off the hook. Right, and worth saying clearly. Many enterprise AI products lack the audit logging, role-based controls, data residency guarantees, and deterministic behavior that regulated industries require. That gap strengthens the thesis rather than weakening it: it explains why demos look so different from production. Demos are curated to avoid exactly the failure modes production has to handle.

Sixty-eight percent of CIOs say their business stakeholders have unrealistic expectations about when AI ROI will appear [6]. Most enterprises are still running AI alongside their existing processes rather than redesigning operations around it [11] — the operational tell that the gap is real.

What enterprise leaders should do

The eight constraints above can be addressed in a planned sequence. The Enterprise AI Deployability Assessment helps make that work visible. Before approving any enterprise AI initiative beyond a contained productivity tool, run an EADA — a pre-deployment readiness check on the constraints demos hide. Seven components, designed to run in parallel.

  1. Data deployability audit. For every data source the use case requires, measure completeness, consistency, access controls, and residency constraints. Verify that the data accessible in the demo is accessible in production under real permissions. Flag any source that needed elevated privileges to show up.

  2. Compliance and regulatory clearance mapping. Map every governance gate — sector-specific AI guidance (OCC SR 11-7, MHRA SaMD, FDA), data protection (GDPR, HIPAA, residency), audit, procurement. Assign timelines; identify what runs in parallel. The most expensive enterprise AI mistake is treating compliance as a final gate.

  3. Permissions and access control architecture review. Design service-account access on a least-privilege basis. Verify compatibility with enterprise IAM. Any use case requiring broader access than an individual user holds is a deployment-blocking design issue, not an implementation detail.

  4. Workflow and undocumented knowledge mapping. Interview the people who currently perform the target workflow. Ask about the steps not in the documentation, the legacy fields that mean something other than their names. The AI will encounter the real process, not the documented one.

  5. Cybersecurity and OT review. Submit the architecture to security early. Determine whether the data classification permits cloud-based inference or requires on-premises or air-gapped deployment. Assess new attack surfaces — prompt injection, model inversion, data exfiltration.

  6. Incentive and accountability alignment. Map the performance metrics for every role expected to use the AI’s output. Identify who bears the cost of errors and who captures the benefit. Adoption fails when the existing incentive structure makes it individually irrational, regardless of model quality.

  7. Staged deployment with rollback protocol. Define stages by scope and oversight level, with explicit success criteria for advancing and failure triggers for pausing. Build observability from day one — inputs, outputs, overrides, downstream outcomes. Make deployment a reversible process, not a one-way door.

The framework is not a magic spell. It is a checklist for the work that already exists and is mostly invisible until it goes wrong.

What changes when you see this

The bottleneck is no longer whether AI can do the task. It is whether the organization can safely let it.

The model may be intelligent enough while the organization still needs work before it can operate it safely. That distinction changes the next conversation: from another demonstration to the permissions, workflows, and review the deployment needs.

If you are inside an enterprise AI program right now, the most useful thing you can do this quarter is unbundle three questions usually asked as one:

The first question is what demos answer. The other two are what production answers. The work of the next two years is the second and third questions, run in parallel, with leadership expectations reset to match.

The companies that win will not be the ones with the best models. They will be the ones that did the unglamorous work of becoming deployable.


References

[1] Salesforce. Just 11% of CIOs Have Fully Implemented AI. 2026. https://www.salesforce.com/news/stories/cio-ai-trends/

[2] Glean. How Enterprise AI Meets Unique Business Needs. 2024. https://www.glean.com/perspectives/what-is-the-difference-between-ai-and-enterprise-ai

[3] Chronus. Why AI Adoption Fails: Enterprise Barriers AI Leaders Ignore. 2024 (citing MIT survey). https://chronus.com/blog/why-ai-adoption-fails-enterprise-barriers-to-ai-leaders-ignore

[4] Glean. How Enterprise AI Meets Unique Business Needs. 2024. https://www.glean.com/perspectives/what-is-the-difference-between-ai-and-enterprise-ai

[5] CIO. You Can’t Train Your Way Out of the AI Skills Gap. 2026. https://www.cio.com/article/4165040/you-cant-train-your-way-out-of-the-ai-skills-gap.html; CIO. What’s Holding Back Enterprise AI? 2026.

[6] Salesforce. CIO Survey on AI Trends. 2026. https://www.salesforce.com/news/stories/cio-ai-trends/

[7] McKinsey. State of AI 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-in-2025

[8] Writer. Enterprise AI Adoption in 2026: Why 79% Face Challenges. 2026. https://writer.com/blog/enterprise-ai-adoption-2026/; BigID/PR Newswire. Major Gap Between Enterprise AI Adoption and Security Readiness. 2025.

[9] California Management Review. Bridging the Gaps in AI Transformation. 2025. https://cmr.berkeley.edu/2025/11/bridging-the-gaps-in-ai-transformation-an-evidence-based-framework-for-scalable-adoption/

[11] CIO Dive. High-Value Use Cases Lag Behind Enterprise AI Hype. 2026. https://www.ciodive.com/news/enterprise-AI-use-case-appian/819416/

Case sources: JPMorgan COIN — WSJ (2017), Reuters (2017). NHS AI Diagnostics — Nature Medicine (2019), BMJ (2022), NHS Digital. Manufacturing predictive maintenance — composite case drawn from documented industrial AI deployment patterns; not attributed to a single named organization.

About the author
Héctor Reinoso writes about how organizations should be designed when intelligence becomes abundant. He works on enterprise AI adoption inside a large industrial organization, after 25 years as a strategy consultant and transformation executive across four continents. Harvard MBA, industrial engineer, and still writes the code he writes about. More →