Seit der Bund im Mai 2026 den Zuschlag für eine souveräne KI-Plattform der Bundesverwaltung erteilt hat – mit STACKIT als Cloud-Basis –, steht der Begriff souveräne KI-Plattform in fast jeder Ausschreibung. Was dabei oft fehlt, ist die Architekturebene: Welche Services laufen wo, wie greifen sie ineinander, wo liegen Identitäten und Rechte, wie kommt ein Modell an seine Anfragen, und wie lässt sich das gegenüber Datenschutz, Informationssicherheit und KI-Verordnung nachweisen?
Dieser Beitrag beantwortet genau das für CompanyGPT Sovereign, die STACKIT-Variante unserer KI-Plattform CompanyGPT, die seit Kurzem im STACKIT Marketplace gelistet ist. Er richtet sich an IT-Leitungen, Architektinnen, Datenschutz- und Informationssicherheitsbeauftragte in der öffentlichen Verwaltung, bei Betreibern von Fachverfahren und im Mittelstand.
Einen kürzeren Überblick zur Motivation gibt es bereits auf innfactory.de. Hier geht es um die Zielarchitektur – und darum, wie KI-Governance darin verankert ist.
Was eine souveräne KI-Plattform ist – und was nicht
Eine souveräne KI-Plattform ist eine KI-Anwendungsumgebung, bei der Betreiber, Rechenzentrum, Datenhaltung und Modellbetrieb einem einheitlichen Rechtsraum unterliegen und der Kunde die Kontrolle über Identitäten, Daten, Modelle, Rechte und Konfiguration behält.
Drei Abgrenzungen helfen bei der Einordnung:
Souveränität ist keine Regionseinstellung. Eine europäische Region eines internationalen Anbieters löst die Frage der Datenresidenz. Sie beantwortet nicht automatisch die Frage nach dem anwendbaren Recht für den Betreiber, nach der Kontrolle über den Identity-Provider oder nach dem Ort, an dem Inferenz stattfindet. Für viele Organisationen ist eine EU-Region genau die richtige Antwort – dann ist CompanyGPT auf Azure die passende Variante. Souveränität im engeren Sinn entsteht erst, wenn Hosting, Identity, Daten und Modelle zusammen betrachtet werden.
Souveränität ist nicht gleich On-Premise. Ein eigenes Rechenzentrum liefert maximale Kontrolle, aber auch maximale Betriebsverantwortung: GPU-Beschaffung, Patching, Hochverfügbarkeit, 24/7-Betrieb. Eine Sovereign Cloud wie STACKIT verlagert diese Verantwortung auf einen Managed-Service-Anbieter im selben Rechtsraum. Für die meisten Verwaltungen und mittelständischen Unternehmen ist das der praktikable Weg.
Souveränität ist eine Architektureigenschaft. Sie lässt sich nicht nachträglich anschrauben. Deshalb beschreiben wir sie hier entlang der Komponenten, aus denen die Plattform besteht. Die Grundlagen dazu: Digitale Souveränität und KI in Europa und der European Sovereign Stack Standard (ES3).
Was Verwaltung und Fachverfahren-Betreiber verlangen
Die Anforderungen an eine KI-Plattform im öffentlichen Sektor sind konkreter als „DSGVO-konform“. Aus unseren Projekten und Ausschreibungen wiederholen sich fünf Punkte:
- Nachweisbare Datenresidenz und Betreiberrecht. STACKIT betreibt seine Rechenzentren in Deutschland (Region EU01) und verfügt über ein BSI-C5-Testat vom Typ 2 sowie eine ISO-27001-Zertifizierung auf Basis des IT-Grundschutzes des BSI. Das ersetzt keine eigene Schutzbedarfsfeststellung, liefert aber die Basis, auf der ein Fachverfahren überhaupt angebunden werden darf.
- Identitäten und Rechte unter eigener Kontrolle. Viele Behörden betreiben ihr Active Directory oder einen landeseigenen Identity-Provider und wollen keinen zusätzlichen Cloud-Tenant als Voraussetzung für einen KI-Assistenten. Deshalb ist Keycloak bei uns der Standard, Entra ID die Option.
- Modelle ohne Drittlandtransfer. Für Berufsgeheimnisträger nach § 203 StGB, Sozialdaten oder Personalakten muss Inferenz im selben Rechtsraum stattfinden wie die Datenhaltung. STACKIT AI Model Serving liefert das; internationale Modelle bleiben ein optionaler, pro Rolle freigegebener Pfad.
- Auditierbarkeit und Kostentransparenz. Wer hat wann welches Modell mit welchen Daten genutzt, und was hat es gekostet? Audit-Logs, Kostenstellen und rollenbasiertes Gating sind für Verwaltungen Voraussetzung, keine Komfortfunktion.
- Reproduzierbare Infrastruktur. Ein Prüfer will den Soll-Zustand lesen können. Infrastructure as Code und automatisierte Bereitstellung per GitOps sind deshalb Pflicht.
Der Kontext ist dabei breiter als eine einzelne Plattform: Mit dem Deutschland-Stack, Landesassistenten wie F13 in Baden-Württemberg und dem GovTech-Deutschland-Rahmenvertrag, an dem STACKIT beteiligt ist, entsteht ein Ökosystem, in das sich eine Plattform einfügen muss.
Die Architektur im Überblick
CompanyGPT Sovereign besteht aus denselben Anwendungsmodulen wie die Azure-Variante – Chat-Oberfläche, Dokumentensuche companyRAG, companyFILES, Administration und Kosten-Dashboard, souveräne Web-Suche, optional AI Gateway und n8n-Automation –, aber auf einer vollständig in STACKIT betriebenen Infrastruktur:
Die folgenden Abschnitte gehen die Schichten von der Laufzeit bis zur Governance durch.
Laufzeit: Container auf STACKIT Kubernetes Engine
Alle Anwendungskomponenten laufen als Container auf der STACKIT Kubernetes Engine (SKE). Kubernetes ist dabei kein Selbstzweck, sondern die Schicht, die drei Anforderungen gleichzeitig erfüllt: Isolation zwischen Komponenten, deklarative Beschreibung des Soll-Zustands und automatisierte Wartung durch STACKIT.
Jedes Anwendungsmodul lebt in einem eigenen Namespace mit eigener Netzwerkrichtlinie. Eingehender Verkehr ist standardmäßig verboten und nur aus dem Cluster selbst erlaubt; von außen existiert genau ein Weg – über den STACKIT Load Balancer, TLS-Terminierung und den authentifizierten Gateway-Pfad. Zertifikate werden automatisch ausgestellt und erneuert. Kubernetes-Versionen und Betriebssystem-Images aktualisiert SKE in einem definierten Wartungsfenster, Node für Node, ohne dass Anwendungen offline gehen.
Die Plattform ist Single-Tenant: Jeder Kunde erhält sein eigenes Cluster mit eigenen Datenbanken. Es gibt keine geteilte Kontrollebene zwischen Mandanten – für Verwaltungen häufig die Voraussetzung, damit ein Fachverfahren angebunden werden darf.
Dieser dedizierte Stack ist zugleich der günstige Einstieg: Ein Pilot startet mit einem kompakten Cluster, Single-Node-Datenbanken und nutzungsbasierter Abrechnung ohne Pro-Kopf-Gebühr. Dieselbe Architektur ist auf High-Scale-Workloads vorbereitet – Node-Autoscaling in SKE, horizontale Skalierung der Anwendungsmodule, Umschalten der Datenbanken auf Hochverfügbarkeits-Replikation, praktisch unbegrenzter Object Storage und ein Model Serving, das STACKIT für Sie skaliert. Von 50 Nutzern in einem Fachbereich bis zu mehreren tausend Nutzern einer Landesverwaltung ändert sich die Konfiguration, nicht die Plattform.
Datenhaltung: Managed Services in Deutschland
Die Datenschicht liegt bewusst auf STACKIT Managed Services, damit Backup, Patching, Verschlüsselung und Hochverfügbarkeit beim Cloud-Anbieter liegen und nicht bei Ihnen:
- STACKIT PostgreSQL Flex hält Identitäten, Sessions, Berechtigungen und die Metadaten der Dokumentensuche – getrennt nach Anwendungsmodul mit eigenen Datenbanken und Zugangsdaten.
- STACKIT MongoDB Flex speichert Chatverläufe, Agenten-Konfigurationen und Nutzerprofile mit Snapshots und Point-in-Time-Recovery.
- STACKIT Object Storage (S3-kompatibel) nimmt Dokumente der Wissensbasis und Backups der Cluster-Volumes auf; jeder Zweck erhält einen eigenen Bucket mit eigenen Zugangsdaten.
- Persistente Volumes im Cluster – etwa für den Suchindex oder geteilte Dateien – werden repliziert und regelmäßig in den Object Storage gesichert.
Die Datenbanken sind über IP-Zugriffslisten ausschließlich für die Adressbereiche des Clusters und optional definierte Admin-Netze freigegeben; die Listen werden mit der Infrastruktur versioniert, jede Verbindung ist TLS-verschlüsselt und authentifiziert. Object Storage und Block Storage verschlüsseln serverseitig mit AES-256, MongoDB Flex bringt Verschlüsselung im Ruhezustand mit, und für PostgreSQL Flex lassen sich kundenverwaltete Schlüssel über den STACKIT Key Management Service einsetzen. In einem rein souveränen Mandanten verlassen die Daten die Region EU01 nicht.
Anbindung an Fachverfahren: STACKIT VPN
Ein KI-Assistent ist für eine Verwaltung erst dann nützlich, wenn er die eigenen Quellen kennt: das Dokumentenmanagement, Fileshares, SharePoint oder Nextcloud, das Verzeichnis der Mitarbeitenden – und perspektivisch die Fachverfahren selbst. Diese Systeme stehen meist im eigenen Rechenzentrum oder beim kommunalen IT-Dienstleister.
Dafür wird die Plattform über STACKIT VPN angebunden, ein gemanagtes IPsec-Gateway für verschlüsselte Site-to-Site-Tunnel zwischen der eigenen Infrastruktur und der STACKIT Cloud. Damit erreichen die Konnektoren von companyRAG interne Dateiquellen, Keycloak kann ein bestehendes Active Directory oder LDAP als Nutzerquelle einbinden, und n8n-Workflows sprechen mit Fachanwendungen, ohne dass ein einziger Port ins Internet geöffnet wird. Wie ein solcher Tunnel aufgebaut und redundant betrieben wird, beschreibt die Produktseite unserer Schwestergesellschaft zu STACKIT VPN.
Das Ergebnis ist eine Plattform, die sich für Nutzer wie ein internes System verhält: Anmeldung mit dem gewohnten Konto, Zugriff nur auf die für die eigene Rolle freigegebenen Quellen, und Daten, die den kontrollierten Rechtsraum nicht verlassen.
Netzwerksicherheit heute – und der nächste Schritt: STACKIT VPC und Private Endpoints
Die Sicherheitsarchitektur folgt dem Prinzip der gestaffelten Verteidigung. Von außen gibt es genau einen Eingang: den STACKIT Load Balancer mit TLS-Terminierung und Authentifizierung am Gateway. Innerhalb des Clusters verbietet eine Default-Deny-Richtlinie jeden eingehenden Verkehr, der nicht explizit erlaubt ist. Die Managed Databases erreichen Cluster und Administratoren über authentifizierte, TLS-verschlüsselte Endpunkte, die per IP-Zugriffsliste auf die Adressbereiche des Clusters beschränkt sind. Zugangsdaten und Modell-Token liegen als Kubernetes Secrets im jeweiligen Namespace und werden automatisch rotiert. Die Anbindung eigener Systeme läuft über STACKIT VPN, ohne dass ein Port ins Internet geöffnet wird.
Den nächsten Schritt hat STACKIT für 2027 angekündigt: ein VPC-Feature mit Private Endpoints, über das Managed Services wie PostgreSQL Flex, MongoDB Flex und Object Storage ausschließlich über private Netzwerkadressen ohne öffentliche IP erreichbar werden. Da alle Datenzugriffe schon heute aus dem Cluster-Netz stammen, ist die Umstellung für die Plattform eine Konfigurationsänderung, kein Umbau – und die Zugriffslisten werden durch eine echte Netzwerktrennung ersetzt. Wer heute höhere Anforderungen hat, kann ergänzend STACKIT Confidential Kubernetes für vertrauliche Workloads und kundenverwaltete Schlüssel über den STACKIT Key Management Service einsetzen.
Identity und Rechte: Keycloak als Standard, Entra ID als Option
Die Identity-Frage entscheidet in Verwaltungsprojekten oft, ob ein Vorhaben überhaupt startet. Unsere Antwort: Alle Anwendungsmodule – Chat, companyRAG, companyFILES, Administration und AI Gateway – sprechen gegen eine neutrale OpenID-Connect-Schnittstelle. Welcher Identity-Provider dahinter steht, ist Konfiguration, nicht Architektur.
Keycloak ist der Standard. Es läuft innerhalb der Plattform auf SKE, nutzt PostgreSQL Flex als Datenbank und stellt OpenID Connect mit Authorization Code Flow und PKCE bereit. Passwortrichtlinie, Brute-Force-Schutz und Session-Laufzeiten sind vorkonfiguriert; Mehrfaktor-Authentifizierung per OTP und Passkeys (WebAuthn) werden pro Mandant im Realm aktiviert. Für Behörden mit bestehendem Verzeichnisdienst ist Keycloak zugleich der Anschlusspunkt: User-Federation gegen Active Directory oder LDAP sowie Identity-Brokering zu Entra ID, AD FS oder akademischen Föderationen wie DFN-AAI sind Standardfunktionen und werden pro Mandant eingerichtet.
Entra ID ist die Option. Wenn eine Organisation ohnehin in Microsoft 365 arbeitet, wird Entra ID per Konfiguration aktiviert – entweder mit einer von uns verwalteten App-Registrierung oder, wie in Verwaltungen üblich, mit einer zentral freigegebenen Registrierung des Kunden. Eine Funktion setzt Entra ID zwingend voraus: das Microsoft-365-Add-in für Outlook und Teams. Alles andere läuft mit Keycloak vollständig.
Gruppen werden zu Rechten. Unabhängig vom Provider werden Gruppenzugehörigkeiten in das Token geschrieben und in der Plattform zu Rollen aufgelöst. Rollen steuern, wer Administrator ist, welche Modelle und Agenten ein Nutzer sehen darf, welche Wissensquellen ihm zur Verfügung stehen und welches Budget ihm zusteht. Die Dokumentensuche companyRAG prüft jeden Zugriff gegen den Identity-Provider, und Wissensquellen werden Rollen zugeordnet: Ein Sachbearbeiter durchsucht über die KI nur die Quellen, die für seine Rolle freigegeben sind.
Model Serving: souverän als Standard, EU-Modelle pro Rolle
Der Modell-Layer ist die Stelle, an der sich Souveränität am deutlichsten zeigt. Ein CompanyGPT-Mandant kann ausschließlich mit STACKIT AI Model Serving betrieben werden: Chat, Agenten, Web-Suche, Memory, Datei-Upload und Dokumentensuche funktionieren mit offenen Modellen aus deutschen Rechenzentren. Aktuell stehen dort unter anderem Llama 3.3 70B, Gemma 4 31B, GPT-OSS 120B und 20B, Qwen3-VL 235B sowie Embedding-Modelle wie E5-Mistral-7B zur Verfügung (Stand September 2026; die Liste ändert sich regelmäßig). Der Zugriff läuft über eine OpenAI-kompatible API, weshalb keine Anwendungskomponente anbieterspezifischen Code braucht.
Die Zugangs-Token für das Model Serving werden von der Plattform verwaltet und automatisch rotiert; kein Nutzer und kein Administrator hantiert mit Modell-Schlüsseln.
Inferenz im eigenen Cluster – etwa auf selbst betriebenen GPU-Knoten – ist bewusst nicht Teil der Standardarchitektur. Gemanagtes Model Serving in einer C5-testierten Umgebung liefert für die meisten Kunden das bessere Verhältnis aus Betriebsaufwand, Verfügbarkeit und Nachweisbarkeit. Wer aus fachlichen Gründen ein spezifisches Modell braucht, kann es anbinden.
Für Mandanten, die zusätzlich internationale Modelle benötigen, gibt es einen dokumentierten zweiten Pfad, den wir in einem früheren Beitrag skizziert haben: OpenAI-Modelle über Azure AI Foundry in EU-Regionen sowie Gemini und Claude über Google Vertex AI in EU-Regionen. Diese Modelle werden pro Mandant aktiviert und pro Rolle freigegeben. Ein rein souveräner Mandant enthält sie schlicht nicht.
KI-Governance: Budgets, Nachvollziehbarkeit, Leitplanken
Souveränität ohne Governance ist nur Hosting. Deshalb ist die Steuerungsschicht fester Bestandteil der Architektur – über das Administrations-Modul und, bei höherem Bedarf, das AI Gateway:
- Modellzugriff nach Rolle. Welche Modelle eine Gruppe nutzen darf, ist eine Richtlinie, keine Nutzerentscheidung. Ein Team mit Sozialdaten bekommt ausschließlich souveräne Modelle; ein Kommunikationsteam darf zusätzlich ein EU-Modell für Übersetzungen nutzen.
- Budgets und Kostenstellen. Verbrauch wird pro Nutzer, Team und Kostenstelle in Euro erfasst; Budgets kaskadieren von der Organisation bis zum einzelnen Agenten. Überschreitungen werden gemeldet oder blockiert.
- Audit-Logs. Jede Anfrage ist mit Nutzer, Modell, Zeitpunkt und Kosten protokolliert. Das ist die Grundlage für die Protokollierungspflichten der KI-Verordnung ebenso wie für interne Revision.
- Leitplanken. Modell-Allowlists pro Rolle, Budgets und Guardrails werden zentral über das AI Gateway gesetzt; Agenten und Wissensquellen werden von Administratoren freigegeben und Rollen zugewiesen.
- Transparenz für Nutzer. Die Oberfläche zeigt, mit welchem Modell und aus welchen Quellen eine Antwort entstanden ist – eine Voraussetzung, damit Mitarbeitende KI-Ausgaben richtig einordnen.
Für Datenschutz und Informationssicherheit bedeutet das konkret: Auftragsverarbeitung im deutschen Rechtsraum, Datenresidenz in EU01, Verschlüsselung, Löschkonzepte pro Mandant, Rechtekonzept aus dem eigenen Verzeichnisdienst, Protokollierung – und damit die Bausteine, die eine Datenschutz-Folgenabschätzung und eine Schutzbedarfsfeststellung nach IT-Grundschutz benötigen.
Was der EU AI Act von Behörden verlangt – und wie die Plattform hilft
Ein allgemeiner KI-Assistent ist nach der KI-Verordnung in der Regel kein Hochrisiko-System. Trotzdem treffen Betreiber – und öffentliche Stellen im Besonderen – konkrete Pflichten, die eine Plattform unterstützen muss:
- KI-Kompetenz (Art. 4). Mitarbeitende müssen den Umgang mit KI beherrschen. Unsere KI-Schulungen und die Ausbildung zum KI-Beauftragten decken das ab; die Plattform unterstützt mit Nutzungsrichtlinien und Transparenzhinweisen direkt in der Oberfläche.
- Transparenz (Art. 50). Nutzer müssen erkennen, dass sie mit einem KI-System interagieren und welche Inhalte KI-generiert sind. Das ist in der Oberfläche verankert.
- Betreiberpflichten bei Hochrisiko-Einsatz (Art. 26, seit 2. August 2026 anwendbar). Wird der Assistent in einem Anhang-III-Kontext eingesetzt, etwa bei Entscheidungen über öffentliche Leistungen, greifen menschliche Aufsicht, Protokollaufbewahrung und Nutzung gemäß Herstellervorgaben. Audit-Logs und Rollen-Gating liefern die technische Basis.
- Grundrechte-Folgenabschätzung (Art. 27). Öffentliche Stellen müssen sie vor dem Hochrisiko-Einsatz durchführen. Die Architekturbeschreibung, das Rechtekonzept und die Modellzuordnung pro Anfrage sind die Unterlagen, die dafür gebraucht werden.
Die Einstufung selbst bleibt Aufgabe der Behörde. Wie Sie das strukturiert angehen, beschreibt unsere KI-Compliance-Beratung; den Zusammenhang mit NIS2 und KRITIS beleuchtet der Beitrag NIS2, KRITIS und der EU AI Act.
Betrieb: Infrastructure as Code und GitOps
Die gesamte Plattform – Cluster, Datenbanken, Netzwerk, Identity-Provider, Anwendungsmodule und Modellzugriffe – ist als Code beschrieben und wird automatisiert per GitOps ausgerollt. Es gibt kein Klick-Deployment und keine manuelle Konfiguration. Jede Änderung ist ein Commit mit Review; jeder Stand ist rekonstruierbar; ein neuer Mandant entsteht aus denselben Modulen mit einer eigenen Konfigurationsdatei.
Für Kunden im öffentlichen Sektor ist das mehr als DevOps-Komfort. Ein Prüfer nach ISO 27001, IT-Grundschutz oder C5 liest den Soll-Zustand statt ihn zu erfragen, und Änderungen an sicherheitsrelevanten Einstellungen sind lückenlos dokumentiert. Feature-Module wie companyRAG, AI Gateway oder n8n werden pro Mandant zu- oder abgeschaltet – eine Verwaltung, die nur Chat und Dokumentensuche braucht, bekommt genau diese Komponenten. Auch die Skalierung ist Konfiguration desselben Codes: Knotenzahl und Autoscaling-Grenzen, Replikation der Datenbanken und Replikate der Anwendungsmodule wachsen mit dem Bedarf, ohne dass die Plattform neu aufgesetzt wird.
Backups laufen auf zwei Ebenen: Die Managed Databases sichern täglich mit Snapshots und Point-in-Time-Recovery, die Cluster-Volumes werden regelmäßig in den STACKIT Object Storage gesichert. Wartung und Updates der Plattform übernehmen wir; Modell- und Sicherheitsupdates werden über denselben GitOps-Pfad ausgerollt wie alles andere.
Sovereign oder Azure: Wahlfreiheit statt Entweder-oder
CompanyGPT gibt es in zwei gleichwertigen Ausprägungen: auf Microsoft Azure und als Sovereign-Variante auf STACKIT. Beide nutzen dieselbe Anwendungsschicht, dieselbe Governance und dasselbe Rechtemodell. Die Entscheidung ist keine Frage von besser oder schlechter, sondern von Anforderungen – Datenresidenz, Identity-Landschaft, Microsoft-365-Integration und Modellbedarf:
| Kriterium | CompanyGPT auf Azure | CompanyGPT Sovereign auf STACKIT |
|---|---|---|
| Laufzeit | AKS in EU-Region | STACKIT Kubernetes Engine, Deutschland |
| Identity | Entra ID | Keycloak (Standard) oder Entra ID |
| Standardmodelle | Azure AI Foundry (EU) | STACKIT AI Model Serving |
| Internationale Modelle | integriert | optional, pro Mandant und Rolle |
| Microsoft-365-Add-in | ja | nur mit Entra ID |
| Anbindung eigener Systeme | Azure-Netzwerkdienste | STACKIT VPN (IPsec Site-to-Site) |
| Datenbanken | Azure Managed Services | PostgreSQL Flex, MongoDB Flex |
| Governance, Rechte, Audit | identisch | identisch |
| Typische Anforderung | M365-zentrierte Organisationen | Verwaltung, Fachverfahren, § 203 StGB, Forschung |
Für Organisationen, die in Microsoft 365 arbeiten und für die eine EU-Region den Anforderungen genügt, ist Azure die naheliegende Wahl – mit tiefer Integration in Entra ID, Outlook und Teams. Wer deutsche Datenresidenz, C5-Nachweis, eigene Identitäten oder Modelle ohne Drittlandbezug braucht, wählt Sovereign. Beide Wege sind vollwertig, und ein späterer Wechsel bleibt möglich. Wie Sie eine solche Auswahl strukturiert angehen, beschreibt unser Leitfaden zu den Auswahlkriterien für KI-Plattformen 2026.
Fazit
Eine souveräne KI-Plattform ist das Ergebnis vieler Einzelentscheidungen: Container auf STACKIT Kubernetes Engine statt eigener Cluster, Managed Databases in Deutschland, ein einziger authentifizierter Eingang, STACKIT VPN für die Anbindung von Fachverfahren und Verzeichnisdiensten, Keycloak als Standard mit Entra ID als gleichwertiger Option, STACKIT AI Model Serving als einziges Pflicht-Backend, Rechte aus dem eigenen Verzeichnis, Budgets und Audit-Logs als Governance-Schicht – und alles als Code, automatisiert per GitOps ausgerollt.
CompanyGPT Sovereign ist im STACKIT Marketplace gelistet und wird nutzungsbasiert abgerechnet. Wenn Sie prüfen möchten, ob Ihre Fachverfahren, Ihr Verzeichnisdienst und Ihre Schutzbedarfe zu dieser Architektur passen, sprechen Sie uns an – ein Architektur-Workshop reicht in der Regel, um Variante, Identity-Pfad und Modellstrategie festzulegen.