IT-Service-Management: autonome Ticketlösung

IT-Service-Desks verbringen den Großteil ihrer Kapazität mit wiederkehrenden Anfragen: Passwort-Resets, Zugriffs- rechte, Software-Installationen, „VPN funktioniert nicht“. Ein LLM-Agent liest das Ticket, ruft Wissen und Verlauf ab, prüft über Werkzeuge den Zustand von Gerät und Konto der Nutzer und führt die Korrektur innerhalb strikter Berechtigungen selbst aus. Alles außerhalb seines Auftrags wird mit einer fertigen Zusammenfassung an einen Menschen eskaliert. Der Nutzen hängt weit mehr von sauberem Wissen, CMDB und Runbooks ab als vom Modell.

Problem & Nutzen

• Heute: Mitarbeitende im First-Level-Support ordnen Tickets ein, fragen fehlende Angaben nach, suchen Wissensartikel heraus und klicken sich durch Administrationskonsolen. Rückstau, Übergaben zwischen den Stufen und schlechte Ticketbeschreibungen bestimmen die Lösungszeit.
• KI-Nutzen: automatische Kategorisierung und Weiterleitung, Abfangen einfacher Anfragen im Portal oder Chat, autonome Ausführung risikoarmer Korrekturen, hochwertigere Eskalationen sowie automatische Lösungsnotizen und Entwürfe für Wissensartikel.
• Belege: Anbieter berichten von großen Einsparungen beim Abfangen von Anfragen und beim Schreiben von Notizen, doch die Zahlen stammen aus Anbieterunterlagen und Sekundär-Blogs und schwanken stark; unabhängige Quellen betonen, dass die Obergrenze von der Genauigkeit der CMDB sowie der Qualität von Runbooks und Wissen gesetzt wird, nicht vom Modell [1][2]. Messen Sie Ihre eigene Ausgangslage, bevor Sie einer genannten Prozentzahl trauen.

Varianten

• KMU / Managed-Service-Provider: KI im vorhandenen Helpdesk-Werkzeug für Sortierung, Antworten und einige sichere Automatisierungen (Passwort-Reset, Lizenzzuweisung).
• ITSM im Großunternehmen: Multiagenten-Aufbau auf ServiceNow oder Jira Service Management mit CMDB- Kontext, Schranken des Änderungsmanagements und Spezialisierung auf L1/L2.
• Öffentlicher Sektor / reguliert: Betrieb On-Premises oder in einer souveränen Cloud, strengere Freigabe- regeln, keine personenbezogenen Daten an Modell-APIs in Drittländern.
• Nur interner Mitarbeitendenassistent (ohne Aktionen): Chatbot, der nur antwortet, siehe CONV-004.

So funktioniert es

1. Eingang (Portal / Chat / E-Mail / Alarm)
2. Klassifikation (Kategorie, Priorität, Service, Sprache, Prüfung auf Duplikate/Großstörung)
3. Kontextabruf (Wissensdatenbank + ähnliche gelöste Tickets + CMDB + Benutzer-/Gerätestatus)
4. Plan (Reasoning-LLM wählt ein Runbook oder eine Werkzeugfolge)
5. Richtlinien-Schranke (Positivliste erlaubter Aktionen, Risikoklasse, Benutzeridentität verifiziert?)
6. Ausführung über Werkzeuge (Identitätsverwaltungs-API, MDM/Intune, Softwareverteilung, ITSM-API)
7. Verifikation (hat die Lösung gewirkt? Bestätigung durch Benutzer, Health-Check)
8. Abschluss mit Lösungsnotiz | Eskalation an L2 mit Zusammenfassung, Belegen, versuchten Schritten

• Sortierung: ein kleiner Klassifikator oder LLM mit Few-Shot-Beispielen; liegt die Sicherheit unter einer Schwelle, geht das Ticket in eine Warteschlange für Menschen.
• Abruf: Hybridsuche (BM25 + Embeddings + Reranker) über Wissensartikel, Runbooks und abgeschlossene Tickets; der Agent muss angeben, welchen Artikel er verwendet hat.
• Werkzeuge: als eng gefasste Funktionen bereitgestellt, zunehmend über das Model Context Protocol (MCP) mit OAuth-basierter Autorisierung; die Spezifikation selbst weist darauf hin, dass Werkzeuge beliebige Codeausführung darstellen und die Durchsetzung Pflicht der Umsetzenden ist [5]. Lese- und Schreib- werkzeuge trennen; Tokens je Aufgabe eingrenzen.
• Mensch-in-der-Schleife (Human-in-the-Loop): (1) Identitätsprüfung vor jeder Kontoaktion; (2) Freigabe für Aktionen mit mittlerem/hohem Risiko (Administratorrechte, Änderungen im Produktivsystem, Löschung); (3) Prüfung von Tickets mit geringer Sicherheit durch Techniker; (4) wöchentliche Stichproben automatisch geschlossener Tickets.

Datenaufbereitung

Benötigte Daten: historische Tickets mit Lösungen, Runbooks und Anleitungen, die Asset- und Konfigurationsdatenbank (CMDB), Benutzer- und Gruppenverzeichnisse sowie Softwarekataloge. Diese liegen im Ticketwerkzeug, in Wikis oder SharePoint, auf Dateiablagen und in den Köpfen einzelner Techniker. Typische Lücken: mit „erledigt“ geschlossene Tickets, doppelte oder widersprüchliche Wissensartikel, kein Kategorienschema, veraltete CMDB-Einträge, Tickets mit Passwörtern oder persönlichen Angaben sowie Agenten oder Dienstkonten mit zu vielen Rechten.

Schritte der Aufbereitung: (1) ein sauberes Kategorienschema und Prioritäten festlegen (PREP-019); (2) die 50 wichtigsten Runbooks und Artikel zu einer verbindlichen Wissensbasis zusammenführen und Dubletten aussortieren (PREP-013, PREP-017); (3) abgeschlossene Tickets auf typische Anfragearten und ihre Lösungsschritte auswerten (PREP-020); (4) Geheimnisse und personenbezogene Daten aus dem Tickettext entfernen, bevor indexiert wird (PREP-022); (5) Dienstkonten mit minimalen Rechten je Aktion einrichten und Berechtigungen aufräumen (PREP-023); (6) einen Testdatensatz realer Tickets mit erwartetem Ergebnis führen (PREP-018). Exporte über PREP-005.

Aufwand: mittel, etwa 25-35 %, überwiegend Bereinigung des Wissens. Beginnen Sie mit GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A - die KI-Funktionen eines vorhandenen ITSM- oder Helpdesk-Produkts (oder der Werkzeuge Ihres Managed-Service-Providers) kosten wenig und brauchen keine Entwicklung.
• Großunternehmen: Weg A - die vorhandene ITSM-Plattform erweitern (ihre eingebauten Agenten); nur für eigene Runbooks oder Werkzeuge, die die Plattform nicht erreicht, auf Weg B wechseln.
• Entwickler: Weg C - offene Frameworks und Modelle mit offenen Gewichten samt MCP-Werkzeugen erlauben volle Kontrolle darüber, was ein Agent ausführen darf.
• Öffentlicher Sektor: Weg C - souveränes Hosting und Vergaberegeln begünstigen selbst betriebene Lösungen oder deutsche/EU-Cloud-Aufbauten.

Weg A — Kaufen (für die meisten Organisationen empfohlen)

• ITSM-Plattformen mit Agenten: ServiceNow (Now Assist und AI Agents, Spezialist für den L1-Service-Desk; autonome Agenten liegen in höheren Lizenzstufen [1]), Atlassian Jira Service Management (virtueller Service-Agent und Rovo-Agenten im Help Center, Portal und Slack [2][3]), Freshworks Freshservice (Freddy AI), Ivanti Neurons, Zendesk, Moveworks (Agent für Mitarbeitendensupport, jetzt Teil von ServiceNow).
• EU-Anbieter: TOPdesk (NL), Matrix42 (DE), Zammad (DE, Open-Source-Kern), Znuny/OTRS- Fork (DE), USU (DE). Daten in EU-Hosting sind ein Verkaufsargument, doch die Tiefe der KI-Funktionen schwankt und sollte je Anbieter geprüft werden [4].
• A wählen, wenn: Sie bereits eines dieser ITSM-Werkzeuge betreiben und über brauchbare Wissensinhalte verfügen. Prüfen Sie den Datenstandort des LLM-Unterauftragsverarbeiters, Positivlisten für Aktionen, Prüfprotokoll und Preis pro Lösung oder pro Konversation.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: führende Reasoning-/Tool-Use-Modelle (Claude, Gemini, GPT) über EU-Regionen (Azure OpenAI EU, Vertex AI EU, AWS Bedrock Frankfurt) oder Mistral (EU-Anbieter).
• Orchestrierung: ein Agenten-Framework (LangGraph, Microsoft Agent Framework, OpenAI Agents SDK, Claude Agent SDK) oder n8n; MCP-Server für ITSM, Entra ID/Okta, Intune und Monitoring.
• Integration: ITSM-REST-APIs (ServiceNow Table API, Jira Service Management API, Freshservice- API), Webhooks bei Ticketerstellung, Teams-/Slack-Bot für den Dialog mit den Nutzern.
• B wählen, wenn: Ihr ITSM-Werkzeug nur schwache KI hat oder Sie maßgeschneiderte Werkzeuge und Richtlinien brauchen.

Weg C — Selbst betreiben (Open Source)

• Modelle: Modelle mit offenen Gewichten und Werkzeugaufrufen wie Qwen3, Mistral Small/Large, Llama, gpt-oss oder DeepSeek, betrieben mit vLLM oder Ollama; Embeddings wie bge-m3 oder Qwen3-Embedding.
• Stack: Zammad oder Znuny als Helpdesk, n8n oder Camunda für Workflows, pgvector/Qdrant für den Abruf, Langfuse für Traces, ein MCP-Gateway für Werkzeugrichtlinien.
• Hardware: HW3 für zuverlässige mehrstufige Werkzeugnutzung mit Modellen der 70-Mrd.-Klasse; HW2 genügt für Sortierung, Zusammenfassung und Abruf mit einem Modell von ca. 30 Mrd. Parametern, ist aber als autonomer Ausführer schwächer.

Weg D — Eigenes Training

Selten nötig. Feintunen Sie einen kleinen Encoder oder ein LLM für Ticket-Klassifikation und Weiterleitung auf mehreren tausend gelabelten historischen Tickets, oder destillieren Sie das Lösungsverhalten in ein kleines Modell, um Kosten zu senken.

Stand der Technik (2026)

• Vom Chatbot zum Akteur: ITSM-Anbieter unterscheiden beratende Assistenten (Vorschläge an den Techniker) von Agenten, die innerhalb konfigurierter Leitplanken handeln: Sortierung, Zuweisung, Korrektur per Runbook, Überwachung des Ergebnisses, Eskalation mit Übergabenotiz [1].
• Abfangen im Self-Service: Agenten im Help Center, Portal und Chat fangen Routineanfragen ab, bevor ein Ticket entsteht; abgerechnet wird oft pro unterstützter Konversation, auch bei später eskalierten [2][3].
• Grenzen und Fehlerbilder: falsche Runbook-Wahl bei mehrdeutigen Tickets; veraltete oder widersprüchliche Wissensartikel; halluzinierte Lösungsmeldungen („behoben“ ohne Überprüfung); Social Engineering gegen den Agenten (ein Angreifer gibt sich als Beschäftigter aus und verlangt einen Reset oder MFA-Reset); Prompt-Injection über Tickettext, E-Mail-Inhalte oder Anhänge, die Werkzeugaufrufe lenkt; zu weit gefasste Rechte von Dienstkonten. Aufgaben, die stark von der CMDB abhängen, scheitern, wenn die CMDB ungenau ist.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: CONV-004 (interner IT-Helpdesk-Assistent, Abrufschicht), LANG-012 (Ticket- Klassifikation), AGENT-001 (Posteingangssortierung), AGENT-002 (Workflow-Engine), AGENT-003 (Computer-Nutzung für Konsolen ohne APIs).
• Vor-/nachgelagert: CODE-010 (AIOps-Störungserkennung speist Tickets), SEC-001 (Sicherheits- alarme gehen ans SOC statt an L1), AGENT-009 (Bereitstellungsanfragen beim Onboarding), AGENT-013 (Multiagenten-Orchestrierung), AGENT-025 (Agenten-Governance, Beobachtbarkeit, Evaluierung).

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für Sortierung und Antwortvorschläge; 3-6 Monate bis zu sicheren autonomen Aktionen, weil Wissensbereinigung, CMDB-Reparatur und Runbook-Automatisierung den Aufwand bestimmen.
• Weg B: 3-6 Monate mit 2-4 Entwicklern; LLM-Kosten pro Ticket sind im Verhältnis zur Technikerzeit meist gering, die Arbeit für Werkzeugintegration und Evaluierung dagegen nicht.
• Kennzahlen: autonome Lösungsquote (verifiziert, nicht nur geschlossen), Abfangquote, mittlere Zeit bis zur Lösung, Wiedereröffnungsquote, Qualität der Eskalation (Bewertung durch Techniker), CSAT, Quote falscher Aktionen, Kosten pro Ticket, Abdeckung durch Wissensartikel.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung (Service-Level, Risikobereitschaft), die Leitung des IT-Service-Desks als Prozessverantwortliche, die Techniker (Anwender) von Anfang an, die IT-Sicherheit (was ein Agent ausführen darf: Passwort-Resets, Zugriffsrechte) und die oder den Datenschutzbeauftragte(n) ein (Tickets enthalten personenbezogene Daten; eine DSFA ist bei einfacher Sortierung meist nicht nötig, prüfen Sie dies aber, wenn Verhalten von Beschäftigten analysiert wird; AVV mit jedem Anbieter). Binden Sie den Betriebsrat vor dem Pilot ein.

Betriebsrat: ja. Ticketsysteme und Agentenprotokolle erfassen, wer was angefragt hat und wie schnell Techniker arbeiten, und sind damit objektiv zur Überwachung geeignet (§ 87 Abs. 1 Nr. 6 BetrVG, BAG-Rechtsprechung); § 90 Abs. 1 Nr. 3 verlangt frühzeitige Unterrichtung und § 80 Abs. 3 erlaubt einen KI-Sachverständigen. Eine Betriebsvereinbarung kann eine individuelle Leistungsbewertung aus Agentendaten ausschließen. In Behörden gilt der Personalrat.

Ergreifen Sie Maßnahmen zur Förderung der KI-Kompetenz (KI-Verordnung Art. 4): Schulen Sie Techniker darin, Agentenaktionen zu prüfen, und Beschäftigte darin, den Self-Service-Chat zu nutzen. Beginnen Sie mit einem Pilot für zwei oder drei risikoarme Anfragearten (Fragen zur Anwendung, Passwort-Resets) und einer Gruppe freiwilliger Techniker; weiten Sie erst aus, wenn Quote korrekter Lösungen und Nutzerzufriedenheit stabil bleiben. Kommunizieren Sie, dass der Agent wiederkehrende Tickets abnimmt, keine Stellen, und dass zerstörende oder privilegierte Aktionen immer eine menschliche Freigabe brauchen. Leitfäden: GUIDE-004, GUIDE-008, GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; für reinen IT-Support greift keine Kategorie aus Anhang III. KI- Kompetenz (Art. 4) gilt. Es wird begrenztes Risiko (Art. 50), wenn Nutzer mit einem Chatbot sprechen, der offenlegen muss, dass er eine KI ist. Vorsicht: Wird die Ausgabe des Agenten genutzt, um Leistung oder Verhalten von Beschäftigten zu überwachen oder zu bewerten (z. B. Beschäftigte nach Ticketvolumen ordnen, Emotionen aus dem Chat ableiten), können die Beschäftigungsregeln aus Anhang III greifen, und Emotionserkennung am Arbeitsplatz ist nach Art. 5 Abs. 1 Buchst. f verboten. Halten Sie den Agenten aus solchen Nutzungen heraus.
• DSGVO: Tickets enthalten Namen von Beschäftigten, Geräte- und Kontodaten und oft personenbezogene Daten im Freitext. Nötig sind eine Rechtsgrundlage, ein Auftragsverarbeitungsvertrag mit Modellanbietern, EU-Region, Datenminimierung (Daten vor dem LLM maskieren), Aufbewahrungsgrenzen und Beteiligung des Betriebsrats in Deutschland (BetrVG § 87 Abs. 1 Nr. 6, da das System technisch Verhalten überwachen kann).
• Sicherheit und Branchenregeln: NIS2 und DORA verlangen Zugriffskontrolle, Änderungsmanagement und Störungsbehandlung; der Agent gehört zum IKT-Risikobereich, und seine Rechte müssen dokumentiert werden. ISO/IEC 27001 und ITIL Change Enablement gelten für automatisierte Änderungen.
• Gegenmaßnahmen: Dienstkonten mit minimalen Rechten je Werkzeug; Aktionen auf Positivlisten mit Risiko- klassen; verpflichtende Identitätsprüfung und Bestätigung über einen zweiten Kanal bei Zugangsdaten- und MFA- Resets; Ticketinhalt als nicht vertrauenswürdige Eingabe behandeln (Injection-Filter, keine Werkzeugausführung direkt aus Nutzertext); vollständiges Prüfprotokoll; Notausschalter; Schattenmodus vor der Autonomie.

Erste Schritte

1. Exportieren Sie Tickets von 6-12 Monaten; clustern Sie sie und wählen Sie 3-5 Kategorien mit hohem Volumen und geringem Risiko (Passwort-Reset, Lizenzanfrage, VPN/WLAN, Drucker, Software-Installation).
2. Bringen Sie die Grundlagen in Ordnung: Wissensartikel von Dubletten befreien, Runbooks schreiben, CMDB-Daten für diese Kategorien prüfen.
3. Starten Sie im Schattenmodus: Der Agent schlägt Kategorie, Antwort und Aktion vor; die Techniker vergleichen.
4. Aktivieren Sie zuerst Werkzeuge nur zum Lesen und das Abfangen mit Antworten, dann Schreibaktionen hinter Freigaben, danach Autonomie für die bewährten Kategorien.
5. Legen Sie Richtlinienschranke, Ablauf der Identitätsprüfung und Notausschalter fest; binden Sie Betriebsrat und Datenschutzbeauftragte(n) früh ein; prüfen Sie wöchentlich Stichproben automatisch geschlossener Tickets.

Quellen

1. Btrnsfrmd - ServiceNow AI Agents & Now Assist in ITSM 2026 (secondary, vendor-feature overview) - https://btrnsfrmd.com/blog/servicenow-ai-agents-now-assist-itsm-2026/
2. Atlassian - How AI agents help reclaim your service desk for instant resolution - https://www.atlassian.com/blog/jira-service-management/rovo-agents-service-desk-instant-resolution
3. Atlassian Support - Set up your virtual service agent - https://support.atlassian.com/jira-service-management-cloud/docs/set-up-your-virtual-agent-in-jira-service-management/
4. EuropeanStack - TOPdesk review 2026 (EU-hosted ITSM) - https://europeanstack.com/software/topdesk
5. Model Context Protocol - Authorization specification - https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
6. Model Context Protocol - Authorization security considerations (2026-07-28) - https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Zammad open-source helpdesk - https://github.com/zammad/zammad