Heating, ventilation and air conditioning typically make up the largest share of a commercial building's energy use, yet most buildings still run on fixed schedules and static set-points. AI adds weather and occupancy forecasts, a model of the building and an optimiser (or learned controller) that adjusts set-points every few minutes, detects faults and shifts load to cheap or green hours. Documented projects report double-digit percentage HVAC savings, but results depend heavily on the baseline and data quality.
Problem & value
- Today: a building automation system (BMS/BACS) executes rules and schedules set once at commissioning. Operators react to complaints, simulate rarely and see little of the interplay between weather, thermal mass, occupancy, heat pumps, PV and tariffs. Faults (stuck valves, simultaneous heating and cooling, drifting sensors) can run unnoticed for months.
- AI value: (1) load forecasting, (2) predictive control such as pre-conditioning based on weather and occupancy, (3) fault detection and diagnostics (FDD), (4) coordinating HVAC with PV, storage, EV charging and dynamic tariffs, (5) reporting for regulation and ESG.
- Evidence: DeepMind reported about a 40% reduction in cooling energy in a Google data centre using ML recommendations (2016); that is a data-centre result and must not be transferred 1:1 to offices [3]. Model-predictive control (MPC) in buildings is well studied; reported savings vary widely, so insist on measured baselines (IPMVP-style) rather than vendor claims.
- Regulatory pull: the recast EU Energy Performance of Buildings Directive (EU) 2024/1275 requires building automation and control systems in non-residential buildings with large HVAC systems (above 290 kW by end of 2024, above 70 kW by end of 2029, where technically and economically feasible) that can monitor, log, analyse and adjust energy use [1]. National transposition (deadline May 2026) varies, so check local law.
Variants
- Offices, schools, hospitals, universities and municipal estates: portfolio-wide analytics with central optimisation.
- Retail chains and hotels: many similar sites, templated models, strong tariff and occupancy effects.
- Data centres and cleanrooms: cooling optimisation with tighter safety limits.
- Residential and housing associations: heat-pump and district-heating optimisation; for single homes see OPT-032.
- Campus/district level: coordination with CHP and heating networks (OPT-023) and storage (OPT-011).
How it works
- BMS/IoT data (BACnet, Modbus, KNX, MQTT) + meters + weather forecast + tariffs + occupancy
- ingestion & semantic model (Brick / BIM, point mapping)
- forecasting (load, PV, occupancy) and grey-/black-box thermal model
- optimisation: MPC / MILP solver or RL policy with comfort constraints
- safety layer (limits, rate limits, fallback to BMS default)
- set-point write-back (supervisory layer, not direct actuator control)
- monitoring: M&V, FDD alerts, operator dashboard, LLM explanation
- Forecasting: gradient boosting or time-series foundation models (e.g. Chronos, TimesFM) for load, PV and occupancy.
- Control: MPC with a simplified RC thermal model solved as LP/MILP/QP is the most robust approach; RL policies are trained in simulators (EnergyPlus, Modelica) and increasingly benchmarked on BOPTEST [4][5].
- FDD: rules (ASHRAE guideline style) plus anomaly detection on trend data, as in ANOM-001.
- LLM layer: translates alarms into plain language, answers "why was it cold in room 3.12?", drafts work orders, and maps messy point names to Brick classes. The LLM never writes set-points directly.
- Human-in-the-loop: facility manager approves operating modes and comfort bands; the system acts only within them and reverts to BMS control on failure.
Data preparation
Needed: meter data (electricity, heat, water), building management system (BMS) trends, sensor data for temperature, CO2 and occupancy, weather data, schedules, floor plans and equipment lists. This lives in the BMS, utility portals, meter reading Excel sheets, and paper maintenance logs.
Typical gaps: meters read manually or only monthly, missing sensors, inconsistent point names across vendors, gaps and outliers in time series, and no mapping of meters to rooms or tenants. Access to the BMS is often locked by the installer, and OT networks are separated from IT.
Preparation steps: - Inventory meters, sensors and BMS points (PREP-001, PREP-005). - Install missing sub-meters or gateways; use open protocols such as BACnet or Modbus. - Harmonise point names and units; fill and flag gaps. - Digitise manual meter readings at source (PREP-008). - Record equipment and schedule data in one table (PREP-011).
Rough share of effort: 50-70 percent, as measurement infrastructure is the main hurdle. Use the check in GUIDE-003 early.
Implementation paths
Which path for whom
- SMB: Path A. Ready-made energy-monitoring and HVAC-optimisation products with EU hosting exist, and buildings follow standard patterns.
- Enterprise: Path B. Large property portfolios justify integrating building data from the BMS into own platforms and APIs, because savings scale with portfolio size.
- Developer: Path C. Open-source tools (e.g. Home Assistant, time-series databases, open forecasting libraries) run on HW1 and suit custom products.
- Public: Path C. Municipal buildings favour sovereign, locally operated or EU-hosted open-source stacks for sovereignty and procurement reasons.
Path A — Buy (recommended for most organisations)
- BMS vendors with AI layers: Siemens (DE; Building X / Desigo CC), Schneider Electric (FR; EcoStruxure Building), Honeywell Forge, Johnson Controls OpenBlue, Trane, Carrier Abound.
- Overlay optimisers: aedifion (DE; cloud analytics and optimisation), BrainBox AI (autonomous HVAC), Verdigris-class monitoring, Loxone (AT) for small commercial and smart buildings.
- Choose A when: you have no in-house controls and data-science team; require a vendor performance guarantee; sites are standardised. Check BACnet/OPC UA openness, data ownership and export, EU hosting, cyber-security certification and what happens when the contract ends.
Path B — Build on cloud APIs
- Platform: Azure, AWS or Google Cloud (EU regions) IoT ingestion plus a time-series database; forecasting via hosted foundation models; optimisation with Gurobi, OR-Tools or HiGHS; LLM APIs (Claude, Mistral, GPT, Gemini) for explanation and point mapping.
- Integration: read from the BMS through BACnet/IP gateways or vendor APIs; write back only setpoint hints through a supervisory layer.
- Choose B when: you operate a large portfolio and want differentiated analytics without replacing the BMS.
Path C — Self-host (open source)
- Stack: EnergyPlus and Modelica Buildings library for simulation, BOPTEST for controller benchmarking, Sinergym for RL training [4][5][6], Brick schema for semantics [7], Home Assistant or VOLTTRON-style gateways, TimescaleDB/InfluxDB, HiGHS/OR-Tools for MPC, Chronos or Darts for forecasts, a small open LLM (Qwen, Mistral, Llama class) for explanations.
- Hardware: HW1 is enough (edge gateway or CPU server) for forecasting and MPC; HW2 only if you want a local LLM.
- Effort: needs controls engineers plus data engineers; commissioning on real plant dominates effort.
Path D — Custom training
Worth it for large portfolios with similar building types: train site-specific thermal models or offline-RL policies on years of BMS history, pre-trained in simulation and fine-tuned on real data. Needs at least one heating and one cooling season of clean trend data.
State of the art (2026)
- MPC remains the production workhorse; RL and hybrid approaches have strong simulation results, but real-world deployments are fewer because of sample efficiency, safety and commissioning cost. BOPTEST gives a shared yardstick for comparison [5].
- Time-series foundation models give usable zero-shot load forecasts, reducing per-building model-building effort.
- Semantic data models (Brick, Project Haystack) and LLM-assisted point mapping cut onboarding time, historically the main cost.
- Grid-interactive buildings: optimisation against dynamic prices and flexibility markets, increasingly combined with PV, storage and heat pumps.
- Limits: poor sensor data, missing metering, undocumented control sequences, comfort complaints from over-aggressive pre-conditioning, rebound effects, and savings that are hard to prove without weather-normalised baselines. Learned controllers can behave unpredictably out-of-distribution.
Shared resources & combinations
- Same stack (time-series + optimization-solver + streaming): PRED-007 load forecasting, OPT-011 battery dispatch, OPT-023 district heating, OPT-032 prosumer home energy, OPT-021 EV depot charging, PRED-031 smart-meter disaggregation.
- FDD and maintenance: PRED-006 predictive maintenance, ANOM-001 anomaly detection on sensor streams.
- Inputs: PRED-017 weather forecasting; PRED-046 structural monitoring shares the sensor infrastructure.
- A single edge gateway and time-series platform serves all of these per site.
Effort, cost & KPIs
- Path A: weeks to a few months per site; subscription or savings-share pricing; BMS upgrades may be needed.
- Path B: 4–9 months for the first portfolio rollout; cost driven by integration and metering, not by AI APIs.
- Path C: 6–12 months with a mixed controls/data team; low licence cost.
- KPIs: weather-normalised kWh/m² and CO2 per m²; energy cost per year; peak demand (kW); comfort-hours out of band; fault detection time and fix time; share of hours under automatic optimisation; payback period.
People & change
Involve management for savings targets and investment, the facility manager as process owner, and IT and IT security because BMS and OT networks must be connected safely (GUIDE-013). The installer or service company is a key partner, as it controls BMS access. Data owners (energy billing, property management) provide meter data. Tenants or building users are affected by temperature changes and must be informed.
Works council: depends. If only building technology data is used, §87(1) no. 6 BetrVG is not triggered; it applies when occupancy or access data can be linked to individuals, or when room sensors allow behaviour monitoring. §90(1) no. 3 asks for timely information on AI-planned changes. In the public sector the staff council (Personalrat) takes this role.
Occupancy sensing should be anonymous and counted, not person-related. If personal data is involved, consult the DPO and check a DPIA (GUIDE-005). AI literacy: train facility staff to understand and challenge setpoint recommendations (GUIDE-006). Start with a pilot in one building, keep manual override at all times, and communicate comfort changes in advance. Typical concern: "too cold or too hot". Address it with comfort limits and a complaint channel (GUIDE-008, GUIDE-009).
Risks, regulation & compliance
- EU AI Act: typically minimal risk. Caution: AI used as a safety component in management and operation of critical digital infrastructure, road traffic, or supply of water, gas, heating and electricity is Annex III high-risk (point 2). Ordinary comfort and efficiency control of a building is not that; district-scale heating or grid control may be. Classify per deployment (not legal advice) [2].
- GDPR: occupancy sensing can become personal data (Wi-Fi/MAC, desk booking, camera-based counting); prefer aggregate, anonymous sensors and a DPIA where individuals can be tracked; works-council co-determination in Germany (BetrVG §87).
- Energy law: EPBD BACS duties and national transposition (in Germany the GEG); Energy Efficiency Directive audits; ISO 50001; EN ISO 52120-1.
- Cyber-security: BMS write access is an attack path; segment OT networks, apply NIS2 where in scope, use least-privilege write access and a hardware fallback.
- Safety and comfort: legionella limits, minimum ventilation (workplace regulations), frost protection, and fire/smoke functions must stay outside AI control.
- Mitigations: bounded supervisory set-points, watchdog fallback to BMS logic, audit log of every action, independent M&V.
Getting started
- Audit what exists: BMS type, BACnet access, sub-metering, point naming, heating/cooling plant, and 12+ months of trend data.
- Pick one or two representative buildings; fix metering gaps and sensor drift first.
- Start with analytics only (forecast + FDD, no write-back); quantify savings potential against a weather-normalised baseline.
- Pilot supervisory optimisation (pre-heating, set-point reset) with comfort bands and automatic fallback; run for a full season.
- Scale via a semantic model (Brick) and templated deployment; document EPBD/ISO 50001 evidence.
Sources
- Directive (EU) 2024/1275 (recast EPBD), EUR-Lex — https://eur-lex.europa.eu/eli/dir/2024/1275/oj/eng
- Regulation (EU) 2024/1689 (AI Act), Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- DeepMind — AI reduces Google data centre cooling bill by 40% — https://deepmind.google/discover/blog/deepmind-ai-reduces-google-data-centre-cooling-bill-by-40/
- EnergyPlus (US DOE) — https://energyplus.net
- BOPTEST, IBPSA Project 1 — https://github.com/ibpsa/project1-boptest
- Sinergym, RL environments for building simulation — https://github.com/ugr-sail/sinergym
- Brick Schema — https://brickschema.org
- Chronos time-series foundation models — https://github.com/amazon-science/chronos-forecasting
- EU.BAC — guidelines for EPBD transposition (2026) — https://eubac.org/wp-content/uploads/2026/02/2025_eu.bac-Guidlines-fort-the-transposition-of-the-EPBD.cleaned-.pdf