From Smart Buildings to Accountable Operations

Reader’s route

Start with the operating loop and evidence checks; then set authority limits, establish incident and exit arrangements, and use the energy context and readiness gates to inform portfolio decisions.

1. The operating problem behind the technology

A building can be digitally visible without being operationally understood. An occupancy platform may show movement without explaining whether people could find appropriate work settings. A fault-detection tool may identify anomalies that no one has time or authority to investigate. An energy model may recommend a set-point change that conflicts with ventilation requirements or a tenant obligation. In each case, the technology has produced information, but the organisation has not yet established a defensible decision.

JLL’s survey-based analysis draws attention to the gap between technology ambition and the organisational capabilities needed to support it [JLL]. Its page describes a survey population of more than 1,000 senior CRE decision-makers across 16 markets. This is useful evidence about reported organisational practice, not a controlled experiment showing that a particular product improves performance. Different passages also describe one adoption measure differently; this paper therefore does not chart that measure or use it to infer market-wide deployment maturity.

The resulting management question is not whether AI belongs in FM. It is which use, under which conditions, is sufficiently evidenced and controllable to become part of normal service delivery. That reframing moves the discussion from product labels to operating responsibilities.

2. Research method and boundaries

This is a structured narrative synthesis, not a systematic review or a new field study. Four accessible primary publications were selected for their relevance to organisational adoption, building-AI evaluation, incident response and energy context. Their publication dates fall between 1 April 2025 and 26 August 2026. Source pages and documents were checked on 1 September 2026. Publication date and observation period are treated separately: a report published in 2025 may legitimately contain estimates for 2024.

The sources are deliberately heterogeneous. JLL reports survey-based observations; Hong and Li provide research-documentation guidance; NIST provides institutional technical recommendations; the IEA combines historical estimates with scenario-based projections. This paper does not pool their populations or attach statistical confidence to its own management framework. No new survey, building measurement or commercial product test was undertaken.

An AI application means software that uses an AI model to classify, predict, generate or recommend. Building analytics is the broader practice of analysing operational data and need not involve AI. Automation refers to the authority to perform an action, which is separate from model sophistication. The proposed operating loop, approval gates and implementation sequence are original Osmos recommendations. They require local engineering, commercial and organisational judgement before adoption.

3. Make the full operational loop visible

Osmos proposes four connected stages: observe, validate, act and verify. Observation captures a condition or signal with its time, location and quality. Validation establishes whether the condition is credible and material. Action assigns an approved intervention to someone with the resources and authority to carry it out. Verification checks whether the intended physical or service outcome followed. An unresolved or recurring condition returns to investigation rather than disappearing into a closed record.

This structure prevents several common accounting errors. An alert is not a fault confirmed. A work order is not a repair completed. A repair completed is not necessarily a problem resolved. Likewise, a model recommendation does not become a saving until the organisation can show a change against a defensible comparison. Each stage should retain its own status, evidence and owner.

The loop also exposes non-technical barriers. Access may depend on a landlord; remedial expenditure may sit with another cost centre; equipment may be unavailable during business hours. Those constraints should remain visible in the outcome record. Otherwise the digital team is blamed for unresolved conditions it cannot change, or a supplier receives credit for benefits delivered through unrelated operational work.

Figure 1. The accountable operational loop Original Osmos Global conceptual framework, 2026. Not a measured dataset. Prepared 1 September 2026.

What this means: An alert earns value only through a verified operational outcome.

4. Build evidence before claiming performance

Hong and Li emphasise documenting data, methods, evaluation and reproducibility in AI-based building studies [HONG, §§3.1–3.6]. Their paper is not a catalogue of achieved savings. Its examples illustrate how research should be reported. Osmos applies that discipline to procurement and operations: the buyer should be able to understand what data a claim rests on and whether the evaluation resembles the intended site.

A credible data record identifies equipment, units, timestamps, sampling frequency and changes in configuration. Missing records, out-of-range values and changes in sensor coverage should be reported rather than silently smoothed away. Training and evaluation periods must be separated where models learn from historical records. Testing on a building already represented in training may not establish performance at an unseen site.

The comparison matters as much as the model. Predictive maintenance should be assessed against the existing maintenance practice or another suitable baseline, not against an artificially weak alternative.

Classification accuracy alone can hide costly false alarms or missed critical events. Teams should examine the kinds of errors that affect their decisions and the capacity required to investigate them.

Energy evaluation needs particular care. Weather, occupancy, operating hours and plant changes may affect consumption alongside the intervention. A before-and-after bill comparison is not automatically a causal estimate. The measurement plan should identify which factors are controlled, modelled or left uncertain.

Where the evidence cannot isolate the effect, report an association or an unresolved result instead of a verified saving.

Figure 2. Four checks before accepting a performance claim Original Osmos Global framework informed by Hong and Li (2026), §§3.1–3.5, CC BY 4.0. No source diagram reproduced. Prepared 1 September 2026.

What this means: A strong algorithm cannot compensate for an invalid comparison.

5. Set the authority boundary separately from intelligence

A model can be useful without being allowed to control equipment. Osmos recommends considering four authority levels: read-only observation, recommendations for review, actions requiring approval, and narrowly bounded automation. These are governance choices, not a universal maturity ladder. A sensitive application may appropriately remain advisory even when its predictions improve.

For each use, document who can authorise an action, which limits apply, what is logged and how the action can be reversed. The approved limits should come from the relevant engineering and operating requirements, not from an AI-generated instruction. Generative outputs require additional care because a plausible explanation can conceal a factual error or unsupported equipment-specific assumption. Model version, retrieval sources and validation arrangements belong in the record [HONG, §3.6].

Higher authority increases the importance of supervision and fallback. A building team should know which functions remain available if a model, network or supplier service fails. The fallback must be compatible with the site’s safety systems and approved procedures. This paper does not prescribe control sequences, isolation actions or emergency settings; those decisions require competent personnel with site-specific knowledge.

Figure 3. Choose the authority boundary explicitly Original Osmos Global conceptual framework, 2026. Categories are not a maturity score. Prepared 1 September 2026.

What this means: More accurate predictions do not automatically justify more control authority.

6. Treat incident response and procurement as one system

NIST SP 800-61 Rev. 3 places incident response within broader cybersecurity risk management [NIST]. Its supply-chain considerations include contractual arrangements and supplier participation in response activities. Its recovery guidance calls for verifying restoration. Applied to buildings, these ideas suggest that cybersecurity cannot be handed off entirely to a platform vendor while FM retains the consequences of disruption.

Before procurement, identify the operator, IT security owner, equipment maintainer and supplier contacts who would participate in an incident. Agree what information they need, how they communicate and who can approve changes. A technically connected platform may span several contracts; gaps between those contracts can become delays during recovery. The incident exercise should test those interfaces rather than assume they will work.

Contracts should also address data export, configuration records, service dependencies and transition assistance. An exit route is valuable even if the relationship continues, because it tests whether the organisation understands its own operational information. Exported files are not necessarily useful unless equipment identifiers, units and relevant history survive the transfer.

Recovery evidence should distinguish digital availability from safe operational readiness. A dashboard coming back online does not prove that underlying equipment is correctly configured or that all changes were authorised. Reconnection and restoration should follow approved local procedures, with engineering checks appropriate to the affected systems. NIST’s cross-sector guidance informs this recommendation; it is not a building-safety certification.

7. Put AI’s energy context in the right frame

The IEA estimates that data centres consumed approximately 415 TWh of electricity worldwide in 2024. In its Base Case, consumption rises to approximately 945 TWh in 2030 [IEA, Energy demand from AI]. The first figure is an estimate of a past year; the second is a scenario projection. Both include data-centre workloads beyond AI. They should not be described as electricity used solely by building analytics or solely by generative AI.

Figure 4 places those values side by side without presenting the future value as a measured outcome. The comparison establishes scale and direction within the IEA’s modelling, not a forecast of an individual organisation’s electricity bill. It cannot be netted against a percentage saving reported by an unrelated building study: boundaries, units and populations would be incompatible.

For a local business case, ask which computing resources the application actually requires, whether existing infrastructure can be used and which operating benefit will be measured. The IEA also discusses opportunities for AI in energy optimisation, but potential under adoption scenarios is not a guarantee of project-level performance. The decision should recognise both the resource cost of the application and the uncertainty around its benefits.

Figure 4. Global data-centre electricity consumption Source: IEA (2025), Energy and AI, Energy demand from AI, CC BY 4.0. Original Osmos chart; rounded source values; no IEA endorsement.

Prepared 1 September 2026.

What this means: The projected global footprint is context—not a calculation of an FM application’s net benefit.

8. Regional context is not a site-level allocation rule

The IEA identifies the United States, China and Europe as accounting for approximately 45%, 25% and 15% respectively of global data-centre electricity consumption in 2024 [IEA, Executive summary]. Figure 5 includes an approximately 15% remainder calculated from those rounded shares. It is explicitly a derived category, not a separately measured regional estimate reproduced from a source table.

These shares describe where electricity was consumed by data centres in that year. They do not allocate the carbon footprint of a particular software service, identify where an individual company’s workloads run or establish the carbon intensity of a specific facility. Electricity mix, workload location and accounting boundaries matter for any such analysis. The chart is therefore a geographical context panel, not a ranking of sustainable AI services.

For India’s GCC leaders, the more immediate operating issue is whether technology can be governed across diverse sites. A leased office and an owner-operated campus may have different rights to building data and controls. A global analytics standard can define the evidence required while allowing local implementation to reflect equipment, contractual access and service responsibilities. No India-specific adoption rate or savings estimate is inferred from the global sources.

Figure 5. Where data centres consumed electricity in 2024 Source: IEA (2025), Energy and AI, Executive summary, CC BY 4.0. Rest of world = 100−45−25−15; rounded inputs. Original Osmos chart; no IEA endorsement. Prepared 1 September 2026.

What this means: Regional electricity shares cannot allocate a particular software service’s carbon footprint.

9. Scale through readiness gates, not installation counts

A portfolio rollout should begin by classifying sites according to the use case and their readiness to support it.

Relevant factors include data quality, equipment mapping, responsible staff, access rights, maintenance capacity and incident arrangements. A site may be ready for read-only monitoring but not for automated action. Recording that distinction supports progress without relaxing controls.

Osmos proposes three implementation phases: define the decision and baseline; test the evidence and operating response; then review verified outcomes and choose whether to scale, adapt or stop. Figure 6 groups these into an illustrative 90-day sequence. It is a planning aid, not an empirically established deployment duration. Complex sites or material safety dependencies may require substantially longer.

The first gate should approve a bounded problem, not a vendor feature list. The second should review both technical performance and the ability to act on findings. The third should examine the outcome, total operating effort and unresolved limitations. A technically accurate tool may still be poor value if every result requires disproportionate investigation. Conversely, a modest model may be useful if it reliably improves a high-value decision.

Before scaling, deliberately test one site that differs from the pilot in a relevant way. That might mean a different plant type, data environment or tenancy arrangement. The purpose is to discover which assumptions travel and which do not. Failure to transfer should lead to a revised scope or evaluation, not an automatic claim that local teams resisted innovation.

Figure 6. An illustrative 90-day readiness sequence Original Osmos Global planning framework, 2026. Illustrative timings, not an empirical deployment benchmark. Prepared 1 September 2026.

What this means: Scale, adapt or stop according to the evidence at each gate.

10. The management record and practical conclusion

The programme record should connect the use case, evidence, authority and outcome. For each application, retain its responsible owner, evaluation baseline, relevant model and configuration versions, approved action limits, unresolved risks, recurring operating cost and decision date. Finance should challenge monetary claims, engineering should challenge physical interpretations, and the operating owner should explain whether the result is useful in practice.

Report stopped or restricted uses alongside successful ones. Discontinuing an application after a fair test can be a good management result; hiding that decision weakens institutional learning. Where the organisation has insufficient evidence, the appropriate status is unresolved rather than successful by default. Avoid aggregating incomparable results into a single maturity score that conceals material differences in risk.

The principal limitation of this paper is that the proposed framework has not been tested as a causal intervention. The sources support its component disciplines, but they do not establish a universal return on investment. Its value is as an explicit decision structure that teams can challenge, adapt and evaluate. The next step is therefore a bounded operational test with agreed evidence and responsibilities—not an assumption that the presence of AI makes the building smart.

Decision checklist for the next investment review

• FM leaders: name the operating owner and confirm that the team can investigate and complete the actions the system generates. • CRE and GCC leaders: verify site-level data and control rights before assuming one pilot can be copied across the portfolio. • IT and security teams: document service dependencies, incident roles, logging and approved restoration checks with the building operator. • Procurement teams: test data portability and transition arrangements alongside functionality, support and price. • Finance and assurance teams: distinguish forecast benefits from verified outcomes and keep the comparison method visible.

Apply the checklist before selecting technology and again when the authority boundary, supplier arrangement or site scope changes. An unresolved item does not always require abandonment, but it should have an owner, an agreed treatment and an explicit effect on the decision. None of these checks substitutes for engineering approval of safety-relevant controls. Their purpose is to ensure that an investment decision does not run ahead of its evidence or its operating capacity.

Source notes

[JLL] Yuehan Wang. Reality check: The true pace and payoffs of AI adoption in corporate real estate. JLL, 2025-10-27. Key highlights; AI pilot selection; Lessons learned. Accessed 1 September 2026. https://www.jll.com/en-hk/insights/global-real-estate-cre-technology-survey [HONG] Tianzhen Hong and Han Li. Good practices for documenting AI-based studies on energy and buildings. Energy & Buildings / Elsevier; author copy hosted by Lawrence Berkeley National Laboratory, 2026-01-20. Sections 2, 3.1–3.6 and 4; pp. 1–4. DOI: 10.1016/j.enbuild.2026.117043. Accessed 1 September 2026. https://eta-publications.lbl.gov/sites/default/files/2026-06/1-s2.0-s0378778826001039-main.pdf [NIST] Alexander Nelson, Sanjay Rekhi, Murugiah Souppaya and Karen Scarfone. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. National Institute of Standards and Technology, 2025-04-03. Section 2; Table 2 GV.SC-05/08; Table 3 RC.RP. DOI: 10.6028/NIST.SP.800-61r3. Accessed 1 September 2026.

https://csrc.nist.gov/pubs/sp/800/61/r3/final

[IEA] International Energy Agency. Energy and AI. IEA, Paris, 2025-04-10. Executive summary; Energy demand from AI; AI for energy optimisation and innovation. Accessed 1 September 2026.

Editorial and visual note

This is original Osmos Global analysis informed by the cited publications. Reported findings are distinguished from Osmos recommendations and illustrative scenarios. Source findings and trademarks remain attributable to their owners. Original visual designs do not imply endorsement by source organisations. The content is general research and does not replace site-specific professional advice.

IEA data attribution: IEA (2025), Energy and AI, IEA, Paris. Licence: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Visuals are newly designed by Osmos; any calculation is identified in its caption.