The question a Swiss bank's board asks about artificial intelligence is rarely "does it work". It is "where does the data go". The answer most vendors give is a contract clause. The answer that satisfies a regulator, an internal auditor and a client whose grandfather chose the bank is an architecture: a description of every place a byte of client data can physically be, at every moment of processing, with the people who can reach it named.
This article argues three things. First, that a Swiss financial institution can use the most capable models available today without a single byte of client-identifying data leaving its jurisdiction. Second, that the revised Federal Act on Data Protection and the supervisory expectations that sit around it are clearer on what is required than the marketing language of the model vendors. Third, that the decision is architectural rather than contractual, and belongs to the chief information officer and the chief risk officer jointly, not to procurement alone.
What sovereignty means when the model is not yours
Sovereign AI is a phrase that has drifted. In a ministry it means models trained, hosted and governed under national law. In a bank it means something narrower and more useful: the institution decides, and can prove, which data reaches which computation, in which legal territory, under whose control.
That definition separates three things that are usually blurred together.
The model weights are the artefact produced by training. They may be open, licensed for self-hosting, or accessible only through a vendor's interface. Where the weights live determines where inference can happen.
The inference computation is the act of running a prompt through the model. It happens where the weights are loaded. If the weights are on a vendor's servers in another jurisdiction, so is every prompt.
The data pipeline is everything before and after inference: retrieval from the bank's own documents, redaction, logging, evaluation, human review. This is where most client data actually flows, and it is entirely within the bank's control regardless of which model it uses.
What the revised FADP actually requires
The revised Federal Act on Data Protection came into force in September 2023. It is often described as Switzerland's answer to the GDPR, and in structure it is. For the AI question, four of its obligations do the real work.
It requires that personal data be processed only for the purpose it was collected for, and that the data subject could reasonably expect that processing. A client who provided documents to open an account did not expect them to be used to train a model, or to be sent to a third party for summarisation, unless told.
It restricts the disclosure of personal data abroad. Transfer to a country without adequate protection requires specific safeguards, and the controller remains responsible for the data once it has left. A vendor's servers in a third country are a disclosure abroad, whatever the interface looks like.
It requires a data protection impact assessment where processing is likely to present a high risk to the data subject. Automated processing of financial records at scale, with a model whose behaviour cannot be fully specified, is the kind of processing the provision was written for.
It establishes duties around automated individual decisions: where a decision with legal effect or significant consequence is made solely by automated means, the data subject must be informed and may request human review. A model that recommends whether to onboard a client is on the edge of that provision. A model that decides is inside it.
None of these obligations forbids the use of large language models. All of them constrain where the data may go and what must be documented before it goes there. That is the point: the law is an architectural specification wearing legal clothing.
The supervisory layer
Above the data protection law sits the supervisory expectation of the Swiss Financial Market Supervisory Authority. Its circular on outsourcing treats the transfer of significant functions to a third party as something the institution remains fully responsible for. The bank must be able to audit the provider, to instruct it, to retrieve its data and to exit. A model vendor that processes client data is, for supervisory purposes, an outsourcing partner. The bank must be able to say who at the vendor can see what, and to demonstrate that the arrangement can be unwound.
Bank-client confidentiality under the Banking Act adds the obligation that is hardest for vendors to meet. Confidentiality is not a matter of consent forms. It attaches to the relationship and it is criminal law. An architecture in which a foreign vendor's staff could, under their own country's legal process, be compelled to produce a Swiss client's prompt history is an architecture the general counsel will not approve. The cleanest way to avoid the question is not to create the data abroad in the first place.
Three architectures, and what each one leaves exposed
There are three realistic ways for a bank to use frontier-class models. They differ in what leaves the building.
| Architecture | Where inference runs | What leaves Swiss control | Who can meet it |
|---|---|---|---|
| Vendor interface | The vendor's infrastructure, usually abroad | Every prompt and every retrieved document | Anyone; it is the default |
| Regional cloud deployment | A hyperscaler's Swiss region, under the vendor's or the bank's tenancy | Nothing by design; telemetry and support access by exception | Institutions with a cloud governance function |
| Self-hosted open weights | The bank's own data centre or a Swiss colocation provider | Nothing | Institutions with an engineering function, or a firm that builds it for them |
The first architecture is where most pilots begin and where most of them should not stay. Redaction before the call helps, but redaction of unstructured financial documents is unreliable, and the audit trail lives with the vendor.
The second is where most institutions should land for the majority of use cases. The Swiss regions of the large cloud providers offer models under a tenancy the bank controls, with encryption keys the bank holds, and with contractual and technical guarantees that prompts are not retained or used for training. The exposures that remain are support access, telemetry and the legal reach of the provider's parent jurisdiction. Each of these is a known question with a documented answer, and the answers belong in the data protection impact assessment.
The third is the sovereign option in the strict sense. Open-weight models of serious quality now exist, and for well-defined tasks such as document classification, extraction, summarisation and internal search they are more than sufficient. The cost is engineering: someone must run the inference cluster, patch it, evaluate the model and replace it when a better one arrives. For a private bank this is usually a firm's job, not a hire.
The law does not forbid the model. It forbids the data leaving. Those are different problems, and only one of them is hard.
The architecture decision, made properly
The decision is not one choice but a set of them, and they are best made in this order.
Classify the data before choosing the model. Client-identifying data, client-derived data that has been aggregated or pseudonymised, and internal non-client data have different obligations. Most of the value in a bank's first AI programme is in the second and third categories: policy search, procedure drafting, code assistance, internal reporting. Start there, with the widest set of models available, and reserve the sovereign architecture for the first category.
Decide the residency boundary explicitly. Write down the legal territories in which client-identifying data may be processed and stored. For most Swiss institutions the answer is Switzerland, with the European Economic Area permitted for specific processing under documented safeguards. This sentence becomes a constraint on every subsequent architecture diagram.
Choose the model to fit the boundary, not the reverse. Once the boundary is fixed, the set of permissible models is short and the choice is easy. Institutions that choose the model first spend a year trying to make the boundary fit around it.
Separate the control plane from the data plane. Orchestration, prompt management, evaluation harnesses and monitoring can run anywhere as long as they never touch client data. Inference and retrieval over client data run inside the boundary. This separation is what makes it possible to use a vendor's tooling without using a vendor's territory.
Design the exit before the entry. Prompts, retrieval indices, fine-tuning data, evaluation sets and logs are the bank's assets. They must be exportable in a documented format, and the model must be replaceable without rewriting the applications above it. A thin abstraction over the model interface costs a week and saves a year.
What the vendor conversation should sound like
A vendor that takes the Swiss market seriously will answer the following questions in writing and without hesitation.
- In which legal territory is inference performed for our tenancy, and can that be fixed contractually?
- Which of your staff, in which countries, can access our prompts, outputs or retrieval data, under what process, and is that access logged in a way we can review?
- Are our prompts or outputs retained after the response, for how long, and are they ever used to train or evaluate models?
- Under which laws could you be compelled to disclose our data, and what would you do?
- Can you support customer-managed encryption keys, and what happens to our data if we revoke them?
- What is the documented procedure for exit, and in what format do we receive our data?
- Which sub-processors touch our data, and how are we notified when the list changes?
A vendor that answers with a link to a trust page has not answered. A vendor that says a question is unusual is not selling to banks.
What to do on Monday
- Ask for the current AI pilots to be drawn as boxes and arrows, coloured by territory and operator. Most institutions discover a colour they did not choose.
- Write the residency boundary as one sentence and circulate it to the CIO, the CRO and the general counsel for signature. It becomes the constraint every later diagram must satisfy.
- Classify the first three intended use cases by data category. Move the ones that touch client-identifying data behind the boundary; let the others proceed with the widest set of models.
- Commission the data protection impact assessment now, as a design document rather than a compliance afterthought. Done early, it is the architecture review.
- Send the seven questions above to every vendor in the current pipeline, and shorten the pipeline by the answers.