ServiceNow AI Agents im ITSM: 5 belegte Fakten, die zählen

ServiceNow präsentiert AI Agents für ITSM – und verspricht, dass bis zu 90 Prozent der Tickets künftig autonom gelöst werden. Klingt gut. Zu gut? Klartext: Was steckt wirklich hinter Now Assist und den neuen AI Agents, was ist belegt, und was ist Hersteller-Marketing?

Zwei Produkte, die viele verwechseln: Now Assist vs. AI Agents

Seien wir ehrlich: In den meisten Pressetexten zu ServiceNow wird alles unter „Now Assist“ zusammengeworfen. Das ist falsch. Und dieser Fehler kostet IT-Entscheider später echtes Geld.

ServiceNow trennt intern sauber zwischen zwei Produktkategorien. Now Assist ist generative KI für die Assistenz: Incident-Zusammenfassungen, Wissensartikel automatisch befüllen, Chat-Unterstützung für Agenten, kontextbezogene Antworten. Der Mensch entscheidet, der Mensch agiert. Die KI liefert Vorschläge.

AI Agents sind eine andere Stufe. Laut ServiceNows offizieller Produktdokumentation handelt es sich um Entitäten, die menschenähnliche Intelligenz nachbilden, indem sie Large Language Models nutzen – und dabei mehrstufige Abläufe eigenständig ausführen. Kein Mensch tippt zwischendurch. Der Agent prüft, analysiert, entscheidet, setzt um, dokumentiert.

Wer diese Unterscheidung verschleift, plant auf Sand. Die IT-Governance-Anforderungen für assistierende GenAI sind eine andere Hausnummer als für autonome Agenten, die tatsächlich Änderungen in Produktivsystemen durchführen. Schluss damit, beides in einen Topf zu schmeißen.

Wie AI Agents einen Ticket-Lifecycle wirklich abarbeiten

Das Demo-Szenario, das ServiceNow in einem offiziellen YouTube-Video zeigt, macht deutlich, wie das agentic AI-Modell im ITSM konkret aufgeteilt ist. Drei spezialisierte Rollen greifen ineinander:

• Case Agent: Prüft eingehende Ticketdetails, Screenshots, Metadaten – strukturiert den Fall.
• Triage Agent: Durchsucht frühere Lösungen, Logs, Known-Error-Datenbanken und Handbücher – liefert Kontext.
• Resolution Agent: Bestätigt die Root Cause, spielt Fixes ein, aktualisiert alle Datensätze.

Das ist kein Monolith-Agent, der alles kann. Das ist ein Multi-Agent-System mit klarer Rollenaufteilung. Jeder Agent hat eine definierte Kompetenz. Meiner Einschätzung nach ist genau dieser Ansatz das Entscheidende: Spezialisierung statt Generalist-KI, die in komplexen ITSM-Landschaften unweigerlich an Grenzen stößt.

In diesem Demo-Szenario löst ServiceNow nach eigenen Angaben 90 Prozent der Tickets autonom. Nur die wirklich komplexen Fälle landen beim Engineer – und der bekommt dann keinen Rohticket-Haufen, sondern bereits analysierte Fälle mit Log-Auswertung und konkreten Handlungsempfehlungen. Die harte Wahrheit dabei: Diese 90-Prozent-Zahl stammt aus einem Vendor-Demo mit spezifischem Setup, nicht aus einem unabhängigen Branchen-Benchmark. Unkritisch generalisieren wäre ein Fehler.

Die belegten Zahlen: Was ServiceNow intern selbst misst

Wer konkrete Kennzahlen sucht, findet sie. ServiceNow hat in einer offiziellen Infografik eigene interne KPIs veröffentlicht – Stand März 2025, mit Aktualisierungen Richtung 355 Millionen US-Dollar annualisiertem Wert. Wichtiger Hinweis: Das sind Zahlen aus ServiceNows eigenem Betrieb, nicht aus Kundenumgebungen.

Was intern gemessen wurde:

• 3 Millionen Stunden freigespielte Arbeitszeit durch AI-Agent-Einsatz
• 76 Prozent der IT-Support-Anfragen werden im Self Service erledigt
• 72 Prozent der Customer-Support-Anfragen ohne menschliche Eskalation
• 53 Prozent Produktivitätsgewinn im Server-Patch-Management
• 20 Prozent höhere Entwickler-Produktivität, 25 Prozent Produktivitätsplus im Order Management

Beeindruckend. Aber: Diese Zahlen lassen sich nicht eins zu eins auf andere Unternehmen übertragen. ServiceNow hat eine eigene, gewachsene Plattformlandschaft und optimierte Prozesse. Wer diese Werte im eigenen Business-Case unhinterfragt übernimmt, baut auf Wunschdenken.

Trotzdem: Für Entscheider, die ROI-Argumente brauchen, sind diese Zahlen als Orientierungsrahmen nützlich – sofern man sie transparent als Herstellerangaben kennzeichnet. Das Server-Patch-Beispiel mit 53 Prozent Effizienzgewinn ist besonders relevant, weil Server-Patching zu den klassischen, gut strukturierten ITSM-Prozessen gehört, bei denen ITSM Automation nachweislich funktioniert.

ITSM Automation: Wo AI Agents stark sind – und wo nicht

Klartext: AI Agents sind kein Universalwerkzeug. Die Einsatzbereiche, in denen ServiceNow AI Agents tatsächlich Traktion zeigen, haben gemeinsame Merkmale. Sie sind standardisiert, gut dokumentiert und risikoarm.

Konkrete Felder, in denen ITSM Automation durch AI Agents Sinn macht:

• Standard Changes mit klaren Genehmigungsregeln und niedrigem Risikoprofil
• Incident-Triage bei bekannten Fehlermustern und vorhandener Known-Error-Datenbank
• Password Resets, Account Provisioning, Software-Installations-Requests
• Server-Patching nach festgelegten Wartungsfenstern
• Onboarding-Workflows mit definierten Checklisten

Wo AI Agents an Grenzen stoßen: hochgradig individuelle Entscheidungen, politisch sensible Change-Prozesse, Situationen mit unvollständiger CMDB oder schlechter Datenqualität. Der ServiceNow-Implementierungspartner servistio formuliert es treffend: AI Agents funktionieren als „autonomer Mitarbeiter im Hintergrund“ – aber der Mensch muss Ausnahmen und Governance-Fragen weiter verantworten.

Enterprise Service Management bedeutet in der Praxis auch: HR-Prozesse, Procurement, Facility Management. ServiceNow AI Agents lassen sich konzeptionell auf diese Bereiche übertragen – Employee Requests, Genehmigungskaskaden, Asset Management. Das Incident-Triage-Modell gilt strukturell genauso für HR-Fälle wie für IT-Störungen. ITSM Automation endet also nicht an der IT-Grenze.

Was IT-Teams vor der Einführung wirklich klären müssen

Die Beratung exccon listet in ihrer Analyse der ServiceNow AI Agents sechs kritische Erfolgsfaktoren für die Einführung auf. Ich würde einen siebten ergänzen: Change-Resistenz im eigenen Team. Wer seine First-Level-Mitarbeiter nicht mitnimmt, verbrennt die besten AI Agents sinnlos.

Die offiziellen Faktoren, ohne die kein Rollout funktioniert:

1. Klare Ziele: Welche Prozesse sollen automatisiert werden, mit welchem Messziel?
2. Datenqualität: Eine fragmentierte CMDB oder fehlende Wissensdatenbank tötet jeden AI Agent sofort.
3. Systemintegration: Monitoring-Tools, Log-Quellen, CMDB – alles muss sauber angebunden sein.
4. User Experience: Self-Service-Portale müssen intuitiv sein, sonst nutzt niemand sie.
5. Kontinuierliches Monitoring: Fehlerraten der Agents, Halluzinationen, Falschentscheidungen – ohne KPIs keine Steuerung.
6. Menschliche Kontrolle: Besonders bei sensiblen Daten und kritischen Changes braucht es definierte Freigabe-Workflows.

Hinzu kommt die Frage nach dem ServiceNow-Release. AI Agents sind in den aktuellen Pro- und Enterprise-Tiers des ITSM verfügbar, aber nicht in jedem Lizenzpaket automatisch dabei. Wer noch auf älteren Releases läuft, muss Upgrade-Kosten einrechnen. Genaue aktuelle Preise sollte man direkt mit ServiceNow verhandeln, da KI-Features oft als separate Add-ons lizenziert werden – Drittquellen sind hier schnell veraltet.

Governance und der AI Control Tower: Kein optionales Feature

Ein Punkt, der in vielen Artikeln zu ServiceNow AI Agents untergeht: ServiceNow bewirbt aktiv einen sogenannten AI Control Tower – eine zentrale Steuerungsebene für Strategie, Governance, Management und Performance aller KI-Einsätze im Unternehmen. Das ist keine Marketingbroschüre, das ist eine operative Notwendigkeit.

Wer AI Agents in ITSM-Produktivprozesse entlässt, die auf sensible Infrastruktur-Daten, Sicherheitslogs oder Personalinformationen zugreifen, braucht saubere Antworten auf drei Fragen. Erstens: Wer darf der Agent eigentlich auf welche Daten zugreifen? Zweitens: Wie wird protokolliert, was der Agent entschieden hat? Drittens: Was passiert, wenn der Agent eine Fehlentscheidung trifft?

Fehlend. In der Breite der ITSM-Teams, die ich beobachte, ist das Governance-Framework für autonome KI-Systeme immer noch der schwächste Punkt – weit hinter der technischen Umsetzung. Ein Change, den ein AI Agent ohne menschliche Freigabe ausrollt und der ein Produktivsystem kippt, ist kein Softwarefehler. Das ist ein Governance-Versagen.

ServiceNow liefert hier Werkzeuge, aber kein schlüsselfertiges Konzept. Das müssen Unternehmen selbst aufbauen, idealerweise bevor der erste Agent produktiv geht. Das Thema KI-Agenten-Reife und warum viele Unternehmen trotz großem Interesse noch kaum autonome Agenten produktiv einsetzen, beschreibt der Befund aus Enterprise-Analysen treffend: Wollen ist nicht dasselbe wie Können.

Der Umsatz-Faktor: Warum ServiceNow AI Agents auch eine Lizenzfrage sind

Seien wir ehrlich: ServiceNow treibt die AI-Agent-Story nicht nur aus technischem Altruismus voran. Now Assist ist einer der zentralen Abo-Wachstumsmotoren des Unternehmens. CFO Gina Mastantuono hat als Ziel ausgegeben, dass Now Assist bis 2026 jährlich über eine Milliarde US-Dollar neues Vertragsvolumen generieren soll. Für ein einzelnes Quartal prognostizierte ServiceNow 3,26 Milliarden US-Dollar Subscription-Umsatz – deutlich über Analystenerwartungen, zu erheblichem Teil getrieben durch Now-Assist-Nachfrage.

Was bedeutet das für IT-Einkäufer? KI-Features in ServiceNow sind strategisch in neue Subscription-Tiers eingebettet. Wer AI Agents für ITSM Automation einsetzen will, zahlt mehr als für klassisches ITSM. Die Mehrkosten müssen durch belegbare ROI-Hebel gerechtfertigt sein: Ticket-Durchlaufzeiten, First-Contact-Resolution-Raten, reduzierte Eskalationskosten, freigespielte Stunden.

Für mittelgroße IT-Abteilungen bedeutet das konkret: Vor dem Signing einer AI-Agent-Lizenz sollte ein Prozess-Assessment stehen. Welche Ticket-Kategorien sind standardisiert genug für echte Automatisierung? Wie viele Tickets pro Monat fallen in diese Kategorie? Was kostet eine manuelle Bearbeitung heute – und was spart ein AI Agent realistisch? Wer diese Hausaufgaben macht, kann den Business Case verteidigen. Wer sie nicht macht, erklärt in zwölf Monaten dem CFO, warum die Lizenzkosten den Nutzen übersteigen.

Pilotprojekte richtig aufsetzen: Ein pragmatischer Einstiegspfad

Viele IT-Abteilungen scheitern nicht an der Technologie, sondern an einem zu ambitionierten Rollout-Scope. Wer AI Agents für ITSM Automation zum ersten Mal einführt, sollte mit einem eng begrenzten Piloten starten – und dabei von Anfang an Messkriterien definieren, keine Erfolgsstorys.

Ein sinnvoller Einstiegspfad sieht in der Praxis so aus: Im ersten Schritt werden zwei bis drei Ticket-Kategorien mit dem höchsten Standardisierungsgrad identifiziert. Das sind typischerweise Password Resets, VPN-Zugangsprobleme mit bekanntem Lösungsmuster oder Software-Installations-Requests mit klarem Genehmigungsworkflow. Diese Kategorien eignen sich deshalb, weil die Fehlerfolgen bei einer Fehlentscheidung des Agents begrenzt und reversibel sind.

Im zweiten Schritt wird für diese Kategorien eine Baseline erhoben: durchschnittliche Bearbeitungszeit heute, Eskalationsrate, Nutzerzufriedenheit, Kosten pro Ticket. Ohne diese Ausgangswerte lässt sich später kein Verbesserung belegen – und ohne belegte Verbesserung gibt es keine Budgetfreigabe für den Ausbau.

Im dritten Schritt geht der Pilot mit explizitem Human-in-the-Loop in Betrieb: Der AI Agent schlägt eine Lösung vor, ein First-Level-Agent bestätigt. Erst nach vier bis sechs Wochen stabilem Betrieb und nachweislich korrekten Empfehlungen wird die Autonomie schrittweise erhöht. Dieser graduierte Ansatz klingt langsam, ist aber der einzige Weg, der das Vertrauen der beteiligten Mitarbeiter und der Führungsebene gleichzeitig aufbaut.

Wichtig dabei: Pilot-Ergebnisse ehrlich kommunizieren. Wenn der Agent in 15 Prozent der Fälle falsch liegt, ist das kein Scheitern, sondern ein Kalibrierungssignal. Wer das intern als Versagen rahmt, tötet die Bereitschaft zu weiteren KI-Projekten – bevor sie überhaupt begonnen haben.

Die Datenbasis als strategischer Hebel: CMDB und Wissensdatenbank im Fokus

Es gibt einen Faktor, der den Unterschied zwischen einem AI Agent, der echten Mehrwert liefert, und einem Agent, der permanent eskaliert oder falsch entscheidet, mehr bestimmt als jede LLM-Architektur: die Qualität der zugrundeliegenden Daten. Im ITSM-Kontext bedeutet das konkret die Configuration Management Database und die Wissensdatenbank.

Eine CMDB, in der 30 Prozent der Einträge veraltet, doppelt gepflegt oder schlicht falsch sind, ist für einen AI Triage Agent aktiv schädlich. Der Agent greift auf fehlerhafte Konfigurationsdaten zurück, zieht falsche Schlüsse über Abhängigkeiten und schlägt Lösungen vor, die am tatsächlichen System vorbeigehen. Das ist kein KI-Problem. Das ist ein Datenproblem, das KI sichtbar macht, weil sie die schlechten Daten in Sekundenbruchteilen und in großem Maßstab verarbeitet.

Dasselbe gilt für die Wissensdatenbank. Wissensartikel, die vor drei Jahren geschrieben wurden, technisch überholt sind und nie überarbeitet wurden, trainieren den Agent auf veraltete Lösungsansätze. ServiceNow Now Assist kann Wissensartikel automatisch generieren und vorschlagen – aber auch das setzt voraus, dass ein Qualitätsprozess für die Review und Freigabe dieser Artikel existiert.

Die strategische Konsequenz: CMDB-Sanierung und Wissensdatenbank-Audit sollten nicht nach dem KI-Rollout stattfinden, sondern davor. Wer diese Reihenfolge umdreht, investiert in einen AI Agent, der auf schlechten Fundamenten arbeitet – und sich dann wundert, warum die Automatisierungsquoten weit unter den Vendor-Versprechen liegen. ServiceNow AI Agents sind so gut wie die Datenbasis, auf der sie operieren. Das ist kein Disclaimer, das ist die zentrale operative Realität jeder ITSM Automation.

Site Reliability Engineering und der Blick nach vorn

ITSM Automation durch ServiceNow AI Agents ist kein isoliertes Phänomen. Der breitere Kontext ist die Konvergenz von ITSM und Site Reliability Engineering: Agenten, die nicht nur Tickets bearbeiten, sondern aktiv Systemstabilität überwachen, Anomalien detektieren und präventive Maßnahmen einleiten. Was heute als Incident-Triage-Agent beginnt, ist morgen ein proaktiver Reliability-Agent, der Störungen verhindert, bevor ein Ticket überhaupt entsteht.

Diese Entwicklung geht über das hinaus, was ServiceNow heute in der Demo zeigt. Aber die Plattform-Architektur und die Multi-Agent-Logik sind darauf ausgelegt. Case-Triage-Resolution ist die erste Ausbaustufe. Change Automation auf Basis von Risk-Scoring und historischen Daten ist die zweite. Autonome Anomalie-Detection mit proaktiver Remediation ist die dritte.

Meiner Einschätzung nach werden Enterprise-IT-Teams, die heute keine strukturierten Grundlagen legen – CMDB-Qualität, klare Prozessdokumentation, Governance-Frameworks –, in dieser dritten Ausbaustufe komplett abgehängt. Enterprise Service Management beginnt nicht mit dem KI-Agenten. Es beginnt mit sauberen Daten.

Was bleibt zu klären?

ServiceNow Now Assist AI Agents kombinieren eine bewährte Enterprise-Plattform mit agentic AI – das ist real, das ist messbar, und das ist kein Hype ohne Substanz. Aber die Erwartungshaltung muss stimmen. 90 Prozent Ticket-Autonomie ist eine Vendor-Zahl aus einem optimierten Demo-Szenario, keine Garantie. 76 Prozent Self-Service ist ServiceNows internes Ergebnis, nicht Ihr Startpunkt.

Wer ITSM Automation mit AI Agents ernsthaft angehen will, muss zuerst die eigene Prozessqualität ehrlich bewerten. Dann Governance-Strukturen aufbauen. Dann pilotieren, messen, skalieren. In dieser Reihenfolge.

Was bleibt: Wie weit sind Sie bereit, autonomen Agenten in Ihrer Infrastruktur echte Entscheidungsgewalt zu geben – und welche Kontrollen haben Sie dafür bereits aufgebaut?