Machine-learning control loops have moved out of pilot floors and into whole-portfolio rollouts across Sydney, Melbourne and Brisbane towers. Landlords aren't buying "AI" as a feature — they're buying a reduction in energy spend and callouts, and increasingly they're getting it. But every AI-operated building we've been asked to retrofit has hit the same wall: the algorithms are the easy part. The ELV backbone underneath them — sensor density, point naming, network segmentation — is what actually decides whether the business case survives contact with a real building.
From Rule-Based BMS to Closed-Loop AI Control
A conventional Australian BMS runs on deterministic logic: if zone temperature exceeds a setpoint by X degrees for Y minutes, open the chilled water valve by Z%. That logic, sitting on BACnet/IP or Modbus TCP field networks, has run CBD towers reliably for two decades because it's predictable and easy to commission. It's also blind — it reacts to conditions after they occur and has no concept of what's coming in the next hour.
AI-driven control adds a forecasting layer on top of that same field network. Instead of reacting to a temperature excursion, a predictive model ingests weather forecasts, occupancy schedules, and historical load curves to pre-condition a zone before demand arrives. Critically, in almost every Australian deployment we've reviewed, this layer doesn't replace the BMS — it writes advisory setpoints back into the existing BACnet points database, with the BMS retaining its safety interlocks and fallback logic. The AI engine is a supervisor, not a replacement controller, and any design brief that assumes otherwise is under-scoping the integration risk.
What's Actually Running on Australian CBD Towers Today
Four use cases account for most of the deployed AI capability we see in Australian commercial towers right now, and each has a distinct ELV footprint:
- HVAC setpoint optimisation — forecasting cooling/heating load 4–24 hours ahead using external weather feeds and internal trend data, then nudging AHU and chilled-water setpoints within safe bands.
- Lift dispatch optimisation — destination-control systems using historical traffic patterns and live card-swipe/turnstile data to group passengers and cut average wait time, particularly valuable in towers above 30 levels where lobby congestion is a tenant complaint driver.
- Lighting and scene automation — occupancy- and daylight-linked dimming that goes beyond simple PIR on/off control, using longer-horizon usage patterns to pre-empt rather than just react to presence.
- Fault detection and diagnostics (FDD) — continuously comparing live BMS trend data against expected equipment behaviour to flag a drifting valve, a stuck damper or a failing VSD weeks before it trips an alarm.
Of these, FDD is where Australian owners are seeing the fastest payback, because it needs the least new field hardware — it largely runs on trend data the BMS is already collecting, provided that data has been named and structured well enough for a model to use it (more on that below).
The Sensor Density Problem AI Exposes
Compliance-driven BMS designs typically place one temperature sensor per air-handling zone — often one AHU serving several hundred square metres. That's sufficient to run a PID loop but nowhere near enough resolution for a zone-level comfort or occupancy model, which needs CO2, VOC and people-counting data at a materially finer grain. In practice, Australian fitouts moving to genuine AI-driven comfort control are specifying one multi-sensor node per 60–100 m² rather than per AHU zone — a five- to ten-fold increase in point count on some floors.
That density shift has real consequences for the ELV design, not just the software licence:
- PoE switch capacity needs re-budgeting — a floor that carried 40 BMS field points might carry 300+ sensor endpoints once wireless multi-sensors and gateway nodes are added.
- Wireless mesh (Zigbee, Thread or proprietary 2.4 GHz sensor networks) is now the default for retrofit sensor density in occupied Australian towers, since running new low-voltage cabling to hundreds of ceiling points in a live building is rarely viable.
- Gateway placement needs its own containment and power provision — these aren't BMS field devices, and treating them as an afterthought on the BMS drawings is the single most common coordination gap we see on retrofit projects.
- Battery-powered sensor nodes need a maintenance regime built into the facilities contract from day one, not bolted on after the first round of battery failures six months post-handover.
Data Contracts: Why Point Naming Decides Whether AI Works
The most underestimated line item in an AI-buildings brief is metadata. A model trained to spot a failing chiller valve across a landlord's twelve-building Sydney portfolio needs every building's BMS points tagged consistently — the same physical function (say, "chilled water valve position, AHU-3, Level 12") has to resolve to the same semantic meaning whether it's building A's Honeywell head-end or building B's Schneider system. Without that, a model has to be retrained per building, which kills the economics of portfolio-scale AI.
This is where semantic tagging frameworks — Project Haystack tags or Brick Schema class hierarchies — earn their place in an Australian ELV specification. Rather than leaving point naming to whatever convention the original BMS integrator used, the design brief should mandate a tagging schema at handover, with trend intervals specified per point class (not a blanket five-minute trend for everything, which either drowns the analytics platform in noise or misses the fast-moving signals a fault model actually needs).
Design takeaway: An AI platform is only as good as the metadata beneath it. Specifying a Haystack- or Brick-tagged point schema and a trend-interval strategy at design stage is cheaper by an order of magnitude than re-tagging a live BMS database after the analytics platform goes live and starts returning nonsense.
Network Segmentation for AI Workloads
An AI analytics platform typically needs read access across systems that were never designed to share a network segment — BMS trend data, sub-metering, access-control event logs and lift traffic counts all feed the same model. That breadth of access is exactly why a flat OT network, tolerable for a single-vendor BMS, becomes a genuine risk once an analytics platform is granted cross-system visibility. The pattern we specify for Australian towers is a dedicated analytics VLAN behind an OT firewall, with the analytics platform granted read-only API access to each source system rather than direct network-layer access to field controllers — the platform should never be able to write directly to a BACnet device without passing back through the BMS's own interlocked logic.
Protocol translation sits in the middle of this architecture: field devices speak BACnet/IP or Modbus TCP, while the analytics platform typically consumes normalised data over MQTT or a REST/OPC-UA gateway. That translation layer — usually a small edge gateway appliance in the comms room — is genuinely part of the ELV scope and should appear on the single-line diagram, not get left to a software integrator to sort out post-handover.
Where the Model Actually Runs: Edge vs Cloud Inference
Not every AI function belongs in the cloud. The rule that's held up across the Australian deployments we've reviewed is simple: anything sitting inside a real-time control loop needs local edge inference so the building keeps functioning through an internet or cloud-service outage; anything doing portfolio-wide learning or long-horizon analytics belongs in the cloud.
- Edge (on-site compute, typically a small rack-mounted server or industrial PC in the comms room): HVAC setpoint control, lift dispatch, any logic where a five-second cloud round-trip is unacceptable or where continuity through a WAN outage is a genuine safety or comfort requirement.
- Cloud: cross-building model training, portfolio benchmarking, FDD trend analysis over months of history, and dashboards for facilities managers and asset owners.
Trained models are then periodically pushed back down to the edge compute layer — a pattern that keeps the building operable offline while still benefiting from portfolio-scale learning. Specifying edge compute capacity (rack space, power, cooling, network drops) at design stage avoids the common failure mode of an AI vendor discovering post-contract that there's nowhere in the comms room to physically put their appliance.
A Composite Retrofit: What This Looks Like on an Occupied Tower
A typical scope we see on a 25–35 level occupied CBD tower moving to AI-assisted operations starts with a two-week BMS data audit — checking point coverage, trend history quality and existing naming conventions — before a single new sensor is ordered. That audit routinely surfaces gaps that have nothing to do with AI: missing trend logs, dead sensors nobody noticed because nothing alarmed, and inconsistent point naming left over from three generations of BMS contractor. Only once that baseline is clean does the sensor-density uplift and analytics platform integration begin, staged floor by floor rather than as a single cutover — which lets the FM team validate FDD alerts against real faults before the system is trusted for setpoint write-back.
What This Means for Australian Landlords Right Now
Three decisions determine whether an AI-operations business case actually lands: whether the existing BMS data is clean enough to train on without a costly re-tagging exercise, whether the network architecture separates the analytics platform from direct field-device access, and whether edge compute capacity has been reserved before a vendor is selected. Owners who treat these as software procurement decisions rather than ELV design decisions consistently end up paying for the same integration work twice — once badly, during a rushed vendor onboarding, and once properly, when the second attempt gets specified correctly from the start.
Where This Is Heading
The functions described here — forecasting, FDD, lift dispatch — are still supervisory: a human or the underlying BMS retains final authority. The next step, closed-loop autonomous operation without human sign-off on every action, raises a different set of instrumentation and liability questions that we cover separately. For now, the buildings seeing the strongest returns are the ones that got the unglamorous plumbing right first — sensor density, point naming, network segmentation — because that plumbing is what any future autonomy layer will have to stand on.
Frequently Asked Questions
Does an existing Australian BMS need to be replaced to add AI control?
Usually not. Most AI overlays sit above the existing BACnet or Modbus network and write setpoints back through the same points the BMS already exposes. The BMS keeps its role as the safety-interlocked control layer; the AI engine acts as an advisory or supervisory layer unless the owner has explicitly commissioned closed-loop write-back with fallback logic.
How much extra sensor hardware does an AI-operated building actually need?
It depends on what already exists. Many Australian towers built in the last decade have enough BMS trend points for basic fault detection and diagnostics, but zone-level comfort optimisation and occupancy-linked control typically need additional CO2, VOC and people-counting sensors at a materially higher density than a compliance-only fitout — often one sensor node per 60–100 m² rather than per floor or per air-handling zone.
Where should the AI models actually run — on-site or in the cloud?
For anything in a real-time control loop — HVAC setpoint adjustment, lift dispatch, life-safety-adjacent logic — inference should run on local edge compute so the loop survives an internet outage. Cloud platforms are the right place for portfolio-wide model training, benchmarking and long-term analytics, with trained models periodically pushed back down to the edge.
Is a converged IT/OT network a security risk for an AI-operated building?
A converged network isn't inherently unsafe, but a flat one is. The risk comes from AI platforms needing broader read access across BMS, metering and access-control data than a traditional BMS head-end ever did, which is exactly why VLAN segmentation, a dedicated OT firewall zone and least-privilege API access for the analytics platform need to be designed in from day one, not retrofitted after a breach.