> **Kern:** Netbits (@NetLightning) recherchierte im OME-Topic „Openclaw mit lokalen Modellen" (23.09.2026) die Datenhaltung bei Cloud-Inferenz — Anlass war unser Tier-0-Modell `deepseek-v4.1-flash` auf Ollama Cloud. Ergebnis: Ollamas Zusagen sind ungewöhnlich stark, aber **vertraglich, nicht technisch** — Ollama verlangt Zero Data Retention von Partnern und weist selbst „model inference providers" als Dritte aus. Zweiter Befund: Prompt-Caching ist ein dokumentierter **Timing-Seitenkanal** — zwei peer-reviewte Arbeiten zeigen Cache-Sharing über Nutzergrenzen hinweg bei mehreren kommerziellen APIs. Der dritte und wichtigste Punkt: Ein Cache ist **kein Trainingsleck, sondern ein Persistenz-Problem** — KV-Tensoren liegen als „data in use" auf fremder GPU-Hardware, und dafür haben weder DSGVO-Auftragsverarbeitung noch CLOUD Act eine Antwort. Prompt- und Policy-Zitate des Posts wurden vollständig verifiziert; **mehrere Angaben des Posts sind falsch oder zu stark** (siehe Korrekturen unten).
Abgerufen direkt von den Primärquellen — Privacy Policy und Pricing-Seite:
| Zusage | Wortlaut (Quelle) |
|--------|-------------------|
| Transiente Verarbeitung | „we process this content **transiently** to provide the Service and this content is not stored beyond the time required to fulfill the request" (Privacy §2) |
| Kein Training | „We do **not** use your inputs or outputs to train any AI models" (Privacy §2); „Prompt or response data is **never logged or trained on**" (Pricing-FAQ) |
| ZDR-Anforderung an Partner | „When Ollama partners with providers, we require **no logging, no training, and zero data retention** policies in place" (Pricing-FAQ) |
| Hosting-Standorte | „primarily in the United States. To serve global demand, we may route to **Europe and Singapore** for additional capacity" (Pricing-FAQ) |
| Partner | „Ollama collaborates with **NVIDIA Cloud Providers (NCPs)** to host open models" (Pricing-FAQ) |
| Dritte (Privacy §5) | „Third parties who help us operate (e.g., Stripe for payments, cloud infrastructure providers, **model inference providers**)" |
| Gewichte | „**Native weights, as released by the model provider**"; Hardware-Formate wie NVFP4 auf Blackwell/Vera Rubin (Pricing-FAQ) |
Der Vergleich mit anderen Anbietern (OpenAI 30 Tage, Anthropic 7 Tage, Google bis 18 Monate), den der Post zieht, ist hier **nicht nachgeprüft** — als Claim des Posts behandelt, nicht als Wiki-Fakt.
## Die Lücke: vertraglich statt technisch
Zwei strukturelle Punkte, die beide durch Ollamas eigene Dokumente gedeckt sind:
1.**Ollama betreibt nicht alle Cloud-Modelle auf eigener Hardware.** Die Privacy Policy nennt „model inference providers" ausdrücklich als dritte Partei, die am Betrieb beteiligt ist. Die ZDR-Zusage ist damit eine **Anforderung an Partner**, die Ollama nicht selbst messt — es gibt (Stand Ingest) keine unabhängige Prüfung.
2.**Ob Datenhaltung greift, hängt am Modell.** Entscheidend ist, welches Modell man fährt und bei welchem Betreiber es landet. Genau diese Frage stellt offenbar auch die Community — siehe GitHub Issue unten.
### GitHub Issue #14279 — offene Frage, nicht Befund
Der Post zitiert [ollama/ollama#14279](https://github.com/ollama/ollama/issues/14279) als „dokumentierte Lücke". Die eigene Prüfung ergibt: Das Issue **existiert** (Titel „Qwen3.5-397B-A17B Cloud data retention and privacy concerns", eröffnet von `asitwere` am **16.02.2026**), ist aber **unbeantwortet** — Label `question`, kein Assignee, kein Milestone, keine Antwort, keine verlinkten PRs. Der Volltext ist eine Rückfrage:
> „It looks like Alibaba is currently the only endpoint available for Qwen3.5, but Ollama's docs/advertising for Ollama Cloud provide data privacy assurances. Since Alibaba retains prompts & responses, can it be confirmed that users are not being routed to Alibaba APIs via Ollama Cloud?"
⚠️ **Korrektur zum Post:** Dokumentiert ist die **Rückfrage**, nicht die Routing-Praxis. Netbits' Formulierung „die Lücke, die dokumentiert ist" ist zu stark. Die zugrunde liegende Beobachtung (Ollama nennt Dritte selbst) bleibt davon unberührt — sie ist durch die Privacy Policy belegt.
### DeepSeek-Verwechslung — die eigentlich gute Nachricht
Die berüchtigte DeepSeek-Datenschutzerklärung (Speicherung in China, Keystroke-Patterns) gilt für **deepseek.com** — die App und die eigene API. Sie gilt **nicht**, wenn ein offenes DeepSeek-Gewichtsmodell bei einem Dritten läuft. `deepseek-v4.1-flash` auf Ollama Cloud ist laut Pricing-FAQ ein **offenes Gewichtsmodell auf NVIDIA-Cloud-Hardware** — nicht die DeepSeek-API. Das ist ein Unterschied, den viele verwechseln, und er ist für unseren Stack der relevanteste Punkt dieses Posts.
## Prompt-Caching als Seitenkanal (zwei peer-reviewte Arbeiten)
Prompt-Caching ist bei uns keine Randerscheinung, sondern Kern der Kostenstrategie — siehe [[../prompt-caching.md]]. Genau deshalb ist dieser Teil relevant.
### Gu et al., ICML 2025 — Audit kommerzieller APIs
[arXiv:2502.07776](https://arxiv.org/abs/2502.07776), „Auditing Prompt Caching in Language Model APIs" — Chenchen Gu, Xiang Lisa Li, Rohith Kuditipudi, Percy Liang, Tatsunori Hashimoto (alle **Stanford University**), ICML 2025. Volltext und Abstract selbst geprüft.
- **8 Provider** mit nachgewiesenem Prompt-Caching.
- **7 davon mit globalem Cache-Sharing über Nutzergrenzen** — Azure, Deep Infra, Fireworks, Lepton, OpenAI (text-embedding-3-small), Perplexity, Replicate. Bei **Anthropic (Claude 3 Haiku)** und **OpenAI (GPT-4o mini)** nur **per-org**, kein globales Sharing.
- **Methode:** statistischer Timing-Audit (einseitiger Kolmogorov-Smirnov-Test) auf Time-to-First-Token von Cache-Hit vs. Cache-Miss.
- **Nebenbefund:** Sie leiteten per Timing ab, dass OpenAIs Embedding-Modell ein decoder-only Transformer ist — vorher nicht öffentlich bekannt.
- **Wirkung:** Nach verantwortungsvoller Offenlegung (60-Tage-Frist) änderten **mindestens fünf Provider** ihre Implementierung, z. B. Abschaltung globalen Cache-Sharings.
- **DeepSeek:** Caching war über Antwortzeiten **nicht** nachweisbar (Tabelle 2). Das Paper stellt fest, dass DeepSeek per-user-Isolation angibt und sie „empirically verified ... based on the number of cache hit tokens returned in the API responses". Die Zuschreibung „DeepSeek ist sauber" stimmt also — beruht aber auf **gemeldeten Cache-Hit-Zählern**, nicht auf Timing-Messung.
- Dokumentiertes per-Organisation-Sharing (OpenAI, Anthropic) wird von den Autoren **nicht** als Sicherheitslücke gewertet.
### Wu et al., NDSS 2025 — PROMPTPEEK
„I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving" — Guanlong Wu, Weili Wang, Jianyu Niu, Yinqian Zhang (**SUSTech**) und Zheng Zhang, Yao Zhang, Ye Wu (**ByteDance**). PDF und NDSS-Seite selbst geprüft.
- **Angriff:** PROMPTPEEK. KV-Cache-Sharing identischer Token-Präfixe in Multi-Tenant-Serving (SGLang, vLLM); Cache-Hits sind über Serving-Reihenfolge bzw. TTFT beobachtbar, der Angreifer ist einfach ein zweiter Tenant.
- **Ergebnisse (Llama-2-13B, A100 80 GB):** **99 %** Erfolgsrate bei Prompt-Input-Rekonstruktion (Reversal Ratio 99 %); **98 %** bei Prompt-**Templates** (91 % Reversal); **95 %** bei Whole-Prompt **ohne Vorwissen** (81 % Reversal).
- **PII-Nachweis:** Aus einem Cloze-Prompt (BMI-Beispiel mit Platzhaltern für Geschlecht, Alter, Gewicht, Größe) ließen sich **alle Platzhalter mit 60 Requests** rekonstruieren — Beispielwerte „male", „35", „90kg", „5 feet 9 inches".
- **Offenlegung/Mitigation:** Die Autoren geben Gespräche mit **SGLang** an; diskutiert werden Obfuskation mit seltenen Tokens, Randomisierung des Longest-Prefix-Matching und das Anfordern von M>1 gemeinsamen Tokens. Lessons Learnt an Provider: KV-Cache-Lebenszyklus modellieren, Cache-Aktivität vor Clients verschleiern, Request-Volumen pro Client kontrollieren.
⚠️ **Korrektur zum Post:** Der Post attribuiert die Arbeit an einer Stelle der „Stanford-Studie". PROMPTPEEK stammt von **SUSTech/ByteDance**; die Stanford-Arbeit ist das ICML-Paper von Gu et al. Beide im Post getrennt genannt, in der Zuordnung aber vermischt.
Netbits' zweiter Teil schärft die Frage an der entscheidenden Stelle — und das ist der konzeptionell wichtigste Beitrag der ganzen Recherche:
> Ein Cache ist **kein** Trainingsdatenleck. Es ist ein *Persistenz*-Thema. Was im Cache liegt, sind **KV-Tensoren** auf fremder GPU-Hardware, für Minuten bis Stunden. Nicht der Rohtext — aber eine mathematische Repräsentation davon, örtlich gebunden an eine bestimmte Maschine in einem bestimmten Rechenzentrum.
Das ist die richtige Trennung. „Wir trainieren nicht auf deinen Daten" und „wir speichern nichts" sind **zwei verschiedene Zusagen** — und die erste sagt nichts über die zweite. Genau hier setzt die von Netbits empfohlene Aufarbeitung an.
### Die Aufarbeitung: Hannecke, „The Hidden Data Residency Problem in Prompt Caching"
Michael Hannecke, Medium, **11.02.2026** ([Artikel](https://medium.com/@michael.hannecke/the-hidden-data-residency-problem-in-prompt-caching-f99e6207451e)). Volltext geprüft (18.815 Zeichen). Die Empfehlung des Posts ist berechtigt — der Artikel ist die präziseste Aufarbeitung der „data in use"-Lücke, die im Wiki vorliegt.
Kernaussagen, verifiziert:
- **Die Lücke:** „Most AI governance frameworks cover data at rest and in transit. Almost none address what happens to your data during inference."
- **Was KV-Tensoren sind:** „a materialization of your prompt content on provider infrastructure. They are not the raw text. But they encode the semantic content of your input. They sit in VRAM on specific GPU nodes in specific datacenters."
- **TTL-Realität:** Default-Cache-Lebensdauern **5 Minuten bis 24 Stunden**. Bei **Google Gemini** (konfigurierbare TTLs) persistent gecachte Tensoren auf **GPU-lokalen SSDs bis zu 24 Stunden** — also nicht nur VRAM.
- **Ungeklärte Details:** Wird Speicher bei TTL-Ablauf sofort genullt oder lazy überschrieben? Wird Cache-Erzeugung/-Eviction geloggt? „Most documentation is silent on this."
### Warum die Rechtssysteme keine Antwort haben
Drei konkrete Lücken, die Hannecke benennt:
| Rahmenwerk / Frage | Stand |
|---|---|
| **DSGVO Art. 17** (Recht auf Löschung) | Kein großer Anbieter bietet (Stand Anfang 2026) eine **Cache-Eviction-API für einzelne Einträge**. Ein Betroffenenantrag lässt sich damit nicht sauber bedienen. |
| **DSGVO Art. 6** (Rechtsgrundlage) | Offene Rechtsfrage: Wenn Anbieter X den Prompt von Nutzer A cacht und Nutzer B einen Cache-Hit auslöst — hat X dann A's Daten „für B" verarbeitet? „This is an open legal question that no provider has addressed publicly." |
| **US CLOUD Act** | Ob ein 5-Minuten-KV-Tensor auf einer GPU in Frankfurt unter „possession, custody, or control" fällt, ist **gerichtlich ungeklärt**. Die konservative Lesart — und die, zu der Juristen greifen — ist **ja**: Wer technisch zugreifen kann, kontrolliert im Sinne des Gesetzes. |
**DPA-Realität:** „Based on a review of publicly available DPAs from major providers, **most do not mention KV-cache residency**. This is not necessarily malicious. It is an oversight born from the fact that prompt caching became standard faster than legal frameworks could adapt."
Der Erfahrungsbericht aus dem Artikel: Bei einer Anbieter-Evaluierung mit einem großen EU-Region-Anbieter kam auf die Frage nach der Cache-Residency nur ein Verweis auf allgemeine Data-Residency-Bedingungen — „No mention of inference-time data. No mention of KV-cache. … **That gap is the norm, not the exception.**"
### Der Datenumfang, der tatsächlich rausgeht
Netbits listet für unseren Fall auf, was bei jedem Turn mitgeht: der komplette System-Prompt (inkl. Memory und User-Profil), der ganze Konversationsverlauf, **jeder Tool-Output** (Dateiinhalte, Logausgaben), Fachinhalte und der Intim-/Rollenspiel-Teil. „Das liegt alles als Klartext bei Ollama auf dem Weg. **Nicht geloggt laut ihrer Politik, aber übertragen.**" Das ist keine neue Enthüllung, sondern die korrekte Beschreibung dessen, was Cloud-Inferenz bedeutet — und der Grund, warum die Persistenzfrage überhaupt relevant ist.
## Mitigationen — was tatsächlich hilft
Die Recherche ergibt vier Wege, in absteigender Härte:
Der Befund, der im Ausgangspost **fehlt**: Für das Kernproblem existiert eine **quelloffene, direkte Mitigation**.
- **vLLM RFC [#16016](https://github.com/vllm-project/vllm/issues/16016)** — „Cache Salting for Secure and Flexible Prefix Caching". Ein optionales Salt pro Request wird in den Block-Hash gemischt. Wer den Salt teilt, kann Prefix-Caching nutzen, **ohne** den Prompt für Fremde cachebar zu machen — Caching bleibt also aktiv, die Cross-User-Wiederverwendung entfällt.
- Das RFC zitiert als Motivation ausdrücklich [arXiv:2411.18191](https://arxiv.org/html/2411.18191v1) („Leaking Secrets from Prefix Caches") und benennt Timing-Seitenkanäle als bekannte Schwäche: „An attacker can infer cache reuse by guessing popular inputs and measuring latency — potentially compromising privacy especially in shared or multi-tenant environments."
- **vLLM und SGLang teilen KV-Caches per Default**; beide unterstützen per-User-/per-Session-Isolation **bei expliziter Konfiguration**.
⚠️ **Selbst-Hosting ist keine automatische Lösung.** Hannecke bringt es präzise: „self-hosting does not eliminate KV-cache risk. **It shifts control.** You still need to configure isolation, monitor cache behavior, and enforce eviction policies. … The risk is the same. The accountability moves to your team." Wer SGLang mit Defaults betreibt, hat exakt das Setup, das PROMPTPEEK ausnutzt.
### 2. Cache-Metriken als Security-Signal lesen
`cache_read_input_tokens` und `cache_creation_input_tokens` sind nicht nur Billing-Werte. Ein **unerwartetes** Hit-Muster — Treffer auf Präfixe, die man selbst nicht kürzlich gesendet hat — ist ein Untersuchungsanlass. Damit wird Cache-Monitoring zum Detektionsmittel, nicht nur zur Kostenanzeige.
### 3. PII-Redaktion vor dem Cloud-Aufruf
**LLM-Redactor** (arXiv:[2604.12064](https://arxiv.org/abs/2604.12064)) — „An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests", Justice Owusu Agyemang, v1 13.04.2026, cs.CR (**Preprint, nicht peer-reviewed**). Open-Source-Shim, kompatibel mit MCP und jeder OpenAI-kompatiblen API.
Acht Techniken evaluiert: local-only inference, Redaktion mit Placeholder-Restoration, semantic rephrasing, TEE-Inferenz, split inference, FHE, MPC-Secret-Sharing, DP-Rauschen — praktisch getestet wurden A/B/C/H über vier Workload-Klassen auf einem Benchmark mit **1.300 Samples / 4.014 Annotationen**.
**Die handlungsleitende Zahl** (im Post nicht genannt): Die Kombination **A+B+C** (lokal routen wo möglich, Rest redigieren und umformulieren) erreicht **0,6 % kombinierter Leak bei PII** und **31,3 % bei Proprietary Code**, bei **null exakten PII-Leaks über 500 Samples**. Heißt: Die lokale Route ist der starke Teil der Kombination — Redaktion/Rephrase allein lassen ein Drittel des Codes durch.
⚠️ Preprint, ein Autor, kein Peer-Review. Die Richtung ist plausibel und deckt sich mit Hanneckes Tiered Approach, die Zahlen sind aber nicht unabhängig bestätigt.
### 4. TEE / Confidential Computing (noch nicht belastbar)
NVIDIA H100/H200 unterstützen Confidential Computing über TEEs. **In der Theorie** die direkte Antwort: Tensoren liegen in verschlüsseltem GPU-Speicher, den selbst der Infrastrukturanbieter nicht lesen kann — womit das CLOUD-Act-Argument technisch entfällt. Praktisch:
> „In practice, this is still emerging. Few inference frameworks fully support TEE-based KV-cache isolation today. Performance overhead remains significant. And the question of whether KV tensors stay inside the enclave boundary during cache operations — or get offloaded to unprotected memory for performance — is an open implementation detail that varies by framework."
Hannecke empfiehlt ausdrücklich: „**verify the implementation before trusting the marketing.**"
⚠️ **Korrektur zum Post:** Netbits stellt TEE als „per Architektur statt per Vertrag" dar und belegt das mit dem Lyceum-Artikel. Das ist zu stark — die vom Post selbst als beste Quelle bezeichnete Aufarbeitung (Hannecke) bewertet TEE als **noch nicht belastbar**. Zudem vermischt der Post zwei verschiedene Dinge: Lyceum beschreibt **flüchtiges VRAM mit LRU-Eviction**, das ist **kein TEE**.
### Lyceum — Herstellerangabe, kein TEE-Beleg
Der [Artikel](https://lyceum.technology/magazine/zero-data-retention-in-llm-inference-how-to) (Abruf 200, 12.616 Zeichen) trägt selbst den Hinweis **„AI This article was created with the help of AI"** und stammt aus dem Firmen-Magazin eines Anbieters — Marketing über das eigene Produkt.
Fachlich korrekt und nützlich ist die **Trennung der Policy-Typen**: Standard API Policy (bis 30 Tage Disk) / No-Training Policy (Training ausgeschlossen, Payloads aber weiter in DBs und Log-Buckets) / Zero Data Retention (nur volatiles GPU-RAM während der Generierung). Der Merksatz: „A common misconception in enterprise procurement is conflating a ‚no training on customer data' clause with zero data retention."
Zur **eigenen** Plattform behauptet der Artikel: Tensoren „held in volatile GPU RAM for a few minutes at most and are scoped to the active session", LRU-Eviction, „never serialized to local NVMe drives, object storage buckets, or external databases". ⚠️ Das ist eine **nicht verifizierbare Herstellerangabe aus einem KI-generierten Werbetext** — im Wiki nur mit dieser Kennzeichnung geführt.
## Anbieter-Vergleich (Sekundärquellen — mit Widerspruch)
Zwei Vergleichsquellen, beide von **Anbietern** (StealthCloud bzw. TheRouter), beide **ohne Ollama**. Damit stützt sich der Befund „Ollamas Cache-Isolation ist unabhängig ungeprüft" auf drei unabhängige Quellen, die Ollama schlicht nicht erwähnen.
**StealthCloud — LLM Provider Privacy Scoreboard** (Donovan Vanderbilt, aktualisiert 18.05.2026; 12 Dimensionen, Basis öffentliche Dokumentation Stand März 2026):
- „No major LLM provider scores above **72 %**." Beste: Anthropic 72 %, Mistral 71 %, Cohere 70 %. OpenAI API **58 %**, Google Gemini API **57 %**, Azure OpenAI **64 %**. Consumer-Tiers deutlich schwächer (ChatGPT Free 47 %, Gemini Consumer 43 %).
- **Retention (API):** Anthropic „30 days (safety), then deleted"; Mistral 30 Tage; OpenAI „30 days (default, configurable to 0)"; Google „Up to 18 months"; Amazon Bedrock „0 days (not stored)"; Azure OpenAI „0-30 days (configurable)".
- Struktureller Befund: „The business model predicts the privacy posture more reliably than any stated commitment." Consumer-Advertising-Modelle (Google, Meta) haben die schwächsten Defaults, Enterprise-API-Anbieter die stärksten.
**TheRouter — Cross-Provider Reference** (Anbieter-Blog, Stand August 2026):
| Anbieter | Default API Retention | Training auf API-Daten | ZDR verfügbar |
|---|---|---|---|
| OpenAI | 30 Tage | Nein | Ja (Org-Level opt-in) |
⚠️ **Widerspruch, nicht auflösbar:** Anthropic wird von TheRouter und vom Ausgangspost mit **7 Tagen** angegeben, von StealthCloud mit **30 Tagen (Safety)**. Beide Quellen sind Anbieter-Blogs, keine Primärdokumentation. Die Zahl gehört damit nicht als Fakt ins Wiki — der Vergleich mit „OpenAI 30 / Anthropic 7 / Google 18 Monate" im Post ist **auf einer wackligen Zeile gebaut**, auch wenn die Größenordnung stimmt.
⚠️ **Zusätzlicher Caveat zum Post:** Netbits nennt diese Zahlen „stärker als OpenAI, Anthropic oder Google" und markiert sie nicht als Sekundärangaben. Nur Ollamas eigene Werte hat er an der Primärquelle geprüft — die Vergleichszahlen stammen aus Anbieter-Zusammenstellungen.
Netbits' Check behauptet, der Gateway habe **genau eine** ausgehende Verbindung (`192.168.100.4 → 76.76.21.123:443`) und die IP gehöre **Amazon** (Walnut, CA) und sei ollama.com. Eigene Prüfung aus dem Hector-Container (2026-09-23):
| Behauptung | Prüfergebnis |
|---|---|
| `192.168.100.4` = „deine Maschine" | **Nicht dieser Container.** Er hat 172.20.0.10, 172.21.0.8, 100.80.221.60 — `192.168.100.4` ist eine LAN-Adresse außerhalb. |
| `76.76.21.123` gehört Amazon | **Falsch.** ARIN-RDAP für `76.76.21.0/24`: Handle `NET-76-76-21-0-1`, Netname **`VERCEL-01`**, Registrant **Vercel, Inc** (Walnut, CA). Kein PTR. |
| Die IP ist ollama.com | **Nicht bestätigt.** Auflösung von hier: `ollama.com → 34.36.133.15` (ARIN `GOOGL-2`, Google Cloud); `api.ollama.com` und `registry.ollama.ai` über **Cloudflare**; `ollama.com` antwortet mit `server: Google Frontend`. |
| „genau eine Verbindung, ein einziger Anbieter" | Nicht reproduzierbar; laut Ollama-Pricing ist Routing nach **Europa und Singapur** möglich — „ein Anbieter" wäre ohnehin nur eine Momentaufnahme. |
Der **methodische** Wert des Checks bleibt: Die Frage „welche Endpunkte spricht mein Agent tatsächlich an" ist sinnvoll und nachprüfbar. Die konkrete Zuordnung ist fehlerhaft.
## Konsequenzen für unseren Stack
- **Was wir wissen:** Unser Tier-0-Modell läuft als **offenes Gewichtsmodell** über Ollama Cloud auf NVIDIA-Cloud-Providern — nicht über die DeepSeek-API. Die datenschutzpolitisch problematische DeepSeek-Erklärung greift damit nicht.
- **Was wir nicht wissen:** ob die ZDR-Anforderung bei jedem Partner und für jedes Modell tatsächlich eingehalten wird. Ollamas Cache-Isolation (und die jedes anderen Anbieters außerhalb des Stanford-Audits) ist **nicht unabhängig getestet**. Das ist eine offene Frage, keine Warnung.
- **Prompt-Caching:** Wir nutzen es stark (Kostenhebel, siehe [[../prompt-caching.md]]). Der Seitenkanal-Risikofaktor ist **Cache-Sharing über Nutzergrenzen**. Per-User- bzw. per-Org-Isolation entschärft ihn; globales Sharing ist der problematische Fall. Für die eigenen Inhalte gilt: Was nicht in einen fremden Cache soll, gehört nicht in einen geteilten Präfix über einen Multi-Tenant-Dienst — oder auf lokale Hardware ([[../hardware/cloud-exit-and-local-superiority.md]], [[../../tools/ollama-cloud-deepseek-v4-flash-200tps-zdr.md]]).
- **Kein-Training ≠ Kein-Speichern:** Die beiden Zusagen sind unabhängig. Ollama gibt beide, was den Fall günstig macht — aber wer nur die Trainingszusage hat, hat zum Retention-Thema nichts gesagt.
- **Vertraglich vor technisch:** Der saubere Weg für sensible Workloads ist die **schriftliche** ZDR- und Cache-Isolationszusage im Enterprise-Vertrag. Ollama hat solche Verträge; die Policy-Zusage allein ist eine Behauptung, keine Audit-Tatsache.
- **Handlungsfähig heute:** Für sensible Inhalte auf lokale Modelle routen; PII vor Cloud-Aufrufen redigieren; Cache-Isolation dort konfigurieren, wo wir sie kontrollieren (vLLM/SGLang `cache_salt` statt Default-Sharing); Cache-Hit-Muster als Security-Signal beobachten.
- **Was wir bewusst nicht tun:** Wir bauen keine eigenen Enklaven und behandeln TEE nicht als gelöstes Problem. Der Stand ist „noch nicht belastbar" — siehe oben.
- TheRouter (Anbieter-Blog): [Cross-Provider Retention Reference](https://therouter.ai/blog/llm-api-privacy-data-retention-cross-provider-reference) — kein Ollama; Anthropic-Widerspruch
- Raw (Post Teil 1+2 + Verifikationsprotokoll): [raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md](../../../raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md)
