KI im IT-Support und Helpdesk: Triage, Antworten, Automatisierung

Warum IT-Support ein Paradefall für KI ist

Kein Bereich in einem Betrieb produziert so viel strukturiertes, wiederkehrendes Text-Material wie der IT-Support: Tickets mit Betreff, Beschreibung und Priorität, eine Wissensdatenbank mit gelösten Fällen, und ein Chatverlauf pro Anfrage. Genau dieses Muster - viel Text, klare Struktur, hohe Wiederholung - ist die Umgebung, in der grosse Sprachmodelle am zuverlässigsten arbeiten. Wenn du verstehen willst, warum das so ist, lohnt sich ein Blick auf Wie ein LLM eigentlich funktioniert: Sprachmodelle sind im Kern darauf trainiert, aus viel Kontext das nächste plausible Textstück vorherzusagen - und ein Ticket-Text mit ähnlichen historischen Fällen als Kontext ist genau das Material, aus dem gute Vorhersagen entstehen.

Gleichzeitig ist der IT-Support ein Bereich, in dem Fehler schnell sichtbar werden: Ein falsch kategorisiertes Ticket verzögert die Bearbeitung, eine falsche Antwort kostet Vertrauen, eine autonom ausgeführte Aktion kann im schlimmsten Fall ein System lahmlegen. Dieser Artikel geht die vier praxisrelevanten Einsatzfelder durch - Triage, Antwortvorschläge, Wissensdatenbank-Chatbot, Automatisierung -, zeigt an einem echten Beispiel, wie das konkret aussieht, und benennt klar, wo die Aufsicht eines Menschen zwingend bleibt.

Ticket-Triage und Klassifizierung

Triage heisst: Ein neu eingehendes Ticket wird automatisch in Kategorie, Priorität und zuständiges Team eingeordnet, bevor eine Person es überhaupt liest. Klassisch lief das über Schlüsselwort-Regeln (“enthält ‘Drucker’ → Kategorie Hardware”), was bei jeder neuen Formulierung oder jedem neuen Gerätetyp von Hand nachgepflegt werden musste. Ein Sprachmodell braucht diese Regeln nicht - es erkennt aus dem Ticket-Text selbst, worum es geht, auch wenn Nutzende ihr Problem in eigenen Worten, mit Tippfehlern oder auf Schweizerdeutsch-Anleihen beschreiben.

Technisch läuft das meist über strukturierte Ausgaben: Das Modell bekommt den Ticket-Text plus eine feste Liste möglicher Kategorien und Prioritäten und muss ein festes Antwortformat liefern, das die Ticket-Software direkt weiterverarbeiten kann. Ein vereinfachtes Beispiel für ein solches Antwortschema:

{
  "kategorie": "Netzwerk",
  "prioritaet": "hoch",
  "team": "Infrastruktur",
  "konfidenz": 0.86,
  "begruendung": "Nutzer meldet VPN-Verbindungsabbruch seit Update, betrifft laut Text mehrere Kolleg:innen"
}

Das Feld konfidenz ist dabei der wichtigste Baustein für den produktiven Einsatz: Liegt die Sicherheit des Modells über einem festgelegten Schwellenwert, wird automatisch zugewiesen; liegt sie darunter, geht das Ticket trotzdem an eine Person zur manuellen Einordnung. So bleibt die Automatisierung auf die Fälle beschränkt, in denen sie zuverlässig ist, mehr dazu unter Struktur­ierte Outputs und Streaming.

Antwortvorschläge und Zusammenfassungen

Der zweite grosse Baustein: Statt jede Antwort von Null zu tippen, bekommt die Support-Person einen Entwurf vorgelegt, den sie prüft, anpasst und abschickt - oder verwirft. Zwei Varianten sind in der Praxis verbreitet:

• Entwurf für die nächste Antwort, gestützt auf ähnliche gelöste Tickets und passende Wissensdatenbank-Artikel. Das Modell schlägt Formulierung und nötige Rückfragen vor, die Person bleibt aber immer die letzte Instanz vor dem Absenden.
• Zusammenfassung eines langen Falls, etwa wenn ein Ticket über Wochen mit vielen Nachrichten gewachsen ist und eine neue Person im Team es übernimmt. Statt den ganzen Verlauf zu lesen, bekommt sie in Sekunden den Kern: was ist das Problem, was wurde schon versucht, was ist offen.

Ein Beispiel für die Art von Anweisung, die einem Modell für Antwortvorschläge mitgegeben wird:

Du bekommst den bisherigen Ticket-Verlauf und die drei ähnlichsten
gelösten Fälle aus der Wissensdatenbank als Kontext.

Aufgabe: Schlage eine Antwort an die anfragende Person vor.
- Nutze nur Informationen aus dem gegebenen Kontext, erfinde
  keine Befehle, Versionsnummern oder Software-Namen.
- Wenn der Kontext das Problem nicht eindeutig löst, schlage
  stattdessen 2-3 konkrete Rückfragen vor statt einer Vermutung.
- Markiere den Vorschlag klar als Entwurf, nicht als fertige Antwort.

Diese Formulierung “erfinde nichts, was nicht im Kontext steht” ist kein Stilmittel, sondern eine der wenigen wirksamen Massnahmen gegen Halluzinationen - Details dazu unter Warum KI halluziniert und Faktencheck von KI-Output.

Wissensdatenbank-Chatbot: Support, der direkt antwortet

Die dritte Stufe geht einen Schritt weiter: Statt der Support-Person einen Entwurf zu liefern, beantwortet ein Chatbot die Anfrage direkt gegenüber der ratsuchenden Person - und zwar gestützt auf die firmeneigene Wissensdatenbank, nicht auf das allgemeine Trainingswissen des Modells. Diese Technik heisst Retrieval-Augmented Generation (RAG): Zu jeder Anfrage werden zuerst die passendsten Wissensartikel gesucht, dann bekommt das Modell genau diese Artikel als Kontext mitgeliefert und antwortet ausschliesslich daraus. Wie das im Detail funktioniert, inklusive Embeddings und Vektorsuche, steht unter RAG: Firmenwissen für KI nutzbar machen und Embeddings und Vektoren erklärt.

Der entscheidende Vorteil gegenüber einem “nackten” Chatbot ohne Wissensanbindung: Die Antworten bleiben an die tatsächlich vorhandenen, geprüften Artikel gebunden. Fehlt ein Artikel zu einem Thema, kann ein gut instruierter Bot das auch ehrlich sagen, statt eine plausibel klingende, aber falsche Antwort zu erfinden - vorausgesetzt, genau das wird ihm in der Systemanweisung auch so vorgegeben.

Reales Beispiel: Pixel, der Wiki-Chatbot dieser Seite

Ein konkretes, laufendes Beispiel für einen Wissensdatenbank-Chatbot ist Pixel, der Chat-Assistent von genau diesem Wiki (guide.sweber.dev). Pixel zeigt gut, wie die einzelnen Bausteine in der Praxis zusammenspielen:

• Retrieval statt freies Wissen: Bei jeder Frage sucht das System zuerst passende Wiki-Artikel und gibt Pixel nur deren Titel, Beschreibung und URL als Kontext mit - inklusive der Anweisung, ausschliesslich diese Slugs zu verlinken und keine zu erfinden.
• Ein Nachschau-Werkzeug für Details: Reicht Titel und Beschreibung nicht, kann Pixel gezielt ein Werkzeug namens lookup_article aufrufen, das den vollen Artikeltext eines einzelnen, aus der Trefferliste gewählten Slugs nachlädt - so zitiert der Bot konkrete Schritte, statt sie aus dem Gedächtnis zu raten. Das Prinzip, wie ein Modell überhaupt entscheidet, wann es ein Werkzeug aufruft, ist unter KI-Agents und Tool-Use beschrieben.
• Seitenkontext: Chattet jemand direkt auf einer Artikel-Seite und schreibt “ich verstehe das hier nicht”, bekommt Pixel automatisch mitgeteilt, welche Seite gerade offen ist - ohne dass die Person das Thema nochmal ausschreiben muss.
• Eskalation mit fester Freigabe: Reicht der Wiki-Inhalt nicht, kann Pixel ein echtes Support-Ticket eröffnen (create_ticket) oder eine kurze Notiz an den Betreiber schicken (escalate_to_admin) - beides ausschliesslich nach ausdrücklicher Zustimmung der chattenden Person, nie auf eigene Initiative. Alternativ füllt Pixel nur das Ticket-Formular vor (prepare_ticket_link) und überlässt der Person das Absenden.
• Explizite Ehrlichkeitsregel: Ist sich Pixel nicht sicher, ist die Systemanweisung eindeutig: “weiss ich nicht genau” sagen und ein Ticket vorschlagen, statt einen Befehl, ein Tastenkürzel oder einen UI-Pfad zu erfinden.

Automatisierung: von Vorschlag zu Aktion

Die vierte Stufe ist die heikelste: Statt nur Text vorzuschlagen, führt die KI eine echte Aktion aus - ein Passwort zurücksetzen, einen Zugriff freigeben, ein Ticket automatisch schliessen, eine Standard-Software neu ausrollen. Der Unterschied zu den vorherigen Stufen ist fundamental: Ein falscher Textvorschlag wird von einer Person gelesen und im Zweifel verworfen, eine falsch ausgeführte Aktion ist bereits passiert, bevor sie überhaupt auffällt.

Sinnvolle Kandidaten für echte Automatisierung teilen typischerweise drei Eigenschaften:

1. Eng begrenzter Wirkungsbereich - ein Passwort-Reset für ein einzelnes Konto betrifft nur diese Person, ein Massenzugriff auf ein Produktivsystem betrifft potenziell alle.
2. Umkehrbarkeit - lässt sich die Aktion rückgängig machen, ist ein Fehler verkraftbar; ein gelöschter Datensatz ohne Backup ist es nicht.
3. Klare, prüfbare Vorbedingung - “Person hat sich per Zwei-Faktor-Verfahren identifiziert” ist prüfbar, “Ticket klingt dringend” ist es nicht.

Automatisierungs-Ampel (vereinfacht)

Grün  -> Automatisch ausführen ohne Rückfrage
         (z. B. Standard-FAQ beantworten, Status-Info liefern)

Gelb  -> Vorschlag erstellen, Mensch bestätigt aktiv
         (z. B. Passwort-Reset, Ticket kategorisieren und zuweisen)

Rot   -> Nie automatisch, auch nicht mit Bestätigungs-Klick
         (z. B. Massenzugriffe ändern, Produktivsystem-Konfiguration,
         Konten löschen, Berechtigungen auf Admin-Ebene vergeben)

Diese Ampel-Logik lässt sich mit den in Ticketsystem-Grundlagen beschriebenen Priorisierungs- und Eskalationsregeln kombinieren: Ein System, das ohnehin schon nach Dringlichkeit und Auswirkung unterscheidet, liefert automatisch die Kriterien dafür, welche Fälle für KI-gestützte Automatisierung überhaupt infrage kommen.

Werkzeuglandschaft im Überblick (Stand: 2026-07)

Die grossen ITSM- und Support-Plattformen haben KI-Funktionen inzwischen tief in ihre Produkte integriert. Konkrete Namen und Funktionsumfänge ändern sich laufend, das Grundmuster - Klassifizierung, Wissenssuche, Antwortvorschlag, begrenzte Automatisierung - bleibt über Anbieter hinweg vergleichbar:

Grenzen und nötige Aufsicht

So nützlich die vier Bausteine sind, sie ersetzen menschliches Urteilsvermögen nicht vollständig - aus mehreren, gut belegbaren Gründen:

Halluzinationen bleiben möglich. Auch mit RAG und strikten Anweisungen kann ein Modell Details erfinden, besonders wenn die Wissensdatenbank lückenhaft ist oder die Frage ungewöhnlich formuliert ist. Deshalb gehört eine klare Ehrlichkeitsregel (“bei Unsicherheit sagen, nicht raten”) in jede Systemanweisung, siehe auch Was KI kann und was nicht.

Fehlklassifizierung hat reale Folgen. Ein als “niedrige Priorität” eingestuftes Ticket zu einem Sicherheitsvorfall, das deshalb tagelang liegen bleibt, ist kein theoretisches Risiko. Konfidenzwerte und ein Schwellenwert für automatische versus manuelle Zuweisung sind hier keine Kür, sondern Pflicht.

Automatisierte Aktionen brauchen eine Rückversicherung. Die Ampel-Logik von oben ist kein Selbstzweck: Jede Aktion, die schwer umkehrbar ist oder mehr als eine Person betrifft, gehört in die gelbe oder rote Kategorie - unabhängig davon, wie zuverlässig das Modell in Tests bisher war.

Personenbezogene und vertrauliche Daten brauchen eine geklärte Grundlage. Tickets enthalten häufig Namen, E-Mail-Adressen, manchmal auch sensible Details. Wird ein KI-Tool eines Drittanbieters eingesetzt, muss vorab geklärt sein, wo diese Daten verarbeitet werden und ob ein Vertragsverhältnis (Auftragsbearbeitung) besteht - siehe DSGVO/nDSG in der IT-Praxis.

Ohne Monitoring verschlechtert sich die Qualität unbemerkt. Ein Klassifizierungsmodell, das bei Einführung 90 % Trefferquote hatte, kann Monate später bei neuen Ticket-Typen deutlich schlechter liegen, ohne dass es jemand merkt - wenn niemand regelmässig eine Stichprobe manuell gegenprüft. Mehr zu systematischer Qualitätsprüfung unter KI-Evaluationen und Testen.

Entscheidungsbaum: Automatisch lösen oder an einen Menschen weiterleiten?

Neues Ticket trifft ein
│
├─ Ist die Anfrage eine reine Standard-FAQ mit klarer Antwort
│  in der Wissensdatenbank?
│   Ja  -> Chatbot antwortet direkt, Ticket bleibt offen bis
│          Person bestätigt "gelöst" oder meldet sich erneut
│   Nein -> weiter
│
├─ Liegt die Konfidenz der automatischen Kategorisierung
│  über dem festgelegten Schwellenwert?
│   Ja  -> Automatisch zuweisen, Antwortentwurf vorschlagen
│   Nein -> An Mensch zur manuellen Einordnung
│
├─ Erfordert die Lösung eine Aktion mit echten Konsequenzen
│  (Zugriff ändern, Konto löschen, Konfiguration anpassen)?
│   Ja  -> Nie automatisch ausführen, Freigabe durch Fachperson
│   Nein -> weiter
│
└─ Ist die Person nach Chatbot-Antwort zufrieden?
    Ja  -> Ticket schliessen (automatisch oder mit Bestätigung)
    Nein -> Eskalation an Mensch, mit vollem Kontext übergeben

Fallstricke in der Praxis

Automatisierung zu früh zu breit ausrollen. Wer gleich mit komplexen Aktionen startet statt mit Triage und Antwortvorschlägen, sammelt zuerst schlechte Erfahrungen statt Vertrauen im Team aufzubauen.

Wissensdatenbank vernachlässigen, aber Chatbot trotzdem einführen. Ein RAG-Chatbot auf veralteten oder lückenhaften Artikeln liefert veraltete oder erfundene Antworten - die Reihenfolge muss stimmen: erst Wissensbasis pflegen, dann Chatbot darauf aufsetzen.

Konfidenzwerte ignorieren. Wird jedes Klassifizierungsergebnis unabhängig von seiner Sicherheit automatisch übernommen, häufen sich stille Fehlzuweisungen, die niemand bemerkt, bis eine dringende Anfrage zu spät auffällt.

Keine Rückfallebene für “ich weiss es nicht” einbauen. Ein Chatbot, der bei jeder Frage irgendeine Antwort liefern muss, wird bei fehlendem Wissen erfinden statt zuzugeben. Die explizite Erlaubnis “sag ehrlich, wenn du’s nicht weisst” gehört in jede Systemanweisung.

Menschliche Nachkontrolle komplett einstellen, sobald es läuft. Ein System, das anfangs stichprobenartig geprüft wurde, aber nach ein paar guten Monaten ohne weitere Kontrolle läuft, verschlechtert sich unbemerkt - siehe Grenzen-Abschnitt oben.

Kurz zusammengefasst

• KI im IT-Support wirkt auf vier Stufen: Ticket-Triage, Antwortvorschläge, Wissensdatenbank-Chatbot und Automatisierung - mit steigendem Nutzen, aber auch steigendem Risiko.
• Triage über strukturierte Ausgaben mit Konfidenzwert ist der risikoärmste und meist beste Einstieg.
• Ein Wissensdatenbank-Chatbot funktioniert nur so gut wie die zugrunde liegende Wissensbasis - RAG bindet Antworten an echte Artikel statt an freies Modellwissen.
• Pixel, der Chat-Assistent dieses Wikis, zeigt das Muster in echt: Retrieval, ein Nachschau-Werkzeug für Details, und Eskalation nur mit expliziter Zustimmung.
• Echte Automatisierung gehört nur zu eng begrenzten, umkehrbaren Aktionen mit klarer Vorbedingung - alles andere bleibt an eine menschliche Freigabe gebunden.
• Halluzinationen, Fehlklassifizierung, Datenschutzfragen und schleichender Qualitätsverlust sind reale Grenzen, die dauerhafte Aufsicht statt einmaliger Prüfung brauchen.

Weiterlernen

• Microsoft Learn: Service Agent in Copilot Service nutzen
• Zendesk: KI-Agents für den Support
• Atlassian Rovo: Überblick
• NIST AI Risk Management Framework
• Microsoft Purview: Datensicherheit für die KI-Ära