Data Act and Physical AI: Who owns the data from connected robots?
Robot data are the main raw material in physical AI, modern robotics and data-driven business models. The Data Act is the first coherent set of rules created by the EU for accessing and using data from connected products. This raises a crucial question for robot manufacturers, operators and integrators as to who is allowed to access robot data, how rights to use data can be contractually safeguarded and which requirements will apply to data access, data licences and "access by design" in the future.
In the first article in our series, we showed that a single connected robot can trigger obligations from multiple areas of law at once. Our focus in this article is on the first pillar – data law – and the questions of who owns the data that a machine generates while in operation and who can use them.
Data as a raw material in robotics and physical AI
The AI start-up Shift (backed by Aachen-based MicroAGI GmbH) has made a striking offer in New York: It cleans apartments for free. The cleaning staff wear recording devices while they are at work and training data for future domestic robots are generated from the recordings. They are explicitly looking for particularly challenging environments; extremely dirty or untidy apartments are particularly valuable, since difficult settings provide the most useful data. (Source: Computerwoche, 2 June 2026.) The relevant process here is not the cleaning; it is the gathering of data: One service is provided for free to acquire something scarcer and more valuable, namely real, physical data.
The same basic pattern can be seen in many other areas of application: Operators of large intralogistics fleets use operational data to optimise route planning and maintenance, connected and automated vehicles improve their systems based on driving and environmental data, agricultural and construction machines generate findings to achieve more efficient work processes and medical devices produce valuable data for medical robotics during their use.
In all these examples, the machine continuously produces data and the economic value is not just in the physical product, but rather in the continuing flow of data and their analysis. Because high-quality data from the physical world are only available in limited quantities and require considerable work to gather, they are increasingly being seen as a strategic resource.
Why physical AI needs data – and traditional robotics do not
To understand why data is becoming a raw material today, it is worth looking at the technical shift that is taking place.
Before: programmed, not trained. For decades, traditional industrial robotics were deterministic. A machine would carry out a pre-programmed sequence in a siloed space – always welding or grabbing the same spot. This sequence was programmed using control logic, with every position being defined in advance. The environment would be adapted to suit the robot (apparatus, exact position of parts, floor markings) rather than the other way around. If a workpiece or the environment deviated from this, the system would stop. The machine's "knowledge" was to be found in the code and the structured work process contained in it, which people had written. If data were used at all, they were used for monitoring and quality assurance, not to "learn" the skill.
Now: learned from data. Physical AI replaces this strict rule with a learned model. "Foundation models", "imitation learning" and "reinforcement learning" allow a system to generalise behaviour from examples instead of having to be programmed in full. For humanoid robots, which increasingly have to venture out of their "cage", this is a technical necessity in fact: Open, changing environments like an apartment, a warehouse or a shared workplace where people also work ("human-robot collaboration"; "HRC") cannot be described in exhaustive detail before deployment. The lighting, objects, arrangements and human behaviour are too varied for a fixed script. To get around this variance, deployers must explain the task and the intended work result to the robot rather than just the individual work steps.
Why the needed data are scarce and expensive. The type of data is crucial: What is needed is physical sensory-motor data – what a robot sees and "feels" and how it responds to those stimuli. Such data cannot be scraped from the internet in the same way that large language models gather text and images; they must be generated in the real world – in training centres, using motion-capture suits or by filming cleaners. This shifts the entire process of creating value: The long-term asset that keeps bearing fruit is not the machine any more; it is the data and the models trained using them. The machine is becoming a vector (and increasingly an interchangeable one) for an ability powered by data.
The Data Act: New rules for data and data access
The Data Act (Regulation (EU) 2023/2854) establishes horizontal rules for fair access to and use of data. Unlike the GDPR, it covers both personal and non-personal data (Article 1 (2)). Its goal is to improve the value of industry data and IoT data, establish fairness in the data economy and minimise "vendor lock-in".
The Data Act therefore also answers the years-long discussion about whether data should be subject to "data ownership" (similarly to section 903 German Civil Code (BGB)) or another absolute right to data (within the meaning of sections 823 (1), 1004 German Civil Code (BGB)).
Data Act in robotics: Correctly classifying manufacturers, users and data holders
A robot (cobot, autonomous mobile robot or "AMR", humanoid, domestic robot, drone/UAS, etc.) is a "connected product" within the meaning of Article 2: an item that can generate, record and transmit data concerning its use or environment.
Fleet management and the cloud backend (the platform used to monitor, update and control robots) are "related services": services without which the product could not perform certain functions.
The "data holder" is usually the manufacturer of the robot or the operator of the platform.
The "user" is whoever owns, rents or leases the robot – which in practice is often the fleet operator.
Range: The Data Act enjoys extra-territoriality – for example, manufacturers of connected products placed on the market in the EU are covered irrespective of the place of establishment of the manufacturer (Article 1).
Data Act: Deadlines applicable to manufacturers of connected robots
The Data Act entered into force on 11 January 2024 and has applied since 12 September 2025. The crucial step for product design is coming late this summer: From 12 September 2026, the requirement for "access by design" (Article 3 (1)) applies to connected products that are placed on the market after this date (Article 50). What this means for robot manufacturers specifically is that models that are placed on the market from then on must already feature data access in their architecture – either in the robot controller, in the "edge" node (the network node that collects data in the system and forwards them to the cloud or backend for example) or via the cloud/backend itself (e.g. in the form of API access).
Data Act: Data access and data use with connected robots (Chapter II)
"Access by design" and transparency (Article 3). Connected products must be designed in such a way that by default the data generated, including relevant metadata, are accessible easily, securely, for free, in a structured and machine-readable format and, where technically feasible, directly. For robotics, this means that it must be possible to access robotics telemetry and sensor data via a defined interface; even before the robot is purchased, rented or leased, the user must be informed what data are recorded in what scope and format and how they can be accessed (Article 3 (2)–(3)).
Provision and use (Article 4). If data are not directly accessible, the data holder must make the "readily available" data accessible to the user without undue delay, easily, securely, free of charge and – if technically feasible – continuously and in real time. Trade secrets are protected at least in theory: Their disclosure may be tied to agreed safeguards and may be reserved or suspended in narrowly defined exceptional cases (Article 4 (6)–(8)). However, the barrier to these protections is high: It is not enough to just declare everything a trade secret.
Perhaps the most consequential mechanism – which may even represent a paradigm shift – is in Article 4 (13): A data holder may only use non-personal "readily available" data on the basis of a contract with the user. This turns the previous default arrangement on its head. Applied to robotics, it means that a manufacturer which uses usage data from robot fleets at customer premises for its own purposes, or which feeds these usage data into a shared fleet model for example, needs an explicit agreement – called a "data licence" – with each customer, even if the data are only used for purposes of maintenance, functional improvement or model training. The right to use non-personal data commercially is therefore granted first and foremost to the user. In addition, Article 4 (13) f. prohibits inferring insights about the user's economic situation from the data that could damage its market position as well as sharing the data with third parties without an agreement.
Sharing data with third parties (Articles 5 and 6). At the user's request, the data holder must also make the readily available data, as well as the metadata required to interpret and use these data, accessible to a third party. This is a key issue for the Data Act: the independent aftermarket and avoiding "vendor lock-in". A fleet operator could, for example, demand that robot data be shared with an independent maintenance or repair service. However, the third-party recipient is subject to its own obligations (Article 6): It may only process the data for the agreed purposes, must not use them to develop a competing robot and must not share them unless this is agreed. Companies designated as "gatekeepers" within the meaning of the Digital Markets Act (Article 5 (3)) are explicitly prohibited from being third-party recipients.
Fair data clauses and clause review (Chapters III and IV)
If a data holder is required to make data accessible, the terms must be fair, reasonable and non-discriminatory; any remuneration must be reasonable and is capped for small and medium-sized enterprises (Articles 8–9). Certified dispute settlement bodies are on hand in the event of disputes (Article 10) – in Germany these are certified by the German Federal Network Agency.
The clause review is of particular practical relevance: A contractual clause concerning data access, use or liability is not binding if it excludes or alters the user's rights from Chapter II to the detriment of the user (Article 7 (2)) or if it is unilaterally imposed and unfair within the meaning of Article 13. The Data Act distinguishes between clauses that are void per se and those that are assumed to be unfair. In essence this is a review of general terms and conditions for the data economy – and it directly affects robot delivery, robot-as-a-service and "marketplace" contracts. The Commission has published helpful non-binding standard contractual clauses; they are deliberately user-friendly and should be adapted to the logic of the contract and business.
Switching between clouds, exporting data and international data use under the Data Act
An important point for robot-as-a-service backends and fleet backends is that providers of data processing services (clouds/edge nodes) must minimise barriers to switching, enable functional equivalence and guarantee interoperability; switching charges will be eliminated in stages (Articles 23–31, particularly Article 29). This is to regulate "vendor lock-in" – the operator should be able to switch data processing services without losing their data. The question of when the operator of a fleet backend is considered a data processing service within the meaning of the Data Act is nevertheless not easy to answer and requires that it be precisely categorised within this term (Article 2 (8)) in the individual case.
Additionally, non-personal data are protected against unlawful access from third countries (Article 32) – which is particularly relevant for international providers. Furthermore, the sui generis database right (Directive 96/9/EC) is not applicable to databases with product data (Article 43) so as not to thwart access.
Data Act and GDPR: Data protection for robot data
The Data Act applies without prejudice to the GDPR; in the event of conflicts, data protection prevails (Article 1 (5)). Where personal data are concerned – which is virtually always the case with domestic robots with cameras or with human-robot collaboration at the workplace – and the user themselves is not the data subject, data may only be shared on a valid legal basis (Article 6 GDPR). In robotics, mixed data sets are the norm. We will explore this interaction in more detail in the next article in the series.
Criteria and grey areas in the Data Act
The actual work of providing advice begins in mapping the terms to reality.
Who is a "user"? Owners, operators, robot-as-a-service providers, lessees and individual employees may all be different parties; the "user" in a factory is the place of business, not the individual person; a fleet of robots may have multiple users. If you do not allocate the role correctly, you might violate rights under the Data Act.
Data holder = platform operator. The most difficult conflict of interests comes when the manufacturer also operates the network that benefits from the aggregated data flow. This is where Article 4 (13) f. and the clause review in Article 13 are most relevant.
The training data question. Can a manufacturer enter usage data from customer premises into a shared fleet model that the customer's competitors also benefit from? Under the Data Act, this requires a contractual basis (Article 4 (13)), it must not harm the customer ((13) f.) and third-party recipients of the data must not build any competing robots with them (Article 6). The question that remains open is whether the weights in the trained model are themselves "data" within the meaning of the act. This is very unlikely – meaning that part of the created value is not subject to the request for access once a model is made from the raw data. This has not been settled in law yet, but it is a key issue for data-driven business models in robotics.
"Readily available" data versus derived data. A threshold determines how much of the asset actually reaches the user. Raw and pre-processed sensor data from the robot – such as its position, acceleration, speed, force, moment of force, temperature or pressure – are covered by the request. Derived data and "content" that are enhanced at great effort, such as audiovisual material – for example the fully processed 3D environment/SLAM data set ("simultaneous localisation and mapping") – are excluded more often than not according to the understanding of the Commission; data discarded immediately on the device are entirely outside the scope of the regulation (no obligation for data storage).
Trade secrets versus access. The Data Act allows data to be reserved under the precise terms of Article 4 (6)–(8) – a balance has to be struck in a contract between the guarantee of data protection and the statutory right of access.
No robotics-specific guidelines. The Commission has published sector-specific guidance for vehicle data – but this is explicitly not transferrable to other sectors. There is no corresponding guidance for robotics; answers to classifying questions (what counts as "readily available", how deep does the access at the controller go, etc.) are therefore less certain and should receive early clarification from lawyers.
Recommendations for robotics and physical AI
Create a data catalogue for each robot type. Record what real data the cobot, autonomous mobile robot or humanoid generates – telemetry, camera/LiDAR/moment-of-force sensor data, trajectory and task logs, maps of surroundings, maintenance data – and categorise every field according to two criteria: whether they are personal or non-personal and whether they are "readily available" or derived. This is the basis both for Articles 3 and 4 and for delineation under data protection law.
Technically situate "access by design". Define data export at the robot controller or at the "edge" node or using the fleet management API (structured, machine-readable, interoperable) and keep in mind the fleet/OTA backend as a "related service" – for all models placed on the market from 12 September 2026.
Manufacturers – secure the contracts and platform. Include rights to the use of one's own data and training rights as a "data licence" in supply and robot-as-a-service contracts (Article 4 (13)); draft a trade secret protection concept in accordance with Article 4 (6)–(8); anchor the "competing product" limitation (Article 6) and non-discrimination against independent service operations (Article 8 (3)) in the partner/"marketplace" terms; review all data clauses in existing standard contracts against Article 7 (2) and Article 13.
Integrators – clarify role and supply chain. A "substantial modification" can turn integrators into manufacturers with all the obligations that follow; data clauses must be passed through the supply chain "back to back".
Operators – Make active use of data rights. Use the access and portability of your own robot data to your benefit. The same robot data can be used simultaneously to preserve evidence for the new product liability and to manage the Machinery Regulation and CRA – this means that setting up data management early and correctly addresses multiple legal pillars at once (see Legal Update #1).
Outlook: The Data Act is permanently changing data-driven robotics
The Data Act turns the old debate "Who owns the data?" into a concrete design task – both in the project architecture and in the contract. If the actual value is in the flow of data, data law decides the business model. CMS advises manufacturers, integrators and operators across disciplines – from data architecture and IT contract protection to data protection and even international scaling.
In the next part in this series, we turn our attention to data protection: seeing and hearing robots and the question of how camera, audio and sensor data can be processed in compliance with the GDPR.
Building the legal stack for physical AI
Editor's note: This information reflects the situation as of the editorial deadline (30 June 2026); individual points are still being detailed (e.g. Commission guidelines and standard contract clauses). Consult the primary sources (EUR-Lex) before actually implementing the contents..
