The EU Data Act requires connected devices and cloud services to make user-generated data accessible and transferable by design, which for many companies means the compliance work happens in the back-end architecture, not the policy document. ZwillGen attorneys Zach Judge-Raza and Jamie Elbert lay out what the act’s interoperability requirements actually demand of product teams and why the absence of centralized EU enforcement could set the table for volatility.
The EU Data Act marks a structural shift in the EU data landscape. It aims to facilitate broader access to and sharing of data generated by connected products and related services, introducing mandatory data-sharing frameworks that intersect with the General Data Protection Regulation (GDPR). For technology companies, particularly cloud services providers and manufacturers of connected devices, compliance requires more than just the development of compliant policies, instead extending to product design, back-end architecture and operational workflow changes.
The act imposes technical design obligations on manufacturers and data holders, including cloud services and software as a service (SaaS) providers. Products and services must be designed and configured such that the data generated by their use is accessible to end users and transferable to third parties, which can include competitors. The interoperability and end-user access rights included in Articles 3 and 4 of the act create new engineering requirements that require close coordination among legal, compliance, security and product teams.
What are the operational implications of these obligations, the tension between the act and the GDPR and the resulting enforcement risks in a fragmented, multijurisdictional landscape?
Technical design obligations and interoperability requirements
The act may obligate product-level redesigns for manufacturers of Internet of Things (IoT)-connected devices and cloud services providers. Article 3(1) mandates that connected products and related services be provided in such a manner that data generated through their use is easily and securely accessible by default; free of charge; and available in a comprehensive, structured, commonly used and machine-readable format and, where technically feasible, directly accessible to the user.
For many SaaS providers and IoT manufacturers, existing data architecture is built around proprietary systems optimized for internal functionality and performance rather than interoperability or direct end-user access. Data generation, storage environments and processing logic are usually designed to support the product itself and may not be easily configurable to provide user access or enable transfer in the format and manner required by the act. As a result, compliance may require re-engineering back-end systems so that users can access and port the data they generate.
Where direct end-user data access is not technically feasible, Article 4(1) requires manufacturers and cloud services providers to make the data, including the metadata needed to interpret and use the data, readily available to the user without undue delay in the same quality as held internally and in a comprehensive, structured, commonly used and machine-readable format. Where feasible, access must be continuous and in real time. End users must also be able to request their data through simple electronic means.
To meet these obligations, companies may need to develop new export functionality, application programming interface (API) capabilities and documentation standards, as well as internal controls to ensure accuracy, completeness and security of the data provided or transferred.
The act does not eliminate trade secret protection, but the existence of trade secrets alone does not justify refusing data access. Companies will therefore need to identify any trade secrets at issue and share data while implementing appropriate technical and contractual safeguards to preserve their secrecy. Refusal is permitted only in exceptional cases where disclosure would likely lead to serious economic harm despite such safeguards.
The US Is Not Alone in Regulating Children’s Data Privacy. Here’s a Primer on the Global State of Play.
Emerging policies extend beyond data privacy into product governance and algorithmic accountability
Read moreDetailsTensions and intersections between the act and GDPR
While the act facilitates the sharing and transfer of data generated by connected products and services, the GDPR restricts and regulates the processing and transfer of personal data. The two intersect but do not fully align where machine-generated data includes personal data as defined in the GDPR.
The tension arises most acutely in relation to scope and proportionality. The act requires disclosure of readily available data generated by the use of the connected product, while the GDPR limits the processing of personal data to what is necessary and proportionate for a specified purpose, subject to data minimization and purpose limitation principles.
Companies must therefore balance the risk of over- or under-disclosure. Over-disclosure of personal data in the course of complying with the act could trigger enforcement under GDPR; under-disclosure could expose companies to enforcement under the data act.
Although this tension is confined to personal data, in practice, segregating personal from nonpersonal data within telemetry, usage logs or behavioral analytics may not be straightforward. Datasets are often interwoven, and extracting nonpersonal elements may require complex filtering logic and additional engineering effort, potentially disrupting existing product infrastructure.
Compounding this complexity is the absence of a “one stop shop” mechanism under the act. Unlike GDPR, which centralizes cross-border enforcement through a lead supervisory authority, the data act leaves enforcement to national authorities in each member state. As a result, companies operating across the EU may face parallel investigations or conflicting interpretations of compliance and technical implementation requirements across jurisdictions.
Enforcement exposure, litigation risk and practical steps
As noted above, the act leaves enforcement mechanisms to the discretion of each member state. For example, Malta’s implementing legislation provides for administrative penalties of up to 5% of turnover in the preceding calendar year for significant infringements, potential liability for company administrators, a two-year limitation period for initiating proceedings and an appeals route before the Malta Digital Innovation Authority. By contrast, Germany’s draft implementing legislation sets out a tiered system of fines, including up to 5 million euros or 2% of global turnover for serious infringements, with lower thresholds and warnings for less severe cases.
In the absence of a centralized coordination mechanism, companies may face parallel investigations from multiple competent authorities. A single incident, such as delayed data transfer to a designated third party, could attract materially different consequences depending on where enforcement is initiated. For example, conduct deemed a significant infringement in Malta could be treated as mid-level in Germany, exposing a company to inconsistent outcomes or overlapping penalties as the member states may independently impose administrative fines.
Civil litigation risk adds an additional layer of exposure. End users may seek injunctive relief to compel data production or transfer under the act and may claim damages for losses arising from noncompliance. Competitors may also strategically leverage the regime by encouraging customers to exercise their access and transfer rights and positioning themselves as designated data recipients. This could allow competitors to test the robustness and timeliness of a company’s compliance infrastructure.
Takeaways for compliance professionals
Compliance with the data act will not be a one-time product change. It will require ongoing oversight, encompassing version control, product testing and documentation updates to ensure that new and existing products remain consistent with the act’s requirements.
Companies should treat readiness as an enterprise-wide initiative rather than a discrete legal or compliance issue. Practical steps include:
- Assessing current data collection, generation, storage and usage practices to ensure that data is maintained in a way that can be easily transferred or produced. Based on this assessment, determine whether product-level or back-end changes are needed to achieve the functionality required by the data act.
- Develop documented procedures for managing access and transfer requests, including timelines, verification steps and escalation protocols.
- Draft and review compliance policies in coordination with technical, legal and compliance teams to ensure they accurately reflect product operations and technical constraints.
Zach Judge-Raza
Jamie Elbert
