Artifact GuideEU

EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR

Build one access workflow that is Data Act-compliant and GDPR-safe.

Focus: connected product data access and portability where datasets often contain mixed personal and non-personal data.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

Many EU Data Act datasets are mixed: sensor streams and device logs can contain both personal and non-personal data. The EU Data Act does not replace the GDPR. It adds specific access and portability rules for connected product and related service data, and you must implement them in a way that respects GDPR principles (lawfulness, minimisation, security, transparency). This page explains how to design a single operational workflow that satisfies both regimes without over-sharing or building duplicate processes.

Section 1

1) What is the Data Act doing that GDPR doesn't?

GDPR is a fundamental-rights regime for personal data. The EU Data Act is a market and fairness regime for access to and use of data (including non-personal data), with a specific focus on connected products, related services, and cloud switching.

The key operational impact: the Data Act can require access/portability mechanisms for datasets that are not purely personal data and that have multiple actors (user, data holder, third party).

GDPR: rights and obligations tied to personal data and controller/processor roles
Data Act (Chapter II): access/portability for connected product/related service data for the user, including sharing with third parties chosen by the user
Data Act adds: direct vs indirect access design patterns and product UX obligations (transparency before purchase)

Section 2

2) Portability: Data Act vs GDPR portability (don't conflate them)

GDPR portability is a data subject right for personal data under specific conditions. Data Act portability is designed for IoT-style operational data, often near real-time, with a focus on enabling switching and innovation.

Practically, teams should implement one export and sharing pipeline that can produce (a) GDPR portability packages for personal data and (b) Data Act exportable datasets for connected products.

Data Act portability: operational, often continuous or near real-time, and includes non-personal data generated by use
GDPR portability: personal-data-only conditions and format obligations; typically request/response rather than streams
Engineering implication: build a shared data export service with policy-based filtering and purpose/recipient controls

Recommended next step

Use EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR as a cited research workflow

Research Copilot can take EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR from how this topic compares with adjacent regulations or standards to a reusable workflow inside Sorena. Teams working on EU Data Act: Fair Access to Connected Product Data and Cloud Switching can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Research workflow

Open Research Copilot for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR

Start from EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR and answer scope, timing, and interpretation questions with cited outputs.

Explore next step

Talk to Sorena

Talk through EU Data Act: Fair Access to Connected Product Data and Cloud Switching

Review your current process, evidence gaps, and next steps for EU Data Act: Fair Access to Connected Product Data and Cloud Switching Data Act vs GDPR.

Explore next step

Section 3

3) Direct vs indirect access: privacy engineering consequences

The Commission's FAQs describe direct access (self-service technical means) and indirect access (request via the data holder). Both can be compliant; they create different privacy and security risks.

Direct access pushes more security responsibility into product design. Indirect access increases operational load but can simplify sensitive-data minimisation.

Direct access: strong identity binding, secure client design, rate limits, and fraud/abuse monitoring
Indirect access: request intake, identity verification, policy checks (personal vs non-personal), and auditable delivery receipts
For mixed datasets: implement field-level classification and recipient-specific filtering

Section 4

4) Sharing to third parties: lawful basis and safeguards (when personal data is included)

When the dataset includes personal data, GDPR still governs lawfulness and safeguards. The Data Act's sharing mechanisms must be implemented with GDPR principles: minimisation, purpose limitation, security, and transparency.

Operationally: you need a consistent way to verify who the requester is, who the recipient is, and what data is being shared.

Define a recipient onboarding path: identity verification, security requirements, and permitted use attestations
Use a policy engine: field-level filters, redaction, aggregation, and purpose-based access decisions
Keep evidence: request logs, identity checks, dataset manifests, and delivery receipts

Section 5

5) A combined implementation blueprint (single workflow, two legal lenses)

Avoid building separate "GDPR portal" and "Data Act portal". Build a single request and delivery workflow with two decision layers: (1) Data Act chapter/role eligibility and (2) GDPR personal-data safeguards.

This also improves UX: users get one consistent experience and you avoid inconsistent exports.

Step A: scope memo per product/service (what is 'readily available', who is data holder, direct vs indirect access)
Step B: data classification (personal vs non-personal) + disclosure policy and filters
Step C: secure delivery pipeline (export formats, encryption, integrity checks, logs)
Step D: evidence pack (requests, decisions, outputs, incidents, disputes)

Primary sources