Mit dem neuen ServiceNow-Plugin für ChatGPT sollten Teams im Incident-Management prüfen, ob sich jede aus einem Gespräch veranlasste Änderung an einem Datensatz nachvollziehen lässt. Dazu gehören die anfordernde Person und das Ergebnis, das ServiceNow tatsächlich gespeichert hat. Eine Gesprächsoberfläche erleichtert die Eingabe von Änderungen. Die Anforderungen an die Nachweise bleiben dabei bestehen.
OpenAI und ServiceNow kündigten am 28. Oktober 2026 ihre erweiterte Partnerschaft an. OpenAI teilt mit, dass das ServiceNow-MCP-Plugin in seinem Marketplace verfügbar ist. Beschrieben werden das Auffinden ähnlicher Incidents, die Bewertung von Änderungsrisiken und das Aktualisieren eines ServiceNow-Datensatzes aus ChatGPT heraus, wobei Action Fabric bestehende Geschäftsregeln und Berechtigungen anwendet.
Das verfügbare Plugin klar von der Roadmap trennen
Das Plugin ist der bereits verfügbare Teil einer größeren Ankündigung. Erweiterte Plugin-Funktionen werden bis Ende 2026 erwartet. Sprachfunktionen werden für das erste Quartal 2027 erwartet; die gemeinsamen Sicherheitsfunktionen sollen im Januar 2027 im Early Access verfügbar sein und im zweiten Quartal allgemein verfügbar werden. Codex in AI Workflow Factory wird für 2027 erwartet.
Die verbreitete Ankündigung von ServiceNow sagt, dass ServiceNow der Ort bleibt, an dem Workflow-Aktionen ausgeführt und gesteuert werden. Beide Ankündigungen beschreiben beabsichtigtes Produktverhalten und künftige Termine. Sie belegen nicht, welche Audit-Felder, Aufbewahrungseinstellungen oder durchgängigen Nachweise in der konkreten Installation eines Kunden verfügbar sind.
Eine einzelne Datensatzänderung rekonstruieren
Nach Einschätzung von Maetra sollte die Rollout-Prüfung einer Datensatzaktualisierung bis zu ihrem gespeicherten Ergebnis folgen. In einem hypothetischen Incident-Workflow bittet ein Operator einen Assistenten, einen Incident dem Netzwerkteam zuzuweisen und eine Work Note hinzuzufügen. Eine prüfende Person sollte diese Anforderung von jeder zusätzlichen Änderung unterscheiden können, die das Modell möglicherweise vorgeschlagen hat.
Erfassen Sie die Incident-Kennung, die beabsichtigten Feldänderungen und die Identität, unter der der Vorgang ausgeführt wird. Verbinden Sie die Anforderung über einen stabilen Korrelationsverweis mit der daraus resultierenden ServiceNow-Aktivität, sofern die Integration einen solchen Verweis unterstützt. Legen Sie fest, welches System welchen Teil des Nachweises bereitstellt, bevor Sie annehmen, dass ein Konversationstranskript bereits die gesamte Kette liefert.
Prüfen Sie dann den gespeicherten Datensatz. Sind die beabsichtigte Zuweisung und die Notiz erhalten geblieben? Wurde ein anderes Feld ebenfalls geändert? Wurde die Aktualisierung abgelehnt, nur teilweise ausgeführt oder von einer anderen Person überholt? Diese Fragen betreffen das beobachtete Ergebnis, auch wenn die anfordernde Person berechtigt war, die Aktion zu verlangen.
Konversationskontext aus dem falschen Feld heraushalten
Eine Incident-Konversation kann Fakten, Hypothesen und aus Alerts kopiertes Material zusammenführen. Legen Sie fest, welche dieser Eingaben zu einer Work Note, einer Zuweisungsanweisung oder einem anderen persistenten Feld werden dürfen. Eine spekulative Erklärung darf nicht stillschweigend zu einem bestätigten Incident-Befund werden, wenn der Assistent den Datensatz schreibt.
Bitten Sie die verantwortliche Anwendungseignerin oder den verantwortlichen Anwendungseigner, mehrdeutige Anforderungen zu testen. Beispielsweise kann ein Operator um die Vorbereitung einer Aktualisierung zur Prüfung bitten, während in derselben Konversation eine alternative Zuweisung besprochen wird. Der Test sollte zeigen, dass der Assistent zwischen Entwurf und Schreiben unterscheidet und das beabsichtigte Ziel identifiziert. Er sollte außerdem zeigen, wie der Nutzer erfährt, dass ein Schreibvorgang fehlgeschlagen ist.
Dies sind empfohlene Abnahmetests, keine Behauptungen über einen Mangel des neuen Plugins. Aus der öffentlichen Ankündigung geht nicht hervor, wie jede einzelne Installation mit Mehrdeutigkeit, parallelen Änderungen oder jeder denkbaren Berechtigungskonfiguration umgeht.
Den Abruf von Nachweisen um das Incident-Team herum gestalten
Die Rekonstruktion erfolgt oft erst, nachdem der ursprüngliche Operator bereits zur nächsten Aufgabe gewechselt ist. Das Incident-Team sollte wissen, wo es die Anforderung, die Ausführungsidentität, die exakte Änderung und das nachgelagerte Ergebnis erhält. Benennen Sie eine verantwortliche Stelle für Lücken zwischen dem Konversationsprotokoll und der eigenen Historie von ServiceNow.
Definieren Sie Zugriff und Aufbewahrung nach der Sensibilität der Nachweise. Bewahren Sie genügend Kontext auf, um die Änderung zu erklären, und vermeiden Sie zugleich unnötige Duplizierung von Zugangsdaten, personenbezogenen Informationen oder detaillierten Sicherheitsbefunden in allgemeinen Protokollen. Prüfen Sie Export- und Löschverhalten, damit ein Assurance-Prozess nicht von einer unzugänglichen persönlichen Konversation abhängt.
Wenn der Workflow eine Freigabe verlangt, verknüpfen Sie diese Entscheidung mit der exakten Änderung. Wenn die Richtlinie eine sofortige Aktion zulässt, bewahren Sie die Grundlage für diesen Weg auf. Der Rekonstruktionsprozess sollte beide Fälle erklären können, ohne den Eindruck zu erzeugen, dass jede Incident-Aktualisierung einen menschlichen Freigabeschritt erfordert.
Den ersten Piloten bewusst gut prüfbar machen
Wählen Sie in einer Testumgebung eine kleine Menge rückgängig zu machender Incident-Aktualisierungen aus. Nehmen Sie eine zulässige Aktualisierung, eine abgelehnte Aktualisierung, eine reine Entwurfsanforderung und eine wiederholte Anforderung auf. Prüfen Sie, ob die Wiederholung zu einer weiteren Änderung führt und ob das Ergebnis für den Operator klar erkennbar ist. Gehen Sie nicht davon aus, dass eine erfolgreiche Schnittstellenmeldung den beabsichtigten Datensatzstatus beweist.
Nutzen Sie die Ergebnisse, um die Einsatzgrenze und offene Fragen für den Anbieter oder den Integrationsverantwortlichen zu definieren. Bewerten Sie künftige Sicherheits- und Entwicklungsfunktionen in einer separaten Roadmap-Prüfung, bis sich ihre Verfügbarkeit und ihr lokales Verhalten verlässlich prüfen lassen.
Maetra Audit bewahrt relevante Nachweise zu Entscheidungen, Freigaben, Laufzeit und Änderungshistorie. Task Guard befasst sich mit Aufgabenabgleich und beabsichtigten Wirkungen. Diese Fähigkeiten bedeuten nicht, dass bereits eine ServiceNow-Plugin-Integration besteht. Nutzen Sie Maetras Leitfaden zu Audit-Nachweisen als Hintergrund und ziehen Sie anschließend Maetras Dokumentation heran, um die für einen einzelnen konversationsbasierten Datensatz-Schreib-Workflow erforderlichen Nachweise festzulegen.
Quellen
- OpenAI: ServiceNow partnership expansion, 28. Oktober 2026. Primäre Partnerankündigung und Termine zur Verfügbarkeit.
- ServiceNow announcement distributed by Business Wire via Yahoo Finance, 28. Oktober 2026. Primäre Mitteilung des Herausgebers, einschließlich der Grenze des Ausführungssystems und zukunftsgerichteter Einschränkungen.