Cloud-Sicherheit in Europa: Warum Kontrolle, Compliance und digitale Souveränität entscheidend sind

In diesem Artikel lesen Sie,

• warum Cloud-Sicherheit in Europa nicht mehr nur eine Frage von Firewalls und Verschlüsselung ist, sondern von Kapazität, Resilienz und Kontrolle,
• welche rechtlichen, organisatorischen und technischen Kriterien eine sichere europäische Cloud erfüllen sollte,
• und woran Unternehmen eine sichere europäische Cloud-Lösung erkennen.

Misstrauen gegenüber der Cloud ist ein Klassiker – und überraschend hartnäckig. Im Fortinet Cloud Security Report 2025 nennen 61 Prozent der Unternehmen ungelöste Sicherheits- und Compliance-Fragen als wichtigsten Grund, der gegen eine breitere Cloud-Nutzung spricht: Wie lassen sich gesetzliche Anforderungen sicher erfüllen, und wie werden vertrauliche Daten zuverlässig geschützt? Bemerkenswerte 92 Prozent der Befragten äußern sich besorgt über die Sicherheit von Public Clouds. Das ist kein Randthema, sondern akuter Handlungsbedarf für IT- und Security-Verantwortliche.

Diese Zahlen zeigen: Die alte Frage „Cloud ja oder nein?“ ist längst entschieden. Unternehmen nutzen Cloud-Plattformen heute für geschäftskritische Anwendungen, sensible Daten und zunehmend für KI-Workloads. Entschieden wird stattdessen, unter welchen Bedingungen das geschieht – wo Daten liegen, wer auf sie zugreifen kann und welchem Rechtsraum die Infrastruktur unterliegt.

Bemerkenswert ist vor allem, wie sich der Sicherheitsbegriff selbst verschoben hat. Sicherheit bedeutete lange „technischer Schutz vor Angriffen“. Heute gehören Resilienz gegen Ausfälle und geopolitische Störungen, transparente Betriebsmodelle und die Kontrolle über Daten und Workloads ebenso dazu. Und mit der breiten Verfügbarkeit generativer KI verändert sich Sicherheit erneut: Daten fließen in Modelle, Rechenleistung wird zum knappen Gut, und neue Governance-Fragen entstehen. Sicherheit ist damit zur Voraussetzung digitaler Souveränität geworden – nicht umgekehrt.

Politische Initiativen unterstreichen diese Verschiebung. Mit dem geplanten Cloud and AI Development Act will die Europäische Union den Ausbau leistungsfähiger Rechenzentrums- und Compute-Kapazitäten in Europa beschleunigen und strategische Abhängigkeiten reduzieren. Dieser Beitrag zeigt, welche Kriterien eine sichere Cloud aus Europa erfüllen sollte, welche Nachweise belastbar sind und welche Rolle digitale Souveränität für eine tragfähige Cloud-Strategie spielt.

Cloud-Sicherheit ist von einer rein technischen Disziplin zu einer Vorstandsfrage geworden. Drei Entwicklungen treiben diese Neubewertung: Die Cloud ist zur unverzichtbaren Infrastruktur geworden, der regulatorische und geopolitische Druck steigt, und KI verschärft die Anforderungen an Kapazität und Kontrolle. Wer Cloud-Sicherheit heute bewertet, denkt deshalb nicht mehr nur an Schutzmaßnahmen, sondern an Versorgungssicherheit und Handlungsfähigkeit.

Cloud-Plattformen bilden das Fundament für digitale Geschäftsmodelle, datengetriebene Entscheidungen, moderne Softwareentwicklung und künstliche Intelligenz. Anders als vor zehn Jahren ist die Cloud damit kein optionaler Effizienzhebel mehr, sondern produktionskritische Infrastruktur: Fällt sie aus, steht der Betrieb. Mit dieser Abhängigkeit verschiebt sich der Maßstab. Verfügbarkeit, Wiederanlauffähigkeit und Kontrollierbarkeit der Plattform sind keine IT-Kennzahlen mehr, sondern Geschäftsrisiken. Genau deshalb rückt die Frage in den Vordergrund, wie eine sichere europäische Cloud betrieben wird – und nicht nur, welche Features sie bietet.

Mit dem Entwurf eines Cloud and AI Development Act diskutiert die EU den Ausbau digitaler Infrastruktur erstmals explizit als strategische und sicherheitspolitische Aufgabe. Das Vorhaben zielt darauf, die in Europa verfügbare Rechenzentrums- und Rechenkapazität deutlich zu erhöhen, Investitionen zu bündeln und kritische Abhängigkeiten von wenigen außereuropäischen Anbietern zu verringern. Für Unternehmen ist die Botschaft wichtiger als der Gesetzestext: Cloud-Kapazität „Made in Europe“ wird politisch gewollt und gefördert. Das verändert die Verfügbarkeit von Alternativen – und damit die Verhandlungsposition gegenüber globalen Anbietern.

Klassische Cybersecurity – Identitäten, Verschlüsselung, Angriffserkennung – bleibt notwendig, ist aber nicht mehr hinreichend. Hinzu kommen Fragen, die früher selten unter „Sicherheit“ liefen: Bekomme ich kurzfristig genügend GPU-Kapazität für KI-Workloads? Läuft die Plattform weiter, wenn ein Anbieter, ein Lieferant oder eine ganze Region ausfällt? Behalte ich die Kontrolle, wenn sich politische Rahmenbedingungen ändern? Kapazität, Resilienz und Souveränität sind damit selbst zu Sicherheitsfaktoren geworden. Eine sichere Cloud EU-weit zu betreiben, heißt heute, alle drei mitzudenken.

Was eine europäische Cloud sicher macht, ist selten ein einzelnes Merkmal, sondern das Zusammenspiel aus Rechtsraum, Betriebsmodell und nachvollziehbaren Kontrollrechten. Der Standort der Rechenzentren ist dabei der sichtbarste, aber bei Weitem nicht der wichtigste Baustein. Entscheidend ist, wer die Plattform tatsächlich kontrolliert – und wie viel davon der Cloud-Nutzer überprüfen kann.

Ein Rechenzentrum in Frankfurt oder Berlin ist ein gutes Argument – aber kein Sicherheitsversprechen. Entscheidend ist, welcher Rechtsordnung der Betreiber unterliegt und wer rechtlich Zugriff auf Daten verlangen kann. Ein europäischer Standort, der von einer Konzernmutter aus einem Drittstaat gesteuert wird, kann weiterhin extraterritorialen Zugriffsansprüchen ausgesetzt sein. Der physische Standort ist deshalb notwendige Bedingung, aber erst zusammen mit Betreiberstruktur und Kontrollrechten wird daraus eine sichere Cloud aus Europa.

Eine sichere europäische Cloud sollte garantieren, dass Datenverarbeitung, Speicherung und Verwaltung vollständig im europäischen Rechtsraum erfolgen – und zwar nicht nur die Produktivdaten, sondern auch Metadaten, Backups, Logs und administrative Prozesse. Werden diese sekundären Datenflüsse außerhalb Europas verarbeitet, entstehen genau dort Lücken, die in Audits regelmäßig übersehen werden. Eine durchgängig im EU-Rechtsraum verarbeitete und administrierte Plattform reduziert regulatorische Komplexität und das Risiko außereuropäischer Rechtsansprüche spürbar.

Sicherheit entsteht durch nachvollziehbare Verantwortlichkeiten. Unternehmen sollten prüfen können, wer die Plattform betreibt, wer administrativen Zugriff besitzt und wie privilegierte Zugriffe kontrolliert, eingeschränkt und lückenlos protokolliert werden. Ein in der Praxis oft unterschätzter Faktor sind dabei lokale Betriebsteams: Wenn Betrieb, Support und Administration durch Personal innerhalb der EU erfolgen – und kein administrativer Zugriff aus Drittstaaten möglich ist – sinkt das Risiko extraterritorialer Einflussnahme erheblich. Dieser Aspekt der operativen Souveränität wird zunehmend von Cloud-Anwendern gefordert.

Cloud-Anbieter stützen sich praktisch immer auf eine Lieferkette aus Hardware-Lieferanten, Konnektivität, Software-Komponenten und teils auf Subdienstleister für einzelne Plattformfunktionen. Transparente Lieferketten und nachvollziehbare Verantwortlichkeiten – inklusive einer Liste der eingesetzten Subunternehmer und ihrer Standorte – sind daher Grundvoraussetzung für Vertrauen, Compliance und Risikomanagement. In regulierten Branchen ist das längst Pflicht: Im Finanzsektor etwa müssen Unternehmen seit Geltung der DORA-Verordnung ein Informationsregister ihrer IKT-Drittparteien führen, das auch die Subdienstleister-Kette für kritische und wichtige Funktionen abdeckt – und dafür auf entsprechende Auskünfte ihrer Anbieter angewiesen sind. Spätestens hier wird Lieferkettentransparenz vom Vertrauensargument zur Nachweispflicht.

Digitale Souveränität wird oft mit „Daten in Europa“ gleichgesetzt – das greift zu kurz. Souveränität meint die dauerhafte Fähigkeit eines Unternehmens, selbst über Daten, Anwendungen und Betrieb zu bestimmen: heute, bei einem Anbieterwechsel und auch dann, wenn sich politische oder rechtliche Rahmenbedingungen ändern. Sicherheit und Souveränität greifen dabei ineinander – ohne belastbare Sicherheit gibt es keine Souveränität, und ohne Kontrollrechte bleibt Sicherheit ein Versprechen.

Hilfreich ist es, Souveränität in mehrere Dimensionen zu zerlegen: Datensouveränität, operative Souveränität (Betrieb und Personal) sowie technologische Souveränität (Portabilität und Unabhängigkeit von einzelnen Lieferketten). Im Zuge der laufenden Souveränitätsdiskussion werden sogar noch weitere Segmentierungen oder spezielle Aspekte von Souveränität beleuchtet: z.B. rechtliche Souveränität, Assurance Sovereignty, Supply Chain Sovereignty, Geopolitical Sovereignty oder Network Sovereignty.

Datenresidenz – die Festlegung, in welcher Region Daten gespeichert werden – ist die Einstiegsstufe. Datensouveränität geht weiter: Sie umfasst die Kontrolle darüber, wer unter welchen Bedingungen auf Daten zugreifen darf, wie Datenflüsse nachvollziehbar bleiben und wie sich Zugriffe technisch durchsetzen lassen. Praktisch bedeutet das: festgelegte Speicherorte, transparente und protokollierte Datenflüsse, kundenseitig kontrollierte Verschlüsselung sowie die Gewissheit, dass auch der Anbieter selbst nicht unbemerkt auf Klartextdaten zugreifen kann. Erst dieses Zusammenspiel macht aus einem Speicherort echte Datenhoheit.

Neben dem Standort der Daten entscheidet die Betreiberstruktur über Souveränität. Unternehmen sollten nachvollziehen können, welche juristische Person die Plattform betreibt, welcher Eigentümer- und Konzernstruktur sie unterliegt und ob diese extraterritorialen Gesetzen ausgesetzt ist. Eine in Europa ansässige, europäisch beherrschte Betreibergesellschaft mit klar definierten Kontroll- und Auditrechten bietet hier strukturelle Vorteile gegenüber einer europäischen Niederlassung eines außereuropäischen Konzerns. Genau an diesem Punkt unterscheiden sich Anbieter, die Souveränität als rechtlich-organisatorisches Modell verstehen, von solchen, die sie auf technische Sicherheitsfunktionen reduzieren.

Internationale Abhängigkeiten erzeugen rechtliche und operative Risiken – und sie betreffen nicht nur den Datenzugriff durch Behörden außerhalb Europas. Ebenso relevant ist die Lieferkette: Hardware, Firmware und kritische Software-Komponenten stammen häufig aus Drittstaaten. Exportkontrollen, Embargos oder kurzfristige Lieferbeschränkungen können dann unmittelbar die Verfügbarkeit von Kapazität – insbesondere von GPUs für KI – beeinträchtigen. Eine Bewertung von Drittstaatenabhängigkeiten muss daher beide Seiten umfassen: den möglichen Zugriff auf Daten und die Versorgungssicherheit bei Technologie und Lieferketten. Community-Ansätze wie beispielsweise für OpenStack reduzieren derartige Abhängigkeiten.

Exit-Fähigkeit ist keine Komfortfunktion, sondern eine Basisanforderung souveräner Cloud-Nutzung. Wer Daten und Workloads nicht zu vertretbaren Kosten und in vertretbarer Zeit zu einem anderen Anbieter migrieren kann, ist nicht souverän – egal, wie viele Sicherheitsfunktionen die Plattform bietet. Eine belastbare Exit-Strategie gehört deshalb von Beginn an in jede Cloud-Strategie: mit offenen Standards und APIs, dokumentierten Datenformaten, klar definierten Exit-Prozessen und regelmäßig erprobten Rückführungs- bzw. Migrationsszenarien. Auch hier setzt die Regulierung den Rahmen – die Bafin beispielsweise verlangt für kritische Auslagerungen ausdrücklich dokumentierte Ausstiegsstrategien.

Verantwortung lässt sich nicht in die Cloud auslagern. Auch wer Daten und Anwendungen einem Anbieter anvertraut, bleibt rechenschaftspflichtig – gegenüber Aufsichtsbehörden, Kunden und betroffenen Personen. Europäische Rechtsbindung ist deshalb mehr als ein Compliance-Detail: Sie bestimmt, wie einfach oder schwer ein Unternehmen seine eigenen Pflichten nachweisen kann.

Die DSGVO definiert europaweit verbindliche Anforderungen an die Verarbeitung personenbezogener Daten – von Rechtsgrundlage und Zweckbindung über Betroffenenrechte bis zu Meldepflichten bei Datenpannen. Für die Cloud heißt das konkret: Der Anbieter muss als Auftragsverarbeiter belastbar dokumentieren, wo und wie verarbeitet wird, und das Unternehmen aktiv dabei unterstützen, seine Nachweispflichten zu erfüllen. Eine Plattform, die DSGVO-Konformität nicht nur zusichert, sondern durch Verträge, technische Maßnahmen und prüffähige Nachweise belegt, senkt den eigenen Compliance-Aufwand erheblich.

Unternehmen bleiben auch in der Cloud Verantwortliche im Sinne der DSGVO. Ein sauberer Auftragsverarbeitungsvertrag (AVV) ist deshalb Pflicht – mit klaren Regelungen zu Weisungsrechten, technischen und organisatorischen Maßnahmen, eingesetzten Subunternehmern und Mitwirkung bei Betroffenenanfragen. Entscheidend ist die Belastbarkeit: AVV, Verzeichnis von Verarbeitungstätigkeiten, Zertifikate und Auditberichte müssen im Ernstfall einer Prüfung standhalten. Anbieter, die diese Unterlagen standardisiert und aktuell bereitstellen, ersparen ihren Kunden aufwändige Einzelnachweise.

Die rechtliche Bewertung internationaler Datenübermittlungen gehört zu den größten Herausforderungen moderner Cloud-Strategien. Unternehmen müssen wissen, welche Daten Europa verlassen, welche Zugriffsmöglichkeiten Behörden in Drittstaaten haben und auf welche Grundlage sich Übermittlungen stützen. Seit den Schrems-Urteilen und trotz des EU-US Data Privacy Framework bleibt diese Bewertung mit Unsicherheit behaftet. Eine sichere europäische Cloud-Lösung umgeht das Problem, indem Übermittlungen in Drittstaaten von vornherein vermieden werden – Daten, die Europa nicht verlassen, unterliegen keinem fremden Zugriffsrecht.

Datenschutz, Cybersecurity und digitale Souveränität werden organisatorisch oft getrennt behandelt – von Datenschutzbeauftragten, CISO und IT-Strategie. In der Praxis hängen sie unmittelbar zusammen: Ein Datenschutzverstoß ist häufig die Folge eines Sicherheitsvorfalls; fehlende Kontrolle über den Betrieb untergräbt beides. Wirksam wird der Schutz erst, wenn die drei Perspektiven gemeinsam gedacht werden – etwa wenn Verschlüsselung (Sicherheit), kundenseitige Schlüsselkontrolle (Souveränität) und dokumentierte Verarbeitung (Datenschutz) ineinandergreifen. Eine sichere Cloud aus Europa zeichnet sich gerade dadurch aus, dass sie diese drei Ebenen integriert adressiert statt isoliert.

Vertrauen ist gut, Nachweis ist besser. Da Kunden die internen Prozesse eines Anbieters selten direkt einsehen können, treten unabhängige Audits, Zertifizierungen und eigene Tests an deren Stelle. Wichtig ist dabei, die unterschiedlichen Nachweisarten korrekt einzuordnen – denn nicht jedes „Siegel“ bedeutet dasselbe. Unabhängige Drittparteien wie die ESAs (European Supervisory Authorities), die Clouds überwachen, können zusätzlich Vertrauen schaffen.

Objektive Audits und Zertifizierungen erlauben es, das Sicherheitsniveau eines Anbieters nachvollziehbar zu bewerten – ohne sich allein auf Marketingaussagen verlassen zu müssen. Entscheidend ist der Geltungsbereich (Scope): Welche Services, Regionen und Zeiträume deckt ein Nachweis ab? Ein Zertifikat, das nur einen Teil der genutzten Dienste umfasst, hat begrenzte Aussagekraft. Ergänzend können Unternehmen eigene Sicherheitstests durchführen oder beauftragen. Seriöse Anbieter unterziehen ihre Plattform zudem regelmäßigen, unabhängigen Penetrationstests und stellen die Ergebnisse bzw. zusammenfassende Berichte auf Anfrage bereit.

Der Kriterienkatalog C5 (Cloud Computing Compliance Criteria Catalogue) des Bundesamts für Sicherheit in der Informationstechnik hat sich im deutschsprachigen Raum als maßgeblicher Referenzrahmen etabliert. C5 ist kein Zertifikat im engeren Sinn, sondern Grundlage einer Wirtschaftsprüfer-Testierung nach internationalem Prüfstandard. Besonders aussagekräftig ist ein Typ-2-Bericht: Er bescheinigt nicht nur, dass Kontrollen definiert sind, sondern dass sie über einen Zeitraum hinweg auch wirksam funktioniert haben. Ein aktuelles C5-Testat über den vollen Service-Scope ist eines der stärksten Argumente für eine sichere Cloud-Plattform Europa-weit.

Mit dem European Cybersecurity Certification Scheme for Cloud Services (EUCS) entsteht unter dem EU Cybersecurity Act ein einheitlicher europäischer Rahmen zur Bewertung von Cloud-Sicherheits- und Souveränitätsniveaus. Wichtig zur korrekten Einordnung: EUCS ist – anders als ISO 27001 oder ein C5-Testat – kein Nachweis, den ein Anbieter heute bereits „besitzt“, sondern das zugrunde liegende Zertifizierungsschema selbst. Es befindet sich weiterhin in der finalen Abstimmung, insbesondere die ursprünglich diskutierten strengen Souveränitätskriterien waren umstritten. EUCS ist daher als künftiger europäischer Referenzstandard relevant – aktuelle Sicherheitsaussagen sollten sich jedoch auf bereits verfügbare Nachweise wie C5 oder ISO 27001 stützen.

International etablierte Standards ergänzen das Bild. ISO/IEC 27001 zertifiziert ein funktionierendes Informationssicherheits-Managementsystem (ISMS) und ist global anerkannt. SOC-2-Berichte (Typ I und II) dokumentieren die Wirksamkeit von Kontrollen entlang definierter Trust-Service-Kriterien und sind vor allem im angloamerikanischen Raum verbreitet. Hinzu kommen branchenspezifische Nachweise – etwa für Gesundheitswesen, Finanzsektor oder öffentliche Auftraggeber. Für eine fundierte Bewertung zählt nicht die Menge der Logos, sondern die Kombination aus Aktualität, Geltungsbereich und Prüftiefe der vorgelegten Nachweise.

Recht und Organisation geben den Rahmen vor – durchsetzen muss ihn die Technik. Die folgenden Bausteine sind weniger „Architektur“ im Sinne eines Bauplans als vielmehr die Sicherheits- und Kontrollschichten, die eine Plattform bereitstellen muss, damit die zuvor beschriebenen Anforderungen praktisch wirksam werden. Entscheidend ist, dass diese Funktionen nicht aufwändig selbst gebaut, sondern als gemanagte Dienste der Plattform genutzt werden können. Gerade die Management- und Security-Services sind dabei ein echter Differentiator: Plattformen wie die T Cloud Public bieten zentrale Bausteine wie Identity and Access Management (IAM), den Log Tank Service oder den Host Security Service als integrierte Onboard-Dienste an, erlauben aber auch die Nutzung von Drittparteien-Services, die Cloud-Nutzer im Einzelfall favorisieren.

Identitäten sind die neue Perimeter-Grenze – die meisten Angriffe beginnen heute mit kompromittierten Zugangsdaten, nicht mit durchbrochenen Firewalls. Ein modernes Identity and Access Management (IAM) stellt sicher, dass nur autorisierte Personen und Dienste auf Systeme und Daten zugreifen, und setzt dabei zentrale Prinzipien durch: Multi-Faktor-Authentifizierung, rollenbasierte Rechtevergabe nach dem Least-Privilege-Prinzip, klare Trennung von Zuständigkeiten sowie eine gesonderte Kontrolle und Protokollierung privilegierter Konten (Privileged Access Management). Als gemanagter IAM-Dienst der Plattform lassen sich diese Kontrollen zentral und konsistent über alle Workloads hinweg durchsetzen.

Verschlüsselung ist kein Allheilmittel, sondern ein Hygienefaktor: unverzichtbar, aber für sich allein kein Sicherheitskonzept. Daten sollten konsequent während der Übertragung (in transit) und im Ruhezustand (at rest) verschlüsselt werden. Den eigentlichen Souveränitätsgewinn bringt jedoch die Schlüsselhoheit: Über einen Key-Management-Service mit Bring Your Own Key (BYOK) oder Hold Your Own Key (HYOK) behält der Kunde die Kontrolle über die kryptografischen Schlüssel – im Idealfall so, dass der Anbieter selbst keinen Zugriff auf Klartextdaten nehmen kann. Den nächsten Schritt adressiert Confidential Computing: Mithilfe Hardware-basierter Trusted Execution Environments werden Daten auch während der Verarbeitung (in use) im Arbeitsspeicher geschützt – und damit eine der letzten klassischen Lücken geschlossen.

In Public-Cloud-Umgebungen teilen sich viele Kunden dieselbe physische Infrastruktur. Eine zuverlässige Mandantentrennung muss daher technisch sicherstellen, dass kein Mandant auf die Daten oder Ressourcen eines anderen zugreifen kann – auf Ebene von Compute, Netzwerk und Storage gleichermaßen. Bewährte Mechanismen sind strikt getrennte virtuelle Netzwerke (VPCs), Mikrosegmentierung, isolierte Schlüssel pro Mandant und – für besonders sensible Workloads – dedizierte Ressourcen bis hin zu dedizierter Hardware. Für Unternehmen mit hohen Compliance-Anforderungen ist die nachweisbare Qualität der Isolation oft das ausschlaggebende Kriterium bei der Wahl der Plattform.

Man kann nur abwehren, was man sieht. Lückenloses Monitoring und manipulationssichere Logs sind deshalb die Grundlage jeder wirksamen Angriffserkennung und ein Standardbestandteil regulatorischer Anforderungen. Statt diese Funktionen selbst aufzubauen, können Unternehmen auf die Management- und Security-Services der Plattform zurückgreifen – ein wesentlicher Differentiator: Die T Cloud Public stellt etwa mit dem Log Tank Service eine zentrale Sammlung, Speicherung und Analyse von Logdaten bereit, mit dem Host Security Service den Schutz und die Überwachung einzelner Workloads sowie mit Diensten zur Nachverfolgung von Aktivitäten (z.B. Cloud Eye, Cloud Trace) die Grundlage für revisionssichere Nachvollziehbarkeit. So entsteht aus verteilten Einzeldaten ein konsistentes Lagebild – die Voraussetzung für schnelle, strukturierte Incident Response.

Sicherheit endet nicht bei der Abwehr von Angriffen – sie umfasst auch die Fähigkeit, nach einem Ausfall oder einem Ransomware-Vorfall wieder handlungsfähig zu werden. Belastbare Konzepte definieren dafür klare Zielwerte: Wie viel Datenverlust ist maximal tolerierbar (RPO) und wie schnell muss der Betrieb wiederhergestellt sein (RTO)? Wirksame Resilienz setzt auf regelmäßige, getestete Backups, idealerweise mit unveränderbaren (immutable) und logisch getrennten Kopien als Schutz vor Verschlüsselungsangriffen, sowie auf eine Verteilung über mehrere Verfügbarkeitszonen oder Regionen. Entscheidend ist, dass Wiederherstellung nicht nur dokumentiert, sondern regelmäßig erprobt wird – ein nie getestetes Disaster-Recovery-Konzept ist im Ernstfall wenig wert.

Moderne Anwendungen bestehen zu großen Teilen aus Fremdkomponenten – Open-Source-Bibliotheken, Container-Images, Pipelines. Angriffe verlagern sich entsprechend in die Lieferkette, wie prominente Vorfälle der vergangenen Jahre gezeigt haben. Eine wirksame Software Supply Chain Security umfasst eine vollständige Bestandsaufnahme der Komponenten (Software Bill of Materials), kontinuierliches Schwachstellen-Scanning, signierte und verifizierte Artefakte sowie abgesicherte Build-Pipelines. Für eine sichere europaweite Cloud-Infrastruktur gehört dazu auch die Transparenz über die Herkunft der eingesetzten Komponenten – damit Abhängigkeiten und mögliche Embargorisiken frühzeitig sichtbar werden.

KI verändert die Sicherheitsanforderungen nicht grundsätzlich neu – aber sie verschärft sie an konkreten Stellen. Drei Dinge sind tatsächlich anders als bei klassischen Workloads: Es fließen sehr viele, oft sensible Daten in Trainings-, Fine-Tuning- und Inferenzprozesse; es braucht knappe, teure GPU-Kapazität; und es entstehen neue Governance-Fragen rund um Modelle und deren Nutzung. Genau diese drei Punkte bestimmen, welche zusätzlichen Anforderungen eine sichere Cloud aus Europa für KI erfüllen muss.

Pauschale Aussagen helfen hier wenig – entscheidend ist, wo genau bei KI-Anwendungen sensible Daten ins Spiel kommen. Drei typische Stellen lassen sich klar benennen: erstens Trainings- und Fine-Tuning-Daten, die proprietäres Wissen, Geschäftsgeheimnisse oder personenbezogene Daten enthalten können; zweitens die Prompts und Kontextdaten im laufenden Betrieb, etwa wenn Mitarbeitende interne Dokumente in ein Modell eingeben; und drittens die Wissensbasen von Retrieval-Augmented-Generation-Anwendungen, die oft Zugriff auf das gesamte Dokumentenarchiv eines Unternehmens haben. An jeder dieser Stellen gelten dieselben Schutzanforderungen wie für andere sensible Daten – nur dass die Datenmengen größer und die Zugriffswege neu sind. Wo dieses Wissen verarbeitet wird und wer darauf zugreifen kann, ist deshalb eine berechtigte und keineswegs nur rhetorische Sicherheitsfrage.

Sicherheits- und Compliance-Anforderungen an Rechen-Infrastruktur sind nicht neu – sie galten immer. Was sich mit generativer KI ändert, ist die schiere Nachfrage nach GPU-Kapazität und damit die strategische Bedeutung ihrer Verfügbarkeit. GPUs sind knapp, teuer und unterliegen Lieferketten- und Exportkontrollrisiken; wer hier von wenigen außereuropäischen Quellen abhängt, hat ein Versorgungs- und Souveränitätsproblem. Hinzu kommt, dass GPU-Workloads dieselben Kontrollmechanismen benötigen wie andere sensible Verarbeitungen – Zugriffskontrolle, Mandantentrennung, Protokollierung. Der eigentliche Unterschied liegt also nicht darin, dass Compliance „plötzlich“ wichtig würde, sondern in der Kombination aus hoher Nachfrage, knapper Kapazität und neuen Datenflüssen.

KI-Governance wird oft mit dem schwer fassbaren Anspruch „Nachvollziehbarkeit von Entscheidungen“ überfrachtet. Konkret und überprüfbar wird sie erst, wenn man sie auf operative Kontrollen herunterbricht: Wer darf welches Modell und welche Trainingsdaten nutzen (Zugriffskontrolle)? Welche Daten sind in welches Modell eingeflossen und woher stammen sie (Daten- und Modell-Lineage)? Welche Anfragen wurden wann von wem gestellt (Audit-Logging der Modellzugriffe)? Und welche Modellversion war zu einem bestimmten Zeitpunkt im Einsatz (Versionierung)? Diese Fragen lassen sich technisch beantworten und protokollieren – im Gegensatz zur vagen Forderung nach „Erklärbarkeit“ jeder einzelnen Modellausgabe. Eine sichere europäische Cloud sollte diese Governance-Funktionen als Teil der Plattform bereitstellen.

Souveräne KI – „Sovereign AI“ – bezeichnet KI-Umgebungen, in denen Datenhoheit, Compliance und Kontrolle durchgängig in der Hand der nutzenden Organisation bleiben. Das setzt eine Infrastruktur voraus, die alle bisher genannten Eigenschaften vereint: europäischer Rechtsraum, kontrollierte GPU-Kapazität, kundenseitige Schlüsselhoheit und belastbare Governance. Für viele Organisationen – besonders in regulierten Branchen und im öffentlichen Sektor – ist eine sichere Cloud aus Europa damit die Voraussetzung dafür, KI überhaupt mit sensiblen Daten produktiv einsetzen zu dürfen. Souveräne KI ist weniger ein Produkt als das Ergebnis einer konsequent souverän aufgebauten Plattform.

Grundsätzlich profitieren alle Organisationen von Kontrolle und Nachweisbarkeit. Für einige Branchen ist eine sichere europäische Cloud jedoch nicht nur sinnvoll, sondern faktisch Voraussetzung – getrieben durch regulatorische Pflichten, die Sensibilität der Daten oder den Schutz geistigen Eigentums.

Behörden und öffentliche Einrichtungen unterliegen besonders hohen Anforderungen an Datenschutz, Nachvollziehbarkeit und digitale Souveränität – und einer wachsenden politischen Erwartung, Bürgerdaten unter europäischer Kontrolle zu verarbeiten. Initiativen wie die Verwaltungscloud-Strategie und das Ziel souveräner Verwaltungsplattformen machen die Wahl der Cloud zur strategischen Frage. Hier zählt nicht nur Compliance auf dem Papier, sondern die nachweisbare Unabhängigkeit von außereuropäischen Zugriffsrechten.

Patientendaten gehören zu den sensibelsten Informationen überhaupt und unterliegen strengen Vorgaben – von der DSGVO über die ärztliche Schweigepflicht bis zu spezifischen Anforderungen an Krankenhäuser und Forschungseinrichtungen. Gleichzeitig entsteht durch elektronische Patientenakte, Telemedizin und KI-gestützte Diagnostik enormer Innovationsdruck. Eine sichere Cloud EU-weit bietet hier die Grundlage, beides zu verbinden: hohen Schutz sensibler Gesundheitsdaten und moderne, datengetriebene Versorgung.

Banken, Versicherungen und andere regulierte Organisationen müssen umfassende Nachweise zu Sicherheit, Compliance und Risikomanagement erbringen. Mit der DORA-Verordnung sind die Anforderungen an digitale operationale Resilienz seit Anfang 2025 verbindlich: IKT-Risikomanagement, ein Register aller IKT-Drittparteien, dokumentierte Ausstiegsstrategien und bedrohungsgeleitete Penetrationstests. Eine sichere europäische Cloud-Lösung mit transparenter Lieferkette, belastbaren Nachweisen und erprobter Exit-Fähigkeit erleichtert die Erfüllung dieser Pflichten erheblich.

Betreiber kritischer Infrastrukturen sehen sich stetig steigenden regulatorischen Anforderungen an Cybersecurity und Resilienz gegenüber. Die NIS2-Richtlinie weitet den Kreis der betroffenen Einrichtungen deutlich aus und verschärft Pflichten zu Risikomanagement, Meldewesen und Lieferkettensicherheit; die nationale Umsetzung konkretisiert diese Vorgaben weiter. Für die betroffenen Organisationen wird die Wahl einer nachweislich sicheren, resilienten und EU-rechtlich gebundenen Plattform damit zu einem zentralen Baustein der Compliance.

Auch außerhalb stark regulierter Branchen wächst die Bedeutung des Schutzes von geistigem Eigentum, Konstruktions- und Forschungsdaten sowie trainierten KI-Modellen. Für forschungsintensive Industrieunternehmen sind Konstruktionspläne, Versuchsdaten oder Modellgewichte oft das eigentliche Kapital – ihr Abfluss kann existenzbedrohend sein. Eine sichere europaweite Cloud-Infrastruktur, die Datenhoheit und kontrollierte KI-Nutzung verbindet, wird damit auch hier zum Wettbewerbsfaktor.

Die Diskussion wird zu oft als „entweder/oder“ geführt – das verfehlt die Realität der meisten Unternehmen. Es geht nicht darum, Hyperscaler gegen europäische Anbieter auszuspielen, sondern darum, Workloads bewusst dem jeweils passenden Modell zuzuordnen. Souveränitätsanforderungen verschieben dabei die Gewichte – sie machen die Standortfrage zur Architekturentscheidung.

Globale Cloud-Anbieter verfügen über beträchtliche Innovationskraft, weltweite Präsenz, enorme Skalierbarkeit und ein sehr breites Serviceportfolio. Für viele Anwendungsfälle – etwa global verteilte, weniger regulierte Workloads oder die schnelle Erprobung neuer Dienste – sind das überzeugende Argumente. Diese Stärken stehen außer Frage und sind Teil einer realistischen Bewertung.

Für besonders sensible Daten und Workloads treten zusätzliche Kriterien in den Vordergrund: Welcher Rechtsordnung unterliegt der Betreiber? Wer kann administrativen Zugriff verlangen? Bleibt die Plattform auch bei geopolitischen Spannungen verfügbar? An diesem Punkt reicht die technische Sicherheit globaler Anbieter allein nicht aus – gefragt ist strukturelle Kontrolle. Genau hier zeigt sich der Unterschied zwischen Anbietern, die Souveränität als rechtlich-organisatorisches Modell verstehen, und solchen, die sie auf technische Sicherheitsfunktionen verengen.

Europäische Anbieter setzen ihren Schwerpunkt häufig genau dort, wo Souveränitätsanforderungen am höchsten sind: Datenschutz, Compliance, Datenresidenz, europäische Betreiberstruktur und lokale Betriebsteams. Sie können verbindlich zusichern, dass Betrieb und Administration vollständig innerhalb der EU erfolgen, und ihre Lieferketten transparent machen. Was eine europäische Cloud sicher und souverän macht, ist damit weniger die einzelne Funktion als die Kombination aus Rechtsbindung, Betriebsmodell und überprüfbarer Kontrolle. Eine sichere Cloud-Plattform Europa positioniert sich genau über dieses Zusammenspiel – nicht über einzelne Sicherheits-Features.

In der Praxis kombinieren die meisten Unternehmen mehrere Plattformen, um Innovationsfähigkeit, Flexibilität und regulatorische Anforderungen gleichermaßen zu erfüllen. Ein bewährtes Muster ist die bewusste Zuordnung nach Schutzbedarf: hochsensible und regulierte Workloads in einer souveränen europäischen Cloud, breit skalierende oder weniger kritische Anwendungen bei globalen Anbietern. Voraussetzung für dieses Modell ist Portabilität – offene Standards und klare Schnittstellen verhindern, dass aus Multi-Cloud ein neues Lock-in wird.

Rund um „souveräne“ und „sichere“ Cloud-Angebote kursieren einige Vereinfachungen, die in der Praxis zu falscher Sicherheit führen. Die vier häufigsten Fehlannahmen lohnt es sich auszuräumen.

Der häufigste Trugschluss: „Server in Deutschland, also sicher“. Tatsächlich sagt der Standort nichts über Betreiberstruktur, Zugriffsrechte, Verschlüsselung oder Betriebsprozesse aus. Ein europäisches Rechenzentrum, das von einer außereuropäischen Konzernmutter gesteuert wird, kann weiterhin fremden Rechtsansprüchen unterliegen. Der Standort ist eine notwendige, aber keine hinreichende Bedingung.

DSGVO-Konformität betrifft den Schutz personenbezogener Daten – ein wichtiger, aber begrenzter Ausschnitt. Sie sagt wenig über Resilienz gegen Ausfälle, Schutz vor Ransomware, Lieferkettensicherheit oder operative Souveränität aus. Ein DSGVO-konformer Dienst kann gleichzeitig schlecht abgesichert oder von einzelnen Drittstaaten-Lieferketten abhängig sein. Datenschutz und Cloud-Sicherheit überschneiden sich – deckungsgleich sind sie nicht.

Auch eigene oder regionale Rechenzentren erzeugen nicht automatisch Souveränität. Entscheidend sind Kontrollrechte, Betriebsmodell und die tatsächlichen Zugriffsmöglichkeiten – etwa, wer die Schlüssel verwaltet, wer administrativen Zugang hat und ob der Betrieb durch Personal innerhalb der EU erfolgt. Souveränität entsteht aus rechtlicher und organisatorischer Kontrolle, nicht aus Beton und Hardware.

Die Annahme „privat = sicherer“ hält der Praxis selten stand. Eine schlecht gepflegte Private Cloud mit veralteten Systemen und dünn besetztem Sicherheitsteam kann deutlich angreifbarer sein als eine professionell betriebene Public Cloud mit zertifizierten Prozessen und automatisiertem Patch-Management. Das Sicherheitsniveau hängt von Architektur, Prozessen, Governance und investierten Ressourcen ab – nicht vom Bereitstellungsmodell.