Microsoft Foundry Agents evaluieren, absichern und überwachen

Einen Microsoft Foundry Agent evaluieren heißt, Antwortqualität, Werkzeugverhalten, Sicherheit und Betrieb gemeinsam zu prüfen. Eine gute Antwort in wenigen Demonstrationsfragen reicht nicht. Produktionsreife verlangt repräsentative Datensätze, messbare Freigabegrenzen und Signale, die Fehler im laufenden Betrieb sichtbar machen.

Der Ratgeber verbindet Offline-Evaluation, Tracing mit OpenTelemetry, Application Insights, Content Safety und Red Teaming zu einem Betriebsmodell. Er zeigt außerdem, wann ein Deployment gestoppt oder auf eine bekannte Version zurückgesetzt werden muss.

Microsoft Foundry Agent evaluieren: Qualitätsvertrag festlegen

Vor den Metriken steht ein Qualitätsvertrag. Er beschreibt, welche Aufgaben der Agent erledigt, welche Fehler tolerierbar sind und welche Ereignisse als kritisch gelten. Fachbereich, Produktverantwortung, IT und Informationssicherheit müssen dieselben Grenzen verstehen. Sonst optimiert jedes Team auf andere Ziele.

Der Vertrag unterscheidet Antwortqualität, Quellenbezug, Toolausführung, Zugriffsschutz, Sicherheit und Nutzererlebnis. Für jede Dimension werden Prüfmethode, Mindestwert und Eskalation festgelegt. Harte Regeln wie „keine Aktion ohne erforderliche Freigabe“ dürfen nicht in einem Durchschnittswert verschwinden.

Evaluationsdaten aus realen Aufgaben ableiten

Ein brauchbarer Datensatz enthält typische, seltene, schwierige und unzulässige Anfragen. Er deckt verschiedene Formulierungen, Sprachen, Dokumenttypen und Benutzerrollen ab. Produktionsdaten dürfen nur unter geklärten Datenschutz- und Aufbewahrungsregeln verwendet werden; häufig sind bereinigte oder synthetisch ergänzte Fälle sinnvoll.

Jeder Fall enthält Eingabe, relevanten Kontext, erwartetes Verhalten und Bewertungskriterien. Bei Wissensfragen können Referenzquellen hinterlegt werden, bei Aktionen erwartete Toolparameter und Statusänderungen. Version und Herkunft des Datensatzes bleiben nachvollziehbar.

Rubriken statt vager Schulnoten verwenden

Eine Rubrik beschreibt, was eine Bewertung konkret bedeutet. Fachliche Richtigkeit, Vollständigkeit, Belegtreue und Verständlichkeit werden getrennt beurteilt. Für Toolaufrufe zählen Auswahl, Parameter, Reihenfolge, Berechtigung und Ergebnisbehandlung. Dadurch wird aus „wirkt gut“ eine wiederholbare Prüfung.

Automatische Evaluatoren können große Varianten vergleichen, bringen aber eigene Unsicherheit mit. Ein fachlich kuratierter Teil wird regelmäßig von Menschen bewertet und dient als Kontrollpunkt. Abweichungen zwischen automatischer und manueller Bewertung werden untersucht, statt den bequemeren Wert zu wählen.

Retrieval und Antwort getrennt bewerten

Bei RAG-Anwendungen kann eine falsche Antwort aus fehlenden Treffern oder aus einer schlechten Verarbeitung guter Treffer entstehen. Retrieval-Metriken prüfen, ob erwartete Quellen gefunden und hoch genug gerankt werden. Antwortmetriken prüfen, ob die Ausgabe durch den bereitgestellten Kontext gedeckt ist.

Diese Trennung verkürzt die Diagnose. Ein Promptwechsel löst keinen unvollständigen Index, und ein größeres Modell ersetzt keine Berechtigungsfilter. Der Beitrag zu Microsoft Foundry RAG beschreibt Datenaufnahme, Suchschicht und Quellenbezug im Detail.

Toolaufrufe als Transaktion testen

Ein Agent kann sprachlich korrekt wirken und trotzdem das falsche Werkzeug oder fehlerhafte Parameter verwenden. Tests prüfen positive Abläufe, Validierungsfehler, Zeitüberschreitungen, doppelte Aufrufe und nicht verfügbare Abhängigkeiten. Schreibende Aktionen benötigen zusätzlich Genehmigungs- und Wiederholungstests.

Der erwartete Geschäftszustand zählt mehr als die formulierte Antwort. Meldet der Agent Erfolg, obwohl die API abgebrochen hat, ist der Test fehlgeschlagen. Idempotenzschlüssel, Statusabfragen und strukturierte Fehler verhindern doppelte oder verdeckte Änderungen.

Berechtigungs- und Mandantengrenzen prüfen

Testidentitäten mit unterschiedlichen Rollen stellen sicher, dass Retrieval und Tools nur erlaubte Daten liefern. Negative Tests versuchen bewusst, fremde Datensätze, verborgene Felder oder administrative Funktionen zu erreichen. Auch indirekte Hinweise in Fehlermeldungen und Quellenangaben werden berücksichtigt.

Die Prüfungen laufen nach Änderungen an Identität, Tool, Index oder Gruppenmodell erneut. Ein einmal bestandener Test bleibt nicht dauerhaft gültig. Der Aufbau eines Foundry-Agenten sollte deshalb Berechtigungsmodell und Toolgrenzen als versionierte Architekturentscheidungen dokumentieren.

Prompt Injection und manipulierte Quellen testen

Red-Teaming-Datensätze enthalten Anweisungen in Dokumenten, verschleierte Aufforderungen, Rollenwechsel, Datenabflussversuche und überlange Eingaben. Ziel ist nicht nur eine sichere Textantwort. Entscheidend ist, dass der Agent keine erweiterten Tools aufruft und keine vertraulichen Inhalte in andere Kanäle überträgt.

Schutzmaßnahmen liegen auf mehreren Ebenen: minimale Rechte, vertrauenswürdige Toolschemas, Trennung von Anweisung und Daten, Eingabe- und Ausgabekontrollen sowie menschliche Freigaben. Ein Prompt allein ist keine Sicherheitsgrenze. Gefundene Angriffe werden als dauerhafte Regressionstests aufgenommen.

Content Safety risikobasiert konfigurieren

Inhaltsfilter und Sicherheitsdienste können schädliche Ein- oder Ausgaben erkennen. Schwellenwerte müssen zum Anwendungsfall passen. Ein interner Arbeitsschutz-Agent verarbeitet andere Begriffe als ein öffentlicher Supportagent. Zu strenge Filter blockieren legitime Aufgaben, zu lockere Filter lassen Risiken durch.

Blockierungen werden mit Kategorie und Version messbar gemacht, ohne unnötig sensible Inhalte zu speichern. Fachlich zulässige Ausnahmen benötigen einen dokumentierten Prozess. Änderungen an Filtern werden mit demselben Referenzdatensatz geprüft wie Modell- oder Promptänderungen.

Tracing mit OpenTelemetry strukturieren

Ein Trace verbindet Eingangsanfrage, Agentenschritte, Modellaufrufe, Retrieval und Tools. OpenTelemetry bietet dafür ein herstellerübergreifendes Modell aus Traces, Metriken und Logs. Eine Korrelations-ID ermöglicht die Rekonstruktion eines Fehlers über mehrere Dienste hinweg.

Spans sollten Dauer, Status, Modell- und Toolversion sowie Verbrauch enthalten. Vollständige Prompts, Dokumente oder Toolantworten gehören nicht automatisch in Telemetrie. Erfassungsumfang, Maskierung und Zugriff werden anhand von Diagnosebedarf, Datenschutz und Aufbewahrungsziel festgelegt.

Application Insights als Betriebsansicht nutzen

Application Insights kann Telemetrie aufnehmen, Abhängigkeiten darstellen und Abfragen sowie Warnungen ermöglichen. Relevante Ansichten zeigen End-to-End-Latenz, Fehlerquoten, Tokenverbrauch, Toolabbrüche und betroffene Versionen. Ein Dashboard pro Team ohne gemeinsame Definition erschwert den Vergleich.

Technische Signale werden mit fachlichen Ergebnissen verbunden. Dazu gehören erfolgreiche Fallabschlüsse, Übergaben an Menschen oder korrigierte Antworten. Steigt die Latenz bei gleichbleibender Qualität, ist die Reaktion eine andere als bei zunehmenden Berechtigungsfehlern.

Online-Monitoring erkennt Drift und Ausreißer

Offline-Tests prüfen bekannte Fälle; im Betrieb treten neue Formulierungen, Datenänderungen und Lastmuster auf. Stichproben und datensparsame Qualitätsindikatoren zeigen, ob Antworten schlechter werden. Häufige Rückfragen, leere Retrieval-Ergebnisse oder unerwartete Toolfolgen sind frühe Warnsignale.

Produktionsfälle werden nach festem Verfahren in den Evaluationsdatensatz übernommen. Dabei werden personenbezogene Daten entfernt und fachliche Referenzen ergänzt. Dieser Kreislauf verhindert, dass Tests dauerhaft nur die ursprüngliche Pilotwelt abbilden.

Schwellenwerte und Alarme handlungsfähig machen

Ein Alarm benötigt Signal, Grenzwert, Zeitraum, Empfänger und Maßnahme. Beispiele sind ein starker Anstieg fehlgeschlagener Toolaufrufe, ungewöhnlicher Tokenverbrauch oder ein kritischer Sicherheitsverstoß. Warn- und Abschaltschwellen werden getrennt definiert.

Jeder Alarm erhält ein Runbook. Es nennt erste Prüfungen, Verantwortliche, Kommunikationsweg und Entscheidungskompetenz. Alarmmüdigkeit wird durch abgestufte Schweregrade, Deduplizierung und regelmäßige Überprüfung begrenzt. Nicht bearbeitete Warnungen sind ein Betriebsdefekt.

Änderungen über eine Evaluationsschranke führen

Prompt, Modell, Tool, Index, Filter und Laufzeit können Verhalten verändern. Jede relevante Änderung erzeugt eine neue, eindeutig benannte Version und durchläuft automatisierte sowie fachliche Tests. Ein Vergleich gegen die aktive Produktion zeigt Verbesserung und Regressionen.

Freigaben basieren auf definierten Schwellenwerten. Ein günstigeres Modell darf nicht live gehen, wenn kritische Toolfehler zunehmen. Umgekehrt rechtfertigt eine kleine stilistische Verbesserung keine deutlich höhere Latenz. Der Entscheid wird mit Messwerten und verantwortlicher Freigabe dokumentiert.

Rollback technisch und organisatorisch vorbereiten

Ein Rollback setzt voraus, dass vorherige Modell-, Prompt-, Tool- und Konfigurationsversionen bekannt und deploybar bleiben. Daten- oder Schemaänderungen brauchen Kompatibilitätsregeln. Bei schreibenden Tools kann zusätzlich eine fachliche Korrektur bereits ausgeführter Aktionen erforderlich sein.

Der Rückfallweg wird geprobt: Umschaltung auf eine bekannte Version, read-only Betrieb, Deaktivierung einzelner Tools oder Übergabe an Menschen. Die Übung zeigt, ob Monitoring, Berechtigungen und Kommunikation tatsächlich funktionieren. Ein theoretischer Schalter ohne Test ist kein belastbarer Notfallplan.

Incident-Lernen in die Produktentwicklung zurückführen

Nach einem Vorfall werden Ursache, Reichweite, betroffene Versionen und getroffene Maßnahmen dokumentiert. Der Fokus liegt auf Systemverbesserung: neuer Regressionstest, engere Berechtigung, robustere Toolvalidierung oder besserer Alarm. Reine Promptkorrekturen greifen bei Architekturfehlern oft zu kurz.

Eine produktionsreife Agentenplattform verbindet Evaluation mit der Skalierung der KI-Transformation. Gemeinsame Rubriken, Telemetriestandards und Freigabeprozesse senken Aufwand für weitere Anwendungsfälle. Gleichzeitig behält jeder Agent seine fachlich spezifischen Risikogrenzen.

Der kontrollierte Weg in den Betrieb

Vor dem Go-live sind Datensatz, Mindestwerte, Sicherheitsprüfungen, Dashboards, Alarme, Runbooks, Eigentümer und Rückfallweg vollständig. Eine begrenzte Nutzergruppe und enges Monitoring reduzieren die Auswirkung unbekannter Fehler. Die Ausweitung erfolgt erst, wenn technische und fachliche Signale stabil sind.

Evaluation ist damit kein einmaliger Testschritt. Sie bildet den Regelkreis für jede Änderung und jeden Vorfall. Ein Foundry-Agent bleibt beherrschbar, wenn Qualität messbar, Verhalten nachvollziehbar und eine sichere Reaktion jederzeit möglich ist.

Serviceziele für agentische Abläufe definieren

Ein Serviceziel kann erfolgreiche Vorgänge, maximale End-to-End-Latenz, zulässige Toolfehler und Anteil unbelegter Antworten kombinieren. Für kritische Sicherheitsereignisse gilt eine Nulltoleranz statt eines Durchschnitts. Ziele werden nach Fragetyp oder Prozessrisiko differenziert.

Die Messung berücksichtigt mehrstufige Abläufe. Ein schneller Modellaufruf hilft nicht, wenn das nachgelagerte Tool regelmäßig abbricht. Fachliche und technische Ziele erscheinen in derselben Betriebsansicht und führen zu eindeutig benannten Maßnahmen.

Regelmäßige Betriebsreviews etablieren

Wöchentlich werden auffällige Fehler, Kosten und Alarme geprüft; monatlich folgen Qualitätsstichproben, Modelländerungen und offene Risiken. In einem größeren Abstand werden Datensätze, Rubriken, Aufbewahrung und Eigentümer überprüft. Die Frequenz richtet sich nach Kritikalität und Änderungsrate.

Der Review endet mit Entscheidungen: Testfall ergänzen, Schwelle anpassen, Tool verbessern, Rechte reduzieren oder Version zurücksetzen. Protokollierte Entscheidungen schaffen Nachvollziehbarkeit und verhindern, dass bekannte Qualitätsprobleme dauerhaft als unvermeidbar gelten.

Datenschutz und Zugriff auf Evaluationsdaten regeln

Evaluationsdatensätze, Traces und Transkripte können vertrauliche Eingaben, Modellantworten und Toolresultate enthalten. Für jedes Artefakt werden Zweck, zulässige Felder, Maskierung, Zugriff, Speicherort und Aufbewahrungszeit festgelegt. Entwickler benötigen nicht automatisch Einblick in vollständige Produktionsgespräche. Für viele Diagnosen reichen Metadaten, IDs und gezielt freigegebene Stichproben.

Der Zugriff wird protokolliert und regelmäßig überprüft. Fälle für Regressionstests werden vor der dauerhaften Aufnahme bereinigt oder synthetisch nachgebildet. Bei Lösch- und Auskunftsprozessen muss bekannt sein, welche Systeme Kopien halten. Diese Regeln schützen Betroffene und verbessern zugleich die Datenqualität: Ein kuratierter Evaluationssatz ist reproduzierbarer als ein unkontrolliertes Archiv sämtlicher Unterhaltungen.