Ephemere KI als Standard: Aufbewahrung, Löschung und Legal Holds

Wenn Apple demnächst Siri‑Chats automatisch löscht, kann Ihr Produkt nicht das unheimliche sein, das Prompts auf ewig hortet. Enterprise‑Käufer verlangen bereits Steuerungen für die Aufbewahrung von KI‑Daten, und Aufsichtsbehörden schauen hin. Das ist kein PR‑Thema; das ist Mindestvoraussetzung. Bauen Sie KI standardmäßig ephemer – oder stellen Sie sich auf deal‑tötende Fragebögen, punitive Discovery‑Kosten und die ständige Angst ein, dass irgendein vergessener Log‑Bucket ein Jahr an User‑Prompts enthält.

Warum das vom „Nice to have“ zur Vorstandsfrage wurde

Drei Signale sind dieses Jahr zusammengekommen:

• Kundenerwartungen: Große Assistenten stellen Berichten zufolge standardmäßig auf automatisch gelöschte Chats um. Wenn die größten Consumer‑Marken ephemer gehen, wird Ihr Enterprise‑SaaS an diesem Maßstab gemessen.
• Institutionelle rote Linien: arXiv hat Sperren für Autorinnen und Autoren angekündigt, die KI die ganze Arbeit machen lassen. Unabhängig von Ihrer Branche ist das ein Warnschuss: Institutionen werden KI‑Missbrauch sanktionieren und Nachweise für Kontrolle verlangen.
• Beschaffungsrealität: Fortune‑100‑Unternehmen fügen Sicherheitsprüfungen inzwischen mehrseitige Zusatzvereinbarungen zur KI‑Datenhandhabung bei. Wenn Sie Prompts unbegrenzt speichern, ziehen sich Rechts‑ und Sales‑Zyklen – oder scheitern.

Und der Clou: Die meisten Startups behalten deutlich mehr KI‑Daten, als nötig. In unseren Prüfungen werden 80–90% der Prompt‑/Trace‑Logs nach 7 Tagen nie wieder angesehen. Gleichzeitig vergrößert dieser Datenabfall den Schadensradius bei einem Breach, bläht Vektorindizes auf und fesselt Ihnen in der Discovery die Hände.

Ein Entscheidungsrahmen für CTOs für standardmäßig ephemere KI

Beginnen Sie nicht mit Tools. Beginnen Sie mit Datenklassen, Aufbewahrungszielen und Löschgarantien. Dann leiten Sie daraus die Architektur ab.

1) KI‑Daten in fünf Klassen einteilen

• P0 Vertraulich/PII: Benutzerkennungen, Kontometadaten, Dateien und jeglicher Prompt‑Inhalt, der PII oder Secrets enthalten könnte.
• P1 Prompts/Responses: Chat‑Transkripte, Funktionsaufruf‑Argumente, Tool‑Outputs, Zwischennotizen von Agents.
• P2 Telemetry/Traces: Token‑Zählungen, Latenzen, Modellversionen, Stichproben von Prompts mit automatischer Schwärzung fürs Tuning.
• P3 Abgeleitete Indizes/Caches: Embeddings, Vektorindizes, Re‑Rank‑Caches, Retrieval‑Logs, Prompt‑Templates.
• P4 Artefakte: Outputs, die zu Produktdaten werden (Tickets, Code‑Änderungen, Knowledge‑Artikel).

2) Standard‑Aufbewahrungsfristen festlegen

• P0: 0 Tage in Logs; nur dort speichern, wo es als Produktdaten absolut erforderlich ist, verschlüsselt im Ruhezustand und unter ausdrücklicher Nutzerzustimmung/-Policy.
• P1: 0–7 Tage Ringpuffer fürs Debugging; standardmäßig aus, pro Mandant Opt‑in. Bieten Sie Admin‑Policies mit 0/7/30/365 Tagen.
• P2: 7–14 Tage; aggregierte Metriken länger (90 Tage), sofern sie inhaltsfrei sind.
• P3: 30 Tage oder weniger mit automatischer Invalidierung; niemals Roh‑Prompts in Indizes speichern; nur Dokument‑IDs und Hashes speichern.
• P4: Folgt der Datenpolicy Ihres Produkts; außerhalb der KI‑Policy, muss aber klar getrennt von P1/P2‑Daten sein.

Das sind Defaults. Regulierte Mandanten (Healthcare, Finance, öffentlicher Sektor in LATAM) werden 0‑Tage‑Erfassung für P1/P2 und mandantenverwaltete Schlüssel verlangen. Sorgen Sie dafür, dass 0‑Tage wirklich funktioniert.

3) Löschungen über alle Stores garantieren

Löschung bedeutet jede Replik und jedes Derivat: OLTP‑DB, Queues, Vektordatenbank, Objektspeicher, Analytics, APM, Volltextsuche und Drittanbieter. Zusagen: ein SLA: P99‑Löschung unter 24 Stunden. Als KPI tracken.

Architektur: So setzen Sie das um, ohne Observability zu verlieren

Hier ist ein Referenzdesign, das wir für KI‑lastige SaaS implementiert haben. Es erhält Debugging und Produktqualität, ohne Nutzertext auf Vorrat zu lagern.

1) Sitzungsgebundener Konversationszustand

• Kontext im Speicher oder in einem schnellen Store (Redis/Memgraph) mit TTL ≤ 24 h halten. Dauerhafte Chat‑Speicherung deaktivieren, es sei denn, ein Mandant aktiviert „Chats behalten“.
• Nutzern einen In‑Product‑Schalter geben: „Diesen Chat behalten“ schreibt in dauerhaften Speicher; Default ist flüchtig.
• Benutzer‑IDs zu pseudonymen Sitzungs‑IDs für die KI‑Pipelines tokenisieren; nur am Rand bei Bedarf wieder den Accounts zuordnen.

2) Prompt‑Logging ohne Haftungsrisiko

• Prompts zu 1–5% für Quality‑Tuning samplen, nachdem beim Ingest automatisiert geschwärzt wurde (Namen, E‑Mails, Keys, Zahlen). Geschichtete Detektoren nutzen (Pattern + ML). Tools wie Presidio sind ein pragmatischer Start.
• Text durch strukturierte Zusammenfassungen ersetzen, wo möglich: Intent‑Tags, aufgerufene Tool‑Namen, Token‑Zählungen. Diese 90 Tage speichern.
• Admins eine Zero‑Prompt‑Retention‑Policy anbieten, die nur aggregierte Metriken behält. Ihr Debug‑Fallback ist ein vom Nutzer ausgelöster „Für Support freigeben“‑Bundle, der auf dem Gerät schwärzt und nach 7 Tagen abläuft.

3) Vektordatenbanken und Caches mit echter TTL

• Niemals Roh‑Prompt‑Inhalte in Vektorindizes speichern. Embeddings + Payload stabiler IDs/Hashes speichern, nicht den Text.
• Pro Punkt eine TTL anhängen oder einen Lösch‑Index nach Dokument/Version führen. Die meisten Vector Stores unterstützen TTL nicht nativ; tägliche Sweeps einplanen, um abgelaufene Punkte zu entfernen.
• Wenn ein Nutzer ein Quelldokument löscht, kaskadierend invalidieren: Seine Chunks sofort aus dem Vektorspeicher, allen Re‑Rank‑Caches und Retrieval‑Logs entfernen.

4) Dateien/Objekte langweilig, aber korrekt handhaben

• Dedizierte Buckets für KI‑Artefakte mit Bucket‑Lifecycle‑Regeln (7–30 Tage) nutzen. Strikt getrennt von Produkt‑Attachments halten.
• KI‑Artefakte ausschließlich über kurzlebige pre‑signed URLs (≤ 60 Minuten) ausliefern.
• Verschlüsselung im Ruhezustand mit mandantenspezifischen Schlüsseln. Wenn Sie BYOK anbieten, mit KMS/HSM integrieren und die Schlüsselverwendung im Audit‑Trail protokollieren.

5) Isolierung gegenüber Modellanbietern

• Provider‑seitiges Training wo immer möglich abwählen. Die meisten großen APIs erlauben ein „do not train“‑Flag; pro Call verifizieren in Code‑Reviews.
• Bei On‑Prem‑ oder VPC‑Modellen Token‑Logs von Prompts trennen. Zählungen und Latenzen behalten; Rohtext standardmäßig verwerfen.

6) Agent‑/Tool‑Traces ohne Geheimnis‑Leakage

• Tool‑Inputs/Outputs an der Grenze säubern. Tool‑Logs wie P1 behandeln.
• Ausführungsbäume statt Volltext für 14 Tage behalten: welche Tools liefen, mit welchen Datenkategorien, Dauer, Erfolg/Fehlschlag.
• Für Sev‑1‑Vorfälle temporäre Trace‑Eskalation erlauben: Für die nächsten N Requests den Volltext im dedizierten Store des Mandanten mit expliziter Freigabe erfassen, dann automatisch ablaufen lassen.

7) Analytics ohne Content‑Hortung

• Früh aggregieren: Intent‑ und Qualitätsmetriken beim Ingest berechnen; nur aggregierte Zähler an Analytics senden (keine Prompts).
• Einfache Differential Privacy auf Mandanten‑Dashboards mit kleinen Zählwerten anwenden. Das erschwert Re‑Identifikation ohne heroische Mathematik.

8) Lösch‑Orchestrierung als First‑Class‑System

• Eine maschinenlesbare Datenkarte pflegen (YAML reicht), die jeden Store, der P1–P3 halten kann, mit seiner Löschmethode auflistet.
• Einen Lösch‑DAG bauen: Wenn ein Mandant oder Nutzer eine Löschung anfordert, Jobs zu OLTP, Vektordatenbank, Objektspeicher, APM, Analytics, Volltextsuche und Providern auffächern.
• Idempotent machen mit Lösch‑Tokens und Retries. Ein signiertes Audit‑Event emittieren, wenn jeder Ast abgeschlossen ist. Ziel: P99 < 24 h, P50 < 1 h.

Produktkontrollen, die Enterprises heute erwarten

• Mandantenweite Retention‑Policy für KI‑Daten: 0/7/30/365 Tage mit einem Default von 0 oder 7.
• Legal Hold: Ein Admin‑Schalter, der Löschungen für definierte Nutzer/Datenklassen einfriert. Kritisch: Er sollte TTL‑Evictions in jedem Store stoppen, inklusive Vektordatenbanken und Objektspeicher.
• Datenexport für P1: ein maschinenlesbares Archiv der verbliebenen Chats (falls Retention aktiviert ist) und ein Audit‑Log der Löschungen.
• Region‑Pinning: P1–P3 in‑Region halten; keine Cross‑Region‑Replikation ohne vertragliche Regelung.
• BYOK oder zumindest mandantenspezifische Schlüssel mit Rotation. Wenn Sie an Finance/Healthcare verkaufen, taucht BYOK im ersten Call auf.

Was das kostet – und was es spart

Zur Einordnung mit Zahlen für ein SaaS im Mid‑Stage mit 10k Daily Active Users, je 10 Prompts/Tag, im Schnitt 600 Tokens rein/raus:

• Rohtext von Prompts/Responses: ~100 MB/Tag. Triviale Speicherkosten auf S3 ($0,023/GB‑Monat), aber nicht triviales Breach‑Risiko.
• Traces: 1–2 GB/Tag, wenn Sie vollständige Agent‑Logs behalten. Bei 30‑Tage‑Retention liegen Sie bei 30–60 GB – wieder: billige Dollars, teures Risiko.
• Embeddings: 100 Mio. Tokens/Tag naiv zu embedden, ist ruinös. Caching und Deduplizierung über Hashes reduzieren das typischerweise um 70–90%. TTL bremst das Long‑Tail‑Wachstum zusätzlich.

Engineering‑Zeit ist der eigentliche Kostenfaktor: Eine Staff‑Ingenieurin/ein Staff‑Ingenieur für 6–8 Wochen kann den Kern dieser Architektur in einer sauber strukturierten Codebasis implementieren; zwei, wenn Ihre Datenkarte unübersichtlich ist. Der Upside ist unmittelbar:

• Weniger Reibung in Security‑Reviews; wir haben Enterprise‑Zyklen um 2–4 Wochen schrumpfen sehen, wenn Teams echte Retention‑Kontrollen demonstrieren können.
• Schadensradius bei Breaches ist um Größenordnungen kleiner. 7 Tage geschwärzter Samples zu verlieren, ist besser als ein Jahr Prompts.
• Debugging‑Disziplin verbessert sich: Teams hören auf, Log‑Archäologie zu betreiben, und ergänzen bessere Intent‑Level‑Metriken.

Häufige Fehlermuster (und wie man sie vermeidet)

• „Ghost Logs“: Sie haben P1 in OLTP gelöscht, aber APM und Volltextsuche vergessen. Beheben mit dem Lösch‑DAG und einer vierteljährlichen Tabletop‑Übung, die End‑to‑End‑Löschung belegt.
• Vector‑Store‑Amnesie: Keine TTL, kein Lösch‑Index, kein Versioning. Beheben, indem Punkte nach Doc+Version geschlüsselt werden und nächtliche Evictions laufen.
• Provider‑Drift: Jemand hat bei einem Library‑Upgrade Training eingeschaltet. Beheben mit statischer Analyse oder CI‑Checks für Provider‑Flags und einer Runtime‑Control‑Plane, die Org‑Level‑Defaults durchsetzt.
• PII in Prompts schlüpft an der Schwärzung vorbei. Beheben mit Defense‑in‑Depth: Patterns, gelernten Detektoren, Allowlists/Denylists pro Mandant und Schwärzung im Client für hochriskante Felder.
• Support‑Tickets mit Roh‑Chats: Ihr „Mit Support teilen“‑Flow kippt alles für immer in Zendesk. Beheben, indem Sie ablaufende Bundles mit 7‑Tage‑TTL und Zugriffslogs senden.

Governance, die sich wirklich betreiben lässt

• KPIs: % der Stores mit TTL; P50/P99‑Löschzeiten; % der gespeicherten Prompts; % Schwärzungs‑Abdeckung; # Mandanten auf 0‑Tage‑Policies; # Legal Holds; Abdeckung der Datenkarte (aufgeführte Stores vs. gesamt).
• Reviews: Vierteljährlicher „Privacy Burn‑Down“, bei dem Sie 10 zufällige Nutzer löschen und die Löschung über alle Stores verifizieren. Ergebnisse intern veröffentlichen.
• Runbooks: One‑Pager für DSR/CCPA/GDPR/LGPD‑Anfragen. Ihr On‑Call sollte eine Nutzerlöschung initiieren können, ohne die ganze Org zu pagern.

Regionale und regulatorische Nuancen, die Sie nicht ignorieren können

Wenn Sie in die US und Latin America verkaufen, jonglieren Sie mit CCPA/CPRA, sektoralen Vorgaben und Brazil’s LGPD. Operativ zählt:

• Proof beats Policy: Auditoren wollen Logs von Löschungen und Nachweise für TTL sehen, nicht nur ein PDF. Bauen Sie den Audit‑Trail jetzt.
• Cross‑Border‑Transfers: Vermeiden Sie es, P1–P3 außerhalb der vertraglich vereinbarten Region zu leiten. Ihre Liste der KI‑Unterauftragsverarbeiter sollte Modellanbieter und Vector Stores explizit nennen.
• Sensitive Sektoren: Käufer in Healthcare/öffentlichem Sektor in LATAM verlangen zunehmend 0‑Tage Prompt‑Retention, BYOK und explizite Legal Holds. Dafür von Anfang an designen, nicht als Sonderanfertigung.

Rollout‑Plan, der Ihre Roadmap nicht ausbremst

1. Woche 1–2: Datenkarte und Defaults. P1–P3‑Stores inventarisieren. Default‑Retention (0/7/30) pro Klasse festlegen. Jegliches Provider‑seitiges Training ausschalten.
2. Woche 3–4: Quick Wins. TTL zu Redis, S3‑Lifecycle‑Regeln und partitionierten OLTP‑Tabellen hinzufügen. Den Schalter „Diesen Chat behalten“ und die Mandanten‑Policy‑UI implementieren. Prompts beim Ingest samplen + schwärzen.
3. Woche 5–6: Lösch‑DAG. Den Orchestrator bauen, der Löschungen über OLTP, Vektordatenbank, Objektspeicher, APM, Analytics, Suche auffächert. Metriken und P99/P50‑Tracking hinzufügen.
4. Woche 7–8: Legal Holds und Audits. Mandanten‑Legal‑Hold implementieren. Signierte Audit‑Events emittieren. Eine Tabletop‑Übung durchführen und Fixes nachziehen.

Wenn Sie Unterstützung brauchen: Genau diese Art funktionsübergreifender Arbeit können Nearshore‑Teams gut – sie betrifft Infra, Data, Backend, Product und Compliance. Mit 6–8 Stunden Überschneidung zu US‑Zeitzonen und LGPD‑Erfahrung kann ein Team aus Brazil das liefern, ohne Ihre Core‑Feature‑Teams zu entgleisen.

Die unbequeme Wahrheit

Der eigentliche Grund, warum Teams alles behalten, ist Angst: „Was, wenn wir es fürs Debugging oder Training brauchen?“ Die Antwort ist Prozess, nicht Horten. Halten Sie einen kurzen Ringpuffer vor, eskalieren Sie die Erfassung für Incidents mit Freigabe und investieren Sie in Intent‑Level‑Metriken, damit Sie keinen Nutzertext lesen müssen, um zu wissen, was kaputt ist.

Wenn Apple ephemer geht, verschiebt das die Erwartungen. Sie können dieser Welle zuvorkommen und sie als Sales‑Vorteil nutzen. Oder Sie erklären, zum dritten Mal in diesem Quartal, warum Ihre KI‑Transkripte für immer in einem Warehouse liegen, das fünf Anbieter abfragen können.

Kernaussagen

• Standardmäßig ephemer ausliefern: 0–7 Tage Retention für Prompts/Traces, mit Mandanten‑Policies und Legal Holds.
• Einen Lösch‑DAG bauen, der auf jeden Store auffächert – OLTP, Vektordatenbank, Objektspeicher, Analytics, APM und Provider – mit P99 < 24 h.
• Observability erhalten, indem Sie strukturierte Zusammenfassungen und Ausführungsbäume speichern, nicht den Rohtext der Nutzer.
• Vektorindizes sicher machen: keine Roh‑Prompts, TTL pro Punkt, Lösch‑Kaskaden und versionierte Dokumente.
• Als Produktfeature behandeln: Admin‑Retention‑Settings, Region‑Pinning, BYOK, Export und auditierbare Logs gewinnen Enterprise‑Deals.

Author: Diogo Hudson Dias