Fine-tuning in one EU region: data residency | Antyxsoft Cloud

Fine-tuning is the hardest GDPR case in machine learning, because the training data is very often the customer data. Not a public corpus, not a licensed dataset — your support tickets, your contracts, your clinical notes.

Teams handle this by picking an EU region and considering it done. Region is the easy half. The hard half is that a fine-tuning pipeline has more exits than anyone maps, and most of them are third-party SaaS that was adopted by an engineer in an afternoon.

Here is where the data actually goes.

1. The base weights are not the problem

Downloading an open-weight model from a hub outside the EU is a transfer to you, not from you. It carries no personal data and no residency obligation.

What does matter is where you cache them. If your pipeline pulls from a public hub on every job, you have a build-time dependency on a third party that can rate-limit you, change a licence, or remove a repository mid-quarter. Mirror the weights into your own object storage in-region once, pin the revision hash, and pull from there. This is a supply-chain argument rather than a privacy one, but it is the same fix.

2. Preprocessing is where data leaves first

The extraction and cleaning step is almost never in the same place as the training step. Common exits:

• Managed notebook services that execute in the provider's region, not yours.
• Hosted labelling platforms, where the annotation workforce is explicitly in a third country — that is the business model.
• Serverless functions deployed to a default region because nobody changed the flag.
• A laptop. Someone pulled a sample to look at it. It is now in a Downloads folder and a cloud sync client has it.

The test is not where the bucket is. It is where the CPU that touched the row was.

3. Experiment trackers are a data exit

This is the one that surprises people, and it is the most common leak in practice.

Experiment tracking tools log more than scalars. Sample predictions, validation examples, confusion matrix rows, prompt and completion pairs, dataset previews, artefact files. Teams log these deliberately, because they are useful. If the tracker is hosted SaaS in a third country, every one of those is a transfer of the exact data you were being careful about.

Same category, same problem: crash reporters that attach local variables, hosted logging that receives a debug dump of a batch, and evaluation dashboards that store generated outputs.

Either self-host the tracker in-region, or agree a strict allowlist of what may be logged — metrics only, no samples — and enforce it in the training harness rather than in a policy document.

4. Checkpoints inherit the sensitivity of the data

A fine-tuned model is a lossy compression of its training set, and language models are demonstrably capable of reproducing training examples verbatim, particularly rare ones — which is exactly the category personal data falls into.

The practical consequence is that checkpoints should be stored, replicated and access-controlled as if they were the training data. In particular: no automatic cross-region replication to a DR region outside the EEA, and no copying the weights to a developer machine to "try it locally".

5. Serving is a second, separate decision

Plenty of teams train carefully in-region and then deploy the result to whichever inference platform is convenient. That undoes the work twice over: the weights move, and every inference request — which contains user input, often personal data — goes with them.

If the fine-tune had a residency requirement, the endpoint has the same one. Include it in the same assessment rather than treating deployment as an afterthought.

6. Access, not just location

Storing in Athens while a support engineer in a third country holds break-glass credentials to the training cluster is a transfer, whether or not anyone uses them. The questions to put to a provider:

• Which staff can access customer compute and storage, and from which countries?
• What technical control — not policy — prevents access from outside the EEA?
• Is access logged in a way you can read?
• Which entity holds the contract, and which law binds it?

"Our policy prohibits it" is a commitment. It is not a control.

7. The checklist worth keeping

Before a fine-tune starts, one page, answered in specifics:

1. Where does raw data live, and where does the process that reads it run?
2. Where does preprocessing execute, and does any of it use a hosted service?
3. Where does the experiment tracker store data, and what exactly is logged to it?
4. Where do checkpoints and artefacts live, and where are they replicated to?
5. Where does evaluation run, and where do generated outputs land?
6. Where does the endpoint run, and where are inference logs retained?
7. Who can access each of the above, from which country, and how is that enforced?

Seven questions. Most teams can answer two of them without going to look, and the going-to-look is the entire exercise.

Why single-region is easier than it sounds

Once you accept that every hosted convenience is a potential exit, the simplest architecture is also the most defensible: object storage, GPU compute, artefact store, tracker and endpoint, all in one region, one provider, one contract, one jurisdiction. Fewer moving parts, one answer for the DPA, and no transfer impact assessment for a tool nobody remembers adopting.

It is marginally less convenient than assembling the best-in-class tool for each step. It is enormously easier to sign off.

Antyxsoft runs regions in Greece and Spain under EU law with no third-country parent. GPU instances are launching soon in those regions — join the waitlist if a single-jurisdiction training pipeline is on your roadmap.