SAP auf US-Hyperscalern: Der versteckte blinde Fleck im deutschen Mittelstand

Warum bei KI jede Datenflussskizze auseinandergenommen wird – und beim ERP-Cloud-Move ein Häkchen reicht

Es gibt eine merkwürdige Asymmetrie in der deutschen Digitalisierungs-Debatte. Wenn ein Mittelständler heute über KI-Einsatz nachdenkt, wird jede Datenflussskizze dreimal vom Datenschutzbeauftragten auseinandergenommen. Wenn derselbe Mittelständler sein gesamtes ERP-System in die Cloud verschiebt, reicht oft ein Häkchen im Steuerungskreis und ein Hinweis auf die Compliance-Zertifizierung des Anbieters.

Das Pikante daran: In beiden Fällen geht es um exakt dieselben Daten. Personalakten, Kundenstammdaten, Margen, Lieferantenverträge. Nur dass im ERP-System die Daten konzentriert und in voller Tiefe liegen – während im KI-System meist nur ausgewählte Auszüge verarbeitet werden.

Wie kommt diese Schere zustande? Und warum wird sie gerade durch zwei parallele Entwicklungen geschlossen, die viele Entscheider noch nicht auf dem Radar haben?

Dieser Artikel zeigt: Wer als CEO oder Geschäftsführer im Mittelstand heute KI-Projekte aus Datenschutzgründen blockt, aber SAP bei AWS, Azure oder Google Cloud betreibt, hat einen blinden Fleck. Das wäre lange Zeit folgenlos gewesen. Es wird es nicht mehr lange bleiben.

Wo SAP-Daten heute wirklich liegen

Beginnen wir mit den Fakten. SAP – ein deutsches Unternehmen mit Hauptsitz in Walldorf – bietet seine Cloud-ERP-Lösungen typischerweise auf drei Plattformen an: Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP). Alle drei gehören US-Konzernen.

Im Frühjahr 2025 hat SAP seine Cloud-Produkte umbenannt: Was früher als „RISE with SAP" und „SAP S/4HANA Cloud Private Edition" bekannt war, heißt heute „SAP Cloud ERP Private". Die ehemalige „S/4HANA Cloud Public Edition" läuft jetzt als „SAP Cloud ERP". Die Marketing-Namen haben sich geändert. Die zugrundeliegende Infrastruktur nicht.

Egal welche Variante – SAP Cloud ERP, SAP Cloud ERP Private oder GROW with SAP für den Mittelstand – die operative Realität bleibt: Die Workloads laufen ganz überwiegend auf Hyperscaler-Infrastruktur. Bei „GROW with SAP" ist das sogar zwingend, weil ausschließlich öffentliche Cloud-Plattformen angeboten werden.

Selbst wenn das Rechenzentrum in Frankfurt steht, ändert das rechtlich nichts. Denn der entscheidende Faktor ist nicht der Standort der Server, sondern die rechtliche Beherrschung des Anbieters.

Warum „Datenstandort EU" keine Souveränität bedeutet

Hier wird es technisch wichtig – aber bleibt einfach. Drei Begriffe muss man auseinanderhalten:

Datenstandort ist der physische Ort, an dem die Daten gespeichert werden. „Hosted in Germany" oder „EU-Rechenzentrum" beschreiben den Datenstandort.

Datenherrschaft ist die Frage, wer rechtlich auf die Daten zugreifen kann. Die Herrschaft folgt dem Unternehmen, nicht dem Standort.

Datensouveränität ist die Kombination aus beidem plus operative Kontrolle (Wer hat Admin-Rechte? Wer verwaltet die Schlüssel? Wer kann den Support kontaktieren?).

Der US CLOUD Act von 2018 verpflichtet US-Unternehmen, auf Anordnung amerikanischer Behörden Daten herauszugeben – auch wenn diese physisch in Europa gespeichert sind. Microsoft, Amazon und Google sind US-Unternehmen. Damit unterstehen sie diesem Gesetz.

Ein deutscher Mittelständler, dessen SAP-Daten in einem AWS-Rechenzentrum in Frankfurt liegen, ist also in einer paradoxen Situation: Die Daten sind physisch in Deutschland. Die rechtliche Zugriffsmöglichkeit aber liegt in den USA.

Das Pikante: Diese rechtliche Konstellation kann durch Verträge nicht aufgehoben werden. Es spielt keine Rolle, welche Standardvertragsklauseln, welche „EU Sovereign Cloud"-Label oder welche Compliance-Zertifikate der Anbieter vorlegt – das US-Recht bricht. Das hat zuletzt ein Rechtsgutachten der Universität zu Köln (2025) ausdrücklich bestätigt und wird mittlerweile von der EU-Aufsicht im Finanzsektor explizit so eingestuft.

Die Asymmetrie: Warum bei KI gefragt wird, bei SAP nicht

Wenn die rechtliche Lage so klar ist – warum wird sie bei KI scharf diskutiert und bei SAP übersehen?

Es gibt drei Gründe für diese Asymmetrie. Alle drei sind nachvollziehbar, aber keiner ist tragfähig.

Grund 1: KI ist neu und sichtbar. ChatGPT ist 2022 in die öffentliche Wahrnehmung explodiert. Jede Datenflussskizze einer neuen KI-Anwendung muss heute durch Datenschutz, Betriebsrat, manchmal die Geschäftsführung. Das ist gut und richtig – aber es lenkt die Aufmerksamkeit auf das Neue.

SAP hingegen ist seit zwanzig Jahren „normal". Niemand hinterfragt mehr, wo SAP läuft. Es ist Teil der IT-Landschaft geworden, und wenn der Anbieter sagt „wir migrieren in die Cloud", wird das als technische Modernisierung wahrgenommen, nicht als datenschutzrechtliche Entscheidung.

Grund 2: KI verarbeitet einzelne Datensätze, SAP verwaltet die ganze Realität. Eine KI-Anwendung sieht typischerweise einen Ausschnitt: eine Anfrage, ein Dokument, eine Auswertung. SAP enthält dagegen die vollständigen Geschäftsdaten – Mitarbeiterstammdaten mit Gehältern, sämtliche Kundenbeziehungen, jede Bestellung, jede Marge, jede Lieferantenkondition.

Der Sicherheitsfokus auf KI ist also paradoxerweise dort hoch, wo das Datenvolumen niedrig ist. Beim ERP-System mit der maximalen Datenkonzentration wird er entspannter.

Grund 3: Bei KI gibt es etablierte Alternativen, bei SAP scheinbar nicht. Wer KI macht, kann zwischen amerikanischen, europäischen und Open-Source-Modellen wählen. Diese Wahlmöglichkeit lädt zur Diskussion ein.

Bei SAP entsteht der Eindruck einer Alternativlosigkeit: „SAP läuft halt auf Hyperscalern, was sollen wir machen?" Das ist ein Mythos. Es gibt sehr wohl Alternativen – sie sind nur weniger bekannt, dazu gleich mehr.

Was sich gerade ändert: Drei Bewegungen, die das Bild kippen

Bisher konnte man die Asymmetrie aushalten. „Steht im Vertrag, ist compliant" hat lange als Antwort gereicht. Das ändert sich gerade rapide, getrieben von drei parallelen Entwicklungen.

Bewegung 1: Die Aufsicht wird konkret

In der Finanzbranche ist die Schonzeit vorbei. Seit Januar 2025 ist die DORA-Verordnung (Digital Operational Resilience Act) vollständig anwendbar. Sie verlangt von Banken, Versicherern und ihren IT-Dienstleistern eine belastbare Steuerung von IKT-Drittparteienrisiken. Konkret: Wer SAP auf US-Hyperscaler-Infrastruktur betreibt, muss nachweisen können, dass das Risiko ausländischer Datenzugriffe kontrollierbar ist.

Das oben erwähnte Rechtsgutachten der Universität zu Köln stellt explizit fest, dass Standardvertragsklauseln und „EU Sovereign Cloud"-Label diese Anforderung nicht erfüllen. Die BaFin und die europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) prüfen das mittlerweile aktiv.

Parallel wird der C5-Kriterienkatalog des BSI weiterentwickelt – C5:2025 verschärft die Anforderungen an Cloud-Betriebsmodelle. Die European Union Agency for Cybersecurity (ENISA) arbeitet an einem EU-Cybersecurity-Certification-Scheme for Cloud Services, das Souveränitätskriterien explizit aufnimmt.

Die Botschaft an Entscheider: „Wir haben einen Vertrag, der ‚compliant' verspricht" reicht in regulierten Branchen schon heute nicht mehr aus. In den nächsten zwei Jahren wird das auf weitere Branchen ausstrahlen.

Bewegung 2: Auf staatlicher Ebene wird Souveränität ernst gemacht

Frankreich hat im Januar 2026 angeordnet, Microsoft Teams und Zoom bis 2027 in der gesamten Verwaltung durch die eigene Plattform „Visio" zu ersetzen. Im April 2026 folgte die Direktive, alle 2,5 Millionen Behördenrechner auf Linux zu migrieren. 80.000 Mitarbeiter der nationalen Krankenkasse sind bereits auf europäische Tools umgestellt. Die Region Île-de-France hat 550.000 Schul-Accounts von Microsoft 365 auf eine französische Plattform verlagert.

In Deutschland hat Schleswig-Holstein bereits fast 80 Prozent seiner 30.000 Behörden-Arbeitsplätze auf Linux migriert – und allein dadurch 15 Millionen Euro Lizenzkosten gespart. Bremen, Niedersachsen und weitere Bundesländer prüfen vergleichbare Schritte.

Was hat das mit Mittelstands-ERP zu tun? Drei Effekte:

Erstens schaffen diese staatlichen Initiativen einen Markt für europäische Anbieter. STACKIT (Schwarz-Gruppe), IONOS Cloud, OVH, T-Systems und Outscale wachsen, weil sie Nachfrage haben. Was vor zwei Jahren noch ein Nischen-Angebot war, ist heute eine ernstzunehmende Plattform-Option.

Zweitens werden öffentliche Ausschreibungen zunehmend Souveränität fordern. Mittelständler, die für die öffentliche Hand arbeiten, müssen darauf antworten können.

Drittens entstehen Standards und Werkzeuge: Der „Sovereign Cloud Stack" als Open-Source-Initiative, Interoperabilitäts-Standards wie Open-Interop, gemeinsame Entwicklungen wie Gaia-X.

Bewegung 3: SAP selbst reagiert

SAP hat das Souveränitätsthema erkannt und investiert. Mit der Delos Cloud existiert seit 2024 eine gemeinsame Initiative von SAP, Microsoft und Arvato Systems, die eine souveräne Cloud-Plattform speziell für die deutsche Verwaltung aufbaut. Ziel: SAP-Workloads auf einer Azure-basierten, aber rechtlich von Microsoft unabhängigen Infrastruktur, die unter deutschem Recht steht.

Daneben gibt es Pläne, weitere RISE-Angebote auf „souveränen Azure-Varianten" zu betreiben – ein Modell, das den Hyperscaler als Technologie-Lieferanten nutzt, aber Datenherrschaft, Schlüsselverwaltung und Admin-Zugriff in europäische Hände legt.

Für Mittelständler bedeutet das: Die Alternativen werden konkreter. „SAP geht nur auf US-Hyperscalern" stimmt nicht mehr. Es gibt mittlerweile gestufte Modelle – von der vollen Hyperscaler-Lösung über souveräne Azure-Varianten bis zur Delos Cloud für besonders sensitive Workloads.

Aber: Diese Entscheidungen muss man aktiv treffen. Sie passieren nicht automatisch.

Was Entscheider jetzt prüfen sollten

Aus all dem ergeben sich drei konkrete Prüfpunkte, die jeder CEO oder Geschäftsführer beantworten können sollte – unabhängig von Branche.

Prüfpunkt 1: Wo läuft unser SAP wirklich? Nicht „wir haben einen Vertrag mit Anbieter X". Sondern: Welcher Hyperscaler steckt unter unserem RISE-Vertrag? Welches Rechenzentrum, in welchem Land, unter welchem Recht? Wer hat Schlüsselhoheit für die Datenbank? Wer kann technisch auf die Maschinen zugreifen?

Wenn die Antworten in der IT-Abteilung nicht auf Anhieb verfügbar sind, ist das selbst eine Antwort.

Prüfpunkt 2: Welche regulatorischen Anforderungen werden uns in den nächsten 24 Monaten treffen? Für Finanzdienstleister: DORA ist da. Für KRITIS-Betreiber: NIS2 ist umzusetzen. Für Auftragnehmer der öffentlichen Hand: Souveränitätsanforderungen werden in Ausschreibungen wandern. Für alle: Die Aufsichtspraxis verschärft sich.

Wer das jetzt nicht prüft, riskiert, in 18 Monaten eine aufwändige Notfall-Migration durchführen zu müssen – statt einer planbaren strategischen Verlagerung.

Prüfpunkt 3: Wie austauschbar ist unser Stack? Die wichtigste strategische Frage. Modular gebaute SAP-Landschaften können Komponenten austauschen, wenn sich Recht oder Anbieterlandschaft verschiebt. Monolithisch in einem Hyperscaler-Ökosystem verwurzelte Landschaften haben keine Optionen mehr – nur noch teure Migrationen.

Wer heute Architekturentscheidungen trifft, sollte „Austauschbarkeit" explizit als Bewertungskriterium einführen. Nicht aus Ideologie, sondern aus Risikomanagement.

Die Verbindung zur KI-Debatte

Hier schließt sich der Kreis – und hier liegt der eigentliche Grund, warum dieser Artikel Teil einer größeren Geschichte ist.

In unserer Serie „KI für Entscheider" haben wir in sechs Teilen gezeigt, was hinter der KI-Begeisterung wirklich steckt: dass „mit KI gebaut" noch keine Software ist (Teil 1), dass ChatGPT-Nutzung keine KI-Strategie ist (Teil 2), dass Generalisten nie Spitzenleistung erbringen (Teil 3), dass die KI selbst nur ein zustandsloser Baustein in einem Software-Konstrukt ist (Teil 4), dass sie nicht „lernt", sondern Wissen explizit eingebaut werden muss (Teil 5), und wie man als Entscheider den ersten konkreten Schritt findet (Teil 6).

Eine zentrale Erkenntnis aus dieser Serie: Wer KI-Anwendungen für sein Unternehmen baut, muss tief in seine Daten greifen. Kundendaten, Vertragstexte, interne Dokumentation, Prozessbeschreibungen – alles wandert in „den Notizordner", auf den die KI zugreift. Damit landet noch mehr unternehmenskritisches Wissen in derselben Cloud, in der oft schon das SAP-System läuft.

Wer also die Architekturfrage bei SAP nicht stellt, vertieft das Problem mit jedem KI-Projekt. Die beiden Themen gehören untrennbar zusammen: Souveräne KI ohne souveräne Datenbasis ist eine Illusion. Souveräne Datenbasis ohne souveränes ERP ist ebenfalls eine Illusion.

Die gute Nachricht: Es gibt einen kohärenten Weg. Wer Architektur als strategische Frage versteht, kann beide Themen in einem Aufwasch lösen. SAP auf souveräner Infrastruktur. KI auf europäischen Modellen. Daten unter eigener Kontrolle. Modular, austauschbar, anpassbar.

Genau das bauen wir bei dataso.

Wie dataso souveräne Architekturen baut

Bei dataso ist Souveränität keine Marketingaussage, sondern eine Architekturentscheidung. Wir bauen Software und KI-Anwendungen für den deutschen Mittelstand auf europäischer Infrastruktur – primär STACKIT (Schwarz-Gruppe), je nach Anforderung ergänzt durch IONOS, OVH, T-Systems oder On-Premise.

Was uns von vielen anderen unterscheidet: Wir denken die Architektur vor dem Anbieter. Wir bauen modular, damit Komponenten austauschbar bleiben. Wir trennen Anwendung von Infrastruktur, damit Sie nicht in einem Lock-in landen. Wir nutzen moderne KI-Modelle, ohne uns an einen einzelnen Anbieter zu binden.

Konkret heißt das: Wenn morgen die EuGH-Rechtsprechung kippt, die DORA-Auslegung verschärft wird oder ein Anbieter seine Preise verdoppelt – Ihre Anwendung läuft weiter. Sie haben Optionen.

Wenn Sie wissen wollen, wie Ihre aktuelle SAP- und KI-Architektur unter Souveränitätsgesichtspunkten dasteht – und welche konkreten nächsten Schritte sinnvoll wären – sprechen Sie mit uns. Ein erster Architektur-Check ist kostenlos und in 30 Minuten erledigt.