Cloud Governance: Compliance, KI und Souveränität vereinen

Cloud-Governance als Steuerungsmodell

Klassische IT-Governance greift hier zu kurz. Cloud-Umgebungen sind dynamisch und erfordern kontinuierliche Anpassung statt einmaliger Konfiguration. Gleichzeitig kommt mit künstlicher Intelligenz (KI) ein neuer Steuerungsgegenstand hinzu: Rechenlast, sensible Daten und automatisierte Entscheidungen wandern in dieselben Plattformen, deren Governance bislang auf Anwendungen und Infrastruktur ausgerichtet war.

Regulatorische Anforderungen treiben die Anbieterwahl

Die Einhaltung gesetzlicher Vorgaben rückt bei der Auswahl eines Cloud-Anbieters vor Kostenaspekte. Zur Datenschutz-Grundverordnung (DSGVO) treten Data Act, der AI Act, der Digital Operational Resilience Act (DORA) und die NIS2-Richtlinie. Dieses Geflecht erzeugt Zielkonflikte im Betrieb. Zugriffsrechte aus dem Data Act können mit Löschpflichten der DSGVO kollidieren, während Anforderungen an Datenvielfalt im AI Act dem Prinzip der Datenminimierung entgegenstehen.

Unternehmen benötigen daher integrierte Compliance-Konzepte, die verschiedene Rechtsakte zusammenführen und gegeneinander abwägen.

Branchenspezifische Vorgaben erhöhen die Anforderungen weiter. DORA verpflichtet Finanzunternehmen, ihre digitale Resilienz nachzuweisen und Risiken in der IKT-Lieferkette zu steuern. Für Versicherer regeln die Versicherungsaufsichtsrechtlichen Anforderungen an die IT (VAIT) Cloud-Auslagerungen samt belastbarer Exit-Strategien. Im Gesundheitswesen führt das Zusammenspiel von Medizinprodukteverordnung und AI Act dazu, dass KI-gestützte Software häufig in eine hohe Risikoklasse fällt. Maßgeschneiderte Konzepte sind die Folge, da ein einheitliches Regelwerk die Sonderpflichten einzelner Branchen nicht abdeckt.

Transatlantischer Datenverkehr bleibt ein Risikofaktor

Für den Datentransfer in die USA gilt seit 2023 das EU-US Data Privacy Framework. Eine Klage des Abgeordneten Philippe Latombe dagegen wurde 2025 abgewiesen, dennoch bleibt die Rechtslage volatil (Gericht der Europäischen Union, Rechtssache T-553/23). Frühere Abkommen wurden bereits aufgehoben, und ein Restrisiko besteht fort. Unternehmen mit hohem Schutzbedarf sollten deshalb eine Ausweichoption mit europäischen oder privaten Betriebsmodellen vorhalten.

Hinzu kommt der CLOUD Act, der US-Anbieter zur Herausgabe von Daten verpflichten kann – unabhängig vom Speicherort. Dies steht im Spannungsverhältnis zu Artikel 48 DSGVO. Ein abschließendes völkerrechtliches Abkommen fehlt weiterhin.

Technische Maßnahmen für Datensouveränität

Technische Schutzmaßnahmen gewinnen daher an Bedeutung. Zu den wichtigsten Schritten gehören unter anderem:

• Bring Your Own Key sichert die Schlüsselhoheit
• Confidential Computing schützt Daten während der Verarbeitung
• Clientseitige Verschlüsselung verhindert Anbieterzugriff
• BSI C5 schafft Transparenz über Zugriffsanfragen

Für hochsensible Daten bleibt clientseitige Verschlüsselung der stärkste Schutz.

Digitale Souveränität als Entscheidungsfaktor

Digitale Souveränität bezeichnet die Fähigkeit, technologische Entscheidungen eigenständig zu treffen und Daten sowie Infrastruktur selbstbestimmt zu kontrollieren. Der Bitkom-Leitfaden zur praktischen Umsetzung von Cloud-Souveränität beschreibt fünf Risikofelder, deren Steuerung über die Handlungsfähigkeit bestimmt:

• organisatorische Defizite
• technologische Abhängigkeiten
• Kompetenzkonzentration
• wirtschaftliche Bindungen ohne Exit-Strategie
• politische Eingriffe durch Drittstaaten

Souveränität bemisst sich an realen Wahlmöglichkeiten samt Exit-Fähigkeit, nicht an der geografischen Herkunft eines Anbieters.

In der Praxis verankern Unternehmen Souveränität als Prüfkriterium in Architektur- und Beschaffungsgremien. Ein Servicekatalog bildet die Grundlage, jeder Dienst wird nach Schutzbedarf bewertet und mit dem Angebot potenzieller Anbieter abgeglichen. Platform Engineering schiebt eine kontrollierbare Infrastrukturschicht ein, über die mehrere Anbieter und Modelle einheitlich gesteuert werden. Offene Standards, portable Datenformate und containerbasierte Deployments erleichtern den Wechsel zwischen Anbietern bei Bedarf.

Architektur und Exit-Strategien richtig planen

Ein belastbares Exit-Szenario beruht auf einem Design for Exit und regelmäßigen Migrationsproben, die Datenexport und Re-Deployment unter realen Bedingungen prüfen. Die Risikobewertung lässt sich mit bestehenden Verfahren des Unternehmensrisikomanagements verzahnen, womit Souveränität messbar und steuerbar wird.

Identitäten und automatisierte Durchsetzung als Kern der Kontrolle

Mit der Verlagerung von Workloads in die Cloud fällt der klassische Netzwerkperimeter weg. Identitäten übernehmen die Rolle der zentralen Kontrollinstanz. Maschinelle Identitäten spielen dabei eine große Rolle, denn Cloud-Anwendungen bestehen aus zahlreichen Machine-to-Machine-Verbindungen mit weitreichenden Berechtigungen. Identity Governance beantwortet nicht nur, wer Zugriff hat, sondern auch, was Zugriff hat. Multifaktor-Authentifizierung (MFA), rollen- und attributbasierte Zugriffssteuerung (RBAC) und das Prinzip der minimalen Berechtigung begrenzen die Angriffsfläche. KI und maschinelles Lernen bewerten den Zustand der Berechtigungen über große Cloud-Bestände hinweg und decken überflüssige oder riskante Rechte auf.

Governance automatisieren mit Policy as Code

Die Durchsetzung der Richtlinien gelingt vor allem über Automatisierung. Ein praxisnaher Ansatz arbeitet in einem fortlaufenden Zyklus aus dem Aufbau eines Governance-Teams, der Risikobewertung, der Dokumentation der Richtlinien, ihrer Durchsetzung und der laufenden Überwachung der Compliance. Die Verantwortung verteilt sich: das Governance-Team setzt die Strategie, Plattform- und Workload-Teams setzen sie in ihren Domänen um. Ein Vererbungsmodell über eine Hierarchie aus Verwaltungsgruppen sorgt dafür, dass Richtlinien von oben nach unten greifen. Ein Monitor-First-Ansatz beobachtet zunächst die Compliance, bevor restriktivere Kontrollen folgen. Policy as Code überträgt Governance-Regeln in versionierten Code und hält die Durchsetzung über Umgebungen hinweg konsistent. Eine zentrale Steuerung mit konsistenten Regeln senkt nach einer beauftragten Wirtschaftlichkeitsanalyse den Aufwand für die Bearbeitung von Sicherheitsvorfällen, auch über die automatische Filterung eines Teils der Meldungen.

Cloud-native und DevSecOps verändern Governance

Wie ein Unternehmen die Cloud nutzt, bestimmt, wo Governance ansetzt. Cloud-native bezeichnet eine Methode, bei der Anwendungen vollständig in der Cloud entstehen und laufen, aufgebaut aus Containern und kleinen, unabhängig entwickelbaren Microservices. Die Container orchestriert in der Regel Kubernetes, häufig als Managed Service. CI/CD-Pipelines liefern neue Releases kontinuierlich, Self-Healing und durchgängige Observability automatisieren den Betrieb, und Serverless-Modelle übernehmen Provisionierung und Skalierung. Eine DevOps-Kultur führt Entwicklung und Betrieb zusammen. Für die Governance bedeutet das eine Verschiebung von statischer Konfiguration hin zu kontinuierlichen, in den Code eingebauten Kontrollen, denn ein einzelnes Modul wird in Sekunden ausgerollt und verändert die Umgebung laufend.

Die Standortbestimmung gelingt über ein Stufenmodell, das den aktuellen Stand in mehreren Handlungsfeldern abbildet, darunter Unternehmenskultur, Team, Prozess, Architektur und Infrastruktur. Sicherheit gehört in diesem Modell in die Pipeline integriert, nicht nachgelagert. DevSecOps verbindet Sicherheitsprüfungen mit der kontinuierlichen Auslieferung, und eine Workload Protection sichert Container- und Multi-Cloud-Umgebungen über den gesamten Lebenszyklus ab. Sie deckt Konfigurationsfehler auf, macht Verbindungen zwischen Diensten transparent und erkennt auffälliges Verhalten frühzeitig. Eine BSI-C5-testierte Plattform aus zertifizierten Rechenzentren in Deutschland verbindet diesen automatisierten Betrieb mit den Souveränitätsanforderungen aus der Risikobewertung.

KI-Governance wird Pflichtaufgabe

Der KI-Einsatz ist kein reines IT-Thema mehr. Er berührt Datenschutz, Geschäftsgeheimnisse, Arbeitsrecht und Haftung und gehört in die Cloud-Governance integriert. Statt ein Werkzeug für alle Zwecke freizugeben, steuern Unternehmen den Einsatz über ein Datenklassenmodell.

Dieser Ansatz umfasst folgendes:

• öffentliche Daten: breite Nutzung
• interne Daten: kontrollierte Business-Tools
• vertrauliche Daten: Enterprise-Lösungen mit AV-Vertrag
• regulierte Daten: souveräne oder private Umgebungen

Die Nutzung orientiert sich am Use Case, nicht am Anbieter.

Der regulatorische Rahmen hat sich zuletzt verschoben. EU-Rat und EU-Parlament haben sich politisch auf den sogenannten AI Omnibus geeinigt der 2024 in Kraft ist. Danach sollen die Pflichten für Hochrisiko-KI-Systeme nach Anhang III erst ab dem 2. Dezember 2027 und für in regulierte Produkte eingebettete Hochrisiko-KI-Systeme erst ab dem 2. August 2028 gelten. Die Einigung ist bislang politisch und noch nicht im Amtsblatt der Europäischen Union veröffentlicht.

Unverändert gelten seit dem 2. Februar 2025 die Verbote bestimmter KI-Praktiken sowie die Pflicht zur Förderung von KI-Kompetenz. Auch der Bußgeldrahmen und das allgemeine Anwendungsdatum des AI Act zum 2. August 2026 bleiben bestehen. Ab diesem Zeitpunkt greifen zudem die Transparenzpflichten nach Art. 50, einschließlich der Kennzeichnung bestimmter KI-generierter Inhalte.

Unternehmen nehmen dabei je nach Einsatzszenario unterschiedliche Rollen im Sinne des AI Act ein; in vielen Anwendungsfällen handeln sie als Betreiber (Deployer) eines KI-Systems und müssen die entsprechenden Pflichten für den jeweiligen Use Case erfüllen.

Schatten-KI und Agenten kontrollieren

Ein eigener Risikobereich ergibt sich aus Schatten-KI und aus dem Einsatz autonomer Agenten. Nicht freigegebene Tools führen zu unkontrolliertem Abfluss von Daten ohne Vertragsgrundlage und ohne Protokollierung. Ein technisches Schichtenmodell aus Freigabeliste, Identitätssteuerung, einem KI-Gateway mit Prompt-Filtern, Data Loss Prevention (DLP) und durchgängigem Audit-Logging kanalisiert die Nutzung. Bei Agenten mit Zugriff auf mehrere Systeme verbinden sich harmlose Werkzeuge zu riskanten Kombinationen, zum Beispiel wenn ein Agent über eine manipulierte Anweisung in einem Dokument eine ungewollte Aktion auslöst. Least Privilege, getrennte Tool-Kontexte, ein Read-Only-Standard sowie Human Approval Gates für kritische Aktionen begrenzen den Schaden. Plattformseitig steuern Content-Filterung, Missbrauchsüberwachung und eine KI-Sicherheits-Baseline das Verhalten der Modelle.

KI Verändert Bedrohungslage und Cyberabwehr

Die Bedrohungslage wandelt sich. Agentenbasierte KI, automatisierte Ransomware und KI-gestützte Phishing- und Deepfake-Kampagnen skalieren Angriffe und senken die Einstiegshürde. Fähigkeiten, die bisher staatlichen Akteuren vorbehalten waren, werden breiter nutzbar.

KI-Modelle selbst werden zum Ziel, zum Beispiel über manipulierte Trainingsdaten oder Prompt Injection. Cloud-Governance sollte diese Vektoren in die Risikobewertung aufnehmen und die Absicherung der KI-Dienste mit derselben Sorgfalt behandeln wie die der übrigen Workloads.

Auf der Verteidigungsseite gehört KI in Security Operations Centern mittlerweile zur Standardausstattung. Sie korreliert Telemetrie, Identitäten und Netzwerkdaten, erkennt Anomalien in Echtzeit und priorisiert Alarme, womit sie Analysten entlastet und den Fachkräftemangel abfedert. Diese Anomalieerkennung verzahnt sich mit der Workload Protection aus den DevSecOps-Prozessen, da beide auf kontinuierlicher Beobachtung des Laufzeitverhaltens beruhen. Nach Angaben von IBM verkürzt KI-gestützte Sicherheit den Lebenszyklus eines Sicherheitsvorfalls um rund 80 Tage und senkt die durchschnittlichen Kosten je Vorfall um etwa bis zu 1,9 Millionen US-Dollar. Eine Zero-Trust-Architektur, die jeden Zugriff einzeln verifiziert, bildet das Fundament, auf dem KI-gestützte Erkennung wirkt. Basisschutz und KI-Abwehr ergänzen sich, denn eine moderne Erkennung ersetzt grundlegende Härtung nicht.

Fazit

Cloud Governance verbindet rechtliche, technische und organisatorische Steuerung zu einer dauerhaften Führungsaufgabe. Die Anbieterwahl folgt der Compliance, der Speicherort und die Schlüsselhoheit entscheiden über die Souveränität, Cloud-native Betriebsmodelle verlagern Kontrolle und Sicherheit in den Entwicklungsprozess, und der KI-Einsatz gehört über Datenklassen, klare Betreiberpflichten und kontrollierte Agentenrechte in dasselbe Regelwerk. Unternehmen, die Souveränität als Prüfkriterium verankern, Identitäten als Kontrollinstanz behandeln und die Durchsetzung automatisieren, sichern sich Handlungsfähigkeit auch bei veränderten Marktbedingungen und gestalten ihre Digitalisierung selbstbestimmt.