|Ben @ Grepture

Sensible Daten in LLM-API-Aufrufen schützen: Eine Schritt-für-Schritt-Anleitung

Schritt-für-Schritt-Anleitung zum Schutz von PII, Secrets und sensiblen Daten in LLM-API-Aufrufen — von Audit bis Durchsetzung.

Das Problem, das niemand anspricht

Sie entwickeln ein KI-Feature für den Kundensupport. Ihre Anwendung setzt Prompts aus Support-Tickets, Benutzerprofilen und Bestellhistorien zusammen. Eine typische Anfrage an OpenAI sieht so aus:

"Kundin Sarah Müller (sarah@example.com, +49-170-5550123) fragt zu Bestellung #45231. Kontodaten: Steuer-ID endet auf 4532, Adresse: Lindenstr. 42, 80331 München..."

All das fließt an die OpenAI-API. Jede Anfrage. Jeder Kunde. Jedes Mal.

Und es betrifft nicht nur den Kundensupport. Jedes KI-Feature, das mit echten Daten arbeitet — Code-Assistenten, die auf private Repos zugreifen, Analysetools, die Nutzerverhalten zusammenfassen, Content-Generatoren, die interne Dokumente referenzieren — hat dasselbe Problem.

Was alles durchsickern kann:

  • Personenbezogene Daten (PII) (Namen, E-Mails, Telefonnummern, Adressen) — DSGVO/CCPA-Verstoß, potenzielle Bußgelder in Millionenhöhe
  • Secrets (API-Schlüssel, Datenbank-Verbindungszeichenfolgen, OAuth-Tokens, die versehentlich im Prompt-Kontext landen) — direktes Sicherheitsrisiko
  • Proprietäre Daten (Quellcode, interne Dokumentation, Geschäftsgeheimnisse) — Risiko des IP-Diebstahls
  • Regulierte Daten (Gesundheitsinformationen, Finanzdaten) — Verstöße gegen HIPAA, PCI-DSS, KYC/AML-Compliance

Die meisten Teams wissen nicht, wie viele Daten fließen — bis sie hinschauen. Die Lösung ist nicht "sorgfältiger arbeiten", sondern automatisierte Erkennung auf Infrastrukturebene. Dieser Leitfaden behandelt einen schrittweisen Ansatz zum Erkennen, Klassifizieren und Kontrollieren sensibler Daten in Ihrem LLM-Traffic mit Grepture.

Schritt 1: Audit — verstehen, was gesendet wird

Bevor Sie irgendetwas schützen können, müssen Sie sehen, was tatsächlich durch Ihre KI-Pipeline fließt. Hier erleben die meisten Teams ihre erste Überraschung.

Richten Sie Grepture mit Log-only-Regeln ein — Erkennung ohne Blockierung. Am Verhalten Ihrer Anwendung ändert sich nichts. Sie fügen lediglich Transparenz hinzu.

import Grepture from "@grepture/sdk";
import OpenAI from "openai";

const grepture = new Grepture({
  apiKey: process.env.GREPTURE_API_KEY,
  proxyUrl: "https://proxy.grepture.com",
});

const openai = new OpenAI({
  ...grepture.clientOptions(),
  apiKey: process.env.OPENAI_API_KEY,
});

// Das war's. Alle Anfragen fließen jetzt durch Grepture.
// Erkennungsregeln im Dashboard konfigurieren — mit Log-only-Modus starten.

Drei Zeilen Code. Nun die Erkennung im Dashboard aktivieren:

  • Regex-Erkennung für strukturierte PII — E-Mail-Adressen, Telefonnummern, Sozialversicherungsnummern, Kreditkartennummern, API-Schlüssel, Bearer-Tokens. 50+ integrierte Muster im Free-Tier.
  • KI-Erkennung für Namen und Orte — diese tauchen in natürlicher Sprache auf und werden von Regex übersehen. Aktivieren Sie lokale KI-Modelle, um sie zu erfassen.

Setzen Sie alle Regeln auf Log-only-Modus mit Schweregrad-Stufen (info, warn oder critical), damit Sie sehen können, was passiert, ohne den Produktionsbetrieb zu beeinträchtigen.

Lassen Sie es eine Woche lang gegen Ihren Produktions-Traffic laufen. Dann prüfen Sie das Dashboard-Traffic-Log — Sie sehen jede Anfrage, was erkannt wurde und den Schweregrad.

Teams unterschätzen, wie viel PII durch ihre KI-Pipelines fließt. Wir haben Anwendungen gesehen, die bei jeder einzelnen Anfrage vollständige Kundenprofile inklusive Sozialversicherungsnummern an LLMs senden — und niemand wusste es, bis man hingeschaut hat. Mehr dazu, worauf Sie achten sollten und wie Sie Ergebnisse kategorisieren, finden Sie in unserem Leitfaden zu PII-Erkennungs-Best-Practices.

Schritt 2: Erkennungsregeln — strukturierte Daten + KI

Nach der Audit-Phase wissen Sie, was fließt. Jetzt Erkennungsregeln aufsetzen. Zwei Ebenen, die zusammenarbeiten.

Regex-Regeln für strukturierte Daten. Schnell, deterministisch, vorhersagbar. Grepture liefert über 50 integrierte Muster (80+ bei Pro):

  • E-Mail-Adressen
  • Telefonnummern (internationale Formate)
  • Sozialversicherungsnummern
  • Kreditkartennummern (mit Luhn-Validierung)
  • API-Schlüssel und Bearer-Tokens
  • Datenbank-Verbindungszeichenfolgen
  • IP-Adressen
  • AWS Access Keys, GitHub Tokens, Stripe Keys und mehr

Aktivieren Sie die Muster, die für Ihre Daten relevant sind. Jede Regel kann mit einer bestimmten Aktion (log, redact, mask, block) und einem Schweregrad konfiguriert werden. Starten Sie mit Logging, dann verschärfen Sie schrittweise.

KI-Erkennung für unstrukturierte Daten. Regex kann "Sarah Müller wohnt in München" nicht erkennen — kein Muster greift. Lokale KI-Modelle füllen die Lücke:

  • Namen — Personennamen in jedem Format, jeder Sprache
  • Orte — Städte, Adressen, Länder in natürlicher Sprache
  • Organisationen — Firmennamen, Institutionsreferenzen

Alle KI-Modelle laufen lokal auf der Grepture-Infrastruktur. Ihre Daten werden nicht an einen weiteren Drittanbieter weitergeleitet.

Prompt Injection als separates Thema. Während Sie die Erkennung einrichten, aktivieren Sie auch das KI-gestützte Prompt-Injection-Scoring. Eine andere Bedrohung als Datenlecks, aber genauso wichtig bei nutzergenerierten Inhalten. Einen ausführlichen Einblick bietet unser Prompt-Injection-Präventionsleitfaden.

Konfigurieren Sie Bedingungen, um bestimmte Endpunkte, Modelle oder Anfragemuster gezielt anzusprechen. Legen Sie Sampling-Raten fest — starten Sie mit 100% für kritische Regex-Regeln. Wenn Sie auf dem Free-Tier sind (25 KI-Erkennungsanfragen/Monat), nutzen Sie Sampling für die KI-Erkennung während der Evaluierung und steigen dann auf Pro für unbegrenzte Erkennung um.

Schritt 3: Mask and Restore — für nutzerseitige KI-Features

Bei Features, bei denen die LLM-Antwort zurück an den Nutzer geht — Chatbots, Support-Agenten, Content-Generierungstools — müssen die Daten den Roundtrip überleben. Den Namen eines Kunden dauerhaft aus einer Support-Antwort zu entfernen, macht sie unbrauchbar. Genau hier kommt Mask and Restore ins Spiel.

So funktioniert es:

  1. Grepture erkennt PII in der ausgehenden Anfrage
  2. Sensible Werte werden durch Token ersetzt (z.B. wird Sarah Müller zu [NAME_1])
  3. Die Originalwerte werden in einem sicheren Vault mit konfigurierbarem TTL gespeichert
  4. Das LLM verarbeitet den tokenisierten Prompt und generiert eine Antwort mit denselben Token
  5. Grepture fängt die Antwort ab und stellt die Originalwerte wieder her

Der Nutzer erhält eine natürliche Antwort mit seinen echten Daten. Das LLM sieht sie nie.

Konfigurieren Sie Mask-and-Restore-Regeln im Dashboard für die relevanten Datentypen:

  • Namen — maskieren mit KI-Erkennung, in der Antwort wiederherstellen
  • E-Mail-Adressen — maskieren mit Regex, in der Antwort wiederherstellen
  • Telefonnummern — maskieren mit Regex, in der Antwort wiederherstellen
  • Adressen — maskieren mit KI-Erkennung, in der Antwort wiederherstellen

Das funktioniert auch mit Streaming-Antworten. Grepture verarbeitet SSE nativ und detokenisiert gestreamte Chunks in Echtzeit, ohne die gesamte Antwort zu puffern.

Einen ausführlichen Einblick in die Funktionsweise von Mask and Restore, einschließlich Vault-TTL-Konfiguration und Sonderfälle, finden Sie in unserem Maskieren-und-Wiederherstellen-Leitfaden.

Schritt 4: Secrets anders behandeln — blockieren, nicht maskieren

Secrets sind kein PII. Sie brauchen eine andere Reaktion.

Wenn ein API-Schlüssel, eine Datenbank-Verbindungszeichenfolge oder ein OAuth-Token in einem Prompt auftaucht, stimmt etwas nicht. Ein Secret zu maskieren kaschiert das Symptom — das Problem ist, dass Zugangsdaten im Prompt-Kontext landen.

Richten Sie Block-Regeln für Secrets ein:

  • Wenn ein API-Schlüssel oder eine Verbindungszeichenfolge erkannt wird, lehnen Sie die Anfrage ab mit einer eindeutigen Fehlermeldung
  • Protokollieren Sie den Vorfall mit critical-Schweregrad, damit Ihr Team die Ursache untersuchen und beheben kann
  • Die blockierte Anfrage erreicht niemals den LLM-Provider

Für Secrets, die in weniger kritischen Kontexten auftauchen könnten — etwa Beispiel-API-Schlüssel in Dokumentationsinhalten — verwenden Sie dauerhafte Schwärzung statt Mask and Restore. Ersetzen Sie den Wert durch [REDACTED] und speichern Sie das Original nicht. Es gibt keinen legitimen Grund, ein Secret über ein LLM hin und zurück zu schicken.

Faustregel:

  • Mask and Restore für PII, die Teil des normalen Betriebs ist (Namen, E-Mails, Telefonnummern in nutzerseitigen Features)
  • Blockieren für Secrets, die auf einen Bug oder eine Fehlkonfiguration hinweisen (API-Schlüssel, Tokens, Verbindungszeichenfolgen)
  • Dauerhafte Schwärzung für sensible Daten, die den Roundtrip nicht überleben müssen (Sozialversicherungsnummern, Kreditkartennummern in analytischen Abfragen)

Schritt 5: Überwachen und verschärfen

Erkennungsregeln sind nicht einmal einrichten und vergessen. Ihre Anwendung entwickelt sich, neue Datenquellen kommen dazu, neue KI-Features. Laufende Überwachung macht aus initialem Schutz dauerhafte Sicherheit.

Dashboard regelmäßig prüfen. Schauen Sie sich an, was erkannt wird, prüfen Sie auf False Positives und identifizieren Sie neue Muster, die Sie noch nicht berücksichtigt haben. Das Traffic-Log zeigt jede Anfrage mit vollständigen Erkennungsdetails — welche Regeln gegriffen haben, welche Aktion ausgeführt wurde und wie lange die Erkennung gedauert hat.

Schwellenwerte anpassen. Die Empfindlichkeit der KI-Erkennung kann justiert werden. Wenn Sie False Positives bei gängigen Namen erhalten, die in Ihrem Kontext keine PII sind, erhöhen Sie den Konfidenz-Schwellenwert. Wenn Sie Grenzfälle übersehen, senken Sie ihn.

Eigene Muster hinzufügen für Ihre spezifischen Daten:

  • Interne Benutzer-IDs oder Kontonummern mit vorhersagbaren Formaten
  • Eigene Token-Formate Ihres Authentifizierungssystems
  • Proprietäre Datenmarkierungen oder Klassifizierungslabels
  • Branchenspezifische Kennungen (Policennummern, Patienten-IDs, Aktenzeichen)

Zero-Data-Modus aktivieren (Business+) für maximale Datenminimierung. In diesem Modus verarbeitet Grepture jede Anfrage nur im Arbeitsspeicher. Keine Request-Bodies, keine Response-Bodies, keine Header berühren den Speicher. Nur operative Metadaten — Methode, Statuscode, Latenz, welche Regeln ausgelöst wurden — werden protokolliert. Ihre Prompts und Antworten bleiben bei Ihnen.

Compliance-Berichte generieren (Business+) als Audit-Nachweis. Diese Berichte dokumentieren, welche Erkennungsregeln aktiv sind, welche Daten gefunden wurden und welche Aktionen ausgeführt wurden — genau das, was Ihr Compliance-Team für DSGVO-, HIPAA- oder SOC-2-Audits benötigt.

Neue KI-Features sind automatisch geschützt. Jede Anfrage fließt durch den Proxy.

Alles zusammengefügt

Die vollständige Pipeline, von null auf geschützt:

  1. SDK-Integration — einmalige Einrichtung, 3 Zeilen Code. Siehe die Schnellstart-Anleitung.
  2. Audit-Phase — Log-only-Modus, 1 Woche Produktions-Traffic. Verstehen, was fließt.
  3. PII-Erkennung — Regex + KI-Regeln, Mask and Restore für nutzerseitige Features. Siehe PII-Erkennungs-Best-Practices.
  4. Secret-Erkennung — Block-Regeln für API-Schlüssel, Tokens und Verbindungszeichenfolgen.
  5. Prompt-Injection-Erkennung — KI-Scoring, mit Logging starten. Siehe Prompt-Injection-Prävention.
  6. Laufende Überwachung — Dashboard-Review, Schwellenwert-Tuning, eigene Muster.

Die Einrichtung dauert unter einer Stunde. Die Audit-Phase ist, wo Sie Zeit investieren — und wo Sie am meisten darüber erfahren, was Ihre KI-Features tatsächlich mit Ihren Daten machen.

Dieser Ansatz erfüllt die Datenminimierungsanforderungen der DSGVO, die Robustheitsanforderungen des EU AI Acts und gibt Ihrem Compliance-Team den Audit-Trail, den es braucht. Details dazu, wie diese Regulierungen speziell auf KI-Systeme anwendbar sind, finden Sie in unserem EU-AI-Act-Compliance-Leitfaden.

Einen breiteren Überblick finden Sie in unserem LLM-Sicherheitstools-Vergleich. Für detaillierte Regelkonfiguration siehe die Konfigurationsdokumentation.

Die Daten, die gerade durch Ihre KI-Pipeline fließen, werden sich nicht von selbst schützen. Starten Sie das Audit, sehen Sie, was da ist, und beginnen Sie, die Lücken zu schließen.