Smart Buildings & AI: How Machine Learning Cuts HVAC Energy Use

In 2018, the survey year behind the U.S. Energy Information Administration's (EIA) latest published breakdown, commercial buildings consumed about 6.8 quadrillion British thermal units of energy, and space heating alone was the largest single use at roughly 32% of it. Heating, ventilation, and air conditioning (HVAC) systems in most of those buildings still run on schedules written years ago. Machine learning offers a different approach: forecast who will be in the building and what the weather will do, then run the equipment to that forecast. This article explains how that works, what the evidence shows, and where it falls short.

Where building energy actually goes

Before asking what artificial intelligence (AI) can save, it helps to know what is being spent. The EIA's Commercial Buildings Energy Consumption Survey (CBECS) is the standard U.S. reference. Its 2018 round put space heating at about 32% of commercial building energy use, ventilation at about 10%, and lighting at about 10% (EIA, Use of energy explained: commercial buildings). EIA notes that climate shifts the heating and cooling shares, which is why a hospital in Minnesota and an office in Texas produce very different pie charts.

Two points follow from those numbers. First, the thermal side of a building (heating, cooling, and moving air) is where most of the controllable energy sits. Second, that energy is controllable in a literal sense: a boiler, chiller, or fan can run harder or softer depending on instructions from a controller. Lighting is mostly a yes-or-no question, but HVAC is a continuous dial, and continuous dials are where optimization pays off.

End use in U.S. commercial buildings (2018 CBECS)	Approximate share of energy use	How much a control system can influence it
Space heating	About 32%	High: setpoints, start times, supply temperatures
Ventilation	About 10%	High: fan speed, outdoor air rate, scheduling
Lighting	About 10%	Moderate: dimming, occupancy sensing
Cooling and other uses	Not broken out on the cited EIA page	Cooling is high; other uses vary

Source: U.S. Energy Information Administration, 2018 CBECS summary. Cooling and remaining categories are not given on the page cited here, so no figure is shown for them.

The table makes the opportunity concrete without overstating it. A control system cannot make a poorly insulated building efficient, and it cannot shrink the energy needed to move heat across a bad window. What it can do is stop the equipment from working harder than the situation requires.

Why fixed schedules waste energy

A conventional building automation system works like a train timetable. The 6:05 train leaves at 6:05 whether it carries 400 commuters or four. Heating might start at 5 a.m. and cooling at 10 a.m. every weekday, and each zone holds a fixed temperature during "occupied" hours. When someone complains about the cold, a facilities manager nudges a setpoint. That is the entire feedback loop in many older buildings.

The trouble is that real occupancy never follows the timetable. Meetings run long, people travel, teams work remotely on different days, and whole floors sit empty during slow weeks. Weather also refuses to follow the schedule: a sunny, mild morning needs far less heating than the timetable assumes, and a cloudy afternoon may need more cooling than predicted. A schedule is a guess made once, and the building lives with that guess for years.

A machine-learning controller works more like a ride-hailing app. It does not run to a fixed route. It estimates demand a few hours ahead, dispatches resources to match, and corrects as conditions change. The analogy has limits (a building cannot drive to the passenger), but the core idea holds: replace a static plan with a rolling forecast.

Why the building's own physics matters

Buildings store heat. A concrete floor slab warmed by afternoon sun releases that heat into the evening, and a cooled slab stays cool for hours after the chiller shuts off. Think of a building as a bathtub of heat with leaky walls: the water level is the indoor temperature, the drain is heat loss through the envelope, and the tap is the HVAC system. The depth of the tub (thermal mass) determines how quickly the level responds to the tap.

A schedule cannot exploit this. A controller that knows the tub's shape can start cooling earlier at a gentler rate, finish exactly when people arrive, and avoid running equipment at peak output. That knowledge of the building's response is the second ingredient of smart building control, after the occupancy forecast.

The three prediction problems inside "smart building AI"

Marketing copy often bundles everything under a single label. In practice, three distinct problems are being solved, each with different data and models. Reading a vendor claim usefully means knowing which of the three it refers to.

Occupancy and load forecasting

The first problem is estimating how many people will be in each zone over the next few hours, and how much heat, humidity, and carbon dioxide (CO₂) they will produce. Typical inputs include badge-swipe records, meeting-room calendar bookings, counts of devices connected to Wi-Fi, CO₂ sensor readings, and motion sensors.

Models range from simple (average the same hour on previous weekdays) to sequence models such as long short-term memory (LSTM) networks, a type of neural network built to retain patterns across time steps. The right choice depends on data volume. A building with one year of clean badge data may be better served by a boring statistical model than by a deep network, a point that applies across the field. Our explainer on time series forecasting covers why simple baselines are hard to beat on short horizons.

Horizon matters more than elegance. HVAC systems respond slowly, so a forecast of the next one to four hours is usually what matters for pre-conditioning a zone. A perfect forecast for next Thursday is worth little if the equipment cannot act on it.

Setpoint optimization: from rules to model predictive control

The second problem converts forecasts into instructions. The most established method is model predictive control (MPC). At each decision step, the controller uses a model of the building to simulate what would happen over the next several hours under different sequences of actions, picks the sequence with the lowest energy cost that respects comfort limits, applies only the first action, and then repeats the whole calculation at the next step.

A GPS navigation unit works the same way. It plans a route to the destination, you drive for a minute, traffic changes, and it replans. It never commits to the full route blindly. This rolling re-optimization is what makes MPC robust to forecast errors: a wrong prediction costs one step of slightly suboptimal action, not an entire day.

The building model inside MPC is often a "grey-box" model, meaning a physics-inspired structure (resistances and capacitances standing in for walls, air, and slabs) whose parameters are fitted from measured data. Machine learning contributes in two places: fitting those parameters, and replacing hand-built components, such as a weather-dependent chiller efficiency curve, with learned ones.

Reinforcement learning and the simulation gap

A newer approach uses reinforcement learning (RL), in which a software agent learns a control policy by trial and error, rewarded for saving energy and penalized for discomfort. Our reinforcement learning explainer covers the general mechanism. The difficulty in buildings is that trial and error in a real building is slow and risky: you cannot try 10,000 bad strategies on an occupied floor.

The usual workaround is to train in a simulated building and then deploy to the real one. That works only as well as the simulator, and the mismatch between simulation and reality (the "sim-to-real gap") is a well-known weakness. The Building Optimization Testing framework, BOPTEST, exists partly to address the evaluation side of this problem. It provides ready-made building emulators, a standard interface for controllers, and standard performance indicators, so different control strategies can be compared on the same virtual buildings. BOPTEST grew out of the International Building Performance Simulation Association's Project 1, with contacts at Lawrence Berkeley National Laboratory and KU Leuven, and received partial funding from the U.S. Department of Energy's Building Technologies Office (BOPTEST project page).

The practical consequence is that published claims for any controller are only meaningful relative to a benchmark. A savings figure from a bespoke simulation, with a bespoke baseline, cannot be compared with one from a different study.

Fault detection and predictive maintenance

The third problem has little to do with comfort and much to do with waste and failure. HVAC equipment degrades in recognizable ways before it breaks. A damper sticks half-open, a valve leaks so that a heating coil and a cooling coil run at the same time, a sensor drifts and tells the controller the room is warmer than it is, a compressor draws more current for the same cooling output.

Fault detection and diagnosis (FDD) software watches measured signals against expected behavior. Expected behavior can come from rules ("heating valve and cooling valve should not both be open"), from a physics model, or from a statistical model of normal operation. Anomaly detectors, including autoencoders (neural networks trained to reconstruct normal data, which flag inputs they reconstruct poorly), flag readings outside the learned normal range.

The right analogy is a doctor tracking blood pressure over years rather than waiting for a heart attack. The system does not diagnose the cause. It notices a trend and asks a technician to look. Much of the real-world value of FDD comes from finding the waste that has been running unnoticed for years, such as simultaneous heating and cooling, rather than from preventing dramatic failures.

Field work at Lawrence Berkeley National Laboratory's building research group illustrates how much of this is unglamorous engineering. Its recent publication list includes multi-site field studies of control sequences for air handling units and guides for assessing central plant retrofits (LBNL publications). The theme is that getting existing equipment to behave as designed is often as valuable as adding a clever algorithm on top.

What data a smart HVAC system needs

Every claim about AI-driven buildings rests on data pipelines, and these fail in mundane ways. The table lists the common data streams, what each is used for, and how it typically goes wrong.

Data stream	Used for	Common failure
Badge or access-control logs	Occupancy forecasting	Tailgating, doors left open, contractors without badges
Meeting-room calendars	Short-horizon load forecasts	Booked rooms nobody uses; ad hoc meetings with no booking
Wi-Fi device counts	Occupancy estimates	One person with three devices; guests; devices left at desks
CO₂ sensors	Direct occupancy proxy, ventilation control	Calibration drift; sensors placed far from breathing zones
Weather forecasts	Load prediction, pre-conditioning	Forecast error, especially for sun and wind
Temperature and humidity sensors	Comfort tracking, model fitting	Drift, poor placement, sensors near vents
Equipment telemetry (current, pressure, flow, speed)	FDD, efficiency modeling	Missing points, wrong units, inconsistent naming

Two cautions come out of this table. First, an occupancy model built from badge data answers a different question than one built from CO₂ readings: the first counts people who entered, the second measures people who are present and breathing. Second, many failures are not model failures at all. A "forecast error" is frequently a sensor that was recalibrated last month and never documented.

Building automation systems also speak a variety of protocols, and point names vary by installer. Mapping thousands of unlabeled data points to meaningful concepts ("supply air temperature, floor 3, air handler 2") is a large share of the work in any deployment and is rarely mentioned in product brochures. It is the building equivalent of the cleaning work described in our data cleaning explainer.

What the documented results show

Public, methodologically transparent results are rarer than the marketing suggests. The best-documented case comes from data centers, not offices.

The number everyone quotes: In July 2016, DeepMind reported that a system of neural networks trained on historical sensor data had consistently cut the energy Google's data center used for cooling by 40%. After accounting for electrical losses and other non-cooling inefficiencies, the company described this as a 15% reduction in overall power usage effectiveness (PUE) overhead. (DeepMind, 2016)

The details matter. DeepMind trained an ensemble of deep neural networks on data from thousands of sensors (temperatures, power, pump speeds, setpoints) to predict future PUE, the ratio of total facility energy to computing energy. Two further network ensembles predicted temperature and pressure over the next hour and were used to check that proposed actions stayed within safe limits. The 40% figure refers to cooling energy only, not total facility energy.

In 2018, DeepMind described a successor that controlled cooling autonomously. Every five minutes, a cloud-based system took a snapshot of thousands of sensors, predicted the effect of candidate actions, selected those that minimized energy use within safety constraints defined by operators, and passed them to the local control system for verification. The company reported average savings of about 30%, up from roughly 12% when autonomous control first launched, and stressed that operators could exit AI control at any time, with the system falling back to existing rules (DeepMind, 2018).

Source	Setting	Reported result	Why it may not transfer to an office
DeepMind, July 2016	Google data center	40% less cooling energy; about 15% lower PUE overhead	Constant computing load, thousands of sensors, no occupants to keep comfortable
DeepMind, 2018	Google data center, autonomous control	About 30% average savings, up from about 12% at launch	Same; plus operators defined the safety envelope in detail
Smart Energy Analytics Campaign (data reported by 2020)	About 6,500 buildings in 104 organizations, over 600 million square feet	Participants' analytics software projected to save $95 million and 4 TBtu per year	Energy management and information systems broadly, not specifically machine learning; savings are projected, not all measured

Sources: DeepMind blog posts (2016, 2018); Smart Energy Analytics Campaign project page.

The third row deserves attention because it is the most relevant to ordinary buildings. The Campaign tracks organizations that adopted energy management and information systems (EMIS), a category that includes simple fault detection and trend analysis as well as more advanced analytics (Smart Energy Analytics Campaign). The headline there is that savings accumulate across thousands of ordinary buildings from relatively unglamorous tools. That is a more realistic picture of the near-term opportunity than a single spectacular percentage.

Why a data center is the easy case

A data center is nearly the ideal setting for machine learning control. Computing load is high and fairly steady, sensors are dense because operators care about every degree, there are no occupants to keep comfortable, and a single operator controls the plant. Most importantly, the energy being optimized is large and concentrated, so a modest percentage translates into a visible number.

An office floor is the opposite: variable occupancy, sparse sensors, mixed preferences, tenants who control their own thermostats, and equipment of many vintages. The same algorithm can be excellent in both settings and still deliver very different percentages. This is why a vendor's quoted range, without a stated baseline, building type, and climate, is a marketing number rather than a planning number. We discuss the data center side of this in how AI data centers use electricity.

How savings are measured, and why it is hard

Proving that a controller saved energy is harder than it sounds, because you cannot observe the same building both with and without the controller in the same weather. Practitioners estimate a baseline, a statistical model of what the building would have used, built from pre-installation data and adjusted for weather and occupancy. Savings are the difference between that baseline and measured use.

Each step can go wrong. A baseline built from a mild year overstates savings in a harsh one. A building that changes its occupancy pattern during the measurement period shifts the baseline underneath you. A concurrent lighting retrofit gets credited to the wrong project. Weather normalization methods matter, and so do the length and quality of the pre-installation data. Because the baseline is itself a model, two honest analysts can report different savings from the same data.

A good deployment therefore defines, in advance, the baseline method, the metering used, the period of measurement, and what counts as an adjustment. Be skeptical of savings claims that omit these. A related trap is comparing against a poorly tuned starting point: a building whose controls had drifted badly will show large savings from simply being retuned, savings that a competent human commissioning engineer could have captured without any AI.

Comfort is a constraint, not a number

Smart controllers do not decide how comfortable people should be. They optimize inside limits set by people. The reference document for those limits in the United States is ASHRAE Standard 55, currently the 2023 edition, titled Thermal Environmental Conditions for Human Occupancy (ASHRAE standards list).

The standard treats thermal comfort as the product of six factors rather than temperature alone: air temperature, the temperature of surrounding surfaces (radiant temperature), air speed, humidity, how active people are, and how much clothing they wear. This is why a room at a single air temperature can feel fine near an interior wall and cold beside a cold window. A well-designed controller works inside the acceptable region the standard defines, looking for the cheapest combination of conditions within it, and holds hard override limits so that an unconstrained optimizer cannot save energy by letting a room drift into discomfort.

Individual preference varies widely, and no single building-wide setting satisfies everyone. The practical remedy is finer zoning, which brings us to cost.

Grid-interactive buildings: when timing matters as much as quantity

Saving kilowatt-hours is one goal. Moving them in time is another. A building that knows its thermal mass can pre-cool in the early morning when electricity is cheaper or the grid is less stressed, then coast through the afternoon peak with the chiller idle. The U.S. Department of Energy's Building Technologies Office describes research on grid-interactive efficient buildings (GEBs) aimed at exactly this kind of connectedness (DOE Building Technologies Office).

This matters for the wider energy system. Buildings that shift flexible loads can reduce the need for peaking power plants and make better use of midday solar output. Our pieces on why grid storage is hard and on how AI optimizes renewable energy grids explain the other side of that exchange. A building's thermal mass is a free, if modest, battery, and smart controls are how it gets used.

Heat pumps raise the stakes further. As more buildings electrify heating, flexible and efficient control of electric heat becomes a grid issue, not only a bill issue. Our explainer on how heat pumps move heat efficiently covers why a heat pump's efficiency depends on the temperatures it works between, which is exactly what a predictive controller can manage better than a fixed schedule.

Where this breaks down

Models go stale

An occupancy model learns the pattern of a particular period. When the pattern changes (remote work, a new tenant, a redesigned floor, a heat wave) the model's forecasts degrade, often without an obvious alarm. This is a case of model drift, covered in our explainer on what model drift means in production. A deployment needs scheduled retraining and monitoring that compares forecasts with outcomes, or the savings erode quietly.

Overfitting is a related risk. A flexible model fitted to one winter can memorize quirks that do not recur. Our article on overfitting and underfitting explains why held-out testing across seasons is the minimum standard for trusting a model.

Retrofit cost and old equipment

Buildings with older, non-digital controls cannot accept automated setpoints at all. Adding sensors, actuators, and a controller that can take commands is a capital project whose size depends on building size, equipment age, and how much of the existing wiring can be reused. That cost, not the algorithm, is the main barrier for small and older buildings. Costs vary too widely by site to quote a typical figure responsibly, and vendor payback claims should be tested against a site-specific audit.

Comfort complaints and zoning

When one setting must serve a floor of people with different preferences, someone will be unhappy, and the complaint will be blamed on the AI. In most such cases the underlying limit is the number of independently controlled zones, a hardware constraint. Finer zoning costs money, which is why it is often absent.

Privacy

Occupancy models use data about when people are in particular rooms. Badge logs and device counts can identify individuals. Data protection regimes such as the European Union's General Data Protection Regulation (GDPR) apply to personal data, so operators typically need a lawful basis, clear notice, and data minimization. A design that uses anonymous counts (how many people, not which people) removes most of the exposure and is usually all the HVAC controller needs. That is a design decision the operator must make deliberately.

Cybersecurity and safety

Connecting building controls to cloud analytics adds paths into systems that move air and water and manage fire and life safety. The U.S. National Institute of Standards and Technology's guide to operational technology security, NIST SP 800-82 Revision 3 (September 2023), explicitly covers building automation systems alongside industrial control systems, and describes typical architectures, threats, and countermeasures (NIST SP 800-82r3). The standard guidance applies here: segment the network, grant minimum access, validate commands, and ensure the building can operate safely if the AI layer is offline. That last principle echoes the DeepMind design, in which the system falls back to existing rules if AI control is exited.

Vendor lock-in and data ownership

Proprietary analytics layered over proprietary controls can leave an owner unable to move data or switch vendors. Contracts should specify who owns the historical data, in what format it can be exported, and what happens to the learned models if the relationship ends.

What people get wrong about AI in buildings

The AI is not making creative decisions about comfort. It optimizes inside human-defined constraints. A system that ignored those limits would be unacceptable and would not survive its first heat wave.

The 40% figure is not a general benchmark. It describes cooling energy in a particular data center, measured against that facility's own baseline. It was a landmark demonstration of what the approach can do in a favorable setting, and it is a poor forecast for any other building.

Predictive maintenance is not prophecy. Anomaly detection says that a signal has moved outside its normal range. It does not state what will fail or when. A technician still has to investigate, and many alerts will be false alarms that cost time. Tuning the alert threshold is a trade-off between missed faults and wasted visits.

Smart does not mean efficient by itself. A building with poor insulation, leaking ducts, or oversized equipment will still waste energy, however clever its controls. Envelope and equipment improvements often have a longer life and a more certain payoff than software.

More sensors are not automatically better. Each sensor needs calibration, power or batteries, network access, and eventual replacement. Sensors added without a purpose become a maintenance burden and a security surface. Start from the decision the data will inform.

What a sensible deployment looks like

Organizations that report success tend to follow a similar order of operations, and it begins with the unglamorous steps.

1. Fix the basics first. Commission existing equipment, repair stuck dampers and leaking valves, and verify that sensors read correctly. Many of the early savings come from this step.
2. Add monitoring before control. Fault detection and trend analysis give a measured view of where energy goes and create the baseline needed to prove later savings.
3. Pilot control in a few zones. Compare against comparable zones left alone, with override limits and a clear fallback.
4. Define measurement in advance. Agree on the baseline method, the metering, and what adjustments are allowed.
5. Plan for maintenance of the models. Assign someone to watch forecast accuracy, retrain on a schedule, and handle alerts.
6. Protect the data and the network. Decide what personal data is truly needed, and secure the control path.

The order matters because analytics on bad data produce confident nonsense, and control on a faulty plant tunes around the faults instead of fixing them.

Frequently asked questions

Q: How much energy can AI save in a typical office building? A: There is no reliable single figure. Google reported 40% less cooling energy in a data center in 2016 and about 30% average savings with autonomous control in 2018, but data centers are unusually favorable settings. For ordinary buildings, the Smart Energy Analytics Campaign reports projected savings of $95 million and 4 TBtu per year across about 6,500 buildings using energy management and information systems, which is a collective figure rather than a per-building promise. Savings depend on starting condition, climate, and measurement method.

Q: What data does an AI HVAC system use? A: Typical inputs include badge or Wi-Fi occupancy counts, meeting-room calendars, CO₂ and temperature sensors, weather forecasts, and equipment telemetry such as current, pressure, and fan speed. The quality and labeling of those data matter more than the model type, and many deployment problems trace back to sensor drift or inconsistent point names.

Q: Does AI make a building less comfortable? A: It should not. Well-configured systems optimize inside comfort limits, such as those defined by ASHRAE Standard 55, and make changes gradually. Complaints more often reflect limited zoning, where one setting must serve people with different preferences, than the controller itself. Override limits should always exist.

Q: What is the difference between a smart thermostat and an AI-optimized building? A: A smart thermostat learns the schedule and preferences for one zone or home from a limited set of sensors. Building-wide optimization coordinates many zones and shared plant equipment such as chillers, boilers, and air handlers, usually draws on more data sources, and often includes fault detection. The control problem is larger and the consequences of error are greater.

Q: Can this work in homes and apartment buildings? A: Partly. Consumer thermostats apply simplified versions of the same idea. Building-wide optimization in multi-unit housing is harder because occupancy is less predictable, preferences differ between tenants, and there are usually no calendars or badge systems to provide forecasts. Turnover also resets what the model has learned.

Q: Do these systems replace existing HVAC hardware? A: Usually not. The software issues setpoints and schedules to existing equipment through its controls. The main cost is in sensors, connectivity, and a control system able to accept commands. Equipment too old to take digital commands may need replacement or an interface retrofit.

Q: What happens when occupancy patterns change suddenly? A: Forecast accuracy falls because the model is matching against history that no longer applies. The remedy is monitoring that compares forecasts with actual occupancy, plus scheduled retraining, so degradation is caught early rather than discovered on the energy bill.

The takeaway

Smart-building AI works by replacing a fixed timetable with a rolling forecast. It predicts occupancy, uses a model of the building's thermal behavior to choose efficient actions inside comfort limits, and watches equipment for the drift that precedes waste or failure. The most cited number, a 40% cut in cooling energy at a Google data center, is real, but it comes from the easiest possible setting. In ordinary buildings, the gains are more modest, more dependent on sensor quality and honest baselines, and often start with fixing the equipment that already exists. The technology is best understood as a way to run a building closer to what it actually needs, with its limits set by data quality, retrofit cost, and the discipline of maintaining the models over time.

Sources

• DeepMind AI reduces Google data centre cooling bill by 40% (July 20, 2016)
• Safety-first AI for autonomous data centre cooling and industrial control (DeepMind, 2018)
• U.S. EIA, Use of energy explained: commercial buildings
• Smart Energy Analytics Campaign
• BOPTEST, building control benchmarking framework
• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• Lawrence Berkeley National Laboratory, building research publications
• FLEXLAB, Berkeley Lab's building and grid testbed, used to test building and grid technologies under real-world conditions
• U.S. DOE Building Technologies Office
• ASHRAE standards list, including Standard 55-2023

---

Read next:

• Smart Cities and AI: How Machine Learning Reduces Urban Energy Waste
• Complete AI Guide 2026
• Complete Machine Learning Guide 2026
• How to Reduce Your Electricity Bill