A Swiss server is not enough: Jurisdictional Integrity for enterprise AI

“Hosted in Switzerland” is useful information. It is not yet an architecture.

An AI service can run on a server in Zurich while its control plane, telemetry, backups, model endpoint or support team sits elsewhere. Encryption can protect data in transit while a foreign provider still controls the keys. A contract can name a Swiss region while an undeclared subprocessor remains in the path.

That does not automatically make the service unlawful or unsafe. It does mean that data residency alone cannot answer the question a board, risk owner or client is really asking:

Can we prove who controls every material part of this system, under which legal order, and what happens when something goes wrong?

At Operal, we call the engineering answer Jurisdictional Integrity.

Sovereignty answers “where”. Integrity goes further.

Jurisdictional Integrity is the deliberate alignment of a digital system’s data, compute, model, access, evidence and accountability inside a defensible control perimeter.

It tests six practical questions:

Where do inputs, outputs, inference, logs and backups actually go?
Which legal entities can operate the service or be compelled to provide access?
Who controls privileged identities and encryption keys?
Are all subprocessors and model dependencies known and governed?
Can a material output be traced to its sources, controls and human owner?
Can the organisation restore, move or exit the service without losing its data or evidence?

The result is not isolation for its own sake. It is a system whose operating reality matches the promises made in a privacy notice, outsourcing register, risk assessment and client conversation.

Why this matters now—especially in finance

AI adoption has moved faster than many institutions’ control structures. In April 2025, FINMA reported that around half of the roughly 400 institutions it surveyed were already using AI or developing initial applications. Of the AI users, 91% used generative AI. FINMA highlighted data quality, data protection, explainability, correctness and outsourcing among the priority risks.

That last point is easy to underestimate. An AI assistant is rarely a single supplier. It can include an application host, foundation-model API, vector database, observability service, document parser and support tooling. Each dependency adds another possible data path, operator and failure mode.

FINMA’s position on outsourcing is unambiguous: responsibility for the proper performance of an outsourced function stays with the institution. Its 2025 Risk Monitor also places growing third-party dependence and concentration among the operational risks institutions must manage.

The legal baseline reaches beyond supervised finance. The Swiss FADP already applies to AI-supported processing of personal data, as the FDPIC reiterated in May 2025. For disclosure abroad, the destination, safeguards, exceptions, transparency and processing inventory all matter; the FDPIC provides a current cross-border transfer guide.

Switzerland still has no overarching AI-specific act as of August 2026. A consultation draft to implement the Council of Europe AI Convention is expected by the end of 2026. That is not a reason to wait: current data-protection, sector, contract and governance duties continue to apply. Swiss organisations serving the EU must also assess the EU AI Act’s territorial scope and role-specific obligations.

What Operal builds

We turn Jurisdictional Integrity from a policy sentence into a working system. The exact architecture depends on the use case and risk tolerance, but our default pattern has four layers.

1. Map the real processing chain

We begin with data classes, flows, suppliers, subprocessors, model calls, administrative access and retention. “No data leaves Switzerland” is only a useful claim when the diagram includes logs, backups, support and failure paths—not just the primary database.

2. Build the sovereign foundation

Where the risk case calls for it, data and inference run on Swiss-hosted infrastructure with self-hosted open-weight models and tightly governed access. Live source data can remain in the client’s system of record. Dedicated deployments and customer-controlled boundaries reduce hidden shared-service dependencies.

3. Make every answer accountable

Location does not make an AI answer correct. We add source grounding, validation, versioned prompts and models, human approval at material decision points, and an audit trail that shows what the system saw and why an output was accepted.

Our rule is simple: no source, no answer; no accountable owner, no automated decision.

4. Engineer for change and exit

Models improve. Providers change. Regulation develops. A defensible system must be portable by design: exportable data, documented configurations, replaceable components, tested restoration and clear deletion evidence. Sovereignty without an exit path is just a different form of lock-in.

The outcome: a smaller trust gap

For a bank, insurer or asset manager, this creates evidence that risk, compliance and internal audit can inspect. For healthcare, public services and professional firms, it creates a clear answer when clients ask where sensitive information went. For any enterprise, it reduces the gap between what the organisation says about AI and what the stack actually does.

Jurisdictional Integrity does not mean every workload must use the same deployment. A public marketing assistant and a client-facing financial copilot do not carry the same risk. The principle is proportionality: make the architecture, controls and evidence as strong as the consequence of failure.

The best time to establish that perimeter is before a pilot becomes critical infrastructure. The second-best time is before the next supplier review.