Ein interner Prüfer stellt dem Betriebsteam eine einfache Frage: Warum wurde der nächtliche Zahlungsabwicklungsprozess um 2:47 Uhr neu gestartet? Das Protokoll des Planungssystems zeigt einen Neustart an. Im Ticket steht: „Erneuter Lauf gemäß KI-Empfehlung“. Niemand kann sagen, was der KI-Agent gesehen hat, welche Berechtigungen er hatte oder wer die Aktion genehmigt hat.
Kurz gesagt: Ein KI-System sollte einen Prüfpfad hinterlassen, der es ermöglicht, die gesamte Entscheidung – und nicht nur den Befehl – nachzuvollziehen. Dieser Prüfpfad sollte aufzeigen, welches System und welche Personen beteiligt waren, welcher Kontext und welche Beweise die Empfehlung beeinflusst haben, welche Befugnisse das System besaß, wer die Aktion genehmigt hat, was genau ausgeführt wurde und was anschließend geschah.
Dieser Artikel erläutert das von Rocket Software vorgeschlagene achtteilige Framework für diese Protokollierung. Er enthält außerdem ein Beispiel für ein Prüfprotokoll aus einem realen Mainframe-Batch-Vorfall, das Sie an Ihre eigene Umgebung anpassen können.
Ein Prüfpfad eines KI-Agenten ist der Nachweis, der die Empfehlung eines KI-Agenten mit der zugrunde liegenden Autorität, Genehmigung, Aktion und dem Ergebnis verknüpft. Nutzen Sie diese Definition als Ausgangspunkt:
Ein Prüfprotokoll für KI-Agenten ist ein chronologisch geordnetes, manipulationssicheres Protokoll, das die Identität eines KI-Agenten, den Kontext und die verwendeten Entscheidungsgrundlagen, die ausgesprochene Empfehlung, die ihm zustehende Berechtigung, die eingeholte menschliche Genehmigung, die ausgeführte autorisierte Aktion und das validierte Ergebnis miteinander verknüpft. Es ermöglicht Prüfern, Bedienern oder Risikoteams, nachzuvollziehen, wer was, warum und mit wessen Genehmigung getan hat.
Das Schlüsselwort lautet „Verknüpfungen“. Die meisten dieser Informationen sind bereits in Ihrer Umgebung vorhanden. Der Prüfpfad des KI-Agenten verbindet sie, sodass niemand die Informationen nachträglich aus fünf verschiedenen Tools zusammentragen muss.
Herkömmliche Systemprotokolle erfassen Ereignisse, aber keine Entscheidungen. Ein Protokoll kann zwar zeigen, dass eine Benutzer-ID zu einem bestimmten Zeitpunkt einen Befehl erteilt hat, aber es kann nicht aufzeigen, warum ein KI-Agent diesen Befehl empfohlen hat, welche Beweise ihn stützten oder ob eine Person mit der entsprechenden Rolle ihn genehmigt hat.
Systemprotokolle sind notwendig, aber nicht ausreichend. Sie benötigen weiterhin SMF-Datensätze (System Management Facilities), Jobprotokolle, Konsolenprotokolle und Sicherheitsprotokolle, da diese die Vorgänge auf Systemebene belegen. Ein KI-Agent fügt jedoch eine zusätzliche Entscheidungsebene zwischen Alarm und Befehl ein. Wird diese Ebene in Ihrem Audit-Trail übersprungen, bleibt Ihnen als einzige Erklärung die Aussage „Die KI war’s“.
Hier die Unterschiede zwischen den beiden Datensätzen:
| Frage, die ein Wirtschaftsprüfer stellt | Traditionelles Systemprotokoll | Prüfprotokoll des KI-Agenten |
| Wer hat gehandelt? | Eine Benutzer-ID oder ein Dienstkonto | Die Identität des Agenten, die anfragende Person und der Genehmiger |
| Was haben sie gesehen? | Nicht aufgezeichnet | Vorfallkontext und Systemzustand zum Zeitpunkt der Entscheidung |
| Warum haben sie gehandelt? | Nicht aufgezeichnet | Entscheidungsbeweise und die angegebene Begründung |
| Durften sie das? | Zugriff gewährt oder verweigert | Zulässiger Bereich, Richtliniengrenze und Einstellungen für minimale Berechtigungen |
| Wer hat das genehmigt? | Manchmal auf einem separaten Ticket | Benannter Genehmiger, Zeitstempel und die genaue genehmigte Aktion |
| Hat es funktioniert? | Nur Rückgabecode | Ergebnisvalidierung, Rollback-Status und Restrisiko |
Führungskräfte betrachten diese Lücke bereits als Produktionshemmnis. In einer Studie von Rocket Software und Hanover Research aus dem Juni 2026, an der 250 IT-Führungskräfte im Finanzdienstleistungssektor teilnahmen, gaben 46 % an, dass sie strenge Governance-Kontrollen und Genehmigungsprozesse benötigen, bevor sie KI im Produktivbetrieb für die operative Diagnose einsetzen. Weitere 43 % wünschten sich eine nachgewiesene Genauigkeit, validiert anhand historischer Vorfälle. Die Befragten nannten zudem mangelnde Erklärbarkeit und Nachvollziehbarkeit als ihre größten Bedenken hinsichtlich agentenbasierter KI in regulierten Bereichen.
IDC berichtet von einem ähnlichen Muster. Laut IDC nennen frühe Anwender von agentenbasierter KI immer wieder die mangelnde Transparenz hinsichtlich Compliance- und Audit-Anforderungen als Herausforderung. IDC merkt zudem an, dass Vertrauensbildung von der Nachverfolgung von Erkenntnissen, Aktionen und Ergebnissen durch Protokolle, Audit-Trails und klare Richtlinien für die menschliche Aufsicht abhängt.
Ein Prüfprotokoll eines KI-Agenten sollte acht Elemente für jede wichtige Empfehlung oder Maßnahme erfassen. Zusammen beantworten diese Elemente alle Fragen, die ein Prüfer, Risikomanager oder Vorfallbearbeiter stellen könnte.
Das ist wichtig, weil jedes Element eine spezifische Lücke schließt. Lässt man die Autorität außer Acht, kann man nicht beweisen, dass der Akteur im Rahmen seiner Befugnisse geblieben ist. Lässt man das Ergebnis außer Acht, kann man nicht beweisen, dass die Handlung hilfreich war.
Ein KI-Prüfprotokoll sollte die Entscheidungsnachweise und die Begründung des Agenten erfassen, nicht aber den verborgenen Gedankengang des Modells. Prüfer müssen nachvollziehen können, worauf sich der Agent stützte und zu welchem Schluss er gelangte. Sie benötigen den internen Token-für-Token-Prozess eines großen Sprachmodells nicht und können ihn in der Regel auch nicht zuverlässig ermitteln.
Konzentriere dich auf das Beobachtbare und Überprüfbare:
Ein Prüfer kann diesen Datensatz überprüfen. Er kann dasselbe Jobprotokoll öffnen, denselben Fehlercode bestätigen und beurteilen, ob die Empfehlung auf den vorliegenden Beweisen beruht. Das ist eine solidere Grundlage für die Verantwortlichkeit als eine undurchsichtige Begründung.
Die menschliche Genehmigung sollte als separater, nachvollziehbarer Schritt zwischen der Empfehlung des Agenten und der ausgeführten Maßnahme ersichtlich sein. Die Dokumentation sollte eine eindeutige Abfolge gewährleisten.
Jeder Schritt benötigt eine eigene Kennung und einen Zeitstempel. Wenn Person B „Neustart ab SCHRITT040“ genehmigt hat und der Agent „Neustart ab SCHRITT010“ ausgeführt hat, sollte der Datensatz die Diskrepanz automatisch kennzeichnen.
Diese Sequenz entspricht abgestuften Stufen der KI-Autorität: Beobachten, Empfehlen, Mit Genehmigung handeln und Autonom handeln. Die meisten wichtigen Produktionsaktionen fallen unter die Stufe „Mit Genehmigung handeln“. Der Prüfpfad dokumentiert, welche Stufe für jede Aktion angewendet wurde.
Ein rechtssicherer KI-Prüfpfad ist vollständig, nachvollziehbar und manipulationssicher. Sollte er sechs Monate später in Frage gestellt werden, muss er auch ohne Erinnerungshilfen standhalten.
Prüfen Sie Ihren Prüfpfad anhand dieser Kriterien:
Die Aufbewahrungsfristen variieren je nach Branche, Rechtsordnung und Art der Aufzeichnung. Ihre Compliance-, Rechts- und Risikoteams sollten diese festlegen.
Ein aussagekräftiges KI-Prüfprotokoll liest sich wie ein kurzer, nachvollziehbarer Vorfallsbericht. So sollte beispielsweise der Neustart des Abrechnungsvorgangs um 2:47 Uhr aus dem Eingangsszenario aussehen.
Szenario: Der nächtliche Zahlungsabwicklungsjob PAYSETL01 bricht in Schritt 040 mit dem Db2® SQLCODE -911 ab. Eine Online-Transaktion des Customer Information Control System (CICS) hat ihr normales Zeitfenster überschritten und Sperren auf der Abrechnungstabelle verursacht. Ein KI-Agent untersucht den Fall, identifiziert den Sperrkonflikt und empfiehlt einen Neustart, sobald die Sperre aufgehoben ist. Der diensthabende Operator eskaliert den Fall an den Leiter der Stapelverarbeitung, der die Empfehlung ausspricht.
| Prüfelement | Beispieleintrag |
| Identität | Agent: ops-triage-agent-03 (v2.4). Initiator: J. Rivera, Bereitschaftsdienst. Genehmiger: M. Chen, Leiter der Stapelverarbeitung. |
| Kontext | Vorfall INC-48213. Produktion LPAR PRD1. PAYSETL01 wurde in STEP040 um 2:31 Uhr abgebrochen. Abrechnungsfrist: 6:00 Uhr. |
| Beweis | Das Jobprotokoll zeigt den SQLCODE -911 mit dem Ursachencode 00C9008E (Timeout). Die Db2®-Meldung DSNT376I nennt die CICS-Transaktion als Sperrinhaber. Die CICS-Aufgabendaten zeigen, dass die langlaufende Transaktion um 2:39 Uhr beendet wurde. Vorheriger Vorfall INC-44107 mit übereinstimmendem Muster. |
| Empfehlung | Starten Sie PAYSETL01 ab Schritt 040 gemäß Runbook RB-112 neu. Begründung: Die Sperre ist abgelaufen, und Schritt 040 startet ab dem letzten Commit-Punkt neu. Unsicherheit: Der Agent konnte nicht bestätigen, warum die Online-Transaktion überzogen wurde. |
| Behörde | Richtlinie OPS-BATCH-07. Der Agent hat Lesezugriff auf Jobprotokolle und Db2®-Diagnosedaten. Neustarts von Jobs erfordern eine manuelle Genehmigung. |
| Zustimmung der Menschen | M. Chen genehmigte um 2:46 Uhr den Neustart von PAYSETL01 ab STEP040. |
| Aktion | Der Agent hat den genehmigten Neustart um 2:47 Uhr über den Jobplaner eingereicht. Die ausgeführte Aktion entsprach der genehmigten Aktion. |
| Ergebnis | Auftrag um 3:21 Uhr abgeschlossen. Datensätze abgeglichen, keine doppelten Einträge. Restrisiko: Überschneidungen im Online-Zeitfenster sind erneut möglich. Ticket für das Anwendungsteam erstellt. |
Beachten Sie, was diese Aufzeichnung bewirkt. Ein Prüfer kann jeden Anspruch überprüfen, ohne jemanden anrufen zu müssen. Der Sachbearbeiter kann nachvollziehen, warum der Agent angerufen hat. Das Antragsteam erhält eine klare Nachverfolgung anstelle von Unklarheiten.
Rocket® EVA™ Passt sich an Bereiche an, in denen operative Teams eine KI-gestützte Diagnose benötigen, die Beweise liefert, die ein Mensch überprüfen kann, bevor Änderungen an der Produktion vorgenommen werden.
Laut IDC ermöglicht Rocket EVA IT-Betreibern und Entwicklern, Fragen in natürlicher Sprache zu stellen und Empfehlungen zum Status von Vorfällen, Abhängigkeiten und Ursachenzusammenhängen aus verschiedenen Quellen wie IBM Db2®, SMF, TMON/SDSF und Workload-Manager-Daten zu erhalten. IDC hebt außerdem hervor, dass Rocket EVA in Ticketsysteme wie Jira integriert ist, wodurch Empfehlungen mit dem jeweiligen Vorfalldatensatz und den bisherigen Lösungsansätzen Ihres Unternehmens für ähnliche Probleme verknüpft werden können.
Dies entspricht direkt den Elementen Kontext, Beweise und Empfehlung des Frameworks. Sobald eine Empfehlung mit den entsprechenden Belegen vorliegt, können die Bediener sie überprüfen und die Prüfer sie später nachvollziehen. Zudem unterstützt es weniger erfahrene Mitarbeiter bei der Durchführung von Untersuchungen, während die Mainframe-Experten die Kontrolle über komplexe, fachlich anspruchsvolle Entscheidungen behalten.
Prüfen Sie für die Elemente Identität, Berechtigung, Genehmigung durch den Benutzer und Aktion die aktuellen Funktionen anhand der offiziellen Rocket Software Dokumentation. Das Ziel bleibt in jedem Fall dasselbe: eine bessere Diagnose und gezieltere Maßnahmen auf Basis Ihrer bestehenden Systeme, ohne die bewährten Prozesse Ihrer Teams zu beeinträchtigen.
Wie können Nachwuchskräfte die CICS-Triage der ersten Ebene sicher durchführen?
Junior-Operatoren können Untersuchungen ohne Produktionsberechtigung durchführen. Hier erfahren Sie, was sie überprüfen dürfen, was tabu ist und wann eine Eskalation erforderlich ist.
Mainframe-native AIOps vs. APM + Copilot: Was ist der Unterschied?
Beide Ansätze können Ihrem Betriebsteam helfen, aber sie lösen Probleme unterschiedlicher Tiefe.
Wie modernisiert man eine CICS-Anwendung, ohne den Produktionsbetrieb zu unterbrechen?
Eine sichere Modernisierung beginnt damit, zu verstehen, was man hat, nicht damit, das zu verändern, was man nicht hat.
Wie lässt sich ein Timeout über API, CICS, Db2® und MQ hinweg nachverfolgen?
Ein Timeout ist ein Symptom, keine Diagnose. So verfolgen Sie die Transaktion bis zum eigentlichen Engpass.
