Buying US-sourced data that contains EU or UK personal data: transfer mechanisms for AI teams

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Where EU and UK personal data hides in US operational records

EU and UK personal data turns up in US datasets wherever a US company serves, employs or corresponds with people in Europe. Support ticket exports from Zendesk or Salesforce Service Cloud carry requester names, emails and free-text addresses from European customers. Sales histories hold CRM contact records for EU buyers, and engineering records hold commit authors and Jira assignees who work for a London or Berlin subsidiary.

Employee data is the most common surprise. A US parent often receives HR, Slack and email records about EU staff from its European affiliate, and those records arrived in the US under a transfer mechanism that still constrains what the parent can do with them. Our guide to employee communications in training data covers the monitoring and works-council questions that sit alongside the transfer analysis.

The first diligence task is therefore a field-level inventory: which tables or document types contain data subjects located in the EU, EEA or UK, how the supplier obtained them, and which legal regime governed collection.

Which flows count as restricted transfers when you license US records

A restricted transfer usually exists only where a party subject to the GDPR or UK GDPR sends personal data to a recipient outside the EEA or UK. That framing matters because the most common deal shape for a European lab, a US supplier shipping records to an EU buyer, is an import into the EU rather than an export from it. The EU buyer then becomes a controller fully subject to the GDPR for that data, with its own lawful basis, Article 14 notice and minimization duties.

The picture changes in three situations. First, the US supplier may be directly subject to the GDPR under Article 3(2) because it offers goods or services to people in the EU, in which case its disclosure to a buyer in a third country (for example Canada, Singapore or the US itself) can be treated as a Chapter V transfer [11]. Second, the supplier may hold the data because it was transferred from Europe under the DPF or SCCs, and those instruments restrict onward disclosure. Third, your own team may re-export the data from the EU, for instance to a US GPU cloud region or an annotation vendor in another country.

Map every hop in writing. Counsel then assigns each hop a status: not a transfer, a transfer covered by adequacy, or a transfer requiring Article 46 safeguards.

When pseudonymised or de-identified delivery takes data outside transfer rules

Data that is anonymous for you falls outside the GDPR entirely, and with it the transfer rules. Recital 26 measures identifiability by the means reasonably likely to be used, taking account of cost, time and available technology [1]. In EDPS v SRB (C-413/23 P, 4 September 2025), the Court of Justice held that pseudonymised data may be personal data for the controller that holds the key but not for a recipient that cannot reasonably re-identify the individuals [3].

Commentators read the judgment as recipient-relative: the same delivery can be personal data at the supplier and non-personal data at the buyer [4]. Lewis Silkin's AI-focused analysis stresses that this depends on the recipient's actual means, including auxiliary data it holds, rather than on a label in the contract [5]. For a lab that also trains on web-scale corpora, that is a demanding test, because rich free text such as ticket bodies can re-identify people without any key. See our detailed treatment of receiving pseudonymised data after EDPS v SRB.

Two cautions follow. The European Commission's Digital Omnibus would narrow the personal-data definition along similar lines, but as of September 2026 those GDPR amendments remained proposals, not law [6]. And a recipient-relative finding does not relieve the supplier, which still processes personal data when it creates and discloses the pseudonymised extract.

How the EU-US Data Privacy Framework applies to training data flows

The Data Privacy Framework is an adequacy route that covers transfers from the EU only to US organizations that have self-certified and appear on the DPF List. The General Court upheld the adequacy decision in Latombe v Commission (T-553/23) in September 2025, and that ruling has been appealed to the Court of Justice [7]. As of October 2026, treat the DPF as valid but contested, check the recipient on the official DPF List, and keep an SCC fallback drafted.

For a training-data buyer, the DPF matters in two directions. If your EU lab sends data to a US contractor or cloud tenant, that recipient's certification (and its scope, which can cover HR data or non-HR data separately) decides whether you need SCCs. If the US supplier received EU data under the DPF, its own obligations travel with the records.

That second point is the one most deals miss. The DPF Principles include Notice, Choice and Accountability for Onward Transfer, which generally require a certified organization to offer individuals an opt-out before disclosing their data to a third-party controller or using it for a materially different purpose, and to bind the recipient by contract to purposes consistent with the original notice [8]. A US supplier that collected EU customer data for support cannot simply license it for model training without checking those conditions.

Choosing between SCCs, the UK IDTA and the UK Addendum

Where no adequacy route covers a hop, the default EU tool is the 2021 standard contractual clauses adopted by Implementing Decision (EU) 2021/914, which count as appropriate safeguards under Article 46 [2]. The clauses are modular: Module 1 for controller to controller, which fits most licensing deals, Module 2 for controller to processor, and Modules 3 and 4 for processor-initiated chains. Clause 14 obliges the parties to assess the importer country's laws and practices, which is where the transfer impact assessment sits.

For UK data, the ICO's International Data Transfer Agreement and the International Data Transfer Addendum to the EU SCCs have been the standard UK contractual tools since 2022. Use the Addendum when the deal already runs on EU SCCs and also carries UK data; use the IDTA for a UK-only arrangement. For US recipients, the UK Extension to the DPF (Data Bridge) has applied since October 2023 [9]; the Extension lets UK organizations make restricted transfers to US organizations certified for the UK Extension without further safeguards; confirm certification scope on the DPF List and in current ICO guidance.

The Data (Use and Access) Act 2025 also reframed the UK transfer test, with most changes reportedly in force from 5 February 2026 [10]. Ask UK counsel whether existing IDTA templates and transfer risk assessments need refreshing. Our UK GDPR licensing guide covers the UK-side lawful basis questions.

Decision table: mapping each hop to a mechanism

Use one row per data hop, not one row per deal. Most licensing transactions have three to five hops once cloud regions, labeling vendors and evaluation contractors are counted.

Illustrative example: invented to show structure; it does not describe an available dataset.

Contract terms and diligence evidence to request from the supplier

The license should record the transfer position as clearly as it records fields and term. Ask the supplier, or your intermediary, for the following before signature:

• Data subject geography: counts or proportions of EU, EEA and UK records per table, and how residency was inferred.
• Collection basis: the privacy notice in force at collection, and whether training or licensing to third parties fell within it.
• Inbound transfer instrument: whether the data entered the US under the DPF, SCCs or the IDTA, and the onward-transfer conditions attached.
• De-identification method: the transformation applied, re-identification testing, and residual free-text risk; our de-identification evidence package checklist lists the documents.
• Onward-transfer permissions: which of your processors and regions the license allows, and how sub-processors are notified.
• Incident path: what both sides do if EU personal data is found after delivery, covered in our response playbook for found personal data.

Your own lawful basis for training on whatever personal data remains needs a separate record; see legitimate interest for training on licensed personal data.

How SourceX handles personal data in sourced datasets

SourceX sources operational datasets from US companies and manages the commercial process, including the licensing agreement, for AI teams wherever they are based. Every dataset is rights-reviewed for ownership and consents, and personal details such as names, emails, phones and account numbers are removed or replaced before delivery, with the method recorded and a sample checked; no method is perfect. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset, which gives your counsel inputs for the transfer analysis above. You can describe the records you need to SourceX, and the wider privacy and de-identification hub and procurement guide cover adjacent steps. For a supplier-side overview, see buyers outside the U.S..

License US records with EU or UK personal data under a clear transfer position

SourceX looks for US businesses that hold the data you describe, assesses data and licensing permissions, and agrees allowed uses in a license before anything is delivered through private, access-controlled workflows. Datasets are sourced on request, a request does not guarantee a match, and nothing is contracted until a supplier agrees. Start a buyer request at sourcex.si/buyers.