Transfer Impact Assessments for a US-Hosted AI Provider

A transfer impact assessment is not a form. It is an argument that the protection guaranteed by the GDPR travels with the data to a country whose surveillance law you do not control, and Clause 14(d) of the standard contractual clauses obliges you to have written it down before a supervisory authority asks. For a US model API the whole argument turns on one contested question about who the provider is.

What a TIA is and who owes it

The obligation comes from two places. Judgment of the Court of Justice of 16 July 2020 in Case C-311/18, Schrems II, held that a controller relying on standard clauses must verify, on a case-by-case basis and where relevant in collaboration with the recipient, whether the law of the destination country ensures adequate protection, and must provide additional safeguards where it does not — see curia.europa.eu for C-311/18. Clause 14 of Decision (EU) 2021/914 then converted that into a contractual warranty, with Clause 14(d) requiring the assessment to be documented and made available to the supervisory authority on request.

The method most authorities expect is the EDPB’s Recommendations 01/2020 on measures that supplement transfer tools, adopted in final form on 18 June 2021 and published in the EDPB’s document register. It is six steps, and it is worth following in its own order because the order is the argument.

The exporter owes it. That is you, not the vendor — although the vendor holds most of the facts, which is why a vendor transparency report and a written answer on its own legal status are inputs you have to ask for rather than infer.

The six steps, applied to a model API

1. Know your transfer. Map every flow, including the ones that are not API calls: the inference request itself, any fallback provider, telemetry and traces, support access to your tenant, and any human review of flagged content. Record what personal data each carries. The awkward one is almost always the abuse-review path, because it is the flow where a human being at the vendor reads a prompt.
2. Identify the transfer tool. Adequacy decision under Article 45, an Article 46 tool such as the SCCs, or an Article 49 derogation. If the provider is certified under the EU-US Data Privacy Framework for this data, you are on Article 45 and steps three to five do not apply to that transfer. If you are on SCCs, choose the module first — see which SCC modules apply to an AI processor.
3. Assess whether the tool is effective in light of the law and practice of the third country. This is the substantive step. For the United States it means examining the surveillance authorities that could reach the transferred data, and asking specifically whether this importer falls within their scope.
4. Adopt supplementary measures where step three shows a problem. Contractual, organisational and technical. The EDPB is explicit that contractual and organisational measures alone generally cannot overcome a legal power of a public authority to compel access, which is why the technical measures matter disproportionately.
5. Take any procedural steps. Where you add measures to the SCCs, verify they do not contradict the clauses. Where you conclude you cannot ensure an essentially equivalent level of protection, the transfer must not start, or must be suspended.
6. Re-evaluate at appropriate intervals. A TIA has an expiry, and for AI vendors the triggering events are frequent: a new sub-processor, a new region, a change to retention, a change to the surveillance statute, or a change in the adequacy position.

The government access question

Three US authorities dominate step three, and the analysis differs for each.

Section 702 of the Foreign Intelligence Surveillance Act, codified at 50 U.S.C. section 1881a — the text is at the Office of the Law Revision Counsel — permits targeting of non-US persons reasonably believed to be located abroad, with compelled assistance from providers falling within a statutory definition. Whether an AI inference provider falls within that definition is genuinely unresolved. It was drafted around electronic communication service providers, and a model API is not obviously one; equally, the definition was broadened in the 2024 reauthorisation in terms that some commentators read as reaching a much wider class of service providers with access to equipment on which communications travel or are stored. There is no public authority settling the question for model APIs. A TIA should state the uncertainty rather than resolve it in either direction, and should record what the vendor itself says about whether it considers itself within scope.

Executive Order 12333 governs signals intelligence collection outside the FISA framework, including collection abroad, and it does not provide for compelled assistance in the same way. Its relevance to a transfer assessment is mostly about data in transit and about the absence of individual redress.

The CLOUD Act, at 18 U.S.C. section 2713, obliges providers subject to US jurisdiction to preserve and produce data in their possession, custody or control regardless of where it is stored. This is the provision that defeats the naive answer “we selected the Frankfurt region”: region selection changes where bytes sit, not who can be ordered to produce them. If the importer is a US corporation, EU hosting is a latency and residency measure rather than a jurisdictional one.

Against this sits Executive Order 14086 of October 2022 — published at the Federal Register — which introduced necessity and proportionality requirements for US signals intelligence and created the Data Protection Review Court as a redress mechanism. It is the foundation of the current adequacy decision, and it is an executive order, which means it can be amended by a later executive act rather than requiring legislation. A TIA that relies on it should say so explicitly, because that reliance is the assessment’s weakest link.

Supplementary measures that actually help

The EDPB’s recommendations set out use cases where effective measures exist and use cases where they do not, and the honest position for a model API is uncomfortable: the strongest technical measure — encryption where the importer holds no key — is unavailable, because the provider must have the plaintext prompt in order to run inference on it. That rules out the EDPB’s clearest effective-measure scenario. What remains is a set of measures that reduce exposure rather than eliminate it:

• Minimise what crosses. The most effective measure available is not sending the data. Redaction or tokenisation of direct identifiers before the call, with the mapping held only in the EU, genuinely narrows what a production order could reach — with the caveat, which the assessment should state, that detectors miss and that free-text context can re-identify.
• Contractual retention limits, in Annex II. Data the importer does not hold cannot be produced. A zero-retention or short-window commitment recorded as a technical and organisational measure is materially stronger than the same promise in a settings page.
• Transparency and challenge commitments. Clause 15 obligations, plus a published transparency report showing the vendor has in fact received and responded to government requests. A vendor that has never published one has given you nothing to assess.
• Route sensitive workloads to an EU-established importer. Not a supplementary measure so much as an avoidance of the transfer, and the only measure that fully answers the CLOUD Act point — provided the EU entity is not a subsidiary under the control of a US parent, which is the detail that undoes many such arrangements.

Writing it down

Clause 14(d) requires documentation, and the document is what you will be judged on. Keep it to the shape of the argument: the transfer mapped; the tool selected; the destination law examined with the specific statutes named; the conclusion on whether this importer is within their scope, including where that is uncertain; the measures adopted; and the residual risk accepted, with who accepted it and when. Date it, name the version of the vendor’s sub-processor list it was written against, and record the review trigger.

Two failure modes are worth naming. The first is a TIA that concludes the risk is low because the vendor has never received a request — an argument about practice that says nothing about the legal power, which is what Schrems II asked about. The second is a TIA that reaches a favourable conclusion and never revisits it; Clause 16 obliges the exporter to suspend transfers where the clauses can no longer be complied with, and that obligation is meaningless if nobody is watching. For the background to why all of this exists, see Schrems II’s effect on US-based LLM providers.