hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
knowledge-base/wiki/concepts/policy/inference-provider-data-retention.md

27 KiB
Raw Blame History

created updated sources tags
2026-09-23 2026-09-23
other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md
concept
policy
privacy
data-retention
zdr
cloud-inference
ollama
prompt-caching
kv-cache
side-channel
deepseek
third-party-routing
data-in-use
gdpr
cloud-act
tee
confidential-computing
vllm
dpa

Datenhaltung & Cache-Seitenkanäle bei Cloud-Inferenz

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).

Was Ollama zusagt (verifiziert am 2026-09-23)

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 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, „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.

  • 17 API-Provider auditiert (Anthropic, Amazon Bedrock, Azure OpenAI, Cohere, Deep Infra, DeepSeek, Fireworks, Google, Groq, Hyperbolic, Lepton, Mistral, OctoAI, OpenAI, Perplexity, Replicate, Together).
  • 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.
  • Drei Szenarien: Whole Prompt Reconstruction, Input Reconstruction, Template Reconstruction.
  • 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.

Data in use: der Persistenz-Blickwinkel

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). 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:

1. Cache-Isolation konfigurieren (der praktikabelste Hebel)

Der Befund, der im Ausgangspost fehlt: Für das Kernproblem existiert eine quelloffene, direkte Mitigation.

  • vLLM RFC #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 („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) — „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 (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)
Anthropic 7 Tage Nein Ja (Enterprise-Vertrag)
Google (Gemini API) je nach Plan Nein (bezahlte Pläne) Ja (bezahlte Pläne)
DeepSeek nicht veröffentlicht nicht ausdrücklich zugesichert Nein
DashScope (Alibaba) nicht veröffentlicht Nein (ausdrückliche Zusage) nicht dokumentiert

⚠️ 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.

Netzwerk-Faktencheck — nicht reproduzierbar

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.

Verwandte Seiten

Quellen