Introduction
PropTech deployments combine suppliers, platforms, sensors and information from buildings and users. A single 'data ownership' clause is unlikely to address all of the rights and obligations involved.
Map the components and permissions
Identify code, hardware, models, datasets, interfaces and branding. Separate supplier background technology from bespoke work. Ask which parties may use outputs and whether licences cover the planned integrations and deployment locations.
A smart-building deployment should be mapped as a system of components and relationships. Identify the device manufacturer, software provider, integrator, building operator and any analytics or hosting supplier. Record what each supplies and which permissions are needed for the intended use. A licence for one platform may not cover an external integration or a different building. Separate pre-existing supplier technology from work commissioned specifically for the project. This map gives the procurement team a clearer basis for questions about ownership, support and access than a general promise that the client owns the entire solution.
Treat data and AI separately
Specify collection, access, permitted use, retention, exports and security responsibilities. IP terms do not override privacy obligations. Review AI-tool terms and human contributions rather than assuming every generated output is exclusively owned or automatically patentable.
Data requires a separate and more detailed schedule. Identify the categories collected, the people or organisations concerned and the purposes for which each party may use the information. Occupancy data, equipment readings and tenant contact records should not be treated as one undifferentiated asset. Agree access controls, retention, export and onward-sharing arrangements, while assessing applicable privacy and confidentiality duties. The parties should also address operational access when a supplier relationship ends. Describing data as owned by the developer does not by itself settle lawful processing, third-party permissions or the rights of affected individuals.
Map responsibility across the connected system
Where AI features are proposed, review the actual service terms and workflow. Ask whether prompts, uploaded drawings or building data may be retained, reused or passed to another provider. Establish what human review is required before an output is used in a design, valuation or customer communication. Keep a record of the source material and relevant permissions. Avoid assuming that a supplier's marketing description guarantees exclusive rights in generated material. Technical performance, safety, privacy and IP questions require their own assessments; a clause addressing one of them should not be presented as resolving all the others.
Plan for a change of supplier or integration partner before deployment. Identify export formats, documentation, interfaces and licences needed to keep the building operating. Consider how replacement equipment affects existing permissions and whether support depends on a subscription that can be suspended. Agree responsibilities for third-party claims and the process for replacing a disputed component without losing essential access. For a system deployed across several countries, assess rights and legal requirements in the relevant markets. A coordinated review can help the project retain practical control without promising ownership of technology that remains with the supplier.
Operational teams should know the contractual limits of a pilot. A supplier may permit a trial in one building using a limited dataset while the business later assumes it can scale the same arrangement across a portfolio. Record the pilot scope, success criteria and the approvals needed for wider deployment. Review permissions again when new buildings, users or data sources are added. This gives the organisation an opportunity to address licence, integration and information-use questions before a successful trial becomes an operational dependency governed by terms that were never intended for full-scale use.
Practical checklist
- Supplier and component inventory
- Code, model and integration permissions
- Data processing and export terms
- AI use and confidential-input controls
Related reading
- Technology & Software Licensing in Construction: Protecting ERP, BIM, and Smart Site Tools in Bahrain
- Patent Protection for Innovative Construction Methods and Technologies in Bahrain
- IP Strategy for Construction and Engineering Firms: Turning Innovation Into Legal Assets in Bahrain
Conclusion
Use an asset and responsibility map before procurement, integration and launch.
For a review of the rights, permissions or agreements relevant to your matter, explore our intellectual property expertise and technology and cybersecurity legal support.
Contact Manal Dhahi Legal Group to discuss your circumstances. The appropriate next step depends on the documents and facts of the matter.
Frequently asked questions
Usually the contract defines ownership and licence rights; review the actual agreement rather than assuming a transfer.
No. Data protection, confidentiality and lawful processing need separate consideration.
Review the data categories, permissions, confidentiality and privacy duties, provider retention and reuse terms, and required human oversight. Use only information the organisation is authorised to share.