Most manufacturers do not have an Industrial AI problem. They have a second-plant problem: a working proof of concept at one site that cannot move to the next one without being rebuilt. The first deployment proves the use case. The second reveals that tags, context, and structures differ at every site. Standardizing the foundation is what turns deployment two into a rollout instead of another integration project. This guide covers the decisions that determine which of those two outcomes you get, in the order they have to be made.
Industrial AI operates across three layers — asset, site, and enterprise — each with different users, latency requirements, and data needs. Choosing an AI strategy means choosing which layer you are solving for first. Most manufacturers will eventually need all three.
| Asset level | Site level | Enterprise level |
Primary users | Operators and technicians | Supervisors and operations teams | DX and manufacturing excellence teams |
Latency budget | Milliseconds to sub-second | Seconds to minutes | Hours to days |
Where it runs | On or beside the machine | Plant server or site edge cluster | Cloud or central data platform |
Data requirement | High-frequency tag data with asset context | Contextualized data across assets and lines, aligned to shifts and units | Standardized, governed data models common to every site |
Why this comes first: the layer determines the data requirement, and the data requirement determines the architecture. Teams that pick a model before picking a layer end up building for a latency budget the data cannot meet.
Common mistake: starting at the enterprise level because that is where the budget sits, then discovering that the standardized data models it depends on do not exist yet at any site.
Industrial AI divides into two types with different latency budgets, deployment models, and data requirements.
Operational AI is real-time, localized, and prompt-driven. It runs at the edge, next to the machine — no cloud round trip, conversational and on-demand for operators and technicians, and functional in restricted, offline, and air-gapped environments.
Enterprise AI is continuous, high-compute, and inference-driven. It runs in the cloud across all sites — finding patterns and benchmarks across plants, centrally governed and version-controlled, training and redistributing models to the fleet.
Most stalled AI programs picked one and assumed it covered everything. The two types need different data, in different shapes, delivered to different systems — from the same governed source.
Practical implication for sequencing: these have different failure modes. Operational AI fails on latency and context; Enterprise AI fails on standardization across sites. Diagnosing which one you are attempting tells you which risk to retire first.
Industrial AI does not stall because manufacturers lack models. It stalls when operational data is disconnected, inconsistent, or missing the context that makes model output useful.
Before any model can be trusted, four things have to be true of the data:
- 1.
Connected. OT data collected from legacy and modern systems at consistent frequency, quality, and format — PLCs, SCADA, historians, MES.
- 2.
Contextualized. Tags carry their assets, units, shifts, and reusable models. A control loop needs a tag value; a model needs to know what the tag means, which asset it belongs to, what shift it was recorded on, and how it relates to every other signal on the line.
- 3.
Governed. Lineage, ownership, and traceability maintained as data scales. This is not a compliance formality — it is the mechanism by which an operator decides whether to act on a recommendation. An AI output no one can trace to a source is an AI output no one will act on.
- 4.
Secured. RBAC, encryption, and controlled OT-to-enterprise access, including in segmented and air-gapped environments.
The decision that matters here: whether the foundation is built once and reused, or rebuilt per project. Establishing it once is what lets AI use cases repeat across machines, lines, and sites.
Industrial AI runs in both places, for different work.
| Edge: inside the plant | Cloud: across sites |
Best suited to | Latency-sensitive, localized, air-gapped decisions | Continuous, high-compute analysis and cross-site comparison |
Latency | Milliseconds to sub-second | Minutes to hours |
Typical workloads | Computer vision, closed-loop control, local SLMs, operator troubleshooting | Model training, cross-plant pattern detection, enterprise benchmarking |
Data movement | Stays on site; works offline and air-gapped | Contextualized data forwarded through governed OT-to-enterprise gateways |
Cost profile | Predictable; does not scale with tag volume | Scales with data volume and compute consumed |
The cost row is the one most teams miss at design time. An edge deployment's cost is set by the hardware footprint. A cloud deployment's cost grows with every tag you decide to forward — which means the data-selection decision made in month two determines the run rate in year two.
Capability checklist for edge execution: sub-second local inference with no cloud round trip; computer vision at line speed with NVIDIA GPU support; locally hosted small language models; CPU- and GPU-based ML inference; containerized model deployment and lifecycle control; support for air-gapped environments.
Agents fail in industrial settings for one reason: they invent answers.
Without grounded access, an agent asked about a stalled filler describes what a filler generally does. With it, the agent reads the asset model, pulls recent telemetry, checks the fault history, and answers from what the machine actually did.
The Model Context Protocol (MCP) is the open standard for connecting LLMs and agents to external systems as callable tools rather than as static text in a prompt. In an industrial context, that means exposing device discovery, tag reads, telemetry sampling, historical queries, container management, and data model traversal as tools the agent can call.
The decision that matters here: whether agents reason over asset models and hierarchies, or over raw tag names. Raw tag names produce plausible answers that cannot be verified. Asset models produce answers with a traceable path back to a signal.
The layer that separates a pilot from a program is deployment management: template-based rollout, model and version management across edge fleets, and lineage and ownership visibility so any AI-driven conclusion is traceable back to its source signal.
.
The pattern that shortens deployment is the same one that makes AI repeatable — standardize connectivity and context once, then replicate rather than rebuild.
The question is no longer "did we deploy AI?" but "what work did AI complete, and what outcome did it improve?"
Measures that indicate a program rather than a pilot:
• Production hours and downtime avoided
• Scrap reduced, energy saved, quality investigations closed faster
• Work orders created without waiting on scarce engineering expertise
• One proven use case replicated across sites instead of rebuilt per plant
• AI models governed, versioned, and traceable at fleet scale
Connected, contextualized, governed, and secured OT data, plus an execution environment for inference — at the edge for latency-sensitive work, in the cloud for high-compute cross-site analysis.
Most pilots solve the data problem for one machine, line, or plant. Because tags, context, and data structures differ from site to site, the second deployment becomes another integration project.
By standardizing the data foundation before the second site, so each new plant inherits the architecture rather than recreating it.
Should Industrial AI run at the edge or in the cloud?
Both, for different work. Edge for latency-sensitive, localized, and air-gapped workloads close to the machine. Cloud for high-compute workloads, cross-site pattern detection, and enterprise benchmarking.
It depends on how standardized the data foundation is before AI is introduced. One Food & Beverage manufacturer reached 95 global sites in 18 weeks using template-based rollout.
No. The integration target is the stack already in place: PLCs, SCADA platforms, historians, MES, cloud infrastructure, and analytics tools.