In the first installment, we covered what happens to your content when you put it somewhere.
Today, let's clarify the one thing that confuses people the most: "EU-based" is not a single property. And "non-EU" isn't automatically bad – it just means a different regime and a different type of risk.
The simplest difference
Generally stricter rules for handling data, typically under GDPR. Clear obligations, oversight, and real fines when someone cuts corners. That's why companies can more easily justify it internally.
Rules are different – sometimes looser, sometimes less predictable. Doesn't automatically mean bad, but it's harder to predict in advance what exactly can happen to your data.
That's it. Now here's why there's so much confusion around it.
"EU-based" can mean very different things
1. Company is in the EU and has servers in the EU
The cleanest scenario: the vendor is European and the infrastructure is also in Europe. The service is typically built around European expectations (GDPR, etc.), easier to justify internally, and it's clearer who's responsible for what. Simply "EU on both sides."
2. Company is outside the EU, but has servers in the EU
Your data may physically sit on servers in Europe (that's a plus), but the service is still owned and operated by a non-EU company. "EU servers" doesn't automatically mean "EU rules and EU control" – decision-making, access (admin/support), and what the company can do under its home jurisdiction may still follow non-EU rules.
3. Company is in the EU, but servers are outside the EU
The vendor is European, but data storage and application processing happen outside Europe. Data actually leaves the EU space, and even though the company is EU-based, internal approval processes tend to be stricter because "data is physically elsewhere."
4. "EU company, but AI is non-EU" Watch out
The most common trap: the website, login, and billing all look European, but the moment you paste in text, the service simply takes it and sends it via API* to a non-EU AI that actually processes it, then sends the result back.
On the outside "EU-based," on the inside a cable going out. Companies then live in false comfort, unaware of where data flows, how many third parties are in the chain, and with sensitive content it ends in endless approvals or a real problem.
That's why "EU-based" is not a guarantee. It's just the beginning of the question: "EU in what sense?"
What non-EU typically means
Non-EU simply means the company and AI are outside the European space. The question that comes up more often is: "If something goes wrong, who has oversight and how enforceable is it?"
USA (e.g., OpenAI and others)
In the standard free/personal version, it's typically a public service for individuals: the company has no control over it, often has no contractual guarantees, and you're simply putting content into someone else's system. Some services may even have content usage for improvement turned on by default.
The enterprise tier is a different story: that's where you negotiate terms, roles/access, auditability, and often data handling policies.
China (e.g., DeepSeek and others)
Companies typically aren't concerned about "model quality" but about trust and predictability: who can access data and what obligations the company has toward the state. That's why many companies won't even consider them for sensitive content, even if they're cheap and fast. For example, the Czech government banned the use of DeepSeek in public administration due to cybersecurity concerns.
Why it's not black and white
An EU tool isn't automatically safe, and a US tool isn't automatically unsafe.
In practice, what matters most is how many third parties are in the chain, and those aren't just "AI models." Even if a service has EU servers, it may use additional external tools for support, monitoring, error logging, analytics, email notifications, or file storage.
Every additional company in the chain creates another place where something can go wrong: more access points, more accounts, more logs, more risk of human error.
Conclusion
After our team tried virtually every possible path and configuration (EU/non-EU, different regimes, different vendor promises), we came to one conclusion: for the most sensitive documents, we want peace of mind. So we chose the path of running our own infrastructure, where the model runs locally. It's more work than "just use a public service," but for us it was the only way to truly eliminate third parties.
For everyday things ("give me a recipe," "what's 2+2"), it practically doesn't matter where you put them. This whole discussion is primarily about situations where you're sending internal and sensitive content to AI: contracts, client data, personal information, know-how, financial figures, internal presentations, or anything that would really hurt if it accidentally surfaced somewhere.
If you wouldn't want your competitors sitting there with popcorn watching… don't put it in public AI. Next up: the EU AI Act in plain language – what it covers and what it doesn't.