Zum Inhalt springen
Künstliche Intelligenz

ServiceNow Agents im ITSM: Was die Agentic Engine wirklich kann

ServiceNow Agents, ITSM Automation – ServiceNow Agents Dashboard im IT Operations Center mit ITSM Automation Übersicht
ServiceNow Agents übernehmen Routing und Triage – aber nur wenn Prozesse und Daten stimmen. (Symbolbild)

ServiceNow nennt es agentic. Die Branche jubelt. Doch was steckt wirklich hinter der neuen KI-Schicht im ITSM – und wo hört Produktvision auf, wo fängt echte Automatisierung an?

Klartext: Was ServiceNow auf Knowledge 2026 wirklich angekündigt hat

Auf dem Knowledge-Event 2026 hat ServiceNow eine klare Ansage gemacht: Schluss mit dem KI-Assistenten als Beiwerk. Das neue Framing heißt AI-nativ – und das bedeutet, dass künstliche Intelligenz nicht mehr neben dem Workflow sitzt, sondern darin handelt. Die offizielle Pressemitteilung vom 9. April 2026 spricht von einem vollständig AI-enabled Produktportfolio und nennt die ESM Foundation sowie neue Packaging-Tiers namens Foundation, Advanced und Prime als konkrete Neuerungen. Das sind keine vagen Roadmap-Ankündigungen mehr. Das ist Produktstrategie mit Preisschild.

Das Herzstück dieser Strategie: die Context Engine und die Workflow Data Fabric. Erstere liefert KI-Entscheidungen den nötigen Unternehmenskontext – Wissen, Assets, Zugriffsrechte, Entscheidungsgraphen. Letztere sorgt dafür, dass fragmentierte Daten aus verschiedenen Systemen zusammenlaufen. Beides zusammen soll autonome ServiceNow Agents erst verlässlich machen. Ob das in der Praxis funktioniert, hängt von der Datenqualität jedes einzelnen Kunden ab. Darüber redet ServiceNow erwartungsgemäß weniger laut.

Die harte Wahrheit: Was ServiceNow intern „Agentic Workflow Engine“ nennt, taucht in offiziellen Quellen eher als Sammelbegriff für agentic workflows, Context Engine und AI-native Packaging auf. Ein klar abgegrenztes Einzelprodukt mit diesem exakten Namen suchen Sie in der offiziellen Produktdokumentation vergebens. Das ist kein Geheimnis – es ist einfach die Realität von Enterprise-Plattformkommunikation, die Marketingsprache und technisches Substrat gerne vermischt.

Wie ITSM Automation mit Foundation Models zusammenwächst

Seien wir ehrlich: Der Wechsel von regelbasierter ITSM Automation zu KI-gestützten Agenten ist keine Kleinigkeit. Klassische ServiceNow-Automatisierung arbeitet mit Flows, Business Rules und Skripten. Diese Welt bleibt bestehen. Was neu hinzukommt, ist eine Schicht, in der Foundation Models – also Sprachmodelle wie GPT-4, Claude oder Gemini – im Kontext von Workflow-Daten entscheiden und handeln können.

Konkret bedeutet das für Incident Management: Ein Agent erkennt einen kritischen Alarm, gleicht ihn mit dem historischen CMDB-Kontext ab, priorisiert automatisch und ordnet einen Change-Request dem richtigen Approval-Pfad zu – ohne dass ein Mensch jeden Schritt manuell anstoßen muss. Das klingt nach Science-Fiction. Ist es aber nicht mehr, zumindest nicht vollständig. Die Analyse von Futurum Group zeigt, dass ServiceNow durch die Bündelung von Workflow-Daten eine Governance-Schicht für Enterprise-AI aufbauen kann – allerdings als Marktinterpretation, nicht als gemessenes Ergebnis.

Was tatsächlich belegt ist: Die Build-Agent-Skills für Entwickler sind laut ServiceNow-Pressemitteilung ab dem 15. April 2026 verfügbar. Damit können Teams eigene Agenten-Fähigkeiten innerhalb der Plattform definieren – also spezifische ITSM-Automatisierungsschritte als wiederverwendbare Agent Skills verpacken. Das ist ein handfester Schritt in Richtung programmierbarer IT Operations, kein vager Zukunftsentwurf.

ServiceNow Agents im Alltag: Incident, Change, Asset

Was ändert sich konkret für IT-Teams? Drei Bereiche stehen im Zentrum der neuen Agenten-Logik.

Incident Management: ServiceNow Agents sollen Incidents automatisch klassifizieren, Routing-Entscheidungen treffen und Lösungsvorschläge aus der Knowledge Base einbinden. Der Mensch bleibt im Genehmigungsprozess eingebunden – zumindest bei kritischen Changes. Für Routine-Incidents mit klaren Mustern ist vollständige Automatisierung das erklärte Ziel. Das entlastet First-Level-Support erheblich, wenn die Datenqualität stimmt.

Change Control: Hier ist Vorsicht angebracht. Autonome Änderungen an Produktivsystemen sind ein hochsensibles Feld. Die Plattform bietet Audit-Trail und Governance-Layer – aber ob ein Unternehmen bereit ist, Change-Entscheidungen an Modelle zu delegieren, ist eine Organisationsfrage, keine Technikfrage. Compliance-Teams werden hier genau hinschauen, besonders in regulierten Branchen.

Asset Management: Die Verknüpfung von CMDB-Daten mit der Context Engine eröffnet interessante Möglichkeiten: Agenten können Lifecycle-Status von Assets automatisch nachführen, Lizenzkonflikte erkennen oder Erneuerungszyklen anstoßen. IT Asset Management Software wird damit potenziell weniger manuell – vorausgesetzt, die Stammdaten sind sauber. Das bleibt die ewige Krux jedes CMDB-Projekts.

Was Unternehmen vor dem Einsatz tatsächlich vorbereiten müssen

Der häufigste Fehler bei der Einführung von Agenten-Automatisierung ist nicht technischer Natur – er ist organisatorisch. Viele IT-Abteilungen investieren in Plattform-Lizenzen, bevor sie die eigenen Prozesse auf Automatisierbarkeit geprüft haben. Das Ergebnis: Agenten, die auf halbgaren Daten operieren und Entscheidungen treffen, die niemand nachvollziehen kann.

Konkret empfiehlt sich vor jeder produktiven Agenten-Einführung eine strukturierte Prozessanalyse entlang drei Achsen. Erstens Datenqualität: Sind CMDB, Asset-Stammdaten und Knowledge-Base-Artikel aktuell, vollständig und konsistent? Zweitens Entscheidungsklarheit: Gibt es für die zu automatisierenden Prozesse dokumentierte Entscheidungsregeln – oder hängt die richtige Antwort noch im Kopf einzelner Experten? Drittens Fehlertoleranz: Was passiert, wenn ein Agent eine Fehlentscheidung trifft? Gibt es einen Rollback-Mechanismus, einen Eskalationspfad und klare Verantwortlichkeiten?

Unternehmen, die diese drei Fragen beantworten können, sind reif für produktive Agenten-Automatisierung. Alle anderen riskieren, mit dem neuen Packaging-Tier hauptsächlich die Komplexität zu erhöhen, nicht die Effizienz. Das gilt unabhängig davon, wie gut die Plattform technisch ist.

Die Governance-Frage: Wer kontrolliert die KI-Entscheidungen?

Hier liegt der eigentliche Knackpunkt. Autonome Agenten, die Tickets routen, Systeme ändern oder Ressourcen buchen, brauchen klare Leitplanken. ServiceNow adressiert das mit Audit-Trails, Zugriffskontrollen und definierten Freigabeprozessen. Der Deloitte Workflow Automation Outlook 2026 formuliert es so: Governance wird nicht zum Bremsklotz, sondern zum Wachstumsmotor. Das ist eine strategische Bewertung – aber sie trifft einen echten Nerv.

Warum? Weil autonome Schritte ohne Nachvollziehbarkeit in Enterprise-Umgebungen schlicht nicht skalieren. Eine KI, die einen Change-Request automatisch genehmigt, aber keinen verständlichen Entscheidungspfad hinterlässt, ist für jedes Audit eine Katastrophe. ServiceNow beantwortet das mit dem Konzept des Decision Graph in der Context Engine – jede Agentenentscheidung soll im Workflow-Kontext nachvollziehbar sein. Ob das in der Praxis lückenlos funktioniert, werden erste Produktiverfahrungen zeigen.

Meine Einschätzung: Die Governance-Architektur ist das Differenzmerkmal, das ServiceNow von generischen KI-Agenten-Frameworks abhebt. Wer LangChain oder AutoGen im Enterprise-Kontext einsetzt, baut diese Schicht selbst. Wer auf ServiceNow setzt, bekommt sie mitgeliefert – zum Preis der Plattformabhängigkeit. Das ist kein kostenloser Vorteil, aber ein echter.

ServiceNow Change Control Audit Trail für ITSM Governance und Compliance
Audit-Trail und Approval-Workflows: Ohne Governance-Schicht keine skalierbare Agentic Automation. (Symbolbild)

Multi-Tenant-Sicherheit und Compliance: Was die Plattform wirklich liefert

ServiceNow betreibt eine Multi-Tenant-Architektur, bei der Kundendaten strikt isoliert sind. Das gilt auch für die neuen KI-Schichten. Foundation Models wie GPT-4 oder Claude werden über API-Anbindungen eingebunden – Trainingsdaten eines Kunden fließen nicht in das Modell eines anderen. Das ist ein fundamentaler Unterschied zu Setups, bei denen Unternehmen Rohdaten direkt an externe Modell-APIs schicken.

Dennoch: Compliance-Teams sollten genau prüfen, welche Daten die Context Engine verarbeitet und wo diese liegen. Besonders für Unternehmen mit DSGVO-relevanten Prozessen oder branchenspezifischen Datenschutzanforderungen gilt: Die Plattform-Architektur allein ist keine Compliance-Garantie. Regionale Hosting-Optionen, Datenresidenz-Einstellungen und vertragliche Regelungen mit ServiceNow spielen eine entscheidende Rolle. Die Frage, welche Foundation-Modell-Anbieter in welcher Region welche Daten verarbeiten, bleibt ein offener Punkt, den Einkauf und Legal klären müssen.

Praktisch für IT-Governance-Teams: ServiceNow liefert Audit-Logs für Agenten-Aktionen, definierbare Approval-Workflows und rollenbasierte Zugriffssteuerung. Das sind keine neuen Konzepte für die Plattform – sie wurden auf die Agenten-Schicht ausgeweitet. Ob die Granularität dieser Logs ausreicht, um regulatorische Anforderungen in stark regulierten Branchen zu erfüllen, hängt vom konkreten Use Case ab.

Das Pricing-Problem: Assists, Tiers und die neue Paketlogik

Schluss damit, so zu tun, als ob Plattformstrategie und Preislogik getrennte Themen wären. ServiceNow hat ab dem 9. April 2026 seine Paketstruktur grundlegend umgestellt. Die alte Fünf-Tier-Logik (Standard, Pro, Pro Plus, Enterprise, Enterprise Plus) ist Geschichte. Die neuen Tiers heißen Foundation, Advanced und Prime.

Was das für ITSM Automation und ServiceNow Agents konkret bedeutet: KI-Funktionen sind nicht mehr als optionale Add-ons buchbar, sondern in die neuen Tiers integriert. Laut Crossfuze erhalten Foundation-ITSM-Fulfiller-Accounts 1.500 Assists pro Jahr; größere agentic actions kosten 150 Assists, kleinere 25. Diese Zahlen sind vertragsabhängig und sollten nie als Standardwert ohne Rückfrage beim eigenen Account Manager interpretiert werden.

Die harte Wahrheit für Bestandskunden: Wer heute auf Pro oder Enterprise Plus läuft, muss aktiv prüfen, was der Wechsel in die neue Struktur kostet und welche KI-Funktionen in welchem Tier enthalten sind. Das Versprechen von ServiceNow, alle Kunden AI-fähig zu machen, klingt attraktiv. Der Teufel steckt – wie immer – im Vertragswerk.

ServiceNow gegen den Wettbewerb: Wo die Plattform wirklich steht

Die ITSM-Automatisierungslandschaft hat sich in den vergangenen zwei Jahren erheblich verdichtet. Microsoft drängt mit Copilot Studio und Power Automate in denselben Markt, während Atlassian mit Jira Service Management und neu integrierten KI-Funktionen den Mid-Market unter Druck setzt. Das sind keine akademischen Wettbewerber – sie sind in vielen Unternehmen bereits installiert.

Der strukturelle Vorteil von ServiceNow liegt in der Tiefe der Workflow-Integration. Während Copilot Studio vor allem auf Microsoft-365-Datenpunkte zugreift, verbindet ServiceNow IT-, HR- und Customer-Service-Workflows auf einer gemeinsamen Datenbasis. Das ist für große Unternehmen mit komplexen, abteilungsübergreifenden Prozessen ein realer Differenzierungspunkt – weniger für mittelgroße IT-Abteilungen, die primär Ticket-Routing automatisieren wollen.

Der Nachteil: ServiceNow ist teuer, komplex und setzt erhebliche interne Expertise voraus. Wer keine dedizierten ServiceNow-Admins und -Entwickler hat, wird die Agentic-Funktionen nur langsam erschließen können, unabhängig davon, welchen Tier er bucht. Hier liegt ein echtes Gegenargument zur Plattformstrategie, das in Marketing-Präsentationen naturgemäß wenig Raum bekommt.

Warum nur 19 Prozent der Unternehmen aus KI Wert ziehen

Futurum Group zitiert in ihrer Analyse eine alarmierende Zahl: Nur 19 Prozent der Unternehmen ziehen derzeit tatsächlich Wert aus ihren KI-Investitionen. ServiceNow nutzt diese Zahl, um den eigenen Governance- und Kontextansatz zu begründen. Die Logik: Wenn KI nicht in bestehende Prozesse eingebettet ist und keine verlässlichen Daten bekommt, produziert sie Rauschen statt Ergebnisse.

Das ist eine legitime These. Sie erklärt auch, warum ServiceNow die IT Operations nicht einfach mit einem generischen Chatbot-Interface überzieht, sondern tief in Workflow-Daten integriert. Der Unterschied zwischen einem KI-Assistenten, der Vorschläge macht, und einem KI-Agenten, der Aktionen ausführt, ist fundamental. Ersterer ist ein Komfort-Feature. Letzterer ist ein Prozesseingriff. Das verlangt andere Reife – technisch und organisatorisch.

Seien wir ehrlich: Viele IT-Abteilungen sind noch nicht soweit. Die CMDB ist unvollständig. Change-Prozesse sind nicht sauber dokumentiert. Asset-Daten stimmen nicht mit der Realität überein. Wer unter diesen Bedingungen autonome Agenten freischaltet, automatisiert vor allem Fehler. ServiceNow liefert die Plattform. Die Grundlagenarbeit müssen Unternehmen selbst leisten.

Wo IT Operations wirklich profitieren kann – und wo nicht

Meiner Meinung nach ist die stärkste Anwendung für ServiceNow Agents derzeit im mittleren Automationsbereich: Prozesse, die zu komplex für einfache Regeln sind, aber zu strukturiert für vollständige menschliche Bearbeitung. Konkret: Incident-Triage bei bekannten Fehlermustern, automatisiertes Onboarding-Workflow-Routing, Lizenzverlängerungen im Asset Management oder die Vorbereitung von Change-Requests mit automatisch aggregiertem Impact-Assessment.

Wo die Grenzen liegen? Überall dort, wo Unsicherheit groß und Fehlerkosten hoch sind. Ein autonom ausgeführter Change an einer produktionskritischen Infrastrukturkomponente, der auf einem KI-Fehlurteil basiert, kann einen schwerwiegenden Outage verursachen. Kein Audit-Trail rettet das Geschäft hinterher. Hier braucht es weiterhin menschliche Entscheidung – ergänzt durch KI-Kontext, nicht ersetzt durch KI-Aktion.

IBM beschreibt in seiner Analyse zu KI-Agenten treffend, wo Erwartungen und Realität auseinanderdriften: Autonome Systeme funktionieren dann, wenn sie klar begrenzte Entscheidungsräume haben und Feedback-Loops für Korrekturen existieren. Das ist keine ServiceNow-spezifische Einschränkung – das ist der Stand der Technik.

Was bleibt also? ServiceNow hat mit der neuen AI-nativen Architektur eine ernsthafte Grundlage für skalierbare IT Operations gelegt. Context Engine und Workflow Data Fabric sind mehr als Buzzwords – sie adressieren das eigentliche Problem von KI in Unternehmen: fehlender, fragmentierter Kontext. Die Frage, die jedes IT-Team jetzt beantworten muss, ist nicht, ob es ServiceNow Agents einsetzen will. Die Frage ist: Sind unsere Prozesse, Daten und Governance-Strukturen reif genug, um KI-Aktionen zu vertrauen – und wie schnell können wir das ändern, wenn sie es noch nicht sind?

Was halten Sie von dem Thema? Hier können Sie mit anderen Leserinnen und Lesern ins Gespräch gehen.