KI-Agenten im IT-Support: Was sie automatisieren und wo Menschen bleiben

Ein KI-Agent im IT-Support ist mehr als ein Chatbot mit freundlicher Oberfläche. Er nimmt einen Fall auf, nutzt Wissen, führt erlaubte Werkzeuge aus, dokumentiert das Ergebnis und weiß, wann ein Mensch übernehmen muss. Genau diese Trennung entscheidet darüber, ob aus einer Antwort ein kontrollierter Support-Prozess wird.

Die wichtigste Frage lautet deshalb nicht: Kann die KI das? Besser ist: Welche Schritte darf der Agent unter welchen Bedingungen ausführen, wie wird Erfolg geprüft und wann endet seine Zuständigkeit?

Antworten und Handeln sind zwei verschiedene Dinge

Ein klassischer Assistent kann eine Anleitung ausgeben. Der Nutzer muss die Arbeit danach selbst erledigen, und das Ergebnis bleibt oft außerhalb des Tickets. Ein operativer Agent verbindet dagegen Verständnis mit Ausführung: Er erkennt das Anliegen, findet relevantes Wissen, ruft ein freigegebenes Tool auf und hält den Verlauf im Fall fest.

Die nara Plattform für KI-Automatisierung ist für diese durchgängige Kette gebaut. Sie verbindet Agenten, Memory und Knowledge Graph, Tools, Edge Connector, Tickets, Monitoring und Rollen. Das macht den Agenten nicht autonom im Sinne von grenzenlos. Es macht seine Arbeit definierbar und prüfbar.

Was KI-Agenten automatisieren können

1. Anfragen aufnehmen und triagieren

Der Agent kann Anliegen, Nutzerkontext und Dringlichkeit erkennen und fehlende Informationen gezielt nachfragen. Bei einem VPN-Problem sind andere Angaben nötig als bei einer Zugriffsanfrage. Eine strukturierte Aufnahme verhindert, dass der Fall mehrfach zwischen Teams wandert, nur weil Basisinformationen fehlen.

Triage ist dabei kein endgültiges Urteil. Wenn Kontext oder Zuständigkeit unklar bleiben, kennzeichnet der Agent die Unsicherheit und übergibt den Fall.

2. Wissen gezielt nutzen

Dokumente allein lösen keinen Fall. Der Agent braucht die passende Anleitung, bekannte Fehlerbilder und den Kontext zum betroffenen System. nara Memory modelliert Wissen als Schemas, Objekte und Beziehungen in einem Knowledge Graph. Der Agent kann dieses Wissen während des Falls gezielt durchsuchen und Quellen nennen, statt eine Antwort zu erraten.

Wenn Wissen fehlt, ist Nichtwissen ein wichtiges Ergebnis. Der Agent leitet an die richtige Fachperson weiter und kann die Antwort für eine spätere, geprüfte Aktualisierung dokumentieren. Mehr dazu zeigt die Seite über operatives Wissen im Support.

3. Freigegebene Tools ausführen

Der größte Unterschied zum reinen Chatbot liegt in der Aktion. Ein Agent kann beispielsweise ein Ticket aktualisieren, einen Systemstatus prüfen oder einen definierten Passwort-Reset anstoßen, sofern dafür ein freigegebenes Tool vorhanden ist.

Jedes Tool hat eine bestimmte Aufgabe, definierte Eingaben und ein erwartetes Ergebnis. Der Agent erhält keinen beliebigen Systemzugriff. Beim nara Edge Connector gibt es keine offene Shell und keine freien Kommandos: Er führt ausschließlich Tools aus, die pro Agent erlaubt sind.

4. Mehrstufige Abläufe koordinieren

Viele Support-Fälle bestehen nicht aus einem einzelnen Aufruf. Onboarding verbindet Konten, Rechte, Geräte, Software, Freigaben und offene Punkte. Operating Protocols führen einen Agenten durch wiederholbare Phasen wie Triage, Wissenszugriff, Tool-Ausführung, Dokumentation und Übergabe.

Der Agent kann erledigte Schritte und Abhängigkeiten verfolgen. Er darf aber keine fehlende Freigabe überspringen, nur weil der nächste technische Schritt möglich wäre.

5. Tickets und Verlauf dokumentieren

Automatisierung ohne Nachweis erzeugt eine neue Blackbox. In nara werden Tool-Aufrufe, Statuswechsel, Kommentare und Übergaben als Ereignisse im Ticket festgehalten. Ein Teammitglied sieht dadurch, wer oder was wann gehandelt hat und mit welchem Ergebnis.

Bestehende Systeme wie ServiceNow oder Jira können führend bleiben. nara automatisiert Arbeit und synchronisiert Fälle, statt das ITSM zwangsläufig zu ersetzen. Die Case-Management-Seite beschreibt Tickets, Sessions, Timeline und Eskalation im Zusammenhang.

6. Status geben und sauber eskalieren

Ein Agent kann Nutzern den Stand eines Falls erklären und bekannte Störungen auslesen. Wenn er nicht weiterkommt, sollte er nicht in einer Schleife weiterfragen. Eine kontrollierte Eskalation enthält den Verlauf, die Diagnose, ausgeführte Schritte und die offene Entscheidung.

So bleibt der Mensch nicht nur als Notausgang übrig. Er bekommt einen vorbereiteten Fall, bei dem die Routinearbeit bereits erledigt ist.

Wo Menschen bleiben müssen

Freigaben für Zugriffe und sensible Änderungen

Ein Agent kann eine Zugriffsanfrage vollständig aufnehmen, gegen Rollen und Regeln prüfen und entscheidungsfertig vorlegen. Die Freigabe für SAP-Zugriffe, Verzeichnisrechte oder andere sensible Berechtigungen bleibt bei den verantwortlichen Menschen. Erst danach führt ein erlaubtes Tool die Änderung aus.

Ausnahmen und widersprüchliche Signale

Standardfälle leben von eindeutigen Voraussetzungen. Stimmen Identität, Systemstatus oder Richtlinie nicht zusammen, braucht es Urteil. Der Agent muss dann stoppen, Unsicherheit sichtbar machen und den Fall mit Belegen übergeben.

Personal- und Richtlinienentscheidungen

Bei Joiner-Mover-Leaver-Prozessen kann der Agent Konten, Rechte, Geräte und offene Schritte koordinieren. Ob eine Person eingestellt wird, welche Sonderrechte eine Rolle erhält oder wie mit einer Ausnahme umzugehen ist, entscheiden weiterhin HR, Führungskraft oder IT-Verantwortliche.

Qualitätssicherung von Wissen

Agenten können aus gelösten Fällen und Ticket-Historien Entwürfe für Wissensartikel erstellen. Gültig wird neues Wissen erst nach Prüfung und Freigabe durch das Team. Sonst würde ein ungeprüfter Einzelfall zur allgemeinen Regel.

Gestaltung und Betrieb der Automatisierung

Menschen definieren, welche Tools ein Agent nutzen darf, welche Rollen Zugriff erhalten, wann eine Freigabe nötig ist und welche Schwellen zur Eskalation führen. Logs, Monitoring und Ticketdaten helfen anschließend zu prüfen, ob der Prozess wie vorgesehen arbeitet.

Ein einfaches Modell für jede Aktion

Teilen Sie Agentenaktionen in drei Klassen:

1. Erlaubt: Der Agent darf den Schritt selbst ausführen, wenn alle Voraussetzungen erfüllt sind. Beispiel: einen bekannten Status lesen oder einen freigegebenen Diagnosetest starten.
2. Freigabepflichtig: Der Agent bereitet alles vor, wartet auf eine benannte Person und führt erst danach aus. Beispiel: ein sensibles Zugriffsrecht ändern.
3. Nicht delegiert: Der Agent sammelt Kontext, trifft aber keine Entscheidung. Beispiel: eine Personalentscheidung oder eine Ausnahme von der Sicherheitsrichtlinie.

Für jede Aktion gehören außerdem Erfolgskriterium, Timeout, Fehlerbehandlung und Ziel der Eskalation in den Ablauf. So wird aus einer allgemeinen Agentenidee ein betreibbarer Prozess.

Woran gute Zusammenarbeit messbar wird

Eine Antwortquote allein sagt wenig. Relevanter sind Fragen wie:

• Wurde der Fall korrekt gelöst oder mit vollständigem Kontext übergeben?
• Waren alle Tool-Aufrufe erlaubt und nachvollziehbar?
• Wie viele Rückfragen und Neuzuweisungen waren nötig?
• An welcher Stelle fehlten Wissen, Integration oder Freigabe?
• Kann ein Mensch den Verlauf ohne erneute Diagnose übernehmen?

Die Seite zur IT Service Desk Automation zeigt konkrete Abläufe für Passwort, VPN, Zugriff und Onboarding. Eine anonymisierte Analyse von 43.676 ServiceNow Tickets zeigt außerdem, wie eine Ticket-Historie die Priorität solcher Abläufe bestimmen kann.

Die Grenze ist Teil des Produkts

Ein guter KI-Agent ist nicht der Agent, der immer weitermacht. Er ist der Agent, der seinen erlaubten Bereich zuverlässig bearbeitet, Ergebnisse prüft und Grenzen früh erkennt. So übernehmen Agenten Wiederholung und Dokumentation, während Menschen Kontrolle über Freigaben, Ausnahmen und Entscheidungen behalten.

Wenn Sie die Aufgabenverteilung für einen eigenen Support-Prozess durchgehen möchten, können Sie eine Demo anfragen. Gemeinsam prüfen wir Tools, Freigaben und Übergaben anhand Ihres Stacks.