Digitale Souveränität für KI- und Analytics-Plattformen – von Prinzipien zu konkreten Lösungen

Digitale Souveränität ist für Organisationen längst mehr als eine abstrakte politische Debatte. Sie entwickelt sich zunehmend zu einer zentralen Anforderung an moderne IT-Architekturen. Wer Analytics- und AI-Plattformen entwirft, steht vor grundlegenden Entscheidungen: Wo liegen Daten? Wer kontrolliert Zugriffe? Welche Abhängigkeiten entstehen durch Software, Anbieter und Lizenzmodelle? Und wie lassen sich diese Entscheidungen mit Anforderungen an Agilität, Kosten und Skalierbarkeit verbinden?

Bei HMS betrachten wir diese Fragen entlang von fünf Dimensionen: Kontrolle, Compliance, Skalierbarkeit, Kosten und Innovationsgeschwindigkeit. Sie bilden den Rahmen, in dem Architekturentscheidungen strukturiert und priorisiert werden können.

Abbildung 1: Fünf Dimensionen zur Einordnung von IT-Architekturen.

In diesem Blogartikel stellen wir die fünf Dimensionen unseres Vorgehens vor. Anhand ausgewählter Projekte zeigen wir, wie Unternehmen gemeinsam mit HMS Lösungen entwickelt haben, die dauerhaft tragfähig sind. Dabei wurden die spezifischen Rahmenbedingungen jedes Kunden berücksichtigt und passgenaue Ansätze erarbeitet.

Kontrolle und Compliance – Souveränität im engeren Sinne

Viele Organisationen starten Architekturüberlegungen mit dem Wunsch nach maximaler Kontrolle über ihre IT-Infrastruktur. Sie wollen selbst bestimmen, wo Daten gespeichert werden, in welchem Format sie vorliegen, wie sie verarbeitet werden und welche Software zum Einsatz kommt. Diese Hoheit über Systeme schafft die Grundlage für Compliance: Nur wer die technische Kontrolle behält, kann Datenschutz, Revisionssicherheit und regulatorische Anforderungen konsequent und nachvollziehbar umsetzen. Kontrolle bedeutet dabei nicht nur physische Hoheit über Systeme, sondern auch die Fähigkeit, Zugriffe differenziert zu steuern – etwa durch Identity & Access Management, Secrets Management und Policy Enforcement. Je klarer diese Mechanismen intern verankert sind, desto größer ist die technologische Unabhängigkeit einer Organisation.

Compliance wiederum umfasst weit mehr als die Einhaltung gesetzlicher Vorgaben: Auch unternehmensinterne Sicherheitsrichtlinien, Auditierbarkeit und die vollständige Nachvollziehbarkeit von Datenflüssen gehören dazu. In regulierten Branchen ist Compliance längst zur Voraussetzung geworden, um am Markt agieren zu können – etwa im Rahmen von ISO 27001, DORA oder NIS2. Doch Kontrolle und Compliance haben ihren Preis. Wer Systeme vollständig selbst betreibt, muss nicht nur Infrastruktur und Fachpersonal bereitstellen, sondern auch die Verantwortung tragen, Systeme aktuell, sicher und verfügbar zu halten. Diese Aufgaben sind essenziell, binden jedoch Kapazitäten, etwa für den Wissensaufbau und -erhalt, die dann nicht mehr für die Entwicklung neuer Produkte, Services oder Analysen zur Verfügung stehen.

Skalierbarkeit und Verfügbarkeit – das Versprechen der Cloud 

Auf der anderen Seite steht häufig der Wunsch nach Skalierbarkeit und Verfügbarkeit: Compute- und Storage-Ressourcen flexibel hoch- oder herunterzufahren, Systeme geografisch zu verteilen und dabei globalen Zugriff mit stabiler Performance zu gewährleisten. Hyperscaler bieten dies fast „out of the box“ – mit weltweit verteilten Rechenzentren, integrierter Redundanz, automatischem Failover und garantierten Service Level Agreements (SLAs).

Wer dagegen alles selbst betreibt, muss Hochverfügbarkeit eigenständig sicherstellen – etwa durch Backup-Standorte, Notstromversorgung, Replikation und Disaster Recovery. Das ist möglich, aber teuer und komplex. Damit zeigt sich ein zentrales Spannungsfeld: Je mehr Kontrolle eine Organisation behalten möchte, desto höher wird der Aufwand, ein vergleichbares Level hinsichtlich Resilienz und Elastizität zu erreichen, das Cloud-Anbieter standardmäßig liefern.

Kosten und Tempo der Innovation – zwei zentrale Dimensionen im Zusammenspiel

Auch bei den Kosten zeigen sich deutliche Unterschiede zwischen Cloud und On-Premises Lösungen: In der Cloud entstehen Ausgaben nutzungsabhängig – und können bei schlecht konfigurierten Services schnell aus dem Ruder laufen. On-Premises erfordert hingegen hohe Anfangsinvestitionen für Hardware, Lizenzen und Personal. Dafür lassen sich die laufenden Kosten meist besser planen und kontrollieren.

In beiden Fällen lohnt der Blick auf den gesamten Lebenszyklus. Neben den sichtbaren Infrastrukturkosten spielen auch versteckte Aufwände eine Rolle – etwa für Schulungen, Integrationsprojekte oder juristische Beratung bei Datenschutzthemen. Eine fundierte Total-Cost-of-Ownership-Betrachtung ist daher unverzichtbar.

Bei der Innovationsgeschwindigkeit bietet die Cloud meist klare Vorteile: Fertige Plattformen, Werkzeuge und KI-Modelle ermöglichen es, neue Ideen oft innerhalb weniger Tage, umzusetzen. On-Premises-Lösungen erfordern dagegen meist Eigenentwicklung, was längere Vorlaufzeiten mit sich bringt – dafür entstehen weniger Abhängigkeiten von externen Anbietern.

Entscheidend für die Innovationsgeschwindigkeit ist jedoch nicht nur die technische Infrastruktur, sondern auch die Organisation des Entwicklungsprozesses im Team. Continuous Integration, Continuous Delivery, Plattformfähigkeiten und standardisierte Schnittstellen erleichtern die Integration neuer Technologien. Dieser kontinuierliche, agile Iterationsprozess bestimmt maßgeblich, wie schnell und innovativ eine Organisation am Markt handeln kann.

Das Paradoxon der souveränen Architektur

Diese Spannungsfelder zeigen deutlich: Es gibt keine Architektur, die allen Anforderungen gleichzeitig gerecht wird. Viele dieser Dimensionen stehen im Widerspruch, andere bedingen sich gegenseitig.

Mehr Kontrolle kann die Compliance stärken, gleichzeitig aber die Innovationsgeschwindigkeit deutlich reduzieren. Innovationsgeschwindigkeit und Skalierbarkeit gehen meist Hand in Hand – doch wer Innovation forciert, kann in Konflikt mit regulatorischen Anforderungen geraten. Und wer Compliance perfektioniert, verlangsamt unweigerlich die Geschwindigkeit.

Wer souveräne Architekturen plant, kann diese Zielkonflikte niemals vollständig auflösen. Vielmehr geht es darum, sie bewusst auszubalancieren – abgestimmt auf die strategischen Ziele der Organisation sowie die konkreten Rahmenbedingungen, in denen sie agiert. Dazu zählen unter anderem verfügbare Budgets, technisches und organisatorisches Know-how, regulatorische Anforderungen, branchenspezifische Standards und die Risikobereitschaft der Führungsebene.

Denn nur wenn Strategie und Kontext gleichermaßen berücksichtigt werden, entsteht eine tragfähige und realistische Architektur. Genau hier setzt der Beratungsansatz von HMS an: Wir übertragen die individuellen Anforderungen einer Organisation systematisch auf die fünf Dimensionen und leiten daraus klare Prioritäten ab. Anschließend gestalten wir gemeinsam mit unseren Kunden Entscheidungen so, dass sie heute tragfähig sind und gleichzeitig zukünftige Entwicklungen ermöglichen.

Archetypen als Orientierungspunkte

In der Praxis haben sich drei grundlegende Muster etabliert, mit denen Organisationen das Spannungsfeld zwischen Kontrolle, Compliance, Skalierbarkeit, Kosten und Innovationsgeschwindigkeit adressieren können:

1. On-Premises ist der klassische Weg für alle, die maximale Kontrolle über ihre Systeme behalten wollen. Der Betrieb erfolgt im eigenen Rechenzentrum unter vollständiger Hoheit. Dieses Modell bietet höchste Kontrolle und kann strengste Compliance-Anforderungen erfüllen – doch es skaliert nicht im selben Maße wie Angebote der klassischen Hyperscaler, erfordert hohe Anfangsinvestitionen und verlangsamt oft die Innovationsgeschwindigkeit.
2. EU-Cloud stellt den Mittelweg dar. Anbieter wie STACKIT, die Open Telekom Cloud oder Hetzner unterliegen europäischem Recht und bieten ein solides Serviceportfolio, was in der Breite jedoch nicht mit US-Hyperscalern vergleichbar ist. Services in EU-Clouds sind weniger global aufgestellt, dafür flexibler und schneller als rein On-Premises betriebene Systeme.
3. US-Hyperscaler stehen für maximale Skalierbarkeit und hohe Innovationsgeschwindigkeit. Neue Technologien sind hier oft zuerst in der Breite verfügbar, das Cloud-Ökosystem ist sehr ausgereift, und die Infrastruktur lässt sich nahezu auf Knopfdruck erweitern. Im Gegenzug geben Organisationen einen großen Teil der Kontrolle ab und bewegen sich in Bezug auf Datenschutz und Compliance mitunter in einer Grauzone – insbesondere in regulierten Branchen.

Keine dieser Varianten ist per se besser oder schlechter. Sie markieren Orientierungspunkte auf einer Landkarte, auf der jede Organisation ihren eigenen Weg definieren muss – abhängig davon, welche konkreten Aspekte für sie Priorität haben.

Sovereign Cloud-Angebote können in bestimmten Szenarien eine ergänzende Option sein. Hierbei handelt es sich um spezialisierte Angebote globaler Cloud-Anbieter, die mit europäischen Datentreuhändern arbeiten oder einen EU-only-Betrieb sicherstellen. Ziel ist es, die Skalierbarkeit und das Serviceportfolio internationaler Hyperscaler mit lokaler Souveränität zu verbinden. In der Praxis sind diese Modelle bislang wenig verbreitet, können jedoch sinnvoll sein, wenn regulatorische Anforderungen höchste Priorität haben und gleichzeitig das Serviceportfolio und die Convenience eines US-Hyperscalers benötigt werden.

Hybride Architekturen bleiben ein bewährter Ansatz: Kritische Workloads bleiben On-Premises, während einzelne Projekte Cloud-Ressourcen nutzen. Auf diese Weise lassen sich Zielkonflikte gezielt entschärfen, ohne die eigene Souveränität vollständig aufzugeben.

Vom Prinzip zur Praxis

Jede IT-Architektur entsteht aus ihrem spezifischen Kontext. Im Folgenden zeigen wir mit Fallbeispielen, wie Unternehmen unter ganz unterschiedlichen Bedingungen Prioritäten gesetzt, die Entscheidungsdimensionen gegeneinander abgewogen und Technologien gewählt haben. HMS hat diese Organisationen beraten und als Implementierungspartner unterstützt - nicht mit Standardlösungen, sondern mit Architekturen, die passgenau auf ihre individuellen Rahmenbedingungen abgestimmt wurden.

Fall 1: Chatbasierte Datenerschließung mithilfe von GenAI

Dieser Fall zeigt zwei gegensätzliche Wege: Auf der einen Seite maximale Souveränität durch einen vollständig On-Premises betriebenen Stack, auf der anderen Seite hohe Innovationsgeschwindigkeit durch Nutzung bestehender Cloud-Infrastrukturen.

Beispiel A: Der souveräne Chatbot eines Finanzinstituts

Ausgangssituation / Kontext
Ein großes europäisches Finanzinstitut wollte interne Dokumente mithilfe generativer KI durchsuchbar machen. Zentrale Anforderung war, dass vertrauliche Informationen das eigene Haus zu keinem Zeitpunkt verlassen durften. Compliance und Kontrolle hatten höchste Priorität.

Lösungsansatz

• Vollständig On-Premises betriebene Architektur auf eigenem OpenShift-Cluster.
• Alle Komponenten – Dokumentenparser, Vektordatenbank, Sprachmodell – liefen isoliert.
• Eingesetzt wurden ausschließlich Open-Source-Bausteine wie Weaviate, MLflow und Open WebUI.

Ergebnisse & Trade-offs

• Volle Kontrolle, maximale Nachvollziehbarkeit, lückenlose Dokumentation aller Datenflüsse.
• Enorme operative Komplexität. Der Betrieb erforderte ein interdisziplinäres Team mit Expertise in GenAI, MLOps und klassischer Infrastruktur.

Abbildung 2: Schematische Übersicht der auf OpenShift bereitgestellten Systemarchitektur: Die Benutzer interagieren über ein Open WebUI Frontend mit dem GenAI-Chatbot. Die agentenbasierte Workflow-Orchestrierung wird mithilfe von LangGraph verwaltet, das über ein FastAPI-Backend bereitgestellt wird. Textdaten werden mit Docling aus SharePoint extrahiert und in einer Weaviate-Vektordatenbank gespeichert. Large Language Models (LLMs) und Embedding-Modelle werden über vLLM für eine effiziente Inferenz bereitgestellt. Zentrales Logging und Tracing werden mit MLflow durchgeführt.

Beispiel B: Innovationstempo mit Azure

Ausgangssituation / Kontext
Ein Industriekonzern plante ebenfalls die Einführung eines Chatbots zur Erschließung interner Wissensquellen – in diesem Fall über 500.000 Forschungsberichte. Im Gegensatz zum Finanzinstitut verfügte das Unternehmen bereits über eine große Azure-Datenplattform, die gut in bestehende Geschäftsprozesse integriert war. Im Fokus stand die schnelle Integration in die bestehende Infrastruktur.

Lösungsansatz

• Integration von Azure OpenAI Services in die bestehende Infrastruktur.
• Nahtlose Einbettung in vorhandene Recherche-Tools.

Ergebnisse & Trade-offs

• Innerhalb weniger Wochen war ein produktiver Chatbot verfügbar.
• Teile der Daten wurden in die Cloud migriert, die technologische Abhängigkeit von Azure nahm zu

Abbildung 3: Schematische Übersicht der Systemarchitektur in Azure: Die Benutzer interagieren über ein in React implementiertes Frontend mit dem GenAI-Chatbot. OpenAI-Modelle werden über Azure Foundry verwaltet, während das Logging der LLM-Aufrufe mit MLflow erfolgt. Benutzeranfragen werden in einer Postgres-Datenbank gespeichert. Die hybride Dokumentsuche basiert auf Elastic Search (für Stichwortsuche) und OpenSearch (für semantische Suche). Die gesamte Plattform wird mit Azure Log Analytics überwacht.

Fall 2: Data-Analytics- Plattformen

Dieser Fall verdeutlicht, wie unterschiedlich Organisationen das Spannungsfeld zwischen Kosten, Skalierbarkeit und regulatorischen Anforderungen adressieren – vom minimalistischen Lakehouse bis zur hochskalierbaren Echtzeitplattform.

Beispiel C: Ein minimalistisches Lakehouse

Ausgangssituation / Kontext
Ein Finanzinstitut unterlag strengen regulatorischen Vorgaben und legte höchsten Wert auf digitale Souveränität. Ziel war der Aufbau einer robusten Datenplattform, die regulatorisch sicher und dennoch zukunftsfähig bleibt.

Lösungsansatz

• Aufbau eines Lakehouse auf Basis von SQL-first, Open Source und offenen Standards (Apache Arrow, Parquet).
• Datenhaltung ausschließlich im eigenen Cluster.
• Containerisierte Workflows, um einfache Migrationen zu ermöglichen.

Ergebnisse & Trade-offs

• Robuste, skalierbare Plattform, die regulatorischen Anforderungen gerecht wird.
• Weniger Komfort und Geschwindigkeit als bei großen Plattformdiensten.

Abbildung 4: Schematische Übersicht aller Systemkomponenten: Die Data Processing App (in der Mitte) enthält ein Orchestrator-Modul, das über einen Message Bus (oben) Befehle und Dateipfade empfängt. Anschließend ruft sie Daten aus dem verteilten Speicher (links) ab und führt eine Reihe von Transformations- und Validierungsschritten mit DuckDB und Arrow auf OpenShift aus. Zwischenergebnisse werden im verteilten Speicher (unten) abgelegt. Das Endergebnis wird in eine relationale Datenbank geschrieben und zusätzlich als Parquet-Dateien im verteilten Speicher gespeichert.

Beispiel D: Echtzeit im Produktionswerk

Ausgangssituation / Kontext
Ein Fertigungsunternehmen wollte Produktionsdaten in Echtzeit verarbeiten, um Prozesse zu optimieren. Innovationsgeschwindigkeit und Skalierbarkeit standen hier im Vordergrund.

Lösungsansatz

• Nutzung von Azure Databricks in Kombination mit Apache Kafka.
• Integration in bestehende Azure-Dienste für nahtlose Workflows.

Ergebnisse & Trade-offs

• Nahezu unbegrenzte Skalierbarkeit, schnelle Prototypisierung von KI-Modellen, hohe Innovationsgeschwindigkeit.
• Deutlich höhere Betriebskosten für Streaming, Storage und Compute, sowie eine zunehmende Abhängigkeit von Azure.

Abbildung 5: Confluent Kafka (links) erfasst kontinuierlich Sensordaten aus der Anlage und speist sie in die Datenplattform ein. Databricks Streaming-Jobs transformieren die eingehenden Daten – sie führen Abgleiche, Validierungen, Anreicherungen und Kontextualisierungen durch – und schreiben die Ergebnisse in Delta-Tabellen (oben rechts in der Mitte). Ein Teil der verarbeiteten Daten wird außerdem in eine PostgreSQL-Datenbank (unten rechts in der Mitte) geschrieben. Azure Data Factory orchestriert Apache Spark Batch-Jobs (oben links), einschließlich der Abrufe von Stammdaten und Kontextdaten aus dem Azure Data Explorer sowie der Wartung der Delta-Tabellen. Power BI und der Azure ML Service (rechts) greifen auf die Daten der Plattform zu, um sie weiter zu verarbeiten und zu visualisieren.

Jeder Weg hat seinen Preis

Die Fallbeispiele verdeutlichen: Es gibt nicht die eine richtige Architektur. Jede Entscheidung spiegelt einen anderen Schwerpunkt wider:

1. Das Finanzinstitut wählte maximale Kontrolle und Compliance.
2. Der Industriekonzern priorisierte Innovationsgeschwindigkeit.
3. Das zweite Finanzinstitut setzte auf Zukunftssicherheit und Portabilität.
4. Der Fertigungsbetrieb optimierte auf Performance.

Alle Lösungen sind valide – weil sie den jeweiligen Kontext berücksichtigen und sich konsequent an der Wertschöpfungskette der Organisationen orientieren.

Fazit

Digitale Souveränität entsteht nicht durch dogmatische Technologieentscheidungen, sondern durch vielschichtige Abwägungen. In diesem Beitrag haben wir fünf Dimensionen vorgestellt, um Entscheidungen strukturiert zu treffen: Kontrolle, Compliance, Skalierbarkeit/Verfügbarkeit, Kosten sowie Innovationsgeschwindigkeit.

Unsere Fallbeispiele zeigen: Souveränität bedeutet nicht maximale Unabhängigkeit, sondern reflektierte Wahlfreiheit. Jede Architektur bringt Abhängigkeiten mit sich – entscheidend ist, dass sie bewusst eingegangen und mit den strategischen Zielen der Organisation und den Rahmenbedingungen in Einklang gebracht werden. Wer die Zielkonflikte kennt und Prioritäten klar formuliert, gestaltet Architekturen, die heute tragfähig sind und zugleich offen für zukünftige Entwicklungen bleiben.

Genau hier setzt HMS an: Wir unterstützen Organisationen dabei, ihre Anforderungen transparent abzubilden, die richtigen Prioritäten zu setzen und Architekturen zu entwickeln, die Sicherheit, Geschwindigkeit und Zukunftsfähigkeit in Balance bringen – und so echte digitale Souveränität ermöglichen.