# Warum sich frontier Modelle und Privacy nicht ausschließen

> LLMs laufen nicht mehr im eigenen Rechenzentrum - jedenfalls nicht ohne signifikante Investition. Wer sensible Daten trotzdem nicht ungefiltert in die Cloud schicken will, braucht keinen eigenen GPU-Cluster, sondern einen Router davor.

- URL: https://blog.goroot.de/de/post/hybrid-llm-data-sovereignty/
- Erstveröffentlichung: 2026-08-19
- Lastmod: 2026-08-19
- 1459 Wörter, 7 min
- Tags: ai, llm, data-sovereignty, self-hosted, privacy
- Autor: Michael Kolb — goroot (https://blog.goroot.de/de/)

---


Die Frage kommt in praktisch jedem Projekt, das gerade ein LLM-Feature bekommt, früher oder später: Darf das, was hier prozessiert wird, überhaupt in die Cloud? Support-Tickets mit Namen und Vertragsnummern, interne Notizen mit Gehaltsdaten, Code mit Kunden-Secrets im Kontextfenster - sobald ein Feature über den Demo-Status hinaus geht, taucht ein Datensatz auf, den niemand OpenAI, Anthropic oder Google schicken will. Und dann kommt der Reflex: "Dann hosten wir das Modell eben selbst." An dieser Stelle funkt die Kostenrealität dazwischen.

## Warum "einfach selbst hosten" an der Kostenrealität scheitert

Ein Modell in Frontier-Qualität - GPT-, Claude- oder Gemini-Klasse - selbst zu betreiben, ist keine Option, die für ein Team mit fünf, fünfzig oder hundert Leuten realistisch auf dem Tisch liegt. Diese Modelle laufen auf Clustern mit zwei- bis dreistelliger H100-Anzahl. Selbst wer sich das leisten kann, bekommt nie die gleiche Modellqualität wie die Anbieter selbst, die kontinuierlich nachtrainieren.

Die eigentlich interessante Erkenntnis: Man braucht diese Modellklasse gar nicht für jede Anfrage. Ein Großteil dessen, was in Unternehmen an ein LLM geschickt wird, ist trivial - Zusammenfassen, Umformulieren, Kategorisieren, einfache Extraktion. Dafür reicht ein 8B- oder 14B-Modell auf einer einzelnen Consumer-GPU völlig aus. Die Frage ist also nicht "eigenes Rechenzentrum oder Cloud", sondern: welche Anfrage braucht wirklich das teure Modell, und welche nicht.

## Das eigentliche Problem ist der Kontext, nicht das Modell

Datensouveränität wird gern als Deployment-Entscheidung behandelt: "Wir nutzen jetzt ein On-Premise-Modell." Das greift zu kurz. Die Frage, ob eine Anfrage die eigene Infrastruktur verlassen darf, lässt sich nicht auf Modellebene beantworten, sondern nur pro Anfrage - auf Ebene des Kontexts, der gerade im Prompt steckt.

Zwei Support-Tickets aus derselben Warteschlange können völlig unterschiedliche Anforderungen haben. "Wie ändere ich mein Passwort?" ist unkritisch für die Cloud. "Herr Meier, geboren am 3.4.1981, Kundennummer 88213, beschwert sich über die Abrechnung seiner Berufsunfähigkeitsversicherung" ist es nicht. Ein statisches Deployment - alles lokal oder alles Cloud - behandelt beide Fälle gleich und ist damit entweder unnötig teuer oder unnötig riskant.

## Der Router: ein sensitivity-aware Gateway statt Bauchgefühl

Die Komponente, die diese Entscheidung trifft, bevor irgendein Modell die Anfrage sieht, hat in der Praxis mehrere Namen, je nachdem aus welcher Ecke man kommt. Als **AI Gateway** bzw. **LLM Gateway** bezeichnen es Anbieter, die den Fokus auf PII-Erkennung[^2] legen: Der Prompt wird am Gateway gescannt, und bei einem Treffer geht die Anfrage automatisch an ein On-Premise-Modell statt an die Cloud-API. In der Forschung zu Routing-Architekturen taucht der Begriff **Sensitivity-aware Routing** bzw. **Semantic Routing** auf - ein Router vor der Inference-API entscheidet anhand von Datensensitivität, Aufgabenkomplexität und Nutzergruppe, welches Modell die Anfrage bekommt. Am nächsten an dem, was ich mir vorstelle, kommt die **Hybrid Local-Cloud Architecture**: ein vertrauenswürdiger, lokaler "Local Controller" übernimmt Planung, Routing und einfaches Reasoning selbst und delegiert nur bei Bedarf an ein nicht-vertrauenswürdiges "Cloud Language Model".[^1]

Wichtig ist das Prinzip, nicht der Name: Klassifizierung passiert, bevor ein Prompt irgendeine Grenze überschreitet, und im Zweifel wird lokal verarbeitet, nie im Zweifel an die Cloud delegiert. Fail closed, nicht fail open. In Code sieht die Entscheidungslogik - bewusst vereinfacht - etwa so aus:

```go
// Route entscheidet, welche Stufe des Stacks eine Anfrage bearbeitet.
// Sensible Kontexte verlassen die eigene Infrastruktur nie - auch dann nicht,
// wenn das lokale Modell für die Aufgabe eigentlich zu schwach ist.
func Route(ctx context.Context, req Prompt) Tier {
	if classifier.ContainsSensitiveContext(ctx, req) {
		return TierDatacenterGPU
	}
	if req.Complexity <= complexityTrivial {
		return TierLocalOllama
	}
	return TierCloud
}
```

Die Klassifizierung selbst muss dabei nicht kompliziert sein. Ein Regelwerk aus Regex-Mustern für Kundennummern, IBANs und Namen aus dem eigenen CRM erkennt einen Großteil der Fälle. Für alles, was Muster-basiert nicht sauber zu fassen ist, reicht oft ein sehr kleines lokales Modell - etwa ein 1B- bis 3B-Modell, das nur eine Frage beantwortet: "Enthält dieser Text personenbezogene oder vertrauliche Informationen? Ja/Nein." Das läuft in Millisekunden auf jeder halbwegs aktuellen GPU und muss selbst nicht gut im eigentlichen Task sein - nur beim Erkennen, wann Vorsicht angebracht ist.

## Die kaskadierte Architektur: Workstation → lokale GPU im Netz → Cloud

Aus dem Routing-Prinzip ergibt sich daraus eine dreistufige Kaskade:

```markdown
Anfrage
│
▼
Sensibler Kontext erkannt? ──ja──▶ lokale GPU im Datacenter (RTX 3090, Qwen2.5-14B o.ä.)
│ nein
▼
Trivial genug für die Workstation? ──ja──▶ Ollama lokal auf dem Laptop
│ nein
▼
Cloud-Modell (Claude, GPT, Gemini, ...)
```

**Stufe 1 - Ollama auf der Workstation.** Autocomplete, kurze Zusammenfassungen, einfache Umformulierungen laufen direkt auf den Rechnern der Mitarbeitenden, ohne dass überhaupt eine Netzwerkanfrage nötig ist. Latenz nahe null, Kosten nahe null.

**Stufe 2 - eine GPU im eigenen Netz.** Alles mit sensiblem Kontext, das mehr Leistung braucht als ein Laptop liefert, geht an eine zentrale GPU im Datacenter oder Homelab, bedient über vLLM oder Ollama im Server-Modus. Diese Stufe ist der eigentliche Kern der Datensouveränität: Sie macht "lokal" praktikabel, ohne dass man gleich einen Cluster braucht. Mit entsprechender Queue ist das auch für Teams mit mehreren gleichzeitigen Nutzern skalierbar.

**Stufe 3 - Cloud.** Alles, was weder sensibel noch trivial ist, geht dorthin, wo die beste verfügbare Modellqualität liegt. Das ist der pragmatische Teil: Man muss nicht jede komplexe Aufgabe lokal lösen wollen, nur weil man kann.

## Was eine RTX 3090 für \~5 Mitarbeitende leistet

Die 24 GB VRAM der RTX 3090 sind der Grund, warum sie in Homelab- und Kleinteam-Setups so oft auftaucht: genug für 8B-Modelle in kaum verlustbehafteter Quantisierung und für 14B-Modelle in Q4, mit noch Luft für Kontext.

| Modell (Quantisierung) | VRAM-Bedarf | Richtwert Durchsatz¹ |
| --- | --- | --- |
| Llama 3.1 8B (Q4_K_M) | \~5 GB | 60-90 Tokens/s |
| Qwen2.5 14B (Q4_K_M) | \~9 GB | 35-45 Tokens/s |
| Qwen2.5 32B (Q4_K_M) | \~19 GB | 15-20 Tokens/s |

¹ Öffentlich kursierende Richtwerte für Einzel-Anfragen, keine eigenen Messungen - für den produktiven Einsatz mit mehreren gleichzeitigen Nutzern vorher selbst benchmarken, insbesondere bei parallelen Requests.

Für ein Team von fünf Leuten, das die GPU nicht dauerhaft sättigt, reicht eine einzelne 3090 für die zweite Stufe der Kaskade in der Regel aus. Wenn es mehr sein soll, ein DGX Spark für wenige tausend Euro. Immer vorausgesetzt, die wirklich rechenintensiven Aufgaben landen ohnehin in Stufe 3. Die Rechnung dahinter, überschlagen: 350 Watt TDP, sagen wir 6 Stunden aktive Last pro Arbeitstag, macht bei 20 Arbeitstagen im Monat rund 42 kWh - bei 30 Cent/kWh knapp 13 Euro Strom. Dazu die Abschreibung der Karte über zwei bis drei Jahre. Das liegt weit unter dem, was fünf Personen an Cloud-API-Kosten verursachen würden, wenn jede sensible Anfrage an ein Frontier-Modell ginge - vor allem, weil Compliance relevante Anfragen tendenziell lang sind (viel Kontext, viele Dokumente) und damit bei tokenbasierter Abrechnung überproportional teuer.

## Grenzen: wann lokale Modelle für den Job einfach zu schwach sind

Der ehrliche Teil dieser Architektur: Ein Qwen2.5-14B in Q4 ist kein Ersatz für ein Frontier-Modell. Bei komplexem Reasoning, langen Dokumenten mit vielen Querverweisen oder Aufgaben, die echtes Weltwissen jenseits der Trainingsdaten brauchen, stößt man schnell an Grenzen. Wem das nicht bewusst ist, der bekommt am Ende schlechtere Ergebnisse und rechtfertigt diese als Datenschutz-Kompromiss - was auf Dauer niemand mitträgt.

Die Lösung ist nicht, die Grenze zu verschieben, sondern eine dritte Option zwischen "lokal, aber schlechter" und "Cloud, aber riskant" einzuziehen: Redaction vor dem hand-off an die Cloud. Namen, Kundennummern und andere Identifikatoren werden vor dem Cloud-Call durch Platzhalter ersetzt und nach der Antwort wieder eingesetzt. Das lokale Modell übernimmt dabei nur die Anonymisierung - eine Aufgabe, für die auch ein kleines Modell gut genug ist -, während die eigentliche, komplexe Aufgabe an ein starkes Cloud-Modell geht, ohne dass Klartext-PII die eigene Infrastruktur verlässt. Das ist mehr Aufwand als reines Routing, aber deutlich weniger als ein eigenes Frontier-Modell zu betreiben.

## Was das für eine Organisation bedeutet

Das Prinzip dahinter ist dasselbe wie bei der [Netzwerksegmentierung meiner IoT-Geräte]({{< ref "network-segregation-iot-not" >}}): Man vertraut nicht blind dem gesamten System, sondern definiert Grenzen, durch die bestimmte Daten schlicht nicht durch können. Und das unabhängig davon, ob eine Anwendung sich später falsch verhält. Bei IoT-Geräten sind das VLANs und Firewall-Regeln. Bei LLM-Anfragen ist es ein Router vor der Inference-API.

Skaliert man das von einem Fünf-Personen-Team auf eine größere Organisation, wird aus dieser technischen Entscheidung schnell eine Governance-Frage: Wer pflegt die Klassifizierungsregeln, wenn sich die Datenkategorien ändern? Wie weist man gegenüber Kunden oder Aufsichtsbehörden nach, dass ein bestimmter Prompt tatsächlich nie die eigene Infrastruktur verlassen hat? Genau dieser Audit-Trail ist der Punkt, an dem "wir nutzen ein lokales Modell" zu einer belastbaren Aussage wird statt zu einer Behauptung. Aus einer Homelab-Lösung mit einer einzelnen GPU wird auf einmal eine Lösung, die man auch einem Wirtschaftsprüfer erklären kann.

[^1]: Verwandte Ansätze, die tiefer in dieselbe Richtung gehen: "Multi-Agent Firewall Architecture for Privacy Protection" und "PrivScope: Task-scoped Disclosure Control for Hybrid Agentic Systems" - beide beschreiben, wie sich Offenlegung von Daten an Cloud-Modelle pro Teilaufgabe statt pro Anfrage steuern lässt.

[^2]: Personal Identifiable information - die maschinelle Erkennung von personenbezogenen- und personenbeziehbaren Daten in Texten.