Man kann eine LLM-Anwendung nicht debuggen, ohne Prompts zu loggen, und man kann diese Prompts nicht behalten, wenn sie voller Namen, E-Mail-Adressen und Kontonummern sind. Nutzer tippen personenbezogene Daten direkt ins Eingabefeld, sodass das Log, das einem hilft, eine schlechte Antwort zu verstehen, zugleich ein wachsender Speicher regulierter Daten ist, der in CloudWatch oder S3 mit der falschen Retention und den falschen Zugriffskontrollen liegt. Die Lösung ist nicht, das Loggen einzustellen. Sie ist, vor der Speicherung zu redigieren und eine Retention-Policy auf das zu legen, was übrig bleibt, sodass der Debugging-Wert erhalten bleibt und die Haftung nicht.

Die Umdeutung: Ein Prompt-Log ist eine Datenerhebungsfläche, keine Debugging-Bequemlichkeit. In dem Moment, in dem man einen rohen Prompt auf die Platte schreibt, hat man erhoben, was auch immer der Nutzer hineingeschrieben hat, unter welcher Regulierung auch immer diese Daten fallen. Die Log-Pipeline als Ort behandeln, an dem PII auf dem Weg hinein entfernt wird, nicht als Ort, den man später aufräumt, nachdem ein Audit gefragt hat.

Auf dem Weg hinein redigieren, nicht auf dem Weg hinaus

Der einzige verlässliche Ort, um PII zu entfernen, ist vor dem Schreiben. Nach der Speicherung zu redigieren bedeutet, dass die Rohdaten schon existiert haben, schon repliziert wurden, schon in Backups liegen, und "wir löschen es später" ist keine Kontrolle, die ein Auditor akzeptiert. Den Redaktionsschritt zwischen die Anfrage und die Log-Senke setzen, sodass der Wert, der in der Speicherung landet, von Anfang an nie sensibel war.

Amazon Comprehend liefert die Erkennungsprimitive. DetectPiiEntities untersucht Text in Echtzeit und liefert jede gefundene PII-Entität, ihren Typ, ihre Zeichen-Offsets und einen Konfidenzwert. Diese Offsets nutzt man, um die Abschnitte vor dem Loggen zu ersetzen. Comprehend unterstützt zwei Maskierungsmodi: jede Entität durch ihren Typ ersetzen, sodass "Jane Doe" zu [NAME] wird, was das Log lesbar hält, oder die Zeichen mit einem festen Symbol maskieren. Der Ersatz durch den Typ ist meist richtig, weil er die Form des Prompts fürs Debugging erhält und dabei die Identität entfernt.

entities = comprehend.detect_pii_entities(Text=prompt, LanguageCode="en")
redacted = prompt
for e in sorted(entities["Entities"], key=lambda x: x["BeginOffset"], reverse=True):
    redacted = redacted[:e["BeginOffset"]] + f"[{e['Type']}]" + redacted[e["EndOffset"]:]
log.write(redacted)   # only the redacted form is ever persisted

Von hinten nach vorne spleißen, damit frühere Offsets beim Umschreiben der Zeichenkette gültig bleiben. Erkennung ist ein Echtzeit-Aufruf; für große historische Batches bietet Comprehend auch asynchrone Redaktions-Jobs, aber der Live-Pfad ist es, der neue Schreibvorgänge schützt.

Erkennung ist probabilistisch, also für Fehltreffer designen

Comprehend ist ein Machine-Learning-Detektor, das heißt, er hat einen Recall unter 100 Prozent und einen Konfidenzwert, für den man eine Untergrenze setzen muss. Ein niedriger Schwellenwert redigiert aggressiv und kann legitimen Text verstümmeln, ein hoher lässt Grenzfall-PII durch. Zwei Gewohnheiten machen das sicher:

  • Einen deterministischen Durchgang darüberlegen. Bei strukturierten Kennungen mit festem Format, Kreditkartennummern, nationalen IDs, manchen Kontoformaten, fängt ein Regex, was ein probabilistisches Modell übersehen kann, und fängt es jedes Mal auf dieselbe Weise. Beide laufen lassen.
  • In Richtung False Positives redigieren. In einem Debug-Log kostet Über-Redaktion ein wenig Lesbarkeit. Unter-Redaktion kostet einen Datenschutzvorfall. Den Schwellenwert in Richtung "zu viel entfernen" verschieben.

Amazon Bedrock Guardrails kann sensible Informationen auch an der Modellgrenze filtern, was komplementär ist: Guardrails schützt den Anfrage- und Antwortpfad, Comprehend schützt, was man in die eigenen Logs schreibt. Das nutzen, was dort sitzt, wo das eigene Risiko liegt.

Retention ist die andere Hälfte der Kontrolle

Redaktion reduziert, was ein Log enthält, Retention begrenzt, wie lange selbst die redigierte Form lebt. Ein redigierter Prompt ist geringeres Risiko, nicht null Risiko, und ein Debug-Log hat eine natürliche Nutzungsdauer, die in Wochen gemessen wird, nicht in Jahren. Retention explizit an der Senke setzen:

  • Nach Zeitplan verfallen lassen. Eine CloudWatch-Log-Group-Retention-Einstellung oder eine S3-Lifecycle-Regel, die nach einem definierten Fenster löscht, bedeutet, dass alte Logs von selbst altern, ohne dass sich jemand ans Aufräumen erinnern muss.
  • Retention an den Zweck anpassen. Operatives Debugging braucht selten mehr als 30 bis 90 Tage. Wird aus einem bestimmten Grund ein längeres Fenster gebraucht, den Grund benennen und die Retention auf die Logs beschränken, die es brauchen.
  • Zugriff einschränken. Auch redigierte Logs verdienen zugeschnittenes IAM. Der Kreis der Leute, die rohe Prompt-Logs lesen können, sollte klein und namentlich benannt sein.

Fazit

Prompt-Logging und PII-Schutz stehen nicht im Widerspruch, sie sind zwei Schritte derselben Pipeline. Vor dem Schreiben mit Comprehend redigieren, einen deterministischen Durchgang für Kennungen mit festem Format darüberlegen und den Schwellenwert in Richtung Über-Redaktion verschieben. Dann eine Retention-Policy auf das legen, was übrig bleibt, sodass die redigierten Logs nach Zeitplan verfallen, statt sich hinter lockerem Zugriff endlos anzusammeln. Beides tun, und man behält das Debugging-Signal, das man braucht, während die regulierten Daten nie ruhend landen. Das Log, das einem hilft, die App zu reparieren, sollte nicht das sein, das in einem Breach-Report auftaucht.

Weiterlesen

Für die Plattformseite von Log-Pipelines, Retention und Zugriffskontrolle gibt es die Cloud-Field-Notes auf ercan.cloud, und den Hub auf ercanermis.com.