Data portability

Overview

Data portability is a person's ability to obtain their data from a service and send it to another one. The problem is that the copy is often partial, arrives in formats only developers can use, and is slow to get 2610.15503 §III.A. The legal baseline in the EU is GDPR Art. 20, which covers personal data "provided" by the person and requires a machine-readable format and transfer to another controller where technically feasible 2610.15503 §II.A.2. The Data Act, the DMA, the proposed EHDS and the AI Act add narrower rules for connected products, gatekeepers, health data and AI 2610.15503 §II.B–§II.E.

The one paper on this concept argues the legal framing is too narrow. It says portability is treated as a qualified right to a copy, and the rules are written from the provider's side 2610.15503 §IV.B. The paper is an analysis, not a system. It names no protocol, API or permission format 2610.15503 §III.C.

Variants

The paper sorts designs by who holds the data and who runs the computation. Its three models are the variants below.

Consent and opt-out

Each service keeps its own data platform. The person can request a copy or instruct the service to transfer data to another service 2610.15503 §III.A. The paper notes that the person gets no storage place under their own control, and that companies have little incentive to build interoperable systems 2610.15503 §III.A. Card: Data Portability Revisited.

Enterprise-centric: GAIA-X and data pods

Shared infrastructure, such as the GAIA-X initiative, or a personal data store per user that applications connect to instead of holding the data themselves 2610.15503 §III.B.1, §III.B.2. The paper says pods are accessible by default, mostly serve enterprises, and get their interoperability standards from platform operators 2610.15503 §III.B.2. Card: Data Portability Revisited.

User-held, private by default

Each person has a private data environment. Applications run on the person's side, in a federated way, and each data access needs prior permission and a stated justification 2610.15503 §III.C. The paper describes this as an open-source API layer but gives no specification 2610.15503 §III.C. Card: Data Portability Revisited.

When to use which

The paper reports no measurements, so this table compares the designs on the constraints the paper itself uses. It makes no claim about cost or speed.

Scope also decides which rules apply. The GDPR covers data the person provided, and the access right does not cover derived data 2610.15503 §II.A.2, pitfalls. The Data Act covers IoT product data at the individual level only 2610.15503 §II.B. The DMA covers gatekeepers only 2610.15503 §II.C. A system built for one scope does not meet the others.

Implementation sketch

The paper's user-held model, in our own words. It is a paraphrase of prose, not a specification from the paper 2610.15503 §III.C.

# Handle an app's request for one kind of personal data
# Input:  app, data_kind, purpose
# Output: the app's result, computed on the user's side

def handle_app_request(app, data_kind, purpose):
    # Data stays in the user's private environment [arxiv:2610.15503 §III.C]
    if not user_has_granted(app, data_kind):
        # Prior permission is required, and the app must justify it
        # [arxiv:2610.15503 §III.C]
        return ask_user_for_permission(app, data_kind, purpose)
    # Apps run locally, in a federated way [arxiv:2610.15503 §III.C]
    return run_app_locally(app, data_kind)

Contradictions

None known. Only one paper covers this concept, so there is nothing to set against it. Its normative claims, such as portability as a fundamental right 2610.15503 §IV.B, are argument and have no measured counterpart.

Papers

• Data Portability Revisited: Toward the Human-Centric, AI-Driven Data Ecosystems of Tomorrow: a legal analysis of EU portability rules that compares consent, enterprise-centric and user-held architectures.