Published on :
August 28, 2026
by
Anisha Bhattacharjee
Views...
AI is playing an increasingly active role in facilities management. It is no longer only used to analyse operational data or surface insights. In some environments, it is also being used to help diagnose why something is happening and to recommend what should be done next.
That shift changes the question FM leaders need to ask. It is no longer only "What can AI do?" It is also "How should AI make and act on decisions?"
This is where governance becomes increasingly important. Manual review, approval processes, and post-action checks can provide effective oversight. But as AI takes on more of this work across a larger portfolio, relying on those controls alone can become harder to sustain consistently. The more consequential the decisions a system supports, the more important it becomes to have governance built into how those decisions happen, rather than relying on processes wrapped around them afterward.
In facilities management, governance is about making sure operational decisions follow defined rules, are supported by appropriate evidence, and can be understood and accounted for. We've explored what that means in more depth on our Governance in FM page.
The question this piece is interested in is narrower: how does governance actually get built into an AI-supported decision process, rather than checked around it? There is no single model every FM organisation needs to follow. What it looks like will depend on the asset, the operational context, and how much autonomy an organisation is prepared to allow. The underlying principle remains the same. Governance needs to be present at the point where information becomes a decision, not applied after the fact. In autonomous maintenance specifically, where a system can move from flagging an issue toward recommending or initiating a response, this becomes especially visible: governance shapes how that sequence of decisions happens.
Consider a simple case. An AI system detects that a solar inverter is behaving differently from its usual pattern. That detection is useful, but it's only the beginning. The system still needs to work out whether the deviation is meaningful or just normal variation, and what evidence supports that conclusion. It needs some sense of how serious the issue is, and whether it's the kind of finding that should be escalated to a person or simply logged for reference. It also needs a clear standard for what counts as the issue actually being fixed, and later, a way to check whether it was.
Each of those is a separate decision point, and each one is a place where a rule, a boundary, an evidence requirement, or a verification step can either be built in deliberately or left to chance. That's why governance matters more as AI takes on a larger role in these decisions. It isn't primarily about controlling the AI. It's about making the decision process itself consistent, explainable, and accountable at every one of these points, not only the first one.
The difference isn't necessarily whether people stay involved; that's decided by how much judgement a given situation needs. The difference is where the control actually sits: built into the process itself, or applied around it after something has already happened. The objective isn't maximum autonomy. It's appropriate autonomy within boundaries that were decided on deliberately, not discovered after something went wrong.
This is also how we've approached the problem at Xempla. Working in autonomous maintenance, we've been thinking about governance alongside decision-making from the beginning, rather than as a layer added once a system is already making decisions. That thinking is reflected in the DIIV Cycle: Discover, Investigate, Implement, Verify. Rather than treating governance as a checkpoint sitting outside that cycle, each phase carries its own governance question.
A real solar inverter case makes each of these concrete, and shows specifically where the governance sits at each step.
A 50kW solar inverter had operated consistently around 38kW, roughly 76% of its rated capacity, since commissioning. In mid-December, an AI agent detected a sustained change in performance: PV power down approximately 21.5%, total inverter output down approximately 26.7%, with a corresponding shift in system variability. The governance question in this step isn't simply whether a deviation was detected. It's what the system was allowed to treat as a meaningful change. Here, the deviation was assessed against the asset's established operating behaviour rather than treated as an isolated abnormal reading, making the basis for the finding explicit rather than assumed.
The finding didn't immediately become a work order. A diagnostic case was built around the deviation, the evidence behind it, and a proposed explanation. An engineer reviewed that case and confirmed it: the inverter had been producing under 50% of expected energy since November 1, with the underperformance traced to specific components, including String 1.1 and Optimizer 1.3.7. The governance here isn't the diagnosis itself. It's the rule governing what happens once that diagnosis exists: in this case, the finding required engineer review and confirmation before it could move forward, which is what earned it escalation rather than sitting as an unverified system output.
From there, the diagnosis would become work on the ground: a technician carrying out the corrective action identified through the investigation. The governance question at this stage is what action is appropriate, and what has to be confirmed before it counts as complete. A job marked closed isn't, by itself, that confirmation. Implementation needs its own defined standard for what "done" actually means, set in advance rather than assumed.
The final question would be whether the intervention actually worked: comparing post-intervention performance against the baseline set before the deviation. Even with a job confirmed complete, if performance doesn't recover, the issue shouldn't be treated as resolved. It should go back to investigation. That is where previous outcomes become part of governance: what happened in an earlier intervention informs what happens with the next decision, rather than every recurrence being logged as something new.
DIIV is one way we've put that principle into practice. It isn't the only possible model, and governance will look different across organisations depending on their systems, risk tolerance, and how much autonomy they're ready to allow.
But as AI takes on a larger role in facilities management, the question worth asking will increasingly move past whether AI can support a decision. It will be whether you can show how that decision was made, why it was allowed to happen, and whether it produced the outcome you expected.
Governance can be embedded by defining decision rules, evidence requirements, action boundaries, and outcome verification at each stage of the workflow, rather than relying only on review after an AI-supported decision has been made.
Governance should define what the system can treat as a meaningful issue, what evidence is needed to escalate it, what actions are permitted, what requires human judgement, and what evidence is needed to confirm the outcome.
Human review isn't a fixed requirement across every stage. Governance defines where a person needs to confirm a system's finding before it proceeds, and where the process can move forward without that step, based on the evidence and the stakes involved.
Implementation confirms that the prescribed corrective action was actually carried out. Verification checks something different: whether the underlying problem was actually resolved, measured against the asset's performance rather than the status of the work order.
© Xempla. All rights reserved.