Modified
Data sovereignty: your data, their servers
Every time you send text to an AI service it leaves your computer and is processed on a company’s servers, in a country with its own laws. This is not a technical problem. It is a legal and strategic choice you make every day you use AI.
The law follows the server, not you.
Data on a US server falls under US law. Data on a Chinese server falls under Chinese law. As a European business you have obligations under regardless of where you choose to store it, but the consequences of choosing wrong vary widely.
The Swedish DPA (IMY) can issue fines of up to 4% of global turnover or EUR 20 million — whichever is higher. This is not a theoretical risk.
Data localisation is not data sovereignty
Data localisation describes where information is stored or processed. Data sovereignty is about who ultimately controls it, and which laws can be used to demand access.
A service can be marketed as "stored in the EU" without being fully shielded from legislation outside the EU. If the provider is controlled by a company in another country, that country's rules can still apply. Nor is a European provider automatically safe. Contracts, security measures and subprocessors still need review.
So do not only ask where the server sits. Ask who operates the service, who can administer it, and who can compel the provider to hand data over.
Your responsibility when someone else runs the model
As a European organisation you are responsible for how personal data is processed, even when an external AI provider does the work. GDPR covers the whole chain, from collection and transfer to access, deletion and security.
Serious breaches can lead to fines of up to 20 million euro or four per cent of global annual turnover, whichever is higher. A wrong provider choice can also stall a launch, force an expensive migration, or damage customer trust.
Three jurisdictions
EU storage
Data stays inside the EU/EEA and falls under European law. No additional contract is needed to comply with GDPR. is the only major frontier provider with native EU storage. Local models via are always EU-safe because the data never leaves your computer.
US storage
OpenAI, Anthropic and Google store data in the US by default. The gives US authorities the right to request data from US companies, including data stored in Europe. GDPR compliance requires a signed with the provider.
China storage
Chinese law requires companies to give authorities access to data on demand, without judicial review. DeepSeek is technically powerful, but for European businesses handling sensitive data: run the model via Ollama instead of using the cloud service.
Schrems II and the CLOUD Act
The Court of Justice of the EU invalidated the earlier Privacy Shield arrangement in its Schrems II ruling, and made clear that organisations must assess whether protection actually works in the receiving country. Standard contractual clauses are not an automatic pass. They need to be paired with an assessment of legislation, access risk and technical safeguards.
The CLOUD Act means US authorities can, under certain conditions, require US service providers to hand over data under their control, even when it is stored in another country. That does not mean open access to European servers. The point is that server location alone does not determine which jurisdiction a provider is exposed to.
For providers covered by the EU-US Data Privacy Framework, the European Commission adequacy decision can be relied on. Otherwise standard contractual clauses are common, together with an assessment of transfer risk. Do not treat "DPA signed" as the same thing as "the transfer is lawful". The agreement governs roles and responsibility. The transfer mechanism handles the data leaving the EU or EEA.
Who holds the encryption keys?
Encryption only helps fully if the right party controls the keys. If the provider both stores the information and can decrypt it, the provider still has technical access.
For sensitive systems, ask about customer-managed keys, separate key storage, and which administrators can gain access. Check backups, logs and temporary files too. A strong solution should not only protect data in transit and at rest. It should limit who can actually read it.
GDPR in practice
What counts as personal data?
Personal data is information that can be linked directly or indirectly to a living person. That includes names, email addresses, phone numbers, IP addresses, customer numbers, location data, and combinations of details that together make someone identifiable.
So when you paste a support ticket into an AI service you may be processing personal data even if no national ID number is present. You need a lawful basis, a clear purpose, and control over how long the data is kept.
Names, email addresses, phone numbers, IP addresses, cookies and any data that can be linked to an identifiable person. If you send these to a US-hosted AI model without a valid DPA, you are in breach of GDPR.
DPA agreement
Both OpenAI and Anthropic offer Data Processing Agreements. A signed DPA satisfies the requirements for transferring personal data to the US. Search for "DPA" in your provider’s admin panel.
EU-based provider
Mistral AI is EU-based (Paris) with servers inside the EU. No transfer of personal data to a third country. The GDPR issue does not arise. The right choice for European products with sensitive data.
Local execution
Ollama with local models (Llama, Mistral, Qwen): no data leaves the machine. Zero GDPR risk from data transfer. The right choice when you handle sensitive data and have a sufficient .
What applies when you prompt?
A prompt can be used to produce the answer, saved in history, logged for debugging, reviewed for abuse, or used to improve the service. It varies between providers, contracts and product tiers.
Check whether content is used for model training, how long prompts and answers are kept, whether administrators can read them, whether logging can be turned off, and whether the provider offers a mode without persistent storage. "No training" and "zero retention" do not always mean the same thing. Data can still be held briefly for security or operations.
Read the terms for the product you actually use. A free chat service, a business account and an API can each have different rules.
Anonymise first
Do you really need to send real names, national IDs or addresses to the model? It is often enough to or pseudonymise the data before it is sent. "The customer is Anna, 34, lives in Gothenburg" can become "the customer is a woman in her 30s in a major Swedish city" without the answer suffering noticeably, but with dramatically lower risk.
and security go together. Key handling, agent isolation and dependency protection are covered on the Security page. Go to Security →
Checklist before choosing an AI service
- Map what information is sent, and whether it contains personal data, confidential material or trade secrets.
- Check the provider's domicile, server regions, subprocessors and possible remote access.
- Secure a data processing agreement and the right mechanism for transfers outside the EU or EEA.
- Review retention, training, logging, deletion, and who controls the encryption keys.
- Anonymise the information or choose local execution when the cloud risk cannot be justified.
This is an overview to help you ask the right questions, not legal advice. The law on third-country transfers keeps moving, and adequacy decisions have been struck down before. Check against current practice and involve a lawyer before committing to a provider for sensitive data.