Why manufacturing AI stalls before it reaches the shop floor

Most manufacturing AI projects do not fail because the technology is wrong. They stall because the conditions required for deployment are never built. Fragmented data, legacy OT infrastructure, misaligned use case selection, absent operational ownership, and undertrained shop floor teams each act as a barrier between a working pilot and a running production system. This article identifies the five patterns we observe most consistently across manufacturing engagements, and what it takes to move from proof of concept to the shop floor.

Introduction

One of the clearest patterns we observe at Vstorm is this: manufacturers do not lack ambition for manufacturing AI implementation. Investment in artificial intelligence across manufacturing processes has continued to grow. What is consistently absent is a viable deployment path.

Over 80% of AI projects fail to reach meaningful production deployment, roughly twice the failure rate of traditional IT projects, according to RAND Corporation research published in August 2024. In 2025, that trajectory worsened: 42% of companies scrapped most of their AI initiatives, up from just 17% the year before, according to S&P Global Market Intelligence. The pattern holds for generative AI specifically: MIT Media Lab’s Project NANDA found that 95% of generative AI pilots delivered zero measurable financial return, according to “The GenAI Divide: State of AI in Business 2025,” published July 2025. The gap between functioning AI solutions and deployed production systems has remained wide despite years of investment.

The pilots work. The models perform in controlled conditions. Then nothing changes on the line.

This article identifies the five reasons we see manufacturing AI projects stall before they reach the shop floor, and what closing that gap actually requires.

What “stalling” looks like on the factory floor

Before examining the causes, it is worth being precise about what stalling means in practice.

The pattern is consistent. An innovation team or external vendor runs a 90-day proof of concept. The data science team presents results. The model performs well against the test dataset. Then the project enters what operations leaders call “pilot purgatory”: the gap between technical validation and operational deployment. The model sits in a notebook. The line keeps running the way it always did. Operators were not consulted during the build and do not trust the output. No one owns what happens next.

In the real world, this gap is the rule rather than the exception. The model was trained to handle repetitive tasks within a bounded, prepared dataset. It was not built for the variability of live production or the edge cases that appear only once the system is running.

This is not a technology problem. It is a deployment problem, and it has specific, addressable causes.

The IT/OT disconnect

The first barrier is structural. Factory-floor operational technology (SCADA systems, PLCs, DCS platforms) was designed for reliability and isolation, not for data integration. These systems run on Modbus, Profibus, and proprietary vendor formats that resist standardisation. They do not expose APIs. They were not built to feed machine learning pipelines.

A Dragos 2026 OT/ICS Cybersecurity Year in Review found that only 46% of OT environment assessments showed adequate network monitoring in place. AI systems that depend on real time data cannot function when the OT layer has no mechanism to surface it consistently. Without a reliable data stream, there is no model that can run at scale.

Retrofitting older production lines with the sensor infrastructure AI requires is not a software task. It demands physical installation during maintenance windows and budget commitments that sit entirely outside most IT project scopes. The IT team owns the data infrastructure. The operations team owns the line. Neither owns the gap between them.

Agentic AI manufacturing workflows built for IT environments cannot reach the environment where the decision needs to be made. The model never connects to the process it was designed to improve.

Data that cannot support a model

Even where OT connectivity exists, the data it produces is rarely ready.

The data produced by manufacturing processes is distributed across MES, SCADA, ERP, and quality management systems, each with its own format, label convention, and collection frequency. Sensor outputs vary across shifts. Machine logs are inconsistently annotated. Historical data from a production line built in the 1990s exists in proprietary formats that no modern tool reads natively.

Nearly 70% of manufacturers identify data quality, contextualisation, and validation as the most significant obstacles to AI implementation, according to Deloitte’s 2025 Manufacturing Industry Outlook.

The consequence is that each new AI-driven initiative starts from scratch. What should be a scalable pattern becomes a custom rebuild for each production line, each facility, each product family. The model that performed in the pilot was trained on clean, prepared data. The production environment provides none of that.

We encountered the same challenge directly in our work with Synera. When we set out to build a text-to-workflow AI agent for Synera’s engineering platform, no training data existed for the target task. The workflow graph format was proprietary and unfamiliar to any available model. We solved this by constructing a synthetic training dataset from Synera’s library of thousands of existing workflows, building an interpreter that converted the graph structure into a format the model could reason over. The data problem had to be engineered before the AI problem could be addressed.

The full case study is available at vstorm.co.

The wrong starting point

The third cause of stalling is AI use case selection driven by visibility rather than readiness.

Manufacturers frequently choose the highest-profile process as the first AI candidate: predictive maintenance systems, quality control across the full line, demand-led production scheduling, end-to-end supply chain optimisation. These are genuinely valuable targets. They are also the most technically complex, the most data-hungry, and the most dependent on the OT/IT integration that does not yet exist.

The projects we have seen deliver genuine operational efficiency gains consistently share a different approach. They start with processes that are bounded, data-rich, and operationally owned. Back-office and operational support processes, not the most visible use cases, deliver the first measurable results. That evidence base is what earns the broader mandate.

A feasibility assessment must precede use case selection. The question is not “where could AI add value?” The question is “which process is ready for AI today, and what would it take to make the next one ready?” This is the foundation of our TriStorm methodology: transformation consulting identifies which AI use cases carry both operational leverage and implementation readiness before any engineering begins.

No operational owner after the pilot

The fourth cause is organisational, and it is the one most consistently underestimated.

AI projects managed by central innovation teams or external vendors, without a named internal operations owner, rarely survive deployment. The model goes live. An edge case occurs that was not in the test data. No one knows who is responsible for retraining, monitoring, or ensuring the system is continuously improving as production conditions change. The system is quietly switched off or bypassed.

McKinsey research published in January 2025 found that nearly 70% of transformations fail, most often due to people and change management factors rather than technology shortcomings. A system without a committed operational owner is a system that will stall the moment those factors surface.

At Vstorm, a named operational owner on the client side is a prerequisite for beginning any engineering work. AI solutions that lack this internal accountability structure do not fail on deployment day. They fail three months later, when the first unexpected condition arrives and no one knows whose problem it is.

The skills gap between the model and the line

The fifth cause is the distance between the team that built the AI system and the people who are expected to use it.

51% of manufacturers now use AI in their operations, yet 82% cite a lack of AI-ready skills as their top workforce challenge, according to a 2025 National Association of Manufacturers report. Shop floor teams are asked to act on outputs they did not help design, from AI tools they do not understand, for decisions they have always made using experience and judgment. The rational response is to ignore the recommendation.

Michael Kolb, Head of Development for AI manufacturing applications at Bosch, described the challenge directly when discussing the company’s Shopfloor Agent deployment: the system had to generate value that operators could act on immediately, not just produce outputs that looked correct in a test environment. Since deploying agentic AI across its own plants from late 2025, Bosch has reported annual savings of approximately EUR 850,000 per plant through reduced machine downtime. The enabling factor was that the system was built around how operators actually work, not around what the model could theoretically produce.

Change management is not a soft deliverable that follows engineering. It is a technical dependency that must be addressed before deployment begins. If the people who run the process do not trust the system, the system will not run.

What closing the gap requires: the Synera example

The Synera engagement illustrates what it looks like to solve these problems in sequence rather than in isolation.

Synera operates an AI agent platform for engineering, used by organisations including NASA, integrating with CAD, CAE, and PLM software. Their platform already supported workflow automation. The challenge was to bring natural language capability to workflow creation: an engineer describes what they need in plain language, and the system generates the executable workflow.

The environment was proprietary. The data did not exist. The model had never encountered the graph-based workflow format Synera uses.

We approached the problem in stages. First, we built a custom interpreter: a translation layer that converted Synera’s node-based workflow structures into pseudo-Python code that a language model could read and manipulate. This solved the environment problem. Second, we constructed a synthetic training dataset from Synera’s existing library of thousands of real workflows. This solved the data problem. Third, we ran structured experiments across model and tooling combinations to identify the configuration that performed within both quality and budget constraints. This solved the feasibility problem.

The result: a production AI application that reduced workflow creation time from hours to seconds for engineers who had previously spent significant portions of their working day on manual construction.

The lesson is not that every manufacturing AI pilot to production path looks the same. It is that the path must be engineered, not assumed. The integration layer, the data foundation, and the environment the agent must operate inside all require as much deliberate work as the model itself. Projects that treat them as prerequisites tend to reach production. Projects that treat them as details tend to stall.

Conclusion

Manufacturing AI projects do not stall because the technology fails. They stall because the conditions required for the technology to operate are never established.

The IT/OT divide leaves the model disconnected from the process. Fragmented data means the model was never trained on what the production environment actually produces. The wrong AI use case is selected for the wrong reasons. No one is named as the owner once the pilot ends. And the people who run the line were never brought into the build.

Each of these is a solvable problem. None of them is solved by a better model.

Before the next manufacturing AI initiative is scoped, the practical questions are these: has the data foundation been assessed against what the model will actually need? Has an operational owner been named who will carry the system after deployment? Has the first use case been chosen for readiness, not visibility?

The answers to those questions determine whether the project reaches the shop floor.

For organisations working through these questions, our AI consulting and advisory practice is where that process begins.