Who Teaches AI What a Building Means?

A note on perspective: this is a researched piece from a media and industry-reporting perspective, rather than a controls-engineering one. I aim to connect conversations we’re seeing at AutomatedBuildings.com.

The question hiding under the AI conversation

Building automation has been trying to solve versions of one problem for decades: how do systems from different eras, vendors, and disciplines exchange information without forcing the owner to rebuild everything around a single supplier?

In 2000, AutomatedBuildings was already publishing the argument that a genuinely open building system needed more than a communications protocol — interoperability had to reach across devices, software, databases, tools, and user access. Contributors kept returning to the same distinction: interoperable devices were necessary but not sufficient, and meaning, not just connectivity, was the harder half. By 2013, the discussion had moved to owner choice, programming tools, and service competition — the recognition that a system can speak an open protocol and still be closed in practice.

Then the industry collected more data.

By 2015, AutomatedBuildings contributors were writing about building “big data” and about Project Haystack as a way to make that data self-describing. In 2018, the archive was covering the collaboration between BACnet, Project Haystack, and Brick on semantic tagging — and the argument that data needs machine-readable meaning before any downstream application can use it reliably.

The technology changed. The friction did not. Yesterday’s argument was whether two systems could communicate. Today’s is harder: can a machine understand what those systems are saying well enough to reason about the building? Ken Sinclair has made the same point looking back over twenty-six years of the archive — interoperability isn’t a destination, it’s a frontier that climbs a layer higher every generation.

Why this has become urgent

AI raises the stakes because software is moving from displaying information to interpreting it, recommending actions, and, in some cases, taking them. The question is no longer only whether a point can be read. It’s whether software knows what the point represents, what equipment it belongs to, what space that equipment serves, what else affects it, and how much confidence to place in that interpretation.

The scale of the installed-base problem is easy to underrate. The U.S. Energy Information Administration’s 2018 Commercial Buildings Energy Consumption Survey counted about 5.9 million commercial buildings with a median age of 36 years; roughly 933,000 of them reported a building automation system controlling heating or cooling. NIST frames the divide another way: about 60 percent of commercial buildings larger than 50,000 square feet have a BAS, while 87 percent of smaller commercial buildings do not.

So the AI-ready building is not a clean-sheet design. It has to coexist with a large and uneven installed base — modern BACnet systems, legacy controllers, proprietary naming, incomplete documentation, aging trend logs, spreadsheets, BIM files, operator knowledge, and devices that were never meant to feed an AI agent.

The upside is just as concrete. Lawrence Berkeley National Laboratory reported median whole-building savings of 8 percent among organizations running fault detection and diagnostics across 550 buildings and 97 million square feet; a later large-scale analysis put median savings at about 9 percent for FDD users after two years. The opportunity isn’t theoretical. The friction is getting data into a form applications can reuse at scale.

The industry has already built several answers

Part of what makes this topic feel muddled is that the industry hasn’t been ignoring it. It has built several serious approaches.

Project Haystack standardizes semantic data models and web services so operational data can be described consistently. Brick provides an ontology for building assets and the relationships among them. ASHRAE’s proposed Standard 223P defines concepts and a methodology for interoperable, machine-readable semantic models for analytics, control, and automation. The BACnet committee’s Semantic Interoperability Working Group is developing ways for applications to discover and interpret building information automatically, and BACnet itself is moving toward an RDF representation through proposed Addendum ct.

The Coalition for Smarter Buildings, now operating within the Linux Foundation, is working the same problem from several directions at once — semantic modeling, digital building profiles, open controls, cloud BIM, digital twins, and an “interoperable building box.” The point isn’t that one project wins. It’s that multiple parts of the industry are converging on the need for an open, reusable information layer.

The conference agenda says the same thing. Realcomm IBcon’s 2026 program framed “data as infrastructure” as a precondition for analytics, automation, and AI readiness, alongside data governance, interoperability, and agentic AI. Controls-Con 2026 put competing protocols, data strategy, cloud platforms, OT/IT convergence, and cybersecurity on the same list of problems practitioners are solving at once. This is becoming the architecture discussion underneath the smart-building market.

Then AI complicates the answer

If AI can infer context, classify points, read drawings, compare time-series behavior, and generate knowledge graphs, do buildings still need all this painstaking semantic standardization? Could AI just look at a messy point list, recognize that “SAT,” “SupplyAirTmp,” and “AHU1_SAT” are the same concept, and build the model itself?

AutomatedBuildings has published the optimistic version of that idea. In June 2026, Ken Sinclair argued that AI can move interoperability from rigid data mapping toward cognitive reasoning — using context to interpret imperfect labels and generate semantic structure. It’s a useful possibility, because manual mapping has been one of the industry’s recurring cost centers. The archive has also been testing whether BACnet points alone can build a knowledge graph.

NIST is pursuing a more measured version of the same idea. Its building digitization and semantic interoperability work plans to use knowledge graphs, machine learning, and large language models to help define, generate, and apply semantic metadata — but pairs that automation with standard models, software tools, and validation procedures that check whether a building-specific model conforms to the standard. That pairing is the clue.

What AI can and can’t replace

LBNL’s work on semantic interoperability is blunt about the bottleneck: without consistent, self-describing information, advanced building applications stay difficult, labor-intensive, and costly to deploy. A later LBNL study that built Brick models for existing commercial buildings found that understanding each building’s data streams was the major cost of digitization.

AI can attack that bottleneck directly. It can suggest tags, infer likely relationships, reconcile naming variants, pull information out of drawings and documentation, and flag contradictions for review. Those are exactly the tasks that make semantic modeling slow and expensive today.

What AI cannot do is safely turn an inference into unquestioned truth. A model sees a point named “SAT.” The trend range and neighboring points suggest supply air temperature — often a good guess. But the building also has a space temperature, a mixed-air temperature, a discharge sensor added during a retrofit, and a control sequence changed three years ago without a clean drawing update. If the AI is answering a question, a wrong inference is an inconvenience. If it is diagnosing a fault, moving a setpoint, or coordinating equipment, the same mistake has an operational consequence.

So the semantic model does more than teach an AI vocabulary. It becomes the building’s declared record of identifiers, relationships, and context — something AI can help build and maintain, but which still needs provenance, validation, and a defined authority for correction. That also dissolves a false choice now in circulation: standards versus AI. The workable architecture is AI-assisted semantics — use AI to cut the human labor of creating and maintaining the model, then use open standards and validation to keep the result portable, testable, and accountable.

We don’t need a perfectly modeled building before AI can help. We also shouldn’t ask AI to invent an operational reality every time it opens a point list.

The harder question is authority

Once AI can generate a plausible building model, the next question isn’t technical. It’s governance. What is authoritative when sources disagree — the BAS database, the latest BIM model, a commissioning record, the technician who knows the valve was replaced last winter, a semantic graph built from all of them, or the AI’s own inference from operating behavior?

A trustworthy architecture needs a way to record where a relationship came from, when it was last verified, who or what changed it, and how much confidence to place in it. This is why the recent AutomatedBuildings discussion of trust and “admissible” building data matters. AI readiness isn’t just access to data; it’s the ability to tell observed fact from declared model from inferred relationship from authorized action. That distinction only grows more important as the industry talks openly about agentic AI and autonomous operation. The more software is allowed to do, the more it matters to know what the software believes about the building, and why.

A practical answer

The research points to a fairly plain conclusion: AI probably won’t make semantic interoperability obsolete. It’s more likely to make it practical at a scale the industry has never reached by hand. That suggests a division of labor.

• Standards define the portable structure — identifiers, relationships, and validation rules. BACnet, ASHRAE 223P, Haystack, Brick, and other open efforts give the industry a common substrate.
• AI does the expensive translation — discover, classify, map, reconcile, extract, suggest, and continuously check the model against live behavior and new documentation.
• People and owners define authority — which sources are trusted, what may change automatically, what needs review, who owns the resulting model, and how corrections survive the next vendor or platform change.

Work those three layers together and the result beats either extreme.

The question worth putting to the industry

So the question for building automation in 2026 isn’t “which ontology wins?” or even “can AI understand a messy BAS?” The more useful one:

What is the minimum trustworthy, machine-readable description of an existing building that lets AI help without forcing it to guess?

That description probably needs surprisingly little to start: durable identifiers, basic equipment-and-space relationships, clear data access, source provenance, a way to express uncertainty, and a mechanism for people to validate or correct what the machine inferred.

The industry already has most of the pieces. What it doesn’t have yet is agreement on how those pieces become a repeatable, owner-controlled operating layer across the existing building stock. That’s the problem worth solving — it connects 27 years of interoperability work to the next 27 years of intelligent buildings.

AutomatedBuildings.com  ·  Editorial research  ·  Research date September 3, 2026