Where your data goes: model origin, hosting & the CLOUD Act
When you pick an AI model for your agent, the model picker shows three different countries. They're easy to confuse, but they mean very different things, and only one of them is about where your data actually goes. This guide explains each, what the US CLOUD Act really means for "Swiss" cloud (even when a local subsidiary operates it), the trade-offs of choosing strictly local models, and how to pick a server location that fits your needs.
The three labels, and which one matters
Model origin is the country of the organisation that created and trained the model (a US lab, a European lab, a Chinese lab, …). Origin says nothing about where your prompts are processed; an American model can run entirely on Swiss servers, and vice-versa. Crucially, the model's creator has no access to how you use the model or the data it processes. Once the model's weights run on our (or a hosting provider's) infrastructure, only the host sees your prompts, and the lab that built it gets nothing back. Origin is therefore about the model's behaviour and provenance, not a data-access channel. Where it does matter is political and values alignment: a model trained under a given jurisdiction can reflect that country's content rules and political sensitivities (some models quietly avoid or steer around politically sensitive topics, or reflect state-aligned positions), and some organisations have policies to avoid models from certain countries on geopolitical or ethical grounds.
Model hosting is the country of the datacenter where the model actually runs and where your prompts and the responses are processed. This is the one that determines where your data is physically sent. If you only look at one label, look at this one.
Hosting company is the company that operates that datacenter. Its home country can claim legal reach over the data in addition to the law of the country where the servers physically sit, even when the data is stored abroad (see the CLOUD Act below). So the operator can pull your data under a second jurisdiction; data can be subject to more than one country's laws at once.
| Label | Answers | Why it matters |
|---|---|---|
| Model origin | Who built the model? | Political / values alignment, vendor policy |
| Model hosting | Where is my data processed? | Physical data residency |
| Hosting company | Who operates the servers? | Legal reach over the data (e.g. CLOUD Act) |
"Swiss datacenter" ≠ Swiss-only jurisdiction: the CLOUD Act
The US CLOUD Act (2018) lets US authorities compel US-headquartered companies to hand over data in their "possession, custody, or control," explicitly regardless of where it's stored.
A natural assumption is that a local subsidiary solves this. For example, Azure's Swiss regions are run through a local Microsoft entity (Microsoft Schweiz GmbH). Unfortunately, that structure does not put the data beyond US reach: US courts interpret "control" broadly, and a wholly-owned subsidiary is treated as controllable by its US parent. Microsoft has confirmed this itself. In June 2025, Microsoft France's legal director testified under oath to the French Senate that he could not guarantee customer data would never be handed to US authorities, and that Microsoft would comply with a lawful US order, even for data held under a French "sovereign" offering.
So a Swiss datacenter operated by a US company (or its Swiss subsidiary) gives you Swiss physical location and latency, and Swiss law does apply, but US law applies on top. For sovereignty against US access specifically, what matters is the operator's ultimate ownership, not where the servers sit or which local entity signs the contract. The strongest position is hosting in Switzerland by a company that is ultimately Swiss-owned and only subject to Swiss law, which is exactly what the "by Swiss company" / "by European company" tiers select for.
The trade-off: sovereignty often costs capability and speed
Stricter isn't automatically better for everyone. The most capable frontier models today are largely built and operated by US (and some Chinese) companies. Swiss- and European-operated options exist and are improving quickly, but they are often a step behind on raw capability, and even when they host the same open-weight models, responses can be slower: lower throughput (tokens per second) and higher latency than the large US hyperscalers.
In other words, choosing a strict server location can mean trading some intelligence and speed for sovereignty. Pick the strictest tier your use case genuinely requires, and loosen it only where the capability or latency gap actually hurts.
A note for voice agents
Voice (phone) deployments involve one additional party that text agents don't: the telephony provider that connects the call. botts.ai uses Twilio, the industry-standard telephony platform, which is US-headquartered. Like any such platform, Twilio handles some data: call logs and metadata (numbers, time, duration), plus recordings or transcripts only if you turn those on (call recording is off by default). Twilio also offers an EU (Ireland) region for Voice, so this data can be kept in the EU when configured. The nuance worth knowing is jurisdictional: as a US company, Twilio remains subject to the US CLOUD Act wherever its servers sit (the same parent-company point as above), so a US provider is part of the chain for phone calls, even with a Swiss-hosted model.
For most use cases that's perfectly fine. But if keeping telephony entirely within Switzerland or the EU is a requirement for you, reach out and we'll prioritise rolling out Swiss/EU phone infrastructure. Until then, text and chat channels keep everything within your chosen server location.
What botts.ai keeps in Switzerland regardless of model
Independent of the model you pick, these always stay in Switzerland, and we never train models on your data:
- botts.ai Server (application infrastructure): 🇨🇭 Switzerland
- Knowledge base storage: 🇨🇭 Switzerland
- Chat storage (conversations & messages): 🇨🇭 Switzerland
- Model training on your data: off
And this isn't only our own policy: we have contractual agreements with every model provider we use (data-processing terms that prohibit training on your data), so the model-hosting companies don't train on your prompts or content either, wherever the model runs.
The only variables are the model (and, for voice, the phone provider). That's why the Data Assessment panel focuses on the model's hosting and operating company.
Choosing a server location
Server location is an organisation-wide setting (set once by an owner or admin under Settings → Server location; it applies to every agent and member in the organisation, not per agent or per user). It filters the model picker to only the models that satisfy your chosen tier, and flags any existing deployment that no longer complies.
- Swiss server by Swiss company: strongest sovereignty. Data in Switzerland, operated by a Swiss company, no CLOUD Act exposure. Best for regulated industries, health, legal and the public sector. Smallest model selection.
- Swiss server, any company: data physically in Switzerland; the operator may be foreign (CLOUD Act may apply). Good physical residency and latency, wider model choice.
- European server by European company: data in Switzerland or the EU, operated by a European company. Strong GDPR alignment.
- European server, any company: data in Switzerland or the EU, any operator.
- Global: no restriction. The full catalogue, including the most capable (and often fastest) models, wherever they're hosted.
Recommendation: start as strict as your use case requires, then relax only if you need a capability or speed the stricter tiers can't match yet. For most Swiss businesses handling customer data, Swiss server by Swiss company (or European by European) is a sound default; reserve Global for non-sensitive workloads where you want the widest, fastest model choice.
Have a specific compliance requirement? Get in touch and we'll help you pick the right setup.
