belegbar.eu

Fall 2026-006 · bestätigt · eröffnet 05.10.2026 · Anbieter: T-Systems / Open Telekom Cloud (AI Foundation Services)

T-Systems LLM Hub: „never saved“ und „Not stored“ — und in der eigenen Leistungsbeschreibung: Zwischenspeicher standardmäßig eingeschaltet

Kurz: Die Trust-Seite des LLM Hub sagt ohne Einschränkung, dass Prompts und Antworten bei den von der Telekom betriebenen Modellen nie gespeichert werden, und fasst das in der Tabelle mit „Storage: Not stored“ zusammen. Dieselbe Seite nennt die Leistungsbeschreibung v1.23 die verbindliche Quelle. Dort steht in Abschnitt 2.3.1: Bereits verarbeitete Anfragen werden für eine begrenzte Zeit zwischengespeichert, und diese Funktion ist standardmäßig eingeschaltet. Die Prefix-Caching-Doku sagt dasselbe. Auf der Trust-Seite kommt der Zwischenspeicher nur als Navigationslink vor.

Die Behauptung

„Regardless of which model you select hosted by Telekom, customer prompts and responses are never saved or used to train or fine-tune any model.“
Trust-Seite „Enterprise Trust“ des LLM Hub (ohne Datumsangabe), Abschnitt „No training on customer data“. Der Satz gilt für alle von der Telekom betriebenen Modelle (Category 1), ohne Hinweis auf eine Zwischenspeicherung. docs.llmhub.t-systems.net/reference/enterprise-trust/, abgerufen 2026-10-03 20:05:22 UTC · Archivkopie
SHA-256 der abgerufenen Seite: df454e984a56197ac19e8b40e0279d1c3cacc967a05f7d0a1b13286d71aed83c
„Customer prompts and returned results are not stored and not viewable by Telekom or third parties“
Dieselbe Seite, Beschreibung von Category 1 (Verarbeitung in EU/EWR bzw. Staaten mit Angemessenheitsbeschluss). In der Tabelle „Data Handling Summary“ steht für Category 1 in der Zeile „Storage“: „Not stored“. Dieselbe Seite: „the Service Description (PDF) (v1.23) is the binding source.“ docs.llmhub.t-systems.net/reference/enterprise-trust/, abgerufen 2026-10-03 20:05:22 UTC · Archivkopie
SHA-256 der abgerufenen Seite: df454e984a56197ac19e8b40e0279d1c3cacc967a05f7d0a1b13286d71aed83c

Der Beleg

„Ihre Anfragen und die darauf erhaltenen Antworten werden im LLM Serving Service standardmäßig nicht dauerhaft gespeichert und auch nicht dazu verwendet, die Sprachmodelle zu trainieren. Damit der Service schneller antwortet, gibt es eine sogenannte Cache-Funktion: Dabei werden bereits verarbeitete Anfragen für eine begrenzte Zeit zwischengespeichert, sodass ähnliche oder wiederkehrende Anfragen schneller beantwortet werden können. Diese Funktion ist standardmäßig eingeschaltet, kann von Kunden aber jederzeit ein- oder ausgeschaltet werden.“
Leistungsbeschreibung & zusätzliche Bedingungen – LLM-Serving-Service, Version 1.23, Stand 31.08.2026, § 2.3.1 (Kategorie „innerhalb EU/EWR und Staaten mit Angemessenheitsbeschluss“, also genau die Modelle, für die die Trust-Seite „Not stored“ sagt). Die Trust-Seite nennt dieses Dokument selbst „the binding source“. Die Wayback-Kopie vom 24.09.2026 ist byte-gleich zum Abruf am 03.10.2026 (gleicher SHA-256). docs.llmhub.t-systems.net/files/Leistungsbeschreibung-LLM-Serving-Service.pdf, abgerufen 2026-10-03 20:05:24 UTC · Archivkopie
SHA-256 der abgerufenen Seite: 5c4292adf3927ac2950082c3649253adb606c6b8295c82c8198cb4a9dcf5a761
„If a prompt should not be retained for reuse at all — a one-off, or content you do not want held even briefly — send save_cache: false on that request and nothing from it is stored.“
Doku „Prefix Caching“ des LLM Hub, Überschrift „Caching is on by default on T-Cloud-hosted models“; ebenda: „Caching keeps already-processed requests for a limited time“. Die eigene Doku beschreibt den Zwischenspeicher also mit „retained“, „held“ und „stored“. docs.llmhub.t-systems.net/guides/prefix-caching/, abgerufen 2026-10-03 20:05:23 UTC · Archivkopie
SHA-256 der abgerufenen Seite: 681e82f22c7c63be6633f12650a1d52b660f31fc18327bd54299051611212dc0

Worin der Widerspruch besteht

Die Trust-Seite sagt ohne Vorbehalt „never saved“ und „not stored“ und fasst es in der Tabelle mit „Storage: Not stored“ zusammen. Die Leistungsbeschreibung, die dieselbe Seite als verbindlich bezeichnet, beschreibt für dieselben Modelle eine Cache-Funktion, die verarbeitete Anfragen für eine begrenzte Zeit zwischenspeichert und standardmäßig eingeschaltet ist. Die Prefix-Caching-Doku nennt das „retained“ und „stored“ und sagt, erst mit save_cache: false werde nichts gespeichert. Wer die Trust-Seite liest, etwa ein Datenschutzbeauftragter, der den Dienst für eine Behörde prüft, erfährt nicht, dass im Standard etwas zwischengespeichert wird. Beide Aussagen können nur zugleich gelten, wenn „saved“ und „stored“ auf der Trust-Seite allein dauerhafte Speicherung meinen.

Was dieser Fall nicht heißt

Dies ist kein Vorwurf der Täuschung. Telekom dokumentiert den Zwischenspeicher offen, und zwar im verbindlichen Dokument und in einer eigenen Doku-Seite. Laut Doku handelt es sich um einen Prefix-Cache, der Anfragen schneller macht, nur für begrenzte Zeit gilt und pro Anfrage oder vom Kunden insgesamt abgeschaltet werden kann. Dass Prompts und Antworten nicht dauerhaft gespeichert und nicht zum Training verwendet werden, wird nicht bestritten. Nicht geprüft ist, wie lange der Cache genau hält und ob Telekom-Mitarbeiter auf ihn zugreifen können. Der Fall betrifft nur die absolute Formulierung der Trust-Seite, die den Zwischenspeicher nicht erwähnt.

Was den Fall ausräumt

  1. Telekom ergänzt die Trust-Seite um den Zwischenspeicher (z. B. „not stored permanently; a short-lived prefix cache is on by default and can be disabled“) und passt die Tabelle an. Dann ist der Widerspruch ausgeräumt.
  2. Telekom schaltet den Cache standardmäßig aus und passt § 2.3.1 der Leistungsbeschreibung an. Dann stimmt „Not stored“ für den Standard, und der Widerspruch ist ausgeräumt.
  3. Telekom legt dar, warum beide Darstellungen zugleich zutreffen (etwa weil ein Prefix-Cache technisch keine Speicherung der Anfrage sei). Wir veröffentlichen die Erklärung wörtlich und prüfen sie gegen die eigene Doku.

Antwort des Anbieters

Noch keine Antwort. Der Anbieter wurde am 07.10.2026 informiert; Antwortfrist bis 21.10.2026. Jede Antwort wird hier wörtlich und ungekürzt veröffentlicht.

Verlauf

06.09.2026Beim Widerspruchs-Scan als Kandidat 3 in der internen Kandidatenliste notiert (Trust-Seite gegen Leistungsbeschreibung und Prefix-Caching-Doku).
03.10.2026Trust-Seite, Prefix-Caching-Doku und Leistungsbeschreibung v1.23 im Internet Archive gesichert, jedes Zitat wörtlich in der Archivkopie geprüft (19:56–20:05 UTC).
03.10.2026Alle drei Quellen neu abgerufen (20:05 UTC), Inhalte per SHA-256 gesichert, alle Zitate wörtlich in den Rohkopien geprüft; die Leistungsbeschreibung ist weiter v1.23 vom 31.08.2026. Fall als Entwurf vorbereitet, noch nicht veröffentlicht, Anbieter noch nicht informiert.
04.10.2026Alle drei Quellen erneut abgerufen (15:51 UTC), byte-gleich zum Abruf vom 03.10.2026 (gleiche SHA-256). Anschreiben an den Anbieter als Entwurf vorbereitet, noch nicht gesendet.
05.10.2026Alle drei Quellen am Versandtag erneut abgerufen (14:48 UTC), byte-gleich zum Abruf vom 03.10.2026 (gleiche SHA-256). Anbieter per E-Mail (ai@t-systems.com, 13:10 UTC, von hallo@belegbar.eu) mit dem vollständigen Text des Falls informiert. Antwortfrist bis 20.10.2026.
06.10.2026Alle drei Quellen erneut abgerufen (16:12 UTC); alle drei Dateien unterscheiden sich vom Abruf vom 03.10.2026. Die Leistungsbeschreibung ist jetzt Version 1.24, Stand 30.09.2026; § 2.3.1 steht wörtlich unverändert, die Cache-Funktion ist weiter standardmäßig eingeschaltet. Die Trust-Seite enthält beide zitierten Sätze und „Not stored“ unverändert und nennt weiter v1.23 als verbindliche Quelle. Die Prefix-Caching-Doku enthält das zitierte Satzstück unverändert. Die Wayback-Aufnahme 20261006161218 der Leistungsbeschreibung ist byte-gleich zu unserer Kopie. Rohkopien: belege/faelle/2026-006/*-2026-10-06.* (SHA-256 in SHA256SUMS). Der Stand 30.09.2026 liegt vor unserer E-Mail vom 05.10.; ob die Änderung mit dem Fall zusammenhängt, ist ungeklärt. Am selben Tag (13:41 UTC) meldete Gmail, dass unsere E-Mail vom 05.10. an ai@t-systems.com noch nicht zugestellt ist: Der Mailserver der Telekom lehnt sie vorübergehend ab („554 … poor reputation of a domain used in message transfer“, Status 4.7.1); Gmail versucht die Zustellung bis 08.10.2026 15:10 UTC weiter. Ob der Anbieter den Fall erhalten hat, ist damit ungeklärt.
07.10.2026Anbieter erneut per E-Mail informiert (ai@t-systems.com, 14:37 UTC, von felix.h.lind@gmail.com), mit dem vollständigen Text des Falls und dem Hinweis, dass die E-Mail vom 05.10. nicht angenommen wurde. Antwortfrist bis 21.10.2026.
08.10.2026Bis 15:16 UTC, gut 24 Stunden nach dem Versand, keine Verzögerungs- oder Fehlermeldung zur E-Mail vom 07.10.; beim ersten Versand kam die erste Verzögerungsmeldung nach rund 24,5 Stunden. Die Zustellung gilt damit als belegt, eine Lesebestätigung gibt es nicht. Die E-Mail vom 05.10. (von hallo@belegbar.eu) hat Gmail am 08.10.2026 endgültig als nicht zustellbar gemeldet.
14.10.2026Alle drei Quellen erneut abgerufen. Die Leistungsbeschreibung ist unverändert Version 1.24, § 2.3.1 wörtlich gleich. Die Trust-Seite nennt die Leistungsbeschreibung weiter „the binding source“, aber ohne Versionsnummer (vorher „(v1.23)“); beide zitierten Sätze und „Storage: Not stored“ stehen unverändert. Die Prefix-Caching-Doku enthält das zitierte Satzstück unverändert. Rohkopien belege/faelle/2026-006/*-2026-10-14.html, SHA-256 in SHA256SUMS.
15.10.2026Halbzeit-Erinnerung an den Anbieter gesendet (14:31 UTC, im Thread der Mail vom 07.10., von felix.h.lind@gmail.com an ai@t-systems.com). Inhalt: Frist 21.10.2026 bleibt, danach Status „bestätigt“, der Fall bleibt für eine Antwort offen.
21.10.2026Prüfung nach Ablauf der Antwortfrist (21.10.2026). Keine Antwort des Anbieters eingegangen, auch nicht auf die Halbzeit-Erinnerung vom 15.10. (Postfach geprüft 21.10.2026 22:55 UTC). Alle drei Quellen erneut abgerufen (22:56 UTC): Die Leistungsbeschreibung ist byte-gleich zum Abruf vom 06.10.2026 (Version 1.24, § 2.3.1 unverändert, Cache-Funktion standardmäßig eingeschaltet). Die Trust-Seite enthält beide zitierten Sätze und „Storage: Not stored“ unverändert und erwähnt den Zwischenspeicher weiter nur als Navigationslink; neu sind nur Menüpunkte und ein Werbebanner. Die Prefix-Caching-Doku enthält das zitierte Satzstück unverändert. Rohkopien belege/faelle/2026-006/*-2026-10-22.*, SHA-256 in SHA256SUMS (Trust-Seite 9ca26b80d34b46d63064bec646f9e51f15f4ec4a090a036585b9aec1aa2b9c29). Snapshot: https://web.archive.org/web/20261021225741/https://docs.llmhub.t-systems.net/reference/enterprise-trust/ (byte-gleich zu unserer Kopie). Status auf „bestätigt“ gesetzt: Frist verstrichen, keine Antwort, beide Aussagen unverändert. Eine spätere Antwort wird wörtlich eingetragen; sobald eine der Auflösungen eintritt, geht der Fall auf „ausgeräumt“.

Status bestätigt: Frist verstrichen oder Antwort räumt den Widerspruch nicht aus. Ein Fall wird nie gelöscht. Auch ein ausgeräumter Fall bleibt mit seinem Verlauf stehen. Was ein Fall ist und was nicht: Methodik.

Sie arbeiten bei T-Systems / Open Telekom Cloud (AI Foundation Services)? Antworten Sie an hallo@belegbar.eu. Ihre Antwort erscheint wörtlich auf dieser Seite. Was Sie sonst tun können: Für Anbieter.