Cloud-Architektur und KI: was wo läuft und wer wofür haftet
Cloud-Architektur und KI: was wo läuft und wer wofür haftet
Artikel-Übersicht
Zwei Fragen werden ständig vermischt: „KI aus der Cloud nutzen" und „KI-Systeme in der Cloud betreiben". Das ist nicht dasselbe, und der Unterschied entscheidet über Kosten, Datenschutz und Architektur. Dieser Artikel sortiert zuerst die drei Bedeutungen, erklärt dann das Kostenmodell — ohne Preise, weil die veralten — und liefert die Entscheidungstabelle zwischen eigenem Betrieb, gemieteter Hardware und gehosteter Schnittstelle. Danach die Bereitstellungsmodelle, das Modell der geteilten Verantwortung als Matrix, und Serverless mit einer klaren Aussage dazu, warum es für KI-Inferenz meist nicht taugt. Ein eigener Abschnitt behandelt die Datenresidenz in Deutschland, Österreich und der Schweiz — im DACH-Raum häufig das eigentliche Auswahlkriterium. Zum Schluss die Bausteine einer KI-Anwendung.
KI aus der Cloud: die drei Bedeutungen
„KI aus der Cloud" kann drei verschiedene Dinge meinen, und sie unterscheiden sich vor allem darin, wer die Daten sieht.
1. Fertige Modelle über eine Schnittstelle nutzen. Du schickst eine Anfrage an einen Anbieter und bekommst eine Antwort. Kein Betrieb, keine Hardware, Abrechnung pro Token. Die stärksten verfügbaren Modelle gibt es nur so. Deine Eingaben verlassen dabei das Haus.
2. Modelle auf gemieteter Infrastruktur selbst betreiben. Du mietest eine Maschine mit Beschleuniger und betreibst dort dein eigenes Modell. Du bezahlst Rechenzeit statt Anfragen, hast volle Kontrolle über das Modell — und trägst den Betriebsaufwand. Die Daten bleiben in deiner Umgebung, wenn auch nicht auf deiner Hardware.
3. Verwaltete KI-Plattformen. Die Anbieter stellen fertige Dienste bereit — Modellhosting, Vektorspeicher, Ablaufsteuerung. Bequem, und zugleich die Variante mit der stärksten Bindung, weil die Bausteine selten austauschbar sind.
Wer über „KI in der Cloud" spricht, sollte immer sagen, welche der drei gemeint ist. Die Kostenrechnung, die Datenschutzfrage und die Architektur unterscheiden sich vollständig.
Was das kostet
Keine Preise — sie ändern sich zu schnell. Die Kostenmodelle:
| Variante | Abrechnung | Wächst mit | Bricht ein bei |
|---|---|---|---|
| Gehostete Schnittstelle | pro Token, Eingabe und Ausgabe getrennt | Nutzungsmenge | konstant hoher Last |
| Gemietete Hardware | pro Stunde, unabhängig von der Nutzung | Laufzeit | geringer oder schwankender Last |
| Verwaltete Plattform | Bereitstellung plus Nutzung | beidem | Unübersichtlichkeit |
| Eigene Hardware | einmalig plus Strom | nichts | Auslastung unter etwa 30 % |
Die Faustregel: Bei geringer und schwankender Nutzung ist die gehostete Schnittstelle günstiger, als man denkt — man zahlt nichts, wenn nichts läuft. Ab einer konstanten Grundlast kippt die Rechnung zugunsten gemieteter oder eigener Hardware.
Der Kipppunkt liegt niedriger, als viele vermuten, weil Ausgabe-Token bei allen Anbietern deutlich teurer sind als Eingabe-Token. Wer viel erzeugen lässt, erreicht ihn schnell. Die einzelnen Hebel zur Kostensenkung behandle ich in LLM-Kosten optimieren.
Selbst betreiben oder mieten?
| Kriterium | Spricht für eigenen Betrieb | Spricht für gehostete Schnittstelle |
|---|---|---|
| Datenschutz | Daten dürfen das Haus nicht verlassen | keine besonderen Anforderungen |
| Last | konstant, planbar | schwankend, unvorhersehbar |
| Modellgröße | mittlere Modelle reichen | größte verfügbare Qualität nötig |
| Betriebskompetenz | vorhanden | nicht vorhanden |
| Kostenstruktur | Investition bevorzugt | laufende Kosten bevorzugt |
| Reproduzierbarkeit | Modell soll sich nicht ändern | immer die neueste Fassung |
Der letzte Punkt wird unterschätzt: Ein gehostetes Modell kann sich ändern, ohne dass du es merkst. Für Auswertungen, die über Jahre vergleichbar bleiben sollen, ist ein lokal eingefrorenes Modell die einzige Möglichkeit.
Wie der lokale Betrieb praktisch aussieht, steht in Ollama: lokale Sprachmodelle betreiben; wie man den Speicherbedarf ausrechnet, in Welches Ollama-Modell?.
Bereitstellungsmodelle
| Modell | Was es bedeutet | Wann sinnvoll |
|---|---|---|
| Öffentliche Cloud | geteilte Infrastruktur eines Anbieters | Normalfall, beste Kostenstruktur |
| Private Cloud | dedizierte Infrastruktur, eigen oder gemietet | regulatorische Anforderungen, konstante Last |
| Hybrid | Teile öffentlich, Teile privat | schrittweise Migration, sensible Teilbereiche |
| Souverän | Betrieb nach Rechtsraum, Zugriff eingeschränkt | öffentliche Hand, kritische Infrastruktur |
Der Begriff souveräne Cloud verdient eine Einordnung, weil er in Ausschreibungen zunehmend auftaucht und selten definiert wird. Gemeint ist meist eine Kombination aus: Betrieb im Rechtsraum, Personal im Rechtsraum, technische Zugriffsbeschränkung gegen den Mutterkonzern, und vertragliche Zusicherungen. Was davon im Einzelfall tatsächlich zugesichert wird, steht im Vertrag und nicht im Marketingmaterial — hier lohnt genaues Lesen.
Geteilte Verantwortung
Die Frage, die in jedem Audit gestellt wird und die in der Praxis am häufigsten falsch beantwortet wird.
Der Anbieter ist für die Sicherheit der Cloud verantwortlich, du für die Sicherheit in der Cloud.
| Ebene | IaaS | PaaS | SaaS |
|---|---|---|---|
| Rechenzentrum, Hardware | Anbieter | Anbieter | Anbieter |
| Virtualisierung | Anbieter | Anbieter | Anbieter |
| Betriebssystem | Kunde | Anbieter | Anbieter |
| Laufzeitumgebung | Kunde | Anbieter | Anbieter |
| Anwendung | Kunde | Kunde | Anbieter |
| Konfiguration | Kunde | Kunde | Kunde |
| Zugriffsrechte | Kunde | Kunde | Kunde |
| Daten | Kunde | Kunde | Kunde |
Die drei letzten Zeilen sind in allen Modellen Kundensache, und genau dort liegen die meisten Vorfälle. Die überwiegende Mehrheit der bekanntgewordenen Datenabflüsse aus Cloud-Umgebungen geht auf Fehlkonfigurationen zurück, nicht auf Ausfälle oder Einbrüche beim Anbieter — ein offener Speicherbereich, ein zu weit gefasstes Zugriffsrecht, ein vergessener Testzugang.
Für KI-Anwendungen kommt eine Zeile hinzu, die in keiner Standardmatrix steht: Was der Anbieter mit deinen Eingaben macht. Ob sie zum Training verwendet werden, wie lange sie gespeichert bleiben, wer darauf zugreifen kann. Das ist vertraglich geregelt, unterscheidet sich je Anbieter und Tarif, und ändert sich. Die rechtliche Seite behandle ich in KI, Datenschutz und Recht.
Serverless
Serverless bedeutet, dass du Code bereitstellst und der Anbieter die Ausführungsumgebung stellt — abgerechnet wird nach tatsächlicher Ausführung.
Die Stärken: keine Serververwaltung, automatische Skalierung von null bis viel, Abrechnung nur bei Nutzung.
Die Grenzen, und sie sind für KI-Anwendungen entscheidend:
- Kaltstart. Eine Funktion, die länger nicht lief, braucht Zeit zum Hochfahren. Bei kleinen Funktionen sind das Millisekunden, bei großen Laufzeitumgebungen Sekunden.
- Laufzeitbegrenzung. Die meisten Anbieter beenden eine Ausführung nach einigen Minuten.
- Speicher- und Größenbegrenzungen. Ein Modell mit mehreren Gigabyte passt nicht in eine typische Funktionsumgebung.
- Kein Zustand zwischen Aufrufen. Was geladen werden muss, wird bei jedem Kaltstart neu geladen.
Daraus folgt: Serverless ist für KI-Inferenz meist die falsche Wahl. Ein Modell, das bei jedem Kaltstart geladen werden muss, ist entweder langsam oder teuer, weil man Instanzen warmhalten muss — und dann ist der Vorteil weg.
Wofür es sich in einer KI-Anwendung trotzdem eignet: die Teile drumherum. Dokumente vorverarbeiten, Ereignisse weiterreichen, Ergebnisse nachbearbeiten, geplante Aufgaben.
Zugriff und Absicherung
Ein verwandter Punkt: Interne Anwendungen von außen erreichbar machen, ohne ein VPN zu betreiben. Die großen Anbieter haben dafür Dienste, die Anwendungen über eine authentifizierte Verbindung veröffentlichen — der interne Dienst bleibt im eigenen Netz, der Zugriff läuft über die Identitätsverwaltung.
Für KI-Anwendungen ist das oft die pragmatische Antwort auf die Frage, wie ein intern betriebenes Modell für Mitarbeitende erreichbar wird, ohne es ins offene Netz zu stellen.
Datenresidenz in Deutschland, Österreich und der Schweiz
Der Abschnitt, an dem im DACH-Raum die meisten Vorhaben entschieden werden — und den kein Anbieter neutral schreibt.
Deutschland und Österreich. Es gilt die DSGVO. Personenbezogene Daten dürfen verarbeitet werden, wenn eine Rechtsgrundlage besteht und mit dem Anbieter ein Vertrag zur Auftragsverarbeitung geschlossen ist. Übermittlungen in Drittländer brauchen zusätzliche Absicherung. Alle großen Anbieter betreiben EU-Regionen; die Frage ist nicht nur, wo die Daten liegen, sondern auch, wer von wo darauf zugreifen kann.
Schweiz. Das revidierte Datenschutzgesetz stellt eigene Anforderungen. Für Schweizer Unternehmen ist „die Daten bleiben in der Schweiz" häufig ein härteres Kriterium als in der EU — teils rechtlich, teils weil es gegenüber Kunden das stärkere Argument ist. Mehrere Anbieter betreiben Schweizer Regionen.
Die Frage, die bei KI hinzukommt und in klassischen Cloud-Betrachtungen fehlt: Werden Eingaben zum Training verwendet? Das ist unabhängig vom Speicherort und unterscheidet sich je Anbieter und Tarif. Bei geschäftlichen Verträgen ist die Nichtnutzung meist zugesichert, bei kostenlosen Angeboten häufig nicht.
Der praktische Rat für Unternehmen mit Standorten in mehreren Ländern: Am strengsten Standard ausrichten. Zwei parallele Regelwerke zu betreiben kostet mehr als der Verzicht auf die bequemere Variante.
Eine KI-Anwendung in der Cloud: die Bausteine
Was eine produktive Anwendung braucht, jenseits des Modellzugriffs:
| Baustein | Wofür | Worauf achten |
|---|---|---|
| Modellzugriff | die eigentliche Inferenz | hinter einer eigenen Schnittstelle kapseln — Anbieter wechseln |
| Vektorspeicher | semantische Suche über eigene Daten | Wechsel des Embedding-Modells erzwingt Neuberechnung |
| Warteschlange | lange Läufe von der Anfrage entkoppeln | Wiederholbarkeit, Idempotenz |
| Geheimnisverwaltung | Schlüssel und Zugangsdaten | nie in Abbildern oder Repositories |
| Beobachtbarkeit | Latenz, Tokenverbrauch, Fehlerquote | Qualität ist nicht dasselbe wie Verfügbarkeit |
| Zwischenspeicher | wiederkehrende Anfragen | größter einzelner Kostenhebel |
Der erste Punkt ist der wichtigste und zugleich eine Architekturentscheidung: Kapsle den Modellzugriff hinter einer eigenen Schnittstelle. Modelle und Anbieter wechseln derzeit im Halbjahrestakt. Wer den Anbieter-Client quer durch die Anwendung streut, hat bei jedem Wechsel einen Umbau statt einer Konfigurationsänderung. Das ist genau der Fall, für den die Abhängigkeitsumkehr aus Clean Architecture gemacht ist.
Die einzelnen Bausteine behandle ich getrennt: RAG selbst bauen für die Suchstrecke, Vektordatenbanken im Vergleich für den Speicher, Event-Driven Architecture mit Apache Kafka für die Entkopplung und Monitoring und Observability für den Betrieb.
Häufige Fragen
Was ist KI aus der Cloud? Drei verschiedene Dinge: fertige Modelle über eine Schnittstelle nutzen, eigene Modelle auf gemieteter Infrastruktur betreiben, oder verwaltete KI-Plattformen einsetzen. Sie unterscheiden sich vor allem darin, wer die Daten sieht.
Was kostet KI in der Cloud? Je nach Variante pro Token, pro Stunde oder als Bereitstellung plus Nutzung. Bei schwankender Last ist die gehostete Schnittstelle günstiger, ab konstanter Grundlast kippt es.
Wer haftet wofür in der Cloud? Der Anbieter für die Sicherheit der Cloud, der Kunde für die Sicherheit in der Cloud. Konfiguration, Zugriffsrechte und Daten sind in allen Modellen Kundensache — und dort passieren die meisten Vorfälle.
Wann lohnt sich Serverless? Für kurze, ereignisgesteuerte Aufgaben mit schwankender Last. Für KI-Inferenz meist nicht, wegen Kaltstart, Laufzeit- und Größenbegrenzungen.
Wann betreibt man KI selbst statt in der Cloud? Wenn Daten das Haus nicht verlassen dürfen, die Last konstant ist, mittlere Modelle ausreichen und Betriebskompetenz vorhanden ist.
Was ist eine souveräne Cloud? Meist eine Kombination aus Betrieb im Rechtsraum, Personal im Rechtsraum und technischen Zugriffsbeschränkungen. Was tatsächlich zugesichert wird, steht im Vertrag.
Zusammenfassung und praktische Tipps
Cloud und KI zusammen erzeugen Fragen, die keine der beiden Seiten allein beantwortet. Die wichtigsten Punkte:
- Kläre zuerst, welche der drei Bedeutungen gemeint ist. Kosten, Datenschutz und Architektur unterscheiden sich vollständig.
- Bei schwankender Last ist die gehostete Schnittstelle günstiger — der Kipppunkt liegt bei konstanter Grundlast.
- Konfiguration, Zugriffsrechte und Daten sind immer Kundensache. Dort passieren die Vorfälle.
- Serverless ist für Inferenz meist die falsche Wahl, für alles drumherum oft die richtige.
- Die Trainingsnutzung von Eingaben ist unabhängig vom Speicherort und muss getrennt geprüft werden.
- Kapsle den Modellzugriff hinter einer eigenen Schnittstelle — Anbieter wechseln schneller als deine Anwendung.
- Bei mehreren Ländern am strengsten Standard ausrichten.
Mein Rat für den Einstieg: Schreib auf, welche Daten in eine Modellanfrage gehen, bevor du über Anbieter sprichst. Diese eine Liste beantwortet die Datenschutzfrage, sie zeigt dir, ob lokaler Betrieb nötig ist, und sie ist die Grundlage für jedes Gespräch mit Datenschutz und Betriebsrat. Alles andere — Kosten, Modellauswahl, Architektur — lässt sich danach entscheiden.
Ressourcen
- AWS Shared Responsibility Model – die Verantwortungsmatrix des größten Anbieters
- BSI – Cloud Computing – Empfehlungen des Bundesamts
- EDÖB – Datenschutz Schweiz – der eidgenössische Datenschutzbeauftragte zum revDSG
- EU – Standardvertragsklauseln – Grundlage für Drittlandübermittlungen