Derived and inferred data are usually outside portability scope

What it is

Inferred data and portability concerns the boundary between data provided by a person and data created through a controller's analysis. In GDPR portability guidance, actively supplied data and observations arising from use can fall within scope, while profiles, scores, classifications, and algorithmic results subsequently created by the controller are generally outside it. That does not make inferences non-personal data or establish that access and other rights can never reach them.

Why it happens

Activity records and inferences have different production relationships. Location points, play histories, and device measurements arise from the person and their activity; risk scores and interest classes add organizational models, features, and judgment. Portability seeks to release personal inputs without indiscriminately transferring analytical products. Exporting only form fields construes “provided” too narrowly by omitting observations, while conflating model parameters with person-level scores hides distinct interests and rights.

Studying it

An actual catalog can be labeled field by field as actively supplied, observed, transformed, inferred, or aggregated, with independent reviewers applying the relevant rule and recording disagreement. Synthetic accounts can compare access copies and portable exports while testing whether people understand the distinction. Provenance matters more than a field name: “activity” might be a direct count or a predicted propensity.

Where it stops holding

“Usually outside” is a bounded claim about GDPR portability, not a global rule. Other laws, contracts, or voluntary exports may cover more. Exclusion from portability does not authorize concealment, indefinite retention, or immunity from correction; access, transparency, automated-decision, and fairness rules may still matter. Trade secrets or others' rights call for an assessment of partial provision rather than automatic rejection of an entire request.

Applying it

• Record generation method, inputs, model or transformation, and applicable rights for each catalog field rather than inferring origin from table name.
• Separate supplied, observed, transformed, and excluded inferred data in export explanations, linking to routes for other personal-data access.
• Preserve portable source observations in mixed pipelines instead of excluding all activity because the product also computes a score.
• Test accounts containing raw events, simple counts, and model scores against lineage and access/portability outputs; route unexplainable provenance to human review.

Related

• Same group: O1.12.1 Portability lets users retrieve their data in a structured format · O1.12.2 Machine readability determines whether another service can import an export · O1.12.4 Export can become a bulk-exfiltration attack surface
• Adjacent: O2.10 Privacy dashboards and data visibility · P4.09 Algorithmic fairness and disparate impact
• Search terms: inferred data · observed data · data portability scope