For US businesses operating in Europe or serving European customers, the EU Data Act and the General Data Protection Regulation are two of the most significant legal frameworks they will encounter. Both are EU laws governing data. Both impose compliance obligations. But they are not the same law, they do not cover the same data, and they cannot be satisfied by a single unified compliance effort. Understanding how they relate — where they overlap, where they diverge, and how to manage both simultaneously — is one of the most practically important questions facing US businesses with EU exposure.

This page explains the fundamental legal distinction between the two frameworks, how they interact in real-world datasets that contain both personal and non-personal data, why GDPR compliance does not automatically satisfy Data Act obligations, and what a practical compliance architecture that addresses both looks like.

The Fundamental Distinction: Personal vs. Non-Personal Data

The GDPR governs the processing of personal data — any information relating to an identified or identifiable natural person. This definition is deliberately broad. A name, an email address, a device identifier, a location trace, a behavioral profile, a medical record, a financial transaction history — all of these are personal data if they can be linked, directly or indirectly, to a living person. GDPR applies to organizations that collect, store, use, share, or otherwise process this data, regardless of where in the world those organizations are located, as long as the data subjects are in the EU.

The EU Data Act has a different primary focus. It governs data access rights, data-sharing obligations, and data portability in connection with connected products (IoT devices, smart machines, and related services), cloud services, and data intermediaries. The Data Act primarily targets non-personal data — information that does not relate to identified or identifiable individuals. This includes machine-generated operational data, industrial sensor readings, aggregate usage statistics, performance telemetry, and similar categories of data that have enormous commercial value but fall outside GDPR’s scope because they do not describe individuals.

This is the headline distinction: GDPR governs personal data processing; the Data Act primarily governs non-personal data and data access rights. In a world where those two categories were cleanly separable, compliance would be relatively straightforward. But in the real world of data collection and use, they are rarely cleanly separable.

The Mixed Dataset Problem

Most real-world datasets are mixed. A smart thermostat collects temperature readings (non-personal operational data) alongside usage patterns, schedule preferences, and user account identifiers (personal data). A connected manufacturing machine generates production performance data (non-personal) that is also associated with operator IDs, shift records, and maintenance logs that include worker information (personal). A fleet management system produces vehicle telemetry (potentially non-personal) that is inseparable from driver behavior data and location history (personal).

When a dataset contains both personal and non-personal components, EU law applies a “mixed dataset” framework. The GDPR applies to the personal data components of the dataset — processing, sharing, and storing information about identifiable individuals requires a valid GDPR legal basis, must respect data subject rights, and must comply with the full range of GDPR obligations. The Data Act applies to the non-personal data components — the access rights, portability obligations, and data-sharing rules of the Act govern how that data can be accessed, shared, and used.

The practical consequence is that a US company handling a mixed dataset cannot treat it as governed by only one framework. The GDPR obligations attach to the personal data components and cannot be overridden or superseded by the Data Act. The Data Act obligations attach to the non-personal data components and are not satisfied simply by being GDPR-compliant. Both sets of rules must be satisfied simultaneously, often in respect of the same underlying collection, storage, and processing infrastructure.

Why GDPR Legal Bases Do Not Automatically Satisfy Data Act Obligations

A common misconception among companies with established GDPR compliance programs is that the Data Act simply adds some additional requirements on top of GDPR, and that GDPR-compliant processes will be largely sufficient. This is incorrect in two important ways.

First, the Data Act creates obligations that have no counterpart in GDPR at all. GDPR does not require a manufacturer to provide users with access to the non-personal data generated by their products. GDPR does not regulate cloud switching fees or mandate that cloud providers enable portability of non-personal datasets. GDPR does not govern B2B data-sharing contracts or restrict unfair contractual terms in data licensing agreements. GDPR does not impose obligations on data intermediaries operating data marketplaces. These obligations arise solely from the Data Act and require separate compliance measures.

Second, the legal mechanisms that authorize data processing under GDPR are not the same as the legal mechanisms that authorize data access and sharing under the Data Act. Under GDPR, processing personal data requires a valid legal basis — consent, legitimate interest, contract performance, legal obligation, vital interests, or public task. Under the Data Act, a user’s right to access data generated by their product arises directly from the Act itself, not from any separately negotiated agreement or consent mechanism. A company cannot tell a user that they have no right to access their product-generated data because the company has not obtained consent for that use under GDPR — the Data Act creates the right independently.

Conversely, a GDPR legal basis does not expand rights under the Data Act. If a company processes personal data under a legitimate interest basis, that does not give it broader rights to restrict data access or charge higher switching fees than the Data Act permits. The two frameworks are legally independent, and satisfying one does not satisfy the other.

Shared Principles: Data Minimization and Purpose Limitation

While the two frameworks are legally distinct, they share some important underlying principles. Data minimization — the idea that only data necessary for the specified purpose should be collected and processed — appears in GDPR Article 5 as a core personal data processing principle. A functionally similar principle runs through the Data Act: data-sharing arrangements should be scoped to what is actually needed, smart contracts must not process data beyond the agreed scope, and access rights do not extend to data that the requesting party does not legitimately need.

Purpose limitation — the principle that data collected for one purpose should not be repurposed for an incompatible use — is explicit in GDPR and implicit in the Data Act’s framework. Data accessed under a Data Act right of access is intended for the user’s or third party’s specified use; repurposing that data for unrelated commercial exploitation would conflict with the spirit of the Act and potentially with GDPR if personal data is involved.

These shared principles create a natural alignment in how organizations should approach data governance. Establishing clear data use policies, documenting the purposes for which data is collected and processed, and building technical controls that enforce those purposes serves both frameworks simultaneously. Organizations with mature GDPR data governance programs are better positioned to extend those programs to cover Data Act obligations than organizations starting from scratch.

Data Subject Rights Under GDPR vs. Data Access Rights Under the Data Act

One of the most practically important intersections between the two frameworks involves access and portability rights. Under GDPR, data subjects have the right to access personal data that an organization holds about them (Article 15), the right to receive that data in a portable format (Article 20), and the right to have it deleted in certain circumstances (Article 17, the right to erasure). These are rights in personal data about the individual — the individual’s name, their transaction history, their behavioral profile.

The Data Act creates a different and broader access right. Under the Act, a user of a connected product has the right to access data generated by their use of that product — including non-personal operational data, performance data, and usage data — regardless of whether that data is “about” them in a personal data sense. A factory operator may have a right under the Data Act to access production data generated by their machines even if that data does not include any personal information. This right exists independently of GDPR.

These two rights can coexist in respect of the same device or service. A smart refrigerator generates personal data (usage patterns that can identify household members and routines) and non-personal data (compressor performance, energy consumption patterns). The household member has GDPR rights in the personal data components and Data Act access rights in both the personal and non-personal components. The manufacturer must be prepared to satisfy both sets of rights through potentially different processes and interfaces.

The right to erasure under GDPR creates additional complexity. A user who exercises GDPR erasure rights in respect of personal data associated with a product may effectively be limiting the dataset available for Data Act access requests. If the personal data that provides context for non-personal operational data is deleted, the non-personal data may become less useful or meaningful. Organizations should design their data lifecycle management so that GDPR erasure obligations can be satisfied without inadvertently destroying data that other parties have valid Data Act access rights to — a design challenge that requires careful architectural thinking.

De-Identification and Anonymization as a Compliance Tool

One of the most practically important tools for managing the GDPR/Data Act overlap is de-identification and anonymization — the process of removing or modifying personal identifiers in a dataset so that it no longer relates to identified or identifiable individuals. Truly anonymized data falls outside GDPR’s scope entirely: there is no personal data, so no GDPR obligations apply. This can simplify compliance significantly for organizations dealing with large datasets that contain personal data in some components.

However, anonymization under EU law is a high bar. Under the GDPR framework (and the guidance of the Article 29 Working Party, now the European Data Protection Board), data is only truly anonymized if re-identification is not reasonably possible — taking into account all the means reasonably likely to be used, given the state of technology at the time. Pseudonymization — replacing identifiers with codes that can be reversed using a separate key — is not anonymization. The original data is still personal data, and GDPR still applies to both the pseudonymized dataset and the key.

This high standard for anonymization means that many datasets organizations believe are de-identified are actually still subject to GDPR. Aggregate statistics, truncated location data, generalized behavioral profiles, and similar approaches may reduce re-identification risk but may not eliminate it to the degree required by EU law, particularly as the available means for data linkage and re-identification continue to improve.

For organizations trying to separate GDPR scope from Data Act scope, genuine anonymization is the cleanest technical solution. If a dataset can be transformed so that no reasonable means of re-identification is available, the anonymized version falls outside GDPR and can be governed exclusively by the Data Act framework. Achieving genuine anonymization typically requires formal privacy engineering techniques: k-anonymity, differential privacy, aggregation with sufficient group sizes, and expert validation of the anonymization quality.

De-identification also plays a role in fulfilling Data Act obligations while protecting GDPR interests. When a user requests access to data generated by their product, and some of that data contains personal information about third parties (for example, data from a security camera that captures images of neighbors), the manufacturer may need to de-identify the third-party personal data before providing access to the requesting user. The Data Act access right does not override the third parties’ GDPR privacy rights.

Practical Compliance Architecture for Both Frameworks

Managing GDPR and the Data Act simultaneously is not just a legal challenge — it is an organizational and technical one. The following framework describes the core elements of a compliance architecture designed to satisfy both.

Data Classification and Mapping

The foundation of any dual-framework compliance program is understanding what data you have and how to classify it. Every data asset in scope should be classified as personal data (GDPR applies), non-personal data (Data Act applies), or mixed (both apply, with specific rules for each component). This classification should inform the data architecture: wherever possible, personal and non-personal data should be stored in logically or physically separate systems, making it easier to apply the correct legal framework to each and to fulfill access or portability requests without commingling the two.

Data mapping — documenting where data flows, who has access to it, how it is used, and with whom it is shared — is already required under GDPR as part of the Records of Processing Activities (Article 30). This mapping should be extended to cover non-personal data flows subject to the Data Act, including the data generated by connected products, the interfaces through which access rights are fulfilled, and the contractual arrangements governing data sharing.

Unified Access Request Handling

Both GDPR and the Data Act create rights for individuals and users to access their data. Rather than building separate processes for GDPR Subject Access Requests and Data Act access requests, organizations should build a unified data access request intake and fulfillment process that routes requests to the appropriate framework and can handle mixed requests that implicate both. This unified process should include: intake mechanisms (web forms, email, in-product interfaces) accessible to users; legal review to classify the request and identify the applicable framework; technical fulfillment capabilities to gather and package the relevant data; and quality review to ensure that personal data components are handled per GDPR and non-personal data components per the Data Act before delivery.

Governance and Policy Integration

GDPR compliance programs typically include a suite of governance documents: a data protection policy, a data retention policy, a privacy notice, a data processing agreement template, and internal training materials. These documents should be reviewed and updated to address Data Act obligations, rather than creating a separate parallel governance structure. The data protection policy should describe the organization’s approach to both personal data under GDPR and non-personal data under the Data Act. The data processing agreement template should include provisions relevant to the Data Act where the counterparty relationship involves data sharing obligations under the Act.

Legal Basis and Contractual Alignment

Every data processing activity involving personal data must have a documented GDPR legal basis. Every data-sharing arrangement involving Data Act in-scope data must comply with the Act’s requirements for fair terms, access enablement, and non-discrimination. Contracts should be audited to ensure that GDPR data processing provisions are consistent with Data Act data-sharing provisions — they should not create commitments that are impossible to honor simultaneously, and they should not be used to contract out of rights that either framework makes non-waivable.

Technical Architecture for Data Separation and Access

Where possible, the technical architecture should reflect the legal framework. Personal data should be stored with access controls, encryption, and logging appropriate to GDPR. Non-personal data should be structured to enable the data access, portability, and interoperability required by the Data Act. APIs that expose non-personal data to authorized third parties under Data Act access rights should not inadvertently expose personal data. Privacy-by-design principles — building privacy and data rights compliance into the architecture rather than bolting it on afterward — serve both frameworks.

Conclusion

The EU Data Act and GDPR are not competitors or substitutes — they are complementary frameworks addressing different aspects of the data economy. GDPR protects individuals’ rights in personal data about themselves. The Data Act creates rights in data generated through the use of connected products and services, primarily non-personal data. Most real-world organizations dealing with IoT, connected products, or data-rich technology services will need to satisfy both simultaneously. The key to managing both is a clear understanding of the distinction between personal and non-personal data, a disciplined approach to data classification and mapping, and a compliance architecture that can address both frameworks’ requirements without treating one as a substitute for the other.