KI-Agent für IT-Operations: interne Tickets, Zugriffe, Monitoring und Dokumentation

Das Problem

Interne IT-Operations hören nie auf, das zuständige Team schon. Eine Jitbit-Analyse zu rund 1.000 Unternehmen, die im Support-Bereich regelmäßig zitiert wird, bezifferte 2017 das durchschnittliche Volumen pro Techniker auf 21 Tickets pro Tag, bei einer durchschnittlichen Lösungszeit von 82 Stunden. Das sind veraltete Daten, von den Autoren selbst als historische Basis statt als aktuelles Ziel dargestellt, als Größenordnung zu lesen, nicht als aktueller Wert.

Zur pro Ticket aufgewendeten Zeit nennt Endsight, ein Managed-Support-Anbieter, im Durchschnitt 63 Minuten, gemessen an eigenen 10.923 über 12 Monate verfolgten Nutzern. Das sind unternehmensinterne, nicht von Dritten geprüfte Daten: eher als Anhaltspunkt zu sehen, nicht als Branchenstandard.

Am solidesten dokumentiert ist der Punkt zu Zugriffen. Eine von Wing Security aufgegriffene und von The Hacker News weiterverbreitete Untersuchung aus dem Jahr 2024 schätzt, dass 63 % der Unternehmen ehemalige Mitarbeiter haben, die weiterhin Zugriff auf Organisationsdaten behalten, und 43 % auf Code-Repositories bei GitHub oder GitLab. Jede Zugriffs- oder Entzugsanfrage, die in einer internen Ticket-Warteschlange liegen bleibt, ist ein direkter Kandidat für genau diese Art von Statistik.

Diese Bearbeitungsverzögerung hat eine zweite, weniger sichtbare Folge als das Sicherheitsrisiko: Die Ticket-Warteschlange selbst wird unübersichtlich. Wenn sich dringende Anfragen (ein blockierter Zugriff, der die Arbeit verhindert) mit Routineanfragen mischen (eine Frage, die in der Wissensdatenbank bereits zehnmal beantwortet wurde), verbringt das IT-Team ebenso viel Zeit mit Sortieren wie mit Lösen. Ein guter Teil dieser Warteschlange sollte nie einen Menschen erreichen: Genau diese Art von Triage kann ein Agent, der die bestehende Dokumentation liest, übernehmen, bevor das Ticket auf seine Bearbeitung wartet.

Was der Agent Schritt für Schritt tut

Ein für IT-Operations eingesetzter autonomer KI-Agent läuft fortlaufend, in seiner eigenen isolierten Umgebung, und überwacht die Ticket-Warteschlange, ohne je zu schlafen.

Er beginnt damit, jedes eingehende Ticket in Jira zu kategorisieren: bereits bekannte Frage, Zugriffsanfrage, technischer Incident. Bei bereits dokumentierten Anfragen antwortet er direkt, mit Verweis auf die in der Notion-Wissensdatenbank des Teams gefundene Prozedur. Bei einer Zugriffsanfrage auf ein Tool oder Repository öffnet er ein strukturiertes Ticket mit allen für die Entscheidung nötigen Informationen, statt sie selbst auszuführen.

Auf der Monitoring-Seite überwacht der Agent die von Datadog gemeldeten Alarme und korreliert sie mit aktuellen Commits oder Deployments, die in GitHub sichtbar sind: Ein Latenzanstieg unmittelbar nach einem Deployment wird nicht als isolierter Incident behandelt. Ist die Korrelation eindeutig, öffnet er eine dokumentierte GitHub-Issue mit dem für das technische Team nützlichen Kontext. Jedes blockiert gebliebene Ticket, jeder kritische Alarm oder jede wartende Zugriffsanfrage löst eine Slack-Benachrichtigung an das IT-Team aus. Jede Aktion, erstelltes Ticket, korrelierter Alarm, gesendete Nachricht, wird in der Timeline des Agenten mit exaktem Status protokolliert.

Ein konkretes Beispiel verdeutlicht die Mechanik: Ein Mitarbeiter öffnet an einem Freitagabend ein Ticket, um den Zugriff auf ein bestimmtes GitHub-Repository im Rahmen eines bereichsübergreifenden Projekts anzufragen. Der Agent kategorisiert die Anfrage, prüft ihre Vollständigkeit (betroffenes Repository, Begründung, gewünschte Dauer) und bereitet dann ein strukturiertes Ticket vor, bereit zur Freigabe durch einen IT-Verantwortlichen schon am Montagmorgen, statt die Anfrage in einer generischen Warteschlange schlummern zu lassen, bis jemand sie zufällig bemerkt.

Die eingesetzten Integrationen

Jira bleibt die verbindliche Warteschlange für interne Tickets. Der Agent durchsucht dort Anfragen (search_issues), prüft Details (get_issue) und kann eine neue strukturierte Issue anlegen, je nach den von seinem Grant abgedeckten Aktionen.

GitHub dient dazu, einen technischen Alarm mit einer Code-Änderung zu korrelieren: Liste aktueller Commits (list_commits), Details eines Pull Requests (get_pull_request), und Erstellung einer dokumentierten Issue (create_issue), sobald die Korrelation feststeht.

Datadog liefert das rohe Monitoring-Signal, das der Agent einsieht, ohne je das Monitoring-Tool selbst zu ersetzen. Notion beherbergt die Prozeduren und Runbooks, die der Agent vor einer Antwort konsultiert, und Slack trägt die Benachrichtigungen in Echtzeit an das IT-Team.

Was beim Menschen bleibt

Der Agent bereitet vor und alarmiert, er führt nie eigenständig eine Änderung an Zugriffen oder Infrastruktur aus. Einen Zugriff tatsächlich zu erteilen oder zu entziehen bleibt eine menschliche Handlung: Der Agent öffnet die dokumentierte Anfrage in Jira, eine Person aus der IT führt sie aus und schließt sie ab.

Die tatsächliche Kritikalität eines mehrdeutigen Alarms, eines, der keinem identifizierbaren aktuellen Deployment entspricht, wird von einem Menschen entschieden, bevor über eine Slack-Benachrichtigung hinaus eskaliert wird. Einen Code- oder Infrastruktur-Fix zu entscheiden und anzuwenden bleibt naturgemäß Aufgabe eines Ingenieurs. Und wie bei jedem Atako-Agenten muss ein Administrator die Grants auf Jira, GitHub und Datadog Aktion für Aktion erteilen und anpassen, mit explizit definiertem Umfang lesen oder lesen und schreiben.

Diese Grenze gilt auch für den Agenten selbst: Stößt er auf eine Situation außerhalb dessen, was sein Geschäftskontext abdeckt, eine ungewöhnliche Lizenzverlängerung, eine Zugriffsanfrage auf ein nicht dokumentiertes System, erzwingt er keine ungefähre Antwort. Er benachrichtigt das IT-Team und lässt das Ticket für eine menschliche Bearbeitung offen, statt eine Prozedur zu erraten, die in seiner Wissensdatenbank nicht existiert.

Messbares Ergebnis

Der direkteste Nutzen ist die Verkürzung der Totzeit zwischen dem Eintreffen eines Tickets oder Alarms und seiner ersten Bearbeitung. Ein Agent, der rund um die Uhr läuft, kann ein am Sonntagabend eröffnetes Ticket kategorisieren und die entsprechende Zugriffsanfrage vorbereiten, bevor das Team am Montag eintrifft, statt die Anfrage in der Warteschlange warten zu lassen.

Der zweite Nutzen betrifft direkt das von Wing Security dokumentierte Problem: Indem er das Öffnen eines Entzugstickets systematisiert, sobald ein Austritt gemeldet wird, verkürzt der Agent die Zeit zwischen dem auslösenden Ereignis und der IT-Handlung, was das Zeitfenster begrenzt, in dem ein Zugriff unnötig aktiv bleibt, ein Fenster, das sich ohne fortlaufende Überwachung laut den oben genannten Befunden über Wochen oder sogar Monate ausdehnen kann.

Jedes eröffnete Ticket, jeder korrelierte Alarm, jede gesendete Nachricht bleibt im Audit-Trail von Atako einsehbar, für das IT-Team exportierbar als CSV mit bis zu 50.000 Zeilen. Diese vollständige Nachvollziehbarkeit erleichtert auch interne Sicherheitsaudits: Wer wann einen Zugriff angefragt hat und auf welcher Grundlage die Anfrage formalisiert wurde, muss nicht mehr aus mehreren verschiedenen Tools rekonstruiert werden.

Ein IT-Agent fällt unter den Standard-Plan, 20 Euro pro Monat und Slot, mit 1.000 inkludierten Credits pro Monat für die Modellaufrufe. Die Zahl bearbeiteter Tickets oder mit dem Agenten interagierender Mitarbeiter hat keinen Einfluss auf diesen Preis, nur die Zahl gleichzeitig aktiver Agenten zählt. Ein kleines IT-Team kann so einen einzigen Agenten über alle internen Tickets, Monitoring-Alarme und Zugriffsanfragen laufen lassen, ohne für jeden Fluss einen eigenen Slot zu benötigen, was die Kosten auch dann vorhersehbar hält, wenn sich der Wirkungsbereich des Agenten im Laufe der Monate schrittweise auf neue Tools oder neue interne Teams ausweitet.