Weniger Sortierarbeit im IT-Servicedesk, mehr Zeit für Tickets, die Menschen brauchen

Der Servicedesk bearbeitet jeden Tag dieselben Anliegen: Passwörter, VPN, Drucker, Postfächer, Software und Berechtigungen. Jedes Ticket wird gelesen, sortiert, oft an das falsche Team gegeben und dann mit einem Artikel beantwortet, den jemand erst finden muss. Die KI übernimmt das Lesen, das Sortieren und den ersten Entwurf. Ihr Team kümmert sich um die Tickets, bei denen es gebraucht wird, und der Second Level bekommt Tickets, in denen schon steht, was er wissen muss.

IT-Abteilungen haben spät angefangen und holen auf. In der Bitkom-Umfrage 2026 unter Unternehmen ab 20 Beschäftigten setzen 9 % der Unternehmen, die KI nutzen, sie in der IT-Abteilung ein, nach 2 % in der Bitkom-Studie 2025, der stärkste relative Anstieg aller Bereiche. IT-Dienstleister sind weiter: In einer Umfrage von Kaseya mit Foundry aus dem Jahr 2025 unter Systemhäusern, Managed Service Providern und IT-Dienstleistern in der DACH-Region war Ticketing und Helpdesk der am weitesten entwickelte KI-Anwendungsfall, 58,4 % nutzen dort KI. Die beiden Umfragen befragen unterschiedliche Gruppen, die Zahlen lassen sich also nicht direkt vergleichen.

• Tickets landen beim ersten Mal beim richtigen Team, statt weitergereicht zu werden.
• Wiederkehrende Anliegen bekommen eine Antwort aus Ihrer Wissensdatenbank, mit verlinktem Artikel.
• Der Second Level bekommt Tickets mit Gerät, Fehlermeldung und den Schritten, die schon versucht wurden.
• Die Bereitschaft findet Runbook, letzte Änderungen und ähnliche Störungen an einer Stelle.
• Sie sehen die Wirkung in Ihren eigenen Zahlen: Stunden pro Ticket und weitergeleitete Tickets, gemessen vorher und nachher.

Der Agent erledigt die Vorarbeit an jedem Ticket und übergibt das Ergebnis an einen Menschen. Der Schritt der Zuweisung ist erprobt. 2020 berichtete produktion.de, dass das IT-Unternehmen BTC mit SAP Service Ticket Intelligence im Betrieb eine Trefferquote von etwa 80 % bei den Arbeitsgruppen und 90 % bei der Priorität erreichte, und nannte das Problem dahinter: die Arbeit mit „veralteten oder fehlerbehafteten Ticketinformationen“. Dieses System stammt aus der Zeit vor den heutigen großen Sprachmodellen (LLMs), den Modellen hinter Werkzeugen wie ChatGPT. LLMs ergänzen die Antwortentwürfe, die Rückfragen und die Suche in Runbooks, und genau diesen Teil bauen wir.

• Klassifizierung und Zuweisung: Kategorie, Priorität und Bearbeitergruppe, Dubletten werden der offenen Störung zugeordnet, zu der sie gehören.
• Antwortentwürfe für wiederkehrende Anliegen wie VPN, Drucker, Postfächer und Software, gebaut aus Ihren Wissensartikeln und gelösten Tickets, mit verlinkten Quellen, damit Ihr Team sie prüfen kann.
• Rückfragen, wenn etwas fehlt, etwa Gerätename, genaue Fehlermeldung oder ein Screenshot, bevor das Ticket den Second Level erreicht.
• Passwort- und Berechtigungsanfragen: Der Agent prüft den Antrag gegen Ihren Rollenkatalog, bereitet die Änderung vor und schickt sie an die zuständige Person zur Freigabe. Passwörter werden über Ihr bestehendes Self-Service mit Multi-Faktor-Authentifizierung zurückgesetzt.
• Runbook-Assistent für den IT-Betrieb: Bei einem Alarm oder einer Störung findet er das passende Runbook, letzte Änderungen und ähnliche frühere Störungen, führt die freigegebenen lesenden Prüfungen aus und schlägt die nächsten Schritte vor.
• Pflege der Wissensdatenbank: Nach einem gelösten Ticket ein Entwurf für einen Wissensartikel zur Prüfung, dazu eine Liste der Artikel, nach denen Tickets immer wieder geöffnet werden.

Jede Entscheidung, die Zugriffe, Systeme oder die Antwort an Nutzer verändert, bleibt bei Menschen. Der Agent bereitet vor, Ihr Team gibt frei.

• Antworten an Nutzer: Ihr Team sendet, ändert oder verwirft jeden Entwurf. Automatische Antworten für benannte Kategorien mit geringem Risiko gibt es erst, wenn die gemessene Qualität es rechtfertigt und Sie es entscheiden.
• Berechtigungen: Führungskraft oder Dateneigentümer geben jede Rolle oder Gruppe frei. Der Agent bereitet die Änderung in Active Directory oder Entra ID nur vor, angewendet wird sie über Ihren Identitätsprozess.
• Passwörter: Der Agent sieht, setzt oder versendet nie ein Passwort. Ein Chat, der Passwörter zurücksetzt, ist ein offenes Tor für Social Engineering, deshalb bleiben Zurücksetzungen beim Self-Service oder bei einer Person, die die Identität prüft.
• Änderungen an Produktivsystemen: Standardmäßig führt der Runbook-Assistent nur lesende Prüfungen aus. Jeder Befehl, der ein System verändert, braucht die Freigabe einer benannten Person und läuft durch Ihr Change-Management.
• Sicherheitsvorfälle, Major Incidents und alles, was personenbezogene Daten einer Person betrifft, gehen direkt an Menschen, ohne Antwortentwurf.

Wir binden den Agenten über die Schnittstelle an das Ticketsystem an, das Sie nutzen, zum Beispiel ServiceNow, Jira Service Management, TOPdesk oder SAP Service Cloud, und an Ihre Wissensdatenbank in Confluence oder SharePoint. Monitoring, CMDB und Verzeichnisdienst kommen dazu, wo eine Aufgabe sie braucht. Migriert wird nichts. Gearbeitet und dokumentiert wird weiter im Ticketsystem.

• Werkzeuge mit je einer Aufgabe: Ticket lesen, Kategorie setzen, interne Notiz anlegen, Gruppenmitgliedschaft vorschlagen. Jedes läuft unter einem eigenen Dienstkonto mit den geringsten nötigen Rechten. Wo es passt, nutzen wir MCP, einen Standard, über den ein Agent mit eigenen Berechtigungen auf ein System zugreift.
• Tickets gelten als nicht vertrauenswürdige Eingabe. Text in einem Ticket kann nicht ändern, was der Agent darf, und interne Admin-Anleitungen erscheinen nie in Antworten an Nutzer.
• Betrieb in Ihrem eigenen Cloud-Konto in einer EU-Region oder auf eigenen Servern mit einem Open-Weight-Modell, also einem Modell, dessen Gewichte Sie selbst betreiben können. Tickets, Wissen und Protokolle bleiben in Ihrer Umgebung.
• Ein LLM-Gateway, ein einziger kontrollierter Zugang zu allen Modellen mit Schlüsseln, Budgets und Protokollen, damit Sie die Kosten pro bearbeitetem Ticket sehen.
• Kaufen oder bauen: Mehrere ITSM-Suiten verkaufen eigene KI-Funktionen. Wenn Ihre Suite Klassifizierung und Antwortentwürfe auf Ihren Daten abdeckt und der Betrieb zu Ihren Vorgaben passt, beginnen Sie dort, und wir können sie an Ihren Tickets testen. Ein eigener Aufbau lohnt sich, wenn Antworten Quellen außerhalb des Ticketsystems brauchen, etwa SharePoint, Dateiablagen, Monitoring oder die CMDB, wenn Daten auf eigenen Servern bleiben müssen oder wenn eine Anfrage durch mehrere Systeme und eine Freigabekette läuft.

Vor dem Go-live durchläuft das System einen Abnahmetest mit einer Auswahl Ihrer früheren Tickets, bei denen die richtige Kategorie, das richtige Team und die richtige Antwort bekannt sind. Wir berichten die Ergebnisse je Kategorie, damit Sie sehen, wo es verlässlich ist und wo nicht.

Nach dem Go-live messen wir an Ihren eigenen Tickets, was für Sie zählt, vorher und nachher: Stunden pro Ticket, Anteil weitergeleiteter Tickets, Wiedereröffnungsquote und Zeit bis zur ersten Antwort. Dieselben Tests laufen nach jeder Änderung an Modell, Prompt oder Wissensdatenbank erneut. Sie bekommen Runbooks für den Betrieb des Agenten selbst, und entweder übernimmt Ihr Team ihn mit Code und Tests, oder wir betreiben ihn.

• Zuweisung: Anteil der Tickets mit richtiger Kategorie, Priorität und richtigem Team, verglichen mit der heutigen Zuweisung durch Ihren Servicedesk.
• Antworten: richtiger Inhalt, eine Quelle, die ihn belegt, und keine nur intern bestimmten Informationen in Antworten an Nutzer.
• Sicherheit: manipulierte Tickets, die dem Agenten Anweisungen geben wollen, Bitten, ein Passwort per Chat zurückzusetzen, und Berechtigungsanträge ohne Freigabe. Erwartet wird eine Ablehnung oder Übergabe.
• Schattenbetrieb: Danach arbeitet der Agent neben Ihrem Servicedesk an echten Tickets mit, seine Vorschläge werden aufgezeichnet, aber nicht angewendet, und wir vergleichen sie mit dem, was Ihr Team getan hat.

Tickets enthalten personenbezogene Daten: Namen, Geräte, Standorte und manchmal Details, die man lieber nicht teilt. Alles wird in Ihrer Umgebung verarbeitet, und Sie entscheiden, was gespeichert wird und wie lange, beraten von Ihrem Datenschutzbeauftragten und Ihren Juristen. Dieser Abschnitt beschreibt die technische Seite und ist keine Rechtsberatung.

Der Betriebsrat ist hier für zwei Gruppen gefragt: die Beschäftigten im Servicedesk und alle, die ein Ticket öffnen. Der Bitkom-Leitfaden „KI und Mitbestimmung“ von 2026 hält fest, dass § 87 Abs. 1 Nr. 6 BetrVG greift, wenn ein System objektiv geeignet ist, Leistung oder Verhalten zu überwachen, unabhängig von der Absicht. Ein System, das Tickets pro Person oder Bearbeitungszeiten pro Servicedesk-Mitarbeiter auswerten könnte, fällt darunter. Wir bauen dagegen: keine Auswertungen pro Person, pseudonymisierte Kennungen in den Protokollen, vereinbarte Aufbewahrungsfristen und ein kurzer KI-Steckbrief, den Ihr Betriebsrat lesen kann.

Ein IT-Support-Assistent gehört nicht zu den Hochrisiko-Anwendungen, die die KI-Verordnung (AI Act) in Anhang III aufführt, etwa Personalauswahl oder Kreditwürdigkeitsprüfung. Die Transparenzpflicht aus Artikel 50 gilt seit dem 2. August 2026: Menschen müssen erfahren, dass sie mit einem KI-System sprechen, also sagt der Chat das.

Beginnen Sie mit einem Ticketstrom, der häufig, wiederkehrend und risikoarm ist, etwa Softwareanforderungen oder Berechtigungsanträge für Standardrollen. Das ergibt einen klaren Ausgangswert und eine Wirkung, die man sieht.

• Exportieren Sie eine Auswahl früherer Tickets aus diesem Strom, mit Kategorie, Team und der endgültigen Antwort, die jedes bekam.
• Messen Sie den Ausgangswert: Stunden pro Ticket, weitergeleitete Tickets und Wiedereröffnungsquote.
• Stimmen Sie Freigabepunkte und Protokollierung vor dem ersten Test mit IT-Sicherheit, Datenschutzbeauftragtem und Betriebsrat ab.
• Führen Sie den Abnahmetest durch, dann den Schattenbetrieb, dann Antwortentwürfe, die Ihr Team freigibt.