Amazon und Alphabet: negativer Cashflow, lange Bindung
Eva Mickler
6 Min. Lesezeit Zwei der drei großen Cloud-Anbieter wiesen zuletzt negativen freien Cashflow aus. Amazon ...
Viele DACH-Konzerne stecken zwischen Souveränitätsanforderungen, Werks-OT und globalen Cloud-Standards. Wer Standort-IT nur als Infrastrukturfrage behandelt, unterschätzt Governance, Betriebsmodell und Capex-Steuerung. Entscheider brauchen ein Betriebsmodell, das beides steuert und ideologische Plattformwahl ersetzt.
Das Wichtigste in Kürze
VerwandtDigitale Souveränität 2026: Delos Cloud, Gaia-X, EU Data Act / Sovereign Cloud: Europas Weg zur digitalen Souveränität
CIO und CDO steuern heute drei Logiken gleichzeitig. Konzernplattformen drängen auf Standardisierung, Skaleneffekte und globale Release-Zyklen. Werks- und Standortsysteme verlangen Verfügbarkeit, deterministische Latenzen und enge Kopplung an Maschinen, Leitsysteme und Schichtübergaben. Regulatorische und vertragliche Vorgaben zu Datenresidenz, Auftragsverarbeitung und Prüfpfaden setzen zusätzliche Grenzen. Daraus folgt noch keine Architektur.
Das Spannungsfeld entsteht, wenn eine der drei Logiken zur alleinigen Leitplanke wird. Eine pauschale Cloud-First-Vorgabe kann OT-nahe Workloads in Latenz-, Wartungs- und Freigabeprobleme führen. Eine pauschale On-Prem-Vorgabe verteuert Standardanwendungen und erschwert Patch- und Identitätsdisziplin. Souveränität im IT-Sinne ist kein politisches Bekenntnis. Sie ist die Fähigkeit, Standort, Verarbeitungsort, Betreiber und Exit-Pfad verbindlich zu steuern.
Praktisch bedeutet das: Datenklassen, Verarbeitungsorte und Betriebsverantwortung müssen vor der Plattformwahl festliegen. Der BSI-Kriterienkatalog C5 verlangt von Cloud-Anbietern in der Systembeschreibung Transparenz zu Gerichtsstand, Orten der Datenverarbeitung und behördlichen Auskunftspflichten. Die Fassung C5:2026 schärft zusätzlich die technische Umsetzung von Souveränität und Mandantentrennung. Parallel regeln Kapitel V der DSGVO (Art. 44 ff.) den Drittlandtransfer personenbezogener Daten. Der EU Data Act (Verordnung (EU) 2023/2854), anwendbar seit September 2025, ergänzt Cloud-Wechselrechte und Schutzmechanismen gegen unzulässige Drittstaatszugriffe auf in der EU gehaltene nicht personenbezogene Daten. Werden diese Festlegungen erst nach der Cloud-Migration nachgezogen, steigen Nachbesserungskosten und Audit-Risiken. Das gilt besonders dort, wo Produktionsdaten, Personaldaten und Lieferantenschnittstellen im selben Stack landen.
Ein belastbares Betriebsmodell startet bei Workload-Klassen, nicht bei Anbietern. Sinnvoll sind mindestens fünf Klassen: unternehmensweite SaaS- und Collaboration-Dienste, Kernsysteme mit hohen Integrationsanforderungen, analytische und KI-Workloads, edge-nahe Steuerungs- und Sensorik-Workloads sowie regulierte oder standortgebundene Verarbeitungen. Jede Klasse braucht Kriterien zu Latenz, Datenklassifikation, Änderungsfrequenz, Betreiberfähigkeit und Exit-Kosten.
Cloud eignet sich dort, wo Elastizität, globale Identitäten und standardisierte Betriebsprozesse den Nutzen treiben. Edge und lokale Rechenkapazität eignen sich dort, wo Produktionstakte, Offline-Fähigkeit oder enge OT-Kopplung den Takt vorgeben. Hybrid ist die planvolle Zuordnung von Workloads zu Orten und Betriebsformen. Orientierung liefern etablierte Referenzmodelle: Die Funktionshierarchie nach ISA-95 (IEC 62264) trennt physischen Prozess, Steuerung, Fertigungsausführung und Unternehmenssysteme. Die Normenreihe ISA/IEC 62443 ergänzt das um Zonen und Conduits, also Sicherheitszonen mit vergleichbaren Schutzanforderungen und kontrollierte Kommunikationspfade dazwischen.
Wer Workload-Klassen sauber schneidet, verhindert zwei typische Fehler. Erstens die Migration kritischer werksnaher Systeme allein, weil der Konzernstandard Cloud heißt. Zweitens die Blockade unproblematischer Standard-Workloads hinter Souveränitätsargumenten, die technisch und rechtlich nicht greifen. Die Entscheidungsfrage lautet: welche Steuerung, welcher Ort und welcher Betreiber für diese Klasse?
Ohne klare Rollen zerfällt Hybrid in Schatten-IT und Doppelarbeit. Konzern-IT setzt Architekturprinzipien, Identitäts- und Sicherheitsbaselines, Beschaffungsrahmen und Plattformstandards. Die regionale IT übersetzt Konzernvorgaben in länderspezifische Compliance, Vertrags- und Betriebsrealität. Die Werksebene verantwortet OT-Nähe, Schichtbetrieb, lokale Störungen und die Schnittstelle zu Instandhaltung und Produktion.
Die Schnittstelle muss formalisiert werden. Change- und Release-Rechte, Incident-Ownership und Freigabewege für OT-relevante Änderungen gehören in ein Betriebsmodell mit klaren Eskalationspfaden. Identitäten, Netzwerkzonen und Logging dürfen nicht je Standort neu erfunden werden. Gleichzeitig braucht das Werk Entscheidungsraum für taktnahe Systeme, die nicht im Konzern-Release-Takt laufen können.
Finanziell trennt sich Capex von Opex entlang derselben Rollen. Konzernplattformen lassen sich oft als geteilte Services budgetieren. Standortnahe Infrastruktur und OT-Kopplung bleiben eher investitionsgetrieben und benötigen mehrjährige Instandhaltungs- und Modernisierungsplanung. Öffentliche Unternehmensbeispiele bestätigen die Trennung von Steuerungsebenen: Volkswagen baut mit der Group Private Cloud 2.0 auf Basis der T Cloud Private von T-Systems eine zentrale Plattform für Unternehmensanwendungen und betont laut Konzern-IT-Vorständin Hauke Stars die Kombination aus Partnerschaften und eigener Infrastruktur. Cloud-only ist dort ausdrücklich nicht vorgesehen. Parallel betreibt Volkswagen produktionsnahe Workloads über die Digitale Produktionsplattform mit AWS. Siemens beschreibt am Motorenwerk Bad Neustadt die Konvergenz von IT und OT als standortnahen Betriebsfall mit datengetriebener Fertigung. Ohne diese Rollen- und Budgettrennung entstehen Schattenbudgets und konkurrierende Prioritäten zwischen Werk und Zentrale.
Das Deutschland-Setup trägt typische Beschaffungsrisiken. Lange Lieferzeiten für Server, Netzwerk und OT-Hardware treffen auf enge Wartungsfenster in der Produktion. Rahmenverträge mit globalen Hyperscalern und lokalen Hostern laufen parallel und erzeugen Inkonsistenzen bei SLA, Audit-Rechten und Exit-Klauseln. Personalengpässe in OT-nahen Betriebsrollen verstärken die Abhängigkeit von Integratoren und Hersteller-Support.
Betriebsrisiken folgen der Architektur. Getrennte Identitäten zwischen IT und OT erhöhen Angriffsflächen und erschweren forensische Nachvollziehbarkeit. Unklare Datenresidenz in Backup-, Logging- und KI-Pipelines erzeugt spätere Korrekturen. Patch-Staus an edge-nahen Systemen entstehen, wenn Sicherheitsupdates nicht mit Produktionsfreigaben abgestimmt sind. Das BSI betont in seinen ICS- und OT-Empfehlungen, dass OT längere Betriebszeiten, seltene Wartungsfenster und Echtzeitanforderungen hat. Office-IT-Schutzmaßnahmen lassen sich deshalb nur bedingt übertragen. Die BSI-„Grundsätze der OT-Cybersicherheit“ (2024) richten sich an Entscheider und fordern ganzheitliche Steuerung von Planung bis Betrieb. ISA/IEC 62443 liefert mit Zonen, Conduits und dem Technical Report 62443-2-3 konkrete Baselines für Segmentierung und Patch-Management in industriellen Automatisierungs- und Steuerungssystemen. Der IT-Grundschutz-Baustein IND.1 des BSI ergänzt das um Anforderungen an Prozessleit- und Automatisierungstechnik.
Sourcing muss deshalb Architektur folgen, nicht umgekehrt. Multi-Cloud aus reinem Verhandlungsreflex verteuert Betrieb und Governance, wenn Workload-Klassen und Datenflüsse nicht vorab geschnitten sind. Lokale Colocation oder souveräne Hosting-Varianten helfen nur, wenn Betriebsprozesse, Schlüsselverwaltung und Wiederanlauf getestet und budgetiert sind. Der CIO steuert hier Residualrisiken und Exit-Fähigkeit.
Ein nutzbarer Entscheidungsbaum beginnt mit der Daten- und Prozessklasse. Zuerst klären Entscheider, ob der Workload personenbezogene, schutzbedürftige oder produktionskritische Daten verarbeitet und welche Residenz- und Prüfpflichten greifen. Danach folgt die Latenz- und Verfügbarkeitsfrage: Reicht eine regionale Cloud-Zone? Braucht es Werksnähe oder Offline-Fähigkeit? Anschließend kommen Änderungsfrequenz und Integrationsdichte zu MES (Manufacturing Execution System), SCADA (Supervisory Control and Data Acquisition), ERP und Identitätsdiensten.
Erst danach fällt die Ort- und Betreiberentscheidung. SaaS ist zulässig, wenn Datenklasse, Vertrag und Exit passen. Private oder virtuelle private Cloud eignet sich für integrierte Kernsysteme mit hohen Steuerungsanforderungen. Edge- und On-Prem-Instanzen greifen bei OT-Kopplung, harten Latenzgrenzen oder standortgebundenen Freigaben. Hybrid entsteht, wenn Datenvorverarbeitung lokal und Analytics oder Training zentral laufen und die Schnittstellen standardisiert sind.
Der Baum endet mit Betriebsnachweis. Wer betreibt, wer patcht, wer eskaliert und wie der Wiederanlauf innerhalb welcher Zeit gelingt, muss vor Go-live beantwortet sein. Die ISO 22301 zum Business Continuity Management definiert dazu die zentralen Zielgrößen RTO (Recovery Time Objective, maximale tolerierbare Ausfallzeit) und RPO (Recovery Point Objective, maximal tolerierbarer Datenverlust). Fehlt dieser Nachweis, ist die Architektur unvollständig, auch wenn die Zielplattform formal freigegeben ist.
Für CIO und CDO ist die Konsequenz klar: Standort-IT wird zum Steuerungsgegenstand mit Workload-Klassen, Rollenmodell und Entscheidungsbaum. Cloud bleibt Werkzeug. Souveränität bleibt Steuerungsfähigkeit. OT bleibt Betriebsrealität. Wer diese drei Ebenen im Betriebsmodell verbindet, reduziert Capex-Fehlallokation und schafft belastbare Hybrid-Entscheidungen für den Deutschland-Modus.
Datenklassen, Verarbeitungsorte und Betriebsverantwortung müssen vor der Plattformwahl festliegen. C5:2026 verlangt Transparenz zu Gerichtsstand, Datenorten und Mandantentrennung. Kapitel V der DSGVO regelt Drittlandtransfer, der EU Data Act ergänzt seit September 2025 Wechselrechte und Schutz vor unzulässigen Drittstaatszugriffen. Nachträgliche Korrekturen treiben Nachbesserungskosten und Audit-Risiken, sobald Produktions-, Personal- und Lieferantendaten im selben Stack landen.
Lange Lieferzeiten für Server, Netzwerk und OT-Hardware treffen auf enge Wartungsfenster in der Produktion. Parallel laufende Rahmenverträge mit Hyperscalern und lokalen Hostern erzeugen Inkonsistenzen bei SLA, Audit-Rechten und Exit-Klauseln. Personalengpässe in OT-nahen Betriebsrollen verstärken die Abhängigkeit von Integratoren und Hersteller-Support. Sourcing folgt der Architektur, sobald Workload-Klassen und Datenflüsse geschnitten sind.
Change- und Release-Rechte, Incident-Ownership und Freigabewege für OT-relevante Änderungen gehören in ein Betriebsmodell mit klaren Eskalationspfaden. Identitäten, Netzwerkzonen und Logging bleiben konzernweit standardisiert. Gleichzeitig behält das Werk Entscheidungsraum für taktnahe Systeme außerhalb des Konzern-Release-Takts. Capex und Opex folgen derselben Rollenlogik und trennen geteilte Konzernservices von investitionsgetriebener Standortinfrastruktur.
Wenn der Betriebsnachweis vor Go-live fehlt. Wer betreibt, wer patcht, wer eskaliert und wie der Wiederanlauf gelingt, muss verbindlich beantwortet sein. ISO 22301 definiert dazu RTO als maximale tolerierbare Ausfallzeit und RPO als maximal tolerierbaren Datenverlust. Ohne diese Zielgrößen und klare Ownership-Pfade bleibt die Architektur unvollständig.
Weiterlesen auf Digital Chiefs
Digital ChiefsToken-OPEX: Inference steuert, nicht das Seat-BudgetDigital ChiefsHardware schlägt Software-Deals – Capex neu sortierenDigital ChiefsDie Rechnung für zehn Jahre InsellösungenMehr aus dem MBF Media Netzwerk
Bildquelle: KI-generiert (Juli 2026)
Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Turnstile. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen