A lot of teams using LLMs carry a comforting assumption: "the models don't store our data - they just process it (they are stateless). So privacy risk isn't a big deal."

If your prompts include personal data (names, emails, chat transcripts, call notes), that assumption can be wrong.

This guide explains why, and what to do about it.

Even when providers say they don't train their AI on your data, many still retain inputs/outputs in logs for abuse monitoring / compliance for a short period — typically 30 days.

Why this matters: "stateless inference" becomes "stored records" for at least some window, which increases the risk that the data might be accessed or compelled to be revealed by a court.

This isn't theoretical. In the New York Times lawsuit against OpenAI, ChatGPT logs were placed under legal hold — meaning data that would normally be deleted after 30 days was preserved indefinitely for litigation. Your customers' data could be caught in the same net.

Some teams assume that choosing a US provider's EU or UK region sidesteps transfer concerns. But the US CLOUD Act (2018) allows US authorities to compel US-headquartered companies to produce data regardless of where it's stored.

The practical upshot: if your AI provider is a US company, the provider's corporate jurisdiction can matter as much as server location.

"We use their London region" can reduce some risks, but it doesn't automatically remove the possibility that a US-owned provider could be compelled to disclose data it controls.

In UK GDPR a "restricted transfer" is not only "we copied a database to the US", it can also include sending personal data to an organisation outside the UK, or making it accessible to them - even if it's "just processing" and even if it isn't stored long-term.

So in AI terms: if you send customer data (names, emails, order history, chat transcripts, call notes, medical details, etc.) to a US model provider for inference, you're very likely in restricted transfer territory. That means you need a legal basis for the transfer, alongside vendor terms that support it.

The UK–US Data Bridge created a route for certain US transfers, but it only covers transfers to US organisations that self-certify to the framework and specifically opt in to the UK Extension. Critically, the Data Bridge only exists because of Executive Order 14086 — the Biden-era order that created the intelligence safeguards the UK required before approving the framework.

The UK–US "Data Bridge" leans heavily on US commitments about signals intelligence safeguards and redress, especially:

Executive Order 14086 (Enhancing Safeguards for US Signals Intelligence) - a Biden-era order that sets safeguards around US signals intelligence and creates a redress mechanism. It is not a "transfer mechanism" and does not mean "US courts can't compel disclosure of data".

PCLOB (the Privacy and Civil Liberties Oversight Board) is explicitly named as having oversight roles tied to EO 14086. In early 2025, reporting said the White House asked Democratic PCLOB members to resign, which would leave the board without a quorum.

What could change: EO 14086 is an Executive Order, not a law, so it's easier for a US President to amend or withdraw. If the UK–US Data Bridge becomes unavailable (or harder to rely on), organisations will need to look at how they can ensure continued GDPR compliance.

If you're not passing personal or confidential data in your prompts, most of these legal concerns don't apply. So the question becomes: can you strip that data out before it reaches the model?

Anonymisation replaces sensitive information - a customer's name, an account number, a medical detail - with a placeholder tag. The mapping between the original data and the tag is cached locally. When the model responds using the tag, you de-anonymise on the way back.

Done well, the anonymisation layer is invisible to the rest of your application. Your AI features work exactly as before; the difference is what actually leaves your infrastructure.

The catch is accuracy. Names come in many forms — nicknames, initials, cultural variations. Is "JD" a person's name or something else? Modern approaches use machine learning rather than simple rules and pattern matching, making them far more reliable.

Note: Most real-world approaches are closer to pseudonymisation than "true anonymisation". You still need to watch for contextual leakage: the model can sometimes infer who someone is from surrounding details even if names are replaced.

Some organisations are asking a bigger question: is the complexity of managing US provider risk worth it at all?

The answer depends on your use case, your risk appetite, and how much capability you're willing to trade. But options do exist.

Why EU hosting works for UK businesses: Unlike transfers to the US, transfers from the UK to the European Economic Area don't require additional safeguards. The UK has adequacy regulations covering all EEA countries - so restricted transfer mechanics aren't needed.

"Sovereign" isn't just geography, it's jurisdiction. Hosting in the EEA reduces exposure to US legal compulsion if the provider is genuinely EU/UK-controlled; if a US provider operates the infrastructure, the risk analysis changes.

There are two main routes: use a European-headquartered provider, or self-host open-source models on European infrastructure.

European-native providers: Mistral AI (France) is the most prominent European foundation model company.

European GPU infrastructure: Little-known 'neocloud' providers are beginning to compete with the US hyperscalers: Scaleway (France), OVHcloud (France), and Nscale (UK).

The trade-offs: European and self-hosted options typically mean more compliance control (data stays in EU/UK, reducing exposure to US legal compulsion), but fewer capabilities (open-source models generally trail frontier models on complex reasoning) and more operational overhead (self-hosting requires GPU infrastructure, MLOps expertise, and ongoing maintenance).

Do you really need frontier performance? Many production use cases — classification, extraction, summarisation, routing — work well with smaller models. At Barnacle Labs, we've converted systems from frontier models to smaller open-source alternatives by strengthening prompts and breaking complex tasks into smaller steps. Where frontier-level capability is genuinely needed, fine-tuning can close the gap.

The legal ground under UK–US data transfers is less stable than it looks. That's not a reason to panic, but it is a reason to plan.

In practice, you have a spectrum of options:

1. Tighten hygiene and retention today — quick defensive steps without changing architecture.

2. Add an anonymisation layer — keep sensitive identifiers inside your perimeter while still using US models.

3. Move workloads to EU/UK-controlled models and infrastructure — where jurisdictional exposure is simpler to reason about.

The right path depends on your use case, your risk appetite, and how much operational complexity you're willing to own.