Data Portability and AI-Derived Profiles Under GDPR

Portability is the narrowest of the data subject rights and it is routinely treated as the broadest. Article 20 does not entitle a person to everything you hold about them — it entitles them to what they gave you, under two of the six lawful bases, where processing is automated. An AI-derived profile usually fails the first of those.

Three gates before Article 20 applies

Article 20(1) of Regulation (EU) 2016/679 applies only where all three of the following hold:

• The data was provided by the data subject to the controller. The subject of the rest of this page.
• The processing is based on consent under Article 6(1)(a) or Article 9(2)(a), or on a contract under Article 6(1)(b). Processing grounded in legitimate interests, legal obligation, vital interests or public task is outside Article 20 entirely — which excludes most model training done under Article 6(1)(f).
• The processing is carried out by automated means. Rarely a live issue here.

Article 20(3) adds that the right does not apply to processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority, and Article 20(4) that it must not adversely affect the rights and freedoms of others — the provision that bites when one person’s message history contains another person’s messages.

The “provided by” limit

The authoritative reading of “provided by” is in the Article 29 Working Party’s Guidelines on the right to data portability (WP242 rev.01), revised in April 2017 and endorsed by the EDPB. The guidelines construe the phrase broadly but not without limit, and they do so by splitting data into three kinds.

Data actively and knowingly provided — what the person typed into a form, uploaded, or wrote — is plainly in scope. Data observed by virtue of the person using the service is also in scope: the guidelines give search history, traffic data and location data, and raw activity logs, as examples. Data inferred or derived by the controller from that input is not: the guidelines give a credit score, the outcome of a health assessment, and a profile created by analysis of raw smart-metering data as things the right does not extend to.

The reasoning is that portability exists to move a person between services and to rebalance the relationship, not to transfer the controller’s own analytical work product. Whether that reasoning is right is arguable; that it is the regulators’ position is not.

Observed data is in; inferred data is out

The line between observed and inferred is the one to get right, and it is not about how the field was computed but about whether it records something the person did or something you concluded about them.

• message_text, uploaded_file, account_email — provided. In scope.
• prompt_history, page_views, feature_click_log, session_timestamps — observed. In scope on the guidelines’ reading, and this is the category most often wrongly withheld.
• churn_probability, topic_embedding, estimated_seniority, persona_cluster_id — inferred. Outside Article 20.
• A model fine-tuned on one user’s conversations — not portable data in any recognisable sense, and the request it answers is usually really an access request. See data subject requests against a fine-tuned model.

A useful test: if the field would still be the same had you never built a model, it is probably observed. If it exists because you ran an analysis, it is probably inferred.

What this means for an AI product

For a typical assistant product, an Article 20 export should contain account details the user supplied, everything they typed or uploaded, and their raw usage and prompt logs, in a structured, commonly used and machine-readable format — Article 20(1) asks for exactly that, and JSON or CSV with documented field names satisfies it. Model outputs are an interesting middle case: they were generated by you, but they are also a direct record of the user’s own conversation, and the practical and defensible course is to include them rather than to litigate a borderline classification against your own user.

Embeddings, cluster assignments, propensity scores and personalisation weights are the derived layer, and excluding them from a portability export is consistent with the guidance. Excluding them from an Article 15 access response is not: the access right has no equivalent limit, and inferred data about an identifiable person is personal data that Article 15(3) reaches. The two rights are frequently conflated, and the conflation always runs in the direction of under-disclosing.

Article 20(2) adds a right to have the data transmitted directly from one controller to another where technically feasible. Recital 68 makes clear this does not create an obligation to adopt or maintain compatible formats, so “technically feasible” is a real limit rather than a euphemism — though sector-specific interoperability duties under other instruments, including those discussed on the Data Act and cloud switching, can impose more than the GDPR does.

The right they probably wanted

Somebody who asks to port their profile almost never wants a file. They want to know what you concluded about them, or they want you to stop. The rights that deliver those are Article 15, which reaches inferred data and under 15(1)(h) the logic of any Article 22 decision-making, and Article 21, which lets them object to profiling based on legitimate interests — see the right to object to AI profiling. A response that correctly explains why Article 20 does not reach the profile and stops there is legally accurate and practically useless, and it is the kind of answer that turns a question into a complaint. Article 12(2) requires a controller to facilitate the exercise of data subject rights, which at minimum means telling the person which right does what they are asking for.

Where the line is contested

The observed/inferred boundary has never been ruled on by the Court of Justice, and the WP242 categories are guidance rather than statutory text. There is a reasonable argument that a low-level derived artefact which is simply a re-encoding of what the user provided — an embedding of a message they wrote, for instance — is closer to provided data than to a credit score, and no authority has addressed it. There is also an unresolved question about how Article 20(4)’s rights-of-others limit applies to conversational data that routinely contains third parties. Treat the categories as a defensible default, document how you classified each field, and expect the edges to move.