RatedWithAI

RatedWithAI

Accessibility scanner

AI Legal & ComplianceAugust 6, 2026

Your Prompt Left the Country. Your Paperwork Did Not.

Transfer mechanisms were designed around databases that sit somewhere. An AI feature routes a fragment of personal data through a model provider, possibly a different cloud beneath it, possibly a different region under load — and the transfer impact assessment in your compliance folder describes none of that because it was written about hosting.

Transient counts
A prompt that is never stored is still a transfer if it crosses the border
Access is transfer
Remote support access from outside the region defeats data residency
Depth
App vendor → model provider → cloud → burst capacity: four links, four mechanisms

The Rule, Stated Plainly

Under the GDPR and its United Kingdom analogue, personal data may only leave the protected area if one of a defined set of mechanisms applies: a finding that the destination country provides adequate protection, an appropriate safeguard such as Standard Contractual Clauses or Binding Corporate Rules, or one of a narrow list of derogations that are not designed for routine operational flows. That is the whole structure, and it has not changed. What has changed is the architecture the structure is being applied to.

Two points cause most of the confusion in AI products. First, a transfer does not require storage — making data accessible to an entity outside the area is enough, which is why a stateless inference call still counts. Second, the obligation is not discharged by signing clauses. Since the Court of Justice's Schrems II judgment, the controller must also assess whether those clauses can actually be honoured in the destination given local surveillance law and practice, and add supplementary measures where they cannot. That assessment is the transfer impact assessment, and it is where AI-specific facts belong.

Why the Standard Template Does Not Describe an AI System

A hosting-era assessment answers: where is the data stored, is it encrypted at rest and in transit, who holds the keys, what is the retention period, and how would the provider respond to a government access request. Useful questions, all still relevant. But an AI processing path raises a different set, and if your assessment does not answer them it is not assessing the thing you are doing.

  • Retention for abuse monitoring. Many model providers retain inputs and outputs for a defined window for safety and abuse review, separately from any training use, and this retention is often configurable only on enterprise tiers. A zero-retention claim on a marketing page and a thirty-day abuse window in the terms are both common; only one of them belongs in your assessment.
  • Human review. Where retained content can be read by reviewers, the assessment has to say where those reviewers sit. Reviewer location is rarely documented and almost always answerable if you ask during procurement.
  • Training use. Whether inputs may be used to train or improve models changes the purpose, the retention profile and the practical possibility of erasure. Enterprise agreements usually exclude it; consumer and self-serve tiers frequently do not, and teams routinely prototype on the latter.
  • Region and capacity routing. Inference capacity is scarce and providers route around it. A commitment to process in a region is meaningful; a default that prefers a region but permits overflow is a different commitment wearing similar words.
  • Derived artifacts. Embeddings, fine-tuning adapters, cached retrieval indexes and evaluation logs are all derived from personal data and all live somewhere. Assessments routinely track the request path and ignore everything the request left behind.

The Subprocessor Chain Is Deeper Than Your Disclosure List

In a conventional SaaS product the chain is short: vendor, cloud provider, a handful of analytics and support tools. In an AI product it is longer and it moves. The application vendor calls a model provider. The model provider runs on hyperscaler infrastructure, sometimes more than one. Specialist inference hosts appear in the middle. Guardrail, moderation, transcription and vector-database services attach at the edges. Every link is an onward transfer that needs its own valid mechanism, and every link is supposed to appear on the subprocessor list you were given.

The realistic ask during diligence is not a promise that the chain will never change — it will — but visibility and time. Specifically: a subprocessor list that names the compute layer and not only the model brand, a notice period long enough to act on, and a stated consequence if you object. Where the vendor cannot say which regions its own provider may use, that is itself the finding, and it belongs in your assessment as an acknowledged uncertainty rather than being quietly resolved in the vendor's favour.

Adequacy, Frameworks and Why Nobody Sensible Relies on One Mechanism

Where a destination country benefits from an adequacy decision, transfers there work much like domestic ones. For the United States, the EU-US Data Privacy Framework provides that route for participating organisations that have certified, within the scope of their certification. This is genuinely simpler when it applies. It applies less often than people assume: subprocessors deep in an AI stack are frequently not certified, and a certification is entity-specific rather than group-wide.

Two previous transatlantic arrangements were annulled, and prudent programs therefore treat framework reliance as the primary route while keeping Standard Contractual Clauses executed and dormant underneath. That costs a signature and removes a scramble. The same logic applies to the UK's own transfer mechanisms, which have to be papered separately even where the substance mirrors the EU position.

What "EU Data Residency" Usually Means on a Pricing Page

Residency offerings sit on a spectrum, and the marketing language for all points on it is nearly identical. At the weakest end, primary storage is in-region while backups, telemetry, logs and support tooling are not. In the middle, storage and processing are in-region but support and engineering access come from elsewhere. At the strongest end, access controls are enforced so that personnel outside the region cannot reach production data without a documented exception.

Only the last of these substantially reduces transfer exposure, and it is the rarest and most expensive. The question that separates them in one sentence: can any employee outside the region access customer content in production, and under what process? A vendor with the strong version answers immediately, because it was hard to build and they are proud of it.

A Working Checklist

  • Map the actual request path for each AI feature, including retries, fallbacks and any secondary model used for moderation or embeddings.
  • Record the retention profile per hop: training use, abuse-monitoring retention, log retention, and whether any of it is configurable at your tier.
  • Confirm the transfer mechanism for every hop, and note where you are relying on a framework certification rather than clauses.
  • Write the transfer impact assessment against the AI facts — reviewer location, training use, derived artifacts — not against a hosting template.
  • Check the subprocessor notice terms and diary the objection window; an unread notification email is functionally consent.
  • Reconcile your public claims. Privacy pages, trust centres and security FAQs that state data never leaves a region are read as representations, and they age badly when routing changes.

Frequently Asked Questions

Does anonymising or redacting prompts remove the transfer problem?

It reduces it if the result is genuinely anonymous, which is a high bar — data that can be re-identified with reasonably available means remains personal data. Redaction pipelines that strip obvious identifiers still leave free-text context that frequently identifies someone, and in support or healthcare use cases the surrounding narrative is the identifier. Pseudonymisation is a useful supplementary measure but it does not by itself take the processing outside the rules.

Are we the controller or the processor for prompts our customers send?

For a B2B product the usual analysis is that your customer is the controller of the personal data inside prompts and you are the processor, with the model provider as your subprocessor. That allocation drives who signs which clauses and who is responsible for the assessment. It changes if you use the content for your own purposes, such as improving your own models, at which point you are acting as a controller for that purpose and need your own lawful basis and disclosure.

What about transfers to countries other than the US?

The same structure applies with different facts. Adequacy exists for a limited list of jurisdictions, and for the rest you are back to clauses plus an assessment of local law. Where inference capacity or annotation work sits in jurisdictions with broad state access powers and no independent redress, supplementary measures have to do more work, and in some cases the honest conclusion is that a particular routing cannot be justified.

How often should a transfer impact assessment be refreshed?

On change rather than on a calendar, with an annual backstop. The triggers that matter are a new subprocessor, a new region, a change in retention or training terms, and a material development in the destination country's law. AI stacks change on all of these more often than hosting stacks do, which is the practical reason these documents go stale faster than teams expect.

Do individual rights requests reach data sent to a model provider?

They should, and this is worth testing rather than assuming. Erasure is the difficult one: if inputs sit in an abuse-monitoring store with a fixed window, the vendor may be unable to delete on request and will instead point to the expiry. Whether that is acceptable depends on your basis and your disclosures, but discovering it during a live request is worse than discovering it during procurement.

Is a Data Protection Impact Assessment the same thing?

No, though they overlap and are often bundled. A DPIA assesses risk to individuals from the processing itself — profiling, automated decisions, sensitive categories. A transfer impact assessment asks the narrower question of whether your transfer safeguard holds up in the destination. High-risk AI processing frequently needs both, and reusing one to satisfy the other is a common review finding.

Related Reading

Does Your Privacy Page Still Match Where Your Data Goes?

Trust centres, privacy pages and security FAQs accumulate residency and retention claims. The most absolute-sounding sentence is usually the oldest one, written before the third model provider was added.

See every data-handling and compliance claim on your site in one pass. Run a free scan and check each against your current subprocessor list.

This article is general information and not legal advice. Transfer rules, adequacy findings and framework participation change, and the correct analysis depends on your role, data categories and destinations. Confirm with qualified counsel before relying on any transfer mechanism.