Over the past three years, almost every conversation with industrial management has touched on artificial intelligence. Pull the word apart, though, and the answer usually narrows fast: a vision-inspection model running on one line, an anomaly-detection alert flagging a bearing-replacement window in one workshop, and not much beyond that. This is not a pessimistic observation. It is the starting point for describing how far industrial AI actually reaches today. Between the macro narrative of an industrial-intelligence transformation and the software actually running on the shop floor sits a gap wider than most analysts are willing to admit.
The first step in assessing an opportunity here is not asking whether a given model's accuracy is high enough — in most use cases that question is already settled; vision recognition and anomaly detection cleared the usability threshold years ago. The question worth answering is whether the capability has actually entered a customer's operating rhythm, or whether it still lives inside a demonstration project run by an innovation department, funded from a separate budget line, with no one accountable for the outcome. Early on, the two are almost indistinguishable from contract size or customer logos. Three years later, that distinction is the difference between still being on the customer list and having quietly fallen off it.
Four categories of deployment that are actually happening
Across the industrial customers and vendors we track, the AI applications that make it into an annual budget on their own merits, without a separate innovation-department sign-off, cluster into four categories. What they share is that their output translates directly into a metric a factory already tracks — defect rate, downtime hours, product-iteration cycle time — without requiring anyone to invent a new way of measuring success.
- Quality inspection: computer vision replacing or supplementing manual visual checks for surface defects, assembly errors and dimensional deviation. This is the highest-penetration category, for a simple reason — the cost of a defective unit already has a clear accounting line in most factories, so a vendor does not need to convince a customer that a new metric matters, only that an existing one can be improved.
- Process optimization: using line-level operating data to suggest parameter adjustments that stabilize yield and output consistency. This is harder to deploy than inspection, because it requires understanding the underlying process logic rather than just recognizing images, but once it works, switching cost is materially higher than for a quality system, since the parameter model has absorbed operating experience specific to that particular line.
- Predictive maintenance: using vibration, temperature or current signals to flag equipment anomalies early, converting unplanned downtime into a scheduled repair window. How quickly this pays off depends on how standardized the equipment is — the more standardized, the more a model can be reused across machines, and the faster a vendor's marginal delivery cost falls.
- R&D acceleration: handing repetitive computation in simulation, materials screening or design iteration to a model, shortening validation time. This category has the shallowest penetration, since R&D tolerates error poorly and engineers build trust more slowly than shop-floor operators — but once established, it is the stickiest, because it changes how a team works, not just one step.
Why pilots fail to scale
Most industrial AI projects die at the pilot stage, and the cause is rarely technical infeasibility. Three causes recur, and each is usually built into the project before it starts. First, the pilot is launched by a digital or innovation department with no direct accountability to the line manager who actually owns the budget and the performance metrics, so the project loses support the moment the innovation department's annual budget gets reallocated. Second, the pilot scenario is unrepresentative — the cleanest data and simplest process on a chosen line are used to prove the concept, and the result does not transfer to the genuinely complex lines. Third, the vendor concentrates delivery effort on the model itself and underestimates the engineering investment required on site, so nothing repeatable survives the pilot and every subsequent rollout starts from scratch again.
All three causes of death point to the same standard: whether an AI project can scale is largely decided at the moment it is approved, not after the model finishes training. When assessing an industrial AI investment, we spend more time asking who is paying for a given pilot and who is accountable for its outcome than we spend asking about model architecture.
The three variables that decide whether a vendor compounds
Shift the lens from a single project to the vendor itself, and the question becomes: what determines whether an industrial AI company, having won its first cohort of customers, can keep winning the next cohort while marginal delivery cost falls as the customer base grows. We think the answer concentrates on three variables, and all three are required — companies in our sample that possessed only one of them have each, at some point, stalled.
Workflow ownership: 1; Deployment muscle: 2; Data access: 3
Illustrative framework for organizing judgment, not a quantitative score
The ordering here is worth explaining. Data access is the foundation — without it, a model cannot iterate. A company with data access alone tends to have an impressive demonstration and a cost structure that collapses at expansion, unable to deliver on site efficiently. Strong deployment capability counts for little if output never leaves the realm of a suggestion and never embeds in the operating process — the vendor then remains a replaceable tool. Workflow ownership sits at the top because it only emerges once the other two work together, and it is hardest for a competitor to replicate quickly.
Implementation economics: the cost line that gets underestimated
The business model of industrial AI is often valued externally as if it carried software-level margins, and that is a systematic source of misjudgment. In most deployments that actually work, revenue splits roughly evenly between software licensing and on-site implementation services, and implementation often outweighs licensing — an engineering team has to be on site for installation, model training and line-specific calibration, work that is nearly impossible to automate in the early years and does not thin out quickly through scale. Applying a pure software valuation framework to this kind of company systematically overstates near-term margin and understates real operating complexity.
The more honest account of the economics is that this is a hybrid software-and-engineering-services business, with modest early margins, and its path to scale runs not through marginal cost approaching zero but through the accumulation of deployment method — each new-scenario deployment should make the next comparable one faster and less labor-intensive to deliver. Whether that downward trend is observable is the central evidence for whether a vendor is genuinely accumulating a barrier or simply repeating project-based revenue at constant labor intensity. When we assess these companies, we weight the trend in implementation cycle time and projects delivered per engineer over the past two to three years more heavily than the absolute margin in any given period.
How we track this inside manufacturing
Lanqing Intelligence is one window we watch this shift through — it began with computer-vision inspection in electronics manufacturing and has, over the past two years, been extending into materials and pharmaceutical lines. That extension is itself a live test of whether workflow ownership transfers across industries: the generality of the underlying algorithm lowers the technical barrier to entering a new sector, but materials manufacturers prioritize batch consistency and pharmaceutical lines operate under compliance requirements, differences that call for dedicated delivery teams rather than a copy of the existing configuration. Whether a company can build that new delivery capability while holding the line on discipline in its original business says more than any single quarter's contract value does.
Back to the original question: which parts of industrial AI are real. The answer has less to do with how advanced a given technology is than with whether a capability is embedded in what a customer does every day, whether a continuous flow of data lets it keep improving, and whether a vendor's deployment team has turned each delivery into a reason the next one will cost less. Deployments that satisfy all three keep expanding. The ones that do not, however impressive the demonstration, will most likely disappear at the next budget review, and no one in particular will notice them go.