In mechanical engineering, AI projects work when the data foundation already exists. Six use cases repeatedly carry their weight in practice: predictive maintenance, visual quality inspection, production planning, quotation costing, service requests, and generating technical documentation. What separates them is not the technology but the data each one presumes — and whether you have it.
This article walks through all six. For each, you get what it requires and when it is not worth doing. The second is the more useful one.
Which AI use cases exist in mechanical engineering?
| Use case | Data foundation | Effort | Not worth it when |
|---|---|---|---|
| Predictive maintenance | sensor data across several documented failures | high | failures are rare or poorly logged |
| Visual quality inspection | a few hundred images per defect class | medium | defect patterns keep changing or lighting cannot be controlled |
| Production planning | order, capacity and setup-time data from the ERP | medium–high | planning is in practice driven by shouted requests and exceptions |
| Quotation and costing automation | historical quotes including post-calculation | low–medium | every quote is a genuine one-off |
| Service and spare-part requests | ticket history, spare-part catalogue, machine records | low | request volume is small |
| Generating technical documentation | existing manuals, terminology, modular structure | low–medium | every machine starts documentation from scratch |
The rightmost column decides project success more often than the two before it. Skip it and you reliably rebuild the expensive third of our five most common mistakes in AI projects.
1. Predictive maintenance
A model recognises from sensor readings that a failure is developing and raises it before the machine stops. The appeal is obvious: unplanned downtime is the most expensive class of disruption in mechanical engineering.
What it requires: sensor data covering a period that contains several real failures, plus a maintenance history that dates and names those failures. A model learns from examples. Three documented bearing failures are not a basis for learning.
When it is not worth it: when failures are rare — precisely then the examples are missing. And when maintenance happens in the technicians’ heads rather than in a system. In that case the first project is not AI, it is dependable data capture.
The alternative that gets overlooked: anomaly detection. It flags deviations from normal operation without predicting the specific fault. It needs no failure history, only a clean baseline — which makes it the more realistic entry point for many operations.
2. Visual quality inspection
A camera checks parts for surface defects, dimensional deviation or completeness. This is the longest-established use case on this list and technically the most mature.
What it requires: images of good parts and of every defect class to be detected — in the order of a few hundred per class. Above all, though: reproducible capture conditions. Lighting, distance and angle have to stay constant.
When it is not worth it: with constantly changing defect patterns in small batch sizes. And when inspection does not fit into a fixed station because the part is too large or the inspection point too variable. The mechanics around it are frequently more demanding than the model.
3. Production planning and scheduling
Sequencing orders, minimising setup times, balancing capacity against deadlines. Classic optimisation, in which AI helps where the rules are too tangled for a formula.
What it requires: order data, capacities and realistic setup times from the ERP. The word “realistic” carries the weight here. Setup-time master data untouched for years produces a plan nobody follows.
When it is not worth it: when actual planning is driven by shouted requests, rush orders and side agreements. An optimised plan that the shop-floor supervisor overturns each morning improves nothing. The problem is then organisational, not computational.
4. Quotation and costing automation
Deriving a preliminary costing from an enquiry and a drawing, based on comparable past orders. The quietest use case on this list and frequently the one with the best effort-to-effect ratio.
What it requires: historical quotes — and, more importantly, their post-calculation. Without the comparison between estimated and actual, the system learns to reproduce your old misjudgements.
When it is not worth it: for genuine one-offs with no repeat parts. As soon as a modular system or a part family exists, however, the use case takes hold quickly.
5. Service and spare-part requests
Pre-qualifying incoming service requests, finding the right spare part for a machine number, answering recurring questions directly. The lowest-threshold entry point on this list.
What it requires: a ticket history, a maintained spare-part catalogue, and the link between machine number and installed configuration. That last link is missing more often than expected and is the real effort driver.
When it is not worth it: at low request volume. If two people handle service on the side, automation saves less than its upkeep costs.
6. Generating technical documentation
Producing operating manuals, maintenance schedules, change descriptions and translations from existing building blocks rather than writing each one anew. Relevant beyond the effort saved: the Machinery Regulation (EU) 2023/1230 replaces the previous Machinery Directive from January 2027 and explicitly permits digital provision of the operating manual. If you have to touch your documentation anyway, you can address the process at the same time.
What it requires: existing manuals as templates, reasonably consistent terminology, and a modular structure from which variants can be derived.
When it is not worth it: when every machine starts documentation from zero. The reusable part is then missing, and review effort eats the time saved.
Which use case should come first?
Not the one with the biggest lever, but the one with the best data. This order has proven itself:
- First the use case whose data is already structured — usually quotation costing or service requests. It delivers an early result you can use internally to show the approach holds.
- Then the one with the biggest lever — often predictive maintenance or production planning. Both need lead time in data capture, which can run alongside the first project.
- Add data capture as you go, not up front. Starting with a two-year data programme loses you internal backing before the first result arrives.
We broke down what this costs, with ranges and a worked example, in What does an AI project cost?. The short version: the effort rarely sits in the model but in data preparation — regularly 40 to 60 percent of the project.
What about engineering design and standards search?
Searching existing engineering documents, standards and project records is a use case in its own right — and a very real one. It is deliberately absent from this article.
The reason is a clean separation: anyone who wants to search and cite documentation and standards is looking for a tool, not a project. That is what KoAssist is for — an assistant that answers from your own documents and cites file and page alongside. In engineering that is not a convenience but the condition for an answer being usable at all.
Generating documentation, by contrast, is an engineering service, which is why it appears above as use case 6.
How does a pilot project start?
Four steps that have proven themselves in mid-sized manufacturing:
- Pick the use case by data, not by enthusiasm. The table above exists for that.
- Data review before development. Two to three days in which somebody actually opens the data. This review has prevented projects, and every time that was the cheaper outcome.
- A bounded proof of concept. One use case, one machine or one product family, one measurable criterion defined in advance.
- Decide on integration and operations only afterwards. Anything running in production has to be maintained, monitored and updated. Those costs belong in the calculation from the start, not in hindsight.
If you have a specific use case in mind and want to know whether your data supports it, we will look at it with you in a free initial consultation — including when the honest answer is “not yet”.
FAQ
Which AI use cases pay off first in mechanical engineering?
The ones whose data already sits structured in your systems: quotation and costing automation, and service and spare-part requests. Both build on ERP and ticket data that is maintained anyway. Predictive maintenance is more attractive but needs sensor data spanning several documented failures, which makes it a poor first project.
What is the most common reason an AI use case fails in mechanical engineering?
Missing or unusable data. The bottleneck is not the model but whether the required data is captured at all, exists in sufficient volume, and is linked to what it describes. In practice, data preparation regularly accounts for 40 to 60 percent of project effort.
Does predictive maintenance require historical failure data?
For the classic approach, yes. A model learns failure patterns from examples. With too few documented failures there is nothing to learn from. Anomaly detection is the alternative: it flags deviations from normal operation without predicting the specific fault, and needs no failure history.
Does searching standards and documentation belong to these use cases?
It belongs to mechanical engineering, but we do not file it under AI consulting. Searching existing engineering documents and standards with a citation down to file and page is a product topic and sits with KoAssist. Generating technical documentation, by contrast, is an engineering service and is covered in this article.
How large does a manufacturer need to be for AI?
Headcount is the wrong measure. What matters is whether a process repeats often enough for automation to pay off, and whether the underlying data exists digitally. A 40-person operation with a clean ERP has better conditions than a 400-person operation whose knowledge lives on paper.
