Steuerung, Beobachtbarkeit und Bewertung von KI-Agenten-Flotten (AgentOps)

Sobald Dutzende oder Hunderte Agenten im Auftrag von Mitarbeitenden und Abteilungen handeln, lautet die Frage nicht mehr „Funktioniert dieser Prompt?“, sondern: „Welche Agenten gibt es, wem gehören sie, was dürfen sie berühren, was haben sie getan, sind sie noch gut – und wie stoppen wir einen?“ AgentOps vereint Agentenregister, Agentenidentität, Tracing, laufende Bewertung, Freigaberichtlinien und einen Notaus-Schalter zu einer Betriebsschicht und liefert die Nachweise für Audits und die KI-Verordnung (AI Act).

Problem & Nutzen

• Heute: Agenten entstehen überall: Copiloten, die Fachanwender selbst bauen, in CRM/ITSM/ERP eingebettete Agenten der Hersteller, von Entwicklern gebaute LangGraph- oder Eigenentwicklungs-Dienste, Coding-Agenten und „Schatten-Agenten“, die ohne Wissen der IT entstehen. Typische Lücken: kein Inventar, Agenten laufen unter den gemeinsamen Zugangsdaten eines Menschen oder mit langlebigen API-Schlüsseln, keine Nachvollziehbarkeit, was ein Agent über mehrere Werkzeuge hinweg getan hat, Qualität, die nach einem Modell- oder Prompt-Wechsel unbemerkt nachlässt, sowie ausufernde Token-Kosten.
• Nutzen durch KI/Werkzeuge: ein einheitliches Inventar und eine Risikosicht; Identität pro Agent mit minimalen Rechten; reproduzierbare Traces für die Vorfallanalyse; Regressionsprüfungen vor der Freigabe; Kosten- und Drift-Warnungen; dokumentierte menschliche Aufsicht. Aussagen von Analysten und Herstellern zu Einsparungen schwanken stark und sind meist nicht belegt – messen Sie daher Ihre eigene Ausgangslage.
• Warum jetzt: Microsoft hat Agent 365 am 1. Mai 2026 allgemein verfügbar gemacht (Register im Microsoft 365 Admin Center, mit Entra- und Purview-Integration) [1]. Die Beobachtbarkeit hat sich auf die OpenTelemetry-GenAI-Semantik-Konventionen mit den Operationen invoke_agent / create_agent vereinheitlicht [2]. Die Anforderungen der KI-Verordnung an Protokollierung und Aufsicht bei Hochrisiko-Systemen (Art. 12, 14, 26) machen „Nachweis pro Aktion“ zu einem Beschaffungskriterium [3].

Varianten

• Unternehmens-IT / Plattformteam: zentrales Register und zentrale Richtlinien für Hersteller- und Eigen-Agenten (M365, Salesforce, ServiceNow, Cloud-Plattformen).
• Entwickler- / Produktteam: Tracing sowie Offline- und Online-Bewertungen für selbst gebaute Agenten (überschneidet sich mit CODE-018, das sich auf die Bewertung von LLM-Anwendungen konzentriert).
• Öffentlicher Sektor: Verzeichnis automatisierter Verfahren, Dokumentation der menschlichen Aufsicht, souveränes Hosting, Transparenz gegenüber Bürgerinnen und Bürgern.
• Regulierte Branchen (Bank, Versicherung, Gesundheit): Anbindung an das Modellrisikomanagement, Vier-Augen-Freigabe für folgenreiche Aktionen, Aufbewahrung von Protokollen für die Aufsichtsprüfung.
• Agent-zu-Agent / Multi-Hersteller: Steuerung über Agenten hinweg, die sich gegenseitig über MCP oder A2A aufrufen (siehe AGENT-013).

So funktioniert es

1. Erkennung (Plattform-APIs, IdP, Code-Repositories, Netzwerk-/Gateway-Logs, MCP-Server-Inventar)
2. Register (Verantwortlicher, Zweck, Datenklassen, Modell, Werkzeuge, Risikoklasse, Lebenszyklusstatus)
3. Identität & Zugriff (eigene Agentenidentität, kurzlebige Token mit begrenztem Umfang, Berechtigungen je Werkzeug)
4. Gateway / Richtliniendurchsetzung (Positivlisten, Raten- und Ausgabenlimits, Freigabeschranken, PII-Filter)
5. Laufzeit-Tracing (OTel-Spans: Agent
6. Modell
7. Werkzeug; Ein-/Ausgaben mit Schwärzung)
8. Bewertung (Offline-Regressionssätze, Online-Stichproben, LLM-as-Judge, menschliche Prüfung, Drift-/Kostenwarnungen)
9. Reaktion (Warnung, Drosselung, Quarantäne, Notaus-Schalter, Rollback der Prompt-/Modellversion)
10. Nachweis (unveränderliche Logs, Aufsichtsprotokolle, Berichte für Datenschutzbeauftragte, Prüfer, Aufsichtsbehörden)

• Register und Erkennung: erfasst Agenten aus Plattformen sowie nicht verwaltete Agenten, die über Identitäts- und Netzwerk-Telemetrie gefunden werden. Jeder Eintrag hat einen benannten menschlichen Verantwortlichen und eine Risikoklassifizierung (einschließlich der Rolle nach der KI-Verordnung: Anbieter oder Betreiber).
• Agentenidentität: Jeder Agent erhält eine eigene nicht-menschliche Identität (kein gemeinsames Dienstkonto), mit Delegation im Namen des Nutzers („On-Behalf-Of“), bei der die Nutzerrechte auf die Aufgabe beschränkt werden; Zugangsdaten sind kurzlebig. Microsoft Entra Agent ID und vergleichbare IdP-Funktionen decken das ab [1].
• Tracing: Jeder Modellaufruf, jede Abfrage (Retrieval) und jeder Werkzeugaufruf ist ein Span, der mit einer Sitzung und einem verantwortlichen Menschen oder Prozess verknüpft ist. Die Inhaltserfassung ist konfigurierbar, weil Prompts oft personenbezogene Daten enthalten.
• Bewertung: Kennzahlen zum Aufgabenerfolg gegen Referenzdatensätze (Golden Datasets), Prüfungen des Ablaufs (richtige Werkzeuge, richtige Reihenfolge, keine verbotenen Aktionen), LLM-as-Judge für offene Ausgaben, kalibriert an menschlichen Bewertungen, dazu Budgets für Kosten und Latenz. Läuft als Prüfschritt in der CI und laufend auf Stichproben des Produktivverkehrs.
• Mensch-in-der-Schleife (Human-in-the-Loop)-Punkte: Freigaberichtlinien je Aktionsklasse (z. B. Zahlungen, externe E-Mails, Löschungen, Zugriffsänderungen); regelmäßige Rezertifizierung der Verantwortlichen; eine benannte Person, die den Notaus-Schalter auslösen darf; menschliche Prüfung markierter Bewertungsfehler.

Datenaufbereitung

Die „Daten“ sind hier überwiegend Telemetrie und Metadaten, keine Geschäftsdaten; der Aufbereitungsaufwand ist daher gering. Agentendefinitionen liegen in den Plattformen und Frameworks, die sie betreiben (Copilot Studio, Agentforce, Eigenentwicklung), Berechtigungen im Identitätsanbieter und im IAM, Kosten in der Cloud-Abrechnung und Richtlinien in PDFs oder Wikis. Typische Lücken: unbekannte oder Schatten-Agenten, die niemand registriert hat, fehlende Verantwortliche, uneinheitliche Trace-Formate zwischen Frameworks, Traces mit personenbezogenen Daten ohne Löschregel und kein Bewertungsdatensatz für die Aufgabe des Agenten.

Konkrete Schritte: zuerst ein Inventar aller Agenten und ihrer Werkzeugbereiche aufbauen ([PREP-001]), jedem Agenten einen benannten Verantwortlichen zuweisen, auf Traces im OpenTelemetry-Stil vereinheitlichen, Datenklassen festlegen und definieren, was in Protokollen erscheinen darf ([PREP-024]), und je Agent 30 bis 100 reale Beispiele als Bewertungsdatensatz sammeln ([PREP-018]). Personenbezogene Daten in gespeicherten Traces maskieren oder pseudonymisieren ([PREP-022]). Werkzeuge: Langfuse, OpenTelemetry-Collectors, das App-Register des IdP, Tabellenkalkulationen für das erste Register.

Grober Aufwandsanteil: etwa 10 bis 15 Prozent des Projekts; der meiste Aufwand entfällt auf Richtlinien, Zuständigkeiten und Integration.

Umsetzungswege

Welcher Weg für wen

• Unternehmen: A. Plattformeigene Governance- und Observability-Produkte sind ausgereifte Standardfunktionen und fügen sich in den bereits vorhandenen Identitäts- und Cloud-Stack ein.
• Entwickler: C. Open-Source-Tracing und -Bewertung (z. B. Langfuse, OpenTelemetry) sind günstig im Betrieb und halten Traces mit Prompts und personenbezogenen Daten unter Ihrer Kontrolle.
• Öffentlicher Sektor: C. Agenten-Traces enthalten Bürgerdaten; der Selbstbetrieb in einer souveränen EU- oder deutschen Cloud lässt sich in der Beschaffung leichter begründen als eine US-SaaS-Konsole.

Weg A — Kaufen (Standardsoftware) (für die meisten Unternehmen empfohlen)

• Plattformeigene Governance: Microsoft Agent 365 (Register, Entra, Purview, Defender; eigenständige Lizenz oder im Paket Microsoft 365 E7, berichtete Preise bitte bei Microsoft prüfen) [1]; Salesforce Agentforce Command Center für Agentforce-Agenten; ServiceNow AI Control Tower; Agentenplattform-Konsolen von Google und AWS. Stark innerhalb des eigenen Ökosystems; die Synchronisation über mehrere Clouds hinweg war laut Microsoft-Roadmap noch in der Vorschau – prüfen Sie dies, bevor Sie sich darauf verlassen.
• Anbieter für Observability und Bewertung: LangSmith, Arize, Datadog LLM Observability, Weights & Biases Weave, Braintrust; Langfuse (in Berlin gegründet, EU-Cloud-Region, EU/Open Source) [4].
• KI-Governance-Plattformen (Register, Risikobewertung, Compliance-Workflows): z. B. Credo AI, IBM watsonx.governance, OneTrust sowie EU-Anbieter wie mit appliedAI verbundene und deutsche/französische GRC-Anbieter; prüfen Sie die Abbildung auf die KI-Verordnung und das EU-Hosting.
• A wählen, wenn: die meisten Agenten auf einer oder zwei Plattformen laufen und eine schnelle Audit-Geschichte wichtiger ist als Flexibilität.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Agenten mit den OpenTelemetry-GenAI-Konventionen instrumentieren [2] und Spans an ein vorhandenes Backend (Grafana, Elastic, Azure Monitor, Datadog) oder ein LLM-spezifisches senden.
• Ein LLM-/Agenten-Gateway vor den Modell- und Werkzeugzugriff schalten (LiteLLM, Portkey, Kong AI Gateway, Azure API Management) für Schlüssel, Budgets, Protokollierung und Richtlinien; MCP-Gateways für Werkzeug-Allowlists nutzen.
• Identität über den vorhandenen IdP (Entra, Okta, Keycloak) mit Workload-Identität und Token-Austausch.
• Bewertungsmodelle (Judge) über APIs in EU-Regionen (Azure OpenAI EU, Vertex EU, Bedrock Frankfurt, Mistral) mit einer anderen Modellfamilie als der des Agenten, um die Selbstbevorzugung zu verringern.
• B wählen, wenn: heterogener Agentenbestand, starkes Plattformteam, Bedarf an eigenen Freigabe-Workflows.

Weg C — Selbst betreiben (Open Source)

• Langfuse (MIT-Kern, Selbstbetrieb mit Docker/Kubernetes, OTel-Ingest, Datensätze, LLM-as-Judge) [4]; Arize Phoenix; OpenLIT; Opik; MLflow Tracing; OpenLLMetry.
• Bewertung: promptfoo, DeepEval, Ragas, Inspect AI, lm-evaluation-harness für Regressionstests.
• Richtlinien und Guardrails: Open Policy Agent für Autorisierungsentscheidungen, NeMo Guardrails, Klassifikatoren wie Llama Guard / Granite Guardian (siehe SEC-010).
• Bewertungsmodelle (Judge): Open-Weight-Modelle wie Qwen3, Llama, Mistral oder gpt-oss-Klasse, betrieben mit vLLM.
• Hardware: Der Telemetrie-Stack läuft auf CPU-Servern (HW1); ein selbst betriebenes Judge-Modell für größere Mengen braucht HW2–HW3.
• Betriebsaufwand: erheblich; der Speicher für Traces (bei Langfuse ClickHouse-basiert) wächst schnell.

Weg D — Eigenes Training

Selten. Erwägenswert: ein feinabgestimmtes kleines Judge- oder Klassifikationsmodell für fachspezifische Qualitätskriterien (trainiert mit einigen Hundert bis Tausenden von Menschen bewerteter Traces) sowie Anomalieerkennung auf Werkzeugaufruf-Sequenzen. Die Bewertungen der Prüfer aus dem Produktivbetrieb sind die natürlichen Trainingsdaten.

Stand der Technik (2026)

• Standardisierung: Die OpenTelemetry-GenAI-Semantik-Konventionen definieren Spans für Agenten, Modelle und Werkzeuge; viele Frameworks und Anbieter geben sie inzwischen aus, doch Attributnamen haben sich zwischen Versionen geändert (z. B. wurde gen_ai.system zu gen_ai.provider.name) – legen Sie daher Versionen fest [2].
• Register als Produktkategorie: Hyperscaler und SaaS-Anbieter liefern Agentenregister aus; die herstellerübergreifende Erkennung nicht verwalteter Agenten ist weiterhin der schwächste Teil und stützt sich auf Identitäts-, Netzwerk- und Repository-Signale.
• Agentenidentität: Eigene nicht-menschliche Identitäten, Token-Austausch und On-Behalf-Of-Abläufe lösen gemeinsame API-Schlüssel ab; die Standardisierungsarbeit (OAuth-Profile für MCP und Agenten) läuft noch.
• Bewertung: Bewertungen auf Ablauf- und Ergebnisebene, Simulation von Nutzern und Werkzeugen sowie LLM-as-Judge mit Kalibrierung sind Standard; Agenten-Benchmarks (z. B. tau-bench, SWE-bench Verified, WebArena/OSWorld für Computernutzung) helfen bei der Modellwahl, ersetzen aber keine eigenen Bewertungen.
• Grenzen und Fehlerbilder: LLM-Judges sind verzerrt (Ausführlichkeit, Selbstbevorzugung, Position) und driften mit Updates des Judge-Modells; Traces mit vollständigen Prompts werden zu einem Speicher für personenbezogene Daten und Geheimnisse; Nichtdeterminismus macht Regressionsschwellen statistisch; Notaus-Schalter wirken nur, wenn die Zugangsdaten des Agenten tatsächlich widerrufbar sind und nachgelagerte Nebenwirkungen ausgeglichen werden können; Plattform-Governance deckt Sichtbarkeit, Zugriff und Richtlinien ab, nicht die fachliche Richtigkeit; „Governance“-Versprechen der Anbieter enden oft am Rand des eigenen Ökosystems.

Gemeinsame Bausteine & Kombinationen

• SEC-010: Laufzeit-Guardrails und Schutz vor Prompt-Injection werden hier von der Richtlinienschicht durchgesetzt; AgentOps liefert Register, Identität und Nachweise.
• CODE-018: Derselbe Tracing-/Bewertungs-Stack (Langfuse, LangSmith, Phoenix) dient der Bewertung von LLM-Anwendungen.
• AGENT-002 / AGENT-013 / AGENT-003: die Agenten, die gesteuert werden; AGENT-003 (Computer-Use-Agenten) braucht die strengsten Freigaben und Sitzungsaufzeichnung.
• AGENT-018: Die laufende Kontrollüberwachung nutzt dieselben Protokolle; AGENT-016: ITSM-Tickets führen Zugriffsanfragen und Vorfälle für Agenten.
• Gemeinsame Infrastruktur: IdP, Gateway, SIEM, Log-Speicher (HW1), Betrieb der Judge-Modelle (HW2–HW3).

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für ein erstes Register und Richtlinien innerhalb einer Plattform; Lizenz pro Nutzer oder pro Agent/Nachricht, plus Integration mit SIEM und GRC.
• Weg B: 3–6 Monate für Gateway, Tracing, Identität und Freigabeabläufe; Kostentreiber sind Trace-Speicher, Token des Judge-Modells (Bewerten kann so viel kosten wie der Betrieb) und die Zeit des Plattformteams.
• Weg C: ähnlicher Aufwand plus Betrieb des Stacks.
• Kennzahlen: Anteil der Agenten, die mit Verantwortlichem und Risikoklasse registriert sind; Anteil entdeckter vs. bereinigter Schatten-Agenten; Anteil der Agenten mit eigener Identität und Prüfung der minimalen Rechte in den letzten 12 Monaten; Aufgabenerfolgsquote und Bestehensquote der Regressionsprüfung; Kosten pro erfolgreicher Aufgabe; mittlere Zeit bis zur Erkennung und zum Stoppen eines fehlerhaft arbeitenden Agenten; Anteil folgenreicher Aktionen mit protokollierter menschlicher Freigabe; Vorfälle pro 1.000 Läufe.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsleitung und der bzw. dem IT-Sicherheitsbeauftragten: Sie legen die Agenten-Richtlinie fest (wer welchen Agenten mit welchen Berechtigungen einsetzen darf), bevor Werkzeuge ausgewählt werden (GUIDE-007, GUIDE-013). Beziehen Sie die IT für Identität, Protokollierung und Integration ein, die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten für Protokollinhalte, Aufbewahrung und eine Datenschutz-Folgenabschätzung (DSFA), wo Traces personenbezogene Daten enthalten (GUIDE-005), sowie Recht/Compliance für die Nachweise nach der KI-Verordnung (Art. 12, 14, 26; GUIDE-014).

Betriebsrat: in der Praxis ja. Traces und Audit-Logs halten fest, wer welche Agentenaktion ausgelöst hat; das System ist damit objektiv geeignet, Verhalten und Leistung der Beschäftigten zu überwachen (§ 87 Abs. 1 Nr. 6 BetrVG, BAG-Rechtsprechung). Informieren Sie den Betriebsrat frühzeitig nach § 90 Abs. 1 Nr. 3, ziehen Sie einen Sachverständigen nach § 80 Abs. 3 in Betracht und vereinbaren Sie eine Betriebsvereinbarung, die die Auswertung einzelner Beschäftigter begrenzt (GUIDE-004). In öffentlichen Stellen gilt der Personalrat.

Starten Sie mit einem Pilot mit ein oder zwei Agenten und ihren Verantwortlichen. Typische Bedenken: Überwachung der Beschäftigten (begegnen Sie dem mit Zweckbindung und aggregierter Berichterstattung), Bürokratie, die Teams bremst (bieten Sie einen schlanken Registrierungsweg an). KI-Kompetenz: Die KI-Verordnung verlangt von Anbietern und Betreibern Maßnahmen zur Förderung der KI-Kompetenz ihres Personals; schulen Sie Agenten-Verantwortliche und Prüfer (GUIDE-006). Behalten Sie den Menschen die Kontrolle durch Freigabeschwellen und einen funktionierenden Notaus-Schalter.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Einstufung hängt davon ab, was der jeweilige Agent tut. Governance-Werkzeuge selbst haben typischerweise minimales Risiko, aber die gesteuerten Agenten können hochriskant sein (Anhang III: z. B. Beschäftigung, Kredit, wesentliche Dienste, öffentliche Leistungen). Für Hochrisiko-Systeme gelten: automatische Ereignisprotokollierung (Art. 12), menschliche Aufsicht, so gestaltet, dass Personen das System verstehen, überwachen, übersteuern und stoppen können (Art. 14), Betreiberpflichten einschließlich Aufbewahrung der Protokolle von mindestens sechs Monaten, Überwachung und Information der Beschäftigten (Art. 26) [3]. Die KI-Kompetenz nach Art. 4 gilt für alle Betreiber. Die Transparenz nach Art. 50 gilt für Agenten, die mit Menschen interagieren. Verbote nach Art. 5 (z. B. Emotionserkennung am Arbeitsplatz, manipulative Techniken, Social Scoring) müssen bei der Registrierung geprüft werden; ein Agent in einer verbotenen Kategorie muss blockiert werden, nicht nur markiert. Die Pflichten nach Anhang III gelten ab dem 2. Dez. 2027 (Digital-Omnibus zur KI, Verordnung (EU) 2026/1744, in Kraft seit 27. Juli 2026).
• DSGVO: Traces und Bewertungsdatensätze enthalten personenbezogene Daten; wenden Sie Datenminimierung, Schwärzung vor der Speicherung, Aufbewahrungsfristen und Zugriffskontrolle an, eine DSFA, wo Agenten personenbezogene Daten in großem Umfang verarbeiten, und Schutzmaßnahmen nach Art. 22, wenn Agenten ausschließlich automatisierte Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung treffen. Die Überwachung von Beschäftigten über Agentenprotokolle löst in Deutschland die Mitbestimmung des Betriebsrats aus (BetrVG § 87).
• Branchenregeln: DORA sowie EBA-/BaFin-Vorgaben zu Auslagerung und IKT-Risiko, NIS2 (Sicherheit der Agentenidentitäten), ISO/IEC 42001 für KI-Managementsysteme, NIST AI RMF als Strukturhilfe.
• Risiken und Gegenmaßnahmen: übermäßiges Vertrauen in LLM-Judges (an menschlichen Bewertungen kalibrieren); Wildwuchs sensibler Daten in Protokollen (Schwärzung, gestufte Aufbewahrung); Governance-Theater (Register ohne Durchsetzung); Werkzeug-Abhängigkeit (OTel und offene Schemata nutzen); ein Notaus-Schalter, der Aktionen nicht rückgängig machen kann (Ausgleichstransaktionen entwerfen, Schadensradius begrenzen).

Erste Schritte

1. Innerhalb von 30 Tagen ein Inventar aufbauen: Plattform-APIs, Anwendungs- und Service-Principal-Listen des IdP, Repository-Scans, MCP-/Werkzeug-Endpunkte; jedem Agenten einen menschlichen Verantwortlichen zuweisen.
2. Eine Risikotaxonomie (Datenklassen, Aktionstypen, Kategorie nach KI-Verordnung) und Freigaberegeln je Klasse festlegen; auf Art. 5 und Anhang III prüfen.
3. Agenten von gemeinsamen Zugangsdaten auf Identitäten pro Agent mit begrenzten, kurzlebigen Token umstellen; ein Gateway vor den Modell- und Werkzeugzugriff schalten.
4. Mit OpenTelemetry-GenAI-Spans instrumentieren; beginnen Sie mit geschwärzten Traces für die fünf Agenten mit dem höchsten Risiko oder den höchsten Kosten.
5. Je Agent 50–200 Referenz-Testfälle anlegen, eine Regressionsprüfung in der CI ergänzen, wöchentlich Produktiv-Traces stichprobenartig für die Judge-Kalibrierung mit menschlichen Bewertungen ziehen; den Notaus-Schalter in einer Übung erproben.

Quellen

1. Microsoft Learn — Microsoft Agent 365 overview — https://learn.microsoft.com/en-ca/microsoft-agent-365/overview
2. OpenTelemetry — Semantic conventions for GenAI agent and framework spans — https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-agent-spans
3. Regulation (EU) 2024/1689 (AI Act), Art. 12, 14, 26 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. Langfuse — open-source LLM engineering platform (self-hosting, EU cloud) — https://langfuse.com/docs
5. AI Act Service Desk / Art. 14 text — https://www.artificialintelligenceact.eu/article/14/
6. Open Policy Agent — https://www.openpolicyagent.org
7. Arize Phoenix — https://github.com/Arize-ai/phoenix
8. NIST AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework