---
kind: concept
slug: data-portability
title: Data portability
summary: >-
  How a person can move or reuse data that a service holds about them, and the three architectures that set who controls the data and how it moves. Based on one legal analysis of EU rules (GDPR, Data Act, DMA) with no experiments, so no measured results.
tags: [data-portability, data-governance, personal-data, eu-regulation]
papers: ["2610.15503"]
related: [differential-privacy, federated-learning]
status: draft
updated_at: 2026-10-19
---

## 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 [arxiv: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 [arxiv: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 [arxiv: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 [arxiv:2610.15503 §IV.B]. The paper is an
analysis, not a system. It names no protocol, API or permission format
[arxiv: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
[arxiv: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 [arxiv:2610.15503 §III.A]. Card:
[Data Portability Revisited](/papers/2610.15503).

### 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
[arxiv: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 [arxiv:2610.15503 §III.B.2]. Card: [Data Portability
Revisited](/papers/2610.15503).

### 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 [arxiv:2610.15503 §III.C]. The paper describes this as
an open-source API layer but gives no specification [arxiv:2610.15503 §III.C].
Card: [Data Portability Revisited](/papers/2610.15503).

## 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.

| Situation | Use | Why |
|---|---|---|
| You must comply with GDPR Art. 20 and have no other constraint | Consent and opt-out | It is the existing model the regulation is written around [arxiv:2610.15503 §II.A.2, §III.A] |
| Many services must exchange data with each other | Shared infrastructure or a pod | The paper counts connections for the consent model: seven services need 21 links, and the number grows quickly [arxiv:2610.15503 §III.A] |
| The user must keep control over data and what apps do with it | User-held, private by default | Access needs prior permission and local execution [arxiv:2610.15503 §III.C] |
| You need a specification to build against | None of the three | The paper gives no protocol, identity method or permission format, so the design work is yours [arxiv:2610.15503 §III.C] |

Scope also decides which rules apply. The GDPR covers data the person
provided, and the access right does not cover derived data
[arxiv:2610.15503 §II.A.2, pitfalls]. The Data Act covers IoT product data at
the individual level only [arxiv:2610.15503 §II.B]. The DMA covers gatekeepers
only [arxiv: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 [arxiv:2610.15503 §III.C].

```pseudocode
# 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
[arxiv: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](/papers/2610.15503): a legal analysis of EU portability rules that compares consent, enterprise-centric and user-held architectures.