Your system is showing a green status. The final value is within tolerance, the Cpk is stable, and the shift is running smoothly. Six weeks later, a complaint comes in, and in the post-analysis, these very screw connections show a curve that deviates from all the others—not in the final value, but in the path leading up to it.
A threshold value couldn’t detect this because it checks only a single data point. This is precisely where AI anomaly detection comes in, and the crucial question isn’t whether it works, but how it specifically analyzes your production data.
THE MOST IMPORTANT POINTS IN A NUTSHELL
|
IN A NUTSHELLAI anomaly detection shifts quality inspection from the end result to the process flow. Instead of asking whether the final value falls within the tolerance range, it asks whether this process looked the same as thousands of processes before it. In this way, it identifies deviations that fall within all specified limits but still indicate a problem: incipient tool wear, unusual batch behavior, or a joint that behaves differently than it did yesterday. Success depends less on the model itself than on three practical prerequisites: complete process data with unambiguous assignment, a narrowly defined initial use case, and a deliberately controlled false alarm rate. |
What is AI anomaly detection, and how does it analyze manufacturing data?
AI anomaly detection is a method that learns a model of normal process behavior from historical manufacturing data and then evaluates each new data point based on how far it deviates from this normal model. The result is not a “good” or “bad” classification, but rather a deviation value known as an anomaly score. Only when a predefined threshold is exceeded does this trigger an alert.
The key difference from traditional inspection lies in the object being inspected. A limit value inspection evaluates a single measured value against a fixed specification. An anomaly model evaluates a pattern: the trajectory of a curve, the relationship between several parameters, or the trend over the last hundred cycles. This is why it detects deviations that fall within the tolerance range.
Three terms distinguish practice from theory and should be used correctly from the outset. An anomaly is a statistical deviation from the learned normal state. A fault is a deviation from the customer’s requirements profile. A failure is the loss of function in a component. An anomaly model detects anomalies. Whether this results in a defect is determined by expert evaluation, not by the algorithm. Clearly defining this distinction is essential for a quality team to trust the system.
Regarding the scale on which such evaluations take place:
| Key metric | Value |
|---|---|
| Screw connections per day in an axle production line | More than 30,000, distributed across 80 connected screwdriving systems |
| Archived process data records per plant and month | More than 130 million |
| Cost factor per process step that a defect continues through | approximately a factor of 10 |
| Common minimum requirement for process capability | Cpk greater than or equal to 1.33 |
| Deadline for standalone high-risk AI under Annex III | December 2, 2027 |
These figures explain why the evaluation cannot be performed manually. With 30,000 bolted joints per day, a sample of 100 units covers 0.3 percent of the volume. An anomaly model checks 100 percent. This is precisely where the leverage lies, and it is a volume-based leverage, not an intelligence-based one. The article on process data analysis in quality assurance illustrates exactly how the transition from sampling to full evaluation takes place.
What manufacturing data is suitable for analysis?
Not every dataset is suitable for anomaly detection. The key factor is whether the data reflects the process itself or only its outcome. Four types of data are commonly encountered in discrete manufacturing, and each requires a different approach.
| Data Type | Typical Source | What the analysis reveals | Data Requirements |
|---|---|---|---|
| Scalar Values | Final torque, final angle, press force, press-in depth, test values | Shifts in the mean value, increased dispersion, outliers resulting from the interaction of multiple values | Low; usually already available |
| Time series and curves | Torque-angle curve, force-displacement curve, temperature profile, adhesive application curve | Shape deviations over time with an unremarkable final value, settlement behavior, joining defects | High, requires complete curve storage |
| Event data | Tool change, program change, alarms, batch change, shift change | Correlations between process events and clusters of deviations | Moderate; requires synchronized timestamps |
| Image data | Camera stations, micrographs, surface inspection | Optical deviations not captured by any measured value | High, requires labeled sample images |
The second type is the most interesting. Curve data contains significantly more information than the final value, but in many companies it is discarded after a short time because it takes up storage space. This results in the deletion of precisely the data set that makes anomaly detection possible in the first place. The patterns found in such curves and their underlying causes are described in detail in the article on screw-in curves, their patterns, and causes.
A practical rule of thumb for preliminary selection: If you could plot the process on a graph and an experienced process engineer could tell from it that something is unusual, then a model can learn it too. If that same information isn’t recorded at all, no algorithm will help.
Where does threshold monitoring end and AI anomaly detection begin?
This question determines the investment. If thresholds and statistical process control are sufficient, no one needs a model. The difference can be described as a ladder with four rungs, where each rung detects something that the one below it does not.
| Level | Subject of Inspection | Detects | Does not occur |
|---|---|---|---|
| 1. Limit value check | A measured value against a fixed specification | Clear tolerance violations | Anything that deviates within the tolerance |
| 2. Statistical process control | Distribution and trend of a metric over time | Shift in the mean, increase in dispersion, trends | Shape deviations within a stable distribution |
| 3. Univariate anomaly detection | Shape of a single data series compared to thousands of reference series | Curve outliers with a correct final value | Deviations that only become apparent when multiple features are considered together |
| 4. Multivariate anomaly detection | Interaction of many features simultaneously | Combinations that are unremarkable when considered individually | Causes that are not reflected in the data |
The honest assessment is this: Levels one and two handle the bulk of the work and are mandatory, not optional. IATF 16949 Section 9.1.1.1 requires the monitoring and measurement of manufacturing processes, and the statistical metrics for this are well-established. Those who do not have this foundation in order will gain nothing from a model; instead, they will only end up with an additional source of alerts built on an unstable foundation. The fundamentals for this are covered in the article on the calculation and interpretation of Cpk and Ppk.
AI anomaly detection is worthwhile starting at level three, specifically when two conditions are met: The process generates historical data, and there are documented cases in which a component caused problems despite being rated as good. The second point is more important than the first. Without such cases, there is no evidence that a gap exists at all.
Which methods specifically analyze production data?
The term “AI” encompasses a wide variety of methods with very different requirements. When making a selection, what matters is not which method is more modern, but which one is best suited to the data type and the available historical data.
| Method | How It Works | Suitable for | Limitations in Practice |
|---|---|---|---|
| Statistical distance methods | Distance of a data point from the center of the distribution, calculated in multiple dimensions | Scalar values, few features | Assumes approximately normally distributed data |
| Isolation Forest and related tree-based methods | Randomly splits data points and measures how quickly a point becomes isolated | Scalar values, many features, short history | Provides little explanation as to why a point stands out |
| Curve comparison with dynamic time warping | Compares curves of different lengths point by point along the time axis | Screw-in and press-fit curves | Computational complexity increases with curve length and reference set size |
| Autoencoder | Learns to reconstruct valid curves and flags where the reconstruction fails | Time series with extensive credit history | Requires many thousands of good examples per variant |
| Multivariate models across process windows | Evaluates multiple features and time windows together | Chained processes, plant networks | Requires synchronized data across stations |
| Supervised classification | Learns from labeled "good" and "bad" examples | Recurring, known error patterns | Requires a sufficient number of bad examples, which are rarely available |
The last point is the most common misconception in preliminary discussions. In a well-running production process, there are hardly any defective parts—often fewer than one in ten thousand. That’s not enough for a supervised model. That is why anomaly detection in manufacturing is predominantly unsupervised: it learns exclusively what “good” looks like and flags anything that looks different. This distinction between anomaly detection and defect classification is also at the heart of the distinction between predictive maintenance and predictive quality.
How does the evaluation process work, step by step?
The evaluation process is like a chain. If one link breaks, the result is worthless, regardless of the model's quality. Seven steps describe the path from the sensor to the feedback to the production line.
- Data Acquisition. The system delivers process data via a machine interface; in discrete manufacturing, this is typically done via OPC UA or a manufacturer-specific interface. It is crucial that the complete data history is transmitted, not just the aggregated final value.
- Mapping. Each data record is uniquely linked to a serial number, station, joining point, program, and tool. Without this mapping, a notification cannot later be traced back to a specific component, and the chain of evidence is broken.
- Synchronize. Experience shows that timestamps from different control systems drift apart. Before any analysis spanning multiple stations, the clocks must be synchronized to a common time base; otherwise, the time offset will create spurious correlations.
- Define characteristics. Evaluable parameters are derived from the raw data: slopes in defined sections, area under the curve, time of force increase, number of direction changes. This step is purely engineering work and determines the quality of the result more than the choice of algorithm.
- Establish a reference. The normal model is learned from a defined historical data set. The time period must be long enough to cover normal fluctuations: different batches, shifts, tool conditions, and ambient temperatures. References that are too short will trigger alarms for every legitimate fluctuation.
- Evaluate and set thresholds. Each new data point receives an anomaly score. The threshold at which an alert is triggered is an operational decision, not a technical constant. It determines how many alerts are generated per shift.
- Report back and document. The alert must reach the appropriate personnel who can take action, and the evaluation must be stored in an audit-traceable manner along with the data record. Otherwise, there will be no reliable evidence during a review of which unit was evaluated, when, and how.
Steps two, three, and four are where the bulk of the effort lies in projects. The model itself is rarely the problem. How to make effective use of the necessary historical data is described in the article on evaluating process history for improvements.
The algorithm is never the bottleneck in these projects. The bottleneck is whether each data record is uniquely linked to a component. If you don’t have that, you buy a model and end up with a guess.
Amadeus Lederle, CTE, CSP Intelligence GmbH
What level of data quality does an anomaly model require?
This question often comes up late in projects, but it should be addressed first. A model is only as good as the dataset from which it learns. Five criteria determine whether the existing dataset is sufficient.
| Criterion | Requirement | Typical shortcoming in practice |
|---|---|---|
| Completeness | Every cycle is recorded, including those that were aborted or reworked | Only confirmed good cycles are saved in the archive |
| Resolution | Curves with sufficient data points covering the entire course | Only final values are saved; the curve is discarded after a certain number of days |
| Traceability | Unique key based on serial number and assembly location | Data record is linked to the station, not to the component |
| Temporal consistency | Common time base across all controllers | Clocks drift; sequence cannot be reconstructed |
| Tagged history | Known periods of good performance and documented problem cases | Complaints cannot be traced back to process data |
A practical rule of thumb from CSP customer projects applies to the data volume: To establish a stable curve model for each variant and joining station, several thousand good cycles from at least one complete period covering the usual fluctuations should be available. With twenty variants per line, this means that the data issue must be resolved before the modeling issue can be addressed.
The most important point is the fifth criterion, and it is regularly underestimated. Without linking a complaint to a process data set, it is impossible to prove that a model is identifying the correct issues. This link is precisely a matter of traceability and data retention, not analytics.
A common mistake that occurs time and again: Many companies launch an AI project with a data export compiled by IT for the pilot. The model delivers good results in the lab but fails in production because the export was cleaner than the ongoing data collection. Test the model exclusively on data generated in the same way it will be generated later in production. A pilot based on exported data proves nothing about production.
How do you keep false alarms under control?
The most common reason why an anomaly detection system is turned off again after three months is not under-detection, but alarm fatigue. If the threshold is set too high, it generates more alerts than the team can evaluate. Alerts that no one evaluates are worse than no alerts at all, because they create a false sense of security.
Two metrics control this and should be considered together from the start. Precision indicates what percentage of alerts turn out to be relevant. The recall rate indicates what percentage of actual problems are reported. You cannot maximize both at the same time. A more sensitive threshold increases the hit rate and decreases precision; conversely, a stricter threshold does the opposite.
| Design | Alerts per shift | Consequence | Recommended for |
|---|---|---|---|
| Very sensitive | More than the team can handle | Alarm fatigue; the system is ignored | Never in continuous operation |
| Capacity-oriented | As many as can be safely assessed | Every report is processed, building trust | Standard practice in mass production |
| Conservative | Few, only clear-cut cases | High precision; individual cases remain undetected | Start-up phase; safety-critical joints as a second level |
| Two-stage | A few immediate alerts plus a collective analysis | Intervention only in clear-cut cases; the remainder treated as trend analysis | Proven structure established after the pilot phase |
The practical approach is capacity-based design: First, determine how many reports your team can realistically evaluate per shift, and then set the threshold accordingly. Not the other way around. This sequence sounds trivial, yet in the majority of projects, it’s done the wrong way around.
Additionally, separating intervention from evaluation is helpful. An immediate shutdown is justifiable only with very high precision. Anything below that threshold works better than a daily batch evaluation, in which a process engineer reviews clusters by station, tool, or batch. The same logic applies to alarm notifications during ongoing operations, as described in the article on the benefits and costs of real-time monitoring in manufacturing.
What obligations does the EU AI Act impose on AI in manufacturing?
This question comes up in every steering committee meeting, and the answer is more reassuring than many expect. The AI Regulation, Regulation (EU) 2024/1689, has been in effect since August 1, 2024, and takes a risk-based approach. An anomaly detection system that monitors process data and alerts a quality team does not fall under the high-risk categories listed in Annex III, as those categories address application areas such as biometric identification, human resources management, creditworthiness assessments, and critical infrastructure.
The timeline has also changed. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on July 27, 2026, and postpones the obligations for standalone high-risk systems under Annex III from August 2, 2026, to December 2, 2027. For high-risk AI embedded in products that are already regulated—that is, those covered by Annex I, such as machinery and medical devices—the deadline is now August 2, 2028. The Omnibus Directive has also narrowed the definition of a safety component, so that systems that merely assist a person are no longer classified as high-risk.
Two points, however, remain relevant and are not mere formalities:
|
The second point is the more challenging one in practice. A model is retrained over time, and then a different model version evaluates the same type of data differently. If this is not recorded with version information, the evaluation cannot be explained years later. The requirements for such evaluation traces align with those for quality data in audit reports.
This classification is intended as a technical guide and does not constitute legal advice. The classification in individual cases depends on the specific application.
How much does a pilot project cost, and when does the analysis pay off?
The costs rarely lie where one might expect. Licensing or computing costs for the model are usually the smaller portion. The four major areas are data acquisition, feature engineering, the evaluation process, and operations.
| Cost Category | What’s Behind It | Share of Total Effort |
|---|---|---|
| Data Acquisition | Equipment integration, complete curve storage, assignment by serial number | High, often the largest category |
| Attribute definition | Derivation of analyzable parameters from raw data, in collaboration with process engineers | Medium to high |
| Model and threshold | Training, validation, threshold determination | Low to medium |
| Evaluation process | Who evaluates reports, within what timeframe, and with what level of escalation | Medium—this is usually underestimated |
| Operation and follow-up training | Model maintenance for product changes, versioning of assessments | Ongoing |
A simple cost-benefit analysis is key to economic efficiency. According to the “rule of ten” for error costs, an error costs about ten times as much once it progresses to the next process stage. An error that reaches the customer thus incurs many times the cost of rework on the production line. For safety-critical joints, there is also the risk of liability and product recalls, which cannot be meaningfully expressed in terms of rework costs.
A robust initial approach is therefore not a broad-based project, but a narrowly focused pilot: one production line, one joint, one specific hypothesis based on a real customer complaint. The pilot is evaluated against existing sampling practices, not against a theoretical optimum. A pilot that, within this narrow scope, demonstrably identifies cases that the random sampling did not detect justifies expansion. A pilot without this narrow scope generates discussions rather than results. The overview of AI in quality assurance in manufacturing illustrates how these benefits fit into a broader approach.
How does the Manufacturing OS analyze production data?
CSP’s Manufacturing OS is the integrated platform on which process data acquisition, quality inspection, operator guidance, and audit-proof archiving operate on a shared database. Three components within the system are relevant for the analysis of production data, and they cover exactly the chain described in this article.
The IPM module automatically captures process data at the production line—including complete curve histories—and links each data record to the serial number and the assembly location. This covers steps one and two of the analysis chain—precisely the point where most AI projects fail. Alerts for deviations are triggered in real time.
The QST module covers the planning, execution, and evaluation of quality inspections, including proficiency testing for screwdriving tools and test equipment. This is relevant for anomaly detection because an unusual curve can have two causes: the component or the tool. Without tool verification, this question remains unresolved.
The CHRONOS module handles long-term archiving in an open format and ensures the database remains accessible even years later. This is essential for a model to learn from a sufficiently long history and for an audit evaluation to remain traceable later on, rather than disappearing into a decommissioned legacy system.
Because all components are part of the same platform, the serial number serves as the consistent primary key from data capture through evaluation all the way to the archive. This is precisely what distinguishes an integrated evaluation from a separate analysis tool that relies on exported data. The solution for anomaly detection in manufacturing is described in detail on the Solutions page.
Frequently Asked Questions
What is AI-powered anomaly detection in manufacturing?
AI anomaly detection is a process that learns a model of normal process behavior from historical manufacturing data and then evaluates each new data point based on how much it deviates from that model. The evaluation considers not only the final value but also the entire trend and the interaction of multiple features. The result is a deviation value that only triggers an alert once it exceeds a set threshold.
What manufacturing data can AI analyze?
Four types of data are relevant in discrete manufacturing: scalar values such as final torque and pressing force; time series and curves such as torque-angle profiles or force-displacement curves; event data such as tool and batch changes; and image data from inspection stations. Curve data provides the most information because it shows deviations in the trend, even while the final value remains within tolerance.
How does anomaly detection differ from SPC and limit monitoring?
A limit check evaluates a measured value against a fixed specification. Statistical process control evaluates the distribution and trend of a metric over time. AI anomaly detection evaluates the shape of a trend against thousands of reference trends and the interaction of multiple characteristics. These three levels are not mutually exclusive but build upon one another.
How much data does AI anomaly detection require?
To create a stable curve model, several thousand good cycles should be available for each variant and joint location from a time period that covers normal fluctuations: different batches, shifts, tool conditions, and environmental conditions (source: empirical data from CSP customer projects). Reference periods that are too short trigger alerts for every legitimate fluctuation.
Does AI anomaly detection also work on-premises without the cloud?
Yes. The analysis of process and curve data can be conducted entirely within the company’s own data center, as the models are trained on the company’s own process data and do not require external model services. This is typically the case for companies with data sovereignty requirements or with customer specifications prohibiting cloud processing.
How many false alarms are normal, and how can they be reduced?
There is no universal benchmark, because the number of alerts is determined by the threshold setting. The most reliable approach is capacity-based design: First, determine how many alerts your team can reliably evaluate per shift, and then set the threshold accordingly. It also helps to separate immediate alerts for clear-cut cases from daily batch reviews for clusters of alerts.
Is anomaly detection in production considered a high-risk AI system under the EU AI Act?
Generally not. Annex III of Regulation (EU) 2024/1689 addresses application areas such as biometric identification, human resources management, and critical infrastructure—not process monitoring in manufacturing. However, the requirement for AI competence under Article 4 has applied to all operators since February 2, 2025. The implementation deadlines for high-risk systems were postponed to December 2027 and August 2028, respectively, by Regulation (EU) 2026/1744. This case-by-case classification does not replace legal advice.
Is AI anomaly detection also worthwhile in mechanical engineering for small production runs?
The benefit does not depend solely on the number of units produced, but rather on the ratio of inspection effort to potential damage. With small production runs, there is often insufficient data to create a variant-specific model, but the damage per unit is usually high. A sensible starting point in such cases is the cross-variant analysis of a common joint or curve analysis of safety-critical connections, rather than a comprehensive model covering all variants.