Herr Neumann, „Made in Germany“ wurde einst als Warnzeichen eingeführt, heute ist es ein Qualitätsmerkmal. Kann „Made in Europe“ bei Cloud denselben Weg gehen?
Absolut – die Parallele ist treffender, als viele denken! „Made in Germany“ wurde Ende des 19. Jahrhunderts von den Briten als Stigma erfunden. 50 Jahre später war es ein globales Gütesiegel. Warum? Weil deutsche Unternehmen nicht billiger, sondern besser wurden. Bei „Made in Europe“ im Cloud-Bereich sehe ich denselben Wendepunkt: Noch wird europäische Cloud oft als regulatorische Last oder Kompromisslösung abgetan. Aber was steckt dahinter? DSGVO-Konformität, Datenhoheit, Schutz geistigen Eigentums – das sind keine Einschränkungen, das sind Differenzierungsmerkmale.
Sie fordern mehr Mut von deutschen Unternehmen. Gleichzeitig ist Deutschland für Gründlichkeit und Perfektionismus bekannt ...
… und genau das ist das Problem: Unser Perfektionismus war jahrzehntelang eine Stärke in der physischen Welt. Ein Auto, das nicht funktioniert, wird zurückgerufen. Da ist Gründlichkeit überlebenswichtig. Aber in der digitalen Welt gelten andere Regeln. Hier gewinnt nicht, wer am längsten plant, sondern wer am schnellsten lernt. Ich sage bewusst provokant: Manchmal sollten wir erst handeln und uns später entschuldigen. Das heißt nicht, fahrlässig zu sein. Es heißt, dass eine 80-Prozent-Lösung, die heute live ist, mehr wert ist als eine 100-Prozent-Lösung, die nie kommt. Digitalisierung ist keine IT-Entscheidung, sondern eine Überlebensfrage für unseren Wohlstand. Und Überleben erfordert Bewegung, nicht Perfektion.
Nun sind ja viele Unternehmen längst in der Cloud. Immer mehr aber merken, dass sie in Abhängigkeiten stecken. Wie gelingt der Weg aus dem Vendor Lock-in?
Der erste Schritt ist ehrlich zu sich selbst zu sein: Wie tief stecken wir wirklich drin? Viele CEOs und CIOs unterschätzen oder verdrängen das. Da wurden über Jahre proprietäre Services genutzt, weil sie bequem waren. Jetzt sitzt man in einer Architektur, die man nicht mehr versteht. Der Weg raus ist kein Big Bang. Was funktioniert: Eine klare Zielarchitektur definieren, die auf offenen Standards basiert. Dann Workload für Workload entscheiden: Was kann ich entkoppeln? Was muss ich neu bauen? Und was bleibt erstmal, wo es ist? Lock-in ist kein technisches Problem, sondern ein strategisches: Wer heute Verträge ohne Exit-Klauseln und Datenportabilität unterschreibt, baut die nächste Abhängigkeit schon ein.
Digitale Souveränität wird oft gefordert, aber selten konkret definiert. Was bedeutet sie in der Praxis?
Für mich muss echte Souveränität drei Voraussetzungen erfüllen: Erstens, Datenkontrolle – ich weiß, wo meine Daten liegen, wer Zugriff hat und unter welchem Rechtsrahmen. Zweitens, Technologiewahlfreiheit – ich kann Komponenten austauschen, ohne alles neu zu bauen. Drittens, Kompetenzhoheit – ich habe intern oder bei vertrauenswürdigen Partnern das Know-how, um meine Systeme zu verstehen und zu steuern. Das klingt banal, ist es aber nicht. Ich erlebe regelmäßig Unternehmen, die ihre eigene Cloud-Architektur nicht mehr erklären können, weil das Wissen beim Dienstleister sitzt.
Zurück zu Europa: 481 Millionen Euro zahlt der deutsche Bund jährlich an Microsoft für Cloud-Leistungen. Gleichzeitig prognostiziert Gartner 23 Milliarden Dollar an Investitionen für Sovereign Cloud in Europa im Jahr 2027. Die Technologie ist da, die Budgets auch – aber reicht das?
Diese Frage treibt mich um! Wir reden seit Jahren über Souveränität, geben Milliarden aus – und gleichzeitig überweisen wir jedes Jahr einen halben Milliardenbetrag nach Redmond. Was mich vorsichtig optimistisch macht: Digitalminister Karsten Wildberger hat jüngst angekündigt, in der Verwaltung zukünftig verstärkt auf Open Source setzen zu wollen – ein wichtiges Signal! Denn das Problem ist nicht die Technologie. Multi-Cloud, offene Standards, souveräne Infrastrukturen: Das sind keine PowerPoint-Prototypen mehr, das läuft alles schon produktiv, bei großen Unternehmen, mit Enterprise-Anforderungen. Was fehlt, sind Vergabeentscheidungen, die dem eigenen Anspruch folgen. Europa hat den Mindshift geschafft, jetzt brauchen wir den Actionshift.
Auch KI bleibt ohne die richtige Cloud-Architektur ein Experiment. Warum scheitern so viele KI-Projekte an der Infrastruktur – und was muss eine Cloud können, damit KI wirklich skaliert?
Genau wie bei der Cloud hat KI kein Software-, sondern ein Infrastruktur-Problem. Und zwar ein massives. Wer KI produktiv betreiben will, braucht eine Cloud, die drei Dinge kann: Elastisch skalieren – nicht in Tagen, sondern in Minuten. Daten dort bereitstellen, wo sie gebraucht werden – schnell, sicher, compliant. Und heterogene Workloads orchestrieren. Die meisten Legacy-Infrastrukturen können das nicht. Wer KI-Strategie macht, ohne Cloud-Strategie zu machen, baut ein Haus ohne Fundament.
Große KI-Modelle laufen heute meist auf US-Hyperscalern. Gleichzeitig wollen Unternehmen Kontrolle über ihre Daten. Wie löst man diesen Problem?
Das ist der Widerspruch, mit dem ich täglich arbeite. Und ich sage bewusst: Es ist ein Widerspruch, kein unlösbares Problem. Die Realität ist: Die großen Foundation Models kommen aus den USA und China. Das werden wir kurzfristig nicht ändern. Aber – und das ist entscheidend – das Modell ist nur ein Teil der Gleichung. Die Daten, mit denen ich trainiere und prompte, die Anwendung, in die ich KI einbette, die Ergebnisse, die ich generiere: Das alles muss nicht auf einem US-Hyperscaler liegen. Hier kommt souveräne Cloud ins Spiel: Ich kann Open-Source-Modelle wie Llama oder Mistral auf europäischer Infrastruktur betreiben. Ich kann Fine-Tuning mit meinen Unternehmensdaten machen, ohne dass die Daten mein Rechtsgebiet verlassen. Ich kann Inferenz dort laufen lassen, wo ich Kontrolle habe. Das erfordert aber eine Architektur, die das von Anfang an mitdenkt: Die souveräne Cloud gibt mir Kontrolle zurück, ohne mich vom technologischen Fortschritt abzukoppeln.
NIS2, DORA, AI Act: Die Regulierungsdichte steigt. Wie können CIOs Compliance und Innovationsgeschwindigkeit unter einen Hut bringen?
Indem sie aufhören, Compliance als Gegner von Innovation zu betrachten. Die meisten Unternehmen behandeln Regulierung wie einen Störfaktor. Da kommt NIS2, also wird ein Projekt aufgesetzt, Checklisten abgearbeitet, und dann hofft man, dass der Auditor gnädig ist. Die cleveren CIOs, die ich kenne, machen es anders: Sie bauen Compliance von Anfang an in ihre Architektur ein. Security by Design, Privacy by Design, Auditierbarkeit als Feature. Das kostet initial mehr – aber es zahlt sich aus, weil man nicht bei jeder neuen Regulierung alles umbauen muss. Und eine Cloud-Architektur, die auf offenen Standards basiert, die dokumentiert ist, die klare Verantwortlichkeiten hat – die ist übrigens nicht nur compliant, die ist auch besser.
Multi-Cloud klingt nach Freiheit, aber auch nach Komplexität. Wann macht eine Multi-Cloud-Architektur wirklich Sinn, und wann wird sie zum Risiko?
Multi-Cloud macht Sinn, wenn sie eine bewusste Entscheidung ist. Sie wird zum Risiko, wenn sie ein Unfall ist. Und leider sehe ich, ehrlich gesagt, mehr Unfälle als Strategien. Echte Multi-Cloud heißt: Ich entscheide bewusst, welcher Workload wo läuft – basierend auf Kriterien wie Kosten, Latenz, Compliance, Verfügbarkeit. Ich habe eine Abstraktionsschicht, die mir Portabilität gibt. Ich habe ein Team, das alle Umgebungen versteht und steuern kann. Das ist anspruchsvoll. Deshalb sage ich auch: Multi-Cloud ist kein Selbstzweck. Für viele Unternehmen ist eine gut gemanagte Single-Cloud mit klarer Exit-Strategie die bessere Wahl als eine schlecht gemanagte Multi-Cloud.
Wenn Sie heute mit einem mittelständischen Unternehmen sprechen, das gerade seine Cloud-Strategie für die nächsten fünf Jahre plant: Welchen einen Fehler sollte es unbedingt vermeiden?
Den vermeintlich einfachen Weg zu nehmen: Zum größten Hyperscaler zu gehen, alles dort hinzupacken, die Managed Services zu nutzen und sich zu freuen, dass es schnell ging. Drei Jahre später wacht man auf und merkt: Man versteht die eigene Architektur nicht mehr, zahlt das Dreifache von dem, was man kalkuliert hat, und ein Anbieterwechsel würde 18 Monate dauern. Der Fehler ist dabei nicht, einen Hyperscaler zu nutzen. Der Fehler ist, nicht zu fragen: Was passiert, wenn ich raus will? Wenn sich die Regulierung ändert? Wenn dieser Anbieter seine Preise verdoppelt? Mein Rat: Bauen Sie von Tag eins für Optionalität. Nutzen Sie offene Standards, wo immer es geht. Dokumentieren Sie Ihre Architektur so, dass nicht nur der Anbieter sie versteht. Und behalten Sie intern die Kompetenz, strategische Entscheidungen zu treffen – statt sie an einen Dienstleister zu delegieren. Cloud-Strategie ist keine IT-Entscheidung. Sie ist eine Unternehmensentscheidung. Und Unternehmensentscheidungen sollte man nicht aus Bequemlichkeit treffen.