LLM-Observability — mächtig, und datenschutzrechtlich heikel

Was im Trace landet — und warum das ein Datenschutz-Thema ist

Ein LLM-Trace ist kein anonymes Performance-Log. Standardmäßig speichert er den vollständigen Prompt, die komplette Antwort und den RAG-Kontext, der dem Modell mitgegeben wurde. Je nach Anwendungsfall heißt das: Bewerberdaten, Patientenanfragen, interne Dokumente, Kundennamen — alles, was der Nutzer ins Chatfenster tippt oder was die Wissensbasis beisteuert.

Tracing einzuschalten ist damit eine eigene Verarbeitung zu einem neuen Zweck (Monitoring, Eval, Debugging). Das ist nicht durch die Rechtsgrundlage des eigentlichen Dienstes mitgedeckt — es braucht eine eigene Betrachtung. Drei Punkte, die in der Praxis fast immer fehlen:

• Rechtsgrundlage + Zweckbindung (Art. 6, Art. 5): Wofür genau werden die Traces verarbeitet, und ist das vom ursprünglichen Zweck gedeckt? „Wir behalten alles, falls wir es mal brauchen" ist es nicht.
• Verzeichnis + Löschkonzept (Art. 30, Art. 17): Die Trace-Verarbeitung gehört ins VVT, mit definierter Aufbewahrungsdauer und Löschpfad — auch für den S3-/ClickHouse-Speicher dahinter.
• Datenfluss in Drittländer (Kap. V / Schrems II): Cloud-Observability (Langfuse Cloud, LangSmith & Co.) schickt die Traces — also die Roh-Prompts — typischerweise in die USA.

Der datensparsame Weg

Observability und Datenschutz schließen sich nicht aus — man muss nur bewusst entscheiden, was man festhält:

• Self-hosted statt Cloud: das Tool läuft on-premise, kein Trace verlässt die eigene Infrastruktur (kein Drittland-Transfer).
• Scope statt „alles": oft reichen Metadaten — Latenz, Token-Zahl, Kosten, Fehlerquote, Modell — für Betrieb und Kostenkontrolle, ganz ohne Prompt-Inhalte zu speichern.
• Datensparsamkeit als Default: Inhalte nur dort loggen, wo es einen dokumentierten Zweck gibt — und mit kurzer, automatischer Löschfrist. Kein „Roh-Daten horten fürs Re-Training".
• Zugriff hart eingegrenzt: die Trace-UI hinter VPN/SSO, nicht öffentlich erreichbar — denn wer sie sieht, sieht die Inhalte.

Wie wir das für euch aufsetzen

Im Lab arbeiten wir mit Langfuse v3 (MIT-Lizenz, voll self-hostbar) als Referenz-Tool. Der Aufbau ist ein Docker-Compose-Stack — UI, Worker, Postgres für Metadaten, ClickHouse für die Analytics, Queue und S3-kompatibler Speicher — angebunden an einen LLM-Gateway (LiteLLM, OpenAI-API, Bedrock) per Callback. Entscheidend ist nicht der Stack, sondern die Konfiguration drumherum: welcher Scope geloggt wird, wie lange, hinter welchem Zugriffsschutz, mit welchem VVT-Eintrag und Löschkonzept. Genau diese Entscheidungen treffen wir mit euch — nicht der Default des Tools.