AI in manufacturing: quality control, prediction, automation

A production line generates data in volumes no team of engineers can process manually. Temperature, vibration, and pressure sensors produce thousands of readings per hour. Cameras on inspection lines take hundreds of photos per minute. MES systems log every production event. This mountain of data has existed for years and has gone unused because the tools needed to process it in real-time were out of reach for everyone except the largest corporations.

In 2026, the situation is different. Vision models run on a standard server with a single GPU. Time-series sensor data is processed by an open-source analytics stack. AI agents coordinate information flow between systems without custom integrations. The problem is no longer technological—it has become organizational: which processes to tackle first, how to prepare data, and how not to buy a brilliantly designed demo that won’t survive contact with the production floor.

Not every manufacturing problem is suitable for AI implementation in the first step. Three areas stand out because they have clearly measurable costs and ready-made implementation patterns.

For most Polish manufacturing plants, quality control is the fastest result—visible within 6–10 weeks of implementation. Failure prediction requires several months of historical data, but the return is proportionally higher.

A classic visual inspector at the end of the line has several weak points: fatigue after 2–3 hours of work, subjective "defect" criteria, speed limited to a few dozen items per minute. A vision model has none of these problems and adds one bonus: every decision comes with an annotated photo as proof.

Typical stack for quality control:

1. Industrial camera on the line (GigE Vision or USB3) with appropriate lighting. Image quality matters more than the AI model.
2. Defect detection model trained on photos of your products. 200–500 photos per defect class is the minimum. Without your own labeled data, there’s no model tailored to your product.
3. Inference server at the line. Latency must be below cycle time (usually 100–500 ms). The cloud doesn’t work here because network latency exceeds time requirements.
4. Decision layer—the model signals a defect, the line control system stops or rejects the item. A human approves new defect classes, not every decision.

Where it doesn’t work: products with high visual variability of natural raw materials (wood, natural leather, seasonal food) require significantly more training data and regular model retraining. It’s worth starting with less variable components and gradually expanding the scope.

Predictive maintenance (PdM) is about predicting failures before they occur. The basic pattern: sensors collect machine condition data, an anomaly model detects deviations from the norm and generates an alert with enough lead time for a technician to schedule service during a planned window, not in the middle of a shift.

Three necessary conditions without which PdM won’t work:

Historical data with failure labels. The model must know what the data looked like hours or days before previous failures. Without a history of failures, only general anomaly detection is possible, not prediction of specific failure modes.

Appropriate sampling frequency. Bearing vibration detection requires sampling every few dozen milliseconds. Oil temperature can be sampled every minute. Matching frequency to the physics of degradation is key.

Integration with the service order system. An alert without automatic or semi-automatic service order creation is just another notification that can be ignored. An AI agent should close the loop: anomaly → service order → technician confirmation → repair log.

Expected effect in the first year: reduction of unplanned downtime by 20–40%, extension of mean time between failures by 15–25%. Exact numbers depend on how regularly machines were serviced before and how clean the historical data is.

The production floor generates stacks of documents daily: shift reports, production orders, NCR (non-conformance) cards, complaints, measurement protocols. Most are filled out by humans based on data already in the systems. This is a classic task for an AI agent with tools.

Typical automations with short payback time:

• Shift report automatically generated from MES data, with performance charts and event lists—the technician only approves, doesn’t write from scratch.
• NCR card created immediately after an item is rejected by quality control, with a defect photo, line, shift, and operator—no manual form.
• Complaint response drafted by a RAG assistant based on order history, product specifications, and previous responses to similar complaints.
• Production schedule optimized for orders, material availability, and machine service windows.

An n8n agent or similar workflow platform allows connecting these automations without custom code for each integration.

The most common reason AI projects in manufacturing end in disappointment: data isn’t in a state that enables training or inference. This isn’t a technical problem that an AI vendor solves. It’s internal work that must be done before implementation.

If your data is in the first three states, the first project should be data preparation, not model implementation. A solid data foundation pays off in every subsequent project.

AI systems controlling production processes fall under the AI Act as high-risk systems if they affect human safety or the quality of regulated products. Three requirements that must be met:

Human-oversight. The AI system can recommend stopping the line or rejecting a batch, but irreversible decisions (e.g., scrapping material worth >X PLN) should require human confirmation. A human-gate on high-risk actions is not optional.

Logging and explainability. Every model decision must be logged with the model version, input data, and result. When a customer or auditor asks why a batch was rejected, the answer must be specific and verifiable.

Agent security. Agents with access to line control systems or ERP must operate on the principle of least privilege. Guardrails block instructions outside the defined scope. Every irreversible action requires a confirmation token.

For regulated products (medical devices, food, automotive), the requirements are stricter. Before implementation, it’s worth conducting a DPIA for systems processing operator or customer data.

A pilot in manufacturing differs from a pilot in services. The environment is more demanding: dust, vibrations, variable lighting, integrations with legacy SCADA systems. A typical pilot scope lasts 8–14 weeks and includes:

• Weeks 1–2: data audit, process mapping, selection of one specific use case.
• Weeks 3–6: integration with source systems, preparation of training data, base model training.
• Weeks 7–10: deployment in shadow mode (model runs but doesn’t make production decisions—only compares with human decisions).
• Weeks 11–14: gradual takeover of decisions in the selected area, metric monitoring, confidence threshold calibration.

Shadow mode is key here. It provides real data to evaluate the model without production risk. It also shows operators how the model thinks before asking them to trust its decisions.

Estimated cost ranges for the first implementation: the inference calculator helps assess model costs. The total project cost (data, training, integration, deployment) depends on scope—details are discussed in a free pilot.

Describe one production process that causes you problems—defect rates, failure frequency, or time wasted on documentation. The model will indicate which approach fits your case and what data is needed to start:

No, it complements them. Statistical process control (SPC) monitors process parameters. The vision model inspects the finished product. Together, they provide a full layer: SPC catches process drift before defects appear, computer vision catches defects that occur despite a stable process. A company with good SPC implements computer vision faster because processes are better described.

The minimum is 200–500 photos per defect class, but quality matters more than quantity. Photos must represent real variability: different lighting, different item positions, defects at the limits of detectability. A model trained on 300 good photos beats a model trained on 2000 low-quality photos. Labeling is done by your quality expert, not an external provider who doesn’t know your standards.

It depends on the value of the machines and the cost of downtime. A plant with one critical machine worth 2–5 million PLN, where downtime costs 50–100 thousand PLN per day, can see ROI after the first prevented failure—potentially in the first quarter. A plant with many low-cost machines needs 3–6 months to gather a sufficient sample. The ROI calculator lets you calculate this for your case.

Through an integration layer, not a direct connection. The API available in your MES or ERP is the entry point for the agent. If the MES doesn’t have an API, data export via files or OPC-UA protocols (for SCADA systems) is possible. Replacing MES/ERP isn’t a condition for AI implementation—integration via n8n or a similar orchestrator is usually faster and cheaper than native integration.

Yes, and in many cases, this is required due to production secrecy or contractual requirements. Vision and predictive models can run locally on a server at the line. Operator data and process parameters don’t need to leave the plant. If a language assistant is used for documentation, PII masking and self-hosting the model are standard options. Discuss data residency requirements before choosing infrastructure.