Vollständige KI-Agenten-Nachweise: Fehlende Ereignisse
Prüfen Sie die Vollständigkeit von KI-Agenten-Nachweisen mit Ereignisbeziehungen, Empfängerabgleich, gezielten Lückentests und klaren Abdeckungsgrenzen.
Die Vollständigkeit von KI-Agenten-Nachweisen betrifft die Frage, ob alle zur Erklärung einer begrenzten Operation benötigten Datensätze vorhanden, verknüpft und verständlich sind. Auch eine Sammlung gültiger Signaturen kann einen abgelehnten Versuch, eine unklare Übermittlung oder eine spätere Rücknahme auslassen. Definieren Sie erwartete Ereignisbeziehungen, vergleichen sie mit maßgeblichen Operationsaufzeichnungen und melden Lücken, ohne fehlende Nachweise als angenommenen Erfolg zu behandeln.
Diese Methode richtet sich an Prüfungs- und Plattformteams, die agentengestützte Abläufe untersuchen. Sie ergänzt die Integritätsprüfung, ersetzt sie aber nicht. Das Beispiel verfolgt ein vorbereitetes Dokument durch Freigabe, Übermittlung und Bestätigung. Die Ereignisnamen bilden ein vorgeschlagenes lokales Modell. Sie sind weder ein OATI-Übertragungsformat noch ein allgemeiner Standard für sämtliche Unternehmensprozesse oder eine Aussage über deren rechtliche Nachweispflichten.
Vor dem Zählen die Grundgesamtheit festlegen
Wählen Sie Fälle, Zeitintervall, Mandanten und Operationstypen für die Prüfung aus. Beschreiben Sie, ob das Intervall nach Anfragezeit, Übermittlungszeit oder Ergebniszeit abgegrenzt wird. Eine Operation am Ende des Zeitfensters kann später abgeschlossen werden. Wird ihr Ergebnis ohne Erklärung ausgeschlossen, erscheint eine ansonsten gültige Folge unvollständig. Diese Grenzfälle gehören deshalb ausdrücklich in die Definition des Prüfungsumfangs.
Verwenden Sie möglichst eine unabhängige Operationsquelle, etwa das Transaktionsregister des empfangenden Systems. Der Vergleich eines Nachweisspeichers nur mit sich selbst kann interne Konsistenz bestätigen und gleichzeitig Aktionen übersehen, die an der Erfassung vorbeigelaufen sind. Fehlt eine unabhängige Grundgesamtheit, beschreiben Sie das Ergebnis als Vollständigkeit innerhalb des beobachteten Datensatzes. Es ist dann kein Beleg dafür, dass jede tatsächliche Aktion erfasst wurde.
Das OpenTelemetry-Protokolldatenmodell unterscheidet Ereignis- und Beobachtungszeit und unterstützt die Zuordnung zu Traces. Diese Felder helfen bei Untersuchungen. Sie bestimmen weder die erforderlichen fachlichen Nachweise noch beweisen sie, dass ein Collector jede Aktion gesehen hat. Die folgenden erwarteten Beziehungen sind anwendungsspezifische Prüfregeln, die für das jeweilige Verfahren festgelegt werden müssen.
Gültige Beziehungen zwischen Ereignissen beschreiben
Nicht jede Anfrage muss mit einem Erfolgsbeleg enden. Eine abgelehnte Anfrage braucht eine dokumentierte Ablehnung und darf im geschützten Pfad keine spätere Ausführung auslösen. Genehmigte Anfragen können offen oder ungewiss bleiben. Ein Abbruch vor der Übermittlung und eine Rücknahme nach dem Abschluss sind unterschiedliche Ereignisse. Sie haben unterschiedliche Folgen und dürfen in der Auswertung nicht gleichgesetzt werden.
| Beobachteter Zustand | Benötigte zugehörige Nachweise | Frage bei einer Lücke |
|---|---|---|
| Anfrage abgelehnt | Entscheidungsgrund und Anfragereferenz | Ist die Ablehnung dokumentiert, ohne spätere verbotene Ausführung? |
| Freigabe erfasst | Exakte Objektversion und berechtigte prüfende Person | Bezieht sich die Zustimmung auf das tatsächlich Übermittelte? |
| Übermittlung versucht | Operationsreferenz und Zuordnung zum Zielsystem | Lässt sich eine Wiederholung von einer neuen Aktion unterscheiden? |
| Ergebnis unbekannt | Zeitüberschreitung oder Unterbrechung mit Abgleichstatus | Wird Ungewissheit fälschlich als Erfolg oder Fehlschlag berichtet? |
| Abschluss beobachtet | Maßgebliche Ergebnisreferenz und Beobachtungszeit | Ist der Abschluss außerhalb des Modelltranskripts belegt? |
| Spätere Korrektur | Verweis auf das frühere Ergebnis mit Begründung | Kann die ursprüngliche Schlussfolgerung noch als aktuell erscheinen? |
Legen Sie ausdrücklich fest, wie viele Datensätze zulässig sind. Eine Operation kann mehrere Versuche, mehrere Beobachtungen und schließlich ein abgeglichenes Ergebnis haben. Wer jede wiederholte Kennung als Duplikatfehler behandelt, kann nützliche Wiederholungsverläufe verlieren. Wer alle Wiederholungen ohne Bedeutungsvergleich akzeptiert, kann dagegen widersprüchliche Ergebnisse übersehen. Beide Fehler verhindern eine verlässliche Rekonstruktion des tatsächlichen Ablaufs.
Mengen statt bloßer Summen abgleichen
Gleiche Datensatzanzahlen beweisen keine Vollständigkeit. Zehn Übermittlungen und zehn Belege können unterschiedliche Operationen betreffen. Verknüpfen Sie über stabile mandantengebundene Operationskennungen und prüfen die erwarteten Beziehungen je Vorgang. Erfassen Sie nicht zugeordnete Einträge in beide Richtungen. Eine Übermittlung ohne Nachweis verlangt eine andere Untersuchung als ein Nachweis, zu dem überhaupt keine bekannte Übermittlung existiert.
Verwenden Sie eine definierte Wartefrist für verzögerte Datensätze. Offene Einträge müssen währenddessen sichtbar bleiben. Ein später Datensatz kann eine Lücke schließen, darf aber den ursprünglichen Bericht nicht so verändern, als hätte die Lücke nie bestanden. Bewahren Sie Berichtszeit und späteres Abgleichereignis auf. So bleibt unterscheidbar, ob Nachweise rechtzeitig vorlagen oder erst nach einem Fehler wiederhergestellt wurden.
Reihenfolge und unsichere Zeitangaben berücksichtigen
Ereignisse können in anderer Reihenfolge eintreffen, obwohl der zugrunde liegende Ablauf gültig war. Vergleichen Sie kausale Referenzen und Quellenstände, bevor Sie folgern, eine Freigabe habe erst nach der Ausführung stattgefunden. Systemzeiten verschiedener Dienste können voneinander abweichen. Dokumentieren Sie Zeitannahmen und Unsicherheiten, die das Ergebnis beeinflussen. Eine genaue Zahl im Zeitstempel beseitigt solche Unsicherheit nicht automatisch.
Eine Sequenznummer oder Hash-Kette kann innerhalb ihres definierten Umfangs fehlende Einträge erkennen lassen. Sie beweist nicht, dass sämtliche externen Aktionen in diese Folge aufgenommen wurden. Prüfen Sie, wie die Folge entsteht, wo die Durchsetzungsgrenze liegt und ob alternative Zugänge oder Wege sie umgehen können. Die zugesicherte Aussage muss zum tatsächlichen Erfassungsmechanismus passen und dessen Grenzen offenlegen.
Eine kleine Übung mit fehlenden Ereignissen aufbauen
Erstellen Sie drei synthetische Operationen: eine abgelehnte, eine abgeschlossene und eine mit unbekanntem Ergebnis. Schreiben Sie zuerst die erwarteten Beziehungen auf. Entfernen Sie die Freigabereferenz der abgeschlossenen Operation und die Ungewissheitsmarkierung der unterbrochenen Operation. Ergänzen Sie einen Beleg für eine unbekannte Operation. Die Prüfung soll drei unterschiedliche Feststellungen liefern, nicht lediglich eine allgemeine Abweichung der Anzahl.
Fügen Sie die fehlenden Datensätze anschließend mit späteren Beobachtungszeiten wieder hinzu. Die Feststellungen müssen als geklärt markiert werden, während der ursprüngliche Bericht erhalten bleibt. Ergänzen Sie ein widersprüchliches Ergebnis zur abgeschlossenen Operation. Das System muss einen Abgleich verlangen, statt das zuletzt eingetroffene Ereignis automatisch als Wahrheit zu übernehmen. Die Ankunftsreihenfolge ist keine fachliche Entscheidungsregel.
Legen Sie schließlich eine zusätzliche synthetische Operation nur im Empfängerregister an. Damit prüfen Sie, ob der unabhängige Mengenvergleich eine im Nachweisspeicher fehlende Aktion erkennt. Ein bestandener Versuch zeigt ein nützliches Abgleichverhalten. Er beweist jedoch nicht, dass das reale Empfängerregister vollständig oder vertrauenswürdig ist. Auch diese Quelle benötigt eine eigene Bewertung ihrer Erfassung und möglichen Auslassungen.
Nachweise wiederherstellen, ohne Geschichte zu erfinden
Kann eine Quelle einen fehlenden Datensatz erneut exportieren, bewahren Sie Herkunft und Wiederherstellungszeit auf. Rekonstruiert eine Person eine Tatsache aus anderen Unterlagen, kennzeichnen Sie das als Rekonstruktion und nennen ihre Grundlage. Erzeugen Sie keinen neuen signierten Datensatz, der fälschlich behauptet, schon gleichzeitig mit der ursprünglichen Aktion entstanden zu sein. Eine spätere Bestätigung und ein damaliger Nachweis sind verschiedene Aussagen.
Lässt sich ein Datensatz nicht wiederherstellen, benennen Sie die Lücke und ihre Folgen für die Schlussfolgerung. Das Ergebnis kann aus einer anderen maßgeblichen Quelle bekannt sein, während die ursprüngliche Freigabegrundlage ungeprüft bleibt. Unterschiedliche Aussagen können deshalb unterschiedlich gut belegt sein. Fassen Sie diese Unterschiede nicht zu einem einzigen grünen Status zusammen, der die verbleibende Unsicherheit verdeckt.
Abdeckung mit aussagekräftigen Bezugsgrößen berichten
Berichten Sie abgegrenzte Grundgesamtheit, erwartete Datensatzarten, offene Lücken, wiederhergestellte Nachweise und Widersprüche. Trennen Sie gewöhnliche Verarbeitungsverzögerung von überschrittenen Nachweisfristen. Erläutern Sie verglichene Quellen und ausgeschlossene Umgehungspfade. Eine Prozentzahl ohne diese Definitionen ist für eine unabhängige prüfende Person schwer interpretierbar und kann eine höhere Abdeckung vortäuschen, als tatsächlich untersucht wurde.
Verwenden Sie die Vorlage bei Freigabetests und nach Änderungen an Collectoren, Warteschlangen, Aufbewahrung oder Exportwegen. Jede offene Feststellung braucht eine Verantwortung und einen nächsten Untersuchungsschritt. Vollständigkeit wird zur betrieblichen Kontrolle, wenn ein fehlendes Ereignis eine konkrete Entscheidung auslöst. Eine Warnung, die beim nächsten Aktualisieren des Dashboards verschwindet, erfüllt diese Aufgabe nicht.
Vorlage und ergänzende Umsetzungsleitfäden nutzen
Nutzen Sie den übergeordneten Leitfaden für die umfassendere Architektur und wenden Sie diesen Artikel auf eine klar begrenzte Umsetzung an. Die ergänzenden Artikel behandeln verwandte Entscheidungen, ohne diese Vorlage zu ersetzen.
Bearbeitbare Vorlage herunterladen. Nächster Schritt.
Technischer Entwurf vom 18. Oktober 2026. Primärquellen wurden an diesem Datum geprüft; die fachliche Prüfung steht noch aus. Die Vorlagen beschreiben vorgeschlagene Tests, keine gemessenen Kundenergebnisse. OATI bleibt eine Entwicklervorschau. Lokale Implementierungsnachweise belegen keine unabhängige Prüfung, Kundenabnahme oder Produktionsreife einer konkreten Bereitstellung.