Allgemein

Die Cloud klaut. Der Running Gag der 2010er Jahre wird gerade zur Begriffsklärung.

Franz-Martin 01. Mai. 2026 · 9 Min. Lesezeit

Wer sich an die deutsche IT-Szene der 2010er Jahre erinnert, kennt den Spruch. „Die Cloud klaut.“ Er stand auf Konferenzfolien, in Kabarettprogrammen, in den Kommentarspalten von Heise. Mal als Warnung, mal als Witz, oft als beides. Nach den Snowden-Enthüllungen 2013 und dem iCloud-Promi-Leak 2014 hatte er seinen festen Platz im Repertoire.

Damals war er Pointe. Heute ist er eine technische Beobachtung.

Ich möchte das in diesem Artikel auseinandernehmen. Nicht als Cloud-Kritik in der üblichen Lautstärke. Sondern als ruhige Begriffsklärung. Was war Cloud ursprünglich gemeint? Was leisten die großen Anbieter wirklich? Und an welcher Stelle bricht das Modell, wenn wir personalisierte KI ins Spiel bringen?

Inhalt

  1. Was Cloud ursprünglich bedeutet hat
  2. Die Anbieter haben echte Engineering-Leistung erbracht
  3. Der Bruch geschieht, wenn der Kontext persönlich wird
  4. Was die Anbieter sehen, ohne dass sie hinschauen müssen
  5. Es gibt Gegenarchitekturen, sie sind aber nicht der Standardpfad
  6. Die richtige Frage ist nicht Cloud oder nicht Cloud
  7. Was der alte Witz heute bedeutet

Was Cloud ursprünglich bedeutet hat

Der Cloud-Begriff stammt aus der Idee des Utility Computing. Rechenleistung, Speicher, Software werden zur allgemeinen Versorgungsleistung. So wie Strom aus der Steckdose kommt, kommt Compute aus dem Rechenzentrum. Du zahlst nach Verbrauch, du kümmerst dich nicht um die Erzeugung.

Das Geschäftsmodell hat eine klare ökonomische Logik. Tausende Kunden teilen sich dieselbe Infrastruktur. Spitzenlasten gleichen sich aus. Die Hardware-Auslastung steigt von typischen zwanzig Prozent im eigenen Serverraum auf siebzig oder mehr. Wartung, Sicherheit, Erneuerung werden professionalisiert und auf viele Schultern verteilt.

Das funktioniert, solange die Workloads austauschbar oder unkritisch sind. Eine Webseite ist eine Webseite. Ein Backup ist ein Backup. Ein Build-Server ist ein Build-Server. Ob er bei dir im Keller läuft oder bei Amazon, ist technisch egal. Ökonomisch ist Amazon meistens überlegen.

Das ist der ursprüngliche Cloud-Begriff. Geteilte Infrastruktur für generische Workloads.

Die Anbieter haben echte Engineering-Leistung erbracht

Bevor ich zur Pointe komme, möchte ich einen Moment bei den Anbietern bleiben. AWS, Azure, Google Cloud, dazu kleinere wie Hetzner oder OVH. Was diese Häuser in zwanzig Jahren aufgebaut haben, ist beeindruckend.

Verfügbarkeit über Regionen hinweg, automatisches Failover, transparente Skalierung von einer Anfrage pro Stunde auf zehntausend pro Sekunde. Datenbanken, die sich selbst replizieren. Object Storage, der praktisch nicht voll wird. Identitäts- und Rechtemanagement auf einem Niveau, das im eigenen Rechenzentrum kaum erreichbar ist. Dazu eine Preisstaffel, die für viele Anwendungsfälle billiger ist als die eigene Infrastruktur, sobald man Personalkosten ehrlich einrechnet.

Wer eine Website baut, einen SaaS-Dienst entwickelt, eine API-Plattform betreibt oder Machine-Learning-Modelle trainiert, der findet in den Cloud-Angeboten einen ausgereiften Werkzeugkasten. Das ist keine Marketing-Erzählung, das ist gemessene Realität.

Mehr noch. Die Verschlüsselungs-, Monitoring- und Compliance-Werkzeuge der großen Anbieter sind oft besser als das, was ein durchschnittlicher Mittelständler im eigenen Haus hinbekommt. Wenn jemand argumentiert, „in der Cloud sind meine Daten sicherer als bei mir“, dann hat er für viele Bedrohungsmodelle nicht unrecht.

Soweit die faire Würdigung. Sie ist mir wichtig, weil das, was jetzt kommt, sonst falsch klingen würde.

Der Bruch geschieht, wenn der Kontext persönlich wird

In den letzten beiden Jahren ist eine neue Klasse von Cloud-Diensten in den Mittelpunkt gerückt. KI-Assistenten, die deinen Kontext kennen sollen. Sie heißen Copilot, Gemini, Claude, ChatGPT mit Custom GPTs, und alle bauen auf demselben technischen Muster auf. Du lädst deine Dokumente hoch. Der Anbieter zerteilt sie in Chunks, vektorisiert sie und legt sie in einer Vektordatenbank ab. Wenn du fragst, sucht das System nach passenden Stellen und reicht sie zusammen mit deiner Frage an das Sprachmodell. Das Verfahren heißt Retrieval Augmented Generation, kurz RAG.

Funktioniert technisch hervorragend. Die Antworten werden präziser, weil das Modell deinen Kontext sieht.

Und genau hier kippt der Cloud-Begriff. Du konsumierst keine geteilte Infrastruktur mehr. Du verlagerst deinen privaten Kontext in jemandes Rechenzentrum.

Damit RAG funktionieren kann, muss der Anbieter zwingend mehrere Dinge tun. Er muss deine Dokumente entgegennehmen und parsen. Er muss sie vektorisieren, was bedeutet, dass irgendein Modell auf seiner Seite den Klartext gelesen hat. Er muss die Vektoren so vorhalten, dass eine Ähnlichkeitssuche möglich ist. Und im entscheidenden Moment, wenn du eine Frage stellst, muss der relevante Originaltext aus deinen Dokumenten als Klartext im Kontextfenster des Sprachmodells landen, denn das Modell rechnet auf Klartext, nicht auf Hashes.

Dazu kommen die üblichen Begleiterscheinungen einer SaaS-Architektur. Logs, in denen Prompts und Antworten zur Fehleranalyse gespeichert werden. Prompt-Caches, die zur Performance-Optimierung Inhalte zwischenlagern. Monitoring, das Inferenz-Pipelines überwacht. Telemetrie für Produktverbesserung. Jedes dieser Subsysteme hat in der Standardkonfiguration Zugriff auf das, was in den Pipelines fließt.

Das ist keine Bösartigkeit der Anbieter. Das ist die Architektur, die das Produkt überhaupt erst ermöglicht. Wenn ein Anbieter dir verspricht, deine Daten würden niemals gelesen, dann meint er meistens „von Menschen nicht gelesen“. Maschinell gelesen werden sie zwingend, sonst gäbe es keine Antwort.

Was die Anbieter sehen, ohne dass sie hinschauen müssen

Die Frage ist nicht, ob ein Mitarbeiter morgens deine Akten durchblättert. Tut er nicht. Die Frage ist, was technisch möglich ist, ohne dass jemand hinschaut.

Ein modernes Cloud-RAG-System hält in jedem Verarbeitungsschritt Daten vor, die ein Insider, ein kompromittiertes Servicekonto oder ein behördlicher Zugriff auswerten könnte. In den USA ansässige Anbieter unterliegen dem CLOUD Act, der Strafverfolgungsbehörden den Zugriff auf Daten ermöglicht, unabhängig davon, in welchem Rechenzentrum die Daten physisch liegen. Auch europäische Tochtergesellschaften amerikanischer Konzerne sind davon betroffen, das hat Schrems II nochmal sehr klar gemacht.

Für eine Website mit Marketingbildern ist das ein theoretisches Problem. Für eine Mandantenakte, eine Patientenakte, eine ungeprüfte Steuererklärung oder die Verhandlungsstrategie für eine Übernahme ist es ein operatives Problem.

Und hier kommt der Running Gag der 2010er Jahre wieder ins Spiel. „Die Cloud klaut“ war damals eine Übertreibung, weil Cloud meistens hieß, dass dein Backup verschlüsselt im S3-Bucket liegt und niemand den Schlüssel hat außer dir. Heute heißt Cloud-RAG, dass deine Mandantenkorrespondenz im Klartext durch ein Inferenzsystem fließt, dessen Architektur auf Klartextverarbeitung angewiesen ist.

Die Pointe ist nicht, dass die Anbieter klauen. Die Pointe ist, dass der Begriff sich geändert hat, ohne dass das Wort sich geändert hat.

Es gibt Gegenarchitekturen, sie sind aber nicht der Standardpfad

Damit das Bild fair bleibt. Die technische Forschung kennt mehrere Ansätze, mit denen sich personalisierte KI in der Cloud betreiben ließe, ohne dass der Anbieter den Klartext sieht.

Confidential Computing nutzt Trusted Execution Environments wie Intel SGX, AMD SEV oder AWS Nitro Enclaves. Daten werden in einem hardwaregeschützten Speicherbereich verarbeitet, in den nicht einmal der Hypervisor hineinsehen kann. Client-Side Encryption verschlüsselt die Daten auf dem Gerät des Nutzers, der Schlüssel verlässt das Gerät nie. Homomorphe Verschlüsselung erlaubt theoretisch Berechnungen auf verschlüsselten Daten, ist für vollwertige Sprachmodell-Inferenz aktuell aber nicht praktikabel, sie ist um Größenordnungen zu langsam.

Diese Verfahren existieren, sie funktionieren in Teilbereichen, und einige Anbieter setzen sie für spezielle Premiumprodukte ein. Im Standardpfad der konsumierten KI-Assistenzdienste, also dem, was die meisten Nutzer und Unternehmen tatsächlich verwenden, kommt davon wenig an. Der Grund liegt in Komplexität und Kosten. TEEs reduzieren die GPU-Auslastung, bringen Performance-Einbußen und sind in der Toolchain anspruchsvoll.

Wer also mit einem Cloud-Anbieter über Datenschutz spricht, sollte präzise fragen. „Ist das DSGVO-konform“ beantwortet jeder Vertrieb mit Ja. Die bessere Frage lautet: „Kann der Klartext meiner Dokumente in der Inferenz-Pipeline von einem privilegierten Prozess ausgelesen werden, und welche kryptografische Eigenschaft verhindert das technisch?“ Bei dieser Frage wird das Gespräch interessant.

Die richtige Frage ist nicht Cloud oder nicht Cloud

Aus all dem folgt nicht, dass Cloud schlecht ist. Es folgt, dass der Cloud-Begriff in den letzten Jahren zwei Bedeutungen erhalten hat, die nicht dieselben sind.

Cloud im ursprünglichen Sinne bedeutet, dass du Infrastruktur teilst. Webserver, Datenbanken, Speicherplatz, Rechenkapazität für generische oder unkritische Workloads. Hier ist Cloud weiterhin die ökonomisch und technisch überlegene Wahl für die meisten Anwendungsfälle. Wer das anders sieht, hat selten die Mathematik gemacht.

Cloud im neueren Sinne bedeutet, dass du deinen privaten Kontext in eine fremde Inferenz-Pipeline einspeist, damit ein dort betriebenes Modell ihn lesen kann. Hier ist nicht mehr von geteilter Infrastruktur die Rede, sondern von ausgelagertem Privatraum. Das ist ein anderes Geschäft, das nur zufällig denselben Namen trägt.

Die saubere Antwort ist also eine Architekturentscheidung. Weder pauschal in die Cloud noch pauschal selbst betreiben. Stattdessen die Frage: Welche Daten gehören zu welcher Klasse, und welche Infrastruktur passt zu welcher Klasse.

Generische Workloads, anonymisierte Telemetrie, Marketinginhalte, Open-Data-Verarbeitung. Cloud, ohne Bauchschmerzen.

Mandantenakten, Patientendaten, ungeprüfte Steuerunterlagen, Verhandlungsstrategien, Quellcode mit Geschäftsgeheimnis-Charakter, Korrespondenz unter Berufsgeheimnis. Lokale Verarbeitung, weil die Architektur das verlangt, nicht weil die AGB es verbieten.

Die Trennlinie liegt nicht zwischen guten und bösen Anbietern. Sie liegt zwischen der Klasse von Daten, für die das ursprüngliche Cloud-Versprechen gilt, und der Klasse von Daten, für die es nie gegolten hat.

Was der alte Witz heute bedeutet

„Die Cloud klaut“ war 2014 eine Übertreibung mit wahrem Kern. Die meisten Datenverluste damals waren Konfigurationsfehler, schwache Passwörter und der Phishing-Angriff auf Promi-Accounts. Echte technische Notwendigkeit, sensible Daten in fremde Klartext-Pipelines zu schicken, gab es selten.

Heute ist sie zur Standardarchitektur geworden. Und der Running Gag wird zur ruhigen Begriffsklärung. Wer seine sensiblen Daten in einen Cloud-RAG-Dienst hochlädt, der klaut nicht, der lagert aus. Aber er lagert etwas aus, das im ursprünglichen Cloud-Modell nicht vorgesehen war.

Die Anbieter haben das Recht, ihr Geschäft zu betreiben. Die Nutzer haben das Recht, zu verstehen, was sie konsumieren. Und der Begriff Cloud hat das Recht, präzise verwendet zu werden.

Architektur statt Versprechen. Das ist die ruhige Variante des alten Witzes.⛵

Quellen und weiterführende Links

Zum historischen Kontext

Zur rechtlichen Lage (CLOUD Act und Schrems II)

Zu den technischen Gegenarchitekturen

Zur Vertiefung Retrieval Augmented Generation (RAG)

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.