Seraphic and CrowdStrike: A New Chapter for Browser Security

Read more
close icon

September 22, 2026

A Deep Dive into the Real Work of Deploying Industrial AI (Part 2)

Type

Deep Dives

Contributors

Christopher Yazdani

In part one of this series, we examined the origin story of Industrial AI and why its evolution has been different from automation cycles of the past.

In this piece, we’ll look more closely at what it will take for Industrial AI to move from promising demos to reliable deployment at scale. The next phase will depend not simply on better models, but on better contextualization and deeper integration into the workflows, systems, and decisions that run the factory. We’ll explore the technical architecture and modeling approaches behind these systems, as well as some of the key deployment challenges that many vendors still overlook.

The gap between demo and deployment

As it stands today, vendors are talking a good game about Industrial AI. For the most part, their sales decks are good, and their customer demos are impressive. Unfortunately, the situation on the ground can look a bit different. Industrial customers are learning the hard way that a model that performs perfectly in a demo might fail miserably in the real world. This is especially true if the model is not properly integrated into the systems those customers use every day, like work-order systems, production-line controls, and analytics platforms.

The challenge often isn’t building a model that works in isolation. It comes when that model has to operate reliably in production. Training models to predict equipment failure, for instance, is hard because those equipment failures may not happen often enough to generate sufficiently representative training data.

Despite what a lot of vendors say, fully autonomous AI control, where the system acts alone, without a human in the loop, is still more of an aspirational goal than a reality. Most systems deployed today instead flag a problem and then wait for a human to decide what to do about it. That is progress, but it remains far from full autonomous control.

Here’s why deployment is hard

To understand why deployment is so difficult, let’s take a closer look at how these systems are put together in the first place. Industrial AI systems are built on a layered foundation that looks something like this:

  • At the base is the physical layer, which comprises sensors, actuators, PLCs, and DCS systems that collect key data points in real time, such as temperature, pressure, flow, and vibration.
  • Above the physical layer is process control software, such as SCADA systems and HMIs, that aggregate data into historians and provide operational visibility.
  • Next, the IT layer, made up of MES, ERP, CMMS, and APM platforms, adds business context, such as work orders, quality records, and maintenance plans.
  • The top layer is AI, which draws on data from every layer under it to generate insights and action. A quality model, for instance, may need camera images from the line, machine settings from the PLC, the active recipe from the MES, and the final inspection result from a quality system.
  • Across the entire stack sits an orchestration layer. It manages data pipelines, features, model versions, inference services, policies, monitoring, and the connectors that turn a model output into an operational action.

The challenge is that many of these systems were not designed to exchange data in the formats, frequency or context that AI requires. Getting data from one system into a format that a model can train on is an engineering problem that can take months to solve.

There is also an important distinction between reading from the industrial stack and acting through it. Data travels upward from machines and operational systems to the model; decisions must travel back down into the processes where work actually happens. Most demos prove the first capability: the model can read data and produce a prediction. Production deployments must solve the second, requiring that the prediction be placed within an alarm, inspection or maintenance workflow.

Once a model is trained, you still need to decide where to run it. Do you deploy it at the edge, right on the factory floor? Or remotely in the cloud, so you can train across multiple sites? In practice, the answer is usually a hybrid approach: real-time decisions at the edge and centralized model improvement in the cloud.

Industrial data is messy

Factories generate enormous amounts of data. Temperatures, pressures and currents are continuously captured across hundreds of measurement points. Maintenance records, quality checks, alarm logs, engineering documents and, increasingly, images and vibration waveforms are being collected.

But the problem isn’t the amount of data being gathered; it’s the quality of the data. Industrial data is inherently messy. The same measurement, for example, might be labeled three different ways across three production lines.

What’s more, when equipment is starting up, shutting down, or switching between production runs, the data may also look completely different from the data produced during normal operation. But those different statesaren’t always consistently labeled. Models can therefore end up being trained on datasets that mix fundamentally different operating conditions. And when something goes wrong, the underlying event may not be logged until hours or days later, making it difficult to align the failure with the conditions that preceded it.

Quality control creates another challenge. A model that predicts whether a semiconductor wafer or machined part will pass inspection needs more than sensor traces. It also needs traceability from raw materials and recipes through machine settings, process events, and final measurements. Without that traceability, the model may learn correlations that disappear as soon as a supplier or product variant changes.

This is why industrial data engineering often matters more than model engineering. The difficult work is building a consistent representation of assets, process states, products, and interventions. NIST describes AI-ready manufacturing data as information that is consistently contextualized, qualified, and prepared for reuse across applications.

Where the demo ends and production begins

A demo is usually optimized to prove that the model can perform the task. A production deployment, however, must be optimized for the reliability of the system around the model. A production deployment, however, must be optimized for the system around the model. A working deployment therefore climbs an autonomy ladder. The system first analyzes historical data offline. Then it runs in shadow mode without showing recommendations to operators. Next it becomes read-only or advisory. After its performance and workflow are understood, it may be allowed to create a draft work order, request approval for an action, or operate automatically within a narrow, prevalidated envelope.

Production deployments also need to be designed for failure. That means local buffering, health checks, version control, rollback, fallback rules, and a clear answer to what happens when a sensor goes silent or the model becomes uncertain. Teams also need to track false positives, missed events, and whether operators act on recommendations.

Industrial deployments also inherit long hardware and software lifecycles. NIST notes that OT components may remain in service for 10 to 15 years. The AI layer must therefore coexist with proprietary protocols, custom applications, and unsupported operating systems.

Cybersecurity is another key consideration. Connecting an AI application to operational technology expands the attack surface. Industrial networks are commonly segmented by function and criticality, with controlled communication between zones. An analytics service should receive only the access it needs, not a direct path to low-level control simply because that integration is possible.

Overall, industrial AI must be evaluated in the context of its effects on the broader system and its users, rather than as an isolated model.

What’s working today, and what’s not

The production use cases that appear most compelling today tend to share three traits: the problem is bounded, the outcome is measurable and the recommendation fits into an existing workflow.

Computer vision is one of the clearest examples. AI can inspect surfaces, assemblies, welds, packaging, and safety conditions at line speed. But the model isn’t the whole system. The camera, lighting, and fixturing that feed it also need to be considered. Change any of these elements (such as moving a camera, adding a new product variant, or introducing a more reflective surface), and the model can quickly degrade.

Another strong use case is condition monitoring. Models can detect unusual combinations of vibration, temperature, acoustic, and electrical signals earlier than fixed thresholds. The value comes when an alert triggers a specific inspection and the result feeds back into the model.

Predictive quality and virtual metrology are also promising use cases, especially in stable, traceable processes. A model can estimate a hard-to-measure quality outcome from process variables before a laboratory or downstream inspection is complete. This can reduce sampling, shorten feedback loops, and prevent additional material from moving through a bad process.

What remains less mature is a single, all-encompassing model that can run across plants with little or no retraining, predicts precisely when a specific asset will fail, and lets an agent manage a complex process end-to-end with minimal human oversight. Narrow, well-scoped versions of these approaches can work. But that’s different from deploying them reliably across the diversity of real industrial environments. NIST’s manufacturing roadmap draws a similar line. It separates areas where AI is already delivering results from more speculative work, such as foundation models, physics-informed AI, and greater autonomy.

The factory of the future isn’t one model

The next phase of Industrial AI will not be defined simply by larger or more capable models, but by models that carry more industrial context.

Pretrained time-series models represent an early step in this direction. Systems such as Chronos and MOMENT show that models trained on diverse time-series datasets can transfer useful patterns to new tasks: Chronos demonstrates that pretrained models can perform competitively on unseen forecasting tasks, while MOMENT extends the approach to forecasting, classification, anomaly detection, and imputation with limited task-specific fine-tuning. However, industrial deployment is a harder problem. Public datasets still do not capture the full diversity of real-world industrial time series, where signals vary widely in sampling frequency, scale, semantics, equipment type, and operating regime.

The more consequential industrial foundation models will likely be multimodal. They will connect sensor histories, images, process states, maintenance records, engineering diagrams, and technical language to asset models. Their advantage will come less from memorizing generic industrial text than from understanding the relationships among a specific machine, process, and workflow.

Physics-informed AI can help here by narrowing the space of plausible answers, though these approaches can introduce their own training and optimization challenges for complex problems.

Digital twins and simulation can provide another bridge. A functional twin is not merely a 3D representation. It connects a simulation to the physical system so the representation can be updated, tested, and used for prediction or control. This makes it useful for generating synthetic data for rare scenarios, testing control policies, and training systems without experimenting on live equipment. The twin must still be calibrated, validated, and accompanied by quantified uncertainty.

Emerging at the top of this stack are industrial agents. An agent may query a historian, inspect an MES record, propose a diagnosis, and prepare a CMMS work order. The key question will be which tools it can call, under what policy, with whose approval, and with what audit trail. What this all means is that the factory of the future will not be run by one model, but rather by a series of models, controls, data systems, and people, each with a clearly defined role.

Conclusion

Industrial AI is moving from impressive demos toward dependable production systems. But the path forward will not be defined by any single model. The systems that succeed will be those that best understand the industrial context around them: the assets, operating states, data systems, workflows, controls and people that determine how a factory actually runs.That is ultimately what separates an AI model from an industrial AI system. The model generates an insight; the system makes that insight reliable, actionable and safe enough to become part of the operation itself.

times
#
# #