Lokal, Cloud oder hybrid?

Die Frage „Welche KI sollen wir verwenden?“ klingt technisch. In Projekten ist sie vor allem eine Architekturfrage.

Denn ein Modell ist nie nur ein Modell. Mit jeder Entscheidung für lokal, Cloud oder eine Kombination daraus entscheiden wir zugleich über Datenwege, Abhängigkeiten, Kosten, Latenz, Verfügbarkeit, Kontrollmöglichkeiten, Update-Risiken und die Frage, wie leicht ein Projekt später den Anbieter oder das Modell wechseln kann.

Ein lokales Modell kann sensible Daten auf dem eigenen System halten und trotzdem schlecht abgesichert sein. Ein Cloud-Modell kann Daten außerhalb der eigenen Infrastruktur verarbeiten und trotzdem über belastbare Unternehmensverträge, Verschlüsselung, Aufbewahrungsregeln und Datenresidenz verfügen. Ein Hybridansatz kann das Beste aus beiden Welten verbinden – oder die Komplexität beider Welten gleichzeitig erben.

Die professionelle Leitfrage lautet deshalb nicht:

Lokal oder Cloud?

Sondern:

Welche Teile unseres Projekts müssen unter unserer direkten Kontrolle bleiben, welche dürfen externe Rechenleistung nutzen – und wie bauen wir die Übergänge so, dass Qualität, Souveränität und Handlungsfähigkeit erhalten bleiben?

Souveränität ist mehr als der Standort eines Modells

In Diskussionen über KI-Souveränität wird häufig zuerst über Serverstandorte gesprochen. Das ist verständlich, aber zu kurz gedacht.

Ein Projekt kann seine Daten im eigenen Rechenzentrum speichern und trotzdem von einem proprietären Modellformat, einem einzelnen Hardware-Stack oder einem externen Lizenzserver abhängig sein. Umgekehrt kann ein Cloud-Dienst so eingesetzt werden, dass keine projektkritischen Rohdaten an ihn gelangen und jederzeit ein zweiter Provider übernehmen kann.

Souveränität bedeutet deshalb vor allem Entscheidungsfähigkeit unter Veränderung.

Ein souveränes Projekt kann beantworten: Wo befinden sich welche Daten? Wer kann sie lesen? Welche Modellinstanz verarbeitet sie? Welche externen Dienste sind für den Betrieb unverzichtbar? Kann ein Provider ausfallen, ohne dass das gesamte Projekt stoppt? Kann ein Modell ersetzt werden, ohne die komplette Prozesslogik neu zu bauen? Welche Entscheidungen bleiben auch bei einem Wechsel von Cloud zu lokal oder von Provider A zu Provider B reproduzierbar?

Der physische Ort der Inferenz ist wichtig. Aber er ist nur ein Teil eines größeren Kontrollmodells.

Drei Ebenen der KI-Souveränität

Für praktische Projekte hilft eine Dreiteilung.

Diese Ebenen sind nicht identisch.

Ein vollständig lokaler Betrieb kann hohe Daten- und Rechensouveränität bieten, aber geringe Modellsouveränität, wenn die gesamte Anwendung auf einem einzigen nicht portierbaren Stack basiert. Ein Multi-Cloud-System kann hohe Provider-Redundanz besitzen, aber geringe Datensouveränität, wenn sensible Inhalte unkontrolliert durch mehrere externe Dienste wandern.

Souveränität entsteht daher nicht durch ein Label wie „on premise“ oder „EU cloud“, sondern durch die Architektur der Abhängigkeiten.

Lokal, Cloud und hybrid sind Betriebsmodelle – keine Qualitätsklassen

„Lokal“ bedeutet im Kern: Modell und relevante Verarbeitung laufen auf eigener oder direkt kontrollierter Infrastruktur.

„Cloud“ bedeutet: Rechenleistung oder KI-Dienst wird über externe Infrastruktur bezogen.

„Hybrid“ bedeutet in diesem Zusammenhang: Ein Projekt verteilt KI-Verarbeitung bewusst über mindestens zwei unterschiedlich kontrollierte Ausführungsräume – zum Beispiel lokale Modelle für vertrauliche Verarbeitung und Cloud-Modelle für besonders anspruchsvolle, nicht sensible Aufgaben.

Wichtig: Das ist breiter als die klassische NIST-Definition einer „Hybrid Cloud“.^[4] Eine Hybrid-KI-Architektur kann lokale Workstations, private Server, öffentliche APIs und mehrere Modellprovider verbinden, ohne dass alle Teile klassische Cloud-Infrastruktur im engeren Sinn sind.

Keine dieser Varianten ist grundsätzlich überlegen.

Die richtige Wahl hängt vom Workload ab.

Was lokale KI tatsächlich verändert

Lokale Inferenz hat einen fundamentalen Vorteil: Der Datenpfad kann deutlich kürzer werden.

Wenn Eingaben, Retrieval, Modell und Output vollständig innerhalb einer kontrollierten Umgebung bleiben, muss der Rohinhalt nicht an einen externen KI-Provider übertragen werden. Für Geschäftsgeheimnisse, unveröffentlichte Forschung, interne Verträge, sensible personenbezogene Daten oder proprietären Code kann das ein entscheidender Architekturvorteil sein.

Zusätzlich entstehen weitere Eigenschaften: Modelle können auch ohne Internetverbindung verfügbar bleiben, Kosten verschieben sich von variablen API-Kosten zu Hardware, Strom, Betrieb und Wartung, Modellversionen können eingefroren und kontrolliert aktualisiert werden, Telemetrie lässt sich selbst gestalten, Spezialmodelle können auf einen begrenzten Aufgabenraum optimiert werden, und ein lokaler Fallback kann Cloud-Ausfälle abfedern.

Aber diese Vorteile sind nicht kostenlos.

Lokal bedeutet nicht automatisch sicher oder compliant

Ein häufiger Fehler lautet: „Die Daten bleiben auf dem Rechner, also ist alles sicher.“

Das stimmt nicht.

Ein lokales System kann veraltete Modellgewichte, unsichere Python-Pakete, offene Netzwerkports, schlecht geschützte API-Keys, unverschlüsselte Logs oder kompromittierte Extensions enthalten. Ein Laptop kann gestohlen werden. Ein lokaler Vector Store kann zu breit freigegeben sein. Ein Agent kann Dateien löschen oder sensible Inhalte in Debug-Logs schreiben.

Auch datenschutzrechtlich ist lokal keine automatische Freikarte. Die Grundprinzipien wie Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht gelten weiterhin, sobald personenbezogene Daten verarbeitet werden.

Die korrekte Aussage lautet deshalb:

Lokale Verarbeitung kann externe Datenübertragung reduzieren und die technische Kontrolle erhöhen. Sie ersetzt aber weder Sicherheitsarchitektur noch Datenschutz-Governance.

Die detaillierte Compliance-Logik gehört in den nächsten Artikel. Für die Architekturentscheidung reicht hier die Konsequenz: Lokal ist ein Kontrollmittel, kein Compliance-Zertifikat.

Was Cloud-KI tatsächlich bietet

Cloud-KI gewinnt nicht nur wegen größerer Modelle.

Sie bietet vor allem Elastizität: keine lokale Hardwarebeschaffung, schnelle Skalierung, leistungsfähige Frontier-Modelle, multimodale APIs, zentrale Updates und oft ein breites Tool-Ökosystem.

Für Projekte kann das bedeuten: hohe Spitzenlast ohne eigene GPU-Flotte, sehr kurze Zeit bis zum ersten Prototyp, Zugang zu spezialisierten Modellen, geringerer lokaler Betriebsaufwand, globale Verfügbarkeit und leichtere Skalierung über viele Nutzende.

Cloud ist daher besonders attraktiv, wenn Capability und Time-to-Value wichtiger sind als maximale lokale Kontrolle.

Aber auch hier gilt: Man kauft nicht nur Rechenleistung. Man übernimmt einen Teil der Betriebsabhängigkeit des Providers.

Cloud bedeutet nicht automatisch „Training mit unseren Daten“

Ebenso problematisch wie die Verklärung lokaler Systeme ist die pauschale Behauptung, jede Cloud-KI würde Geschäftsdaten automatisch zum Modelltraining verwenden.

Bei professionellen Angeboten können die Bedingungen deutlich anders aussehen. OpenAI erklärt für Business-, Enterprise- und API-Produkte beispielsweise, dass Geschäftsdaten standardmäßig nicht zum Training der Modelle verwendet werden; für bestimmte API-Szenarien existieren außerdem Aufbewahrungs- und Datenresidenzoptionen.^[5]

Das macht Cloud-Verarbeitung nicht automatisch passend für jeden Datentyp. Es zeigt aber, warum Architekturentscheidungen vertragliche und technische Produkteigenschaften prüfen müssen, statt nur das Wort „Cloud“ zu bewerten.

Die relevanten Fragen lauten: Wird auf unseren Daten trainiert? Wie lange werden Inputs und Outputs gespeichert? Wo erfolgt Verarbeitung und Speicherung? Welche Subprozessoren sind beteiligt? Welche Admin- und Audit-Funktionen existieren? Können Retention und Logging reduziert werden? Welche Vertrags- und Transfermechanismen gelten?

Ein Providername allein beantwortet keine dieser Fragen.

Der Hybridansatz ist kein 50/50-Kompromiss

Hybrid bedeutet nicht, dass die Hälfte der Aufgaben lokal und die andere Hälfte in der Cloud landet.

Eine gute Hybridarchitektur routet nach Eigenschaften des Arbeitsschritts.

Ein Beispiel:

1. Vertragsdokumente werden lokal eingelesen und klassifiziert.

2. Namen, interne Kennungen und vertrauliche Anhänge bleiben im lokalen Datenraum.

3. Ein lokales Modell erzeugt eine abstrahierte Problemrepräsentation.

4. Nur diese abstrahierte, freigegebene Darstellung wird für besonders anspruchsvolles Reasoning an ein Cloud-Modell gesendet.

5. Das Ergebnis kehrt in den lokalen Raum zurück.

6. Die finale Entscheidung, Zusammenführung und Ablage erfolgen lokal.

Damit wird nicht „lokal gegen Cloud“ entschieden. Es wird für jeden Übergang entschieden.

Genau darin liegt die Stärke des hybriden Modells.

Vor Model Routing kommt Data Routing

Viele Teams beginnen mit einem Modellrouter: Kleine Aufgaben gehen an Modell A, komplexe an Modell B.

Für souveräne Projekte ist das zu spät.

Zuerst muss entschieden werden, welche Information welchen Ausführungsraum überhaupt verlassen darf.

Eine einfache Datenklassifikation kann bereits viel bewirken:

Die konkrete Klassifikation muss zur Organisation passen. Das Prinzip ist entscheidend: Der Router entscheidet nicht nur nach Modellqualität, sondern nach Datenfreigabe.

Eine souveräne KI-Architektur braucht fünf Ebenen

Die Entscheidung lokal oder Cloud wird robuster, wenn das Projekt nicht als „Chat mit Modell“ gedacht wird, sondern als System aus Schichten.

1. Data Plane

Hier liegen Dateien, Datenbanken, Retrieval-Indizes, Secrets und der kanonische Projektzustand.

Die Data Plane bestimmt, welche Daten überhaupt verfügbar sind und welche Zonengrenzen existieren.

2. Inference Plane

Hier laufen lokale und externe Modelle.

Nicht jedes Modell erhält automatisch denselben Kontext.

3. Orchestration Plane

Sie entscheidet, welcher Task an welches Modell geht, welche Fallbacks zulässig sind und wann ein menschliches Gate erforderlich ist.

4. Action Plane

Hier befinden sich Tools, APIs, Dateisystemzugriffe, Datenbank-Schreibrechte und andere reale Nebenwirkungen.

Ein Cloud-Modell kann zum Beispiel Reasoning liefern, ohne direkt Schreibrechte auf interne Systeme zu erhalten.

5. Evidence Plane

Hier werden Runs, Modellidentität, Routingentscheidung, Artefakte und Freigaben dokumentiert.

Damit bleibt nachvollziehbar, welcher Teil lokal und welcher extern verarbeitet wurde.

Diese Ebenen dürfen technisch in derselben Anwendung liegen. Architektonisch sollten sie trotzdem getrennt gedacht werden.

Der Model Router ist eine Policy Engine

Ein guter Router fragt nicht einfach: „Welches Modell ist am billigsten?“

Er bewertet mehrere Dimensionen gleichzeitig:

Sensitivity – Welche Datenklasse verarbeitet der Task?

Capability – Welche Mindestqualität benötigt er?

Latency – Wie schnell muss ein Ergebnis vorliegen?

Cost – Welches Budget ist akzeptabel?

Availability – Welche Provider sind aktuell verfügbar?

Context – Welche Kontextgröße wird benötigt?

Tooling – Welche Tools oder Modalitäten werden gebraucht?

Action Risk – Darf das Modell nur lesen, Vorschläge machen oder handeln?

Ein Routing-Entscheid kann deshalb so aussehen:

D2 + read-only + Standardanalyse → lokales Modell.

D0 + hohe Reasoning-Anforderung → Frontier-Cloud-Modell.

D3 + hohe Reasoning-Anforderung → zunächst lokale Reduktion/Abstraktion; Cloud nur nach expliziter Freigabe.

So wird Routing zu einer steuerbaren Architekturentscheidung statt zu einer unsichtbaren Kostenoptimierung.

Local-first mit Capability Escalation

Ein besonders robustes Muster ist Local-first.

Der Task beginnt lokal. Das System versucht zunächst, ihn innerhalb der kontrollierten Zone zu lösen. Erst wenn eine definierte Qualitäts- oder Fähigkeitsgrenze nicht erreicht wird, darf eine Eskalation erfolgen.

Dafür braucht es eine Capability-Schwelle: Besteht die lokale Antwort den Eval, wird lokal abgeschlossen. Scheitert sie, wird die Datenfreigabe geprüft. Ist der Inhalt freigabefähig, folgt die Cloud-Eskalation. Ist er es nicht, bleiben eine lokale Spezialroute, menschlicher Review oder der Abbruch.

Dieses Muster verhindert, dass Cloud-Nutzung zum Default wird, nur weil sie bequem ist.

Gleichzeitig verhindert es dogmatische Lokalität: Wenn ein lokales Modell die Aufgabe nicht zuverlässig lösen kann, wird die Qualitätslücke sichtbar statt schöngeredet.

Cloud-first mit kontrolliertem Rückzug

Auch das Gegenmuster kann sinnvoll sein.

Bei öffentlichen oder niedrig sensitiven Daten kann ein Projekt Cloud-first arbeiten und lokale Systeme als Fallback und Exit-Option vorhalten.

Der Vorteil liegt in hoher Startgeschwindigkeit und Capability. Die Voraussetzung lautet aber, dass wesentliche Projektobjekte außerhalb des Providers leben: eigener kanonischer State, eigene Prompt- und Policy-Versionen, portable Tool-Schemas, eigene Artefakte, eigene Evaluationssets und eigene Routinglogik.

Dann ist die Cloud ein austauschbarer Ausführungsraum – nicht das Gedächtnis des Projekts.

Split Processing: Sensitives lokal, Abstraktion extern

Zwischen vollständig lokal und vollständig Cloud liegt ein mächtiges Muster: Split Processing.

Dabei wird die Aufgabe zerlegt.

Das lokale System kann beispielsweise personenbezogene Daten entfernen, Dokumente klassifizieren, interne IDs pseudonymisieren, irrelevante Anhänge entfernen, Codeauszüge minimieren oder eine strukturierte Zusammenfassung erzeugen.

Erst danach erhält ein externes Modell den freigegebenen Ausschnitt.

Wichtig ist, diese Technik nicht mit perfekter Anonymisierung zu verwechseln. Eine Zusammenfassung kann weiterhin sensible Informationen enthalten; Pseudonymisierung ist nicht Anonymisierung. Die Architektur reduziert Exposition, garantiert aber nicht automatisch Datenschutzkonformität.

Provider-Volatilität ist ein Projektrisiko

Ein KI-Projekt kann methodisch sauber sein und trotzdem an seinem Provider scheitern.

Mögliche Ursachen sind API-Ausfall, Rate Limits, regionale Störung, Modell-Deaktivierung, Preisanpassung, veränderte Limits, geänderte Sicherheitsrichtlinien, geänderte Toolfähigkeiten oder eine neue Modellversion mit anderem Verhalten.

Darum gehört Provider-Volatilität in die Architektur – nicht nur in eine Risikoliste.

Die Frage lautet nicht: „Kann der Provider ausfallen?“

Sondern:

Was tut unser System in der ersten Minute nach dem Ausfall?

Ein zweiter API-Key ist noch kein Fallback

Ein echtes Fallback-System braucht mehr als einen alternativen Endpoint.

Es braucht mindestens:

1. Trigger – Wann wird umgeschaltet?

2. Compatibility Contract – Kann das Ersatzmodell denselben Input und dieselben Tools verarbeiten?

3. Quality Floor – Welche Mindestqualität muss die Ersatzroute erfüllen?

4. State Transfer – Welcher Projektzustand wird übergeben?

5. Data Policy – Darf dieser Datentyp überhaupt zum Ersatzprovider?

6. Recovery Rule – Wann und wie kehrt das System zurück?