Running EU AI workloads in Frankfurt: a data residency checklist

Who this checklist is for

Teams building on EU personal data, such as support transcripts, clinical notes, HR documents or user-generated content, usually get the same instruction from legal: keep it in the EU. Choosing a Frankfurt region is the easy part. The hard part is everything that quietly leaves it: a snapshot policy that copies to another continent, an observability exporter pointed at a US endpoint, a CI runner that pulls the eval set into Virginia.

This is a practical engineering checklist for keeping training data, checkpoints, inference traffic, logs and backups inside Reviosa's EU Central (Frankfurt) region, eu-central-1. Running there does not cost more: published rates on /pricing are identical in all four regions.

This is not legal advice. GDPR and the EU AI Act impose obligations that depend on your role, your data and your use case. Use this checklist to make engineering decisions concrete, and have qualified counsel confirm what applies to you.

GDPR in one paragraph, for engineers

The GDPR applies when you process personal data of people in the EU, wherever your company is incorporated. It requires a lawful basis for each purpose, data minimization, purpose limitation and security appropriate to the risk. When a vendor processes personal data on your behalf, you need a data processing agreement (Article 28). Transfers of personal data outside the European Economic Area need a legal mechanism such as an adequacy decision or standard contractual clauses (Chapter V). Individuals have rights, including access, erasure and objection, that your pipelines must be able to honor.

Physical data residency is not itself a GDPR requirement. It is the simplest way to stay clear of transfer rules, and many customer contracts and internal policies demand it outright. That is why engineering ends up owning it.

EU AI Act: dates to keep on your radar

The AI Act entered into force on 1 August 2024 and applies in phases:

The European Commission has proposed adjusting some of these deadlines, so check the current official timeline before you plan around a specific date. Three engineering implications hold either way: document where your training data came from, keep logs that let you reconstruct what a system did, and know which of your systems could be classified as high-risk. All three are far easier when your data lives in one well-understood place.

The residency checklist

1. Compute

• [ ] Every instance that touches EU personal data launches in eu-central-1. Make region an explicit, required parameter in launch scripts and infrastructure code, never a default.
• [ ] Use a dedicated API key and a naming prefix for EU workloads, so a stray launch in us-east-1 or us-west-2 stands out in the console and on invoices.
• [ ] Dev boxes count. An engineer debugging in another region with a copy of production data has made a transfer.

2. Datasets

• [ ] Raw and processed datasets live on block volumes or object storage buckets in eu-central-1. See Storage for the options.
• [ ] Preprocessing (tokenization, deduplication, PII scrubbing) runs in-region too, on CPU instances on the same private network.
• [ ] Minimize before you train: drop fields you do not need, pseudonymize identifiers, and keep any re-identification mapping in a separate location with tighter access.
• [ ] Record lineage for every dataset version: source, purpose, legal basis noted by counsel, date and content hash.

3. Checkpoints and model artifacts

• [ ] Treat checkpoints of models trained on personal data with the same residency as the data. Models can memorize training examples, so a checkpoint is not automatically anonymous.
• [ ] Push checkpoints, adapters and optimizer states to an in-region bucket, not to a model hub hosted elsewhere. Search your training scripts for push_to_hub and similar flags.
• [ ] Pulling public open-weight models into the region is fine. Residency is about what leaves, not what arrives.

4. Inference traffic

• [ ] Serve EU users from endpoints in eu-central-1, and route them there explicitly if your application is global.
• [ ] Check where TLS terminates. CDNs, API gateways and WAFs in front of your endpoint can decrypt, inspect and log request bodies in their own regions.
• [ ] Keep any persisted prompt or response caches on in-region storage with a defined retention period.

5. Logs, traces and metrics

This is the most common leak, because prompts and completions are personal data whenever users type personal data into them.

• [ ] Log metadata by default: latency, token counts, status codes, model version. Log content only when you need it, deliberately.
• [ ] Audit every telemetry SDK. Error trackers, APM agents and OpenTelemetry exporters often default to a US ingest endpoint and capture request payloads.
• [ ] Run your collector, log store and dashboards in-region, or use vendors' EU endpoints with contracts that say so.
• [ ] Enforce retention with lifecycle rules, not good intentions.

6. Snapshots and backups

Reviosa snapshots support cross-region copy and restore to any of our four regions. That is valuable for disaster recovery, and it is exactly the feature that can move EU data out of the EU.

• [ ] Audit every snapshot schedule's destination. Snapshots of EU data stay in eu-central-1 unless counsel has approved otherwise.
• [ ] Treat restores as transfers too. Restoring an EU snapshot into another region "just to test something" counts.
• [ ] Check bucket replication and sync jobs (rclone, aws s3 sync and similar) for out-of-region destinations.
• [ ] Plan erasure for backups: either delete on restore or keep retention short enough that erasure requests age out within an agreed window.
• [ ] Be explicit about disaster recovery. Frankfurt is our only EU region, so cross-region DR leaves the EU. In-region options are triple-replicated block volumes, in-region snapshots and an off-platform backup to another EU location you control.

7. People and access

• [ ] Remote access from outside the EEA can itself be a transfer. Limit who can read EU data, from where, and keep access logs.
• [ ] Use least-privilege credentials for training jobs, and separate keys for production and experimentation.

8. Third parties in the pipeline

• [ ] Experiment trackers, labeling vendors, evaluation services and hosted LLM-as-judge APIs all receive data. Each is a processor relationship and possibly a transfer.
• [ ] Run evals that use real data on in-region infrastructure; use synthetic or scrubbed data anywhere else.

Cross-region pitfalls we see most often

A five-minute static check catches many of these before they ship. Keeping the private network and the data in one region does the rest:

# Flag non-EU regions and hub uploads in infra, configs and training code
grep -rnE "us-east-1|us-west-2|ap-northeast-1" infra/ configs/ scripts/
grep -rnE "push_to_hub|upload_folder|hub_model_id" training/

Vendor questionnaire: what to ask your GPU cloud

Ask every infrastructure vendor these questions, including us, and get the answers in writing:

1. Where are compute, block storage, object storage and snapshots physically located? Can data move between regions without customer action?
2. Which subprocessors can access customer data, and from which countries?
3. Is a data processing agreement available, and which transfer mechanism covers any access from outside the EEA?
4. How is data encrypted at rest and in transit, and who manages the keys?
5. What happens on deletion of a volume, bucket or instance? Is GPU memory cleared between tenants?
6. Who on the vendor's side can access customer instances, from where, and is that access logged?
7. How quickly will you be notified of a personal data breach? Controllers have 72 hours to notify their supervisory authority, so the vendor's commitment needs to be faster.
8. Which audit reports or third-party assessments are available today? Ask for current documents, not logos.
9. What usage metadata does the vendor keep about your account, and for how long?

Our privacy policy covers how we process personal information for users of the Frankfurt region. For the rest of your questionnaire, send it through contact sales and we will answer in writing.

FAQ

Does running in Frankfurt make our AI workload GDPR compliant?

No. Residency in the EU avoids many international transfer questions, but GDPR compliance also depends on lawful basis, minimization, security, processor contracts and data subject rights. Treat residency as one control among several, and confirm your obligations with counsel.

Which Reviosa region is in the EU?

EU Central (Frankfurt), region id eu-central-1. It is our only EU region. Published rates are the same as in our other three regions; check the console for current SKU availability.

Are model checkpoints personal data?

They can be. Models can memorize and reproduce training examples, so checkpoints trained on personal data should get the same residency and access controls as the dataset until you have a documented reason to treat them differently.

When do EU AI Act obligations apply?

In phases: prohibitions from February 2025, general-purpose AI model obligations from August 2025, most remaining provisions from August 2026, and some product-related high-risk rules from August 2027. Proposed changes may shift dates, so check the current official timeline.