Ask ten manufacturers what they want AI for and you get roughly the same six answers. Predict the failures. Catch the defects. See the real OEE. Cut the energy. Flag the anomalies. Build the twin. The list isn't the hard part. Everyone agrees on the list, the vendors all sell against it, and the demos are genuinely impressive.
The hard part is that the same solution — same vendor, same model, same configuration — can go into production at plant one and fail to get out of pilot at plant two. Not because the second plant is worse run. Because its data doesn't look the same.
Industrial AI solutions are applications of machine learning, computer vision, language models and AI agents to specific manufacturing problems — predicting equipment failures, inspecting quality, optimizing energy use, and assisting operators directly.
They share a dependency. Every one runs on operational technology data from PLCs, SCADA systems and historians, and that data has to be connected, contextualized and governed before any model output can be trusted.
Six account for most production deployments: predictive maintenance, quality inspection, OEE intelligence, energy optimization, anomaly detection and digital twin. Each has a different latency budget, a different place it has to run, and a different data requirement.
Predictive maintenance. Detecting equipment failures before they occur, across a fleet of assets rather than a single machine. Needs high-frequency signals carrying asset context, and enough history to establish a baseline — which is why it's often the first use case attempted and often the one that stalls on data depth rather than model quality.
Quality inspection. A packaging line runs thousands of packets an hour. Seal defects cause spoilage, human inspection can't keep pace, and the reject decision has under 100 milliseconds to resolve. Vision and language models running at the edge classify the packet and explain why — a 5mm wrinkle on the top-left seal, likely from heater temperature fluctuation. The explanation is what makes it actionable rather than just a reject count.
OEE intelligence. Performance visibility across lines, shifts and plants. The calculation is trivial; the hard part is that four systems will produce four different OEE numbers unless they share a definition of what counts as downtime. That disagreement is a data problem presented as a reporting problem.
Energy optimization. Identifying idle consumption and savings opportunities across equipment and utilities using real-time data, then comparing across sites — which only works if energy data means the same thing at every site.
Anomaly detection. Flagging operational deviations in real time, close enough to the process that the deviation can still be acted on. Runs locally, including in air-gapped plants.
Digital twin. Virtual models of production systems built on standardized data models rather than per-site tag structures. That distinction is what lets a twin built for one line be applied to the next one.
Anything with a latency budget under a second, anything in an air-gapped or restricted-network plant, and anything where data volume makes forwarding impractical. Computer vision at line speed, closed-loop control and operator assistance are the clearest cases.
The rest is a genuine choice rather than a constraint. Model training, cross-site pattern detection and enterprise benchmarking all belong where compute is cheap and latency doesn't matter. Most production architectures end up running both, which is why a solution that only supports one narrows your roadmap in ways that aren't obvious on day one.
The cost profile differs too, and this is the part evaluations usually miss. Edge cost is set by hardware footprint. Cloud cost grows with every tag you decide to forward — so a data-selection decision made in month two sets the run rate in year two.
A newer category of solution that treats AI as capacity rather than another dashboard: always-on assistants that absorb repetitive analytical work across every site, grounded in the same trusted operational context.
The common ones are a shift assistant (what happened, what changed, what the next team must act on), a production analyst (where production was lost and what to correct), a reliability engineer (at-risk assets, likely failure modes, drafted work orders), a quality investigator (scrap and variation turned into evidence-backed summaries), an energy engineer and a compliance analyst.
The premise is simple enough: every plant has more operational work than expert hours available. The constraint is the same as everywhere else on this page — an assistant reasoning over raw tag names produces plausible answers nobody can verify. One reasoning over an asset model produces answers with a path back to a signal.
Because tags, context and data structures differ between sites. The solution is portable; the data pipeline underneath it usually isn't, unless the data model was standardized first.
This is the most expensive misdiagnosis in industrial AI. The first deployment proves the use case. The second reveals that tags, context and structures differ at every site — and the team concludes the model needs retraining, when what actually needs rebuilding is everything beneath it.
None of the six solutions above work on raw tag data. Each needs signals that carry their asset relationship, units and time context, and whose lineage back to source is traceable. That's why industrial AI programmes are usually gated by data readiness rather than model availability.
The one with a measurable outcome and a named owner, at one site, for one asset class. Predictive maintenance and quality inspection are the most common entry points because both have bounded data scope and a result you can put a number on.
Two practical rules beyond that. Build the data model for the asset class rather than for the pilot — if it only describes the machines in one plant, it won't travel. And connect a second site before declaring the pilot successful, because that's where architecture problems surface. Finding them at site two is cheap. Finding them at site twenty is not.
Providers fall into three groups: specialist application vendors covering one domain, automation and enterprise software vendors embedding AI into suites manufacturers already run, and industrial data platforms supplying and governing the operational data those applications depend on. Most manufacturers end up using more than one.
Litmus is in the third group. The solutions above run on the Litmus Industrial Data Foundation — connectivity to PLCs, DCS, SCADA, historians and MES without requiring an OPC UA server or SCADA layer; contextualization into reusable models for assets, lines and facilities; lineage back to the tag through Litmus Data Catalog; and local execution for the models that have to run inside the plant, including GPU-accelerated vision at line speed and small language models hosted in air-gapped sites.
The evidence that matters for solutions work is multi-site: a food and beverage manufacturer reached 95 global sites in 18 weeks on template-based rollout, Niagara Bottling standardized across more than 50 plants streaming to Databricks, and Jaguar Land Rover runs 126 edge deployments.
Litmus is also one of the few platforms in this category still independent — Schneider Electric is acquiring Cognite and already owns AVEVA, TPG assembled Velotic from Kepware, ThingWorx and Proficy, Bosch acquired Uptake, and Emerson owns AspenTech. For a manufacturer running mixed automation brands, that matters: a platform owned by an automation vendor has a structural reason to work best inside that vendor's equipment.
Start with one solution. Build the foundation that carries the rest. Book a demo or try Litmus Edge free →
Applications of machine learning, computer vision, language models and AI agents to specific manufacturing problems — predictive maintenance, quality inspection, energy optimization, OEE, anomaly detection and digital twin among the most common.
Three groups: specialist application vendors covering one domain, automation and enterprise vendors embedding AI in their existing suites, and industrial data platforms supplying and governing the operational data those applications run on. Most manufacturers use more than one.
The one with a measurable outcome and a named owner, at one site, for one asset class. Predictive maintenance and quality inspection are the most common entry points because both have bounded data scope and a result you can quantify.
No. They run on data from the PLCs, SCADA platforms, historians and MES already in place.
Can Industrial AI solutions run without cloud access?
Several can. Vision inspection, anomaly detection and operator assistance run locally inside the plant, including in fully air-gapped environments. Model training and cross-site benchmarking are better suited to the cloud.
Because tags, context and data structures differ between sites. The solution is portable; the data pipeline underneath it usually isn't, unless the data model was standardized first.
Traditional Industrial AI deployments take 12 to 18 months to reach production, most of it data work. Where a standardized data foundation already exists, individual use cases deploy in days.