Wenn Azure nicht ausreicht

Für viele Unternehmen ist die Azure-Variante von CompanyGPT die richtige Wahl: tiefe Microsoft-365-Integration, Entra ID, AKS, fertig. Es gibt aber Branchen und Behörden, für die der Begriff “Cloud” automatisch eine Frage nach Gerichtsbarkeit, Eigentümerstruktur und Datenresidenz auslöst. Öffentlicher Sektor, Forschung, kritische Infrastruktur, Gesundheitswesen: hier reicht eine europäische Azure-Region oft nicht. Genau dafür haben wir CompanyGPT Sovereign gebaut.

Souveränität als Architekturprinzip

Souveränität ist keine Eigenschaft, die man später anbaut. Sie ist eine Architekturentscheidung, die jede Komponente betrifft. Bei CompanyGPT Sovereign haben wir das konsequent umgesetzt: Die gesamte Anwendungsplattform läuft auf STACKIT, der Cloud der Schwarz-Gruppe mit Rechenzentren in Deutschland und einer Betreibergesellschaft, die vollständig dem deutschen Recht unterliegt.

Das bedeutet keine US-Holding, kein CLOUD Act, keine Gerichtsbarkeit außerhalb der EU. Für Kunden mit echten Souveränitätsanforderungen ist das der entscheidende Unterschied zu jeder anderen Hyperscaler-Variante.

Die Architektur im Überblick

Die Plattform unterscheidet sich in mehreren Punkten klar von der Azure-Variante:

STACKIT Kubernetes Engine (SKE) als Laufzeitumgebung
PostgreSQL Flex als relationale Datenbank
MongoDB Flex für dokumentenorientierte Workloads
STACKIT Model Serving für souveräne KI-Modelle
Keycloak als selbst gehostete Identity- und SSO-Lösung
Longhorn für persistenten Cluster-Storage mit RWO und RWX
nginx-ingress mit cert-manager und Let’s Encrypt für TLS
Optional Azure AI Foundry und Google Vertex AI für ergänzende Modelle

Alle Komponenten werden über Terraform provisioniert. Es gibt kein Klickdeployment, keine manuelle Konfiguration. Jede Tenant-Umgebung ist exakt reproduzierbar.

STACKIT SKE als Laufzeit

SKE liefert managed Kubernetes mit deutscher Datenresidenz. Wir nutzen es für dieselben Workloads wie auf AKS in der Azure-Variante: Frontend, API, Worker, RAG-Connectoren, MCP-Server und Suchindex laufen als Container nebeneinander. Auf der Plattform-Ebene setzen wir auf Kubernetes-Standards: Helm Charts für Releases, NetworkPolicies für Traffic-Isolation, RBAC für Cluster-Berechtigungen.

Persistenter Storage kommt über Longhorn, das innerhalb des Clusters läuft und RWX-Volumes über NFS bereitstellt. Damit funktionieren Workloads, die geteilte Volumes brauchen, identisch zur Azure-Variante mit Azure Files. Alle Daten bleiben physisch im STACKIT-Rechenzentrum.

PostgresFlex und MongoDB Flex hinter privaten Netzwerken

Die Datenbankschicht ist bewusst auf zwei Engines aufgeteilt:

PostgreSQL Flex hält strukturierte Daten wie Identitäten, Sessions, Audit-Logs und Konfigurationen
MongoDB Flex speichert Konversationen, Memory-Einträge und dokumentenorientierte Inhalte

Beide Datenbanken sind über das STACKIT-Netzwerk erreichbar, nicht über das öffentliche Internet. Backup, Hochverfügbarkeit und Patch-Management übernimmt STACKIT als Managed Service. Aus Sicherheitssicht entspricht das funktional dem Setup mit privaten Endpoints in Azure, nur eben innerhalb der STACKIT-Welt.

Modelle: souverän zuerst, hybrid bei Bedarf

Der Modell-Layer ist der spannendste Teil der Architektur. Die Reihenfolge ist klar:

Souverän zuerst: STACKIT Model Serving liefert Mistral, Llama und Gemma direkt in Deutschland. Für viele Anwendungsfälle reicht das vollständig aus
EU als zweite Wahl: Azure AI Foundry stellt OpenAI-Modelle wie GPT-4.1 und GPT-5.1 in EU-Regionen bereit, etwa Sweden Central
Spezialmodelle aus EU-GCP: Google Vertex AI bietet Anthropic Claude und Gemini in europe-west1

Diese Reihenfolge ist bewusst. Standardanfragen laufen auf souveränen Modellen. Erst wenn ein Modell zwingend benötigt wird, das in Deutschland nicht verfügbar ist, schalten wir die EU-Hyperscaler-Modelle frei. Der Anwender sieht das Routing, der Datenschutzbeauftragte hat klare Regeln, der CISO eine nachvollziehbare Default-Position.

Embeddings für RAG nehmen wir bewusst aus Azure AI Foundry, weil hier die Qualität und Sprachabdeckung im EU-Kontext aktuell am besten ist. Auch das ist eine bewusste Entscheidung mit Begründung statt einer Out-of-the-Box-Annahme.

Identity ohne Entra ID

In der Azure-Variante ist Microsoft Entra ID das Rückgrat für SSO und Token-Propagation. Im souveränen Setup ersetzen wir das durch eine selbst gehostete Keycloak-Installation. Keycloak läuft als Pod im SKE-Cluster, nutzt PostgresFlex als Datenbank und stellt OpenID Connect für die Anwendung bereit.

Der Vorteil: Identitäten und Sessions verlassen die STACKIT-Umgebung nie. Föderation zu bestehenden Identity-Providern (Entra ID, AD FS, Active Directory, akademische IdPs wie DFN-AAI) ist möglich, aber optional. Für Kunden ohne eigene IdP-Landschaft bietet Keycloak das volle Spektrum: Benutzerverwaltung, Gruppen, MFA, Passkeys.

TLS, DNS und Netzwerk

Die Anwendung ist über nginx-ingress erreichbar. cert-manager kümmert sich automatisch um Zertifikate von Let’s Encrypt via HTTP-01 Challenge. Damit gibt es keine manuelle Zertifikatsverwaltung und keine Abhängigkeit von einem proprietären Cert-Service.

DNS und Netzwerktrennung folgen demselben Prinzip wie überall: STACKIT-Netzwerke isolieren Workloads, NetworkPolicies regeln Pod-zu-Pod-Kommunikation, externe Zugriffe gehen ausschließlich über den Ingress. Audit-Logs aus dem Cluster und den Datenbanken landen im zentralen Monitoring.

Infrastructure as Code als Pflicht

Wie bei der Azure-Variante ist alles Code. Terraform-Module beschreiben SKE, Datenbanken, Netzwerke, Keycloak, die Anwendung und alle optionalen Modell-Backends. Konfiguration pro Mandant lebt in dedizierten Werteüberschreibungen, die getrennt vom Plattform-Code versioniert werden.

Für Kunden im öffentlichen Sektor ist das mehr als ein DevOps-Komfort. Es ist ein Compliance-Argument: Jede Änderung an der Plattform ist in einem Pull Request dokumentiert, jede Genehmigung ist nachvollziehbar, jeder Stand ist rekonstruierbar. Das vereinfacht ISO-27001-, BSI-IT-Grundschutz- und C5-Audits erheblich.

Wann Sovereign, wann Azure?

Die ehrliche Antwort: nicht jeder Kunde braucht die souveräne Variante. Unsere Empfehlung:

CompanyGPT auf Azure, wenn Microsoft 365 und Entra ID das zentrale Universum sind und die EU-Region des Hyperscalers ausreicht
CompanyGPT Sovereign, wenn deutsche Datenresidenz, BSI- oder C5-Konformität, Public-Sector-Anforderungen oder Forschungsförderbedingungen explizit gefordert sind

Beide Varianten teilen sich die Anwendungsschicht. Ein späterer Wechsel ist möglich, wenn sich die Anforderungen ändern. Datenmigrationen zwischen den Datenbanken sind eingespielt.

Fazit

Souveränität ist nicht das Gegenteil von Cloud. Sie ist eine bewusste Cloud-Entscheidung. CompanyGPT Sovereign zeigt, dass ein Enterprise-fähiger KI-Stack komplett auf deutscher Infrastruktur laufen kann, ohne auf Funktionalität, Modellvielfalt oder Betriebsqualität zu verzichten. Die Kombination aus STACKIT als Basis, optional ergänzten EU-Modellen und Infrastructure as Code als Lieferweg ergibt eine Plattform, die selbst die strengsten Auditoren beruhigt.

Wenn Sie überlegen, ob Sie Azure oder Sovereign brauchen, sprechen Sie uns an. In der Regel reicht ein Workshop, um die richtige Variante zu identifizieren.

Demo anfragen oder direkt zu unseren STACKIT-Leistungen wechseln.