How to Apply AI in Manufacturing Operations: A Practical Method

Applying artificial intelligence in a factory does not start with picking a model or signing up for a platform. It starts with the data the plant already generates and with a specific problem that costs money every week. This guide lays out an ordered path for an industrial SME: which data requirements must be in place, which use cases to tackle first depending on maturity, and how to know, with numbers, whether the project is actually working.

Where not to start: buying AI without data

The most expensive mistake in industrial AI is made before a single line of code is written: contracting a prediction tool, or a generative AI pilot, while the plant is still recording stoppages on a whiteboard and energy consumption lives in the PDF of the electricity invoice. A model learns from history. If that history was never recorded, or was recorded by hand with gaps and criteria that change from shift to shift, no algorithm can compensate for it.

The sensible sequence is the reverse of what the market usually sells. First you connect the data sources (machines, ERP, sensors) and build up a reliable history. Then you exploit that history with simple means: visualisation and rules. Only when those two layers work and are used daily does it make sense to invest in prediction. Skipping steps does not save time: it shifts the cost into the AI project, where every data gap is far more expensive to fill.

There is a quick test for whether a factory is ready. If nobody can answer within five minutes, from records rather than from memory, the question "how many hours was line 2 down last month, and for which causes?", the project the plant needs is not AI. It is data capture. And it is a much cheaper project.

The data you need before talking about models

You do not need a corporate data lake or years of pristine history. You do need a set of minimums that are worth checking use case by use case:

• Automatic capture of the critical variables. Hand-logged data is fine for getting started, but it introduces delay and bias. For prediction, the key signals (machine states, counters, temperatures, consumption) must come from the PLC, the sensor or the ERP without human intervention.
• Enough history of the phenomenon you want to predict. Months of data are not sufficient on their own: you need examples of the event in question. To anticipate a given failure mode, the history must contain several failures of that type together with their context. A fault that has occurred twice in three years is a poor candidate.
• Labelled context. A vibration series is worth little if you do not know which product reference was being made, or whether the stoppage was a breakdown or a changeover. Machine records need to be cross-referenced with work orders, downtime causes and quality results.
• Continuous series with consistent timestamps. Clocks that drift between systems, and long unrecorded gaps, are the two defects that generate the most cleaning work later on.

If part of this is missing, the good news is that fixing it is a connectivity and organisation project, not a data science one, and it delivers value on its own: a plant that measures properly already makes better decisions even if it never trains a model.

Use cases ordered by maturity

It helps to think of AI in the factory as a four-rung ladder. Each rung builds on the previous one and has value in its own right: you do not have to reach the top for the investment to pay off.

Levels 1 and 2 are not "the boring bit before the AI": in many SMEs they are where most of the return sits, because they make visible the losses nobody was quantifying. Level 3 is where models proper come in; in our experience it works better to start with a tightly scoped case, of the kind we describe in prediction and alerts, than with a general-purpose platform. Level 4, agents, is recent and promising, but it demands that the previous three exist: an agent querying incomplete data will confidently state things that are not true.

Typical mistakes in industrial AI projects

1. Starting with the technology and looking for a problem afterwards. The symptom is a spectacular demo that nobody on the shop floor is using three months later. The healthy order is problem, data, model.
2. Pilots with no owner on the shop floor. If the project belongs only to IT or to an external consultancy, it dies when that person changes priorities. It needs an operations owner who personally suffers the problem being solved.
3. Ignoring the cost of false alarms. A model that warns often and is right rarely trains the plant to ignore it. Within a few weeks nobody looks at the alerts and the project is dead, even if the dashboard is still switched on.
4. Measuring the model instead of the decision. A 92% accuracy figure says nothing on its own. The question is what the plant does differently when the warning arrives, and what that difference is worth. Closing that gap between model and decision is exactly the job of the operating recommendations module, which proposes the action with its justification and records the human decision.
5. Forgetting model maintenance. Processes change: raw materials, recipes, recalibrated sensors. A model trained once and abandoned degrades silently. How to watch for that degradation is covered in detail in industrial MLOps.

How to measure whether it works

An industrial AI project is evaluated on three layers, and all three have to be defined before it starts, not at the end:

• Technical metric. The model's own: hit rate, false alarms, prediction error. Necessary, but the least important of the three.
• Operational metric. The plant indicator the project is supposed to move: hours of unplanned downtime, scrap rate, consumption per unit produced. It is measured before the project to establish a baseline and tracked afterwards.
• Adoption metric. How many alerts are acted on, how often the system is consulted, whether the habit survives the project champion's holidays. A system nobody uses has zero return regardless of its technical quality.

A practical rule: if three months after go-live you cannot show a table with the baseline, the current value and at least one concrete decision that changed thanks to the system, the project needs reviewing. The number does not have to be large; it has to exist.

If you manufacture in the Valencia region of Spain and want to discuss where to start in your case, on industrial AI in Valencia we explain how we approach this journey, from data connectivity to models in production.

Frequently asked questions