The Swiss question

A question that comes up more often than one would think — and an answer that surprises

It arrives almost as a reflex as soon as the words "data residency" come up in a conversation that is not being held with a Swiss company: "Why should that concern us, we are based in Germany?" The answer is more surprising than the question suggests — and that is precisely why it is worth giving at length.

For customers based in Switzerland, data residency in JiCo is not one option among several that can be selected or deselected in the settings, but a fixed, non-negotiable requirement. All permanent data stores — the audit trail, the internal queue for assignments, the encrypted mapping, every cache, every log — stay inside the customer's own infrastructure. If a cloud model is used at all, that is only permissible through a region firmly pinned to Switzerland, with cross-region distribution of requests explicitly switched off. If residency cannot be established beyond doubt for a particular path, the local model applies automatically — not as an awkward fallback, but as a deliberately chosen default for exactly that case of doubt.

The easy part — and the genuinely difficult one

The obvious part of this requirement is indeed easy to meet: a local model and a local data store satisfy it practically by themselves, without anything special having to be built for it — the data simply never leaves the machine, because there is no technical reason for it to.

The real work sits in what one does not see at first glance — in the trimmings that nobody would describe as "the data processing" and that nevertheless take effect in exactly that place: an automatic update check that briefly phones home when the program starts. A crash report that ends up somewhere without anyone having consciously clicked "send". A telemetry endpoint for operational data that happens not to sit in Switzerland, because nobody explicitly configured it to. None of these places changes a single bit of an actual personal record — and yet residency would be broken if even one of them were to remain quietly active. That is exactly why telemetry and comparable side channels stay dormant in JiCo as long as nobody explicitly configures an endpoint for them — an advantage in this respect, not a technical omission.

The box that answers the question architecturally rather than contractually

For customers who want to answer this question not through a configuration setting but through the architecture itself — because a setting can be changed, whereas a physical arrangement cannot be changed so easily — there is a preferred variant: a dedicated appliance on Apple silicon hardware, standing directly at the customer's site, with Ollama running natively on the host operating system and the remaining building blocks containerised alongside it.

This particular arrangement is a technical necessity, not a symbolic wish for hardware of one's own: a containerised language model loses direct access to the graphics unit under macOS and therefore falls back to markedly slower computation on the CPU — measured in practice as three to six times slower than with direct hardware access. For a single interactive chat that may still be tolerable. For an overnight assignment run across hundreds of tickets it would burst the entire time window in which an approval folder has to be ready by the next morning.

The pleasant side effect of this solution: a physical box in one's own data centre needs neither a cloud contract nor a continuous check of whether cross-region distribution really stays switched off. The requirement is met because there is simply no route to the outside that would have to be checked at all — not because a configuration promises it, but because the hardware makes it structurally impossible.

Two routes, the same region, different pitfalls

Even when a cloud model is deliberately chosen in an individual case, the examination does not end with picking the right region. Two large providers offer access to a well-known cloud model through a Swiss region — one through the one large cloud infrastructure, one through the other, both with a data centre in Zurich. Both routes count as residency-compliant only if the request really stays pinned to that one region.

The pitfall here is a feature whose actual purpose is to improve resilience: a cross-region distribution of requests that automatically diverts to another, possibly far-away region when load is high. It is exactly this feature that has to be explicitly switched off for Swiss customers, or its scope demonstrably confined to Switzerland — otherwise a feature meant to provide greater reliability would quietly break, in the background, the very assurance that had just been given.

Why this answer is relevant outside Switzerland too

The mechanism that was originally developed for Switzerland is at its core the same one a German company needs for its processing on behalf of a controller under the GDPR (the EU General Data Protection Regulation), or an Austrian one for questions of official secrecy (Amtsgeheimnis) in certain sectors: a demonstrable, concretely nameable place where the processing actually happens — and, in case of doubt, a decision that consistently comes down on the side of restraint rather than the more convenient option.

Anyone who asks this question at all — from whichever of the three German-speaking countries — is as a rule not only asking about a single, specifically named law. They are asking about a fundamental attitude towards control over one's own data, and that can usually be read off this one answer quite reliably already.