Company News

Over the past two years, one of the questions manufacturing customers ask most is: How exactly should AI be implemented in factories? After the model is connected, has the factory's production process really changed?

Large models and Agents are getting hotter. Almost every manufacturing company is looking at them, and many have already made a first round of attempts. Connect a large model, build a knowledge base, pick a few business scenarios to run POCs, then build a few Agents. In demos, the results are usually good.

But when it actually reaches the workshop, problems arise. Engineers won't look at fewer trend charts just because there is an extra chat box; when equipment is abnormal, they still have to dig through historical data themselves; when the model gives a judgment, they still have to confirm with process, equipment, and automation teams whether it can actually be adjusted. The demo works, but the production process hasn't changed. This is a common awkward situation in manufacturing AI implementation today.

From enterprise AI research published in 2026 by Gartner, Deloitte, MIT NANDA, McKinsey, and others, what everyone sees is actually quite similar: enterprises are very enthusiastic about investing in GenAI and AI Agents, but going from POC to a real production environment still has a long way to go. Many projects are put in a corner to gather dust after the demo.

The problem is no longer just whether the model is smart enough. On the manufacturing floor, if any link among data, equipment, software, process, control, and safety is not connected, AI may ultimately stop at being able to answer questions but struggle to actually do work.

We have been doing projects on equipment engineering sites for the past few years, and we feel this deeply. If today's large models are compared to a high-speed train with excellent performance, many companies have actually already bought the train. But if the tracks, signals, scheduling, braking, and safety boundaries are not ready, the high-speed train still cannot run.  

The same is true for manufacturing AI. Model capabilities are improving rapidly. What is really missing is an engineering system that allows models to enter industrial sites. This is also what Getrontec PreMaint Equipment Intelligent Engineering (hereinafter referred to as Getrontec EES) has been solving.

Over the past period, we have implemented AI with many manufacturing enterprises and have also seen some projects that had already done POCs. Many problems look different, but in the end they often come down to the following three pitfalls. Lessons others paid for can become your experience.

Pitfall One: Finding AI scenarios first, without matching business pain points

This is the easiest pitfall to fall into. The boss thinks AI is important, the IT department starts researching large models, and then asks: What scenarios in our factory can use AI?

Then everyone goes to the workshop to find scenarios: Can AI write shift reports? Can a large model judge equipment faults? Can process parameters be adjusted directly by AI? These can all be done, but the question is: after doing them, what actually changed?

When we judge whether a manufacturing AI scenario is worth doing, we usually don't look at the model first; we look at the site first. For example, in an oven moisture control scenario, what really gives the site a headache is: moisture fluctuates, lab results come back slowly, and how to adjust parameters depends heavily on the shift leader's experience.

Then the goal of this project is very clear. It is not to build a large model that understands ovens, but to find a way to control moisture more stably. So we break it down:

Can process variables be obtained in real time?

Which variables are related to moisture?

Can a soft-sensor model be built from historical data?

After the model gives a prediction, how does the recommended setpoint enter control?

Under what conditions is adjustment allowed, and under what conditions must it fall back to manual operation?

In the end, you will find that AI is indeed used in this matter, but what the user really pays for is not AI. What they pay for is more stable moisture, less manual adjustment, and experience no longer stored only in the minds of veteran workers. This is also the basic logic by which Getrontec EES selects AI scenarios.

Internally, we often use three questions to judge a scenario: Who is in pain? What is being repeated every day? Which metric can ultimately be improved? If these three questions cannot be answered clearly, don't rush to deploy the model.

In the end, manufacturing still recognizes yield, downtime, fluctuation, energy consumption, false alarms, and labor hours. AI is just a new tool for solving these problems.

Pitfall Two: The large model is connected, but industrial software does not have AI capabilities

This problem is more common than the first. Many enterprises have now connected large models into their systems. The equipment system has interfaces, the data platform also has data, and with a chat entry point added, it looks like AI capabilities are there. But after engineers actually use it for a few days, they quickly discover problems.

For example, they say: Help me check whether the torque of handling robot No. 3 is abnormal. AI may know who robot No. 3 is and can retrieve the relevant data. But what about the next step?

Can it automatically find this robot's historical normal waveform?

Can it select samples?

Can it invoke model training?

After training, can it compare with normal actions?

After an abnormality is found, can it enter a monitoring process?

If these things still require engineers to click page by page, then this AI is essentially just adding a chat entry point to the original software. This is also the design principle of Getrontec EES: not to bolt an AI onto equipment software, but to first transform equipment engineering itself into software that AI can use.

We call this AI-native five transformations.

1.Interface-ization — Give AI hands. Data collection, monitoring, alarming, diagnosis, reporting, and model training—functions that originally required people to operate on pages—must first become capabilities that Agents can call. Humans being able to click does not mean AI can call. Without this step, Agents have no hands.

2.Semanticization — Let AI understand. Industrial sites have a large number of measurement point codes, equipment codes, and variable names. Engineers may understand what TC-01-04 means, but large models do not. EES organizes the relationships among equipment, components, measurement points, abnormalities, and operating conditions. When an engineer says that handling robot No. 3 doesn't seem quite right recently, the system needs to know where to find data, what data to look at, and what to compare with. This is equivalent to enabling Agents to begin to understand the factory.

3.Event-ization — Let AI proactively discover problems. Traditional software is mostly people looking for the system. When equipment alarms, people open a page; when the trend looks wrong, people go check history. After Agents truly enter the site, it should be the opposite. When status changes, events proactively enter the process, and then it judges what to check next, what to calculate, and whom to notify.

4.Automation — Let AI perform repetitive engineering actions. Manufacturing sites actually have a large number of repetitive engineering actions. Sample selection, training, comparison, release, and monitoring—many steps do not need engineers to do them from scratch every time. If these actions can be standardized and orchestrated, Agents have a chance to truly take over part of the work.

5.Safe and controllable — Let AI know what it can and cannot do. This is especially important in manufacturing. In office scenarios, if AI answers a sentence wrong, at worst you regenerate it. Equipment sites are different. When parameter modifications and control commands are involved, it must know who is allowed to operate, what the current interlock status is, whether the equipment is in automatic mode, and how to roll back if something goes wrong. AI capabilities in EES are not designed from the start to adjust whatever it wants. What can be read, what can be done, under what circumstances writing is allowed, and who confirms—every step has boundaries.

After these five things are done, AI's role in equipment engineering begins to change.

Take handling robots as an example. In the past, anomaly detection required engineers to find torque waveforms, select normal samples, choose a base model, configure parameters, train, review the effect, and finally release. If there are dozens or hundreds of similar devices on site, there is a lot of repetitive work. In EES, we put this model engineering capability into the equipment engineering foundation.

After the torque waveform of each action cycle comes in, the system can judge whether it resembles a normal action and give an anomaly score.

The repetitive processes of sample selection, training, comparison, and deployment can continue to be executed by Agents. This is how one machine, one training and one machine, one model can be achieved.

What Agents truly save is not the time engineers spend typing a few words, but the engineering operations that repeat every day behind the scenes. This is also our understanding of equipment intelligence.

Pitfall Three: Industrial data is all there, but it has not been turned into AI “executable context”

When many factories first talk about AI, they say: We have been collecting data for many years. This statement is usually true. But there is still a long way between having data and AI being able to use data.

Real-time values are in one system, alarms in another, and recipes in MES; equipment installed a few years ago uses one protocol, and a production line bought later uses another. To make a complete judgment, it often goes like this: first go to system A to look at trends, then go to system B to check alarms, can't find the recipe, and then call the site to ask. This is how people work, so Agents naturally cannot run either.

Another thing EES does is to consolidate these previously scattered equipment engineering capabilities onto one foundation: collection into unified measurement points; establishing context among equipment status, alarms, recipes, and operating conditions; and using the same equipment semantics for monitoring, diagnosis, and model engineering. In this way, what Agents receive is no longer just a number, but knows: which equipment this is, which component, and what change under what operating conditions.

The next step is writing, which many AI projects most easily overlook: AI seeing a problem is one thing. Having AI participate in adjustment is a completely different thing. In EES, control commands must pass through a unified intelligent control channel. Interlock status must be visible, auto/manual status must be visible, permissions must be controllable, and model release must also have access control.

For example, a soft-sensor model can first enter the control loop read-only. It can judge and give suggestions, but it cannot, just because the model thinks the valve should be opened wider, bypass the original control system and directly write to the valve. Only when this link is complete can AI possibly move from: I think there is a problem here, gradually to: I have completed diagnosis, this is the recommended action, and it can be executed after these conditions are met. At this point, AI has truly begun to enter the production process.

Three pitfalls, and the lessons summarized, ultimately correspond to three sentences:

Response strategy

Scenarios: pain points first, models second;

Systems: five transformations first, dialogue second;

Pathways: connect first, then talk about automation.

After doing manufacturing site work for so many years, we are increasingly certain of one thing: manufacturing does not lack a smarter chatbot; what it truly lacks is a carrier that enables AI to enter equipment engineering. AI needs to know what is happening on site; understand equipment and measurement points; be able to call existing capabilities such as monitoring, diagnosis, and model training; and when needed, be able to participate in the next action within the boundaries of permissions and interlocks.

We have made PreMaint into an equipment intelligent engineering foundation: from equipment, collection, monitoring, and diagnosis, to optimization, model engineering, and then Agent collaboration, putting as much as possible into the same equipment engineering system.

This is also why we did not make Agent a standalone AI feature. If the underlying equipment data, software capabilities, model engineering, and control links are not ready, no matter how smart the Agent is, on site it can only chat.

What manufacturing AI really needs to solve is to move equipment from the past state of having data and being able to monitor, further forward to being understandable, searchable, and diagnosable, and adjustable when adjustment is needed.

The 100 free trial spots are still open, with priority given to existing customers and enterprises that have already gone through AI pilots and hope to further embed AI into the frontline rather than stop at the chat window. Fill out the questionnaire to register. We will screen within 48 hours, and after approval, a specialist will contact you.