Foundation
Sovereign and on-device AI
You decide where the model runs and what it may see. We design the system so that the answer to “where does our data go?” is a short list you can check.
Residency and sovereignty
Residency is where the servers are. Sovereignty is who controls the data: which jurisdiction governs it, who can compel access and who holds the keys. Data can sit in Switzerland and still be reachable from abroad, depending on who operates the infrastructure. We answer both questions in stage 01 and record the answer in the regulatory applicability note.
Where the system can run
| Option | When it fits | What it means |
|---|---|---|
| Swiss-hosted cloud | Swiss residency is required and standard cloud controls meet your risk profile | Data stays in Swiss data centres; operator and access model named in the design |
| EU-hosted cloud | Swiss residency is not required and your data protection assessment allows it | Wider choice of models and services; transfer basis documented |
| Your own infrastructure | You run a cloud tenancy or data centre you trust | The system runs inside your environment and controls |
| On premises | The data must not leave your building | Local models on your hardware, no external model calls |
| On the device | The data should not leave the user’s phone or computer | Inference on the device; nothing sent for the AI step |
Most systems combine two: personal data stays on Swiss or customer infrastructure, and only anonymised content goes to a stronger model for the steps that need it.
What we have built
Zeza · Beta. A voice app for iPhone that turns speech into clean text with nothing leaving the phone. Live transcription runs on the iOS SpeechAnalyzer, a second, more accurate pass on the Parakeet TDT 0.6b v3 speech model, polishing, summarising and restyling on Apple Foundation Models, and read-back on on-device neural voices. No backend, no account, notes stored locally. It needs iOS 26 on an iPhone that supports Apple Intelligence, and the larger models download after install.
Clipgenie · Beta. A Mac clipboard manager whose summarise, translate and clean-up actions run on the device through Apple Foundation Models, on Apple-silicon Macs with macOS 26 and Apple Intelligence. An optional bring-your-own key sends long documents to a cloud model, and only the clip the user acts on. There is no Clipgenie server, and clips from password managers are skipped.
Tenderix, our internal procurement tool, reads Swiss public tenders in German, French and Italian with an optional local model, called through a sandbox that blocks outbound traffic. Every feature also works without the model. Comparizzo compares files in the browser, and Kutio, our Mac archiver, has no accounts, no analytics and no network code: neither uploads anything.
When a cloud model is the right tool
For some steps a large cloud model is clearly better, and then personal data stays out of the call. Our anonymise-before-inference build aliases every name, address and identifier first, an independent check fails the run if a real value is about to leave, and the aliases are reversed locally at the end.
What leaves and what stays
| Design | Stays with you | Leaves your control |
|---|---|---|
| On the device | Audio, text, notes, model output | Nothing for the AI step; model files downloaded once |
| Local model on premises | Documents, prompts, outputs, logs | Nothing for the AI step |
| Customer or Swiss cloud, hosted model | Data at rest, logs, the alias table | Prompts and outputs pass through the model service you chose |
| Cloud model with anonymisation | Personal data and the alias table | Aliased text only, after the independent check passes |
The trade-offs
| Choice | You gain | It costs |
|---|---|---|
| On-device | Nothing leaves; works offline; no per-request bill | Smaller models; supported hardware only; evaluation on the target devices |
| Local model on premises | Full control of data and model version | You run the hardware and patch the model; local models trail the largest cloud models on long, open tasks |
| Swiss or customer cloud | Residency and control on managed infrastructure | Fewer models in some regions; operator and access model need checking |
| Cloud model with anonymisation | The strongest models for the hardest steps | Aliasing is a step to test; some tasks need identities |
We set out these trade-offs in stage 01 and test them in stage 02: a local model is chosen when it passes the evaluation set, and the design changes when it does not.
In the six stages
| Stage | Sovereignty work |
|---|---|
| 01 · Ground the case | Residency and sovereignty answered; hosting chosen; DPIA scoped |
| 03 · Engineer the system | Hosting built; anonymisation and check in place; on-device or local models packaged |
| 05 · Scale what works | Hosting extended to new sites and devices; device support confirmed |
| 06 · Run and evolve | Model updates tested before rollout; hosting reviewed when rules or providers change |
Questions
Is Swiss hosting enough?
It answers where the servers are. It does not answer who operates them, which law can compel access or who holds the keys. We scope both questions in stage 01 and write the answer into the architecture.
Can a local model match a large cloud model?
Sometimes, on narrow and well-defined tasks. On long documents and open reasoning the largest cloud models are usually ahead. The evaluation set decides: a local model is used where it passes, and the design changes where it does not.
What runs on an employee’s device?
Only what the device can run well and the use case allows. Our on-device products state their hardware limits: Zeza needs an iPhone that supports Apple Intelligence, and Clipgenie works as a plain clipboard manager on Macs without it.
If we use a cloud model, what does it see?
Only what the step needs, with personal data replaced by aliases where the design allows. An independent check fails the run if a real value is about to leave, and the aliases are reversed on your side.
Who updates local models?
The operating agreement sets that out. Under Run and evolve we test every model update against your evaluation set before rollout; if your team runs the system, they receive the same suite.
Related
Start with the data question
An AI Opportunity Assessment includes a regulatory applicability note that tells you which rules apply to your data and use case. The hosting choice follows from it.
See the AI Opportunity Assessment