Die 9 Stellen, an denen dein KI-System Daten verliert (und wie du jede einzelne abdichtest)

Warum Verschlüsselung nicht hilft

Die Standardantwort auf „unser KI-System verarbeitet sensible Daten" lautet: „Wir verschlüsseln sie." Verschlüsselung schützt Daten im Ruhezustand und bei der Übertragung. Für Daten in Verarbeitung bringt sie nichts. In dem Moment, in dem deine Anwendung Kundendaten entschlüsselt, um einen Prompt zu bauen, sind diese Daten für den LLM-Anbieter sichtbar, in Vektordatenbanken eingebettet, in Logs geschrieben, über Tool Calls weitergereicht, im Arbeitsspeicher zwischengespeichert und in Fehlerberichten gespeichert.

KI-Systeme verlieren Daten auf Wegen, die traditionelle Anwendungen nicht kennen. Die Angriffsfläche ist nicht das Netzwerk oder die Datenbank. Es ist die Pipeline: Jeder Schritt zwischen dem Empfang der Benutzereingabe und der Auslieferung einer Antwort erzeugt einen potenziellen Leak-Punkt.

Wir haben jeden Leak-Punkt in den KI-Systemen kartiert, die wir gebaut und deployt haben. Dieser Artikel ist das Ergebnis. Für die architektonische Lösung (semantische Tokenisierung, Trust Boundaries, Policy-gesteuertes Restore) schau dir unseren DSGVO-Compliance-Leitfaden an. Dieser Artikel konzentriert sich darauf, wo Leaks passieren und wie du sie erkennst.

Die 9 Leak-Punkte

Benutzereingabe (enthält PII)
    │
    ├──▶ 1. PROMPTS ────────────▶ LLM-Anbieter sieht Rohdaten
    │
    ├──▶ 2. EMBEDDINGS ─────────▶ Vektor-DB speichert PII dauerhaft
    │
    ├──▶ 3. LOGS ───────────────▶ Log-Aggregator indexiert PII
    │
    ├──▶ 4. TOOL CALLS ─────────▶ Externe APIs erhalten PII als Parameter
    │
    ├──▶ 5. AGENT MEMORY ───────▶ Konversationshistorie speichert PII
    │
    ├──▶ 6. FEHLERMELDUNGEN ────▶ Error-Tracking erfasst PII in Stacktraces
    │
    ├──▶ 7. CACHE ──────────────▶ Response-Cache speichert PII in Antworten
    │
    ├──▶ 8. FINE-TUNING-DATEN ──▶ Trainingsdaten enthalten PII dauerhaft
    │
    └──▶ 9. AGENT HANDOFFS ─────▶ PII überschreitet Trust Boundaries zwischen Agents

1. Prompts

Der offensichtlichste Leak-Punkt und der, den die meisten Teams für gelöst halten. Jeder Prompt, der an einen externen LLM-Anbieter gesendet wird, enthält die Daten, die du hineinsteckst. Wenn du den Namen, die E-Mail, die Bestellhistorie oder den Beschwerdetext eines Kunden in den Prompt aufnimmst, empfängt der LLM-Anbieter diese Daten.

Wo es leckt:

• Die API des LLM-Anbieters empfängt den vollständigen Prompt
• Der Anbieter kann Prompts zur Missbrauchserkennung loggen
• Der Anbieter kann Prompts zur Modellverbesserung verwenden (abhängig von den Nutzungsbedingungen und ob API- oder Consumer-Tarif)

Wie du es abdichtest: Ersetze rohe PII durch semantische Tokens, bevor der Prompt das LLM erreicht. Das Modell empfängt {{person:p_001}} statt des echten Namens. Der Token trägt Metadaten (Geschlecht, Formalität, Sprache), damit das Modell weiterhin korrekte Ausgaben erzeugen kann.

// Vorher: PII im Prompt
const prompt = `Write a reply to Sara Mustermann about order #12345`;

// Nachher: tokenisierter Prompt
const transformed = await guardai.transform(prompt);
// transformed.safe_text = "Write a reply to {{person:p_001}} about order {{order:o_001}}"
const response = await llm.generate(transformed.safe_text);
const final = await guardai.rehydrate(response, transformed.session_state);

2. Embeddings

Das ist der Leak-Punkt, den die meisten Teams komplett übersehen. Wenn du Dokumente für RAG einbettest, kodieren die Embedding-Vektoren semantische Informationen über den Inhalt. Wenn der Inhalt PII enthält, tragen die Embeddings eine Repräsentation dieser PII in der Vektordatenbank.

Wo es leckt:

• Vektordatenbank speichert Embeddings, die aus PII-haltigen Dokumenten abgeleitet wurden
• Ähnlichkeitssuche kann PII aus nicht verwandten Abfragen aufdecken
• Backups der Vektordatenbank enthalten PII-Repräsentationen

Wie du es abdichtest:

Option A: Dokumente vor dem Embedding tokenisieren. Die Embeddings basieren auf tokenisiertem Text. Die Vektordatenbank enthält nie PII-abgeleitete Vektoren.

Option B: Rohe Dokumente einbetten, aber zur Abfragezeit tokenisieren. Die Vektordatenbank befindet sich innerhalb der vertrauenswürdigen Zone. Nur die abgerufenen Chunks überschreiten die Grenze zum LLM, und diese werden vor dem Grenzübertritt tokenisiert.

// Option A: tokenisierten Inhalt einbetten (sicherer, leicht geringere Retrieval-Qualität)
const tokenized = await guardai.transform(documentText);
const embedding = await embedder.embed(tokenized.safe_text);
await vectorStore.upsert({ id: docId, embedding, metadata: { tokenized: true } });

// Option B: roh einbetten, zur Abfragezeit tokenisieren (besseres Retrieval, komplexer)
const embedding = await embedder.embed(documentText); // Roh-Embedding
await vectorStore.upsert({ id: docId, embedding });
// Zur Abfragezeit: Chunks abrufen, dann vor dem Senden an das LLM tokenisieren

Für mehr zur RAG-Pipeline-Architektur schau dir unseren RAG-Reliability-Leitfaden und den Vector-Search-Leitfaden an.

3. Logs

Deine Logging-Infrastruktur wird zu einem PII-Speicher, sobald du rohe Prompts oder Antworten loggst. Dein Datadog-, CloudWatch-, Elasticsearch- oder Grafana-Loki-Cluster verarbeitet jetzt personenbezogene Daten, und jeder davon erfordert DSGVO-Dokumentation, Aufbewahrungsrichtlinien und Betroffenenrechte-Verfahren.

Wo es leckt:

• Strukturierte Logs, die Prompt-Text enthalten
• Request/Response-Logging-Middleware
• Debug-Logs aus der Entwicklung, die es in die Produktion schaffen
• Drittanbieter-Logging-SDKs, die Request Bodies erfassen

Wie du es abdichtest: Logge Token-IDs, niemals Werte. Logge Event-Typen, Entity-Counts, Confidence Scores und Policy-Namen. Logge niemals den Rohtext.

// Gut: PII-freies strukturiertes Log
logger.info('transform_complete', {
    session_id: 'ses_abc',
    entities_detected: 3,
    entity_types: ['person', 'email', 'phone'],
    policy: 'german-support',
    duration_ms: 12,
});

// Schlecht: PII in Logs
logger.info('Processing request', {
    input: 'Sara Mustermann wants to cancel order 12345...',
    // Das ist jetzt PII in deinem Log-Aggregator
});

4. Tool Calls

In agentischen Systemen ruft der KI-Agent externe Tools auf (APIs, Datenbanken, Services). Die Tool-Call-Parameter enthalten oft PII, die aus der Konversation extrahiert wurden. Ein CRM-Lookup-Tool empfängt einen Kundennamen. Ein Abrechnungs-Tool empfängt eine Kontonummer. Ein E-Mail-Tool empfängt eine Empfängeradresse.

Wo es leckt:

• Tool-Call-Parameter, die an externe Services gesendet werden
• Tool-Call-Logging (Agent-Frameworks loggen oft jeden Tool Call)
• Tool-Response-Daten, die im Agent Memory gecacht werden

Wie du es abdichtest: Fange Tool Calls an der Trust Boundary ab. Der Agent übergibt tokenisierte Parameter. Die Runtime löst Tokens in echte Werte innerhalb der vertrauenswürdigen Zone auf, ruft den externen Service mit echten Daten auf und tokenisiert die Antwort, bevor sie an den Agent zurückgeht.

Agent: "Look up customer {{person:p_001}}"
  │
  ▼ (Trust Boundary)
Runtime: löst p_001 zu "Sara Mustermann" auf
Runtime: ruft CRM-API mit echtem Namen auf
Runtime: erhält Antwort mit echten Daten
Runtime: tokenisiert Antwort
  │
  ▼
Agent empfängt: "Customer {{person:p_001}}, account {{customer_id:cid_001}}"

Der Agent sieht oder speichert nie die rohen Werte. Der externe Service operiert innerhalb der vertrauenswürdigen Zone. Wie wir das im agentischen Commerce umsetzen, beschreibt unser Agentic-Commerce-Leitfaden.

5. Agent Memory

Agentische KI-Systeme pflegen Konversationsspeicher über mehrere Turns hinweg. Dieser Speicher enthält die gesamte Konversationshistorie, einschliesslich aller PII, die der Benutzer geteilt hat. Wenn der Speicher persistiert wird (Redis, Datenbank), akkumuliert sich PII über die Zeit.

Wo es leckt:

• In-Memory-Konversationshistorie während der Sitzung
• Persistierter Speicher in Datenbanken oder Key-Value-Stores
• Langzeitgedächtnis für sitzungsübergreifende Personalisierung
• Gemeinsamer Speicher zwischen Agents in Multi-Agent-Systemen

Wie du es abdichtest: Scoping des Speichers nach Tenant, Session und Thread. Tokenisiere PII im Speicher genauso, wie du Prompts tokenisierst. Setze TTLs auf persistierten Speicher. Teile niemals Speicher über Tenant-Grenzen hinweg.

// Memory-Scoping: Tenant + Session + Thread
const memoryKey = `${tenantId}:${sessionId}:${threadId}`;

// Speicherinhalt ist tokenisiert
const memory = [
    { role: 'user', content: 'I am {{person:p_001}}, my order is {{order:o_001}}' },
    { role: 'assistant', content: 'Let me check order {{order:o_001}} for you, {{person:p_001}}.' },
];

// TTL: Speicher verfällt nach Sitzungsende
await memoryStore.set(memoryKey, memory, { ttl: SESSION_TTL });

Für Multi-Tenant-Speicher-Isolationsmuster schau dir unseren Multi-Tenant-Design-Leitfaden an.

6. Fehlermeldungen

Wenn etwas fehlschlägt, enthalten Fehlermeldungen und Stacktraces oft die Daten, die den Fehler verursacht haben. Ein JSON-Parse-Fehler enthält das rohe JSON. Ein Validierungsfehler enthält den ungültigen Feldwert. Ein API-Timeout enthält den Request Payload.

Wo es leckt:

• Error-Tracking-Services (Sentry, Bugsnag, Datadog APM)
• Stacktraces in Server-Antworten
• Fehler-Logs mit Request-Kontext
• Unbehandelte Exception-Reporter

Wie du es abdichtest: Bereinige Error Payloads, bevor du sie an das Error-Tracking sendest. Entferne Request Bodies aus dem Fehlerkontext. Maskiere PII in Fehlermeldungen. Gib niemals rohe Fehlerdetails an Clients zurück.

// Error-Sanitizer-Middleware
function sanitizeError(error: Error, context: any): SanitizedError {
    return {
        message: error.message,
        code: error.code,
        // PII aus dem Kontext entfernen
        context: {
            session_id: context.session_id,
            entity_types: context.entity_types,
            // NICHT einschliessen: context.input, context.prompt, context.customerData
        },
    };
}

7. Cache

Response-Caching speichert die vollständige Antwort, einschliesslich aller PII in der generierten Antwort. Wenn eine gecachte Antwort „Sara Mustermanns Bestellung wurde gestern versandt" enthält, sieht jeder nachfolgende Benutzer, der denselben Cache-Key auslöst, Saras Daten.

Wo es leckt:

• Application-Level-Response-Caches (Redis, Memcached)
• CDN-Caches (wenn KI-Antworten am Edge gecacht werden)
• Semantische Caches (ähnliche Fragen liefern gecachte Antworten mit PII zurück)

Wie du es abdichtest: Cache tokenisierte Antworten, nicht rehydrierte. Der Cache speichert {{person:p_001}}s Bestellung wurde gestern versandt. Jede Benutzeranfrage rehydriert mit dem eigenen Session-Mapping.

Alternativ: Nimm die Session- oder Tenant-ID in den Cache-Key auf, damit personalisierte Antworten nie an den falschen Benutzer ausgeliefert werden.

8. Fine-Tuning-Daten

Wenn du ein Modell mit Kundendaten fine-tunest, sind diese Daten dauerhaft in den Modellgewichten eingebettet. Du kannst keine spezifischen Datensätze aus einem fein abgestimmten Modell extrahieren. Du kannst einem DSGVO-Löschantrag für Daten, die im Training verwendet wurden, nicht nachkommen.

Wo es leckt:

• Trainingsdatensätze, die PII enthalten
• Modellgewichte (Daten sind kodiert, nicht extrahierbar, beeinflussen aber die Ausgaben)
• Trainingsdaten, die vom Modellanbieter während des Fine-Tunings gespeichert werden

Wie du es abdichtest: Tokenisiere Trainingsdaten vor dem Fine-Tuning. Das Modell lernt Muster aus tokenisiertem Text, nicht aus echten PII. Wenn du für die Fine-Tuning-Qualität echte Daten verwenden musst, dokumentiere die Rechtsgrundlage, implementiere Aufbewahrungsrichtlinien und sei darauf vorbereitet, das Modell neu zu trainieren, falls ein Löschantrag es erfordert.

9. Agent Handoffs

In Multi-Agent-Systemen kann ein Agent eine Konversation an einen anderen Agent übergeben. Die Übergabe enthält typischerweise Konversationskontext, der PII aus der Interaktion enthält. Wenn Agents über verschiedene Trust Boundaries hinweg operieren (verschiedene Services, verschiedene Anbieter), überschreitet PII diese Grenzen während der Übergabe.

Wo es leckt:

• Übergabenachrichten zwischen Agents
• Gemeinsame Kontextspeicher, die von mehreren Agents genutzt werden
• Agent-zu-Agent-API-Aufrufe, die Konversationsstatus transportieren
• Orchestrator-Services, die zwischen Agents routen

Wie du es abdichtest: Tokenisiere den Übergabekontext. Der empfangende Agent erhält tokenisierte Konversationshistorie, keine rohen PII. Jeder Agent operiert innerhalb desselben Trust-Boundary-Modells. Grenzüberschreitende Übergaben durchlaufen dieselbe Tokenisierungsschicht wie jeder andere Trust-Boundary-Übergang.

Wie wir Multi-Agent-Architekturen mit ordentlicher Isolation entwerfen, behandelt dieser Leitfaden im Detail.

Der Output Guard: Auffangen, was das Modell erfindet

Neben den 9 eingabeseitigen Leak-Punkten gibt es ein 10. Problem: Das Modell kann PII halluzinieren, die nicht in der ursprünglichen Eingabe enthalten war. Wenn du das Modell bittest, eine Antwort an {{person:p_001}} zu schreiben, kann es eine Telefonnummer, eine Adresse oder einen Firmennamen aus seinen Trainingsdaten erfinden.

Diese halluzinierten PII sind nicht durch deine Tokenisierung geschützt, weil sie nie tokenisiert wurden. Die Lösung ist eine Zweit-Pass-Erkennung auf der Ausgabe des Modells:

async function outputGuard(response: string, sessionTokens: Set<string>): GuardResult {
    // PII-Erkennung auf der Modellantwort ausführen
    const detected = await detector.detect(response);

    // Jede erkannte Entity gegen bekannte Session-Tokens prüfen
    const unknown = detected.filter(entity => !sessionTokens.has(entity.tokenId));

    if (unknown.length > 0) {
        return {
            safe: false,
            flagged: unknown,
            action: 'remove_or_flag', // Unbekannte PII entfernen oder zur Prüfung markieren
        };
    }

    return { safe: true };
}

Der Output Guard fängt ab: erfundene Telefonnummern, halluzinierte Adressen, echte Firmennamen aus Trainingsdaten und jede andere PII, die das Modell generiert und die nicht in der ursprünglichen Eingabe enthalten war.

Mehr zu KI-Fehlermodi, einschliesslich Halluzination, behandelt dieser Leitfaden mit den breiteren Mustern.

Erkennungspriorität

Nicht alle Leak-Punkte sind gleich gefährlich. Priorisiere basierend auf Expositionsfläche und Datensensitivität:

Beginne mit P0 (Prompts und Logs). Diese haben das höchste Volumen und sind am einfachsten zu beheben. Dann kümmere dich um P1 (Tool Calls, Memory, Fehlermeldungen). P2 und P3 sind wichtig, aber weniger dringend.

Häufige Fallstricke

1. Denken, Verschlüsselung löst das Problem. Verschlüsselung schützt Übertragung und Speicherung. Sie bringt nichts, wenn Daten für die Verarbeitung entschlüsselt werden, und genau das tut ein LLM.

2. Nur den finalen LLM-Aufruf schützen. Ein 5-Schritte-Agent-Workflow hat 5 Leak-Oberflächen. Nur den Generierungsschritt zu schützen lässt 4 ungeschützt.

3. Prompts zum Debuggen loggen. Jeder Prompt, den du loggst, ist PII in deinem Log-Aggregator. Logge stattdessen Token-IDs, Entity-Typen und Metadaten.

4. Kein Output Guard. Das Modell halluziniert PII aus Trainingsdaten. Ohne Zweit-Pass-Erkennung auf der Ausgabe erreicht halluzinierte PII den Endbenutzer.

5. Rehydrierte Antworten cachen. Wenn der Cache „Sara Mustermanns Bestellung wurde versandt" speichert, sieht jeder Benutzer, der denselben Cache-Key trifft, Saras Daten.

6. Fine-Tuning mit rohen Kundendaten. Sobald PII in Modellgewichten steckt, kann sie nicht extrahiert oder gelöscht werden. Tokenisiere Trainingsdaten.

7. Error-Tracking ignorieren. Sentry und Bugsnag erfassen standardmässig Request-Kontext. Dieser Kontext enthält PII, wenn deine Requests PII enthalten.

8. Gemeinsamer Agent Memory über Tenants hinweg. Agent A in einem Tenant darf keinen Zugriff auf die Konversation von Agent B in einem anderen Tenant haben.

Wichtigste Erkenntnisse

• KI-Systeme haben 9 unterschiedliche Leak-Punkte. Prompts, Embeddings, Logs, Tool Calls, Agent Memory, Fehlermeldungen, Cache, Fine-Tuning-Daten und Agent Handoffs. Jeder braucht seine eigene Schutzstrategie.

• Verschlüsselung hilft zur Verarbeitungszeit nicht. Daten müssen entschlüsselt werden, bevor das LLM sie verarbeiten kann. Der Schutz muss auf der Anwendungsebene stattfinden, nicht auf der Transportebene.

• Semantische Tokenisierung ist die architektonische Lösung. Ersetze Rohwerte durch Tokens, die Metadaten tragen. Das LLM verarbeitet Tokens. Echte Werte bleiben innerhalb der vertrauenswürdigen Zone.

• Der Output Guard fängt halluzinierte PII auf. Das Modell erfindet Daten aus seinem Trainingsset. Eine Zweit-Pass-Erkennung auf der Ausgabe fängt Entities ab, die nicht im Token-Mapping der Session enthalten waren.

• Beginne mit Prompts und Logs (P0). Diese haben das höchste Volumen und sind am einfachsten zu beheben. Dann kümmere dich um Tool Calls, Memory und Fehlermeldungen (P1).

• Jeder Leak-Punkt braucht Monitoring. Verfolge, wie viele PII-Entities erkannt werden, wie viele tokenisiert werden, wie viele durchrutschen. Alarmiere bei Anomalien.

Wir wenden diese Muster in all unseren KI-Systemen durch OGuardAI an, unsere Open-Source-Runtime für semantischen Datenschutz. Wenn du KI-Systeme baust, die sensible Daten verarbeiten, sprich mit unserem Team oder fordere ein Angebot an. Schau dir unsere KI-Services und unsere Trust-Seite an, um mehr darüber zu erfahren, wie wir Datenschutz angehen.