Who Owns the Building’s Brain? Data Rights, AI Training, and the Next Contract War

If your BAS or PropTech vendor can train AI models on your building’s operational data, who benefits when you’re paying the bill?

Here’s a scenario playing out across commercial portfolios right now: A property owner adds an analytics platform to improve energy performance and tenant comfort. The vendor promises “AI-powered insights” and asks for data access. Eighteen months later, the team wants to switch providers or add a second tool. That’s when they discover the exports are incomplete, the API has usage caps they never negotiated, and the contract grants the vendor rights to use “anonymized, aggregated data” to “improve services”—which can include model training beyond your portfolio unless you draw clear boundaries. At that point, switching costs can get real: it’s not just point data you’re leaving behind, it’s the enriched history, tuned logic, and operational context you paid to create.

At that point, the fight isn’t about dashboards. It’s about leverage. If you can’t export the full dataset (including metadata) and you haven’t set boundaries on reuse and training, the operational intelligence you thought you owned can become something you’re effectively renting.

This isn’t a future problem. Building data has become a strategic asset—and a contract battleground—because AI shifted the value equation. Smart buildings now generate continuous telemetry, context, and work-process history that vendors need to train predictive models, tune fault detection, and verify outcomes. Your building’s “brain” (trends plus metadata plus maintenance history) is now a training dataset. The question is: did you consent to that, can you control it, and can you leave with it intact?

What “data rights” actually means (and why “ownership” isn’t enough)

When facility managers talk about data rights, they often mean “we own the data.” But ownership is meaningless without enforceable permissions. Data rights cover six distinct domains:

Ownership: Who holds legal title to telemetry, metadata, and derived analytics.

Access: Can you pull data in real-time via API? Can you automate exports, or is it “upon request”?

Use permissions: What can the vendor do with your data? Train models? Share with subprocessors? Aggregate across customers?

Derived data: Who owns the fault rules, tagging schemas, normalization mappings, and KPI configurations the vendor built using your data?

Retention and deletion: How long is data kept? What happens to historical trends after termination? Can you verify deletion?

Portability: Can you export data in a usable format with context intact (asset IDs, tags, hierarchies)—or just raw time-series?

Most MSAs and SOWs address ownership vaguely and ignore the rest. That’s where the fights happen.

Why this became urgent (AI, platforms, and the governance gap)

Three forces converged to make data rights unavoidable:

AI needs operational data to learn. Digital twins, predictive analytics, and occupancy optimization don’t just visualize—they train on real building behavior. Vendors need continuous access to trends, alarms, work orders, and metadata. As one industry analysis put it, when AI “leaves the screen,” buildings become operational platforms—and contracts need to specify model training permissions, retention limits, anonymization requirements, and reuse boundaries.

Cloud platforms centralized control. Smart building data used to live on-premise. Now it flows to vendor-hosted platforms. That shift gave vendors leverage: if you want to leave, you need them to export your data. Portability and offboarding terms you never negotiated suddenly determine switching costs.

Responsibility fragmented. IT owns the network. FM owns the systems. Cybersecurity owns access control. But nobody owns data governance. As the industry has noted, “operations never got an MSI”—no Master Systems Integrator for data integration, quality, and decision rights. The result: contracts assume someone else handled it.

The 5 contract battlegrounds (where fights actually happen)

These are the failure modes facility teams encounter after go-live:

• “You own the data” vs. “you can access the data”: Contract says ownership stays with the building. But exports are delayed, incomplete, expensive, or missing metadata (tags, asset IDs, hierarchies). The vendor may host data offshore or use undisclosed subprocessors—triggering cross-border obligations you didn’t plan for. You “own” data you can’t actually control or move.
• Derived data and IP: Vendor claims the fault rules, normalization layers, and KPI models they built using your data. You paid for customization; they say the “intelligence” is theirs. You leave without the improvements—and exports arrive as raw CSVs without schema documentation or the tagging maps that make data usable.
• AI training and model reuse: MSA includes “improve services” language that grants training rights. Your alarms, work-order patterns, and occupancy analytics feed the vendor’s product roadmap—potentially benefiting competitors in your market.
• Retention after termination: What happens to five years of trends, alarm narratives, and maintenance enrichment when you cancel? Does the vendor delete it, archive it, or keep training on it? Most contracts are silent.
• Offboarding timelines and costs: Vendor has 90 days to provide exports. Support ends at termination. The new provider can’t start until data arrives. You’re paying two vendors for three months—or staying locked in.

A real scenario: the analytics platform that became a dependency

A mid-sized portfolio adds a cloud analytics platform to track energy across 12 buildings. The vendor requests API access to BAS trends, alarms, and work orders. The FM signs the MSA: “Customer owns all building data; Vendor may use anonymized, aggregated data to improve services.”

Eighteen months later, the portfolio wants to add a second analytics tool. That’s when they discover: the first vendor’s API has rate limits blocking dual access, fault rules are “proprietary derived data,” the tagging schema doesn’t export, the “improve services” clause granted unlimited training rights, and historical trends arrive as CSVs with no metadata. The new vendor quotes a six-month re-tagging project. The FM is locked in by data dependency.

Regional realities: privacy obligations that change the stakes

Australia: If your organisation is covered by the Privacy Act 1988, some “building data” can become personal information when it’s tied to identifiable people (e.g., access logs, video analytics, named occupancy records). APP 6 generally limits use/disclosure to the purpose you collected it for unless an exception applies (including consent). Before disclosing personal information to an overseas recipient (including many cloud/subprocessor arrangements), APP 8 requires you to take reasonable steps to ensure the overseas recipient doesn’t breach the APPs—and you can remain accountable for their mishandling in some cases. If a breach is likely to result in serious harm, the NDB scheme can trigger notification obligations, which is why vendor incident response and logging cooperation belong in the contract. For organisations designated as responsible entities under the SOCI Act (critical infrastructure or Systems of National Significance), enhanced cyber obligations add incident reporting and risk management requirements that intersect with vendor data access.

United States: Privacy is a patchwork, but California is a practical reference point for contracts. Under CCPA/CPRA, a vendor generally only fits the “service provider/contractor” model if the written contract includes required restrictions—especially limits on retaining/using/disclosing personal information beyond the defined business purpose and limits on using it outside the direct business relationship. California regulations (11 CCR § 7051) require contracts prohibiting vendors from retaining, using, or disclosing personal information for purposes other than performing services—and prohibiting sale or sharing. If your contract is vague (e.g., “we can use data to improve services” without clear boundaries), it can undermine those protections and create compliance and governance risk you didn’t budget for. State privacy activity keeps expanding across the U.S., so it’s safer to treat occupant-facing data as regulated by default.

Bottom line: vendor AI training on building data isn’t just a data rights issue—it’s a compliance risk.

Contract red flags (what to watch for in MSAs and SOWs)

Look for these warning signs in vendor agreements:

• Vague “improve services” or “product development” language that grants reuse/training rights without scope limits, opt-out, or anonymization requirements.
• “Anonymized and aggregated data” carve-outs with no definition of what counts as anonymized or who decides.
• “Upon reasonable request” export terms with no SLA, format specification, or cost cap.
• Vendor owns “derived data,” “insights,” or “models” without defining what you paid for vs. what they created.
• Termination clauses silent on data retention, deletion timelines, or offboarding support—or worse, “data may be retained for backup and compliance purposes indefinitely.”

What to ask vendors (in procurement or renewal meetings)

Use these questions to surface data-rights gaps before you sign:

1. “If we terminate, how do we export all telemetry plus metadata (tags, asset IDs, hierarchies)? In what formats, timeframes, and at what cost?”
2. “Do you train AI models on our building data? If yes, what’s the scope, retention policy, anonymization process, and opt-out mechanism?”
3. “What do we keep if we leave: fault rules, tagging schemas, KPI configurations, normalization mappings?”
4. “Who are your subprocessors, and where is data stored geographically? Can we restrict cross-border transfers?”
5. “What’s your process for data deletion and proof of deletion after termination?”
6. “Who is the system of record for assets, spaces, users, and control sequences? Can we export the full registry with context?”
7. “Can we automate recurring data pulls via API, or is it manual and on-request?”
8. “How do you handle data breaches? What are our notification obligations vs. yours?”
9. “If we add a second analytics platform, can both access the same data feeds simultaneously?”
10. “What happens to historical data, work-order enrichment, and alarm narratives after we cancel?”

A 30/60/90-day action plan (no new software required)

Days 1–30: Inventory and assign ownership

• FM lead: List every system generating operational data (BAS, meters, lighting, access control, CMMS/IWMS, video/occupancy analytics). Tag mission-critical vs. nice-to-have.
• IT + FM: Map data flows. Where does data go? Who hosts it? Who has API or remote access?
• Legal/Privacy: Identify which datasets may include personal information under APPs (AU) or state privacy laws (US).

Days 31–60: Contract reality check and gap analysis

• FM + Procurement: Pull MSAs and SOWs for data-generating platforms. Review for: ownership, access/export rights, AI training permissions, retention/deletion, portability, subprocessors, offboarding.
• Legal: Flag contracts with vague “improve services” clauses, missing deletion terms, or cross-border data flows without APP 8 compliance (AU) or service-provider restrictions (US/CA).
• FM + IT: Draft a one-page data rights addendum (use the checklist below). Socialize with legal and cybersecurity.

Days 61–90: Prove portability (the “data fire drill”)

• FM + SI/vendor: Pick one critical system. Request a full export: 30–90 days of telemetry plus all metadata (tags, asset IDs, hierarchies, work-order linkage).
• IT/FM: Test import into another tool or hand to a consultant. Document what’s missing (context, schema, derived rules).
• FM: Assign a permanent owner for data governance, integration quality, and vendor change control (this ties to the “minimum viable operating model” concept—someone must own the handoffs).
• Legal + FM: Add data rights terms to your standard vendor addendum template for future procurements.

What good looks like: a one-page data charter

The goal is a short, enforceable schedule you attach to every MSA. Key elements:

• Datasets in scope: BAS trends/events/alarms, semantic tagging, asset registry, work-order enrichment, fault rules, occupancy analytics, video metadata.
• Ownership & use restrictions: Building owner retains ownership; vendor has limited license for service delivery only. No AI training, cross-customer aggregation, or product development without explicit opt-in with scope and retention terms.
• Access & portability: Real-time API with documented endpoints. Full export (telemetry + context) within 5 business days, CSV/JSON with schema, no additional cost.
• Retention & deletion: Data retained only as necessary for the contracted service or legal obligations. Upon termination, active/accessible customer data is deleted within 30 days and the vendor provides written confirmation; backup copies expire per a documented backup rotation schedule (unless legally required to retain).
• Derived data: Customizations paid for by customer (fault rules, tagging maps, KPIs) are customer property and export with full context.
• Subprocessors & geography: Vendor discloses all subprocessors and storage locations. Cross-border transfers require approval and APP 8 (AU) or state law (US) compliance.
• Breach notification: Vendor notifies customer within 24 hours. Vendor cooperates with NDB (AU) or state law (US) obligations.
• Offboarding: 60 days transition support post-termination, including full export, API access, and technical assistance.

Align this with NIST AI Risk Management Framework principles (transparency, accountability, risk management) and NIST SP 800-82 Rev. 3 guidance on OT security and access control when centralizing building data.

---

This article provides operational guidance for facility managers and building operators. It is not legal advice. Work with legal, IT, and privacy/security teams to draft enforceable contract language and ensure compliance with applicable privacy and cybersecurity obligations in your jurisdiction.

---

Works Cited

California Code of Regulations, Title 11, § 7051. “Contract Requirements for Service Providers and Contractors.” Operative March 29, 2023. https://www.law.cornell.edu/regulations/california/11-CCR-7051

California Department of Justice, Office of the Attorney General. “California Consumer Privacy Act (CCPA).” Updated March 13, 2024. https://oag.ca.gov/privacy/ccpa

Cyber and Infrastructure Security Centre (CISC). “CISC Factsheet – Systems of National Significance and Enhanced Cyber Security Obligations.” April 2025. https://www.cisc.gov.au/resources-subsite/Documents/cisc-factsheet-systems-of-national-significance-enhanced-cyber-security-obligations.pdf

International Energy Agency (IEA) Energy in Buildings and Communities (EBC) Programme. “Annex 81 – Data-Driven Smart Buildings: Final Report.” June 2025. https://annex81.iea-ebc.org/Data/publications/IEA%20EBC%20Annex%2081%20–%20Final%20Report.pdf

National Conference of State Legislatures (NCSL). “Brief: Consumer Privacy 2025 Legislation.” Updated July 28, 2025. https://www.ncsl.org/technology-and-communication/consumer-privacy-2025-legislation

National Institute of Standards and Technology (NIST). “Artificial Intelligence Risk Management Framework (AI RMF 1.0).” January 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

National Institute of Standards and Technology (NIST). “NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security.” September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final

Office of the Australian Information Commissioner (OAIC). “About the Notifiable Data Breaches scheme.” https://www.oaic.gov.au/privacy/notifiable-data-breaches/about-the-notifiable-data-breaches-scheme

Office of the Australian Information Commissioner (OAIC). “Chapter 6: APP 6 — Use or disclosure of personal information.” https://www.oaic.gov.au/privacy/australian-privacy-principles-guidelines/chapter-6-app-6-use-or-disclosure-of-personal-information

Office of the Australian Information Commissioner (OAIC). “Chapter 8: APP 8 — Cross-border disclosure of personal information.” https://www.oaic.gov.au/privacy/australian-privacy-principles-guidelines/chapter-8-app-8-cross-border-disclosure-of-personal-information

Smart Buildings Academy. “SBA 237: Building Automation As A Service?” February 8, 2021. https://podcast.smartbuildingsacademy.com/237

Smart Buildings Academy. “SBA 504: What Every Manager Should Know in 2025.” July 17, 2025. https://podcast.smartbuildingsacademy.com/504

Smart Buildings Magazine. “MSIs are for delivery, but operations never got one.” Published Feb 1, 2026. https://smartbuildingsmagazine.com/features/msis-are-for-delivery-but-operations-never-got-one

Smart Buildings Magazine. Marson, Matthew. “The minimum viable operating model: How FMs turn PropTech into performance.” Published Oct 1, 2025. https://smartbuildingsmagazine.com/features/the-minimum-viable-operating-model-how-fms-turn-proptech-into-performance

Smart Buildings Magazine. Marson, Matthew. “When AI leaves the screen, buildings become the stage.” Published Nov 1, 2025. https://smartbuildingsmagazine.com/features/when-ai-leaves-the-screen-buildings-become-the-stage