AI in FM, Part II: Your AI Is Only as Smart as the Data Behind It. So Let's Talk About the Data.

In Part I of this series, my co-founder Martin said that “You can't shove AI at chaos and expect it to make things better.” The leak sensor story. The janitor with the mop. The AI that worked perfectly and the process that didn't. If you haven't read that one, go back and start there — it'll make this one land harder.

Today I want to talk about what you actually do about the chaos. And the answer, frustratingly, is data governance.

I say frustratingly because "data governance" sounds daunting and abstract, like something that lives in a 300 page three-ring binder on a VP's shelf. Like a compliance checkbox. Like something your IT department handles and then nobody thinks about again. That's not what I mean.

What I mean is: who is responsible for the accuracy of your asset list? What happens when a vendor changes and the new contact doesn't get updated? When a piece of equipment gets replaced and the old record stays in the system untouched for two years — whose fault is that, and who's going to fix it?

Those are governance questions. And they're people questions.  IFMA's own FMJ Magazine made this point directly in their Data Unlocked series last year: data governance "is not just a technical exercise — it is about establishing a culture in which data is treated as a valuable asset." I'd frame it even more bluntly: the technology is rarely the problem. The habits, the ownership, and the accountability structures around the technology are almost always the problem.

What Governance Actually Is

Salesforce's data governance guide defines it well: governance is the structured approach to managing data integrity, security, usability, and compliance — it defines who has access to what, and keeps data accurate, accessible, and protected. But I want to translate it into facility management terms.

Integrity means: is this asset record accurate? Is the last-serviced date real, or is it the date someone finally got around to entering it?

Usability means: can a technician on their phone, standing in a mechanical room, actually find what they need in under thirty seconds?

And "who has access to what" — in FM, that often means: who has permission to close a work order? Who can mark an asset as decommissioned? If the answer is "anyone," you're going to end up with records that are a mess.

Here's the part that trips up most FM teams: data governance is not the same as data management. Data management focuses on the technical storage and processing of data. Governance defines the rules and responsibilities that ensure data is handled correctly at every stage. Buying software is data management. Deciding how your team will use it — what fields are required, what naming conventions you'll use for assets, who reviews records when someone leaves the company — that's governance. You can have the best software in the world and still have a governance disaster. 

Buying software is data management. Deciding how your team will use it — what fields are required, what naming conventions you'll use for assets, who reviews records when someone leaves the company — that's governance. You can have the best software in the world and still have a governance disaster.

What Governance Would Have Actually Done

Let me go back to Jose and his mop bucket for a second, because we didn’t actually finish that story.

The leak sensor triggered. The alert fired. The FM team ran. And when they got there, it was the janitor — again.

We used that story in Part I to illustrate that the technology worked and the process failed. But I want to be more specific now, because "the process failed" is too easy. What exactly failed?

Jose's Tuesday and Thursday 6:30 AM cleaning rounds were never entered into any system. They existed in his head, in the building manager's head, and maybe in a paper schedule in a back office somewhere. When the sensors went live, nobody ran a commissioning checklist that asked: are there routine activities in this zone that involve water on the floor? That question would have surfaced the schedule. But there was no checklist, because there were no governance standards for bringing a new sensor system online.

If that cleaning schedule had been a record in the system — a recurring scheduled activity, linked to that floor location — a few things become possible. Alert suppression during known maintenance windows. A low-confidence flag on alerts that fire during those windows. At minimum, a note in the dispatch queue that says scheduled cleaning in progress, confirm before responding.

The FM team doesn't run down the hall. Or if they do, they do it once, update the record, and it never happens again.

That's data governance. Not a dashboard. Not a data warehouse. Just: operational context lives in the same place as equipment data, someone owns it, and there's a process for capturing it before you go live with something new.

Here's what specifically broke down, in governance terms. The cleaning schedule was tribal knowledge that never got captured — the first failure pattern we see in almost every FM organization. The sensor commissioning had no standard operating procedure requiring documentation of known water-use activities in the zone — a data completeness failure. And nobody owned the cleaning schedule as a record, so even if someone had thought to enter it once, there was no accountability for keeping it current when the janitorial schedule changed.

Three governance failures. One very tired facilities manager.

The Three Things That Actually Break FM Data

I've supported enough facilities teams to know the failure patterns. They cluster around three things.

1. The first is tribal knowledge that never gets captured. Jose mops at 6:30 AM. The loading dock door sensor is sensitive — don't trust it. This information exists in people's heads, in text message threads, in the institutional memory of employees who have been there for fifteen years. When those people leave, the knowledge leaves too. Governance means building the habit — and the systems — to capture it before it walks out the door.

2. The second is inconsistency in how things get recorded. One technician writes "replaced filter" in a work order. Another writes "PM complete." A third writes nothing and just closes the ticket. Three records, zero useful data. When different teams access conflicting versions of the same data, communication and planning breaks down.In FM, this shows up as not knowing if something was actually fixed, or not being able to pull a meaningful maintenance history on an asset when it fails again six months later. This is exactly the problem that FM industry standards like Omniclass and UniFormat were designed to address at a classification level — they give organizations a shared vocabulary for assets and systems so that "AHU-3" means the same thing to every team member, every vendor, and every system. You don't have to implement a full BIM environment to benefit from that thinking. Just pick a naming convention, document it, and enforce it.

3. The third is no ownership. The IFMA Data Unlocked series describes this well, distinguishing between data stewards — who are responsible for ensuring data quality and consistency across the organization — and data custodians, who maintain the accuracy and completeness of data day-to-day. In a small FM team, one person might play both roles. But the key word is person. Not a department. Not a policy document. A named individual who is accountable when the asset list goes stale. 

Why This Matters for AI

Here's what I keep telling people: data is the lifeblood of AI. The more diverse and integrated the data from various sources, the smarter and more autonomous the AI becomes. Without governance, your AI initiatives are likely to fail.

I'll say it more bluntly in FM terms. If your work order history is a mess of inconsistent entries, an AI can't tell you which assets are approaching end-of-life. If your asset records have wrong locations, an AI-powered routing tool sends technicians to the wrong place. If your preventive maintenance schedules are aspirational rather than actual — meaning, they represent what you planned to do, not what you did — the patterns an AI finds in that data are fiction.

Garbage in, garbage out has always been true. AI just makes it faster and more expensive.

A Realistic Starting Point

I'm not going to tell you to implement a formal governance framework with a council and a Chief Data Officer and a data catalog. That's not where most FM teams are, and it's not where you need to start.

The IFMA Data Unlocked series recommends starting with a data readiness assessment — an honest look at the current state of your data, where the gaps are, and where management practices need improvement. I'd translate that to three practical questions for any FM team.

One: what are the five or six fields that actually matter on a work order? Require those. Let the rest be optional. Mandate completion on close.

Two: who owns the asset list? One person. Not a department — a person. That person audits it twice a year and is responsible for keeping it current when equipment changes, vendors change, or staff turns over.

Three: what's your naming convention? Building A, Suite 100, AHU-3 — or is it first floor east wing air handler, or HVAC unit 3A? Pick one. Write it down. Make it stick.  If you want to go further, look at how Omniclass categorizes assets — it's a free standard and gives you a proven starting point rather than inventing your own.

That's governance. It's not glamorous. It's also the thing that makes everything else possible.

One honest warning: the IFMA article flags stakeholder buy-in as one of the hardest governance challenges, and they're right. People resist changing how they enter data, especially when they're busy and the payoff feels abstract. The answer isn't a mandate — it's making the right behavior the easy behavior. Short forms. Mobile-friendly tools. Defaults that guide people toward consistency rather than relying on them to remember the rules.

The Foundation Is the Point

At sonpito, we built our product for this layer — not for the AI layer, not for the analytics layer, but for the capture layer. Simple enough that your team will actually use it in the field. Structured enough that the data you collect is worth something.

We call it data governance before intelligence. The IT world figured this out twenty years ago with help desk software. The FM industry is working through it now — and resources like IFMA's Data Unlocked series and Salesforce's data governance guide are good places to go deeper if you want the formal framework behind the principles.

AI is going to make FM teams dramatically more effective. But only for the ones who've done the unglamorous work first. Strong data governance is the foundation for better decision-making — it transforms data from a byproduct of daily operations into a trusted, strategic asset.

Build the foundation. The intelligence will follow.

This is Part II of a two-part series on AI in FM. Read Part I here.

For further reading on data governance frameworks in FM, see IFMA's Data Unlocked series and Salesforce's Guide to Data Governance.