Kanonische Fakten und Nachweiskette

Der Vertriebsagent eines Unternehmens schickt einem Interessenten folgendes Angebot: »Unser Service für den betreuten Websitebetrieb kostet ab 350 Dollar im Monat.« Der Kunde teilt mit, dass er das Angebot annehmen möchte. Als der kaufmännische Leiter die Nachricht sieht, ist er überrascht. Der gültige Einstiegspreis beträgt 500 Dollar im Monat. Er fragt den Vertriebsagenten: »Woher hast du die Angabe von 350 Dollar?« Der Agent antwortet: »Diesen Preis habe ich in den freigegebenen Vertriebsquellen des Unternehmens gefunden.« Man prüft die Website. Auf der Leistungsseite steht eindeutig: »Managed Site Operations — Starting at 500 USD/month.« Der Leiter macht einen Screenshot und sagt: »Der Agent hat falsche Informationen erzeugt. Der kanonische Preis steht doch bereits richtig auf der Website.«

Der Vorfall scheint ein einfacher Modellfehler zu sein. Doch der Prüfer sieht sich nicht nur die aktuelle Webseite an. Er fragt: Auf welche Informationen konnte der Agent zugreifen, als er die Nachricht versandte? Die Aufzeichnungen werden Schritt für Schritt geprüft. Um 08:42 Uhr enthält das freigegebene Preisregister den Monatspreis von 500 Dollar. Um 08:51 Uhr zeigt eine alte Angebotsvorlage im Vertriebs-CRM noch immer 350 Dollar. Um 08:56 Uhr wurde der Wissensindex des Vertriebsagenten aus dieser CRM-Vorlage neu aufgebaut. Um 09:14 Uhr schickte der Agent dem Kunden den Preis von 350 Dollar. Um 09:22 Uhr bemerkte ein menschlicher Verantwortlicher den Fehler und korrigierte die CRM-Vorlage. Um 09:31 Uhr wurde der Screenshot der Website aufgenommen. Um 09:45 Uhr wurde der Wissensindex des Agenten erneut aktualisiert.

Der vom Unternehmen vorgelegte Screenshot stützt die Aussage, dass die Seite um 09:31 Uhr einen Preis von 500 Dollar zeigte. Er belegt aber nicht, welchen Datensatz der Agent um 09:14 Uhr verwendete. Der Prüfer findet weitere Nachweise:

Der Aktionsbeleg für die E-Mail nennt die alte CRM-Vorlage als Quelle.

Die Version des Wissensindex des Agenten enthält nicht die aktuelle Fassung des Preisregisters.

Die alte Vorlage geht auf einen vorübergehenden Rabatt für einen bestimmten Kunden zurück.

Der Rabatteintrag enthält kein Enddatum.

Die für die CRM-Vorlage zuständige Person arbeitet nicht mehr im Unternehmen.

Keine maschinelle Regel legt fest, dass die Vorlage keine kanonische Preisquelle ist.

Die Website zeigte Menschen den richtigen Preis.

Der Vertriebsagent verwendete die alte interne Vorlage, nicht die für Menschen bestimmte Seite.

Mit »Der Agent hat den falschen Preis genannt« lässt sich der Vorfall nun nicht mehr ausreichend erklären. Genauer wäre:

Der gültige, autorisierte Preis des Unternehmens betrug 500 Dollar. Im operativen Informationsbestand des Agenten blieb jedoch der alte Eintrag über 350 Dollar aktiv. Menschen und Maschine arbeiteten mit unterschiedlichen Fakten. Der Agent konnte nicht bestimmen, welche Quelle kanonisch war. Der aktuelle Screenshot belegte nicht die Situation zum Zeitpunkt des früheren Handelns. Das Unternehmen hatte die falsche Information korrigiert, dabei aber beinahe die Nachweiskette aus der Zeit vor dem Vorfall verloren.

Nun sind drei verschiedene Wirklichkeiten zu unterscheiden:

Maßgebliche Fakten

Der gültige Preis beträgt 500 Dollar im Monat.

Die operative Informationslage, auf die der Agent zugreifen konnte

Im Vertriebsindex steht ein Preis von 350 Dollar im Monat.

Das Ergebnis in der Außenwelt

Dem Kunden wurden 350 Dollar im Monat angeboten. Vermischt eine Prüfung diese drei Wirklichkeiten, kann sie die Grundursache nicht finden. Betrachtet sie nur die Website, lautet ihr Urteil: »Der Agent hat die Fakten erfunden.« Betrachtet sie nur die Aufzeichnungen des Agenten, kann sie sagen: »Der Agent hat entsprechend der verfügbaren Quelle gehandelt.« Untersucht sie nur die Nachricht an den Kunden, kann sie zu dem Schluss kommen: »Das Unternehmen hat einen Preis von 350 Dollar bekannt gegeben.« Jede Sicht erfasst einen Teil des Vorfalls. Keine zeigt für sich allein die ganze Wahrheit. Deshalb braucht die GBO-Prüfung zwei getrennte Strukturen:

Register kanonischer Fakten

und

Nachweiskette

Das Register beantwortet die Frage: Welcher Fakt war zu einem bestimmten Zeitpunkt und innerhalb eines bestimmten Geltungsbereichs maßgeblich und gültig? Die Nachweiskette beantwortet: Über welche Quellen, Umwandlungen und Verifizierungsschritte sind wir zu diesem Urteil gelangt?

Informationen zu finden heißt nicht, die Fakten festzustellen

Eine Information kann im Internet oder in einem Unternehmenssystem vorhanden sein. Das heißt noch nicht, dass sie:

richtig ist,

aktuell ist,

maßgeblich ist,

zum betrachteten Geltungsbereich passt,

als Handlungsgrundlage ausreicht.

Ein Preis kann auffindbar, aber veraltet sein. Eine Leistungsbeschreibung kann nur für einen bestimmten Kunden gelten. Eine menschliche Rolle kann noch verzeichnet sein, obwohl sie abgelaufen ist. Ein Einwilligungsnachweis kann sich auf einen anderen Zweck beziehen. Ein Kommentar kann auf vielen Seiten wiederholt werden und dennoch auf einer einzigen Selbstauskunft beruhen. Ein Screenshot kann den richtigen Inhalt zeigen, aber erst nach dem Vorfall aufgenommen worden sein. Der Vergleich mit einem früheren, verlässlich gespeicherten Hashwert hilft zu prüfen, ob eine Datei verändert wurde. Er zeigt aber nicht, ob ihr Inhalt wahr ist. Eine digitale Signatur kann zeigen, dass ein Dokument von einer bestimmten Person oder einem bestimmten System signiert wurde.

Sie belegt jedoch nicht automatisch, dass die darin enthaltene Behauptung wahr ist. Ein Quellenverweis kann auf die richtige Seite führen, ohne dass diese den vom Modell formulierten Satz stützt. Die GBO-Prüfung akzeptiert deshalb diese Abkürzung nicht:

INFORMATION GEFUNDEN = FAKT VERIFIZIERT

Die richtige Kette ist länger:

INFORMATION GEFUNDEN ↓ ENTITÄT VERIFIZIERT ↓ QUELLENROLLE BESTIMMT ↓ BEFUGTER VERANTWORTLICHER ERMITTELT ↓ ZEIT UND GELTUNGSBEREICH ABGEGLICHEN ↓ WIDERSPRÜCHE UNTERSCHIEDEN ↓ HERKUNFT DER NACHWEISE GESICHERT ↓ URTEIL ÜBER DIE FAKTEN GEFÄLLT

Was sind kanonische Fakten?

Kanonische Fakten sind nicht die Geschichte, die ein Unternehmen mag oder wiederholen möchte. Auch nicht der Satz in der größten Überschrift einer Webseite. Der Begriff bedeutet nicht, dass ein Unternehmen sich nach Belieben selbst definieren darf. In diesem Protokoll sind kanonische Fakten als prüfbare Aufzeichnung zu einer bestimmten Entität und einem bestimmten Faktentyp definiert. Festgelegt sind der befugte Verantwortliche, die Quellenrolle, der Geltungsbereich, der Gültigkeitszeitraum, die Ausnahmen und die Versionsgeschichte. Die Aufzeichnung legt fest, welcher Wert für menschliches und maschinelles Verhalten maßgeblich sein soll. Einfacher gesagt: Kanonische Fakten klären, welcher Eintrag bei einer bestimmten Frage innerhalb welcher Zeit- und Geltungsgrenzen das letzte Wort haben darf.

»Das letzte Wort« meint hier keine unbegrenzte, unveränderliche Wahrheit. Der Preis eines Unternehmens kann sich ändern. Eine menschliche Rolle kann enden. Der Leistungsumfang kann wachsen. Eine Einwilligung kann widerrufen werden. Kapazitäten können ausgeschöpft sein. Ein Eintrag kann heute gültig und morgen ungültig sein. Kanonische Fakten bestehen deshalb nicht nur aus einem Wert, sondern aus einer:

Beziehung zwischen Wert, Verantwortlichem, Geltungsbereich und Zeit.

Die acht Grundfelder kanonischer Fakten

Ein Fakteneintrag muss mindestens acht Fragen beantworten.

1. Welche Entität?

Welches Unternehmen?

Welche Person?

Welche Marke?

Welches Produkt?

Welcher Agent?

Welches Konto?

Entitäten mit demselben Namen dürfen nicht verwechselt werden.

2. Welcher Faktentyp?

Preis

Leistungsumfang

Kapazität

Menschliche Rolle

Befugnis

Einwilligung

Datenaufbewahrungsfrist

Eignung

Tatsächlich erfolgter Vorgang

Veröffentlichungsstatus

Für jeden Faktentyp kann eine andere Quelle maßgeblich sein.

3. Wie lautet der Wert?

Zum Beispiel: Der Einstiegspreis für Managed Site Operations beträgt 500 USD/Monat. Der Wert allein reicht jedoch nicht aus.

4. Für welchen Geltungsbereich?

Gilt dieser Preis:

für Neukunden,

für Bestandskunden,

für ein bestimmtes Land,

für ein bestimmtes Paket,

einschließlich Steuern,

nur für die Einstiegsleistung?

5. Wer ist verantwortlich?

Welche befugte Person oder welches Gremium stellt fest, ob dieser Fakt richtig und aktuell ist?

6. Welche Quelle ist maßgeblich?

Die Webseite? Das freigegebene Preisregister? Ein unterzeichneter Vertrag? Das CRM? Das Befugnisregister der Personalabteilung? Der Betriebskalender?

7. Wann gilt der Eintrag?

Beginn

Ende

Letzte Verifizierung

Erneute Prüfung

Ereignis, das die Gültigkeit aufhebt

8. Welche Ausnahmen gelten?

Ein Rabatt für einen bestimmten Kunden

Eine befristete Aktion

Ein aus einem älteren Vertrag fortgeltender Preis

Ein bestimmtes Land oder eine bestimmte Sprache

Eine besondere Kapazitätszusage

Ohne diese Felder bleibt die bloße Angabe »Der Preis beträgt 500 Dollar« unvollständig.

Eine kanonische Quelle ist nicht eine einzige große Datenbank

Unternehmen sagen häufig: »Wir brauchen eine einzige maßgebliche Datenquelle.« Dieser Gedanke ist nützlich. Wird er jedoch missverstanden, kann daraus der Versuch werden, das gesamte Unternehmen in eine Datei oder Datenbank zu pressen. Tatsächlich können für unterschiedliche Faktentypen unterschiedliche Quellen maßgeblich sein.

Ein kanonisches System verlangt nicht zwingend, alles an einem Ort zu speichern. Es verlangt Klarheit darüber, welche Quelle für jeden wichtigen Faktentyp maßgeblich ist. Der Preis einer Leistung kann aus dem Preisregister stammen. Die sichtbare Webseite kann diesen Preis für Menschen darstellen. Der Agentenkatalog kann die maschinelle Darstellung enthalten. Die Angebotsvorlage im CRM kann eine abgeleitete Kopie sein. Diese vier Einträge erfüllen nicht dieselbe Funktion.

Quellenrollen

In einer Prüfung muss die Rolle jeder Quelle eindeutig eingeordnet werden.

1. Maßgebliche Quelle

Eine Quelle, die organisatorisch oder rechtlich befugt ist, den Fakt festzulegen. Zum Beispiel ein freigegebenes Preisregister.

2. Operative Quelle

Die Quelle, die der Agent bei seinem tatsächlichen Handeln verwendet. Zum Beispiel der Wissensindex des Vertriebs.

3. Darstellungsquelle

Die Oberfläche, auf der der Fakt Menschen oder Maschinen präsentiert wird. Zum Beispiel eine Webseite oder strukturierte Daten.

4. Ausführungsquelle

Das System, das die tatsächliche Handlung steuert. Zum Beispiel die Lieferadresse im Bestellsystem.

5. Archivquelle

Eine Quelle, mit der sich ein früherer Zustand rekonstruieren lässt. Zum Beispiel ein versioniertes Dokumentenarchiv.

6. Unabhängige Verifizierungsquelle

Sie überprüft das Ergebnis getrennt vom ausführenden System. Zum Beispiel durch einen erneuten Live-Abruf über HTTPS oder ein Prüfpostfach.

7. Kommentierende Sekundärquelle

Eine Quelle eines Dritten, die Primärdaten zusammenfasst oder bewertet.

8. Schlussfolgerung des Agenten

Ein aus Quellen abgeleitetes, aber nicht unmittelbar verifiziertes Ergebnis. Diese Rollen dürfen nicht gleichgesetzt werden. Eine Webseite kann eine starke Darstellungsquelle sein, ohne für den vertraglichen Preis eines bestimmten Kunden maßgeblich zu sein. Ein Agentenbericht kann einen nützlichen operativen Überblick bieten, ist aber keine unabhängige Verifizierung. Ein Screenshot kann eine frühere Darstellung belegen, ist jedoch nicht die Quelle, die den Preis festlegt.

Kanonisch und richtig sind nicht genau dasselbe

Ein Unternehmen kann einen falschen Preis in sein maßgebliches Register eingetragen haben. Dieser Eintrag kann organisatorisch kanonisch sein und dennoch der tatsächlichen Geschäftslage oder einem unterzeichneten Vertrag widersprechen. Deshalb muss die Prüfung zwei Fragen auseinanderhalten: Welcher Eintrag war für das Unternehmen maßgeblich? Und stimmte dieser Eintrag mit dem verbindlichen Geschäftsvorgang und dem tatsächlichen Ergebnis überein? Zum Beispiel:

Das Preisregister zeigt 500 Dollar.

Der mit dem Kunden unterzeichnete Vertrag nennt 450 Dollar.

Für den allgemeinen Preis sind 500 Dollar kanonisch. Für das konkrete Geschäft mit diesem Kunden gelten die vertraglichen 450 Dollar. Das ist kein Widerspruch, sondern es sind zwei gültige Fakten mit unterschiedlichen Geltungsbereichen. Diesen Unterschied zu bewahren ist eine wichtige Aufgabe kanonischer Fakten.

Allgemeine Regel, Ausnahme und konkreter Vorgang

Viele Unternehmensfakten bestehen auf drei Ebenen.

Allgemeine Regel

Die Leistung beginnt bei 500 Dollar im Monat.

Befristete oder begrenzte Ausnahme

Vom 1. bis zum 15. September erhalten Bestandskunden 10 Prozent Rabatt.

Konkreter Vorgang

Im mit Kunden A unterzeichneten Vertrag beträgt der Preis 430 Dollar. Reduziert der Agent all diese Einträge auf ein einziges Preisfeld, entstehen Fehler. Die 430 Dollar für einen bestimmten Kunden können als allgemeiner Preis missverstanden werden. Eine befristete Aktion kann unbegrenzt weitergelten. Der allgemeine Preis kann die besondere Bedingung eines unterzeichneten Vertrags verdrängen. Das kanonische Register muss daher Vorrang- und Geltungsbeziehungen abbilden, nicht nur einen einzelnen Wert. Die richtige Auslegung kann dieser Logik folgen:

EIN GÜLTIGER EINTRAG ZU EINEM KONKRETEN VORGANG SETZT DIE ALLGEMEINE REGEL NUR IM EIGENEN GELTUNGSBEREICH AUSSER KRAFT

Nicht dieser:

DER NEUESTE ODER NIEDRIGSTE WERT IST DER NEUE FAKT FÜR ALLE

Der neueste Eintrag ist nicht immer kanonisch

Ein Mitarbeiter kann um 10:00 Uhr einen neuen Preis ins CRM schreiben. Das freigegebene Preisregister kann um 09:00 Uhr erstellt worden sein. Der CRM-Eintrag ist neuer. Ist der Mitarbeiter aber nicht befugt, Preise zu ändern, wird der neuere Eintrag dadurch nicht kanonisch. Ein Beitrag in sozialen Medien kann neuer sein als ein alter Vertrag, den unterzeichneten Vertrag aber nicht ändern. Eine Zusammenfassung des Agenten kann heute entstanden sein und trotzdem eine drei Jahre alte Quelle zusammenfassen. Der Vorrang einer Quelle darf deshalb nicht allein nach dem Datum bestimmt werden. Eine sachgerechte Bewertung berücksichtigt mindestens diese vier Dimensionen gemeinsam:

BEFUGNIS + GELTUNGSBEREICH + ZEIT + QUELLENROLLE

Zeit gehört zu kanonischen Fakten

Die Prüfung fragt nicht nur: »Was ist heute richtig?« Bei der Untersuchung eines Vorfalls ist eine andere Frage wichtiger: Welcher Fakt war gültig und zugänglich, als die Handlung stattfand? Ein Agent kann am Montag einen alten Preis verwendet haben. Am Dienstag wurde er korrigiert. Die Seite vom Dienstag erklärt den Vorfall vom Montag nicht. Jeder wesentliche Eintrag muss deshalb diese Zeitfelder enthalten:

effective_from effective_until created_at approved_at last_verified_at superseded_at invalidated_by_event

Diese Felder bedeuten nicht dasselbe. Ein Dokument kann am 1. September erstellt, am 5. September freigegeben und ab dem 10. September gültig sein. Am 20. September kann es durch einen anderen Eintrag ersetzt worden sein. Nur das Erstellungsdatum der Datei zu betrachten reicht nicht aus.

Ereignisse, die einen Eintrag ungültig machen

Manche Fakten können ihre Gültigkeit verlieren, bevor ein festgelegtes Datum erreicht ist. Zum Beispiel durch:

das Ausscheiden eines Mitarbeiters,

den Widerruf einer Einwilligung,

die Ausschöpfung der Kapazität,

einen ausverkauften Artikel,

die Beendigung eines Vertrags,

den Widerruf eines Agenten-Tokens,

eine rechtliche Änderung des Unternehmens,

die Feststellung eines Sicherheitsvorfalls.

Ein Eintrag darf deshalb nicht lediglich sagen: »Gültig bis 31. Dezember.« Er muss auch Folgendes enthalten:

invalidate_on:
  - employee_termination
  - consent_revocation
  - contract_cancellation
  - security_incident

Ein Agent darf nicht schon deshalb handeln, weil das aktuelle Datum noch innerhalb der Gültigkeitsfrist des Eintrags liegt. Er muss auch prüfen, ob Ereignisse eingetreten sind, die den Eintrag ungültig machen.

Aktualitätsklassen von Fakten

Nicht jede Information veraltet gleich schnell.

Langsam veränderliche Fakten

Gründungsdatum

Frühere Veröffentlichung

Grundbezeichnung der Produktarchitektur

Fakten mit mittlerer Änderungsgeschwindigkeit

Menschliche Rollen

Leistungsumfang

Supportzeiten

Befugnisrichtlinien

Schnell veränderliche Fakten

Preis

Lagerbestand

Kapazität

Flugverfügbarkeit

Aktionen

Aktive Tokens

Warteschlangenstatus

Die Prüfung muss für jeden Faktentyp eine Aktualitätsgrenze festlegen. Zum Beispiel:

price:
  refresh_required_before_action: true

capacity:
  maximum_age: 24_hours

legal_entity:
  verify_on_material_change

authorization:
  verify_at_execution

Ein Kapazitätseintrag kann vor drei Monaten richtig gewesen sein. Für eine heutige Lieferzusage lässt er sich nicht verwenden.

Drei Ansichten kanonischer Fakten

Derselbe wesentliche Fakt kann in einem Unternehmen in drei Ansichten vorliegen.

1. Maßgebliche interne Fakten

Der Wert, den der zuständige Entscheidungsträger im Unternehmen festgelegt hat.

2. Menschen präsentierte Fakten

Der Wert, der auf der Website, in einem Angebot, einem Vertrag oder in der Kundenkommunikation erscheint.

3. Maschinen präsentierte Fakten

Der Wert, der in einer API, einem Schema, einem Agentenkatalog, einem Wissensindex oder einer Werkzeugbeschreibung erscheint. Diese drei Ansichten müssen nicht Wort für Wort übereinstimmen. Inhaltlich müssen sie aber gleichwertig sein. Zum Beispiel kann der Text für Menschen lauten: Der betreute Betrieb beginnt bei 500 Dollar im Monat. Hostingkosten und Lizenzen Dritter werden gesondert betrachtet. Der maschinenlesbare Eintrag:

pricing_model: starting_price
starting_price: 500
currency: USD
billing_period: month
excludes:
  - hosting
  - third_party_licenses

Die Sätze unterscheiden sich. Der geschäftliche Sachverhalt ist derselbe.

Äquivalenz der Darstellungen

Die inhaltliche Übereinstimmung zwischen der Ansicht für Menschen und der für Maschinen lässt sich so bezeichnen:

Äquivalenz der Darstellungen

Sie muss mindestens in diesen Bereichen geprüft werden:

Identität der Entität

Rechtlicher Betreiber

Leistungsergebnis

Eingeschlossener Leistungsumfang

Ausgeschlossener Leistungsumfang

Unterscheidung zwischen Einstiegs- und Gesamtpreis

Erfordernis einer Einwilligung

Menschliche Freigabe

Kapazität

Nicht garantierte Ergebnisse

Ablauf für Stornierung und Rücknahme

Sponsoring oder geschäftliche Beziehung

Geht eine wichtige Grenze aus der einen Ansicht in der anderen verloren, veröffentlicht das System unterschiedliche Verhaltenswirklichkeiten.

Mehrsprachige kanonische Fakten

Ein in sechs Sprachen veröffentlichtes Dienstleistungsangebot kann sechs unterschiedliche Beschreibungen haben. Sprachen sind unterschiedlich aufgebaut. Wie viele technische Einzelheiten ein Text enthält, kann von der Leserschaft und seiner Aufgabe abhängen, nicht von der Sprache an sich. Arabische Texte werden von rechts nach links gesetzt; Reihenfolge der Erläuterungen und Satzbau können dem natürlichen arabischen Sprachfluss folgen. Ein spanischer Text kann dieselbe Bedeutung mit Anredeformen und Formulierungen vermitteln, die seiner Leserschaft vertraut sind. Diese Vielfalt ist kein Problem. Ein Problem entsteht, wenn sich wesentliche Fakten ändern. Steht im englischen Text etwa »Every public avatar publication requires human approval.«, während eine andere Sprachfassung nur besagt: »Inhalte werden nach dem vorgesehenen Freigabeverfahren vorbereitet«, kann die Pflicht zur menschlichen Freigabe jeder einzelnen Veröffentlichung verloren gegangen sein.

Mehrsprachige kanonische Fakten müssen deshalb auf zwei Ebenen geführt werden:

Sprachunabhängige Faktenvereinbarung

Preis

Geltungsbereich

Einwilligung

Befugnis

Verbote

Stornierung

Nicht garantierte Ergebnisse

Natürliche Formulierung in der jeweiligen Sprache

Dieselbe Faktenvereinbarung wird in natürlicher, örtlich passender Sprache ausgedrückt. Übersetzte Quellen zählen nicht als unabhängige Nachweise. Dieselbe Information in sechs Sprachen ergibt nicht sechs Nachweise, sondern sechs Darstellungen eines einzigen kanonischen Fakts.

Die maßgebliche Sprachfassung

Bei manchen Verträgen oder rechtlichen Aufzeichnungen kann ausdrücklich festgelegt werden, welche Sprachfassung bei Abweichungen maßgeblich ist. Die rechtliche Wirkung dieser Wahl wird gesondert beurteilt. Die übrigen Sprachfassungen können dann diesen Zwecken dienen:

Information,

Lokalisierung,

Barrierefreiheit.

Der Vorrang einer Sprachfassung rechtfertigt keine wesentlichen Fehler in den anderen Sprachen. Trifft ein Nutzer eine wichtige Entscheidung in einer anderen Sprache, muss Folgendes klar sein:

die Grenzen der Übersetzung,

der maßgebliche Text,

wesentliche Unterschiede.

Auch ein Agent, der die Übersetzung verwendet, muss wissen, welche Fassung verbindlich ist.

Kanonische Fakten sind keine subjektiven Überlegenheitsbehauptungen

Ein Unternehmen kann als kanonisch festhalten: »Wir bieten Leistungsseiten in sechs Sprachen an.« Tut es das tatsächlich, ist dies ein überprüfbarer Fakt. Die Behauptung »Wir sind das beste GBO-Unternehmen der Welt« kann es nicht allein durch eigene Entscheidung kanonisch machen. Dafür braucht es:

eine definierte Vergleichsmenge,

eine Vergleichsmethode,

Daten,

einen Zeitpunkt,

eine unabhängige Bewertung.

Ein Unternehmen kann seine eigene Darstellung offiziell machen. Doch eine offizielle Selbstauskunft macht die behauptete Überlegenheit noch nicht zu einer Tatsache außerhalb des Unternehmens. Im Register müssen deshalb diese Klassen unterschieden werden:

Verifizierter Unternehmensfakt

Selbstauskunft

Marketingpositionierung

Messergebnis

Unabhängige Bewertung

Schlussfolgerung

Meinung

Eine Behauptung als kanonisch zu veröffentlichen macht sie nicht automatisch zu einem objektiven Fakt über die Außenwelt.

Widersprüchliche kanonische Fakten

Bei einem Audit können verschiedene Quellen zum selben Sachverhalt unterschiedliche Werte ausweisen. Zum Beispiel:

Webseite: 500 Dollar

CRM: 350 Dollar

Vertrag: 430 Dollar

Agentenkatalog: auf Anfrage

Altes PDF: 400 Dollar

Der erste Schritt besteht nicht darin, einen Wert auszuwählen. Zunächst ist zu fragen: Beantworten diese Angaben überhaupt dieselbe Frage? Der Vertragspreis von 430 Dollar könnte für einen bestimmten Kunden gelten. Das alte PDF könnte inzwischen ungültig sein. Der Preiseintrag von 350 Dollar im CRM könnte fehlerhaft und nicht freigegeben sein. Im Agentenkatalog wurde der Preis möglicherweise nicht aktualisiert. Die Webseite könnte den allgemeinen Neukundenpreis zeigen. Auf den ersten Blick gibt es fünf verschiedene Preise. Nach korrekter Einordnung bleibt möglicherweise nur ein echter Widerspruch.

Widersprüche zwischen Fakten auflösen

Bei einem wesentlichen Widerspruch ist folgendes Verfahren anzuwenden.

1. Die Handlung dem Risiko entsprechend stoppen

Ein Vorgang mit weitreichenden Auswirkungen darf nicht fortgesetzt werden, solange Preis, Befugnis, Einwilligung oder Zielidentität unklar sind.

2. Alle vorhandenen Versionen sichern

Einen Datensatz nicht vorschnell korrigieren und dabei historische Nachweise vernichten.

3. Faktenart und Geltungsbereich festlegen

Geht es um einen allgemeinen Preis? Einen kundenspezifischen Vertrag? Eine befristete Aktion?

4. Die Quellenrollen einordnen

Handelt es sich um eine maßgebliche Quelle, eine Darstellung, eine abgeleitete Kopie oder ein Archiv?

5. Den Gültigkeitszeitraum bestimmen

Welche Version war zum Zeitpunkt des Ereignisses aktiv?

6. Die verantwortliche Person ermitteln

Wer ist befugt, diesen Sachverhalt verbindlich zu klären?

7. Ausnahme und Fehler unterscheiden

Beruht die Abweichung auf zulässigen Sonderkonditionen oder auf einem nicht aktualisierten Datensatz?

8. Die Klärung dokumentieren

Welcher Wert wurde für welchen Geltungsbereich und welches Datum als gültig anerkannt?

9. Die Änderung in alle Darstellungen übernehmen

Web, API, CRM, Agentenverzeichnis, Angebote und Sprachfassungen.

10. Die Übernahme unabhängig prüfen

Die Aussage, die Quelle sei geändert worden, reicht nicht. Es ist zu prüfen, ob die nutzenden Systeme aktualisiert wurden.

11. Betroffene Vorgänge ermitteln

Welche Nachrichten, Angebote, Zahlungen oder Entscheidungen hat die falsche Angabe beeinflusst?

12. Erneut testen

Nutzt der Agent im selben Szenario nun die richtige Quelle?

Den alten Datensatz löschen, bevor der Widerspruch geklärt ist

Findet eine Organisation einen falschen Datensatz, möchte sie ihn möglicherweise schnell korrigieren. Das ist gut gemeint. Wird der alte Datensatz jedoch vor Beginn des Audits gelöscht, lassen sich diese Fragen nicht mehr beantworten:

Hat der Agent diesen Datensatz tatsächlich gesehen?

Wie lange war er aktiv?

Welche Vorgänge hat er beeinflusst?

In welches Agentenverzeichnis wurde er übernommen?

Wo entstand der ursprüngliche Fehler?

Sind weitere Kopien noch aktiv?

Das richtige Vorgehen:

Den bisherigen Zustand sichern.

Die Nachweise zum Ereignis unveränderlich festhalten.

Die neue Version veröffentlichen.

Die alte Version als ungültig oder archiviert kennzeichnen.

Den Umfang der Auswirkungen untersuchen.

Einen früheren falschen Datensatz aufzubewahren bedeutet nicht, ihn aktiv zu halten. Historische Nachweise sind von den im Betrieb geltenden Fakten zu trennen.

Kanonische Übernahme

Steht ein maßgeblicher Fakt fest, muss er alle für das Verhalten relevanten Darstellungen und Systeme erreichen. Diesen Vorgang können wir so bezeichnen:

Kanonische Übernahme

Eine Preisänderung kann beispielsweise folgende Bereiche betreffen:

Die für Menschen bestimmte Webseite

Den maschinenlesbaren Dienstleistungskatalog

Strukturierte Daten

Die Angebotsvorlage im CRM

Den Wissensindex des E-Mail-Agenten

Mehrsprachige Seiten

Die Vertriebspräsentation

Die Vertragsvorlage

Branchenverzeichnisse

Externe Plattformen

Wurde nur das kanonische Register geändert, kann der Agent weiterhin die alte Kopie verwenden. Die kanonische Quelle ist richtig. Die operative Wirklichkeit bleibt falsch.

Übernahmeverzögerung

Die Zeit zwischen der Änderung eines kanonischen Fakts und der Aktualisierung aller relevanten Darstellungen und Systeme lässt sich so bezeichnen:

Übernahmeverzögerung

Zum Beispiel:

Preisregister aktualisiert: 09.00 Webseite aktualisiert: 09.05 Agentenkatalog aktualisiert: 09.20 CRM-Vorlage aktualisiert: 11.30 Index des Vertriebsagenten aktualisiert: am Folgetag

Während dieser Zeit arbeitet die Organisation mit mehreren Versionen der Fakten. Bei Änderungen mit weitreichenden Auswirkungen kann das betroffene Agentenverhalten eingeschränkt werden, bis die Übernahme überall abgeschlossen ist.

Kanonische Abdeckung und Äquivalenz messen

Ein einzelner Punktwert reicht nicht aus. Manche Kennzahlen machen jedoch Lücken sichtbar.

Anteil der Fakten mit kanonischer Zuständigkeit

Wesentliche Fakten mit benannter verantwortlicher Person ÷ Wesentliche Fakten insgesamt

Äquivalenzquote der Darstellungen

Datensätze mit übereinstimmender wesentlicher Bedeutung in Darstellungen für Menschen und Maschinen ÷ Verglichene Datensätze insgesamt

Äquivalenzquote der Sprachfassungen

Sprachfassungen, die die entscheidenden Inhalte der Faktenvereinbarung bewahren ÷ Sprachfassungen insgesamt

Quote zur Einhaltung der Aktualitätsanforderungen

Innerhalb der vorgeschriebenen Frist überprüfte dynamische Fakten ÷ Dynamische Fakten insgesamt

Vollständigkeit der Übernahme

Darstellungen und Systeme mit dem aktuellen kanonischen Wert ÷ Zu aktualisierende Darstellungen und Systeme insgesamt

Anzahl ungeklärter wesentlicher Widersprüche

Offene Widersprüche, die Handlungen beeinflussen, etwa bei Preis, Befugnis, Einwilligung, Geltungsbereich oder Identität. Diese Kennzahlen schaffen lediglich operative Transparenz. Ein einzelner kritischer Widerspruch darf nicht hinter einer hohen Gesamtquote verschwinden.

Was ist ein Nachweis?

Eine Behauptung zu wiederholen ist kein Nachweis. Die Aussage eines Systems „Ich war erfolgreich“ ist kein Nachweis. Auch die Aussage einer Organisation „So ein Problem gibt es bei uns nicht“ ist keiner. Die kanonische Definition lautet: Ein Nachweis ist eine beobachtbare Aufzeichnung zu einer bestimmten Behauptung, Konfiguration, Verhaltensweise oder einem Ergebnis, deren Herkunft, Zeitpunkt, Integrität, Geltungsbereich und Erhebungsmethode bekannt sind und die einem anderen Prüfer hilft, das Urteil nachzuvollziehen. Ein Nachweis ist nicht immer ein schlüssiger Beweis. Seine Aussagekraft kann unterschiedlich stark sein. Ein Screenshot kann zeigen, was zu einem bestimmten Zeitpunkt auf dem Bildschirm zu sehen war. Er zeigt aber nicht das gesamte dahinterliegende System. Ein Log kann einen aufgezeichneten Vorgang zeigen. Verhalten außerhalb der Protokollierung zeigt es nicht.

Ein Vertrag kann eine Befugnis belegen. Er beweist jedoch nicht, dass das technische System den Vertrag eingehalten hat. Bei der Verwendung eines Nachweises müssen daher folgende Eigenschaften berücksichtigt werden:

seine Rolle,

seine Grenzen,

seine Aussagekraft.

Behauptung, Beobachtung, Schlussfolgerung, Entscheidung und Ergebnis

Diese fünf Begriffe müssen im Audit unterschieden werden.

Behauptung

Der Agent versendet keine Nachrichten ohne menschliche Freigabe.

Beobachtung

Im Szenario ohne Freigabe wurde das Versandwerkzeug nicht aufgerufen.

Schlussfolgerung

Möglicherweise verhindert das System einen Versand ohne Freigabe.

Entscheidung

Die Befugnisschranke hat den Test innerhalb des festgelegten Prüfumfangs bestanden.

Ergebnis

Beim Auditempfänger kam keine Nachricht an, und die Versandwarteschlange blieb leer. Vor dem Übergang von einer Beobachtung zu einer weitreichenden Behauptung ist zu prüfen, ob die Nachweise ausreichen. Dass in einem einzelnen Szenario keine Nachricht versendet wurde, rechtfertigt nicht den Schluss: „Der Agent kann niemals eine versenden.“ Dass eine Nachricht nicht eingegangen ist, belegt ebenso wenig zwingend, dass der Agent keinen Versandversuch unternommen hat. Ein Werkzeugaufruf könnte fehlgeschlagen sein. Das Audit darf diese Ebenen nicht vermischen.

Was ist eine Nachweiskette?

Die kanonische Definition lautet: Eine Nachweiskette ist eine versionierte Spur, die zeigt, woher, von wem, wann und wie Rohquellen erhoben wurden, die eine Auditbehauptung stützen oder widerlegen; welche Umwandlungen, Maskierungen, Klassifizierungen und Analysen sie durchlaufen haben; mit welchen Beobachtungen und Feststellungen sie verknüpft wurden; und wie ihre Integrität und ihr Aufbewahrungsstatus gesichert wurden. Einfacher gesagt: Eine Nachweiskette beantwortet von Anfang bis Ende die Frage: „Wie sind Sie zu diesem Schluss gekommen?“ Sie kann folgenden Weg abbilden:

ROHQUELLE ↓ ERHEBUNGSMETHODE ↓ ZEITPUNKT UND ERHEBENDE PERSON ↓ INTEGRITÄTSNACHWEIS ↓ ERFORDERLICHE MASKIERUNG ↓ BEOBACHTUNG ↓ ZUORDNUNG ZUR BEHAUPTUNG ↓ GEGENBELEG ↓ AUDITURTEIL

Eine Nachweiskette ist nicht die private interne Gedankenkette des Agenten. Das Audit versucht nicht, die verborgenen Überlegungen des Systems vollständig aufzuzeichnen. Benötigt wird eine beobachtbare Spur der Verantwortlichkeit:

Welche Quelle wurde gelesen?

Welches Werkzeug wurde aufgerufen?

Welche Befugnis wurde ausgeübt?

Welches Ergebnis trat außerhalb des Systems ein?

Welche Aufzeichnung hat es bestätigt?

Zehn Eigenschaften von Nachweisen

Jeder Nachweis ist anhand der folgenden Dimensionen zu bewerten.

1. Relevanz

Bezieht sich der Nachweis tatsächlich auf die aufgestellte Behauptung? Die allgemeine Sicherheitsrichtlinie eines Unternehmens belegt möglicherweise nicht, dass für den Versand einer bestimmten E-Mail die erforderliche Befugnis vorlag.

2. Befugnis

Ist die Quelle befugt, über diese Art von Fakten Auskunft zu geben? Ein Kommentar in sozialen Medien kann den aktuellen Preis nicht festlegen.

3. Zeitliche Übereinstimmung

Bildet der Nachweis den Zeitpunkt des Ereignisses oder den maßgeblichen Gültigkeitszeitraum ab? Ein heutiger Screenshot belegt nicht das Verhalten der vergangenen Woche.

4. Authentizität

Lässt sich überprüfen, ob die Quelle tatsächlich von der angegebenen Person, dem genannten System oder der genannten Organisation stammt?

5. Integrität

Wurde der Nachweis nach der Erhebung verändert? Ein Datei-Hash kann hier helfen.

6. Vollständigkeit und Kontext

Enthält die Aufzeichnung die nötigen Kontextinformationen? Ein zugeschnittener Screenshot kann eine wichtige Ausnahme verbergen.

7. Unabhängigkeit

Ist der Nachweis von der Selbstauskunft des geprüften Systems getrennt?

8. Reproduzierbarkeit

Kann ein anderer Prüfer mit derselben Methode zu einer ähnlichen Beobachtung gelangen?

9. Spezifität

Auf welchen Nutzer, welche Aufgabe, welche Version und welchen Vorgang bezieht sich der Nachweis? Ein allgemeines Log lässt das konkrete Verhalten möglicherweise nicht erkennen.

10. Verhältnismäßigkeit und Privatsphäre

Wurden für den Nachweis unnötige Daten über Menschen oder Organisationen erhoben? Starke Nachweise bedeuten keine unbegrenzte Datensammlung.

Arten von Nachweisen

In einem Audit können verschiedene Nachweisklassen gemeinsam genutzt werden.

1. Richtlinien- und Vertragsnachweise

Unternehmensrichtlinie

Aufgabenvereinbarung des Agenten

Einwilligungsdokument

Befugnisnachweis

Dienstleistungskatalog

Zeigen, was geschehen soll. Belegen für sich genommen nicht, was tatsächlich geschehen ist.

2. Konfigurationsnachweise

Agentenanweisung

Werkzeugberechtigungen

Modell- und Versionsnachweis

API-Berechtigungsumfang

Warteschlangeneinstellung

Stopprichtlinie

Zeigen, wie das System eingerichtet wurde.

3. Verhaltensnachweise

Werkzeugaufruf

Aktionsbeleg

Testausführungsprotokoll

Delegation an einen Unteragenten

Aufzeichnung der menschlichen Freigabe

Zeigen, was das System in einer bestimmten Situation getan hat.

4. Ergebnisnachweise

Nachricht im Posteingang des Empfängers

Bank- oder Zahlungsdatensatz

Ausgabe der Live-Webseite

Geänderter Kundendatensatz

Tatsächlicher API-Zustand

Zeigen, was in der Außenwelt geschehen ist.

5. Wiederherstellungsnachweise

Stoppbeleg

Abbruch der Warteschlange

Ungültigkeit des Tokens

Rollback-Ergebnis

Übergabe der Kontrolle an einen Menschen

Neustartprotokoll

Zeigen das Verhalten bei einem Fehler oder einer Rücknahme.

6. Menschliche Aussagen als Nachweise

Aussage einer befugten Person

Gesprächsaufzeichnung

Erläuterung einer Freigabe

Einwand einer betroffenen Person

Wichtig, aber für sich genommen möglicherweise kein Beleg für das technische Ergebnis.

7. Unabhängige externe Nachweise

Bestätigung durch den Empfänger

Aufzeichnung eines Drittsystems

Unabhängiges Auslesen des Live-Zustands

Externe Messung

Liefern ein Ergebnis, das vom Eigenbericht des Systems getrennt ist.

Was beweist ein Screenshot?

Screenshots sind für ein Audit nützlich. Ihre Rolle ist jedoch begrenzt. Ein Screenshot kann zeigen, dass zu einem bestimmten Zeitpunkt ein bestimmter Text auf dem Bildschirm sichtbar war. Er beweist für sich genommen nicht, dass:

die Seite tatsächlich die kanonische Quelle war,

der Inhalt zum Zeitpunkt des Ereignisses derselbe war,

die zugrunde liegenden Daten dieselben waren,

andere Nutzer dasselbe gesehen haben,

das Bild nicht zugeschnitten wurde,

der Agent diese Seite verwendet hat,

die Handlung tatsächlich stattgefunden hat,

die Seite Bots keine abweichenden Inhalte gezeigt hat.

Die Aussagekraft eines Screenshots steigt mit folgenden Zusatzinformationen:

URL oder Systemkennung

Datum und Uhrzeit

Zeitzone

Nutzerrolle

Kontext des vollständigen Bildschirms

Zugehörige Netzwerk- oder Quellenaufzeichnung

Integritätswert der Datei

Zweite, unabhängige Methode

Ein Screenshot hält eine Beobachtung fest. Er ist für sich genommen nicht befugt, den Sachverhalt festzulegen.

Was beweist ein Log?

Logs können starke Nachweise sein. Aber auch ein Log bildet die Wirklichkeit nicht unbegrenzt ab. Folgende Fragen sind zu stellen:

Welches System hat es erzeugt?

Welche Ereignisse zeichnet es nicht auf?

Sind die Uhren synchronisiert?

Kann es nachträglich verändert werden?

Reicht die Protokollierungsstufe aus?

Wie viele Agenten nutzen dasselbe Dienstkonto?

Werden fehlgeschlagene und erfolgreiche Vorgänge gleichermaßen aufbewahrt?

Bedeutet ein fehlender Logeintrag, dass keine Handlung stattgefunden hat?

Wenn eine Nachricht im Versandlog nicht auftaucht, kann das bedeuten:

Die Nachricht wurde nicht versendet.

Die Aufbewahrungsfrist des Logs ist abgelaufen.

Ein anderes Werkzeug wurde verwendet.

Ein anderes Dienstkonto wurde genutzt.

Die Protokollierung ist fehlgeschlagen.

Deshalb gilt:

NICHT IM LOG ≠ HAT DEFINITIV NICHT STATTGEFUNDEN

Ein angemessenes Urteil könnte lauten: „In den untersuchten Logs wurde kein Eintrag gefunden. Wegen weiterer Versandwege und begrenzter Aufbewahrung erlaubt dieses Fehlen keinen abschließenden Schluss.“

Was beweist ein Hash?

Der kryptografische Prüfwert einer Datei, ihr Hash, hilft bei der Prüfung, ob die Datei verändert wurde, wenn man ihn mit einem zuverlässig aufbewahrten früheren Prüfwert vergleicht. Das ist wertvoll. Ein Hash beweist jedoch nicht, dass:

die Datei aus der richtigen Quelle stammt,

ihr Inhalt wahr ist,

sie den gesamten wesentlichen Kontext enthält,

sie zum Zeitpunkt des Ereignisses aktiv verwendet wurde.

Auch eine falsche Datei kann einen korrekt berechneten Hash haben. Ein erfundener Bericht kann unverändert aufbewahrt werden. Der Hashvergleich hilft bei der Integritätsprüfung. Er belegt nicht die Richtigkeit. Deshalb sind vier Begriffe zu unterscheiden:

INTEGRITÄT: Wurde die Datei verändert? AUTHENTIZITÄT: Stammt die Datei tatsächlich aus der behaupteten Quelle? BEFUGNIS: Ist die Quelle befugt, in dieser Frage zu entscheiden? RICHTIGKEIT: Entspricht der Inhalt den Tatsachen und dem Kontext?

Starke Nachweise für einen dieser Aspekte belegen die anderen nicht automatisch.

Was beweist eine digitale Signatur?

Eine gültige digitale Signatur kann bei erfüllten Schlüssel- und Prüfbedingungen zeigen, dass:

das Dokument mit dem überprüften Signaturschlüssel signiert wurde,

das Dokument seit der Signatur nicht verändert wurde.

Eine gewöhnliche Freigabeaufzeichnung bietet nicht automatisch dieselbe kryptografische Absicherung. In beiden Fällen sind die Identitätszuordnung, der Umfang der Freigabe und die Entscheidungsbefugnis gesondert zu prüfen. Die unterzeichnende Person kann:

falsch informiert sein,

in der betreffenden Frage nicht befugt sein,

den Geltungsbereich missverstehen,

nicht alle Anlagen des Dokuments gesehen haben.

Eine Signatur hilft daher nur dann zu klären, wer etwas freigegeben hat, wenn eine verlässliche Identitätszuordnung und ein klarer Freigabekontext vorliegen. Sie belegt für sich genommen nicht, dass der Inhalt zweifelsfrei richtig ist.

Was beweist ein Quellenverweis?

Eine KI-Antwort kann auf die richtige Webseite verweisen. Das kann zeigen, dass das Modell die Seite seiner Antwort als eine der Quellen zugeordnet hat. Es zeigt aber nicht, dass jede Behauptung der Antwort auf dieser Seite steht. Das Audit muss mindestens diese drei Elemente vergleichen:

Die Behauptung in der Antwort

Den tatsächlichen Text der angeführten Quelle

Die Grenzen, innerhalb derer die Quelle die Behauptung stützt

Ein Quellenverweis belegt eine Verbindung. Ob die Quelle die Aussage inhaltlich stützt, muss gesondert geprüft werden.

Kann eine KI-Ausgabe ein Nachweis sein?

Ja. Es muss aber klar sein, wofür sie ein Nachweis ist. Eine KI-Antwort kann belegen, was der Agent zu einem bestimmten Zeitpunkt gesagt hat. Sie belegt nicht, dass die Aussage über die Außenwelt wahr ist. Ein Agent kann erklären: „Diesen Preis habe ich von der Webseite übernommen.“ Das ist seine eigene Darstellung. Die tatsächliche Quellennutzung muss anhand folgender Aufzeichnungen überprüft werden:

Abrufprotokoll,

Quellenkennung,

Werkzeugaufruf,

Aktionsbeleg.

Auch wenn mehrere Agenten dasselbe sagen, ist das kein unabhängiger Nachweis. Sie könnten dieselbe Quelle oder die Ausgaben der jeweils anderen genutzt haben.

Unverarbeitete und abgeleitete Nachweise

Im Audit sind zwei Arten von Nachweisen zu unterscheiden.

Unverarbeitete Nachweise

Die Aufzeichnung, die der Quelle am nächsten ist. Beispiele:

Ursprüngliche API-Antwort

Unverarbeiteter Logauszug

Datei des unterzeichneten Vertrags

Live-HTML

Aufzeichnung einer versendeten Nachricht

Einwilligungsregister

Abgeleitete Nachweise

Sie können aus unverarbeiteten Nachweisen in folgenden Formen entstehen:

Zusammenfassung,

Klassifizierung,

maskierte Fassung,

Tabelle,

grafische Darstellung,

Interpretation eines Agenten.

Abgeleitete Nachweise sind nützlich. Sie müssen jedoch mit ihrer Rohquelle verknüpft bleiben. Eine Zusammenfassung kann lauten: „36/36 Zugriffstests bestanden.“ Der Prüfer muss bei Bedarf erkennen können, welche 36 Tests wann und mit welchem User-Agent durchgeführt wurden.

Umwandlung von Nachweisen

Nachweise können im Verlauf des Audits verändert werden. Zum Beispiel:

Personenbezogene Daten werden maskiert.

Logs werden auf den relevanten Zeitraum gefiltert.

Unterschiedliche Zeitzonen werden abgeglichen.

Dateien werden in ein gemeinsames Format umgewandelt.

Ereignisse werden mithilfe von KI klassifiziert.

Text wird aus einem Bild extrahiert.

Mehrere Aufzeichnungen werden in einer Tabelle zusammengeführt.

Jede dieser Umwandlungen muss dokumentiert werden. Folgende Fragen sind zu beantworten:

Welches Werkzeug wurde verwendet?

Welche Version?

Welche Felder wurden entfernt?

Welche Werte wurden maskiert?

Hat sich die Bedeutung verändert?

Bleibt die Rohquelle erhalten?

Lässt sich die Umwandlung reproduzieren?

Umgewandelte Nachweise dürfen nicht als Rohquelle ausgegeben werden.

Maskierung und Schwärzung

Prüfnachweise können personenbezogene Informationen oder Geschäftsgeheimnisse enthalten. Einzelne Teile dürfen deshalb unkenntlich gemacht werden. Eine Schwärzung darf jedoch nicht:

den wesentlichen Kontext verändern,

zu Verwechslungen bei der Identität des Ziels führen,

zeitliche Zusammenhänge verfälschen,

ausschließlich günstige Inhalte sichtbar lassen.

Ein Kundenname lässt sich beispielsweise durch das Pseudonym Müşteri-017 ersetzen. Erhalten jedoch zwei verschiedene Kunden dasselbe Pseudonym, kann das die Untersuchung einer Aktion am falschen Ziel beeinträchtigen. Das Schwärzungsprotokoll muss folgende Angaben enthalten:

redaction_applied: true
redacted_fields:
  - personal_name
  - email_local_part
reason:
  privacy_protection
performed_by:
  AUDITOR-02
raw_source_retained:
  secure_vault

Der öffentliche Bericht kann geschwärzt sein, während für eine befugte Nachprüfung ein kontrollierter Zugang zu den unverarbeiteten Nachweisen erhalten bleibt.

Uhren und Zeitzonen in der Nachweiskette

In einer Umgebung mit mehreren Systemen können die Uhren voneinander abweichen.

Der E-Mail-Dienst verwendet UTC.

Das CRM verwendet die Ortszeit.

Die Uhr des Agentenservers geht einige Minuten nach.

Die externe Plattform verwendet eine andere Zeitzone.

Dadurch kann eine Ereigniskette in die falsche Reihenfolge geraten. Eine menschliche Freigabe, die erst nach dem Versand erteilt wurde, kann wegen der Zeitdifferenz so aussehen, als sei sie vorher erfolgt. Nachweisdatensätze müssen deshalb Folgendes enthalten:

einen absoluten Zeitstempel,

die Zeitzone,

die Zeitquelle,

eine bekannte Uhrenabweichung.

Auch die Zeitsynchronisierung kann Gegenstand der Prüfung sein.

Gegenbelege

Prüfer dürfen nicht nur Unterlagen sammeln, die ihre erste Annahme stützen. Sie müssen auch fragen: Welche Nachweise sprechen gegen dieses Urteil? Angenommen, die Behauptung lautet, ein Agent habe ohne Freigabe eine Nachricht versandt. Dafür sprechen könnten:

die versandte Nachricht,

das Fehlen eines Freigabenachweises,

der Werkzeugaufruf.

Als Gegenbelege kommen infrage:

die allgemeine Kampagnenfreigabe durch eine menschliche Führungskraft,

die Behauptung, eine dauerhafte Versandbefugnis sei bereits erteilt worden,

ein Freigabenachweis in einem anderen System.

Der Prüfer bewertet diese Gegenbelege. Möglicherweise besteht tatsächlich eine allgemeine Freigabe, die diesen konkreten Versand aber hinsichtlich folgender Punkte nicht erfasst:

Ziel,

Geltungsdauer,

Kanal,

Nachrichtentyp.

Wer Gegenbelege sichtbar macht, stärkt die Grundlage des Urteils.

Fehlende Nachweise und Unsicherheit

Manche Ereignisse lassen sich nicht mit Sicherheit rekonstruieren. Protokolle können gelöscht oder das Konto eines ehemaligen Mitarbeiters geschlossen worden sein. Vielleicht führt der externe Anbieter keine Aufzeichnungen. Solche Lücken dürfen Prüfer nicht mit Vermutungen füllen. Dafür eignen sich folgende Statusangaben:

Verifiziert

Stark gestützt

Teilweise gestützt

Widersprüchlich

Unzureichende Nachweise

Konnte nicht verifiziert werden

Nachweisverlust

„Konnte nicht verifiziert werden“ bedeutet nicht „nicht geschehen“. „Unzureichende Nachweise“ bedeutet nicht „das System ist sicher“.

Auch Nachweisverlust ist eine Feststellung

Kann eine Organisation folgenreiches Agentenverhalten später nicht mehr rekonstruieren, erschwert das nicht nur die Prüfung. Es ist eine eigenständige Governance-Lücke. Beispiele:

Es ist unbekannt, welcher Agent die Nachricht versandt hat.

Ein Nachweis der menschlichen Freigabe fehlt.

Die verwendete Preisquelle ist nicht auffindbar.

Das Datum des Tokenwiderrufs ist unbekannt.

Es wird kein Stoppbeleg aufbewahrt.

Ob das Ereignis günstig oder schädlich war, bleibt dann möglicherweise offen. Fest steht jedoch: Die Organisation zeichnet wesentliches Agentenverhalten nicht prüfbar auf. Der Verlust von Nachweisen kann für sich genommen eine Feststellung begründen.

Unabhängigkeit der Nachweise

Die von einem System selbst erzeugten Aufzeichnungen sind nicht durchweg wertlos. Sich ausschließlich anhand der eigenen Aufzeichnungen zu verifizieren, ist jedoch riskant. Ein Agent für Webveröffentlichungen könnte etwa:

eine Datei hochladen,

den Protokolleintrag „Upload erfolgreich“ erzeugen,

sein eigenes Protokoll lesen und „Live-Verifizierung bestanden“ melden.

Alle drei Schritte gehen auf dieselbe Informationsquelle zurück. Für eine unabhängige Verifizierung kommen etwa infrage:

ein erneuter Abruf der Live-Website über HTTPS,

ein anderer Browser,

ein externer Beobachtungspunkt,

ein separates Prüfkonto.

Unabhängigkeit setzt nicht immer ein anderes Unternehmen voraus. Auch ein anderes System derselben Organisation kann unabhängige Nachweise liefern, wenn es von der zu prüfenden Aktion getrennt ist.

Nachweispakete

Für jede wesentliche Prüfbehauptung lässt sich Folgendes zusammenstellen:

Ein Nachweispaket

Zum Beispiel:

NACHWEISPAKET — PRICE-INCIDENT-01

Behauptung: Am 8. September 2026 um 09.14 Uhr sandte der Vertriebsagent einem Kunden eine Nachricht mit dem ungültigen Preis von 350 USD. Kanonischer Sachverhalt: Der gültige allgemeine Einstiegspreis betrug 500 USD/Monat. Unverarbeitete Nachweise:

PRICING-REGISTRY-v4.2

Die zum Ereigniszeitpunkt verwendete Version der CRM-Vorlage

Der Retrieval-Nachweis des Vertriebsagenten

Die versandte E-Mail

Die Freigabe durch die für den Preis verantwortliche Person

Eine archivierte Fassung der Webseite aus der Zeit vor dem Ereignis

Operative Realität: Im Wissensindex des Agenten war der Eintrag mit 350 USD aktiv. Aktionsergebnis: Beim Kunden ging eine Nachricht mit einem Preis von 350 USD ein. Gegenbeleg: Die aktuelle Webseite des Unternehmens zeigt 500 USD. Bewertung des Gegenbelegs: Die heutige Seite zeigt den korrekten Zustand nach dem Ereignis. Sie widerlegt nicht, welche Eingabe dem Agenten zum Ereigniszeitpunkt vorlag. Integritätsnachweise:

Dateihashes

E-Mail-Nachrichten-ID

Zeitstempel

Versions-IDs des Archivs

Offene Unsicherheit: Wer den alten CRM-Preis ursprünglich angelegt hat, ließ sich nicht verifizieren. Prüfurteil: Der maßgebliche Preis betrug 500 USD. Die vom Vertriebsagenten verwendete operative Quelle widersprach dem kanonischen Preis. Das Ereignis entspricht GBO-ERR-012, GBO-ERR-016 und GBO-ERR-092.

Dieses Paket stützt das Urteil nicht auf ein einzelnes Dokument oder einen einzelnen Screenshot. Es zeigt die gesamte Verhaltenskette.

Register kanonischer Fakten

Das erste verpflichtende Dokument dieses Kapitels ist:

NOMOS GBO Register kanonischer Fakten.

Das Register führt die wesentlichen Fakten des Prüfungsumfangs zusammen.

Menschenlesbares Beispiel

KANONISCHER FAKTENDATENSATZ

Fakten-ID: CANON-PRICE-MSO-2026-04

Entität: NobleAxis Managed Site Operations

Faktentyp: Allgemeiner Einstiegspreis

Kanonischer Wert: 500 USD/Monat

Geltungsbereich:

Neue Direktkunden

Basisleistung für den verwalteten Websitebetrieb

Hosting und Lizenzen Dritter ausgeschlossen

Steuern werden gemäß Vertrag gesondert berücksichtigt

Nicht erfasst:

Hosting Core für 200 USD/Jahr

Kundenspezifische Wartungsverträge

Verträge mit fortgeltendem früherem Preis

Menschlicher Verantwortlicher: Verantwortlicher für den kaufmännischen Betrieb

Maßgebliche Quelle: Pricing Registry v4.2

Darstellungen für Menschen:

Englische Leistungsseite

Türkische Leistungsseite

Angebotsvorlage v5.1

Darstellungen für Maschinen:

Service Catalog v4.2

Structured Data v3.8

Sales Agent Knowledge Index v7.1

Gültig ab: 1. September 2026

Gültig bis: Zur Veröffentlichung einer neuen maßgeblichen Version

Ereignisse, die den Datensatz ungültig machen:

Freigabe eines neuen Preises

Änderung des Leistungsumfangs

Änderung der rechtlich maßgeblichen Preisrichtlinie

Ausnahmen:

Unterzeichneter kundenspezifischer Vertrag

Datierter Kampagneneintrag

Ersetzter Datensatz: CANON-PRICE-MSO-2026-03 — 450 USD/Monat

Letzte Verifizierung: 8. September 2026, 08.42 Uhr

Offener Widerspruch: Der alte Preis von 350 USD in CRM Template v2.8

Status: Aktiv; Übernahme in die operativen Systeme unvollständig

Maschinenlesbares Register kanonischer Fakten

canonical_fact:
  fact_id: CANON-PRICE-MSO-2026-04

  entity:
    entity_id: SERVICE-MSO-001
    canonical_name: Managed Site Operations

  fact_type: starting_price

  value:
    amount: 500
    currency: USD
    billing_period: month

  scope:
    customer_type:
      - new_direct_customer
    included:
      - managed_site_operations_base_scope
    excluded:
      - hosting_core
      - third_party_licenses
      - taxes_unless_contractually_included

  owner:
    human_role: commercial_operations_owner
    approval_record: APPROVAL-PRICE-2026-104

  authoritative_source:
    source_id: PRICING-REGISTRY-4.2
    source_role: canonical_authority

  representations:
    human:
      - SERVICE-PAGE-EN-v6.1
      - SERVICE-PAGE-TR-v6.1
      - PROPOSAL-TEMPLATE-5.1
    machine:
      - SERVICE-CATALOG-4.2
      - STRUCTURED-DATA-3.8
      - SALES-KNOWLEDGE-INDEX-7.1

  validity:
    effective_from: 2026-09-01T00:00:00+03:00
    effective_until: null
    invalidate_on:
      - authorized_price_change
      - service_scope_change
      - applicable_legal_pricing_policy_change

  exceptions:
    allowed_only_when:
      - signed_customer_contract
      - approved_time_limited_campaign

  supersedes:
    fact_id: CANON-PRICE-MSO-2026-03

  conflicts:
    - source_id: CRM-TEMPLATE-2.8
      conflicting_value: 350
      status: obsolete_unresolved_copy

  status: active_with_propagation_gap

Dieser Datensatz speichert nicht nur den Wert von 500 Dollar. Er zeigt zugleich:

wer dafür verantwortlich ist,

für welchen Bereich der Wert gilt,

wo er dargestellt wird,

welche Gültigkeit er hat,

welcher Widerspruch dazu besteht.

Nachweisregister

Das zweite verpflichtende Dokument dieses Kapitels ist:

NOMOS GBO Nachweisregister.

Jeder Nachweisdatensatz zeigt, welche Behauptung oder Feststellung er stützt und wo seine Grenzen liegen. Der Preisvorfall dieses Kapitels ist ein eigener Lehrfall. Er ist vom veralteten Preiseintrag v3.7 im Beispiel zur Kundensuche getrennt. Hier werden PRICING-REGISTRY-v4.2 und GBO-AUDIT-PRICING-2026-001 verwendet. Die Nachweise beider Akten dürfen nicht so zusammengeführt werden, als gehörten sie zu demselben eingefrorenen Prüfungsumfang.

Menschenlesbarer Nachweisdatensatz

Nachweis-ID: EVID-PRICE-INCIDENT-004

Prüfungs-ID: GBO-AUDIT-PRICING-2026-001

Nachweisart: Aktionsbeleg des Agenten und Quellenspur

Quellsystem: Sales Agent v2.4

Quellenrolle: Verhaltensnachweis

Zugehöriges Ereignis: Preis-E-Mail um 09.14 Uhr

Erfassungszeit: 8. September 2026, 10.12 Uhr

Erfasst durch: Prüfer AUDITOR-02

Unverarbeiteter Datensatz: ACTION-EMAIL-8841

Integritätsnachweis: Hash und Nachrichten-ID erfasst

Was der Nachweis zeigt:

Die E-Mail wurde vom Vertriebsagenten versandt.

In der Nachricht wurde ein Preis von 350 USD verwendet.

Als Quellen-ID wurde CRM-TEMPLATE-2.8 erfasst.

Es wurde kein Nachweis einer menschlichen Freigabe gefunden.

Was der Nachweis nicht zeigt:

Wer die CRM-Vorlage ursprünglich erstellt hat

Ob die menschliche Führungskraft über einen anderen Kanal eine allgemeine Versandfreigabe erteilt hat

Ob der Kunde das Angebot rechtlich angenommen hat

Vorgenommene Veränderungen:

Die E-Mail-Adresse des Kunden wurde maskiert.

Persönliche Angaben in der Signatur wurden entfernt; der Nachrichtentext blieb erhalten.

Speicherort des unverarbeiteten Datensatzes: Verschlüsselter Nachweistresor

Gestützte Feststellungen:

FINDING-AUTH-03

FINDING-CANON-02

Gegenbeleg:

Die aktuelle Webseite zeigt 500 USD.

Status: Verifiziert

Aufbewahrungsfrist: 180 Tage; bei laufender Streitigkeit erneut bewerten

Maschinenlesbares Nachweisregister

evidence_record:
  evidence_id: EVID-PRICE-INCIDENT-004
  audit_id: GBO-AUDIT-PRICING-2026-001

  evidence_type:
    - action_receipt
    - source_trace

  source:
    system_id: SALES-AGENT-2.4
    record_id: ACTION-EMAIL-8841
    source_role: behavioral_evidence

  acquisition:
    collected_by: AUDITOR-02
    collected_at: 2026-09-08T10:12:00+03:00
    method: read_only_export

  integrity:
    hash_algorithm: SHA-256
    hash_value: recorded_in_secure_vault
    source_message_id: MSG-928472
    integrity_status: verified

  temporal_relevance:
    event_time: 2026-09-08T09:14:00+03:00
    time_alignment: direct

  observations:
    - email_was_sent
    - stated_price_was_350_USD
    - source_id_was_CRM_TEMPLATE_2_8
    - explicit_human_approval_not_present_in_record

  limitations:
    - does_not_identify_original_creator_of_CRM_template
    - does_not_exclude_approval_existing_in_unreviewed_channel
    - does_not_establish_contract_acceptance

  transformations:
    - customer_email_masked
    - personal_signature_removed

  supports:
    findings:
      - FINDING-AUTH-03
      - FINDING-CANON-02

  counter_evidence:
    - EVID-WEB-CURRENT-001

  storage:
    location: encrypted_evidence_vault
    access:
      - lead_auditor
      - authorized_client_reviewer

  retention:
    days: 180
    deletion_receipt_required: true
    review_on_ongoing_dispute_or_preservation_duty: required
    example_duration_not_universal_legal_rule: true

  status: verified

Statusangaben im Nachweisregister

Bearbeitungshistorie, Verifizierungsstatus, Einwände und Zugangsbedingungen sind getrennt zu verfolgen. Mehrere der folgenden Kennzeichnungen können gleichzeitig zutreffen. So kann die Integrität eines Datensatzes verifiziert sein, während der Zugriff beschränkt ist und sein Inhalt angefochten wird:

Erfasst

Integrität verifiziert

Authentizität verifiziert

Teilweise verifiziert

Widersprüchlich

Angefochten

Für ungültig erklärt

Durch neuen Nachweis ersetzt

Abgelaufen

Nachweisverlust

Zugriff beschränkt

Archiviert

Gelöscht und Beleg erstellt

Erweist sich ein Nachweis später als falsch oder unvollständig, darf sein Datensatz nicht stillschweigend gelöscht werden. Stattdessen muss sich der Status ändern. So bleibt nachvollziehbar, warum das frühere Urteil geändert wurde.

Behauptungs-Nachweis-Matrix

Jede wesentliche Prüfbehauptung muss den Nachweisen zugeordnet werden, die sie stützen oder ihr widersprechen.

Diese Matrix verhindert, dass Prüfer mehr behaupten, als die Nachweise tragen.

Mindestfelder eines Nachweispakets

Jede Feststellung mit hoher Auswirkung muss mindestens folgende Felder enthalten:

claim expected_state observed_state canonical_fact raw_evidence operational_evidence action_evidence outcome_evidence counter_evidence time_alignment transformations limitations uncertainties reviewer judgment

Beruht eine Feststellung ausschließlich auf einem Screenshot, einer menschlichen Aussage oder der Erklärung des Agenten, muss das ausdrücklich erkennbar sein.

Nachweisaufbewahrung und Datenminimierung

Prüfnachweise sollen nicht unbegrenzt aufbewahrt werden. Die Aufbewahrungsdauer kann abhängen von:

der Risikostufe,

dem Stand einer Streitigkeit,

dem Vertrag,

Datenschutzanforderungen,

dem Bedarf an erneuten Tests,

dem Abschlussstatus des Vorfalls.

Soweit möglich, sollten:

personenbezogene Daten maskiert,

nicht benötigte Inhalte entfernt,

der Zugriff auf unverarbeitete Nachweise beschränkt,

öffentliche Berichte auf eine Zusammenfassung begrenzt,

nach der Löschung ein Beleg erstellt werden.

Bei der Nachweisminimierung darf jedoch kein entscheidender Kontext verloren gehen. Wird etwa nur der Nachrichtentext aufbewahrt, während folgende Angaben gelöscht werden:

Empfänger,

Zeit,

Quellen-ID,

Freigabenachweis,

kann der Vorgang dadurch unprüfbar werden.

Nachweistresor und Nachweiszugriff

Kritische Nachweise können in einem separaten Nachweistresor gespeichert werden. Dieser kann Folgendes bieten:

Zugriffskontrolle,

Änderungsprotokoll,

Verschlüsselung,

Integritätsprüfung,

Versionierung,

Löschrichtlinie,

Aufzeichnung darüber, wer welchen Datensatz eingesehen hat.

Prüfer dürfen nicht sämtliche Nachweise auf ihr privates Gerät oder in ein nicht freigegebenes Cloud-Werkzeug kopieren. Auch KI-Werkzeuge zur Nachweisanalyse müssen dafür autorisiert sein.

KI-gestützte Nachweisanalyse

Ein Prüfagent kann:

Tausende Protokolleinträge klassifizieren,

einen Zeitablauf rekonstruieren,

ähnliche Ereignisse gruppieren,

Sprachfassungen vergleichen,

widersprüchliche Quellen markieren.

Das ist nützlich. Dabei gelten jedoch folgende Grenzen:

Die KI-Ausgabe darf unverarbeitete Nachweise nicht ersetzen.

Die Klassifizierung durch die KI darf nicht als unabhängige Verifizierung gelten.

Die endgültige Feststellung darf nicht allein von der KI-Ausgabe abhängen.

Ein Prüfagent könnte etwa sagen: „Dieser Datensatz sieht nach einem Befugnisverstoß aus.“ Der menschliche Prüfer muss dann untersuchen:

die tatsächlich geltende Befugnisvereinbarung,

den Umfang des Vorgangs,

die Gegenbelege.

Auch folgende Angaben zum eingesetzten KI-System müssen in der Nachweiskette sichtbar sein:

Version,

Datenzugriff,

Transformationsmethode.

Nachweiskontamination

Synthetische Datensätze aus einer Prüfung können sich mit echten Betriebsdaten vermischen. Beispiele:

Ein Prüfkunde wird in die echte Kundenliste aufgenommen.

Ein Testpreis wird in den Vertriebskatalog geschrieben.

Ein Angriffsszenario bleibt als echte Anweisung im Gedächtnis des Agenten zurück.

Eine Prüf-E-Mail-Adresse wird später zum Vertriebsziel.

Ein synthetischer Einwilligungsdatensatz wird einer echten Person zugeordnet.

Dafür können wir den folgenden Begriff verwenden:

Nachweis- und Testkontamination

Prüfdaten müssen eindeutig gekennzeichnet werden. Nach Testende sind:

die Daten aus dem aktiven System zu entfernen,

die erforderlichen Nachweiskopien aufzubewahren,

die im Gedächtnis verbliebenen Änderungen zu bereinigen,

Lösch- oder Archivierungsbelege zu erstellen.

Eine Prüfung darf das System nicht unbemerkt verändern, während sie es untersucht.

Zwölf Schritte zur Prüfung kanonischer Fakten

1. Wesentliche Behauptungen erfassen

Fakten auflisten, die das Verhalten beeinflussen: etwa Preis, Befugnis, Einwilligung, Umfang, Kapazität und Ergebnis.

2. Die Entität eindeutig identifizieren

Verwechslungen mit einer anderen Person, einem anderen Unternehmen, Dienst oder Agenten verhindern.

3. Den Faktentyp einordnen

Jede Behauptung der passenden Faktenfamilie zuordnen.

4. Den menschlichen Verantwortlichen bestimmen

Wer ist für die Aktualität und Richtigkeit des Fakts verantwortlich?

5. Die maßgebliche Quelle bestimmen

Welcher Datensatz ist befugt, für diesen Faktentyp die letzte Entscheidung vorzugeben?

6. Die operativen Quellen finden

Welche Kopie oder welchen Index verwendet der Agent tatsächlich?

7. Zeit und Geltungsbereich festhalten

Welcher Wert galt zum Ereigniszeitpunkt für welchen Nutzer und Vorgang?

8. Ausnahme und Widerspruch unterscheiden

Handelt es sich um einen Sondervertrag, eine Kampagne oder einen historischen Datensatz?

9. Darstellungen für Menschen und Maschinen sowie Sprachfassungen abgleichen

Transportieren alle Darstellungen dieselbe Faktenvereinbarung?

10. Die Nachweiskette aufbauen

Unverarbeitete Quelle, Integrität, Transformation, Beobachtung und Gegenbelege miteinander verknüpfen.

11. Die Übernahme verifizieren

Hat die kanonische Korrektur alle betroffenen Systeme erreicht?

12. Das Verhalten erneut testen

Führt der Agent nun auf Grundlage des richtigen Fakts die richtige Aktion aus?

Prüfschranke für kanonische Fakten und die Nachweiskette

Bevor aus einer Behauptung ein Prüfurteil wird, müssen folgende Schranken bewertet werden:

1. Entität

Bezieht sich der Fakt auf die richtige Person, Organisation, Dienstleistung oder den richtigen Agenten?

2. Faktentyp

Ist die Quelle befugt, über diesen Gegenstand zu entscheiden?

3. Menschliche Verantwortung

Ist bekannt, welcher Mensch für den Fakt verantwortlich ist?

4. Geltungsbereich

Wurden allgemeine Regel, Ausnahme und konkreter Vorgang voneinander getrennt?

5. Zeit

Passt der Nachweis zum Ereigniszeitpunkt und zum Gültigkeitszeitraum?

6. Äquivalenz der Darstellungen

Vermitteln die Darstellungen für Menschen und Maschinen sowie die Sprachfassungen denselben wesentlichen Fakt?

7. Operativer Zugriff

Ist die Quelle bekannt, die der Agent tatsächlich verwendet hat?

8. Herkunft

Sind die ursprüngliche Quelle und die Ableitungskette des Nachweises sichtbar?

9. Integrität

Lässt sich verifizieren, dass der Nachweis unverändert ist und seine Transformationen aufgezeichnet wurden?

10. Unabhängigkeit

Beruht das Ergebnis ausschließlich auf der eigenen Aussage des geprüften Systems?

11. Gegenbelege

Wurden Aufzeichnungen bewertet, die dem Urteil widersprechen?

12. Privatsphäre

Wurden mehr Daten erhoben, als die Prüfung benötigt?

13. Reproduzierbarkeit

Kann ein anderer Bewerter anhand desselben Datensatzes zu einem ähnlichen Ergebnis gelangen?

14. Aufbewahrung und Gültigkeit

Wie lange wird der Nachweis aufbewahrt, und wer erhält unter welchen Bedingungen Zugang? Vereinfacht:

PRÜFBARE REALITÄT = RICHTIGE ENTITÄT UND RICHTIGER FAKTENTYP UND BEFUGTER MENSCHLICHER VERANTWORTLICHER UND DEFINIERTER GELTUNGSBEREICH UND GÜLTIGER ZEITBEZUG UND ÄQUIVALENZ DER DARSTELLUNGEN UND SPUR DER OPERATIVEN QUELLE UND HERKUNFT DER NACHWEISE UND INTEGRITÄT UND UNABHÄNGIGE VERIFIZIERUNG UND PRÜFUNG DER GEGENBELEGE UND VERHÄLTNISMÄSSIGE DATENNUTZUNG

Kritische Unsicherheiten über die Fakten

Manche Unsicherheiten können es erfordern, das Verhalten vor Beginn der Szenariotests vorübergehend auszusetzen. Beispiele:

Es ist unbekannt, welcher Preis gilt.

Es gibt widersprüchliche Angaben dazu, wer die Befugnis besitzt.

Der Einwilligungsnachweis ist nicht auffindbar.

Die vom Agenten verwendete Datenquelle ist unbekannt.

Darstellungen für Menschen und Maschinen zeigen unterschiedliche Geltungsbereiche.

Es lässt sich nicht feststellen, in welchem Konto das Versandergebnis entstand.

Es besteht der Verdacht, dass der Nachweis nach dem Ereignis verändert wurde.

Die Ausgabe eines Unteragenten wird als unabhängige Quelle verwendet.

Für einen Vorgang mit nahezu kritischem Risiko liegt nur ein aktueller Screenshot vor.

Die angemessene Prüfreaktion lautet dann nicht: „Die Nachweise reichen nicht aus; machen wir trotzdem weiter.“ Sie kann vielmehr lauten: „Das betreffende Verhalten mit hoher Auswirkung ist einzuschränken, bis Faktenlage und Nachweisweg geklärt sind.“

Was soll ein Agent tun, wenn kanonische Fakten fehlen?

Trifft ein Agent auf zwei widersprüchliche Preis-, Rollen- oder Einwilligungsdatensätze, darf er keinen neuen Fakt erfinden. Die richtige Reaktion kann je nach Risiko unterschiedlich ausfallen:

Bei geringem Risiko

Die Unsicherheit erklären und mögliche Optionen aufzeigen.

Bei mittlerem Risiko

Die maßgebliche Quelle oder den verantwortlichen Menschen suchen.

Bei hohem Risiko

Die Aktion stoppen und die Entscheidung einem Menschen übergeben. Der Agent könnte sagen: „Für diese Leistung gibt es zwei aktive Einträge: 500 und 350 USD. Der Preis von 500 USD steht im Preisregister, 350 USD in einer alten CRM-Vorlage. Ohne Bestätigung des für die kanonischen Geschäftsdaten verantwortlichen Menschen sende ich dem Kunden keinen Preis.“ Diese Antwort kann wie eine unerledigte Aufgabe wirken. Tatsächlich ist das angemessenes Verhalten.

Was soll ein Prüfer tun, wenn die Nachweiskette fehlt?

Findet der Prüfer nicht genügend Nachweise, um eine Behauptung zu verifizieren, hat er drei Möglichkeiten:

1. Die Behauptung eingrenzen

„Es wurde verifiziert, dass die Richtlinie diese Regel enthält. Ihre Anwendung im Verhalten konnte nicht verifiziert werden.“

2. Weitere Nachweise anfordern

Unverarbeitete Protokolle

Versionsaufzeichnung

Unabhängiger Test

Freigabe des verantwortlichen Menschen

3. Eine Feststellung zu unzureichenden Nachweisen erfassen

„Im geprüften Umfang konnten keine ausreichenden Aufzeichnungen beschafft werden, um die menschliche Freigabe für die Aktion mit hoher Auswirkung nachträglich zu rekonstruieren. Ob der Nachweis nie geführt wurde, verloren ging oder nicht zur Prüfung vorgelegt wurde, ist noch nicht geklärt.“ Es ist nicht Aufgabe des Prüfers, diese Lücke mit vorausgesetztem Vertrauen zu füllen.

Verpflichtende Ergebnisse dieses Kapitels

Nach Abschluss dieses Kapitels muss die Prüfakte zwei Strukturen enthalten:

1. Register kanonischer Fakten

Es enthält alle wesentlichen Fakten des Prüfungsumfangs zu Identität, Preis, Umfang, Kapazität, Einwilligung, Befugnis und Ergebnis.

2. Nachweisregister

Es zeigt, auf welchen Nachweisen jede Behauptung, jeder Test, jede Feststellung sowie jedes Urteil über Ergebnisse oder Wiederherstellung beruht. Dazu gehören Herkunft, Zeit, Integrität, Transformation und Grenzen der Nachweise. Beide Register müssen mit der Verhaltenskarte verbunden sein. Von jedem wesentlichen Knoten der Karte müssen erreichbar sein:

der kanonische Fakt,

der zugehörige Nachweis,

der verantwortliche Mensch.

Das gemeinsame Ergebnis der ersten vier Kapitel

Die Grundlage der Prüfung steht nun. Vorhanden sind:

Blatt zur Prüfaussage

Es zeigt, was wir nachweisen wollen.

Prüfermächtigung

Sie zeigt, was der Prüfer innerhalb welcher Grenzen tun darf.

Protokoll des festgeschriebenen Prüfumfangs

Es hält fest, welche Systemversion geprüft wird.

Verhaltenskarte für Menschen, Agenten und Werkzeuge

Sie zeigt sämtliche Verhaltenswege: vom menschlichen Ziel über externe Aktionen und Nachweise bis zum Stopp.

Register kanonischer Fakten

Es bestimmt für jeden wesentlichen Fakt die maßgebliche Quelle, die verantwortliche Person, den Geltungsbereich, den Zeitbezug und die Ausnahme.

Nachweisregister

Es macht rekonstruierbar, wie das Prüfurteil zustande kam. Auch ohne diese Strukturen kann man direkt zu Testszenarien übergehen. Dann prüfen die Tests womöglich das falsche System, den falschen Fakt oder die falsche Befugnis.

Das Urteil dieses Kapitels

Korrekte Informationen auf der Website einer Organisation beweisen nicht, dass ihr Agent korrekte Informationen verwendet hat. Ein richtiger Preis im maßgeblichen Register zeigt nicht, dass alle operativen Quellen aktuell sind. Ein Screenshot rekonstruiert nicht das System zum Ereigniszeitpunkt. Ein Hashvergleich prüft Änderungen gegenüber einer verlässlichen früheren Aufzeichnung; er beweist nicht, dass der Dateiinhalt stimmt. Eine digitale Signatur kann den Unterzeichner erkennen lassen, nicht aber die durchgängige Richtigkeit des Inhalts belegen. Ein Quellenverweis kann eine Verbindung zur Quelle zeigen, ohne zu belegen, dass diese die Behauptung tatsächlich stützt. Eine KI-Erklärung zeigt, was das System gesagt hat. Sie beweist für sich allein nicht die tatsächliche Ursache des Verhaltens. Das erste Urteil dieses Kapitels lautet daher: Kanonische Fakten sind nicht bloß Werte. Sie verbinden die richtige Entität und den richtigen Faktentyp mit befugtem Verantwortlichem, Geltungsbereich, Zeit, Ausnahme und Version.

Zweitens: Eine kanonische Quelle muss nicht eine einzige Datei sein, in der alles steht. Für jeden wesentlichen Faktentyp muss bekannt sein, welche Quelle maßgeblich ist. Drittens: Allgemeine Regel, vorübergehende Ausnahme und konkreter Vorgang dürfen sich nicht gegenseitig im selben Faktenfeld überschreiben. Viertens: Ein heute korrekter Datensatz beweist nicht automatisch, was der Agent früher gesehen und seiner Handlung zugrunde gelegt hat. Fünftens: Darstellungen für Menschen und Maschinen sowie verschiedene Sprachfassungen müssen dieselbe Faktenvereinbarung für das Verhalten vermitteln. Sechstens: Nachweise zu besitzen, reicht nicht. Herkunft, Zeit, Integrität, Transformation, Unabhängigkeit und Grenzen müssen bekannt sein. Siebtens: Fehlende Nachweise bedeuten nicht, dass keine Fehler vorliegen. Lässt sich wesentliches Verhalten nicht rekonstruieren, ist das eine eigenständige Governance-Feststellung.

Achtens: Die Nachweiskette ist keine private Gedankenkette, sondern eine beobachtbare Spur von Quelle, Befugnis, Aktion, Ergebnis und Wiederherstellung. Und das abschließende Urteil: Eine Prüfung darf kein eindeutiges Urteil über Bereiche fällen, die ihre Nachweise nicht abdecken. Wir wissen nun:

was wir prüfen,

von wem wir dazu ermächtigt wurden,

welche Verhaltenswege das System nutzt,

welche Fakten kanonisch sind,

welche Nachweise diese Fakten stützen.

Die 99 in Band II definierten Fehler sind jedoch nicht für jedes System gleich wichtig. Bei einem Agenten zur Dokumentzusammenfassung besteht möglicherweise kein Risiko eines falschen Preises. Bei einem Einkaufsagenten können dagegen Fehler bei Budget, Abonnements und Doppelzahlungen kritisch sein. In einem Avatarsystem sind Einwilligung und synthetische Identität Fragen auf Vetoebene. Bei einem Webagenten stehen Live-Veröffentlichung, kanonische Daten und Rollback im Vordergrund. Bei einem Agenten zur Kundensuche sind der richtige Adressat, personenbezogene Daten und die Befugnis zum externen Versand entscheidend. Derselbe Fehler kann in einem risikoarmen Entwurf begrenzte Auswirkungen haben, in einem anderen System aber Millionen Menschen oder eine Transaktion mit hohem Wert betreffen.

Deshalb besteht der nächste Schritt nicht darin, alle 99 Fehler wahllos zu testen. Zuerst sind folgende Fragen zu beantworten:

Welche Fehlerfamilien sind auf dieses System tatsächlich anwendbar? Welche sind am wahrscheinlichsten? Welche richten den größten Schaden an? Welche sind unumkehrbar? Welche müssen schon bei einem einzigen Ereignis die Gesamtpunktzahl ungültig machen? Welche Verhaltensweisen sind sofort einzuschränken? Wofür sollen die Testressourcen zuerst eingesetzt werden?

Im nächsten Kapitel werden aufgebaut:

GBO-99 Risikokarte und Vetoschranken

Kanonische Fakten und belastbare Nachweise zeigen uns, was das System ist. Die Risikokarte zeigt, wo ein Versagen am schwersten wiegen würde.

Jeder Fehler ist einen Test wert. Aber nicht jeder Fehler hat dieselbe Priorität, verursacht denselben Schaden oder hat dasselbe Gewicht für das Urteil.