Published on :
June 4, 2026
by
Anisha Bhattacharjee
Views...
Ecotrak's 2026 State of Facilities Management survey found that about 75% of respondents would use AI in their CMMS to automate decision-making and improve workflow efficiency, up from 61% in 2024. That's a sharp jump in willingness to use AI in just one year.
The same respondents attached a condition, though. Before they'd trust autonomous technology to act on its own predictions, they said they'd need visibility into historical trends, or an added layer of FM approval before a work order goes out. That suggests the hesitation isn't about using AI itself. It's about being able to see enough context, or retain a human checkpoint, before the system acts on its own.
That, in essence, is human-in-the-loop. The question isn't where to put a human in the AI workflow. It's which decisions actually need one.
Human-in-the-loop (HITL) in FM is a governed workflow where AI handles the decisions it can reliably make within defined boundaries, while human involvement is reserved for decisions or actions that require contextual judgment, human authorisation, specialist expertise, or physical intervention.
A simpler version of this idea treats HITL as a single checkpoint: the AI makes a call, a person signs off, and it proceeds. That's a fair starting point, and it captures part of what matters. A fuller version goes further, because oversight works best when it's built into how a case moves through the workflow, not added as one review step:
AI handles the routine → exceptions get identified → a person is involved where their judgment, authorisation, expertise, or hands are actually needed → the outcome gets verified.
The human isn't an approval layer sitting on top of the AI. The human is part of the decision architecture. A workflow built this way defines, at every point:
Governance covers who or what is deciding at each point in a fault's life, and why, across a much wider set of questions than HITL alone. Human-in-the-loop answers one part of that: when, within a given case, a person needs to be involved, whether that's their judgment, their authority, or their hands.
Because AI and humans are good at different parts of the maintenance decision process, and neither replaces the other's strengths.
The goal isn't maximum automation or maximum human involvement. It's putting each where it adds the most value. That's also the logic behind Xempla's approach to autonomous maintenance: the workflow moves forward on its own wherever the system can reliably operate within defined boundaries, with human input concentrated on exceptions, judgment, and physical work.
A person enters the workflow when a case falls outside what the system is confident about, outside what it's authorised to do on its own, or when the work itself needs someone physically there to do it. That's triggered by the case, not by a fixed schedule of review. We've written in detail about this idea in the context of exception-based maintenance: people shouldn't spend their time reviewing every signal. They get brought in where their involvement can actually change the outcome.
Mapped against the four-stage framework Xempla structures autonomous maintenance around, called DIIV (Discover, Investigate, Implement, Verify), that looks like this:
When a case does get escalated, what the person receives matters as much as whether they're escalated to at all. A properly designed handoff gives them a decision-ready case, not another investigation to start from scratch. We've laid this out in more detail in how the autonomous maintenance workflow actually runs, but at minimum, it should include:
This is where the Ecotrak finding lines up with how the workflow needs to be built. Visibility into history and context isn't a nice extra. It's the difference between a checkpoint that can make an informed call and one signing off out of habit.
That habit is worth naming directly, because it's one of the easiest ways HITL quietly stops working. Requiring approval on every AI decision defeats the purpose of automation; it simply creates another queue. But the opposite failure matters too. If people approve recommendations without actively judging them, the human becomes a rubber stamp. Good HITL isn't measured by how many decisions get reviewed. It's measured by whether the right decisions reach the right person, with enough context to make a meaningful judgment.
Governance defines the boundaries within which the system operates. HITL applies one part of those boundaries in the workflow: determining when a case needs human involvement, and what kind.
Who owns an escalated decision, and whether the fix actually held afterward, are also governance questions, but they run alongside HITL rather than being part of it: a named owner for every escalated decision, and a check afterward on whether the outcome worked.
Yes. AI takes on the routine review and investigation, so the workflow around the team changes, though the team's expertise doesn't become any less necessary. The human's job doesn't disappear. The composition of the job changes: less time goes into reconstructing context by hand, and more of it goes into the calls that genuinely need a person. We've covered what this looks like for engineers, technicians, and supervisors in more detail separately.
HITL doesn't look the same across every FM function, because the underlying work and data are different.
Hard FM functions such as HVAC, electrical, and plumbing generate structured asset data that AI can continuously monitor and reason over. That makes automated detection, investigation, and exception-based escalation particularly suitable.
Soft FM and security also generate operational data, but much of the work stays more human-centric, relying on physical presence, observation, interaction, checklists, and contextual judgment. AI can support these workflows, but the point at which a person enters the loop will look different. HITL should be designed around the nature of the work and the data available, rather than applied as one rule across all of FM.
For a deeper look at how human-in-the-loop works at scale, see our companion piece, How Does Human-in-the-Loop Work in Autonomous Maintenance?, which examines what one year of autonomous maintenance data across approximately 25,000 assets tells us about human review and autonomous decision-making.
A human handles the decisions or actions that require contextual judgment, authorisation, physical intervention, or expertise the system's defined boundaries don't cover.
Human approval puts a person in front of every decision by default. Human-in-the-loop determines when a person needs to enter the workflow, based on the case's confidence level and consequence, not on habit.
No, it's narrower. Governance covers the full set of boundaries, accountability, and checks around how an AI system operates. Human-in-the-loop is the specific piece concerned with when, within that system, a person needs to step in.
No. In a well-built system, routine cases resolve without review, and a person is brought in only when the system's confidence is low or the case falls outside its defined authority.
When its confidence in a recommendation is low, the case falls outside defined operating boundaries, the decision requires human authorisation or specialist expertise, or the work requires physical intervention.
© Xempla. All rights reserved.