backicon

What Is Human-in-the-Loop in Facility Management AI?

Published on :

June 4, 2026

by

Anisha Bhattacharjee


Human-in-the-loop (HITL) in facility management AI is an operating model in which artificial intelligence handles routine maintenance decisions autonomously, including triage, PPM scheduling, BMS fault classification, and contractor coordination, while human reviewers are present only for decisions that genuinely require their judgement.

Facilities management runs on decisions. Hundreds of them, every day, across every site in a portfolio. Which work orders get prioritised. Which PPM tasks get rescheduled. Which HVAC fault warrants a contractor today and which one can wait. Which BMS alert is signal and which is noise.

For most of FM's history, every one of those decisions passed through a human. That was not a design choice. It was a constraint. There was no alternative.

AI changes that. But the moment AI enters a CMMS or CAFM workflow, a question follows immediately: who is actually in control?


What Human-in-the-Loop Means in CMMS and PPM Workflows

The key word in any HITL definition is require. Not every decision. Not most decisions. The ones where human expertise changes the outcome.

This is not a novel concept in FM. A senior maintenance manager has always known, instinctively, which calls to make themselves and which ones to delegate. Human-in-the-loop AI formalises that instinct into a governed operating model with defined boundaries, escalation logic, and a full audit trail.

It is worth being precise about what this is not. A system where every AI recommendation still goes to a human for review and approval before anything happens has not solved the problem. The human is still the bottleneck. The AI has not automated the decision. It has added a drafting layer on top of the same workload. The maintenance queue is just as long. The reviewer is just as stretched. Nothing has fundamentally changed about where human attention is being spent.


The Governance Concern and What a Well-Designed System Actually Does

When asset owners, NHS estates teams, and institutional FM buyers first encounter AI-assisted maintenance platforms, a reasonable concern surfaces: if AI is making decisions autonomously, how do we maintain accountability?

It is the right question. And the answer is not to put a human in front of every decision. It is to design the system so that accountability is built into the architecture from the start, so that every action, human or AI, is traceable, auditable, and governed by rules the asset owner has set.

Governance in facility management AI is not about how many decisions humans review. It is about whether the right decisions reach the right reviewer at the right time.

When human sign-off is required at every step, oversight becomes a processing task rather than a governance function. SLA performance degrades. PPM backlogs grow. The humans who should be focusing on consequential decisions spend their time on routine ones.

Governance means structured accountability, not universal human review. The distinction matters enormously for FM operations at scale, and particularly for compliance-driven buyers who need auditability, not paralysis.


What Xempla Believes About Human Expertise in FM

That principle is not abstract. It is the foundation of how Xempla is built.

Xempla is a System of Decisions, a governance layer that defines which decisions AI owns, which escalate to humans, and which stay with the asset owner, before any work order is touched.

The operating belief underneath it is explicit.

Until someone needs to pick up a wrench and go to the asset, most of what happens in an FM operation should be automated or require minimal human supervision. Human expertise should focus on exceptions, not norms.

This reflects how the best FM operations have always worked at their peak. A skilled maintenance manager does not personally approve every PPM work order. They set the standards, review the exceptions, and intervene where their judgement creates value. The problem in traditional FM is not that humans were too involved. It is that the tools available forced them to be involved in everything, including the things that did not need them.

AI, properly governed, does what good FM management has always tried to do. It concentrates human attention where it matters.


The OMI Handover: AI and Human Oversight Across CMMS and BMS

In Xempla's operating model, this belief is made real through the OMI handover: the structured process that determines which decisions the AI agent handles and which ones reach a human reviewer.

OMI is Xempla's AI agent for fault triage and analysis. When an alert comes in, OMI works through it before any human is involved. It checks whether the fault is real or a false alarm, assesses severity, analyses the asset's historical behaviour, correlates contextual parameters, and reviews the facility's own maintenance policies. Where OMI has the authority and confidence to act, it acts. It does not wait.

The ROC, Xempla's Remote Operations Centre, is where human oversight lives. ROC reviewers are Xempla's own internal team, monitoring AI-guided activity across client sites simultaneously. They are not a checkpoint for routine transactions. They are the judgement layer for decisions OMI has determined should not be made without a human.

When OMI reaches one of those decision points, whether due to asset criticality, a compliance obligation, or confidence falling below a defined level, it stops and hands over. The ROC reviewer receives everything: asset history, fault analysis, the data reviewed, contextual correlations, recommended action, and the specific reason the decision was escalated. Not a raw alert. A complete operational brief.

The reviewer makes the call. The decision is logged. OMI continues.

In practice, the large majority of work order decisions never reach the ROC. Roughly one in several decisions, depending on portfolio complexity and asset criticality, escalates to a human reviewer. That is the governance model made operational: most decisions handled at the speed and consistency of AI, the consequential ones handled by a human who has everything they need to act well.


What This Looks Like in Practice: A Real Fault on a Live Site

Definitions explain governance. A real example shows how it works.

A heater battery was flagged for operating continuously at peak condition for more than 30 days. In a traditional FM operation, this alert would land in a supervisor's queue. They would pull historical data if they had time, make a judgement call about whether it warranted a work order, and move on. Under pressure, that review might take minutes and miss critical context. It might not happen at all.

This is what OMI did instead.

It reviewed the alert and identified the parameters driving the fault: heating valve position, inlet temperature, discharge temperature, and space temperature. It then analysed 30 days of historical data across those parameters. The heating valve had remained fully open at 100% with no meaningful variability. The expected temperature rise across the heater battery was inconsistent and repeatedly negative. The asset was demanding maximum output and not delivering it.

OMI expanded the analysis. Space air temperature and setpoint data confirmed that the conditioned space was consistently below the desired setpoint despite continuous maximum heating demand. The asset was not performing. The issue was real, not operational noise.

Before recommending action, OMI checked the facility's work order prioritisation criteria and site-specific maintenance policies. The conditions for generating a corrective work order were not fully met. So OMI recommended further investigation rather than immediate escalation, consolidating its full reasoning into a structured operational summary and handing it to the ROC reviewer.

The ROC reviewer received not a raw alert, but a complete brief: what the data showed, what was ruled out, what OMI concluded, and why it stopped short of a work order.

A call that would previously have required a supervisor to manually triage the alert, review data across multiple systems, and decide against escalation was completed autonomously, with full reasoning attached, and the human reviewer brought in at exactly the right moment with everything they needed.

That is human-in-the-loop facility management AI working as it should.

See how Xempla's operating model performs across live client environments at xempla.ai/case-studies.


What OMI Does Before Any Decision Reaches a Human

The heater battery case is not unusual. It is the standard. Every fault that enters the system goes through the same structured process before a human reviewer is involved or before OMI acts autonomously.

Stage What Happens
Alert review Key parameters responsible for triggering the fault are identified
Historical analysis Trend data across fault-driving parameters is analysed to distinguish persistent issues from noise
Contextual correlation Analysis expands to associated operating parameters to confirm or rule out the fault
Independent fault assessment Observed behaviour is validated as a genuine equipment issue or operational noise
Policy and criteria check Site-specific maintenance policies and work order eligibility criteria are reviewed
Consolidated recommendation A clear position is reached, either act, investigate, or escalate, with full reasoning attached
Handover to ROC (where required) The complete brief is passed to the ROC reviewer when the decision falls outside OMI's operating boundary

The ROC reviewer enters at the last row and only at the last row. Everything above it has already been done. By the time a human is involved, the analysis is complete. The reviewer's role is judgement, not data processing.


What Human-in-the-Loop Is and What It Is Not

What People Assume HITL Means What It Should Actually Mean
A human reviews every AI recommendation before action is taken A human reviews the decisions where their judgement changes the outcome, not every decision
The more human oversight, the safer the system The right human oversight at the right decision point is what makes a system safe; volume of review is not the measure
AI acts, humans approve AI acts within defined boundaries autonomously; humans are not an approval layer, they are a governance layer
Human-in-the-loop slows things down Poorly designed HITL slows things down; well-designed HITL concentrates human attention and speeds up everything it does not touch
If something goes wrong, a human should have caught it If something goes wrong, the governance boundary was wrong; the answer is better boundary design, not more human review
Human oversight means the AI cannot be trusted Human oversight means the system has been designed to know what it does not know; that is a sign of maturity, not weakness
HITL is a temporary measure until AI is good enough to act fully autonomously HITL is the permanent architecture; full autonomy without a human accountability layer is not the destination for regulated FM environments


FAQs

What is human-in-the-loop in facility management AI?

Human-in-the-loop in facility management AI is an operating model where AI handles routine CMMS triage, PPM scheduling, and BMS fault classification autonomously, while a human reviewer receives escalations for decisions that are high-consequence, compliance-sensitive, or outside the AI's authorised operating boundary. The human is present where their judgement changes the outcome, not at every step.

Does human-in-the-loop mean humans approve every AI decision?

No. If every AI recommendation still requires human approval before action, the human remains the bottleneck and nothing has fundamentally changed. Human-in-the-loop means structured escalation with defined boundaries, clear triggers, and human review reserved for the decisions that actually require it.

What is the OMI handover?

The OMI handover is the structured process through which Xempla's AI agent transfers a decision to the ROC reviewer when it falls outside OMI's authorised operating boundary. The handover includes full reasoning, data analysis, contextual correlations, and recommended action, so the reviewer receives a complete brief, not a raw alert.

Who are the human reviewers in Xempla's model?

The human layer in Xempla's operating model is the Remote Operations Centre (ROC), Xempla's own internal team. ROC reviewers monitor AI-guided maintenance activity across client sites and receive escalations from OMI when decisions fall outside defined operating boundaries.

Why does this model matter for NHS and institutional FM buyers?

Regulated environments managing critical assets require two things from an AI operating model: efficiency and documented accountability. Human-in-the-loop delivers both. Routine decisions move faster. Consequential decisions reach a human reviewer with the full context to act on them. The audit trail covers both.

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5
Heading 6

Paragraph

Block quote

Ordered list

  1. Item 1
  2. Item 2
  3. Item 3

Unordered list

  • Item A
  • Item B
  • Item C

Bold text

Emphasis

Superscript

Subscript