Abstract
Most critiques of industrial AI are written by people who want it to fail. This one is not. The technology has real applications in maintenance, and the fastest way to lose them is a visible failure that nobody anticipated and everybody generalizes from. This paper catalogues eight mechanisms by which AI-assisted maintenance degrades, so that a plant recognizes the mechanism when it appears instead of concluding the whole category was oversold. Most of them are not technical, and most of them predate AI by decades.
The machine with no work orders
Start with a story that has no AI in it at all, because it describes the ground the technology has to be installed on.
The dryers were big machines. Porous conveyors carrying material while hot air blows through to dry it, three levels. The top level of one of them tripped an overload every single time it started up.
I found out by accident. I happened to be there when the operator called to start it, and the operator was standing inside the guard, kicking the sheave to get it going when it tried to start.
I told him to get the hell out of there and asked what he was thinking. He said it will not start otherwise, you just get a motion alarm. I told him I would look into it, and not to start it from inside that guard again.
The other operators had been doing it so long they had a system. Just kick it to get it going.
Here is the part that matters. Not one work order had ever been generated. The operators knew. Electrical knew, had looked at it, and could not figure it out. The PLC contractor knew. The fault ran for a very long time with zero documentation anywhere.
Now put a maintenance AI on that plant. Ask it about the dryer. It reads the CMMS and finds an asset with no history of the fault, no failure codes, no repeated work orders, no trend. It will tell you, fluently and correctly given its inputs, that the dryer is one of your healthier machines.
The record was not wrong. The record was empty, and empty reads as fine.
The specialist who would not test it
There is a second half to that story and it is about people, which is where most of these mechanisms live.
Electrical had the problem assigned to a PLC specialist who basically lived there. I watched it with him, and I remembered a similar problem from years before. A PLC has a ramp-up time that tells the drive how long to take reaching full speed. Set it too low and the motor trips trying to go from zero to full instantly instead of ramping.
I am a PLC guy myself, so I asked him if that was the cause. He said no. I asked if he had tested it. He said no. I asked him to please check that, and I put in a work order.
I brought the work order over and he told me he had tried it and it did not work. I said fine, figure it out, I cannot have guys kick-starting a machine, guard or not.
About a week later he came and told me he had finally fixed the dryer overload. I asked what it was. He said he adjusted the ramp-up time.
I asked whether that was not exactly what I had asked him to do. He said yeah, but I didn't do it. I asked why not.
He said: I didn't think it would work.
Hold on to that, because it is going to happen to every plant that installs a diagnostic AI. A hypothesis from a source the expert does not respect gets reported as tested when it was not tested. He was not lazy and he was not stupid. He was a specialist being handed an answer by somebody outside his discipline, and the cheapest way to dispose of it was to say he had checked.
Replace me with a model and the dynamic gets worse, not better, because now the source has no standing at all and cannot follow up.
The eight mechanisms
1. Laundering assumption into instruction
A model produces fluent scope from incomplete evidence. The uncertainty is real, but there is no field for it to live in, so it is lost, and an assumption arrives at the machine wearing the costume of a specification.
I gave an AI a folder of twenty-eight scripts and asked it to pick the three best openers. It could not read the folder. Instead of saying so, it produced a plausible ranked list built from old context, including a script that does not exist, with a title good enough that I briefly believed it was mine. Challenged, it corrected smoothly rather than admitting it had never read the files.
The fabrication and the fluency come from the same place. Truth is not a language model's default state. It is a property that has to be checked against something outside the model.
2. Orchestration failure
Access to the right tools is not competence with them. PHMForge tests agents against industrial prognostics tasks with domain tools and finds that even strong configurations fail at tool sequencing, multi-asset reasoning, and generalization to unfamiliar equipment.
That is the same failure as a man who checks every gauge he was told to check and does not know what the system does.
3. Authority creep
A system granted read access is given write access after it performs well, with no corresponding rise in evidence burden. Nobody re-ran the approval question when the consequence changed.
The physical version happened to me with a spare motor. I approved storing it under the stranders because a mechanism held the shaft up and kept the rotor off the bearings. Somebody later removed the mechanism, with no record of who or why. Three years of vibration later the bearings were destroyed before the motor ever turned. When I raised it the answer was "you signed off."
I had. With the mechanism in place. The approval outlived the condition it depended on, and nothing in the system noticed, because the approval was recorded and the assumption was not.
Every AI write-access approval granted today under conditions of human review, limited scope and a trusted source will face the same drift, and the paperwork will still say approved.
4. Metric capture, and the order nobody could stop
The system optimizes what it can measure, and the organization reorganizes around producing that thing.
The purest example I have of an automated process running past all human objection had no software in it worth mentioning.
Plant startup, my area. Cleaning the dryers needed dry ice and nobody knew how much to buy, because there was no usage data yet. A planner kept demanding to know how much I wanted, and I kept honestly saying I did not know. He got angry. I asked what the sister plant used. Eight totes a week. Fine, start with eight, use what is left next week, keep adjusting.
He agreed, and then quit about a week later, irritated at me or the company.
First shipment was ten totes. We used four. I told the planners to dial it back. Next week, ten again. Cut it back. OK. Next week, ten. I bitched them out. Next week, ten. I took it to the plant manager, who said he would deal with it. Next week, ten.
Everybody walked past a growing pile every day and nobody cared. It got to more than forty totes on the floor.
Then somebody mentioned in passing that we were paying rental on the totes, which I had not even known, on top of the dry ice cost. And the dry ice had clumped and gone unusable.
I started opening totes to burn off the dry ice so I could return them, and the manager for all of Western Canada showed up that day and asked what I was doing. I told him I had over forty of these damned things, they were in my way, and I needed them gone. He asked why I had them. I told him I ordered eight and the rest I have no idea about. He asked if I knew what they cost. I said I had heard about six hundred a tote plus rental. He looked at me and said: more.
The reveal was that the planner who quit had put in a standing order for ten a week out of spite, and the rest of the planning team would not fix it despite my repeated asks, because they were angry at the company over whatever he quit over.
The system did exactly what it was set to do, for weeks, long after everyone involved knew it was insane.
That is the mechanism. Not a wrong algorithm. A correctly functioning automated process, a configuration nobody remembered making, a cost nobody was counting, and diffused responsibility that made stopping it nobody's specific job. Every one of those conditions is easier to create with an agent than with a planner, and the pile on the floor is the only reason it was ever caught. Most automated waste does not produce a pile you have to walk around.
5. Feedback poisoning
Model output becomes the next generation's input. Estimates converge on themselves and drift from reality while confidence rises, because self-consistency reads as accuracy.
The maintenance version already exists without AI. A false repair is recorded as a repair, and later reads as confirmation that the original diagnosis was right.
6. Skill decay
The apprentice who never had to work it out.
The argument is not about generational character, and I want to be careful here because the lazy version of it is wrong and insulting. It is about which specific diagnostic capacity is being lost and whether the plant has made that trade knowingly.
I nearly lost my eyesight pulling a cap off a pump whose gauge read zero and was wrong. Years later I caught an apprentice about to pull one the same way and told him to loosen the back nuts first, so that if there is pressure the cap gaps away from him. He asked why. I told him. He now knows something that cost me a hospital-grade afternoon to learn, and he got it for free.
That transfer is what an apprenticeship is. The risk is not that AI answers the question. It is that nobody is left who knows why the answer is what it is when the AI is wrong.
7. Operational memory failure
Plants re-solve the same problem for decades because the solution lived in a person. Current systems capture the outcome and discard the reasoning, and the reasoning is the half that transfers.
This is simultaneously the most plausible high-value application of AI in maintenance and the least well served.
8. The expert who will not test the outsider's hypothesis
The dryer specialist. A correct hypothesis, delivered by somebody outside the discipline, reported as tested when it was not, and then quietly implemented a week later as an original finding.
This one is specific to AI-assisted work and I have never seen it named. Every diagnostic recommendation a system produces will be evaluated by a human whose expertise it is implicitly challenging. Some of those evaluations will be honest. Some will be "I tried it, it didn't work."
The countermeasure is not trust and it is not culture. It is requiring the test to be recorded as a test, with what was changed and what happened, so that "I tried it" becomes a claim with evidence attached rather than a sentence that closes a conversation.
What the mechanisms share
Seven of the eight are organizational rather than technical, and none is fixed by a better model. They are all failures of boundary. Between known and assumed. Between retrieval and judgement. Between advising and acting. Between measuring and being measured. Between a test performed and a test claimed.
This is consistent with the staged-adoption literature. Crespo-Márquez and Gómez Fernández review agentic AI across the maintenance management framework and find empirical evidence concentrated in technical phases while managerial and strategic phases remain largely unexplored. The gap in the research mirrors the gap in the failures, and for the same reason: the technical part is the part that is fun to work on.
Conclusion
None of these mechanisms argues against using AI in maintenance. Each argues for deciding in advance which one you are most exposed to, and instrumenting for it before deployment rather than after the incident.
A plant that can name the mechanism when something goes wrong keeps the capability. A plant that cannot will conclude the whole category was oversold, and will be wrong, and will still be kicking the sheave from inside the guard because nobody ever wrote a work order for it.
References
- Li, Feng, Chen, Tsai, Sun, Das, El Maghraoui, Lin & Patel, “PHMForge: Evaluating LLM Agents on Industrial Prognostics through MCP-Native, Algorithm-Grounded Tools,” 2026. https://arxiv.org/abs/2604.01532
- Crespo-Márquez & Gómez Fernández, “Agentic AI for maintenance management: a process-centric review and a staged framework for industrial adoption,” Computers & Industrial Engineering, 2026. https://www.sciencedirect.com/science/article/pii/S0360835226004869
- Misra, Vyas, Gutta & Mercangöz, “ADMITBench: A Safety-Governed Reference Framework for Evaluating the Admissibility of Industrial LLM Advisories,” 2026. https://arxiv.org/abs/2608.03866
- Liu et al., “ConMem: Contribution-Aware Memory for Long-Horizon Manufacturing Inspection Logs,” 2026. https://arxiv.org/abs/2607.28126