Digitale Souveränität als Architektur-Prinzip. Technologieentscheidungen jenseits der Cloud-Infrastruktur

Die Debatte um digitale Souveränität hat in den vergangenen Jahren erheblich an Fahrt aufgenommen. NIS2-Richtlinie, verschärfte DSGVO-Durchsetzung und geopolitische Spannungen haben IT-Verantwortliche sensibilisiert: Wer kontrolliert unsere digitale Infrastruktur? Wo liegen unsere Daten? Was passiert, wenn ein Cloud-Provider seine Preise verdoppelt oder seine Geschäftsbedingungen ändert?

Cloud-Provider, Multi-Cloud-Strategien oder Kubernetes - diese Infrastrukturaspekte sind relevant, greifen jedoch zu kurz. Denn Cloud-Abhängigkeit entsteht nicht erst bei der Wahl des Rechenzentrums, sondern bei jeder Architekturentscheidung: von der Datenbank über Identity-Services bis zur Integration von LLM-APIs. 

Eine aktuelle Bitkom-Studie zeigt, dass 90% der deutschen Unternehmen sich stark von Diensten und Technologien aus dem Ausland abhängig fühlen. Gleichzeitig ist ihr Vertrauen in US-amerikanische Anbieter "erheblich geschwächt" (37%). Doch diese Abhängigkeit entsteht nicht nur durch die Wahl eines Cloud-Providers – sie entsteht faktisch bei jeder Technologieentscheidung.

Dieser Artikel plädiert dafür, Souveränität als strategisches Architektur-Prinzip zu etablieren – gleichberechtigt neben Performance, Skalierbarkeit und Wartbarkeit. Wir entwickeln ein pragmatisches Framework, das Software-Architekten und Engineering-Verantwortlichen hilft, bewusste Entscheidungen im Spannungsfeld zwischen Time-to-Market, Kosten und Souveränität zu treffen. Denn die zentrale Erkenntnis lautet: Souveränität beginnt nicht bei der Wahl des Rechenzentrums – sie beginnt beim ersten Import.

Anatomie technischer Abhängigkeiten

Das unsichtbare Stack: Wo Cloud-Abhängigkeit beginnt

Wenn wir über Souveränität sprechen, denken wir in Schichten. Eine moderne Anwendungsarchitektur lässt sich grob in vier Ebenen unterteilen, jede mit unterschiedlichen Souveränitäts-Implikationen:

Infrastructure Layer: Hier siedeln sich die klassischen Cloud-Provider an, aber auch Kubernetes-Distributionen und Container-Runtimes. Die bisherige Souveränitäts-Debatte hat sich hier konzentriert. Die scheinbar offensichtliche Lösung: Kubernetes als Abstraktionsschicht, die Portabilität zwischen verschiedenen Cloud-Providern verspricht.

Platform Layer: Diese Ebene umfasst Datenbanken, Message Queues, Caching-Systeme, Identity-Provider und API-Gateways. Hier wird es bereits deutlich komplexer: Beispielsweise nutzen Event-Driven-Architekturen mit AWS EventBridge herstellerspezifische Features, die sich nicht 1:1 auf Apache Kafka abbilden lassen.

Application Layer: Frameworks, ORMs, HTTP-Clients, Logging-Bibliotheken – die vermeintlich harmlosen Bausteine der Anwendungen. Doch auch hier lauern Abhängigkeiten: Wenn Geschäftslogik tief in Framework-Spezifika eingebettet ist, wird eine Migration zur Herausforderung.

AI/ML Layer: Die jüngste Schicht im Stack und gleichzeitig die disruptivste. Large Language Models, Computer-Vision-APIs, Recommendation Engines – oft als Cloud-Service konsumiert. Diese Ebene unterscheidet sich fundamental von allen anderen: Sie ist nicht-deterministisch, entwickelt sich mit hoher Geschwindigkeit weiter und bettet Geschäftslogik in externe Black Boxes ein.

Jede Ebene hat ihre eigenen Lock-in-Mechanismen. Während die Infrastruktur-Ebene durch standardisierte Schnittstellen (Kubernetes APIs, S3-kompatible Object Storage) zunehmend austauschbar wird, sind die höheren Ebenen oft noch proprietärer.

Drei Dimensionen der digitalen Souveränität

Souveränität ist mehrdimensional. Wir unterscheiden drei zentrale Dimensionen, die für Architekturentscheidungen relevant sind:

Technologie-Souveränität bezeichnet die Fähigkeit, Technologien eigenständig auszuwählen, zu migrieren oder weiterzuentwickeln:

• Kann ich diese Komponente durch eine Alternative ersetzen, ohne große Teile meines Systems neu schreiben zu müssen?
• Basiert die Technologie auf offenen Standards oder proprietären Protokollen?
• Habe ich Zugang zum Quellcode und könnte ich diesen anpassen?

Ein Beispiel: Der Wechsel von PostgreSQL zu MySQL ist überschaubar – der Wechsel von DynamoDB zu einer relationalen Datenbank erfordert fundamentale Architektur-Änderungen.

Know-how-Souveränität fokussiert auf die Fähigkeit, kritische Betriebsabläufe jederzeit eigenständig durchführen zu können:

• Verfügt unser Team über das Wissen, diese Technologie zu betreiben, zu entstören und weiterzuentwickeln?
• Ist dieses Wissen ausreichend dokumentiert und verteilt?
• Können wir im Notfall auf externe Expertise zugreifen?

Managed Services reduzieren operative Know-how-Anforderungen kurzfristig, schaffen aber langfristig Abhängigkeit. Wenn niemand im Team mehr versteht, wie die zugrundeliegende Technologie funktioniert, wird ein Vendor-Wechsel zur existenziellen Herausforderung.

Datensouveränität umfasst die Kontrolle über Speicherort, Zugriff und Verwendung von Daten:

• Wo werden die Daten physisch gespeichert und verarbeitet?
• Wer kann unter welchen Umständen auf die Daten zugreifen (inkl. Provider, Behörden)?
• Wie aufwändig ist ein vollständiger Datenexport in ein nutzbares Format?
• Gibt es Vendor Lock-in durch proprietäre Datenformate oder APIs?

Die Datensouveränität ist besonders bei SaaS-Lösungen und Cloud-Services kritisch. Ein konkretes Beispiel: Ein Unternehmen nutzt einen Cloud-basierten Analytics-Service und reichert dort über Jahre Daten mit Custom-Modellen an. Die Rohdaten lassen sich exportieren – aber die trainierten Modelle und Konfigurationen sind proprietär und nicht übertragbar.

Die versteckten Kosten von Vendor Lock-in

Lock-in manifestiert sich auf verschiedenen Ebenen:

Expliziter Lock-in ist die offensichtlichste Form: Die Nutzung proprietärer APIs, Vendor-spezifischer Features oder geschlossener Protokolle. Beispiele:

• AWS Lambda mit EventBridge-Integration statt Standard-HTTP-Triggern
• Azure-spezifische AD-Integration statt OIDC-Standard

Diese Abhängigkeiten sind dokumentiert, oft sogar bewusst eingegangen. Der Trade-off ist klar: höhere Geschwindigkeit und bessere Integration gegen geringere Portabilität.

Impliziter Lock-in ist tückischer, weil er sich schleichend entwickelt:

Ökosystem-Effekte: Die Entscheidung für AWS Lambda führt zur Nutzung von CloudWatch für Monitoring, IAM für Berechtigungen, Secrets Manager für Credentials. Jede Komponente für sich wäre ersetzbar – das Gesamtsystem ist es nicht mehr.

Data Gravity: Je mehr Daten in einem System akkumulieren, desto schwieriger wird die Migration. Nicht nur wegen des Volumens, sondern wegen der Verknüpfungen, Indizes, Zugriffsmuster und historisch gewachsenen Strukturen.

Team-Spezialisierung: Das Engineering-Team wird zu AWS-Experten. Sie kennen Best Practices, Optimierungen, Workarounds. Ein Wechsel zu Azure würde nicht nur Systeme, sondern auch das Team-Know-how entwerten.

Transitive Abhängigkeiten: Eine scheinbar harmlose Library zieht weitere Abhängigkeiten nach sich, die wiederum eigene Lock-ins mitbringen. Package-Manager zeigen oft Hunderte transitiver Abhängigkeiten – ein Flickenteppich potenzieller Souveränitäts-Risiken.

Kubernetes als Schlüsseltechnologie verdient besondere Beachtung, da es oft als Allheilmittel für Portabilität gepriesen wird. Die Realität muss differenzierter betrachtet werden:

Kubernetes standardisiert die Container-Orchestrierung, indem es Workload von Infrastruktur abstrahiert und über eine generische Schnittstelle automatisieren lässt. Ein weiterer Vorteil ist, dass sich auf Basis von Kubernetes portable Ökosysteme zu spezifischen Plattformen entwickeln lassen. So wird eine organisationseigene Cloud-Plattformen möglich, die mit Features wie Self-Service, Service-Katalog, Transparenz und Nachvollziehbarkeit, Deployment-Mechanismen, Ende-zu-Ende Automatisierung und automatisch provisionierbaren Managed Services aufwarten kann. 

Aber in der Praxis entstehen hierdurch neue Herausforderungen:

Distributionsspezifische Unterschiede: EKS, AKS und GKE sind zwar alle "Kubernetes“, unterscheiden sich aber in den Details.

Ökosystem-Komplexität: Eine produktive Kubernetes-Plattform besteht aus Dutzenden zusätzlichen Komponenten, die oft stärker binden als die Kubernetes-Distribution selbst. 

Operator-Pattern: Immer mehr Anwendungen werden als Kubernetes-Operators deployed. Diese sind zwar portabel, aber oft optimiert für spezifische Distributionen oder Cloud-Provider.

Managed vs. Self-Hosted: Die Entscheidung zwischen EKS und selbst gehostetem Kubernetes ist eine fundamentale Souveränitäts-Entscheidung – trotz identischer APIs.

Kubernetes löst also Portabilität auf der Infrastruktur-Ebene, schafft aber neue Komplexitäten. Der Aufwand für das Lifecycle Management von Kubernetes ist signifikant. Das dafür notwendige Know-how ist teuer. Viele interdependente Services und Bestandteile müssen aufeinander abgestimmt werden und über die Lebenszeit gewartet werden. 

Fazit: Kubernetes ist ein Werkzeug für Souveränität – nicht ihre Garantie.

Das Spannungsfeld: Geschwindigkeit, Kosten, Souveränität

Zielkonflikt: Geschwindigkeit, Kosten und Cloud-Souveränität

Architekturentscheidungen sind immer ein Balanceakt zwischen konkurrierenden Zielen. Neben den qualitativen Zielen wie Skalierbarkeit, Performance, Sicherheit und Wiederverwendbarkeit gilt es den Konflikt der folgenden drei Ziele abzuwägen und aufzulösen: 

Time-to-Market (Geschwindigkeit): Wie schnell können Funktionalität ausgeliefert werden? Managed Services und SaaS-Lösungen bieten hier klare Vorteile: Geringe Setup-Zeit, keine Infrastruktur-Komplexität, Out-of-the-Box-Features, das Lifecycle Management outgesourct. Ein Identity-Provider wie Auth0 ist in Stunden integriert – eine selbst gehostete Keycloak-Instanz benötigt Tage bis Wochen.

Total Cost of Ownership (TCO): Die Gesamtkosten über den Lebenszyklus einer Lösung. TCO -Betrachtungen streben nach einer ganzheitlichen Perspektive, die über die Summierung der direkten Kosten hinausgeht. Hierbei ist die Rechnung oft kontraintuitiv: Ein scheinbar teurer Managed Service kann TCO-günstiger sein als eine "kostenlose" Open-Source-Alternative, wenn man Betriebskosten und Know-how-Aufbau mit betrachtet.

Souveränität: Die Fähigkeit, selbstbestimmt über Technologie, Betriebsbereitschaft (Know-how) und Daten zu verfügen. Wie im Abschnitt zu den drei Dimensionen der Souveränität ausgeführt, ist dies eine mehrdimensionale Größe.

Diese drei Ziele stehen in einem Spannungsverhältnis, das sich in einer Matrix darstellen lässt:

Zielmatrix: Geschwindigkeit, Kosten, Souveränität

Wichtig ist die Erkenntnis: Es gibt keine objektiv "richtige" Wahl. Die optimale Entscheidung hängt vom Kontext ab.

Ein pragmatisches Entscheidungsmodell

Um diese komplexen Zielkonflikte systematisch zu bewerten, schlagen wir ein dreistufiges Entscheidungsmodell vor:

Stufe 1: Kontext-Analyse

Bevor wir Technologien vergleichen, müssen wir den strategischen Kontext klären:

1. Geschäftliche Differenzierung: Ist diese Komponente differenzierend für das Geschäftsmodell? 
2. Kritikalität: Wie geschäftskritisch ist diese Komponente? 
3. Erwartete Lebensdauer: Wie lange wird diese Lösung voraussichtlich im Einsatz sein?
4. Regulatorische Anforderungen: Welche Compliance-Vorgaben gelten? (DSGVO-relevante personenbezogene Daten, NIS2-kritische Infrastruktur, branchenspezifische Regularien wie BAIT, KRITIS, etc.)

Diese vier Dimensionen spannen einen Entscheidungsraum auf. Eine Komponente, die geschäftsdifferenzierend, hochkritisch, langlebig und reguliert ist, stellt höhere Anforderungen an Souveränität. Eine Commodity-Komponente für einen taktischen Use Case kann mit starkem Vendor Lock-in leben.

Stufe 2: Ziel-Bewertung

Für jede betrachtete Technologie-Option bewerten wir nun systematisch die drei Hauptziele:

Time-to-Market:

• Wie schnell können wir eine produktionsreife Lösung aufsetzen?
• Wie lange dauert die Integration in bestehende Systeme?
• Wie schnell können wir neue Features nutzen?

TCO (Total Cost of Ownership):

• Direkte Kosten: Lizenzen, Cloud-Ressourcen, Support-Verträge
• Personalkosten: für Entwicklung, Betrieb und auch die Wartung
• Know-how-Aufbau: Trainings, Zertifizierungen, Lernkurve
• Opportunitätskosten: Was entgeht uns, weil Ressourcen gebunden sind?
• Exit-Kosten: Was würde eine spätere Migration kosten?

Souveränität:

• Migrationsfähigkeit: Wie stark ist der Vendor Lock-in? Basiert sie auf Standards?
• Kontrollierbarkeit: Wie transparent ist die Technologie? Können wir debuggen, anpassen, erweitern? 
• Risikominimierung: Wie abhängig sind wir von einem Vendor? Was passiert bei dessen Ausfall oder Preiserhöhung?

Stufe 3: Heuristische Entscheidungsregeln

Basierend auf der Kontext-Analyse und Dimensionen-Bewertung können wir Heuristiken formulieren:

Entscheidungsheuristik

Wichtig: Diese Regeln sind Heuristiken, keine Gesetze. Sie bieten Orientierung, ersetzen aber nicht die kontextspezifische Abwägung.

Open Source und Open Weight Modelle: Der Mittelweg bei AI/ML

Die Diskussion um digitale Souveränität im KI-Bereich wird oft auf die Dichotomie "proprietäre APIs vs. selbst gehostete Modelle" reduziert. Doch es gibt einen wichtigen Mittelweg, der in der Praxis zunehmend relevant wird: Open Weight Modelle.

Open Source vs. Open Weight: Während echte Open-Source-Modelle sowohl Modellgewichte als auch Trainingscode und die zu Grunde liegenden Trainingsdaten offenlegen (z.B. Mistral, Olmo), beschränken sich Open Weight Modelle auf die Veröffentlichung der Modellgewichte (z.B. Llama, Qwen). Der Trainingsprozess bleibt proprietär.

Souveränitäts-Perspektive:

Technologie-Souveränität: Open Weight Modelle bieten vollständige Kontrolle über Inferenz und Deployment. Fine-Tuning ist möglich, aber die Reproduzierbarkeit des Trainings ist eingeschränkt. Dennoch: deutlich höhere Souveränität als bei proprietären APIs.

Know-how-Souveränität:Das Betreiben erfordert ML-Ops-Expertise (Modell-Deployment, Optimierung, Monitoring), aber der Lernaufwand ist geringer als bei Training von Grund auf. Die Community bietet umfangreiche Dokumentation und Tooling (vLLM, Ollama, llama.cpp).

Datensouveränität:Vollständige Kontrolle: Daten verlassen nie die eigene Infrastruktur. Keine Abhängigkeit von Vendor-Policies bezüglich Datennutzung, Retention oder Zugriff.

Praktische Überlegungen:

Lizenzmodelle beachten: Llama hat Nutzungsbeschränkungen bei >700M monatlichen Nutzern. Mistral und andere bieten Apache 2.0-Lizenzen ohne solche Einschränkungen. Die Lizenzwahl beeinflusst langfristige Souveränität erheblich.

Performance-Gap akzeptieren:Open Weight Modelle liegen typischerweise 6-12 Monate hinter State-of-the-Art proprietären Modellen (GPT-5, Claude Sonnet 4.6 oder Opus). Für viele Use Cases ist die Performance dennoch ausreichend – insbesondere bei domänenspezifischem Fine-Tuning.

Infrastruktur-Investition:Das Hosting eines Llama-4-109B-Modells erfordert mindestens eine H200-GPU (ca. €2.500-9.000/Monat Cloud-Kosten; je nach Anbieter und geographischer Region) plus ML-Engineering-Kapazität. Dazu kommt die Lernkurve für Prompt-Optimierung, da Open-Source-Modelle oft andere Prompting-Strategien erfordern als GPT.

Quantisierung als Enabler:Moderne Quantisierungstechniken ermöglichen es, größere Modelle auf Consumer-Hardware zu betreiben. Ein quantisiertes Llama-3-70B läuft auf 2× RTX 4090 – das demokratisiert den Zugang erheblich.

Strategische Empfehlung:

Hybrid-Ansatz mit Abstufung:

• Prototyping & nicht-kritische Use Cases: Proprietäre APIs (GPT, Claude) für maximale Velocity
• Production & Standard-Tasks: Open Weight Modelle self-hosted (Llama, Mistral) für Balance zwischen Performance und Souveränität
• Hochsensible Daten & Compliance: Fine-tuned Open Weight Modelle on-premise mit strengen Zugriffskontrollen
• Commodity-Tasks (z.B. Klassifikation, einfache Extraktion): Kleine Modelle (Llama-3-8B, Mistral-7B) – oft überraschend leistungsfähig bei spezifischem Fine-Tuning

Die Landschaft entwickelt sich rasant: Was heute noch proprietär ist, kann morgen als Open Weight verfügbar sein. Unternehmen sollten ihre Architektur so gestalten, dass ein Wechsel zwischen Modell-Typen mit vertretbarem Aufwand möglich bleibt – etwa durch Abstraktion über Frameworks wie LangChain oder Semantic Kernel, kombiniert mit eigenem Prompt-Management.

Fazit: Open Weight Modelle sind kein Kompromiss, sondern oft der pragmatischste Weg zu AI-Souveränität. Sie bieten 80-90 % der Capabilities proprietärer Modelle bei deutlich höherer Kontrolle und ohne die existenziellen Vendor-Risiken. Für die meisten Unternehmens-Use-Cases ist das der Sweet Spot.

Fazit

Souveränität ist kein binärer Zustand, sondern der Prozess auf einem Kontinuum Trade-off-Entscheidungen anzustellen. Es gibt keine universell „richtige“ Entscheidung. Die optimale Balance zwischen Time-to-Market, Kosten und Souveränität hängt vom Kontext ab.

Wichtiger als die einzelne Technologieentscheidung ist die Etablierung einer Souveränitäts-Kultur in der Engineering-Organisation.

Besonders relevant wird dies im Kontext von AI/ML: Large Language Models stellen unsere bisherigen Souveränitäts-Konzepte vor neue Herausforderungen. Die Infrastruktur-Debatte ist wichtig – aber wie gezeigt unvollständig. Souveränität ist ein kontinuierlicher Prozess, der ständige Abwägungen erfordert. Dieser Artikel erweitert diese Perspektive: Jede Technologieentscheidung ist eine Souveränitätsentscheidung. Das oben erwähnte 3-Stufenmodell hilft, diese Entscheidungen bewusst zu treffen, statt unbewusst abhängig zu werden.

Call-to-Action für Software-Architekten:

1. Inventarisieren Sie Ihre Abhängigkeiten: Erstellen Sie eine SBOM (Software Bill of Materials) – nicht nur für Security, sondern für Souveränität.

2. Bewerten Sie Ihr Souveränitäts-Portfolio: Welche Komponenten sind kritisch und differenzierend? Wo sind die größten Vendor Lock-in-Risiken?

3. Definieren Sie Exit-Strategien: Für Ihre Top-5-Abhängigkeiten: Was wären die Alternativen? Was würde ein Wechsel kosten?

4. Etablieren Sie Souveränitäts-Audits: Halbjährlich: Wo haben sich Risiken verändert? Wo sollten wir nachsteuern?

5. Nutzen Sie das Entscheidungsmodell: Bei der nächsten Technologieentscheidung: Kontext, Dimensionen, Heuristiken – systematisch abwägen.

Souveränität ist kein Luxus, den sich nur Konzerne oder öffentliche Einrichtungen leisten können. Es ist eine strategische Notwendigkeit für jede Organisation, die langfristig handlungsfähig bleiben will. Die Frage ist nicht, ob wir uns mit Souveränität beschäftigen – sondern wie bewusst und systematisch wir es tun.

Die Infrastruktur-Schicht haben wir im Griff – jetzt ist es Zeit, die Souveränitäts-Diskussion auf die Ebene zu heben, wo sie hingehört: in die Software-Architektur, ins Design, in jede Technologieentscheidung. Denn Souveränität beginnt beim ersten Import.

Souveränitäts-Strategie im Experten-Call klären

Die fünf Handlungsempfehlungen oben zeigen den Weg, erfordern aber oft mehr Know-how und Kapazitäten, als IT-Teams im Unternehmensalltag aufbringen können. Wenn Sie Unterstützung oder Starthilfe suchen, nutzen Sie unseren kostenfreien Experten-Call: 60 Minuten, cloud-neutral, ohne Verkaufsdruck. Im offenen Austausch ordnen wir Ihre aktuellen Abhängigkeiten ein, identifizieren kritische Lock-in-Risiken in Ihrer Architektur und entwickeln Ideen für Ihre ersten konkreten Schritte. Sie erhalten individuelle Empfehlungen, die zu Ihrer Ausgangslage, Ihren Compliance-Anforderungen und Ihren Ressourcen passen.