Nachvollziehbarkeit von Agents: Wie schaust du für ein Audit in eine KI-Interaktion hinein?

Der Support öffnet eine Sitzung. Die UI sagt zwei Suchen und sechs Tools. Die Foundry Traces zeigen etwas anderes. App Insights erzählt eine dritte Geschichte. Niemand kann sagen, ob der Agent im Wissen gesucht, einen Zitatpfad halluziniert oder ob der Zähler gelogen hat. Das ist kein kosmetischer Bug. Da fehlt eine Produktoberfläche.

Aktivitätszeitleisten müssen Traces der Plattform, MCP-Wissenssuchen und Zähler der UI abgleichen. Speichere normalisierte Ereignisse, nicht nur Chat-Blasen. Zähle Wissenssuchen getrennt von allgemeinen Tool-Aufrufen. Nachvollziehbarkeit gehört bei Wissens-Agents mit hohem Risiko in die schriftliche Richtlinie.

Abbildung 1. Speichern, projizieren, abgleichen. Wenn du die Tool-Aufrufe nicht erklären kannst, hast du eine Chat-Oberfläche über einer undurchsichtigen Laufzeit.

Kontext und Rahmenbedingung

Stell dir eine Agent-Shell vor, in der die Debug-Schublade und die polierten Aktivitäts-Chips einander widersprechen. Engineers vertrauen den Traces. Nutzer vertrauen den Chips. Der Support vertraut keinem von beiden. Die Zeit für Incidents explodiert, weil das Produkt sich nicht selbst erklären kann.

Traces aus Foundry (oder einem Gegenstück), MCP-Wissenssuchen und Zusammenfassungen in der UI müssen sich ein normalisiertes Ereignismodell teilen. Die UI darf vereinfachen. Sie darf nicht erfinden. Eine Debug-Schublade auf Basis von Foundry plus App Insights verkürzt Incidents nur, wenn dieselben Kennungen Chat, Tools und Spans der Plattform zusammennähen.

Chips in der Shell nützen nur, wenn die Anwendungskarte und der Ereignisspeicher dieselbe Geschichte erzählen. Zähler in der UI allein sind kein Audit-Trail. Speichere Ereignisse und gleiche sie mit den Traces der Plattform ab. Die Anwendungskarte und die Transaktionsansichten von Application Insights taugen für den Support nur, wenn Operation IDs die Spans von Shell, API und Foundry zusammennähen. Siehe Microsoft Learn: Korrelation in Application Insights und Übersicht über Application Insights.

Design

1. Zähler in der UI als Projektionen gespeicherter Ereignisse behandeln

"2 Suchen / 6 Tools" muss aus gespeicherten Aktivitätsereignissen berechnet werden, nicht in React hochgezählt, weil ein Spinner lief. Wenn die Plattform einen Tool-Aufruf ablehnt, darf die UI den optimistischen Zähler nicht behalten. Fehler in der Projektion sind Fehler im Modell.

2. Normalisierte Aktivitätsereignisse speichern

Speichere eine strukturierte Zeitleiste: Tool-Name, Wissenssuche oder allgemeines Tool, Status, Latenz, Correlation IDs und geschwärzte Argumente, soweit die Richtlinie es erlaubt. Chat-Blasen sind eine Darstellung. Ereignisse sind das System of Record für den Support. Ohne Speicherung kannst du eine Sitzung nicht rekonstruieren, nachdem der Websocket gestorben ist. Abbildung 1 zeigt diesen Vertrag als drei Aufgaben.

3. MCP-Wissenssuchen getrennt zählen

Eine Wissenssuche ist ein anderes Risiko und eine andere Support-Frage als "Rechner ausgeführt" oder "CSV exportiert". Trenne Zähler und Filter. Sorgfältige Nutzer fragen, welcher Korpus getroffen wurde. Wer alles als "Tools" bündelt, versteckt die Antwort. Abbildung 2 macht die Trennung sichtbar.

Abbildung 2. Eine Wissenssuche ist nicht einfach ein weiteres Tool. Getrennte Zähler beantworten Fragen zum Korpus. Ein einziger Tool-Topf macht Audits zum Theater.

4. Eine Debug-Schublade auf Foundry + App Insights ausliefern

Gib internen Nutzern (und sorgfältig geschützten Support-Rollen) eine Schublade, die die Spans der Plattform neben den normalisierten Ereignissen zeigt. Die End-to-End-Transaktionsansichten in App Insights werden nutzbar, wenn du Operation IDs durch Shell und API weiterreichst. Bei Enterprise-Agents ist das kein optionaler Feinschliff. Abbildung 3 zeigt die Naht.

Abbildung 3. Eine Operation ID über Shell, API, Foundry und App Insights hinweg. Ohne diese Naht bekommst du drei Inseln und drei Wahrheiten.

5. Nachvollziehbarkeit zu einem Punkt der schriftlichen Richtlinie machen

Schreib auf, was du aufbewahrst, wie lange, wer rohe Traces sehen darf und wie die Schwärzung funktioniert. Wenn das Produkt "fundiert mit Zitaten" verspricht, muss die Betriebsgeschichte auch "wir können zeigen, welche Suche lief" enthalten. Sonst werden Audits zum Theater.

6. In Tests bewusst abgleichen

Automatisierte Tests sollten sicherstellen, dass eine geskriptete Tool-Sitzung passende Aggregate in der UI und passende Zahlen gespeicherter Ereignisse erzeugt. Mach einen Snapshot der Form der Zeitleiste. Fang Abweichungen ab, wenn jemand einen Tool-Pfad hinzufügt, der vergisst, Ereignisse zu senden.

Schwärzung gegenüber Nutzen

Gespeicherte Tool-Argumente helfen beim Debuggen und schaffen ein Risiko für Datenabfluss. Schwärze standardmäßig Freitext und Geheimnisse. Behalte Tool-Namen, Status, Zeiten und Korpus-Kennungen, soweit die Richtlinie es erlaubt. Dokumentiere das Schwärzungsprofil neben dem Ereignisschema. Der Support sollte wissen, was er nicht sehen wird, bevor er ein Ticket in Erwartung einer vollständigen Prompt-Wiedergabe öffnet.

Was der Support in fünf Minuten beantworten können sollte

Welche Wissenssuchen liefen, mit welchem Korpus-Hinweis und welchem Status? Welche allgemeinen Tools liefen? Passen die Chips in der UI zu den gespeicherten Ereignissen dieser Runde? Können wir die korrelierte Transaktion in App Insights öffnen? Wenn eine Antwort verlangt, drei unverbundene Systeme zu lesen und zu raten, ist das Produkt noch nicht betriebsfähig. Bau Schublade und Schema, bis diese Antworten langweilig sind.

Wenn ein neues Tool dazukommt, enthält die PR-Checkliste das Senden der Ereignisse, die Projektion in der UI und einen Abgleichstest. Tools, die die Checkliste überspringen, erzeugen die ursprüngliche Lüge im neuen Kostüm.

Jede Person im Team sollte das Ereignisschema lesen können, ohne vorher die Foundry-Konsole zu lernen.

Häufige Fehler

Optimistische Zähler in der UI. Spinner zählen hoch, Fehler zählen nicht herunter.

Nur Blasen. Kein Ereignisspeicher, der Support liest Screenshots.

Ein einziger "Tools"-Topf. Fragen zum Zugriff auf Wissen werden unbeantwortbar. Abbildung 2 macht diesen Fehler sichtbar.

Traces ohne Correlation IDs. Inseln in App Insights, Inseln in Foundry, Inseln in der UI. Abbildung 3 zeigt die Naht, die das verhindert.

Die Debug-Schublade als Nachgedanke. Während eines Ausfalls gebaut, nie gepflegt.

Auditierbarkeit versprechen, ohne die Aufbewahrung zu entwerfen. Prüfer fragen, das Engineering zuckt mit den Schultern.

So übernehmen oder anpassen

So übernehmen

• Ein normalisiertes Schema von Aktivitätsereignissen, gespeichert pro Gesprächsrunde.
• Aggregate in der UI sind ausschließlich Projektionen dieses Schemas.
• MCP-Wissenssuchen werden getrennt von allgemeinen Tools gezählt und gekennzeichnet.
• Correlation IDs nähen Shell, API, Foundry und App Insights zusammen.
• Eine Debug-Schublade für den Support mit Rollenschutz.
• Eine schriftliche Richtlinie für Aufbewahrung, Schwärzung und Audit-Zugriff.

Vor dem Einsatz anpassen

Normalisierte Ereignisse zu speichern kostet Speicher und einen Entwurf für die Schwärzung. Dafür bekommst du Tempo bei Incidents und Vertrauen. Getrennte Zähler für Wissen machen die UX komplexer. Sie entsprechen aber der Art, wie Menschen über Risiko denken. Debug-Schubladen brauchen Zugriffskontrolle, damit sie nicht selbst zum Datenleck werden. Abgleichstests verlangsamen PR-Zyklen ein wenig und verhindern stille Lügen der Zähler. Ihr werdet darüber streiten, wie ausführlich Argumente gegenüber der Debugbarkeit geschwärzt werden. Schreib die Richtlinie einmal.

Wichtigste Quellen: Microsoft Learn zur Korrelation in Application Insights und die Doku zu Tracing und Observability in Microsoft Foundry für deine Stack-Version. Ergänze sie um ein schriftliches Ereignisschema im Repo.

Speichere die Zeitleiste. Gleiche die Zähler ab. Trenne die Wissenssuchen. Wenn du die Tool-Aufrufe nicht erklären kannst, verschieb den Start und bau das Observability-Produkt, das du schon versprochen hast.