AI in Manufacturing: Both Benchmark Numbers Are From 2017
Manufacturing has the strongest evidence base of any sector for AI delivering measurable returns, and among the lowest adoption rates.
Both halves are worth unpacking, because the explanations differ. Start with the evidence, because it is older than its repetition suggests.
Both benchmark numbers date from 2017
Search for predictive maintenance returns and two figures appear, usually quoted together without their provenance.
The optimistic one: a 30–50% reduction in machine downtime with equipment life extended 20–40%. It traces to Manufacturing: Analytics unleashes productivity and profitability, McKinsey, 2017.
The conservative one: equipment uptime up 10–20%, overall maintenance costs down 5–10%, maintenance planning time down 20–50%, MRO material spend down 5–10%. It comes from Deloitte’s Industry 4.0 maintenance work of the same period — the ranges appear in the Deloitte Analytics Institute position paper on predictive maintenance, alongside Industry 4.0 and predictive technologies for asset maintenance, published by Deloitte Insights on 9 May 2017.
Both are nine years old, and both predate the current AI wave entirely.
That is not a reason to discard them. Predictive maintenance is a considerably older discipline than generative AI — condition monitoring, vibration analysis and failure modelling were mature practices long before anyone used the phrase “AI in manufacturing industry”. The underlying physics has not changed, and the figures remain the best published benchmarks available.
It does mean two things.
Anyone presenting these as evidence of what AI delivers in 2026 is misrepresenting them. They describe analytics-driven maintenance programmes of the mid-2010s. Whether current models improve on that is an open question the published literature has not answered.
The two figures describe different things, and the gap between them is where business cases fail.
| Measure | McKinsey, 2017 | Deloitte, 2017 |
|---|---|---|
| Downtime / uptime | 30–50% less downtime | 10–20% more uptime |
| Maintenance cost | — | 5–10% lower |
| Equipment life | 20–40% longer | — |
| Maintenance planning time | — | 20–50% lower |
| MRO material spend | — | 5–10% lower |
McKinsey describes mature, well-run programmes — the ceiling. Deloitte’s ranges, drawn partly from client work, describe what disciplined operators in ordinary factories achieve.
Plan against Deloitte. Treat McKinsey as the upside. A business case built on the first set and delivered against the second fails even when the project succeeds.
A third figure in circulation — maintenance cost reduction of “10–40%”, also attributed to McKinsey — appears as 10–40% in some citations and 18–25% in others. Treat it as drifted rather than quote it.
One documented example worth knowing. Deloitte’s 2017 Insights paper describes a pilot on a single asset class — extruders — that cut unplanned downtime by 80%, with cost savings of around $300,000 per asset. That is far above both published ranges, and it is a pilot on one well-chosen asset class rather than a plant-wide result. It illustrates the real shape of these programmes: concentrated returns on the right assets, diluted across everything else.
Why adoption is low: the prerequisite is physical
The MaintainX 2026 Maintenance Trends Report found two-thirds of maintenance teams planning to adopt AI by year end, with only 32% having partially or fully implemented it. IoT Analytics put predictive maintenance AI deployment at 38% of manufacturers by 2025.
The gap is not scepticism and it is not budget. Manufacturing AI has a prerequisite the other sectors do not: the data has to be physically collected before any of it is possible.
In most enterprise functions the data already exists. Finance has transactions, HR has applications, support has tickets. They may be messy or badly owned, but they were recorded, because the business could not operate otherwise.
A machine that has never been instrumented produces no data at all.
Predictive maintenance needs vibration, temperature, current draw, acoustic signature or pressure, sampled often enough to catch degradation and stored long enough to learn from. If the machine has no sensors, there is nothing to model. If it has sensors feeding a local PLC that overwrites every shift, there is nothing to learn from. If the historian keeps the data but nobody recorded which alerts turned out to be real failures, there is no label to train against.
That is a capital equipment and systems integration problem before it is a software problem, and it explains the adoption gap more completely than any cultural theory.
It also explains why the published returns look strong. The manufacturers who cleared the prerequisite had generally invested in instrumentation for other reasons, which means the population reporting results is self-selected for data maturity. Their numbers are real. They are also not predictive of what happens in a plant starting from no sensors.
The first question in any manufacturing AI initiative is not which use case to pick. It is which assets are already instrumented and how far back the history goes.
The instrumentation layer this depends on — connectivity, protocols, and what industrial sensing actually involves — is covered in industrial IoT applications.
The readiness check, before anything else
Five questions. The answers determine which of the use cases below are even available.
- Which assets have sensors, and measuring what? Vibration, thermal, current, acoustic, pressure. An asset with none is not a candidate regardless of how critical it is.
- Where does that data go, and how long does it stay? A historian retaining two to three years is the usual threshold for predictive work. Data overwritten weekly supports monitoring, not prediction.
- Are failures recorded, and linked to the asset? The one most often missing. Sensor history without failure labels gives you anomaly detection, not failure prediction — two different products with two different business cases.
- Can OT and IT systems actually exchange data? Plant networks are frequently and deliberately isolated. The integration path is often the longest line item in the project.
- Who owns the shop-floor data? Operations, engineering and IT frequently each believe one of the others does.
Questions 1 to 3 can usually be answered in a week from existing documentation. That week is the cheapest work in the entire initiative, and it is what an AI readiness assessment does when applied to a plant rather than an office.
Find out which assets your data can actually support
The AI use cases in manufacturing, by data prerequisite
Six use cases, ordered by how much has to exist before any of them is possible. The summary first, the detail below.
| Use case | What has to exist first | Evidence strength | Where it usually breaks |
|---|---|---|---|
| Predictive maintenance | Sensors, historian retention, failure labels | Strongest — two independent benchmark sets, both 2017 | Missing failure labels; alerts that land in email rather than a work order |
| Visual inspection and defect detection | Cameras, consistent lighting and positioning, labelled defect images | Strong on repetitive, well-defined defects | Defect scarcity — a good line produces too few examples to train on |
| Production planning and factory automation | Accurate routings, cycle times, changeovers in MES or ERP | Moderate, inconsistently reported | Master data that drifted years ago |
| Generative AI on the plant floor | Documentation that exists and is current | Moderate, low risk | Knowledge that was never written down |
| Digital twins | All of the above, plus a process model | Varies enormously by what is meant | Three different things sold under one name |
| Agentic and autonomous operation | Everything above, plus a decision you are willing to delegate | Weakest in production | Scope that assumes no human in the loop |
The ordering is not by business value. It is by how far your plant already is from being able to attempt it.
Predictive maintenance
Prerequisite: sensors, historian retention, failure labels.
The strongest evidence base in manufacturing AI, with the caveats above on which figures to plan against.
What it breaks on — and it is rarely the model. Two failure modes dominate, and both are operational.
The first is failure labels. Plants routinely have years of sensor history and no reliable record of which anomalies preceded actual failures. Without labels you can build anomaly detection — useful, but a smaller and different business case than failure prediction.
The second is the alert path. A prediction that arrives as an email performs far worse than one that creates a work order in the maintenance system automatically. The prediction window a model buys you — often weeks — evaporates while the alert sits in an inbox waiting for someone to triage it. Programmes that miss their business case overwhelmingly miss it here rather than on model accuracy.
Design the path from prediction to work order before building the model. It is the cheapest decision in the project and the one most often deferred.
For the condition-monitoring methods underneath — vibration analysis, thermography, oil analysis, and how thresholds are set — see predictive maintenance techniques.
Related capabilities:
Machine learning
Predictive analytics
Visual inspection and defect detection
Prerequisite: cameras, consistent lighting and positioning, and labelled defect images.
Computer vision inspection outperforms manual inspection on repetitive, well-defined defect classes. The appeal is obvious: inspection is tiring, human accuracy degrades across a shift, and the cost of an escaped defect is usually known.
What it breaks on. Defect scarcity, which is a genuinely awkward problem. A well-run line produces very few defects, which means very few training examples of the thing you want to detect. Teams routinely discover they need to manufacture defects deliberately or synthesise them to assemble a usable dataset.
The second constraint is physical consistency. A model trained under one lighting condition and camera angle degrades when either changes, and shop floors change.
On the underlying technology — model types, accuracy trade-offs and deployment options — see image recognition software.
Production planning, scheduling and factory automation
Prerequisite: accurate routings, cycle times, changeover times and constraint data in the MES or ERP.
Weaker and less consistently reported than the two above, and the reason is instructive: the master data is frequently wrong. Routings reflect how a part was made when it was introduced, not how it is made now. Changeover times are estimates nobody has revalidated.
An optimisation model is only as good as the constraint data it optimises against, and in many plants that data has drifted for years. AI in factory automation fails more often on master data accuracy than on algorithm quality.
What it breaks on. This is the use case most likely to produce a technically correct answer that the floor ignores because it does not match reality.
The system layer this runs on is covered in manufacturing execution system architecture.
Generative AI in manufacturing
Prerequisite: documentation that exists and is current.
What works. Maintenance manual search, standard operating procedure retrieval, shift handover summarisation, and translating technical documentation for multilingual crews. Document-processing tasks with reasonable results and low risk, because a wrong answer is caught by the person reading it.
What it breaks on. Documentation quality, which in manufacturing is frequently worse than in office functions — procedures drift, the authoritative version lives in a binder, and the tribal knowledge was never written down at all.
Where the useful knowledge is not written anywhere, no retrieval system can find it. That is a documentation project wearing an AI costume, and it is worth naming as such before it is funded as the latter.
Related capability
Generative AI development
Digital twins in manufacturing
Prerequisite: everything above, plus a process model.
Clarify which of three things is meant before anything else. “Digital twin” is used for a live dashboard, a simulation model, and a full physics-based replica, and the gap between them is measured in orders of magnitude of cost and time.
- A live monitoring twin mirrors the current state of an asset or line from sensor data. Achievable once instrumentation exists, and genuinely useful — but it is a visualisation layer, not a predictive one.
- A simulation twin lets you test changes — a different schedule, a different line configuration — before making them. This requires a process model: a validated understanding of how the physical system behaves under conditions it has not yet encountered.
- A physics-based replica models the asset from first principles. Expensive, slow, and justified only where the asset is critical enough and the failure consequences large enough.
What it breaks on. The process model, almost always. Most plants have sensor data describing what happened and no validated model describing why. Buying a twin platform does not supply one — it supplies the place to put one.
The practical sequencing point: a live monitoring twin is a reasonable output of the instrumentation work the rest of this article argues for. A simulation twin is a separate project with a separate prerequisite, and conflating the two is how digital twin budgets overrun.
For the underlying technology and how it works across industries, see digital twin technology in practice.
Agentic AI in manufacturing, and how autonomous any of this should be
The vocabulary has moved faster than the deployments. “Agentic AI” and “AI agents in manufacturing” now describe what was previously called autonomous or closed-loop operation: a system that detects a condition, decides what to do about it, and acts — scheduling the intervention, adjusting the line, releasing the work order — without a person in between.
The capability is real and the framing is useful. The scoping question it raises is not new.
S&P Global’s 2026 research found that only 22% of AI projects across all sectors target a fully autonomous end state. The majority sit at minimal autonomy, where AI recommends and a person decides.
In a plant that is not caution, it is correct design. A maintenance prediction that schedules its own intervention without a planner reviewing it will eventually schedule one at the worst possible moment in the production plan. A quality model that rejects parts without human confirmation will eventually reject a batch that was fine. The cost of a wrong autonomous decision in manufacturing is measured in scrapped output and unplanned stoppages, which is why the human review point survives even in mature deployments.
Where agentic framing earns its place is the alert path described earlier — the gap between a prediction and a work order. An agent that converts a prediction into a scheduled, routed, parts-reserved work order for a planner to approve removes the delay that kills most predictive maintenance business cases, without taking the decision away from the person accountable for it.
That is the version with a defensible business case. Scope for it, and the rescope that most fully autonomous initiatives undergo around month four does not have to happen.
Where to start
The sequence follows data availability rather than ambition.
Start with the assets that are already instrumented, even if they are not the most critical. Proving the approach on a monitored asset population is faster and cheaper than instrumenting a critical asset and proving it there. Deloitte’s extruder pilot is the shape of this — one well-chosen asset class, concentrated return, then expansion to other critical equipment across facilities.
Separate anomaly detection from failure prediction in the scope and the business case. If failure labels do not exist, build the anomaly detection product and begin recording labels — which turns the first deployment into the data collection for the second.
Fix the alert path before the model. A prediction that lands in an inbox produces a fraction of the value of one that creates a work order.
Treat instrumentation as a separate, earlier project. Where sensors do not exist, that is capital expenditure with its own approval path and timeline, and bundling it into an AI business case tends to sink both.
Where the sequence usually has to start. The first project is frequently not an AI project. One CodeIT manufacturing engagement began with exactly the prerequisite this article describes: the team was brought in to digitalise existing manufacturing data, which meant first analysing the factory floor machines themselves, then building a production monitoring system around them. What was delivered was a dashboard giving centralised access to manufacturing data, real-time visualisation of information collected from production line machines, and a machine status viewer updating the state of each machine as it ran. The problems being solved were stated plainly: lack of visibility, and insufficient data analysis.
None of that is AI. All of it is the condition under which AI becomes possible — and the readiness questions above are unanswerable without it. Full write-up: manufacturing execution system implementation.
Where a specific uncertainty blocks the decision — whether existing sensor history is sufficient to predict a particular failure mode — a proof of concept answers it against your own data for a fraction of a build. Where teams disagree on sequencing across plants, AI advisory services cover the prioritisation.
CodeIT’s wider work in the sector sits under manufacturing software development.
Turn instrumented assets into a funded roadmap
FAQ
Predictive maintenance is the most established and best-documented, followed by visual inspection and defect detection. Production planning and factory automation, generative AI for documentation and procedures, digital twins, and agentic or autonomous operation follow. The ordering tracks data availability rather than business value — maintenance and inspection lead because sensors and cameras produce the data those models need.
It depends which figure you plan against, and both come from 2017. McKinsey puts the reduction in machine downtime at 30–50% with equipment life extended 20–40%, describing mature well-run programmes. Deloitte’s ranges for what disciplined operators typically achieve are lower: 10–20% improvement in uptime, 5–10% reduction in maintenance costs, 20–50% reduction in planning time. Use the second set for the business case and the first as the upside.
Both the optimistic and the conservative benchmark were published in 2017, before the current AI wave. They remain the best available published ranges, because predictive maintenance is an older discipline than generative AI and the underlying physics has not changed. But anyone presenting them as evidence of what AI delivers in 2026 is misrepresenting what they measured.
The term covers three different things: a live monitoring twin mirroring current state from sensor data, a simulation twin that lets you test changes before making them, and a physics-based replica modelling the asset from first principles. Costs differ by orders of magnitude. The live version is achievable once instrumentation exists. The simulation version requires a validated process model describing how the system behaves under conditions it has not encountered — which most plants do not have, and which buying a platform does not supply.
The current term for autonomous or closed-loop operation: a system that detects a condition, decides what to do, and acts without a person in between. The capability is real, but S&P Global found only 22% of AI projects across all sectors target a fully autonomous end state. In a plant the human review point usually survives, because the cost of a wrong autonomous decision is scrapped output and unplanned stoppages. The version with a defensible business case is narrower — an agent that converts a prediction into a routed work order for a planner to approve.
Because the prerequisite is physical. Other functions have data that was already being recorded for operational reasons. An uninstrumented machine produces nothing. Sensors, historian retention and OT/IT integration all have to exist before any model is possible, and that is capital equipment work with its own timeline. The MaintainX 2026 report found two-thirds of maintenance teams planning to adopt AI with only 32% having implemented it.
Three things: sensor data appropriate to the failure mode — vibration, thermal, current, acoustic or pressure; a historian retaining two to three years of it; and records of actual failures linked to specific assets. The third is the one most often missing. Without failure labels you can build anomaly detection, which is useful but is a different product from failure prediction.
Anomaly detection flags behaviour that departs from the normal pattern. Failure prediction states that a specific component is likely to fail within a specific window. The second requires labelled failure history; the first does not. They are often sold interchangeably and carry different business cases — scoping the one you can actually build avoids a difficult conversation later.
Most often because of the alert path. A prediction that arrives as an email rather than as an automatically generated work order loses most of the window it bought — the weeks of warning evaporate while the alert waits for someone to triage it. The model is rarely the problem; the workflow between prediction and action usually is.
Not for predictive maintenance or visual inspection. Document and procedure work — maintenance manual search, SOP retrieval, shift handover summaries — needs only existing documentation and is a reasonable starting point where instrumentation does not yet exist. Production planning depends on MES or ERP master data rather than sensors, though it depends heavily on that data being accurate.