Allgemein Sovereignty

Warum „Buy European“ nicht reicht: Was die Schweiz bei der digitalen Souveränität wirklich tun sollte

29. Juni 2026

Als die EU ihr Cloud Sovereignty Framework veröffentlichte und im April 2026 Cloud-Aufträge über 180 Millionen Euro an vier europäische Anbieter vergab, sah das nach einem klaren Sieg für die digitale Souveränität aus. Doch am Swiss Software Festival 2026 in Basel lieferte die UCL-Ökonomin Cecilia Rikap eine schärfere Analyse: Geografische Souveränität ist notwendig, aber nicht ausreichend. Das tiefere Problem nennt sie Epistemic Capture. „Epistemisch“ bedeutet: das Wissen und die Kategorien betreffend, mit denen wir die Welt ordnen. Die Idee ist einfach: Der Fuchs hat den Hühnerstall mitentworfen. Hyperscaler prägen die Regeln, Definitionen und Kategorien des Souveränitätsspiels, selbst wenn sie scheinbar verlieren.

Ich sprach am selben Anlass über die Engineering-Vorteile der Schweiz im KI-Zeitalter und möchte Rikaps akademisches Argument mit dem verbinden, was ich täglich beim Betrieb von Infrastruktur für regulierte Schweizer Unternehmen erlebe: die Lücke zwischen Souveränität als politischem Ziel und Souveränität als Engineering-Praxis.

Das Souveränitäts-Framework funktioniert. Einigermassen.

Das SEAL-Framework der EU bewertete Anbieter in acht Dimensionen. Drei rein europäische Anbieter erreichten SEAL-3. Proximus, dessen Konsortium Google Cloud (über das S3NS-Joint-Venture mit Thales) einschloss, erreichte nur SEAL-2. Das Framework bestrafte die Beteiligung von Hyperscalern korrekt. Wir haben das Framework analysiert und VSHN daran gemessen, eine nützliche Übung für jeden Anbieter, der Souveränität ernst meint.

Das Wichtigste an diesem Framework sind nicht die Ergebnisse selbst. Entscheidend ist, dass Souveränität nicht mehr eine binäre, emotionale Debatte ist („Sind wir souverän oder nicht?“). Sie ist jetzt messbar über acht Dimensionen, die man diskutieren, planen und priorisieren kann. Das verändert das Gespräch von Ideologie zu Engineering.

Aber Rikaps Argument lautet: Microsoft, Google und Amazon waren auf dieses Framework vorbereitet, bevor es veröffentlicht wurde. Sie hatten bereits Joint Ventures, lokale Tochtergesellschaften und Partnerschaftsmodelle aufgebaut, die darauf ausgelegt waren, bei Souveränitätsbewertungen gut abzuschneiden. Das Framework hat sie nicht überrascht. Sie haben die Rahmenbedingungen mitgestaltet, in denen es geschrieben wurde.

Das ist Epistemic Capture: Wenn die regulierten Unternehmen die Kategorien, Definitionen und Prioritäten der Regulierung selbst beeinflussen. Das Ergebnis sind Souveränitäts-Frameworks, die die Symptome behandeln (Datenstandort, Rechtsordnung), ohne die Grundursache anzugehen (die Kontrolle über den Technologie-Stack und seine Entwicklung).

Wie Epistemic Capture in der Praxis aussieht

Google, Amazon und Microsoft kontrollieren zusammen rund 65% des globalen Cloud-Marktes, dazu die Unterseekabel, die ihn verbinden. Rikap beschrieb KI als „Trojanisches Pferd“: Organisationen nutzen KI-Dienste, die auf Hyperscaler-Infrastruktur laufen, und schaffen Abhängigkeiten, die tiefer gehen als der Speicherort der Daten:

  • Black-Box-Modelle: Man nutzt die API, ohne Zugang zu den Modellgewichten, Trainingsdaten oder Architekturentscheidungen zu haben. Die eigene KI-Strategie hängt von einem Anbieter ab, den man nicht prüfen kann.
  • Ökosystem-Lock-in: Sobald Datenpipeline, ML-Training und Inferenz auf dem Stack eines Hyperscalers laufen, bedeutet ein Wechsel Neuaufbau, nicht bloss Migration.
  • Datengravitation: KI-Modelle brauchen Daten, Daten ziehen Services an, Services ziehen mehr Daten an. Dieser selbstverstärkende Kreislauf macht KI zu einer der grössten zentralisierenden Kräfte unserer Branche. Die Daten sind schon da, das Ökosystem der Tools ist schon da, und jede neue Integration macht die nächste schwerer anderswo zu platzieren.
  • Standards-Capture: Hyperscaler finanzieren und besetzen die Normierungsgremien, die Cloud-Native-Computing definieren. Die „neutralen“ Standards beinhalten oft Annahmen, die ihre Architekturen begünstigen.

Ein europäisches Unternehmen, das Mistral AI auf Azure betreibt, ist nicht souverän, nur weil Mistral französisch ist. Das KI-Modell sitzt in einem von Microsoft kontrollierten Ökosystem, unterliegt US-Recht und ist von Nvidias Hardware-Lieferketten abhängig.

„Buy European“ und „Buy Swiss“ greifen zu kurz

Rikap warnte ausdrücklich davor, US-Big-Tech durch europäische Big-Tech zu ersetzen. Dass SAP, Siemens und Mistral europäisch sind, macht sie noch nicht zu souveränen Alternativen. Sie betreiben dieselben Geschäftsmodelle (Plattformdominanz, proprietärer Lock-in, Rentenextraktion), einfach unter einer anderen Flagge.

Dieselbe Logik gilt für „Buy Swiss“. Die Schweiz hat echte strukturelle Vorteile für die Souveränität (dazu weiter unten mehr), aber eine Schweizer Flagge auf der Rechnung ist keine Souveränität. Ein Schweizer Unternehmen, das Azure mit lokalem Support weiterverkauft, bietet keine operative Unabhängigkeit. Ein Schweizer SaaS-Anbieter auf AWS eu-central-1 schützt nicht vor dem CLOUD Act. Die Frage ist nicht, wo der Anbieter seinen Hauptsitz hat. Die Frage ist, ob man den Anbieter wechseln kann, ohne die Technologie zu wechseln.

Chinas Ansatz (staatlich orchestrierte KI-Industrialisierung) ist ebenfalls kein Vorbild. Wie Rikap feststellte, „reproduziert er die Logiken US-geführter Raubtier-Ökosysteme, ohne sie in Frage zu stellen.“ Techno-Nationalismus ist keine Souveränität, egal ob die Nation die USA, China oder die Schweiz ist.

Was echte Souveränität erfordert

Wenn geografische Herkunft und nationale Champions nicht ausreichen, wie sieht echte Souveränität dann aus? Basierend auf Rikaps Analyse und meiner Erfahrung mit dem Betrieb von Produktionsinfrastruktur für Schweizer Banken, Gesundheitsdienstleister und Behörden sind drei Bedingungen entscheidend:

1. Open-Source-Grundlagen

Open Source ist das einzige Technologiemodell, bei dem man überprüfen kann, was die Software tut, sie an die eigenen Bedürfnisse anpassen und den Betreiber wechseln kann, ohne alles neu aufzubauen. Die Umfrage der Linux Foundation von 2025 ergab, dass 83% der Unternehmen Open Source als wertvoll für ihre Zukunft ansehen. Thomas Wüst (CEO von ti&m), ebenfalls Redner am SSF 2026, beschrieb, wie ti&m die eigenen Unternehmenssysteme auf einen Open-Source-Stack migriert hat, nachdem die Kosten durch Vendor-Lock-in eskalierten.

Das ist kein Idealismus. Es ist Risikomanagement. Als HashiCorp die Terraform-Lizenz änderte und an IBM verkaufte, spaltete die Community innerhalb von Monaten OpenTofu unter der Linux Foundation ab. Als Atlassian Jira-Kunden von Server über Data Center zu Cloud zwang, berichtete Wüst, dass die Lizenzkosten von ti&m zwischen 2023 und 2027 um rund 900% stiegen. Open Source macht solche erzwungenen Migrationen strukturell unmöglich.

EU und Schweiz bewegen sich beide in Richtung Open Source als Staatspolitik. Der Schweizer Ständerat hat im Juni 2026 eine Motion für ein Impulsprogramm zur digitalen Souveränität angenommen. Die Schweiz hat mit EMBAG bereits seit 2024 ein Bundesgesetz, das die Verwaltung verpflichtet, sämtliche Eigenentwicklungen als Open Source zu veröffentlichen, sofern kein spezifischer Grund dagegen spricht. Die Open-Source-Strategie der EU positioniert Open Source als zentral für die technologische Souveränität. Das sind keine Nischenpositionen. Es ist ein sich formierender Konsens.

2. Operative Kontrolle statt nur Datenstandort

Das EU-Framework trifft mit der Dimension „Operational Sovereignty“ (SOV-4) teilweise ins Schwarze. Aber die gängige Marktinterpretation lautet „europäisches Personal, das in europäischen Rechenzentren arbeitet.“ Das greift zu kurz.

Operative Kontrolle bedeutet: Kann man den Betreiber wechseln, ohne die Technologie zu wechseln? Wenn das verwaltete Kubernetes auf Red Hat OpenShift oder Upstream-Kubernetes mit dokumentierten APIs läuft, kann man den Betreiber wechseln. Wenn es auf Amazon EKS, Azure AKS oder Google GKE läuft, nutzt man eine proprietäre Steuerungsebene mit cloudspezifischen Integrationen, die nicht übertragbar sind. Die Kubernetes-API ist portabel. Die verwalteten Wrapper darum herum sind es nicht.

Das ist kein theoretisches Problem. Wer der FINMA-Regulierung untersteht, muss einen dokumentierten Prozess vorweisen, um innerhalb von 12 Monaten von jedem Anbieter weg migrieren zu können, sonst ist man nicht compliant. Portabilität ist für regulierte Schweizer Organisationen keine Option. Es ist eine gesetzliche Anforderung.

Das meine ich mit „Wer kontrolliert die Laufzeitumgebung?“, die Frage, die ich in meiner SSF-Keynote gestellt habe. KI macht die Codegenerierung nahezu kostenlos. Die Grenzkosten der Softwareentwicklung sinken rapide. Aber die Komplexität hat sich verschoben: hin zu Architektur, Plattformen und Sicherheit. Die Ebene, die über die eigene Unabhängigkeit entscheidet, ist nicht mehr der Anwendungscode. Es ist die Plattform darunter.

Die Schweiz hat hier einen strukturellen Vorteil. Die Kombination aus regulierten Branchen (die hybride Architekturen erfordern), Open-Source-Kompetenz und vertrauenswürdigen regionalen Cloud-Anbietern (Cloudscale, Exoscale) schafft ein praxistaugliches Multi-Cloud-Ökosystem, in dem operative Portabilität der Standard ist. Wir bauen diese Art von Infrastruktur bei VSHN seit 2014, nicht weil Souveränität modisch war, sondern weil unsere Kunden in Banken, Gesundheitswesen und Verwaltung sie brauchten.

3. Governance statt Geografie

Rikaps stärkstes Argument: Souveränität ist eine Frage der Governance und der demokratischen Rechenschaftspflicht, nicht des Territoriums oder der Nationalität. Wer bestimmt die Technologie-Roadmap? Wer hat Zugriff auf die Daten? Welche Möglichkeiten haben die Nutzer, wenn sich die Plattform ändert?

Für Organisationen, die Cloud-Anbieter evaluieren, übersetzt sich das in konkrete Fragen:

  • Ist der Quellcode des Anbieters prüfbar?
  • Kann man denselben Stack mit einem anderen Betreiber nutzen?
  • Was passiert mit den eigenen Daten und dem Betrieb, wenn der Anbieter übernommen wird?
  • Werden Preise und Konditionen von einem stabilen Rechtsrahmen (Schweizer Recht, EU-Recht) bestimmt oder vom Quartalsdruck eines Anbieters?

Das Schweizer Recht liefert auf mehrere dieser Fragen starke Antworten: kein CLOUD Act, EU-Angemessenheitsbeschluss für den Datenschutz, stabiles Handelsrecht. Aber Schweizer Recht allein reicht nicht, wenn der darunter liegende Technologie-Stack von einem US-Unternehmen kontrolliert wird. Governance erfordert sowohl rechtliche als auch technische Unabhängigkeit.

Die Schweizer Chance und die Schweizer Lücke

Die Schweiz ist gut positioniert, aber Positionierung ist nicht dasselbe wie Handeln. Am SSF 2026 zog sich ein Thema durch alle Keynotes: Die Schweizer IT versteht Souveränität, hat aber souveräne Alternativen noch nicht schnell genug skaliert.

Die Zahlen sprechen für sich. Über 70% der Schweizer Unternehmen investieren weniger als 5% ihres IT-Budgets in KI (ti&m/HSLU AI Maturity Study 2026). Gleichzeitig berichtete Penny Schiffer von UBS, dass die Bank bereits über 300 KI-Anwendungsfälle produktiv betreibt und ihren ersten Chief AI Officer ernannt hat. Die Kluft zwischen den Vorreitern und der Mehrheit wächst, und damit das Risiko, dass die Mehrheit standardmässig von Hyperscaler-KI-Diensten abhängig wird, statt sich bewusst dafür zu entscheiden.

Der nächste praktische Schritt ist nicht, auf Regulierung oder nationale Champions zu warten. Es geht darum, auf dem aufzubauen, was bereits existiert: Open-Source-Software, in der Schweiz betriebene Infrastruktur und Engineering-Teams mit der Erfahrung, Plattformen zu entwerfen, die kein einzelner Anbieter kontrolliert.

Die Schweiz baut seit Jahrhunderten Präzisionsmaschinen. Die nächste Maschine, die es zu bauen gilt, ist die souveräne Plattform: Open Source, Multi-Cloud, operativ portabel und dem Schweizer Recht unterstellt. Die Komponenten existieren. Das Engineering-Talent existiert. Was fehlt, ist die Entscheidung, sie zusammenzubauen.

Die Frage ist nicht, welche Cloud man wählt. Die Frage ist, ob die eigene Architektur einem diese Wahl auch morgen noch lässt. Wer abhängig ist, muss um Erlaubnis fragen. Wer souverän ist, kann liefern.


VSHN betreibt seit 2014 Open-Source-Infrastruktur für regulierte Schweizer Organisationen. Wir sind der erste CNCF Kubernetes Certified Service Provider der Schweiz, Red Hat Premier Partner und Linux Foundation Silver Member. Unsere Managed Services laufen auf Schweizer Cloud-Anbietern, unter Schweizer Recht, auf Open-Source-Basis und ohne Hyperscaler-Abhängigkeit. Vereinbare ein Beratungsgespräch, um eure Souveränitätsanforderungen zu besprechen.

Aarno Aukia

Aarno ist Mitgründer der VSHN AG und als CTO für die technische Begeisterung zuständig.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt