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

Viele Mittelständler blockieren KI-Projekte aus Datenschutzgründen und betreiben gleichzeitig ihr komplettes ERP auf der Infrastruktur eines US-Konzerns. Beide Male geht es um dieselben Daten, nur dass im ERP alles in voller Tiefe liegt, während eine KI-Anwendung meist Auszüge sieht.

Die Asymmetrie: Bei KI wird jede Skizze zerlegt, beim ERP reicht ein Häkchen

Wenn ein Mittelständler heute eine KI-Anwendung plant, nimmt der Datenschutzbeauftragte jede Datenflussskizze auseinander. Verschiebt derselbe Betrieb sein SAP-System in die Cloud, reicht oft ein Häkchen im Lenkungskreis und ein Verweis auf die Zertifikate des Anbieters. Das Pikante: Personalakten, Kundenstämme, Margen und Lieferantenverträge liegen im ERP konzentriert und vollständig. Der Sicherheitsfokus ist also dort am höchsten, wo das Datenvolumen am kleinsten ist.

Für Sie als Datenschutz-, Compliance- oder Risikoverantwortliche ist das der Punkt, an dem eine Prüfung ansetzen sollte, die bislang niemand verlangt hat.

Wo SAP-Daten heute wirklich liegen

SAP bietet seine Cloud-ERP-Varianten in aller Regel auf den Plattformen von Amazon, Microsoft und Google an. Die Produktnamen haben sich mehrfach geändert, die Infrastruktur darunter nicht. Bei den Angeboten für den Mittelstand ist die öffentliche Cloud eines Hyperscalers sogar der einzige vorgesehene Weg.

Selbst wenn das Rechenzentrum in Frankfurt steht, ändert das rechtlich nichts. Entscheidend ist nicht der Standort der Server, sondern wer den Anbieter rechtlich beherrscht.

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

Drei Begriffe gehören auseinandergehalten. Der Datenstandort ist der physische Ort der Speicherung; „Hosted in Germany" beschreibt genau das. Die Datenherrschaft ist die Frage, wer rechtlich auf die Daten zugreifen kann, und sie folgt dem Unternehmen, nicht dem Standort. Datensouveränität ist beides zusammen plus operative Kontrolle: Wer hat Administrationsrechte, wer verwaltet die Schlüssel, wer bedient den Support?

Der US CLOUD Act verpflichtet US-Unternehmen, auf Anordnung amerikanischer Behörden Daten herauszugeben, auch wenn diese in Europa gespeichert sind. Ein deutscher Mittelständler mit SAP-Daten in einem Frankfurter Rechenzentrum eines US-Konzerns ist damit in einer paradoxen Lage: Die Daten liegen physisch in Deutschland, die rechtliche Zugriffsmöglichkeit in den USA. Standardvertragsklauseln und „Sovereign Cloud"-Label ändern daran nichts, weil ein Vertrag das Gesetz des Herkunftslandes nicht aufhebt.

Warum bei KI gefragt wird und bei SAP nicht

KI ist neu und sichtbar. Jede neue Anwendung muss durch Datenschutz und Betriebsrat, und das ist richtig, lenkt die Aufmerksamkeit aber auf das Neue. SAP ist seit Jahrzehnten normal; eine Cloud-Migration wird als technische Modernisierung wahrgenommen, nicht als datenschutzrechtliche Entscheidung.

Dazu kommt der Eindruck der Alternativlosigkeit. Bei KI kann man zwischen amerikanischen, europäischen und offenen Modellen wählen, das lädt zur Diskussion ein. Bei SAP heißt es: „Läuft halt auf Hyperscalern, was sollen wir machen?" Das stimmt so nicht mehr. Europäische Betreiber wie STACKIT, IONOS oder T-Systems bauen ihr Angebot aus, und SAP selbst arbeitet mit Partnern an Betriebsmodellen, bei denen Datenherrschaft, Schlüsselverwaltung und Administration in europäischer Hand liegen. Diese Optionen muss man aber aktiv wählen. Sie kommen nicht von selbst.

Was die Aufsicht inzwischen verlangt

In der Finanzbranche ist die Schonzeit vorbei. Die Verordnung zur digitalen operationalen Resilienz (DORA) verlangt von Banken, Versicherern und ihren IT-Dienstleistern eine belastbare Steuerung der Risiken aus Drittanbietern. Wer SAP auf US-Infrastruktur betreibt, muss zeigen können, dass das Risiko eines ausländischen Datenzugriffs beherrscht wird. „Wir haben einen Vertrag, der Compliance verspricht" reicht dort nicht mehr. Für Betreiber kritischer Infrastruktur kommt NIS2 dazu, und in öffentlichen Ausschreibungen tauchen Souveränitätsanforderungen zunehmend auf. Es ist absehbar, dass diese Praxis auf weitere Branchen ausstrahlt.

Wer KI-Daten in der EU verarbeiten will, braucht ein souveränes ERP

Hier schließt sich der Kreis zur KI-Debatte. Wer KI-Anwendungen für sein Unternehmen baut, greift tief in die eigenen Daten: Kundendaten, Vertragstexte, Prozessbeschreibungen wandern in die Wissensbasis, aus der das Modell antwortet. Damit landet noch mehr kritisches Wissen in derselben Cloud, in der oft schon das ERP läuft. Wer die Architekturfrage bei SAP nicht stellt, vertieft das Problem mit jedem KI-Projekt. Souveräne KI ohne souveräne Datenbasis ist eine Illusion, und eine souveräne Datenbasis ohne souveränes ERP ebenfalls. Warum das Modell selbst dabei nur ein Baustein ist, zeigt Teil 4 unserer Serie „KI für Entscheider".

Drei Prüfpunkte für die nächste Sitzung

Wo läuft unser SAP wirklich? Nicht „wir haben einen Vertrag mit Anbieter X", sondern: Welcher Hyperscaler steckt darunter, in welchem Land, unter welchem Recht, und wer hat die Schlüsselhoheit über die Datenbank? Sind die Antworten in der IT-Abteilung nicht auf Anhieb verfügbar, ist das selbst eine Antwort.

Welche regulatorischen Anforderungen treffen uns in den nächsten zwei Jahren? DORA, NIS2, Ausschreibungsbedingungen. Wer das jetzt nicht prüft, riskiert eine hektische Notfallmigration statt einer planbaren Verlagerung.

Wie austauschbar ist unser Stack? Modular gebaute Landschaften können Komponenten wechseln, wenn sich Recht oder Anbieter verschieben. Monolithisch in ein Hyperscaler-Ökosystem verwurzelte Landschaften haben nur noch teure Migrationen vor sich.

Wir bauen Software und KI-Anwendungen auf europäischer Infrastruktur und trennen Anwendung von Infrastruktur, damit Komponenten austauschbar bleiben. Beantworten Sie die drei Prüfpunkte schriftlich, und bringen Sie das Ergebnis in den Potenzial-Check: eine halbe Stunde, kostenlos, und Sie wissen danach, ob Ihre SAP- und KI-Architektur unter Souveränitätsgesichtspunkten trägt oder wo sie nachgebessert werden muss. Potenzial-Check buchen