Schwarz-Digits-Geschäftsführerin zu Digitaler Souveränität: „Die IT-Abteilung will in der Regel nichts ändern”
zent der europäischen Cloud-Infrastruktur betreibt laut t3n eine Handvoll US-Konzerne.

Claudia Alsdorf, Geschäftsführerin Business Development bei Schwarz Digits, beziffert deren technologischen Vorsprung im Podcast t3n Arbeit in Progress auf über zehn Jahre. Für IT-Verantwortliche in DACH liefert das Gespräch zwei harte Parameter: ein reales Wechsel-Szenario der Schwarz-Gruppe von Microsoft zu Google und ein Architekturmuster mit gespiegelter Stackit-Cloud als Plan B gegen den US Cloud Act.
Marktanteil und Zeitvorsprung
Alsdorf nennt 70 Prozent als Indikator für die Abhängigkeit europäischer Cloud-Workloads. Der Zeitvorsprung der US-Anbieter liege bei über zehn Jahren. Beide Werte sind keine Prognosen, sondern Status quo aus Sicht von Schwarz Digits zum Zeitpunkt des Podcasts beim Käpsele Innovation Festival 2026 in Freiburg. Alsdorf selbst wechselte von Microsoft und SAP zu Schwarz Digits und kennt beide Seiten des Verhandlungstischs.
Auslöser: 11 Prozent Preiserhöhung
Die Schwarz-Gruppe mit 600.000 Mitarbeitern zählte zu den großen Microsoft-Kunden. Auslöser des Wechsels war laut Alsdorf eine Preiserhöhung von elf Prozent. Microsoft habe auf Verhandlungen mit „Keep it or leave it" reagiert. Schwarz Digits habe daraufhin eine Alternative mit Verhandlungsspielraum gesucht und sie bei Google gefunden. Voraussetzung war laut Alsdorf die explizite Zusicherung, dass die Datenhoheit auf der Stackit-Cloud verbleibt.
Spiegel-Architektur als Plan B
Kern des Modells: Alle produktiven Daten werden auf die souveräne Stackit-Cloud gespiegelt. Sollte ein Zugriff über den US Cloud Act erfolgen oder ein Kill-Switch greifen – der Internationale Gerichtshof in Den Haag habe dies laut Alsdorf erfahren –, bleiben die Daten unter europäischer Kontrolle. Alsdorf definiert digitale Souveränität in diesem Kontext als Handlungsfreiheit mit nachweisbarem Plan B, nicht als ideologischer Verzicht auf US-Technologie.
Datenpfade jenseits des Standorts
Alsdorf grenzt Standort und Verarbeitung strikt ab. Bei US-Anbietern verließen auch Telemetrie- und Maintenance-Daten den europäischen Rechtsraum, selbst wenn die Datenzentren lokal stehen. Der Begriff Souveränitäts-Washing beschreibt diese Lücke: physisch Europa, juristisch USA. Für Architektur-Reviews bedeutet das: Der Standortparameter allein genügt nicht, der Verarbeitungspfad muss im Datenflussdiagramm ausgewiesen sein.
Engpass öffentliche Verwaltung
Alsdorf nennt den Public Sector als aktuell größte Begrenzung für souveräne Projekte. Deutschland liege bei der Digitalisierung weit hinten, der Rückstand erzeuge mittlerweile einen messbaren Wettbewerbsnachteil. Schwarz Digits stoße dort auf langsamere Beschaffungszyklen als im eigenen Konzernumfeld. Daraus folgt für den IT-Großhandel und angeschlossene Systemhäuser: Souveräne Stacks skalieren in der Privatwirtschaft schneller als im öffentlichen Sektor.
Vier Prüfparameter für die eigene Infrastruktur
| Parameter | Messgröße | Sollwert für Souveränität |
|---|---|---|
| Verarbeitungsort | Standort der Compute-Instanz, nicht der Hardware | Europäische Jurisdiktion, vertraglich fixiert |
| Datenpfad | Telemetrie, Logs, Support-Daten | Vollständig innerhalb EU/EWR |
| Exit-Klausel | Vertragslaufzeit, Preisanpassungsrecht | Kurzfristige Kündigung, definierter Datenexport |
| Plan-B-Stack | Sekundäre Cloud oder Colocation | Spiegel produktiver Daten, RPO/RTO dokumentiert |
Zusätzlich zu prüfen: SLA-Verhalten bei externer Anordnung, Audit-Rechte gegenüber Sub-Prozessoren, Standort der Backups, Verschlüsselungsschlüssel-Hoheit.
Konsequenz für die Beschaffung
Wer Server, Storage oder Colocation-Kapazität einkauft, sollte Angebote mit Lieferantenstack und Verarbeitungsstandort getrennt bewerten. Hyperscaler-Verträge sind nicht per se unsouverän, aber sie erfordern einen dokumentierten Spiegel-Pfad mit eigener Schlüsselhoheit. Wer diesen Pfad nicht besitzt, betreibt faktisch einen Single Point of Failure unter fremder Jurisdiktion – und das ist der eigentliche operative Risikofaktor, nicht der Markenname des Anbieters.