What large language models change for IoT

Why IoT under-delivered

Operating buildings accounts for around 30% of global final energy consumption.²³ The International Energy Agency has estimated that using real-time data to improve operations could cut their energy use by 10%.²⁴ For more than a decade, the Internet of Things has promised to deliver exactly this data. It has delivered the data. It has rarely delivered the value.

The pattern was visible early. McKinsey found that only about 1% of the data from the 30,000 sensors on a typical oil rig was used.¹ In buildings, a 2020 Omdia survey of 248 users found that 77% of smart-building users keep the data their facilities generate, but 42% do not analyse it.⁵ McKinsey later named interoperability and installation among the main headwinds: almost every large deployment needs customisation.²

The underlying reason is not missing sensors. It is missing meaning. A building automation system can hold thousands of data points with labels such as AHU2_SAT_SP or Rm214.T, following conventions that differ from site to site, if one exists at all. Normalising the metadata of a typical five-storey office building can take weeks of expert work, an approach the researchers call clearly not scalable.³ Researchers at Lawrence Berkeley National Laboratory describe understanding the buildings’ data streams as the major bottleneck of digitising existing buildings.⁴

The layer LLMs change

It helps to see an IoT system as a stack of five layers, from the device on the wall to the action in the building. Classic IoT and analytics improved the lower layers: cheaper sensors, better connectivity, cloud storage. The layer in the middle, where data gets its meaning, stayed manual. That is the layer where large language models are strongest.

This is also where my own work has taught me the most. Measuring indoor conditions around the clock is a solved problem. Making those measurements mean something to the people who run a building, in their terms, for their decisions, is where projects succeed or stall.

Four shifts

1. From naming chaos to shared semantic models

The building industry has worked for years on shared vocabularies for data points. Brick and Project Haystack announced in 2018 that they would fold their approaches into the proposed ASHRAE Standard 223.⁶ The proposed standard, 223P, went through a second public review in spring 2026 and is not yet final,⁷ and the U.S. Department of Energy notes that none of the existing schemas is yet a consensus standard.⁸ The schemas exist; the bottleneck has been the expert effort to map each building onto them.

LLMs change that effort. Researchers at Berkeley Lab have set out how LLMs can create and query Brick models, precisely because building and querying ontologies requires scarce expertise.⁹ A 2026 approach from AWS classifies building automation points into Brick classes by combining retrieval of similar labelled examples with several models, and sends uncertain cases to human reviewers; it outperformed earlier fine-tuned language models on the buildings tested.¹⁰ The pattern matters more than the numbers: the machine does the bulk of the mapping, and the expert decides the doubtful cases.

2. From dashboards to questions

Dashboards answer the questions someone thought of when building them. Operators have other questions. Berkeley Lab has shown an approach in which a model turns a plain-language question into a query over the building’s semantic model, retrieves the matching time series from the automation system and computes the answer.¹¹ On a public benchmark, the BrickQA method improved answer accuracy (F1) by 0.29 to 0.36 on average over a standard agent baseline, at about half a cent per question in its cheapest setting, and answered 9 of 10 time-series questions on a fault-detection dataset correctly. The authors note that the results come from a single run with one model on small, cleaned datasets.¹²

3. From thresholds to rules that explain

Fault detection in buildings has long relied on fixed thresholds or opaque machine-learning models. A 2025 study let an LLM write and refine detection rules as executable code. It reached an F1 score of 0.926 on a public HVAC fault dataset, against 0.902 for the next best method, while two methods in which the LLM read the time series directly scored 0.083 and 0.021.¹³ The result is a clear design lesson: use the language model to produce logic that engineers can read and test, and let conventional code run that logic on the data.

4. From monitoring to proposals for control

The most ambitious shift is from observing a building to acting on it. Early work showed that GPT-4, given task descriptions and examples, could control HVAC in a way comparable to reinforcement learning with few samples.¹⁵ In a 2026 simulation of a five-zone office, an LLM-based controller had 4.95% comfort violations, against 18.49% for model predictive control and 28.91% for rule-based control, while using less energy than predictive control but more than the rule-based baseline.¹⁶ The study covers one simulated building over three winter days, with setpoints clamped to safe bounds. It shows potential, not proof.

Where LLMs do not help

The same research that shows the potential also marks the boundaries. In an analysis of three LLM-based forecasting methods, removing the language model or replacing it with a simple attention layer did not reduce accuracy and usually improved it.¹⁴ For numbers, purpose-built models remain better and cheaper. A review of LLMs for building energy applications lists compute and API cost, data privacy, missing domain knowledge and inconsistent answers as the main challenges, and recommends validation and expert review.¹⁷

Three practical limits follow. First, an LLM cannot repair bad data; it can only describe it more fluently. Second, many building decisions need answers in seconds and must keep working when the connection fails, which argues for small models or plain logic close to the equipment. Small models that run on a phone show that this is feasible.¹⁹ Third, every new capability is also a new attack surface.

The relationship also runs the other way. IoT gives AI something it lacks: continuous, measured facts about the physical world. An AI system that reasons about a building without live data is guessing. With it, its proposals can be checked against what actually happens.

Design principles

From the evidence and from building such systems, six principles stand out.

Why it matters now

In the EU, building automation is no longer optional for larger buildings. The recast Energy Performance of Buildings Directive requires Member States to ensure that non-residential buildings whose heating, air-conditioning or combined heating or air-conditioning and ventilation systems exceed 290 kW have building automation and control systems by the end of 2024, and those above 70 kW by the end of 2029, where technically and economically feasible. These systems must monitor, log and analyse energy use, detect efficiency losses and be interoperable across proprietary technologies; since 29 May 2026 they must also be able to monitor indoor environmental quality.²⁰ The Smart Readiness Indicator, an optional EU scheme today,²¹ is to be applied to non-residential buildings above 290 kW through a delegated act that the Commission must adopt by 30 June 2027.²⁵

The obligation creates the data. Large language models make it far cheaper to turn that data into understanding. Organisations that combine the two carefully, with clear semantics, bounded autonomy and people in charge of what the building does, will get the value IoT has long promised.

Frequently asked questions