The Asset Maintenance Roles AI Automation Actually Threatens, and the Ones It Doesn't

Every asset management conference this year has had a session on AI and agentic systems, and underneath most of them sits the same question from the room: which of my team's jobs are actually exposed. The honest answer is that exposure has very little to do with job title and a great deal to do with the shape of the work: how much of it is pattern-matching against clean, structured data, and how much of it is judgement made under incomplete information.

Treating "the maintenance workforce" as a single category leads to bad decisions in both directions: over-hedging roles that are genuinely safe and under-hedging roles that are already being absorbed. There is a clear line here, and it is worth drawing plainly rather than spreading risk evenly across every role to avoid saying something specific. The line runs through task structure and criticality judgement, and it splits maintenance roles more cleanly than seniority or job title ever will.

The Roles Already Being Absorbed

Condition monitoring reporting, inspection round logging, and routine preventive maintenance scheduling generated from OEM intervals share a profile: high volume, structured inputs, and short feedback loops. A telemetry reading is either in range or it isn't. A checklist is either complete or it isn't. This is precisely the profile that agentic systems exploit well, because there is no ambiguity in the input and the correct output is close to deterministic.

In a water utility, an agent watching SCADA telemetry can flag an out-of-range pressure reading and draft the work order faster than a technician can open the CMMS and type it in. In transport, condition assessment scoring from inspection photos is moving the same direction. None of this is speculative. It is already the shape of the tools being deployed into these workflows. What we've found is that the roles built almost entirely around capturing and routing this kind of data are the ones with the least structural protection, not because the people doing them lack skill, but because the task itself doesn't require the kind of judgement that resists automation.

Where Criticality Judgement Resists Automation

Criticality assessment is a different kind of task, and it is worth being specific about why. ISO 55001:2024 Clause 6.1 requires an organisation to determine the risks and opportunities that need to be addressed within its asset management system, but the standard stops at the requirement. It does not tell you how to weigh a safety risk against a budget cycle, or how to rank a reputational exposure against a capital constraint. That weighing is a judgement call, and it draws on context that rarely makes it into a structured field: the near-miss that was never logged, the political sensitivity of a particular asset, the workforce safety history that lives in a supervisor's memory rather than the CMMS.

The GFMAM Asset Management Landscape treats decision-making as a distinct subject group precisely because it is not the same activity as data capture or planning. It sits on top of both and requires reconciling them under uncertainty. A defence sustainment lead deciding whether operational tempo overrides a scheduled maintenance window is not consulting a manual for that call; they are drawing on institutional memory about what actually happens when that trade-off has been made before. No agent trained on maintenance records has access to that memory, because it was never written down anywhere an agent could read it.

The Contested Middle: Planners and Reliability Engineers

The roles generating the most genuine uncertainty right now sit between these two poles. A reliability engineer running failure mode and effects analysis, or a planner sequencing a shutdown, does work that is partially automatable: an agent can draft an FMEA table from failure history, propose an RCM strategy, or generate a first-pass shutdown sequence in a fraction of the time it used to take. What remains stubbornly human is the decision to accept, reject, or modify that output against the specific risk appetite of the asset owner.

This is where the near-term change is actually concentrated, and it is not full replacement. It is role redesign. Less time producing the first draft of an analysis, more time reviewing it, stress-testing its assumptions, and defending the final call to a budget owner who wasn't in the room when the trade-off was made. In practice, this looks less like job loss and more like a shift in where a planner's hours actually go.

What to Do With This Over the Next Quarter

The practical move is a task audit, not a workforce restructure. Take one maintenance team's activity log and split it into two columns: structured, repeat tasks with clean data inputs, and judgement calls made under incomplete information. Most teams have never done this split explicitly, and it changes the conversation from "which roles are safe" to "which hours, within each role, are exposed."

Quick win: for the roles concentrated in the first column, redirect the freed-up time toward verification and exception review rather than assuming the role disappears outright. Someone still needs to catch the agent's mistakes, and that requires a different skill than the data entry it replaces. For the roles concentrated in the second column, invest deliberately in the judgement itself: documented escalation criteria, criticality review forums where the reasoning behind a call gets tested out loud, and mentoring that transfers the institutional memory before the person holding it retires. The teams that get ahead of this aren't the ones hedging every role equally. They're the ones who know exactly which hours are exposed and which aren't, and who are already redesigning around that line.