KI für Change Management im ITSM: Was sich automatisieren lässt und was beim CAB bleibt

Kann KI beim Change Management im ITSM helfen?

Ja, solange Sie sie auf die richtige Hälfte der Aufgabe richten. Change Management, das ITIL 4 Change Enablement nennt, hat zwei Hälften: entscheiden, ob eine Änderung stattfinden soll, und mit dem umgehen, was danach passiert. KI ist gut im Lesen, Abgleichen und Zusammenfassen, das beides umgibt. Sie ist nicht das, was Sie entscheiden lassen wollen.

Ich baue die Helpdesk-Integrationen von eesel, darunter die für Jira Service Management, und verbringe deshalb viel Zeit in den ITSM-Queues anderer Leute. Das Muster, das ich an internen IT-Desks sehe, ist durchgehend gleich. Der Änderungsprozess selbst funktioniert auf dem Papier meist. Die Woche fressen das Hin und Her bei halb ausgefüllten Änderungsanträgen und der Montagmorgen, an dem 30 Tickets „VPN ist down“ melden und niemand am Service Desk weiß, dass am Samstag eine Firewall-Regel geändert wurde.

Dieses Bild ist das ganze Argument. Die drei Stufen, in denen KI hilft, sind die mit viel Dokumenten- und Abgleichsarbeit. Die zwei in der Mitte sind Urteilsvermögen und Hände auf der Tastatur, und sie bleiben bei Menschen.

Die Zahlen zeigen, warum die Ränder wichtiger sind als die Mitte:

Die DORA-Zeile sollte ändern, wie Sie darüber denken. DORA suchte nach Belegen, dass formale Freigabe die Änderungsfehlerquote senkt, und „fand keine Belege für diese Hypothese“. Wenn Sie also einen KI-Risikowert an dieselbe Gremiensitzung hängen, bekommen Sie eine schnellere Version eines Schritts, der Änderungen nicht sicherer gemacht hat. Die bessere Wette ist KI bei den Eingaben (ist dieser Antrag vollständig?) und bei den Ergebnissen (welche Tickets hat diese Änderung verursacht?).

Wo passt KI in jede Stufe einer Änderung?

KI passt zur Aufnahme, zur Risikoerklärung, zur CAB-Vorbereitung und zur Ticketwelle nach der Änderung. Freigabe und Umsetzung bleiben menschlich. So würde ich es aufteilen, mit dem, was die großen ITSM-Tools für jede Stufe liefern:

Zwei Dinge fallen an dieser Tabelle auf. Erstens hören alle Anbieter an derselben Linie auf: Die KI schlägt vor, ein Mensch reicht ein. Zweitens ist die Zeile „nach der Änderung“ am dünnsten. Dort lebt der Service Desk, und von dort kommt der größte Teil des Frusts in den Community-Threads, die ich gelesen habe.

Kann KI einen Änderungsantrag prüfen, bevor das CAB ihn sieht?

Ja, und hier würde ich anfangen, weil es risikoarm ist und das meiste Hin und Her spart. Eine Vollständigkeitsprüfung liest den Antrag und markiert, was fehlt, bevor ein Mensch Zeit darauf verwendet.

ServiceNow liefert die vollständigste Version davon. Der Change Quality Assessor bewertet fünf Teile einer Änderung (Umsetzungsplan, Backout-Plan, Testplan, Risiko- und Auswirkungsanalyse, Begründung) auf einer Skala von „Excellent“ bis „Incomplete“. Er prüft zuerst Ihr eigenes Änderungsrichtliniendokument und greift nur dann auf ähnliche abgeschlossene Änderungen zurück, wenn Sie keines haben. Diese Reihenfolge ist wichtig: Schreiben Sie die Richtlinie auf, und die KI bewertet nach Ihrem Standard statt nach dem, wie Ihre früheren Änderungen zufällig aussahen.

Warum der Aufwand? Weil die Rollback-Frage die ist, mit der CAB-Sitzungen ihre Zeit verbringen, und die Leute wissen das:

„Die machen ja keine echte Arbeit. Das ist einfach jemand, der dafür bezahlt wird, in einer einstündigen Besprechung zu sitzen und am Ende zu fragen: ‚Ach, gibt es einen Rollback-Plan?‘“

u/timmyotc, Reddit

Wenn die KI diese Frage in dem Moment stellt, in dem der Antrag eingereicht wird, muss die Besprechung es nicht mehr tun. Kleinere Teams ohne ServiceNow bekommen eine Version davon kostenlos: Ein Sysadmin in einer kleinen Firma schlug vor, die KI das Änderungsdokument selbst erstellen zu lassen („Was Sie tun, Rollback-Plan, Risiko usw.“), laut einem r/sysadmin-Thread. Eine Checkliste, die die KI ausfüllt, ist immer noch eine Checkliste, die jemand liest.

Ein praktischer Hinweis: An einem Desk mit vorgeschalteter Helpdesk-KI kann dieselbe Prüfung im Gespräch stattfinden. Wenn jemand in Slack fragt „Wie beantrage ich eine Änderung für die DNS-Umstellung?“, kann der Agent aus Ihrer Änderungsrichtlinie in Confluence antworten und gleich nach dem Backout-Plan fragen, sodass der Antrag vollständig ankommt. Das ist die Self-Service-Hälfte eines KI-IT-Helpdesks, angewandt auf Änderungen.

Kann KI das Risiko einer Änderung bewerten?

Teilweise. Die nützliche Version erklärt einen Risikowert und holt die Historie dahinter. Vorsicht ist bei der Version geboten, die Ihnen eine Zahl hinwirft und erwartet, dass Sie ihr vertrauen.

Schauen Sie genau hin, was jedes Tool tut:

• ServiceNow: Der Risikowert selbst stammt aus einer Umfrage mit regelbasierten Schwellenwerten (0 bis 25 Low, 26 bis 50 Moderate, 51 und höher High). Die KI-Schicht sitzt obendrauf: Sie erklärt den Wert anhand ähnlicher Änderungsanträge und der Incidents, die sie verursacht haben, und sie kann die Risikoantworten vorausfüllen, damit ein Mensch sie vor dem Einreichen prüft.
• Jira Service Management: Die KI-Risikobewertung schreibt eine erzählende Zusammenfassung mit einem Konfidenzwert und einer Einstufung als Low, Medium oder High. Sie prüft offene Incidents am betroffenen Service, fehlgeschlagene Deployments, in den letzten 90 Tagen abgelehnte Änderungen am selben Service und ob Test- und Rollback-Pläne existieren.
• Freshservice: Richtlinien zum Änderungsrisiko sind regelbasiert und bewerten jeden Faktor von 0 bis 10 mit optionaler Gewichtung. Freddys KI-Anteil besteht darin, ähnliche frühere Änderungen zu finden, nicht darin, den Wert zu erzeugen.

Meine Einschätzung: Behandeln Sie die Risikoausgabe der KI als Briefing, nicht als Urteil. Die Dokumentation von Jira ist hier ungewöhnlich direkt. Die Funktion „genehmigt oder lehnt Änderungen nicht automatisch ab“ und liefert keine „garantierten oder deterministischen Vorhersagen“. Außerdem gibt es eine Eigenheit, die Sie kennen sollten, bevor sich Ihr CAB darauf verlässt: Die Bewertung wird pro Nutzer erzeugt, basierend darauf, was die jeweilige Person sehen darf, sodass zwei Genehmiger für dieselbe Änderung unterschiedliche Zusammenfassungen bekommen können.

Und gehen Sie mit realistischen Erwartungen an die Genauigkeit heran. ServiceNows KI kennt Ihre Historie nur, wenn Ihre Historie in ServiceNow liegt und richtig verknüpft ist. Ein Praktiker erklärte, warum Demos besser aussehen als die Produktion:

„Die Demo-Instanzen, die der Vertrieb nutzt, sind schwer richtig hinzubekommen. Es gibt dort keine echten ‚historischen‘ Daten, also nichts, was dem Machine-Learning-Modell beibringt, wohin etwas gehören sollte.“

u/Excited_Idiot, Reddit

Umgekehrt gilt das Gleiche. Wenn Ihre Änderungen nicht mit Services und Konfigurationselementen verknüpft sind, hat der Teil „ähnliche Änderungen und ihre Incidents“ nichts zum Abgleichen. Jira sagt ausdrücklich, dass die Konflikterkennung nur funktioniert, „wenn zusammenhängende Änderungen richtig mit Services oder Assets verknüpft sind und geplante Start- und Endtermine enthalten“.

Sollte KI das Change Advisory Board ersetzen?

Nein, aber sie sollte schrumpfen, was das CAB ansieht. Das ehrliche Problem der meisten CABs ist nicht, dass Leute schlecht entscheiden. Es ist, dass sie über alles entscheiden und deshalb alles nur überfliegen:

„So lief es in der Theorie bei den großen Firmen, für die ich als Freelancer gearbeitet habe. In der Praxis war es aber ein Raum voller anderer Techniker, die darauf warteten, dass ihr Name aufgerufen wird, gefolgt von einem Stempel. Ich glaube nicht, dass ich je gesehen habe, dass eine Änderung von Kollegen infrage gestellt wurde.“

u/Unable-Entrance3110, Reddit

Es gibt auch einen Folgeeffekt. Wer Änderungen um eine wöchentliche Besprechung bündelt, sorgt dafür, dass alle auf einmal landen:

„Das Beste daran, Dinge durchs CAB zu schicken, die da gar nicht hingehören, ist, dass sich dadurch Änderungen häufen, die alle zur selben Zeit passieren ... nach der CAB-Sitzung. Wenn jetzt etwas kaputtgeht, kann es eines von Dutzenden Dingen sein, die in den 15 Minuten nach der Sitzung eingespielt wurden.“

esikich, Hacker News

Die aktuelle Empfehlung von DORA zur Verschlankung der Änderungsfreigabe geht in dieselbe Richtung: Hören Sie auf, „alle Änderungen gleich zu behandeln“, und betreiben Sie „laufende Analysen, um riskante Änderungen früh zu erkennen und zu markieren, damit sie zusätzlich geprüft werden können“. Das ist eine Sortieraufgabe, und Sortieren kann KI gut. Ein nützliches CAB-Paket sieht so aus:

1. Standardänderungen, per Vorlage vorab genehmigt und nur zur Kenntnis aufgelistet. Jira Service Management genehmigt Standardänderungen bereits automatisch per Automatisierungsregel, und ServiceNow behandelt sie als vorab autorisiert.
2. Unvollständige Anträge, die vor der Sitzung zurückgeschickt werden, mit benannten Lücken.
3. Konflikte, die markiert werden: zwei Änderungen am selben Service im selben Fenster oder eine Änderung innerhalb eines Freeze.
4. Die wenigen riskanten, jede mit einer einabsätzigen Zusammenfassung und den ähnlichen früheren Änderungen, die schiefgingen.

ServiceNows Änderungszusammenfassung liest 17 Felder einer Änderung (darunter Umsetzungs-, Test- und Backout-Pläne) in ein kurzes Briefing ein, und der Conflict Assessor gleicht betroffene CIs mit Blackout- und Wartungsfenstern ab. Atlassians Prevention Center bündelt eine Änderungszusammenfassung, eine Abhängigkeitskarte und eine Kalenderkollisionsprüfung, befindet sich aber noch in einem offenen Early-Access-Programm. Prüfen Sie also Ihren Plan, bevor Sie darauf aufbauen.

Das Gremium verbringt dann seine Stunde mit Punkt 4. Das ist die Version eines CAB, die DORA „Prozessarchitekt und Informationsleuchtturm“ statt Türsteher nennt.

Was passiert am Service Desk, nachdem eine Änderung schiefgeht?

Die Tickets kommen, bevor jemand sie mit der Änderung verbunden hat. Diese Stufe halte ich für ein IT-Team für die wichtigste, und sie ist die, die die ITSM-Anbieter am wenigsten abdecken.

Das Ausmaß kann gewaltig sein. Als CrowdStrike am 19. Juli 2024 ein fehlerhaftes Content-Update ausrollte, war es etwa 78 Minuten live, bevor es zurückgenommen wurde, laut eigener Auswertung, und Microsoft schätzte, dass es 8,5 Millionen Windows-Geräte betraf. Die meisten internen Änderungen sind viel kleiner, aber das Bild am Service Desk ist dasselbe: eine Ursache, Dutzende Tickets, die jeweils ein anderes Symptom beschreiben.

Die Leute, die diesen Desk betreuen, beschreiben es genauso:

„Ich weiß nicht, ob dir das hilft, weil ich im Service Desk bin, aber bei uns fühlt es sich genauso an. Jedes Mal, wenn wir etwas ausrollen oder aktualisieren, müssen wir trotz Tests usw. fast sofort anfangen, Brände zu löschen. Das ist so verdammt anstrengend.“

u/rootpl, Reddit

Und die schlimmste Version ist die Änderung, die niemand erwähnt hat. In einem r/sysadmin-Thread lief eine genehmigte Änderung an einem Samstag, an dem das Werk eigentlich geschlossen sein sollte; der Produktionsleiter war nicht informiert worden, dass es ein doppelter Produktionstag war, und der Nutzer bezifferte die Kosten auf 1,5 Mio. $ für einen dreistündigen Ausfall.

Das kann die KI in dieser ersten Stunde tun:

1. Das Muster erkennen. Mehrere neue Tickets zum selben Service in kurzer Zeit sind ein Signal, dieselbe Idee wie bei der Ticket-Deduplizierung.
2. Aktuelle Änderungen an diesem Service nachschlagen. In Jira Service Management sind Änderungen Issues, daher beantwortet eine JQL-Suche nach Änderungen am betroffenen Service der letzten Tage die Frage „hat sich etwas geändert?“ in Sekunden.
3. Eine interne Notiz hinterlassen an jedem Ticket, die den Schlüssel der wahrscheinlichen Änderung nennt, damit der Agent, der es übernimmt, bei der Ursache startet statt bei null.
4. Eine Statusantwort senden an alle Betroffenen, einmal entworfen und einmal freigegeben. Das ist dieselbe Aufgabe wie bei Statusseiten-Updates und Kommunikation bei Major Incidents, nur durch eine Änderung ausgelöst.
5. Den Änderungsverantwortlichen informieren mit der Ticketzahl, damit die Rollback-Entscheidung auf Basis von Belegen fällt.

Freshservice hat die nächstliegende native Funktion. Der Initiating Change Suggester reiht Änderungen, die in den letzten 14 Tagen abgeschlossen wurden und einen Incident verursacht haben könnten, und ein Agent verknüpft die richtige von Hand. Er ist im Early Access und braucht das Copilot-Zusatzpaket.

Das 14-Tage-Fenster ist eine sinnvolle Leitplanke. Eine Änderung vom letzten Monat ist selten die Ursache der Tickets von heute Morgen, und eine KI, die sie trotzdem vorschlägt, erzeugt nur Rauschen.

Welche ITSM-Tools haben KI für Change Management?

ServiceNow hat den umfangreichsten Satz, Jira Service Management die am besten dokumentierte Risikobewertung und Freshservice die stärkste Verbindung vom Incident zurück zur Änderung. Eine Helpdesk-seitige KI wie eesel deckt die Ticketwelle und die Gespräche mit Antragstellern ab, egal in welchem ITSM der Änderungsdatensatz liegt. So vergleichen sie sich bei den Details, die ein Käufer tatsächlich prüft:

Quellen: ServiceNow ITSM packages, Atlassian pricing und Freshservice pricing. Atlassians Seite hat einen Schalter für Teamgröße und Abrechnung, prüfen Sie also den aktuellen Preis für Ihre Platzzahl.

ServiceNow Otto (Now Assist) für ITSM

Die Dokumentation von ServiceNow nennt die generative KI-App inzwischen „ServiceNow Otto for IT Service Management“, während die Preisseite noch Now Assist sagt. Sie listet acht agentische Änderungsabläufe, darunter Konfliktbewertung, Qualitätsbewertung, Terminplanung, CI-Vorschläge und konversationelle Änderungserstellung.

Was mir gefällt: Die Leitplanken sind ausdrücklich. Standardmäßig sind alle Datensätze der Agent-Workflows schreibgeschützt, und einen davon selbstständig laufen zu lassen bedeutet, ihn zu duplizieren, zu aktivieren und ihm einen Trigger zu geben. Die Agents für Konflikte, Qualität und Terminplanung werden von Hand aufgerufen. Worauf Sie sich einstellen sollten: Change Management ist nicht im Foundation-Paket, und der Posten „AI Agents for ITSM“ taucht nur in Prime auf, planen Sie also ein Angebotsgespräch ein. Die Stimmung unter Praktikern ist gemischt: Eine Antwort in r/servicenow nennt die KI „mehr Verkaufsgespräch als Realität“, eine andere erwartet, dass sie innerhalb eines Jahres ordentlich wird. Kostendetails finden Sie in unserer Aufschlüsselung der ServiceNow-Preise.

Unsere Einschätzung: Wählen Sie es, wenn Sie bereits ServiceNow ITSM Advanced oder Prime nutzen und Ihre CMDB in ordentlichem Zustand ist. Allein der Quality Assessor ist es wert, eingeschaltet zu werden.

Jira Service Management mit Rovo

Atlassians KI-Risikobewertung, die auf Rovo basiert (der Agent dahinter heißt jetzt Ops Expert), liest verknüpfte Wissensdatenbank-Artikel, URLs in der Änderungsbeschreibung und angebundene Deployment-Pipelines. Sie teilt das Risiko in technische und operative Dimensionen auf und schlägt Maßnahmen zur Risikominderung vor; wer eine annimmt, erzeugt eine Folgeaufgabe, die mit der Änderung verknüpft ist.

Was mir gefällt: Sie kann eine einfache statische Codeanalyse auf verknüpften Pull Requests ausführen, was für Teams, deren Änderungen Deployments sind, ein echter Vorteil ist. Das Deployment Gating kann eine Bitbucket- oder Jenkins-Pipeline anhalten, bis die Änderung genehmigt ist. Worauf Sie sich einstellen sollten: Jede Änderungsfunktion liegt seit dem 16. Oktober 2024 in Premium oder Enterprise, sie ist nicht HIPAA-konform, und die Ausgabe variiert je nach Berechtigungen pro Nutzer. Einen größeren Überblick geben die KI von Jira Service Management und Rovo.

Unsere Einschätzung: am besten für Teams, bei denen die meisten Änderungen aus CI/CD kommen. Wenn Sie im Standard-Plan sind, ist die KI-Risikobewertung ein Grund, Premium durchzurechnen, kein Grund, das Tool zu wechseln.

Freshservice mit Freddy AI

Freshservices Änderungs-KI dreht sich um Historie statt um Vorhersage. Der Similar Change Suggester zeigt passende Änderungen bis zu 6 Monate zurück, jeweils mit ihrem Risikoniveau und der Anzahl verknüpfter Incidents.

Was mir gefällt: „Genau diese Änderung hat beim letzten Mal 2 Incidents verursacht“ ist das Überzeugendste, was Sie einem Genehmiger vorlegen können, und es steht direkt im Änderungsdatensatz. Worauf Sie sich einstellen sollten: Die Risikobewertung ist regelbasiert, ein KI-Builder für Risikoumfragen ist für eine künftige Version gelistet und nicht live, und beide Änderungs-KI-Funktionen brauchen das Copilot-Zusatzpaket. Plattformen vergleichen? Siehe Freshservice vs. ServiceNow und Freshservice vs. Jira Service Management.

Unsere Einschätzung: stark für mittelgroße IT-Teams, die bereits für Pro zahlen. Schalten Sie den Initiating Change Suggester ein, sobald Ihr CSM ihn aktivieren kann.

eesel auf der Service-Desk-Seite

eesel ist kein ITSM und führt Ihren Änderungsdatensatz nicht. Es ist ein KI-Teammitglied, das in Ihre Helpdesk-Queue einsteigt, daher liegt seine Aufgabe im Change Management auf der Ticketseite: Fragen beantworten, wie man eine Änderung beantragt, die Ticketwelle nach einer Änderung bearbeiten und den Änderungsverantwortlichen auf dem Laufenden halten. Es verbindet sich nativ mit Jira Service Management und Zendesk. In JSM übernimmt es neue Anfragen und Kommentare, antwortet oder hinterlässt eine interne Notiz und kann Issues mit JQL durchsuchen, mit Labels versehen, zuweisen und im Workflow weiterschieben. Es liest Issues live, statt aus Ihrer Jira-Historie zu lernen, und sein Wissen stammt aus Quellen wie Confluence.

Für ServiceNow oder Freshservice gibt es keinen eingebauten Konnektor. Der Weg führt über die API des Tools per Network Access oder über einen MCP-Server, falls Sie einen betreiben, richten Sie sich also darauf ein, das selbst einzurichten. Mehr dazu in KI für ITSM-Tools.

Unsere Einschätzung: Setzen Sie es ein, wenn der Schmerz am Service Desk liegt, nicht im CAB. Es wird pro bearbeitetem Ticket abgerechnet statt pro Agentenplatz.

Wie richte ich KI für Change Management ein?

Beginnen Sie mit dem günstigsten, sichersten Schritt und arbeiten Sie sich nach außen vor. Diese Reihenfolge würde ich bei einem typischen internen IT-Team einhalten, und sie entspricht der Reihenfolge, in der Ihr Vertrauen in die KI wachsen sollte:

1. Schreiben Sie Ihre Änderungsrichtlinie auf. Ein Dokument: was jeder Änderungstyp braucht, wie ein guter Backout-Plan aussieht, wer was genehmigt, wann die Freeze-Fenster sind. ServiceNows Quality Assessor liest zuerst ein Richtliniendokument, und jede andere KI arbeitet damit ebenfalls besser. Legen Sie es dort ab, wo Ihre KI es lesen kann, etwa in Confluence oder Google Drive.
2. Schalten Sie die Vollständigkeitsprüfung im Vorschlagsmodus ein. Lassen Sie die KI einige Wochen lang Lücken in neuen Anträgen markieren, ohne etwas zu blockieren. Zählen Sie, wie oft ein Mensch ihr zustimmt.
3. Verknüpfen Sie Änderungen mit Services und Terminen. Konflikterkennung, Abgleich ähnlicher Änderungen und die Ticketverknüpfung nach der Änderung hängen alle davon ab. Das ist der unglamouröse Schritt, der den Rest zum Funktionieren bringt.
4. Verbinden Sie den Service Desk mit dem Änderungsdatensatz. Ob Freshservices Suggester, eine JQL-Suche in JSM oder ein Helpdesk-Agent: Das Ziel ist dasselbe, nämlich dass ein neuer Incident gegen aktuelle Änderungen an diesem Service geprüft wird. Testen Sie es zuerst an alten Tickets; ich würde eine Simulation gegen frühere Tickets aus Ihrer letzten schlechten Änderung laufen lassen, bevor ich ihm live vertraue.
5. Halten Sie Schreibaktionen hinter einer Freigabe. Alles, was eine Nachricht an alle sendet, ein Ticket weiterschaltet oder den Änderungsdatensatz berührt, sollte erst einen Menschen fragen, bis Sie gesehen haben, dass es eine Weile richtig lag. In eesel läuft jede Aktion eigenständig, fragt zuerst nach oder bleibt aus, und Freigaben können als Karte in Slack eintreffen.
6. Behandeln Sie die Anweisungen der KI ebenfalls als Änderung. Wenn die Regeln des Agents ändern, wie Tickets bearbeitet werden, versionieren Sie sie und rollen Sie sie wie jede andere Änderung aus. Swiftreg führt seine eesel-Anweisungen als nummerierte Releases, die über das eigene Verfahren ausgerollt statt live bearbeitet werden, genau die Gewohnheit, die Sie von einem IT-Team erwarten möchten.
7. Messen Sie drei Zahlen. Zurückgeschickte unvollständige Anträge, die Änderungsfehlerquote (DORAs Definition: Deployments, die einen Hotfix oder Rollback brauchen) und Tickets pro fehlgeschlagener Änderung. Wenn die dritte Zahl sinkt und im CAB niemand mehr Rollback-Plänen hinterherläuft, funktioniert es. Mit einem Aufbau für Support-Reporting lässt sich die dritte leicht abrufen.

Was sollte KI im Change Management niemals tun?

Halten Sie diese Liste kurz und setzen Sie sie in den Berechtigungen des Tools durch, nicht nur in einem Prompt:

• Eine normale Änderung oder eine Notfalländerung genehmigen oder ablehnen. Keines der drei großen ITSMs erlaubt es, und Sie sollten keine Umgehung bauen.
• Die Änderung ausführen. Terminvorschläge sind in Ordnung; die Produktion anzufassen nicht.
• Die Ursache eines Incidents feststellen. Sie kann die wahrscheinliche Änderung nennen. Ein Mensch bestätigt.
• Tickets als gelöst schließen, weil ein Rollback stattgefunden hat. Fragen Sie beim Antragsteller nach; ein Rollback kann den Service reparieren und trotzdem den kaputten Zustand eines Nutzers zurücklassen.
• Die Pläne im Änderungsdatensatz eigenmächtig bearbeiten. ServiceNows autonomer Quality Agent ist hier ein gutes Vorbild: Er speichert seine Bewertung und Notizen „ohne Werte in Feldern des Änderungsantrags zu setzen“.

Der gemeinsame Nenner ist Verantwortlichkeit. Wenn etwas schiefgeht, braucht die Nachbesprechung eine namentlich benannte Person, die entschieden hat, und „die KI hat es genehmigt“ ist keine Antwort, die Ihre Auditoren akzeptieren. Einen tieferen Blick auf Zugriffsebenen bietet der Leitfaden zur KI-Sicherheitsprüfung.

eesel an Ihrem IT-Service-Desk ausprobieren

Wenn Änderungen bei Ihrem Service Desk als Stapel verwirrter Tickets ankommen, kann eesel als Teammitglied in dieser Queue sitzen. In Jira Service Management durchsucht es aktuelle Änderungen am betroffenen Service, hinterlässt an jedem neuen Ticket eine interne Notiz mit dem Schlüssel der wahrscheinlichen Änderung und entwirft eine Statusantwort, die ein Mensch freigibt. Es beantwortet auch „Wie beantrage ich eine Änderung?“ in Slack aus Ihrer eigenen Richtlinie. InDebted setzt es als First Responder an einem internen JSM-Desk ein und lässt es 15 % der Tickets selbstständig lösen, mit 55 % als Ziel. Bei Zendesk nutzt Cactus Club Cafe es für internen Tech-Support, wo es in einem Monat 790 Antworten entwarf, indem es den Runbooks des Teams Schritt für Schritt folgte.

Es gibt einen kostenlosen Plan mit 100 Credits, und die bezahlten Pläne beginnen bei 299 $ im Monat für 500 Credits, ohne Gebühr pro Platz. Testen Sie eesel an den Änderungstickets des letzten Monats und sehen Sie, was es markiert hätte.