Bildquelle: Pexels / https://www.pexels.com/photo/digital-checklist-on-tablet-with-stylus-33266834/
KI-Agenten im IT-Betrieb brauchen Freigaben, Runbooks und saubere Rückfallwege
Viele IT-Teams experimentieren gerade mit KI-Agenten, die Tickets zusammenfassen, Störungen klassifizieren, Änderungen vorbereiten oder mit Werkzeugzugriff gleich selbst Aktionen auslösen sollen. Die Verlockung ist verständlich. Sobald ein Modell nicht nur Text erzeugt, sondern Systeme lesen, schreiben oder Prozesse anstoßen kann, wirkt Automatisierung plötzlich deutlich greifbarer als bei einem reinen Chatbot. Genau an diesem Punkt kippt aber auch das Betriebsrisiko. Denn ab dann geht es nicht mehr nur um Antwortqualität, sondern um Berechtigungen, Eskalationen, Protokollierung und Rücknahmefähigkeit.
Anthropic beschreibt in seinem Beitrag zu effektiven Agenten einen einfachen, aber wichtigen Unterschied: Zwischen vordefinierten Workflows und echten Agenten, die ihre Werkzeugnutzung dynamisch selbst steuern. OpenAI beschreibt denselben Kern aus anderer Richtung über Tool Calling, also die mehrstufige Schleife aus Modellentscheidung, Funktionsaufruf, Ausführung im Anwendungscode und Rückgabe des Ergebnisses. Für den IT-Betrieb ist das entscheidend, weil damit klar wird: Das Modell handelt nie im luftleeren Raum. Es handelt über Schnittstellen, Rollen und Systeme, die jemand bewusst freigeben muss.
Wer Agenten produktiv in Support, Betrieb oder internen Serviceprozessen einsetzen will, sollte deshalb nicht zuerst nach dem leistungsfähigsten Modell fragen. Die wichtigere Frage lautet: Welche Aktionen darf dieser Agent wirklich auslösen, unter welchen Bedingungen, mit welcher menschlichen Kontrolle und welchem Fallback, wenn etwas schiefläuft?
Tool-Zugriff macht aus Assistenz operative Wirkung
Solange ein Modell nur Vorschläge macht, bleibt der Schaden meist auf Zeitverlust, Verwirrung oder schlechte Kommunikation begrenzt. Mit Tool-Zugriff ändert sich das Bild. Dann kann ein Agent zum Beispiel einen Knowledge-Artikel aktualisieren, einen Benutzer in eine Gruppe aufnehmen, ein Monitoring-Query ausführen, einen Change im ITSM-Tool anlegen oder Statusmeldungen verschicken. Genau deshalb ist die neue Betriebsfrage nicht mehr nur, ob die Antwort plausibel klingt, sondern ob der Handlungspfad betrieblich sauber begrenzt ist.
Das gilt unabhängig davon, ob die Werkzeuge direkt per API angebunden sind oder über Standards wie MCP. Das MCP-Projekt positioniert sich bewusst als offenes Verbindungsprotokoll zwischen KI-Anwendungen und externen Systemen. Das vereinfacht Integration erheblich, ersetzt aber keine Governance. Ein standardisierter Anschluss an Dateien, Datenbanken oder Tools ist noch keine sichere Betriebsfreigabe. Ohne Rollenmodell, Scope-Begrenzung und Nachvollziehbarkeit wird aus dem bequemen Anschluss schnell ein sauber verkabeltes Risiko.
OWASP nennt das Problem beim Namen: Excessive Agency
Die OWASP GenAI Security Guidance trifft einen Punkt, der für IT- und Service-Teams operativ sehr hilfreich ist. Unter dem Risiko „Excessive Agency“ beschreibt OWASP die Lage, in der ein LLM-basierendes System zu viel Funktionalität, zu viele Rechte oder zu viel Autonomie erhält. Das ist keine Spezialwarnung für Security-Teams allein. Es ist ein direktes Betriebsproblem.
Ein Agent, der nur Tickets lesen und Entwürfe formulieren soll, braucht keine Löschrechte im Wissenssystem. Ein Agent, der Störungstexte clustern soll, braucht keinen offenen Shell-Zugriff. Ein Agent, der einen Nutzerkontext aus mehreren Quellen zusammenführen darf, sollte nicht automatisch dieselben Schreibrechte in Zielsystemen erben. Genau hier scheitern viele frühe Einführungen: Nicht weil das Modell besonders intelligent wäre, sondern weil die umgebenden Werkzeuge zu breit, zu generisch und zu privilegiert bereitgestellt werden.
OWASP nennt zusätzlich Prompt Injection als Grundrisiko, besonders wenn Agenten externe Inhalte wie Mails, Webseiten, Tickets oder Dateianhänge verarbeiten. Das ist für den IT-Betrieb hochrelevant. Wer Incident-Texte, Chatverläufe oder Wissensartikel ungefiltert in Agentenläufe gibt, koppelt den Handlungspfad des Systems an Inhalte, die falsch, manipuliert oder absichtlich schädlich sein können. Dann reicht ein gut formulierter Fremdinhalt, um einen zu freizügigen Agenten in die falsche Richtung zu lenken.
Freigaben gehören an die Wirkung, nicht nur an den Start des Projekts
Viele Organisationen denken Freigaben bislang als einmaligen Go-live-Moment. Für Agenten reicht das nicht. Sinnvoller ist ein Wirkmodell mit gestuften Aktionen. Lesen, zusammenfassen und priorisieren kann deutlich früher freigegeben werden als Schreiben, Ändern oder Auslösen. Ein guter Betriebszuschnitt beginnt deshalb mit mindestens drei Klassen: reine Leseaktionen, vorbereitende Schreibentwürfe und hochwirksame Aktionen mit menschlicher Bestätigung.
Praktisch heißt das zum Beispiel: Der Agent darf Incidents lesen, ähnliche Fälle suchen und einen Lösungsvorschlag entwerfen. Er darf vielleicht auch einen Change-Draft oder eine Standardantwort vorbereiten. Er darf aber keinen produktiven Change freigeben, keine Rechte eskalieren, keine kritischen Konfigurationen ändern und keine Kommunikation an Kunden oder Management absetzen, ohne dass dafür ein klarer Approval-Step existiert.
Genau hier hilft die Denkweise aus dem klassischen ITSM. Jede Agentenaktion braucht einen sauberen Servicekontext, klare Verantwortliche und definierte Eskalationspfade. Ein Agent ohne klaren Übergabepunkt an Menschen ist betrieblich ähnlich problematisch wie eine Automatisierung ohne Not-Aus.
Runbooks und Rückfallwege sind wichtiger als Demo-Magie
Die meisten Demos zeigen, wie elegant ein Agent mehrere Tools hintereinander nutzt. Im Live-Betrieb ist die wichtigere Frage, was bei Unsicherheit passiert. Dafür brauchen Teams Runbooks. Nicht als Marketingfolie, sondern als ausführbare Betriebslogik. Ein Agent muss wissen, wann ein Schwellenwert überschritten ist, wann ihm Kontext fehlt, wann mehrere Systeme widersprüchliche Daten liefern oder wann eine Aktion auf ein sensibles Zielsystem trifft.
Dann braucht es einen sauberen Rückfallweg. Das kann die Übergabe an den Service Desk, die Erzeugung eines manuellen Approval-Tickets, die Rückstufung auf einen Entwurfsmodus oder ein kompletter Abbruch mit sauberer Protokollierung sein. Genau dieser Teil entscheidet, ob Agenten den Betrieb entlasten oder neue Incident-Arten erzeugen.
Anthropic empfiehlt bei agentischen Systemen, mit möglichst einfachen und gut verständlichen Mustern zu beginnen. Das ist nicht nur ein Entwicklungstipp, sondern gute Betriebspolitik. Je offener und autonomer der Ablauf, desto wichtiger werden Debuggability, Limits und verlässliche Eingriffsstellen.
Beobachtbarkeit gehört auf die Ebene der Tool-Aufrufe
NISTs AI RMF und das zugehörige Playbook arbeiten mit den Funktionsbereichen Govern, Map, Measure und Manage. Für Agenten im IT-Betrieb lässt sich das sehr konkret übersetzen. Govern heißt, Rollen, Zuständigkeiten und zulässige Einsatzfelder zu definieren. Map heißt, Datenquellen, Systeme, Risiken und Fehlermodi sauber zu erfassen. Measure heißt, nicht nur Antwortqualität zu messen, sondern auch Fehlaufrufe, Eskalationsquoten, Abbruchgründe und manuelle Korrekturen. Manage heißt schließlich, diese Erkenntnisse in Policies, Freigaben und Betriebseingriffe zurückzuführen.
Wichtig ist dabei die richtige Beobachtungsebene. Es reicht nicht, nur die finale Textantwort eines Agenten zu loggen. Entscheidend sind die Tool-Aufrufe: Welches Werkzeug wurde wann gewählt, mit welchen Parametern, gegen welches Zielsystem, mit welchem Ergebnis und welcher Folgeaktion? Erst auf dieser Ebene werden Risiken, unnötige Schleifen und ungewollte Seiteneffekte sichtbar.
Wie ein pragmatischer Einstieg aussieht
Für die meisten IT-Organisationen ist der beste Start kein vollautonomer Agent, sondern ein klar eingehegter Betriebshelfer. Gute erste Einsatzfelder sind Ticket-Zusammenfassungen, Klassifizierungsvorschläge, Vorschläge für Known-Error-Verweise, Change-Drafts oder die Bündelung von Diagnoseinformationen aus klar freigegebenen Read-only-Quellen. Von dort aus lässt sich schrittweise lernen, wo die Modelle stabil genug arbeiten, welche Tool-Schnittstellen sauber geschnitten sind und an welchen Stellen menschliche Freigaben unverzichtbar bleiben.
Wenn Teams diesen Einstieg sauber aufsetzen, wächst daraus eher ein belastbares Assistenzsystem als eine unkontrollierte Automatisierung. Genau das ist im IT-Betrieb oft der bessere Weg. Nicht maximale Autonomie zuerst, sondern kontrollierte Wirkung mit klarer Verantwortlichkeit.
Fazit
KI-Agenten werden im IT-Betrieb nicht durch ein stärkeres Modell zuverlässig, sondern durch klare Werkzeuggrenzen, gestufte Freigaben, saubere Runbooks und beobachtbare Rückfallwege. Tool Calling und Standards wie MCP machen Agenten praktisch einsetzbar, verschieben die Verantwortung aber nicht vom Betreiber weg. Wer Rechte, Eskalationen und Logging nicht mitdesignt, automatisiert im Zweifel nicht den Fortschritt, sondern den Fehler. Für IT- und Service-Teams ist deshalb nicht die schönste Demo der relevante Reifegradmesser, sondern die Frage, ob der Agent im unsauberen Alltag kontrolliert scheitern kann.
