KI-Ticket-Triage: Was ein Agent allein entscheiden darf

Ein Ticket meldet, dass das Root-Dateisystem einer VM bei 95 Prozent liegt und Log-Schreibvorgänge scheitern. Ein Admin liest das, meldet sich auf der Maschine an, sucht die größten Verzeichnisse, findet ein Log, das seit Wochen nicht rotiert wurde, räumt auf und schließt das Ticket. Zwölf Minuten Arbeit, davon zehn für Dinge, die eine Maschine hätte erledigen können.

Bei zwanzig solcher Tickets pro Woche ist das der Punkt, an dem KI-gestützte Triage interessant wird. Und der Punkt, an dem die meisten Vorhaben die falsche Frage zuerst stellen.

Red Hat hat Anfang September ein Demo-Video zum neuen automation orchestrator für die Ansible Automation Platform veröffentlicht, das dieses Szenario durchspielt. Es lohnt sich anzusehen, weil es ein Muster sauber zeigt, das weit über das Produkt hinaus trägt. Es lohnt sich aber auch, genau hinzusehen, wo eine Demo endet und der eigene Betrieb anfängt.

Drei Wege statt einer Antwort

Der Aufbau im Video ist schnell erzählt. Ein Agent liest ein eingehendes ServiceNow-Ticket über MCP-Tools, zieht sich Kontext aus dem ITSM und aus der Liste verfügbarer Job Templates, schreibt seine Einschätzung ins Ticket zurück und gibt eine Empfehlung ab. Ein nachgelagerter Switch-Knoten wertet diese Empfehlung aus und wählt einen von drei Zweigen.

Automatisch beheben. Freigabe einholen. Nur anreichern.

Im Video geht das volle Dateisystem den ersten Weg: Ein Cleanup-Job-Template läuft, das Ticket geht auf resolved. Ein SSH-Brute-Force geht den dritten Weg, das Ticket bleibt aktiv und wird um die Analyse ergänzt, denn ein blockierter Angriffsversuch ist nichts, was man wegautomatisiert. Eine hohe CPU-Auslastung geht den zweiten Weg: Ein Mensch klickt auf Freigeben, erst danach wird der Prozess beendet.

Diese Dreiteilung ist der eigentlich wertvolle Teil, und sie ist an kein Produkt gebunden. Sie beantwortet nämlich eine andere Frage, als die meisten Teams stellen.

Die übliche Frage lautet: Wie zuverlässig ist das Modell? Darauf gibt es keine befriedigende Antwort, weil sie von der Eingabe abhängt und sich mit jedem Modellwechsel ändert. Die bessere Frage lautet: Welche Klasse von Vorgängen darf in unserem Betrieb ohne Rückfrage laufen?

Das ist keine Eigenschaft des Modells, sondern eine Betriebsentscheidung. Sie lässt sich unabhängig von KI treffen, sie lässt sich dokumentieren, und sie ist auditierbar. Ein temporäres Verzeichnis aufzuräumen ist reversibel und der Schaden bei einer Fehlentscheidung ist begrenzt. Einen Prozess auf einem Produktionssystem zu beenden ist es nicht. Diese Grenze zieht man einmal, bewusst und schriftlich, und danach entscheidet das Modell nur noch innerhalb davon.

Wer die Frage in dieser Reihenfolge stellt, kann mit einem mittelmäßigen Modell produktiv arbeiten. Wer sie umgekehrt stellt, wartet auf ein Modell, das gut genug ist, und fängt nie an. Dasselbe Muster gilt übrigens nicht nur für Tickets: Bei AI-Troubleshooting auf Linux entscheidet ebenfalls die Grenze zwischen Vorschlag und Aktion darüber, ob aus dem Werkzeug ein Betriebsmittel wird.

Warum der Ticket-Text nicht reicht

An einer Stelle bricht die Übertragung der Demo in einen echten Betrieb, und sie ist leicht zu übersehen: Die drei Tickets im Video wurden von der Demo selbst erzeugt, über ein Job Template. Ihre Beschreibungen waren dadurch vollständig, eindeutig und exakt auf den vorgesehenen Weg zugeschnitten.

Für eine Demo ist das richtig so, denn sie braucht reproduzierbare Eingaben. Es verschiebt nur die eigentliche Schwierigkeit aus dem Bild.

In einem echten Service Desk ist der Ticket-Text die schwächste Datenquelle im Raum. Er ist entweder das, was ein Mensch unter Zeitdruck getippt hat, oder das, was ein Alert-Template gefüllt hat. Beides ist eine Interpretation, kein Messwert. Typisch sind Tickets, die ein Symptom melden und die Ursache schon mitbehaupten, die zwei unabhängige Probleme in einem Vorgang vermischen, die den betroffenen Host falsch benennen, oder die als Kopie eines drei Wochen alten Tickets angelegt wurden, weil das schneller ging.

Der Satz “Root-Dateisystem bei 95 Prozent” beantwortet außerdem keine der Fragen, die für die Einordnung zählen. Steht der Wert seit zehn Minuten oder seit drei Wochen? Steigt er linear oder ist er gerade gesprungen? Ist dieselbe Maschine im letzten Quartal schon mehrfach vollgelaufen? Sind gleichzeitig andere Systeme betroffen, was auf ein gemeinsames Backend statt auf ein lokales Problem deutet?

Ein Agent, der nur den Ticket-Text liest, kann diese Fragen nicht beantworten. Schlimmer: Er kann dem Ticket nicht widersprechen. Er reproduziert dessen Fehler, nur flüssiger formuliert und mit mehr Selbstbewusstsein. Das ist ein schlechtes Tauschgeschäft, weil ein selbstbewusst falscher Vorschlag mehr Zeit kostet als gar kein Vorschlag.

Erst erden, dann klassifizieren

Deshalb habe ich meinen eigenen Aufbau anders angeschnitten. Ich arbeite gerade an einer vergleichbaren Triage im U-KNOW AI Studio, angebunden an KIX als Ticketsystem. Zusätzlich hängen Prometheus und Loki meines Kubernetes-Clusters mit dran.

Der Ablauf dreht die Reihenfolge um. Der Agent liest das Ticket nicht, um daraus eine Antwort abzuleiten, sondern um daraus eine Frage an die Betriebsdaten zu formen. Aus “Dateisystem voll auf Host X” wird eine Metrik-Abfrage über die letzten Tage und eine Log-Abfrage auf denselben Zeitraum. Erst das Ergebnis dieser Abfragen ist die Grundlage für die Einordnung.

Das ändert die Qualität der Vorschläge an einer konkreten Stelle. Der Ticket-Text sagt, dass etwas voll ist. Die Metrik sagt, ob es langsam gewachsen oder gesprungen ist, und das entscheidet zwischen Kapazitätsplanung und Störung. Die Logs sagen, welcher Dienst geschrieben hat. Zusammen ergibt das einen Vorschlag mit Beleg statt einer plausiblen Vermutung.

Ein angenehmer Nebeneffekt: Ein Vorschlag mit Belegen lässt sich prüfen. Ein Admin, der die zugrunde liegende Abfrage und ihr Ergebnis sieht, braucht dem Modell nicht zu glauben. Er sieht in zehn Sekunden, ob die Ableitung trägt. Genau das entscheidet darüber, ob so ein Werkzeug nach drei Wochen noch benutzt wird.

Wo bei mir der erste Weg noch zu ist

Mein Aufbau behebt bisher nichts automatisch. Es gibt nur den dritten Weg: anreichern und vorschlagen, entscheiden tut ein Mensch.

Das ist keine grundsätzliche Haltung gegen Automatisierung. Es fehlt schlicht eine Zahl. Ich habe noch nicht gemessen, wie oft die Klassifizierung daneben liegt, und in welche Richtung. Solange diese Zahl fehlt, ist die Öffnung des automatischen Weges eine Wette und keine Entscheidung.

Die Messung selbst ist unspektakulär. Man triagiert eine Menge echter Tickets von Hand, hält das Ergebnis als Referenz fest, lässt den Agenten parallel zum bestehenden Prozess laufen und vergleicht. Interessant ist dabei weniger die Trefferquote insgesamt als die Verteilung der Fehler. Ein Agent, der einen risikoarmen Fall fälschlich zur Freigabe schickt, kostet etwas Zeit. Ein Agent, der einen riskanten Fall fälschlich als risikoarm einstuft, ist ein Vorfall.

Aus derselben Richtung kommt ein Punkt, der in Demos praktisch nie vorkommt: Tickets können von außen befüllt werden, über ein Kundenportal oder eine Mail-Schnittstelle. Damit ist der Ticket-Text eine nicht vertrauenswürdige Eingabe. Wer daraus einen Prompt baut, hat einen Injection-Pfad, an dessen Ende im Zweifel ein Job Template mit Produktionszugriff steht. Der Ticket-Inhalt ist Datum, niemals Anweisung, und diese Trennung gehört nicht nur in den Prompt, sondern in die Architektur.

Was das für den Einstieg heißt

Wenn Sie über KI-gestützte Triage nachdenken, ist die Reihenfolge wichtiger als die Werkzeugwahl.

Beginnen Sie mit der Berechtigungsfrage, nicht mit dem Modell. Nehmen Sie die Ticket-Kategorien der letzten sechs Monate und sortieren Sie sie in die drei Wege ein, von Hand und ohne KI im Kopf. Wenn Sie dabei feststellen, dass Sie den ersten Weg nur für zwei oder drei Kategorien guten Gewissens ankreuzen können, ist das ein wertvolles Ergebnis. Genau diese zwei bis drei sind Ihr Einstieg.

Klären Sie danach, welche Datenquellen der Agent braucht, um eine Ticket-Aussage zu prüfen statt zu wiederholen. In einer Kubernetes-Umgebung sind das in der Regel Metriken, Logs und der Cluster-Zustand. Ohne diese Anbindung bekommen Sie eine Textzusammenfassung, und die löst kein Ticket.

Und lassen Sie den ersten Weg zu, bis Sie Ihre Fehlerquote kennen. Ein Vorschlag mit Belegen, den ein Mensch in zehn Sekunden prüft, ist ein realer Gewinn und ein sehr viel besserer Ausgangspunkt als eine Automatisierung, deren Trefferquote niemand beziffern kann.

Wollen Sie Triage-Aufgaben in Ihrem Betrieb entlasten, ohne die Kontrolle abzugeben?

Ich bin Björn Ohlrich und begleite seit über 20 Jahren Infrastruktur-Projekte, seit einigen Jahren mit Schwerpunkt Kubernetes On-Premise in mittelständischen und regulierten Umgebungen. Zertifiziert als CKA, RHCE und RHCSA.

Wie ich an KI im laufenden Betrieb herangehe, steht unter AI Ops im Betrieb: erst die Betriebsregeln, dann das Werkzeug, und Vorschläge mit Belegen statt Automatisierung auf Verdacht. Wenn zuerst geklärt werden soll, wie es um Rechte, Nachvollziehbarkeit und Diagnosefähigkeit Ihrer Plattform steht, ist das Kubernetes Review der passende Einstieg.

Lassen Sie uns unverbindlich sprechen. Ein Gespräch reicht meist, um einzuschätzen, ob das Thema bei Ihnen ansteht.

Quellen

Red Hat, YouTube-Kanal The Ansible Playbook, 08.09.2026: Drowning in Ticket Queues? How Automation Orchestrator Solves Ticket Enrichment
Red Hat Blog, 21.08.2026: Unify IT workflows at scale with the new automation orchestrator for Ansible Automation Platform
Produktseite: Ansible Automation Platform automation orchestrator