Entscheiden, was in einem KI-Ausführungstrace bleibt

Was eine Debugging-Sitzung tatsächlich braucht

Die ersten Fragen im Bereitschaftsdienst sind strukturell: Warum hat der Agent dieses Tool aufgerufen, warum hat der Lauf vierzig Sekunden gedauert, warum hat er dreimal so viel gekostet wie üblich, wo ist er gescheitert? Der Span-Baum beantwortet die meisten davon, mit Operationsnamen, angefragtem und antwortendem Modell, Token-Verbrauch, Tool-Namen, Fehlertypen und Laufzeiten sowie einer Kennung, die den Lauf mit dem Geschäftsvorgang verbindet. Die Semantic Conventions von OpenTelemetry für generative KI, noch im Status Development, definieren Attribute für die meisten dieser Angaben. Vollständige Inhalte braucht man für engere Aufgaben: eine falsche Antwort nachstellen, die Qualität einer Ausgabe beurteilen und einen Verdacht auf Prompt Injection untersuchen.

Drei Stufen von Trace-Daten

1. 1

   Stufe 1: betriebliche Metadaten

   Span-Struktur, Modellnamen, Token-Zahlen, Tool-Namen, Status, Zeiten und ein pseudonymer Verweis auf den Nutzer. Keine Nachrichteninhalte. Aufbewahrt nach Ihrer üblichen Frist für Betriebslogs.

2. 2

   Stufe 2: Inhalte nach Entscheidung

   Prompts, Systemanweisungen, Ausgaben, Tool-Argumente und -Ergebnisse, abgerufene Textstellen. Nur für eine festgelegte Stichprobe, markierte Läufe oder eine befristete Untersuchung erfasst, getrennt von Stufe 1 gespeichert, mit engerem Zugriff und einer kürzeren Frist, die Ihre Verantwortlichen festlegen.

3. 3

   Stufe 3: nie gespeichert

   Access Tokens, API-Schlüssel, Passwörter, Verbindungszeichenfolgen und rohe Session-Kennungen. Das OWASP Logging Cheat Sheet nennt diese unter den Daten, die in der Regel entfernt, maskiert, gehasht oder verschlüsselt statt direkt protokolliert werden sollten.

Inhalte standardmäßig aus Traces heraushalten

Die OpenTelemetry-Konventionen für generative KI stufen Modellanweisungen, Nutzernachrichten und Ausgaben als sensibel ein. Sie sehen vor, dass Instrumentierungen diese standardmäßig nicht erfassen, aber ein Opt-in anbieten, und empfehlen für die Produktion, Inhalte extern zu speichern und auf Spans nur Verweise abzulegen, damit für Inhalte eigene Zugriffsregeln gelten können. Bibliotheken außerhalb von OpenTelemetry können sich anders verhalten, und die OpenTelemetry-Hinweise zu sensiblen Daten machen es zu Ihrer Aufgabe, zu prüfen, was Ihre Instrumentierung ausgibt. Kontrollieren Sie die tatsächliche Ausgabe jeder Bibliothek in einem Testlauf, statt sich allein auf ihre Dokumentation zu verlassen.

Schwärzung als zweite Verteidigungslinie

Der OpenTelemetry Collector kann Attribute löschen, hashen oder umschreiben, ganze Spans verwerfen und mit dem Redaction-Prozessor Attribute entfernen, die nicht auf einer Allowlist stehen. Nutzen Sie für Stufe 1 eine Allowlist, damit ein neues Attribut nicht unbemerkt durchrutscht. Verlassen Sie sich nicht auf musterbasiertes Schwärzen von Freitext: Personenbezogene Daten tauchen in Prompts in Formen auf, die kein Muster vorhersieht. OpenTelemetry weist außerdem darauf hin, dass das Hashen eines kleinen oder vorhersehbaren Werts, etwa einer numerischen Nutzer-ID, ihn womöglich nicht anonymisiert, weil sich der Hash durch Ausprobieren aller möglichen Eingaben umkehren lässt.

Wer die Aufbewahrungsfrist festlegt

Wie lange jede Stufe aufbewahrt wird, entscheiden Ihre Verantwortlichen für Datenschutz, Recht und Sicherheit, nicht eine technische Voreinstellung, und dieser Beitrag ist keine Rechtsberatung. Das OWASP Logging Cheat Sheet formuliert den Grundsatz klar: Logdaten sollen weder vor Ablauf der erforderlichen Frist gelöscht noch darüber hinaus aufbewahrt werden. Die technische Seite macht die Entscheidung durchsetzbar:

• Getrennter Speicher je Stufe mit Ablauf, der im Speicher selbst konfiguriert ist
• Löschung, die auch Exporte, Kopien in Evaluierungssets und Backups erreicht
• Ein Zugriffslog für Stufe 2, das jemand außerhalb des lesenden Teams prüft
• Ein Verzeichnis, was jeder Dienst erfasst, aktualisiert bei jeder Änderung der Instrumentierung

Wenn Traces die Arbeit einzelner Beschäftigter erkennbar machen, beziehen Sie früh die Stellen ein, die Fragen zu Beschäftigtendaten bearbeiten.

Eine hypothetische Debugging-Sitzung nach diesen Regeln

Ein KI-Agent im Support nennt einem Kunden einen falschen Erstattungsbetrag. Die Bereitschaft öffnet den Trace über die Vorgangsnummer. Stufe 1 zeigt, dass der Agent erst die Bestellabfrage und dann das Tool zur Erstattungsberechnung aufgerufen hat, das schnell und mit normalen Token-Zahlen erfolgreich war. Der Fehler liegt also in den Eingaben oder der Logik. Tool-Argumente gehören zu Stufe 2 und wurden nicht erfasst. Der Engineer beantragt eine befristete Erfassung für genau dieses Tool, die Datenverantwortliche stimmt zu, und ein Lauf mit einer synthetischen Bestellung im Staging zeigt, dass der Betrag ohne Währung übergeben wurde. Nach der Korrektur wird die Erfassung abgeschaltet, und die erfassten Inhalte laufen zum vereinbarten Datum ab.

KI-Engineering und -Architektur