The maintenance industry is experiencing a wave of AI vendor claims that field practitioners are uniquely positioned to call out as nonsense. These are people who have watched IoT sensor vendors deploy equipment and disappear. Who have seen predictive maintenance models trained on synthetic data fail in the first month of production. Who understand viscerally that a hallucinated torque spec is not a minor inconvenience — it's a safety event.

The result is a deep, well-founded skepticism. And it has a specific shape: not a blanket rejection of AI, but a very precise set of constraints on what they'll accept and what they won't.

What practitioners won't accept

Predictive failure claims without data prerequisites

Field-deployed predictive AI models have been found to run at under 20% accuracy in real production environments. The gap between conference-room demos and production reality is enormous, driven by data that looks clean but isn't, models trained on idealized datasets, and the normal variance of industrial equipment that wasn't in the training set.

The false-positive problem compounds this. When predictive models are biased toward false positives — which they typically are, because missing a real failure is worse than a false alarm — maintenance teams spend labor chasing alarms that don't correspond to real failures. Over time, technicians stop trusting the alerts. The system continues generating them. The labor is wasted.

Auto-created work orders from AI outputs

The concern is direct and practical: one AI-generated work order that turns out to be wrong — a phantom fault, a misidentified asset, an incorrect priority — and technicians stop trusting the work queue. Trust in a work order queue is the product. Once it's gone, it's almost impossible to recover.

AI that fills data gaps with synthetic data

A specific failure mode that has been observed in production: AI systems that fill missing sensor data with synthetic values, train models on those synthetic values, and generate outputs that have no relationship to physical reality. The system looks coherent because its inputs are complete. The completeness is manufactured.

What practitioners will accept

LLM Q&A on asset history and uploaded documentation

A technician types "what was done last time this fault code appeared on this motor?" and gets back the relevant work order records from the CMMS — summarized, with parts used and resolution noted. This is genuinely useful, low hallucination risk (the LLM is retrieving from a closed corpus of actual records), and solves a real problem: finding relevant history quickly without navigating CMMS sub-menus.

The same applies to OEM manual Q&A: upload the pump manual, ask "what's the bearing replacement interval for this model under high-ambient-temperature conditions?" and get the specific section back. The LLM is a search and summarization layer over documents you own. Hallucination risk is bounded by the grounding.

AI-assisted close-out note generation

Technician taps a microphone button at job completion. Records 30 seconds of voice. AI cleans it up into a structured summary: symptom observed, diagnosis reached, repair performed, recommendation for next PM. Technician reviews and edits before saving.

This feature has a clear value proposition: most technicians don't want to write a close-out note at the end of a long shift. A structured summary that they can review in 15 seconds and approve with one tap is a much lower friction path to a useful record.

Anomaly detection on meter readings

"This meter usually reads around 23.5. You entered 235. Did you mean 23.5?" This is a constrained, low-risk application of pattern detection. The output is a soft warning, not an action. The technician is in the loop. The data quality benefit is real.

OCR nameplate capture

Photo of a data plate — the asset's make, model, serial number, and specification nameplate — and AI parses the structured data into asset record fields. Technician confirms before saving. This solves a real, specific friction point: manually transcribing a 29-character alphanumeric serial number from a plate in a dark equipment room.

The governing principle

Every AI feature that practitioners will accept shares three properties: it is constrained to data they already own, it requires human review before any action is taken, and it produces outputs that are obviously wrong when they're wrong — not subtly wrong in ways that propagate through the system.

The AI features they won't accept all share a different property: the failure mode is silent, the error is consequential, and the human is out of the loop when it matters most.

This isn't a statement about AI capability. It's a statement about where AI capability meets industrial operational requirements. The bar is different here than in a content recommendation engine or a chatbot. And the practitioners who set that bar are right to set it where they have.