What is the difference between edge AI and cloud AI for buildings?

Edge AI runs on computing equipment in or near the building: a gateway, a small server in the plant room or a device with built-in processing. Cloud AI runs on remotely hosted computing services, reached over the internet or a private connection. In practice, most building architectures use both, with some functions running locally and others centrally.

So "edge or cloud?" is the wrong question. The useful one is where each function should run, and the answer depends on how fast it must respond, whether it must keep working when the connection fails, how much data it handles, how sensitive that data is and who will look after it.

NIST's guide to operational technology (OT) security, SP 800-82, describes edge computing as computing distributed along the path between the data source and the cloud, which not only collects data for onward transmission but also processes, analyses and acts on it locally. That is precisely the role edge AI plays in a building.

Placing each function

Neither location removes the need for secure access, good data and a defined owner.

Advice and control are different risks

Much building AI today is advisory. It flags a likely fault, suggests a schedule or forecasts a load, and a delayed recommendation is merely an inconvenience. A function that directly changes how plant operates is a different matter: it needs defined limits, a safe state if the AI is unavailable, and a fallback to normal BMS control. No essential building function should sit behind an external service without a documented fallback.

The responsibilities each option brings

Edge devices need power, physical security, patching, monitoring and eventual replacement, in every building where they are installed. Cloud services bring dependencies of their own: on connectivity, on the provider's availability and on the contract, including what happens to your data and models at exit. NIST's guide to OT security (SP 800-82) advises that when OT data is stored in the cloud or on vendor servers, organisations should analyse how the provider protects it and whether further countermeasures are needed. It also recommends multi-factor authentication for remote access to OT systems and monitoring of information flows between security domains.

Location changes the mechanics of governance, not the duty. An edge model in fifty plant rooms needs its updates tested, approved and rolled out fifty times, with a record of which version runs where; a cloud model changes once, but possibly without the building team noticing. Either way someone has to own how outputs are checked and updates approved. For the wider governance, NIST's AI Risk Management Framework offers a structure that works wherever the model runs.

Get the boundary in writing

Whatever the proposal, the supplier should document:

• which functions run locally and which centrally, and why;
• what data leaves the site, how often and how it is protected;
• what happens when the connection, the edge device or the cloud service fails;
• who patches, monitors and replaces each component;
• how model updates are tested and approved.