The EU Data Act's Device Data Access Rule and AI Training

A connected product generates data. Its manufacturer holds that data and would like to train on it; so would the user, and so would a competitor the user might share it with. The Data Act decides who can, and its answer is more asymmetric than the summaries suggest.

What the Data Act is and when it applies

Regulation (EU) 2023/2854 — the Data Act — was adopted on 13 December 2023, entered into force in January 2024, and became applicable on 12 September 2025. It is a Regulation, so it applies directly without national implementation, and it is not a data-protection instrument: Article 1(5) makes clear it is without prejudice to the GDPR, which continues to apply in full to any personal data within its scope.

Chapter II is the part relevant here. It concerns “connected products” — items that obtain, generate or collect data concerning their use or environment and can communicate it — and “related services”, the digital services without which the product could not perform some of its functions. That is a wide net: vehicles, industrial machinery, medical devices, agricultural equipment, building systems, consumer appliances. Certain products are carved out and there are transitional provisions for products placed on the market before applicability, so check the timing against your product rather than assuming.

The Article 3 and 4 access rights

Article 3(1) requires connected products and related services to be designed and manufactured so that product data and related service data, including the relevant metadata, are by default easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, directly accessible to the user. Access by design, in other words, is an obligation on the product rather than an obligation to answer requests. Article 3(2) and (3) add pre-contractual information duties about what data the product generates, in what volume, how often, and how the user can access it.

Article 4 handles the case where the data is not directly accessible. The data holder must make readily available data, together with the relevant metadata, available to the user without undue delay, of the same quality as is available to the data holder, easily, securely, free of charge and in a comprehensive, structured, commonly used and machine-readable format, and where relevant and technically feasible, continuously and in real time. The user may then, under Article 5, require the data holder to make it available to a third party of the user’s choosing on the same terms.

“Readily available data” is the concept that bounds all of this: it means data the data holder lawfully obtains or can obtain from the product without disproportionate effort beyond a simple operation. Inferred or derived data — the output of the manufacturer’s own analytics or model — is outside the access right. That boundary is doing a lot of work commercially, because it means the raw telemetry is shareable and the manufacturer’s derived insight is not.

What the data holder may do with the data

Here is the asymmetry the summaries miss. The Data Act does not stop the manufacturer training on the data its own products generate. What it does is condition that use. Article 4(13) provides that the data holder may use readily available data that is non-personal only on the basis of a contract with the user. So the manufacturer’s own use of non-personal product data is contractualised: it needs a term with the user, and the term is subject to the unfair-terms control in Article 13 where it is unilaterally imposed on another business.

Article 4(14) then adds a substantive limit: the data holder shall not use such data to derive insights about the economic situation, assets and production methods of the user, or the user’s use of the product, in a way that could undermine the user’s commercial position. For an industrial customer this is the provision that matters most. A machine-tool manufacturer building a model over customer telemetry that reveals utilisation rates, throughput or production scheduling is squarely in its territory, and the limit applies to the insight rather than to the technique that produced it.

There is no equivalent prohibition on the data holder building a competing product, for the obvious reason that the data holder is usually the incumbent rather than the entrant. The competing-product restriction lives in the next section and applies to somebody else.

The competing-product restriction on recipients

When a user directs data to a third party under Article 5, Article 6 governs what that third party may do. The recipient must process the data only for the purposes and under the conditions agreed with the user, and Article 6(2) sets out prohibitions. Two matter here.

Article 6(2)(e) prohibits the third party from using the data it receives to develop a product that competes with the connected product from which the data originates, and from sharing it with another third party for that purpose. Article 6(2)(b) prohibits using the data to derive insights about the economic situation, assets and production methods of the data holder — the mirror image of the Article 4(14) limit, protecting the manufacturer this time.

Whether training a machine-learning model on received device data constitutes “developing a product that competes with the connected product” is genuinely unresolved, and it is the question a lawyer asked about this Regulation is most likely to be asked. Consider three cases. A predictive-maintenance service built on data from a competitor’s machines, sold to the owners of those machines: not obviously a competing product, since a service is not the connected product, though it may compete with a related service. A model trained on device data and then embedded in the recipient’s own rival hardware: much closer to the prohibition. A general-purpose model trained on device data among a thousand other sources and later used in a product that happens to compete: the case where the causal link is weakest and where nobody currently knows the answer.

What would settle it is guidance from the Commission, national enforcement practice under the authorities designated in Chapter IX, or litigation. Until then, the honest advice is that the restriction is drafted around products rather than around models, that a model is a means rather than a product, and that a recipient relying on that distinction is taking an untested position rather than a safe one. Contracting explicitly for the permitted purposes under Article 6(1) is worth more than an argument about the boundary.

Trade secrets cut across all of it. Articles 4(6) to 4(8) and the corresponding provisions for third parties allow disclosure to be conditioned on measures to preserve confidentiality, and permit refusal in defined circumstances where the data holder can demonstrate it is highly likely to suffer serious economic damage. Those provisions are a real limit on access in practice and are dealt with in the Data Act and trade secrets.

Where the GDPR still governs

The Data Act creates access rights; it does not create a lawful basis. Where product data is personal data — and telemetry tied to a vehicle, a wearable or a household appliance usually is — every operation described above still needs an Article 6 basis, and the Data Act says so expressly. Article 4(12) restricts the data holder’s use of personal data where the user is not the data subject, requiring a valid legal basis under Article 6(1) of the GDPR and compliance with Article 9 where relevant.

Three practical consequences. Where the user of a connected product is not the data subject — a fleet operator whose drivers generate the data, a landlord whose tenants use the appliance — exercising the Article 4 access right does not make the onward use lawful under the GDPR, and the user becomes a controller with its own obligations. Where the user directs data to a third party under Article 5, the third party needs its own basis; the user’s instruction is not one. And where the resulting corpus feeds model training, the purpose-limitation analysis in purpose limitation and training reuse applies unchanged, as does the data-minimisation duty in data minimisation for AI training.

The design conclusion is unglamorous but load-bearing: separate the personal from the non-personal at the point of collection, because the Data Act’s cleanest permissions attach to non-personal data and the GDPR’s heaviest obligations attach to the rest. A telemetry pipeline that cannot tell you which of its fields are which will end up treated as though all of them are personal, which is the expensive outcome and the one that arrives by default.