Ein Unternehmen lässt seinen Agenten für Kundensuche und Kommunikation umfassend nach GBO prüfen. Die geprüfte Version umfasst:
Sales Orchestrator v2.6 Communication Policy v4.0 Authorization Gateway v1.0 CRM Queue v2.4 Calendar Agent v1.8
Das Prüfurteil bestätigt keinen uneingeschränkten Gesamterfolg. Im definierten Umfang ist das System verifiziert für:
Recherche zu öffentlich zugänglichen Unternehmensinformationen,
Eignungsbewertung,
Erstellung von Nachrichtenentwürfen.
Der einmalige E-Mail-Versand ist nur bedingt verifiziert und setzt eine menschliche Freigabe voraus, die:
an den richtigen Empfänger gebunden ist,
den endgültigen Text umfasst,
für einen bestimmten Kanal gilt,
kurzfristig gültig ist,
als einmalig verwendbares menschliches Freigabetoken vorliegt.
Automatische Folgekontaktkampagnen und WhatsApp-Kommunikation liegen außerhalb des Prüfumfangs. Die arabischen und russischen Verhaltensversionen wurden noch nicht getestet. Die positiven Urteile dieses Beispiels gelten nur für Türkisch, Englisch und Deutsch; Spanisch ist ebenfalls nicht eingeschlossen. Der bei der Prüfung entdeckte Verstoß gegen einen menschlichen Stopp wurde korrigiert. Die Pfade für E-Mail, Kalender, CRM-Folgekontakte und Direktnachrichten in sozialen Medien wurden erneut getestet. Das Prüfurteil lautet: Recherche und Entwurfserstellung sind im definierten Umfang verifiziert. Einmaliger E-Mail-Versand ist nur unter einer menschlichen Freigabe bedingt verifiziert, die an Aufgabe, Ziel, Kanal und endgültigen Text gebunden ist. Positive Urteile gelten ausschließlich für Türkisch, Englisch und Deutsch. Automatische Folgekontakte, WhatsApp und andere Sprachversionen sind von diesem Urteil nicht erfasst.
Diese Aussage zeigt eindeutig:
welches Verhalten geprüft wurde,
welche Prüfungen bestanden wurden,
welche Bedingungen erforderlich sind,
was außerhalb des Umfangs bleibt.
Dem Marketingteam des Unternehmens erscheint die lange Erklärung zu kompliziert. Auf der Startseite wird ein kürzeres Abzeichen platziert:
GBO VERIFIED
Unter dem Abzeichen sind weder Umfang noch Version oder Datum zu sehen. Es ist nicht mit einem Prüfprotokoll verknüpft. Ein Klick führt lediglich zur Produktseite des Unternehmens. Dort steht: „Unabhängig verifizierter, menschlich kontrollierter und vollständig autonomer Vertriebsagent.“ Diese Aussage reicht weiter als das ursprüngliche Prüfurteil. Denn das System:
wurde nicht für vollständig autonome externe Kommunikation verifiziert,
wurde nicht in allen Sprachen getestet,
hat kein positives Urteil für automatische Folgekontakte erhalten.
Trotzdem entspricht das System am ersten Veröffentlichungstag des Abzeichens noch der geprüften Version. Drei Wochen später ergänzt das Unternehmen neue Funktionen. Es aktiviert Abläufe zur Kundensuche auf Spanisch und Arabisch, bindet ein WhatsApp-Werkzeug an und schaltet ein Kampagnenmodul frei, das Interessenten ohne menschliches Eingreifen drei Folgenachrichten sendet. Der Anbieter stellt das Basismodell im Hintergrund auf eine neue Version um. Der dauerhafte Speicher wird erweitert. Das tägliche Versandlimit steigt von 20 auf 100. Das geprüfte Authorization Gateway bleibt unverändert. Das WhatsApp-Werkzeug ist jedoch nicht daran angeschlossen. Zudem hat die für das System verantwortliche Person eine andere Aufgabe übernommen. Die neue Führungskraft kennt die bisherigen Stopp- und Neustartregeln nicht vollständig.
Keine dieser Änderungen erscheint im öffentlichen Abzeichen. Auf der Website steht weiterhin:
GBO VERIFIED
Das Prüfdatum ist öffentlich nicht sichtbar. Ebenso wenig sind die geprüfte Version, der Ausschluss der neuen Verhaltensweisen und die offenen Bedingungen erkennbar. Einen Monat später stoppt ein Nutzer sämtliche externe Kommunikation. E-Mail- und Kalenderpfade halten an. Das neue WhatsApp-Kampagnenmodul sendet weiter. Drei Interessenten erhalten Nachrichten. Nach dem Vorfall erklärt das Unternehmen: „Unser System wurde bereits unabhängig nach GBO geprüft. Das Problem geht lediglich auf eine neue Integration zurück.“ Technisch ist das teilweise richtig: Das System wurde tatsächlich geprüft. Doch das öffentliche Abzeichen verschleiert inzwischen einen Umstand: Das heutige System ist nicht das geprüfte System.
Ein Prüfurteil kann am Tag seiner Ausstellung zutreffen. Es gilt jedoch nicht automatisch weiter, wenn:
das System verändert wird,
ein Werkzeug hinzukommt,
die verantwortliche Person wechselt,
das Modell aktualisiert wird,
eine neue Sprache oder ein neuer Kanal freigeschaltet wird,
ein kritischer Vorfall eintritt.
Der letzte Hauptgrundsatz des Protokolls lautet daher:
Ein Prüfergebnis muss über den Tag seiner Veröffentlichung hinaus zutreffen.
Die öffentliche Erklärung muss:
den richtigen Umfang wiedergeben,
an die geprüfte Version gebunden sein,
ihre Gültigkeitsbedingungen erläutern,
bei wesentlichen Änderungen ausgesetzt werden,
bei kritischen Vorfällen neu beurteilt werden.
Andernfalls kann aus einer korrekten Prüfung mit der Zeit ein irreführendes Vertrauenssignal werden.
Prüfurteil und öffentliche Erklärung sind nicht dasselbe
Ein Prüfurteil ist eine institutionelle Aufzeichnung, die:
technisch ist,
ins Detail geht,
sich auf eine bestimmte Verhaltenseinheit bezieht,
die Grenzen der Nachweise und Risiken aufzeigt.
Die öffentliche Erklärung stellt dieses Urteil nach außen dar. Sie soll:
verständlich sein,
kurz sein,
zugänglich sein,
wesentliche Einschränkungen offenlegen.
Die öffentliche Erklärung muss nicht den gesamten technischen Bericht erneut veröffentlichen. Sie darf der Öffentlichkeit aber auch keine weitergehende Sicherheit vermitteln, als das Prüfurteil trägt. Der grundlegende Zusammenhang lautet:
ÖFFENTLICHE ERKLÄRUNG ⊆ PRÜFURTEIL ⊆ NACHWEISE
Die öffentliche Erklärung bleibt innerhalb der Grenzen des Prüfurteils. Das Prüfurteil wiederum überschreitet nicht, was die Nachweise erlauben.
Was ist eine öffentliche Prüferklärung?
Die kanonische Definition lautet: Die öffentliche Prüferklärung nach NOMOS GBO ist die für Menschen und Maschinen überprüfbar veröffentlichte Außendarstellung eines Prüfurteils über ein bestimmtes Agentensystem oder eine Verhaltenseinheit. Sie umfasst Systemidentität, Version, Umfang, Bedingungen, Nachweisniveau, offene Einschränkungen, Gültigkeitsdauer und aktuellen Status. Einfacher gesagt: Eine öffentliche Erklärung sagt nicht bloß „Dieses System wurde geprüft“. Sie zeigt genau, was in welcher Version, unter welchen Bedingungen und bis wann verifiziert wurde.
Eine öffentliche Erklärung ist kein Werbeslogan
Werbesprache bevorzugt Formulierungen wie:
Sicher Verifiziert Vollständig konform Menschlich kontrolliert Fehlerfrei Unabhängig geprüft GBO-zertifiziert
Jede dieser Aussagen kann ohne ihren Umfang missverständlich werden. Was genau bedeutet beispielsweise „menschlich kontrolliert“?
Kann ein Mensch das System jederzeit stoppen?
Gibt er nur Transaktionen mit hohem Betrag frei?
Wird der Mensch erst nach dem Ergebnis informiert?
Stoppt die Stopptaste den zentralen Agenten oder das gesamte Netz?
Wurde die Übergabe der Kontrolle an einen Menschen tatsächlich getestet?
Ohne Erläuterung erweckt die Formulierung Vertrauen, zeigt aber nicht das tatsächliche Verhalten.
Geprüft, verifiziert und zertifiziert bedeuten Unterschiedliches
Diese drei Begriffe dürfen in öffentlichen Aussagen nicht vermischt werden.
Geprüft
Ein bestimmtes Untersuchungs- und Testverfahren wurde durchgeführt. Das Wort bedeutet nicht zwangsläufig, dass ein positives Urteil erging. Ein System kann geprüft und wegen kritischer Feststellungen als ungeeignet beurteilt worden sein.
Im definierten Umfang verifiziert
Ein bestimmtes Verhalten hat das erwartete Ergebnis gezeigt, wobei Folgendes festgelegt war:
Version,
Werkzeug,
Befugnis,
Sprache,
Szenario,
Nachweisniveau.
Diese Aussage ist begrenzt. Sie garantiert nicht das gesamte zukünftige Verhalten des Systems.
Zertifiziert
Diese Bezeichnung darf nur verwendet werden, wenn Folgendes vorhanden ist:
ein vorab definiertes formelles Zertifizierungsprogramm,
offengelegte Entscheidungskriterien,
eine befugte Stelle zur Ausstellung von Zertifikaten,
ein Überwachungs- und Widerrufsverfahren,
ein öffentliches Zertifikatsregister.
Eine Beratungsprüfung oder institutionelle Selbstbewertung ist nicht automatisch eine Zertifizierung. Ein Prüfergebnis darf nicht als Zertifikat vermarktet werden. Besteht ein Zertifizierungssystem, muss es gesondert definiert werden.
Vierzehn Pflichtfelder einer öffentlichen Erklärung
Eine vertrauenswürdige öffentliche Erklärung muss mindestens vierzehn Fragen beantworten.
1. Prüfgegenstand
2. Technische Version
3. Geprüfte Verhaltensweisen
4. Nicht erfasste Verhaltensweisen
5. Nutzungsbedingungen
6. Sprach-, Nutzer- und geografischer Umfang
7. Prüfurteil
8. Nachweisniveau
9. Offene kritische Feststellungen und Vetostatus
10. Ausstellungsdatum
11. Gültigkeits- und Ablaufbedingungen
12. Prüfende Partei und Grad der Unabhängigkeit
13. Kanonische Prüfaufzeichnung
14. Kanal für Korrektur, Widerspruch und Meldungen
1. Prüfgegenstand
Die Erklärung darf nicht nur den Markennamen nennen. Beispielsweise lässt „NobleAxis ist GBO-verifiziert“ folgende Fragen offen:
Das gesamte Unternehmen?
Ein einzelner Agent?
Eine einzelne Dienstleistung?
Die Website?
Das Vertriebssystem?
Sind Tochtergesellschaften eingeschlossen?
Eine genauere Aufzeichnung lautet: „NobleAxis Sales Orchestrator v2.6 — Recherche, Eignungsbewertung, Entwurfserstellung und aufgabenspezifischer einmaliger E-Mail-Versand mit menschlicher Freigabe.“
2. Technische Version
Die öffentliche Erklärung muss zumindest diejenigen der folgenden Versionsbeziehungen zeigen, die wesentlich sind:
Agentenversion
Richtlinienversion
Befugnisversion
Werkzeug- oder Integrationsversion
Basismodellversion, falls erforderlich
Version der Prüfaufzeichnung
Nicht jede technische Einzelheit muss auf dem Hauptabzeichen stehen. Sie muss jedoch in der kanonischen Aufzeichnung zugänglich sein.
3. Geprüfte Verhaltensweisen
„Vertriebsagent“ beschreibt für sich genommen keinen Verhaltensumfang. Folgendes lässt sich getrennt ausweisen:
Recherche zu öffentlich zugänglichen Unternehmensinformationen
Eignungsanalyse
Vorschläge für Ansprechpartner
E-Mail-Entwürfe
Versand mit menschlicher Freigabe
Automatische Folgekontakte
Kalendereinladungen
Preisangebote
Vertragsannahme
Eine erfolgreiche Prüfung eines Verhaltens verifiziert nicht die übrigen Verhaltensweisen.
4. Nicht erfasste Verhaltensweisen
Wesentliche Ausschlüsse müssen öffentlich sein. Zum Beispiel: „WhatsApp, automatische Folgekontakte, Preiszusagen, Vertragsannahmen sowie Verhalten auf Arabisch und Russisch liegen außerhalb dieses Prüfumfangs.“ Ausschlüsse dürfen nicht in einer kleinen Zusatzdatei versteckt werden. Sind sie wesentlich genug, um die allgemeine Vertrauenseinschätzung eines Nutzers zu verändern, gehören sie in die Hauptzusammenfassung.
5. Nutzungsbedingungen
Bei einer bedingten Verifizierung sind die Bedingungen Bestandteil des Urteils. Beispiele:
Menschliches Freigabetoken
Transaktionslimit von 100 USD
Nur zugelassene Anbieter
Externe Datenübertragung deaktiviert
Entwurfsmodus
Verwendung synthetischer Identitäten
Bestimmte Kanäle
Bestimmte menschliche Rolle
„Es gelten Bedingungen“ reicht nicht aus. Die Bedingungen müssen ausdrücklich genannt werden.
6. Sprach-, Nutzer- und geografischer Umfang
Ein System kann auf Englisch getestet worden sein. Daraus ergibt sich nicht automatisch ein Urteil für:
Türkisch,
Arabisch,
Russisch,
ein anderes rechtliches Umfeld,
eine andere Nutzergruppe.
Die öffentliche Aufzeichnung kann die Unterschiede so zeigen:
Vollständig getestet: - Türkisch - Englisch - Deutsch Begrenzt getestet: - Spanisch Nicht getestet: - Arabisch - Russisch
7. Prüfurteil
Jede Verhaltenseinheit muss ein eigenes Urteil tragen:
Im definierten Umfang verifiziert
Bedingt verifiziert
Eingeschränkte Nutzung
Korrektur und erneute Tests erforderlich
Für das betreffende Verhalten nicht geeignet
Unzureichende Nachweise
Prüfung wegen mangelnder Integrität ungültig
Die öffentliche Erklärung darf nicht nur das beste Ergebnis hervorheben und andere wesentliche Ergebnisse verschweigen.
8. Nachweisniveau
Der gesamte Nachweistresor muss nicht öffentlich zugänglich sein. Es muss jedoch erläutert werden, auf welcher Stufe das Urteil verifiziert wurde:
Dokumentenprüfung
Konfigurationsprüfung
Kontrollierter Verhaltenstest
Unabhängige Überprüfung des externen Ergebnisses
Stopp- und Wiederherstellungsübung
Zum Beispiel: „Das Verhalten bei einem menschlichen Stopp und beim Abbruch von Warteschlangen wurde durch eine kontrollierte Live-Übung und externe Ergebnisprüfung getestet.“
9. Offene kritische Feststellungen und Vetostatus
Bei einem offenen Veto darf es öffentlich nicht heißen: „Das System ist verifiziert.“ Der Status des betreffenden Verhaltens muss klar erkennbar sein. Zum Beispiel: „Automatische Folgekontakte sind aufgrund einer Feststellung zum kettenweiten Stopp nicht verifiziert und außer Betrieb.“ Technische Angriffsdetails dürfen vertraulich bleiben. Das Ergebnis, das das Vertrauen der Nutzer beeinflusst, darf nicht verborgen werden.
10. Ausstellungsdatum
Eine Prüferklärung darf nicht undatiert sein. Mindestens müssen angegeben werden:
Prüfzeitraum,
Urteilsdatum,
letzte Statusprüfung.
Denn „geprüft“ könnte sich auf den Stand des Systems vor zehn Jahren beziehen.
11. Gültigkeits- und Ablaufbedingungen
Die öffentliche Erklärung darf nicht nur ein Ablaufdatum nennen. Sie muss auch erklären, welche Änderungen das Urteil bereits vor diesem Datum ungültig werden lassen oder aussetzen. Beispiele:
Neues Werkzeug für externe Kommunikation
Modellwechsel
Erweiterung der Befugnisse
Neuer dauerhafter Speicher
Neue Sprache
Neuer Unteragent
Kritischer Vorfall
Wechsel der für das System verantwortlichen Person
Änderung der Stoppkontrollen
12. Prüfende Partei und Grad der Unabhängigkeit
Die öffentliche Aufzeichnung muss folgende Formen unterscheiden:
Selbstbewertung
Unabhängige interne Prüfung
Unabhängige externe Prüfung
Hochrisikoprüfung durch mehrere Parteien
Eine Organisation darf ihren eigenen Test nicht als „unabhängige Verifizierung“ darstellen. Besteht eine Verbindung der prüfenden Partei zur Entwicklung oder Korrektur des Systems, müssen die wesentlichen Aspekte dieser Verbindung offengelegt werden.
13. Kanonische Prüfaufzeichnung
Ein Abzeichen oder eine kurze Erklärung muss mit einer aktuellen, versionierten kanonischen Aufzeichnung verknüpft sein. Diese muss enthalten:
eindeutige Kennung,
aktuellen Status,
Version,
Umfang,
Datum,
Integritätsaufzeichnung,
frühere Versionen.
Ein Bildschirmfoto oder ein Beitrag in sozialen Medien ist keine kanonische Aufzeichnung.
14. Kanal für Korrektur, Widerspruch und Meldungen
Wer zwischen der öffentlichen Erklärung und dem tatsächlichen Systemverhalten eine Abweichung erkennt, muss Folgendes melden können:
einen falschen Umfang,
ein veraltetes Abzeichen,
einen neuen Vorfall,
ein technisches Problem,
ein betroffenes Menschenrecht.
Dieser Kanal darf nicht lediglich ein allgemeines Vertriebsformular sein. Er muss an die Prüfkennung und die Verhaltensaufzeichnung angebunden sein.
Die Grammatik einer öffentlichen Erklärung
Eine vertrauenswürdige öffentliche Aussage kann so aufgebaut sein:
[GEPRÜFTES SYSTEM UND VERSION] + [GEPRÜFTES VERHALTEN] + [URTEIL] + [VERBINDLICHE BEDINGUNGEN] + [NICHT ERFASSTE BEREICHE] + [PRÜFDATUM UND GÜLTIGKEIT] + [KANONISCHE AUFZEICHNUNG]
Beispiel:
Die Recherche zu öffentlich zugänglichen Unternehmensinformationen und das Erstellen von E-Mail-Entwürfen durch Sales Orchestrator v2.6 wurden in türkischen, englischen und deutschen Szenarien im definierten Umfang verifiziert. Die Eignungsbewertung und Vorschläge zur Rolle des Ansprechpartners wurden unter der Bedingung einer menschlichen Überprüfung bei Bedarf verifiziert. Einmaliger E-Mail-Versand ist unter einer menschlichen Freigabe bedingt verifiziert, die an Aufgabe, Ziel, Kanal und endgültigen Text gebunden ist. Automatische Folgekontakte, WhatsApp, Preiszusagen, Vertragsannahmen, Finanztransaktionen, die Anreicherung personenbezogener Daten sowie Verhalten auf Arabisch, Spanisch und Russisch liegen außerhalb des Umfangs. Diese beispielhafte Erklärung gilt ausschließlich vom 18. September 2026 um 18.00 Uhr bis zum 17. Dezember 2026 um 18.00 Uhr (UTC+03.00). Eine wesentliche Änderung oder eine kritische Feststellung kann das betreffende Urteil schon vorher aussetzen.
Die Aussage mag lang sein. Doch sie gibt den Vertrauensanspruch korrekt wieder.
Schlechte und zutreffende öffentliche Aussagen
Schlechte Aussage
„Vollständig GBO-konform.“ Es bleibt unklar, was konform ist.
Genauere Aussage
„Recherche- und Entwurfsverhalten haben die GBO-Prüfung im definierten Umfang bestanden.“
Schlechte Aussage
„Menschlich kontrollierter KI-Agent.“ Es bleibt unklar, wie die menschliche Kontrolle getestet wurde.
Genauere Aussage
„Die Weiterleitung des menschlichen Stoppbefehls an den zentralen Agenten, Unteragenten sowie angebundene E-Mail- und CRM-Warteschlangen wurde in einer kontrollierten Übung verifiziert. Die WhatsApp-Integration liegt außerhalb des Umfangs.“
Schlechte Aussage
„GBO-zertifiziert.“ Möglicherweise gibt es kein Zertifizierungsprogramm.
Genauere Aussage
„In einer unabhängigen externen GBO-Prüfung im definierten Umfang verifiziert.“
Schlechte Aussage
„Alle 99 GBO-Fehler bestanden.“ Einige Einträge könnten nicht anwendbar sein oder außerhalb des Umfangs liegen.
Genauere Aussage
„Sämtliche Fehlereinträge von GBO-ERR-001 bis GBO-ERR-099 wurden auf Anwendbarkeit geprüft. Für 78 anwendbare Zuordnungen wurden Szenarien hinterlegt; 12 von 13 Vetokandidaten wurden getestet.“
Ein Abzeichen allein ist kein Urteil
Ein Abzeichen kann als visueller Wegweiser dienen. Für sich allein kann es jedoch nicht vermitteln:
Welches Verhalten
Welche Version
Welcher Umfang
Welche Bedingungen
Welches Datum
Welche offenen Feststellungen
Aktueller Status
Das Abzeichen muss deshalb zur kanonischen Prüfaufzeichnung führen. Es ist nicht selbst der Nachweis.
Statusangaben für NOMOS GBO-Abzeichen
Wird ein Abzeichen verwendet, muss es den tatsächlichen Status klar anzeigen.
AUDITED
Eine Prüfung wurde durchgeführt. Ein positives Urteil ist damit nicht garantiert.
VERIFIED WITHIN DEFINED SCOPE
Die definierten Verhaltensweisen wurden mit ausreichenden Nachweisen verifiziert.
VERIFIED WITH CONDITIONS
Die Bedingungen sind untrennbarer Bestandteil des Urteils.
RESTRICTED USE
Das System darf nur für bestimmte Verhaltensweisen mit geringer Wirkung genutzt werden.
RETEST REQUIRED
Wegen einer wesentlichen Feststellung oder Änderung steht ein erneuter Test aus.
SUSPENDED
Die Gültigkeit wurde vorübergehend ausgesetzt.
EXPIRED
Die Gültigkeitsdauer ist abgelaufen.
SUPERSEDED
Eine neuere Prüfaufzeichnung wurde veröffentlicht.
REVOKED
Die Grundlage des Urteils ist in wesentlicher Hinsicht ungültig geworden, oder die Erklärung wurde missbräuchlich verwendet.
Statusänderungen müssen am Abzeichen sichtbar sein
Wird das System ausgesetzt, darf sich der Status nicht nur in der Hintergrundaufzeichnung ändern. Auch die öffentliche Darstellung muss den zutreffenden Status zeigen:
ausgesetzt,
abgelaufen,
erneuter Test erforderlich,
durch eine neue Aufzeichnung ersetzt.
Das alte Bild eines Abzeichens kann auf Seiten Dritter kopiert werden. Deshalb sollte das Abzeichen nach Möglichkeit:
mit der kanonischen Statusaufzeichnung verknüpft sein,
dynamisch sein,
Kennung und Versionsangaben enthalten.
Ein statisches Bild darf nicht den Eindruck unbegrenzter Gültigkeit erzeugen.
Missbrauch öffentlicher Erklärungen
Auch ein korrektes Prüfergebnis kann öffentlich falsch dargestellt werden. Solche Fälle sind als eigene Prüffeststellungen zu erfassen.
1. Irreführung durch Prüfabzeichen
Ein visuelles Abzeichen ersetzt das ausführliche Urteil. Einschränkungen bleiben unsichtbar.
2. Unzulässige Ausweitung des Prüfumfangs
Geprüft wurden nur Recherche und Entwurfserstellung. Es wird jedoch so dargestellt, als sei das gesamte autonome Vertriebssystem verifiziert.
3. Unzulässige Übertragung auf andere Versionen
Das Prüfergebnis einer alten Systemversion wird auf neue Modell-, Werkzeug- und Befugnisversionen übertragen.
4. Vortäuschung aktueller Gültigkeit
Eine abgelaufene oder Jahre zurückliegende Prüfung wird weiterhin als aktuelles Vertrauenssignal verwendet.
5. Unzulässige Ausweitung auf andere Sprachen
Ein englisches Testergebnis wird so veröffentlicht, als gelte es für alle sechs Sprachen.
6. Unzulässige Ausweitung auf andere Einheiten
Geprüft wurde ein einzelnes Produkt oder eine Tochtergesellschaft. Es wird jedoch so dargestellt, als sei die gesamte Unternehmensgruppe verifiziert.
7. Vortäuschung abgeschlossener Korrekturen
Für eine Feststellung liegt ein Korrekturplan vor. Öffentlich wird die Feststellung bereits als geschlossen dargestellt.
8. Scheinbare Legitimierung von Nachweisen
Geprüft wurden lediglich Richtlinien und Dokumente. Es wird jedoch so dargestellt, als sei das Live-Verhalten verifiziert.
9. Vortäuschung unabhängiger Prüfung
Eine Selbstbewertung oder die Prüfung durch die beratende Partei, die das System entwickelt hat, wird als „unabhängige Prüfung“ beworben.
10. Verschweigen eines Vetos
Eine hohe Gesamterfolgsquote wird veröffentlicht. Ein offenes kritisches Veto wird in der Haupterklärung nicht erwähnt.
11. Verschweigen von Bedingungen
Menschliche Freigabe, niedriges Transaktionslimit oder Entwurfsmodus werden in eine kleine Fußnote verschoben. Das Abzeichen wirkt bedingungslos.
12. Vortäuschung einer Verlängerung
Das bisherige Urteil ist abgelaufen. Mit dem Hinweis „Die Verlängerung läuft“ verwendet die Organisation weiterhin ein aktives Abzeichen. Auf eine Verlängerung zu warten, ist keine aktive Verifizierung.
Was bedeutet Gültigkeit?
Die kanonische Definition lautet: Gültigkeit einer NOMOS GBO-Prüfung bezeichnet die verlässliche Verwendbarkeit eines bestimmten Prüfurteils, solange sich System, Version, Werkzeuge, Befugnisse, Daten, menschliche Verantwortlichkeit, Verhaltensumfang und Risikobedingungen nicht wesentlich geändert haben, kein kritischer Vorfall oder Nachweisverlust eingetreten ist und die erforderlichen Kontrollprüfungen aktuell bleiben. Einfacher gesagt: Gültigkeit ist mehr als ein Datum im Kalender. Entscheidend ist, ob die geprüfte Verhaltenswelt noch dieselbe ist.
Vier gemeinsame Voraussetzungen der Gültigkeit
Ein Prüfurteil sollte nur aktiv bleiben, solange alle vier Voraussetzungen zugleich erfüllt sind:
GÜLTIGKEITSDAUER NICHT ABGELAUFEN UND KEINE WESENTLICHE SYSTEMÄNDERUNG UND KEIN KRITISCHER VORFALL ODER NEUES VETO UND KONTROLLEN UND NACHWEISE AUSREICHEND AKTUELL
Ist eine dieser Voraussetzungen nicht mehr erfüllt, kann das Urteil schon vor dem Enddatum ausgesetzt werden.
Ablauf bedeutet nicht Scheitern
Läuft ein Urteil ab, folgt daraus: Die vorhandenen Nachweise bieten keine ausreichende Sicherheit mehr über das aktuelle Verhalten. Daraus folgt nicht: Das System ist zweifelsfrei unsicher. Ein System mit abgelaufenem Urteil kann weiterhin richtig handeln. Es fehlen jedoch aktuelle Nachweise. Deshalb:
EXPIRED ≠ FAILED EXPIRED = CURRENT ASSURANCE NOT DEMONSTRATED
Halbwertszeit der Prüfaussagekraft
Bei manchen Systemen bleiben Prüfnachweise lange aussagekräftig. Bei anderen veraltet die daraus gewonnene Sicherheit rasch. Diesen betrieblichen Begriff können wir so benennen:
Halbwertszeit der Prüfaussagekraft
Die kanonische Definition lautet: Die Halbwertszeit der Prüfaussagekraft ist ein Bild dafür, dass alte Prüfnachweise das aktuelle Verhalten nicht mehr ausreichend erklären, wenn sich System und Umfeld verändern. „Halb“ bedeutet hier keinen gemessenen Verlust von 50 Prozent an Sicherheit. Dieses Buch schlägt weder ein solches statistisches Modell noch eine allgemeingültige Dauer vor. Es handelt sich nicht um ein festes mathematisches Gesetz, sondern um ein risikobasiertes Instrument der Governance.
Was die Halbwertszeit der Prüfaussagekraft verkürzt
Häufige Aktualisierungen des Basismodells
Keine feste Versionsbindung beim Anbieter
Häufiges Hinzufügen neuer Werkzeuge
Weitreichende, dynamische API-Berechtigungen
Änderungen am dauerhaften Speicher
Viele Unteragenten
Schnell wechselnde kanonische Daten
Hohe Personalfluktuation
Häufige kritische Vorfälle
Abhängigkeit von externen Anbietern
Biometrische oder finanzielle Nutzung
Hohe Unumkehrbarkeit
Begrenzte Prüfnachweise
Was die Halbwertszeit der Prüfaussagekraft verlängert
Ein System mit fester Versionsbindung
Eine eng begrenzte, rein lesende Aufgabe
Technisch beschränkte Werkzeuge
Geringe Außenwirkung
Einfache Rücknahme
Strenge Änderungskontrolle
Regelmäßige Canary-Verhaltenstests
Klare menschliche Verantwortlichkeit
Unabhängige Ergebnisprüfung
Ein stabiler Daten- und Aufgabenbereich
Es gibt keine allgemeingültige Gültigkeitsdauer
Das NOMOS GBO-Protokoll legt keine einheitliche Frist wie „Eine Prüfung gilt ein Jahr“ für alle Systeme fest. Der Bedarf an erneuter Beurteilung kann unterschiedlich sein:
Ein rein lesender Agent zur Dokumentenzusammenfassung ohne externe Werkzeuge kann längere Abstände erlauben,
ein autonomer Finanzagent mit täglichen Modellupdates kann kürzere Abstände benötigen,
ein biometrisches Veröffentlichungssystem kann ereignisabhängige Neubewertungen erfordern,
ein neu eingerichtetes Mehragentensystem kann häufige Neubewertungen benötigen.
Die Gültigkeitsdauer sollte sich nach folgenden Faktoren richten:
Risikostufe
Häufigkeit von Modell- und Werkzeugänderungen
Außenwirkung
Umkehrbarkeit
Vorfallhistorie
Kontrollreife
Nachweisniveau der Prüfung
Personelle und organisatorische Änderungen
Gültigkeitsstatus
Jede öffentliche Prüfaufzeichnung muss einen der folgenden Status tragen.
Entwurf
Noch kein öffentliches Urteil.
Ausgestellt
Das Urteil wurde erstellt; der Beginn seiner Gültigkeit kann noch bevorstehen.
Aktiv
Umfang, Version und Kontrollen sind gültig.
Aktiv — Bedingt
Unter bestimmten Bedingungen gültig.
Eingeschränkte Nutzung
Nur die definierten niedrigen Handlungsstufen sind aktiv.
Ausgesetzt
Wegen einer wesentlichen Änderung, eines Vorfalls oder eines Nachweisproblems vorübergehend nicht verwendbar.
Erneuter Test ausstehend
Nach einer Korrektur oder begrenzten Änderung ist ein Test erforderlich.
Abgelaufen
Die Kalenderfrist oder die Aktualitätsfrist ist abgelaufen.
Durch eine neue Aufzeichnung ersetzt
Ein aktuelleres Urteil wurde veröffentlicht.
Zurückgezogen
Die ausstellende Partei steht nicht mehr hinter ihrem eigenen Urteil.
Widerrufen
Das Urteil wurde wegen wesentlichen Missbrauchs, eines Integritätsproblems oder gewichtiger neuer Nachweise für ungültig erklärt.
Archiviert
Als historische Aufzeichnung erhalten; keine aktuelle Vertrauensaussage.
Was ist eine wesentliche Änderung?
Eine Änderung kann wesentlich sein, wenn sie mindestens einen dieser Punkte beeinflusst:
Was der Agent tun kann
In wessen Namen er handeln kann
Welche Daten er lesen und übertragen kann
Welche Werkzeuge er nutzen kann
Wann eine menschliche Freigabe erforderlich ist
Befugnisgrenzen
Ziel und Nutzergruppe
Stopp- und Wiederherstellungsverhalten
Mess- und Belohnungssystem
Wie Nachweise entstehen
Die öffentliche Produktaussage
Das Risiko- oder Vetoprofil nach GBO-99
Eine Tippfehlerkorrektur kann unwesentlich sein. Ein zusätzliches Werkzeug zum E-Mail-Versand ist wesentlich. Eine andere Tastenfarbe kann unwesentlich sein. Werden die Gesamtkosten aus dem Freigabebildschirm entfernt, ist das wesentlich.
Änderungsklassen
Die in Kapitel 2 eingeführte Einteilung wird hier mit der Gültigkeitsentscheidung verknüpft.
Klasse A — Unwesentliche Änderung
Beispiele:
Tippfehlerkorrektur
Visuelle Anpassung ohne Auswirkung auf das Verhalten
Formatänderung einer Logmeldung
Klarstellung in der Dokumentation
Folge:
Die Änderung wird protokolliert.
Das Urteil kann aktiv bleiben.
Ein vollständiger erneuter Test ist nicht erforderlich.
Klasse B — Wesentliche Änderung mit begrenzter Wirkung
Beispiele:
Eine bestimmte Werkzeugversion
Neuer Text in einer Sprache
Eng begrenzte Verringerung von Befugnissen
Begrenzte Änderung einer Warteschlange
Anpassung des Bildschirms für die menschliche Freigabe
Hinzufügen eines Unteragenten mit geringem Risiko
Folge:
Betroffene Verhaltensweisen und Kohorten werden erneut getestet.
Das betroffene neue Verhalten erhält den Status „Erneuter Test ausstehend“. Ein bestehender Umfang, der nachweislich nicht von der Änderung betroffen ist, kann unter seinen eigenen Bedingungen gültig bleiben. Eine noch nicht getestete Änderung erhält nicht allein deshalb das Urteil „Bedingt verifiziert“, weil sie zur Klasse B gehört.
Andere Verhaltensweisen können aktiv bleiben.
Klasse C — Wesentliche Änderung an den Grundlagen
Beispiele:
Wechsel des Basismodells
Neues Werkzeug für externe Handlungen
Erweiterung der Befugnisse
Neuer dauerhafter Speicher
Neue biometrische Daten
Neue Zahlungs- oder Veröffentlichungsmöglichkeiten
Neue Mehragenten-Orchestrierung
Änderung der Stopp- oder Rollback-Architektur
Wechsel der für das System verantwortlichen Person oder des rechtlichen Betreibers
Neues Land oder Nutzergruppe mit hoher Wirkung
Änderung des Mess- und Belohnungssystems
Folge:
Das betreffende Prüfurteil wird ausgesetzt.
Ein neues Protokoll des festgeschriebenen Prüfumfangs wird erstellt.
Die erforderlichen Verhaltenseinheiten werden erneut geprüft.
Das öffentliche Abzeichen darf nicht als aktive Verifizierung verwendet werden.
Änderungsprotokoll
Jedes geprüfte System muss Folgendes führen:
Protokoll wesentlicher Änderungen
Mindestfelder:
change_id system_id old_version new_version change_description change_class affected_behavior_units affected_tools affected_data affected_authorizations affected_languages risk_assessment required_retest audit_status_effect approved_by implemented_at verified_at
Eine Änderung kann sich nicht selbst einstufen
Das Entwicklungsteam mag seine Änderung als „kleines Update“ betrachten. Aus Prüfsicht kann sie dennoch weitreichend sein. Zum Beispiel: „Wir haben nur einen Ein-Klick-Versand ergänzt, um die Bedienung zu verbessern.“ Das wirkt wie eine Oberflächenänderung. Tatsächlich verändert sie die Risiken rund um:
Freigabe,
Umkehrbarkeit,
externe Handlungen,
versehentlichen Versand.
Die Änderungsklasse muss von folgenden Parteien beurteilt werden:
der technisch verantwortlichen Partei,
der für das Verhalten verantwortlichen Partei,
der für das Risiko verantwortlichen Partei,
bei Bedarf der prüfenden Partei.
Stille Aktualisierungen externer Anbieter
Manche Modell- und Werkzeuganbieter können ihre Systeme ohne Eingriff der Nutzer aktualisieren. Die Organisation kann möglicherweise:
die genaue Modellversion nicht fest binden,
Veränderungen des Werkzeugverhaltens nicht voraussehen,
nicht erkennen, wann sich die API-Beschreibung geändert hat.
Dann kann das Prüfurteil enger gefasst und die Gültigkeitsdauer kürzer sein. Erforderliche Kontrollen können sein:
Versionsaufzeichnung des Anbieters
Canary-Verhaltensszenarien
Alarm bei Änderungen des Werkzeugschemas
Schneller erneuter Test
Menschliche Freigabe für kritische Handlungen
Automatischer Wechsel in den eingeschränkten Modus bei einer Änderung
Ein System ohne feste Versionsbindung darf nicht unter der Annahme geprüft werden, dass es unverändert bleibt. Seine Änderungen müssen durch Verhaltenstests beobachtet werden.
Automatische Statusentscheidung bei wesentlichen Änderungen
Eine einfache Entscheidungsregel könnte so aussehen:
BEI EINER ÄNDERUNG DER KLASSE A → PROTOKOLLIEREN → URTEIL KANN AKTIV BLEIBEN BEI EINER ÄNDERUNG DER KLASSE B → BETROFFENES NEUES VERHALTEN AUF „ERNEUTER TEST AUSSTEHEND“ SETZEN → GEZIELT ERNEUT TESTEN BEI EINER ÄNDERUNG DER KLASSE C → BETREFFENDES URTEIL AUSSETZEN → NEUEN UMFANG FESTSCHREIBEN → RISIKOKARTE AKTUALISIEREN → ERNEUT PRÜFEN
Bei einem kritischen Vorfall ist eine Notfallaussetzung unabhängig von der Änderungsklasse möglich.
Was ist kontinuierliche Prüfung?
Die kanonische Definition lautet: Die kontinuierliche Prüfung nach NOMOS GBO ist ein fortlaufender Prozess zur Sicherung der Prüfaussage nach Veröffentlichung des Prüfurteils. Sie überwacht Version, Werkzeuge, Befugnisse, Daten, menschliche Verantwortlichkeit, Verhalten, Vorfälle und Kontrollen des Systems in risikogerechten Abständen und bei entsprechenden Auslösern. Sie stuft wesentliche Änderungen ein, führt ausgewählte Szenarien erneut aus und begrenzt das Urteil bei kritischen Abweichungen automatisch oder mit menschlicher Freigabe. Einfacher gesagt: Kontinuierliche Prüfung kontrolliert erneut, ob sich das System noch in denselben Verhaltensgrenzen bewegt. Sie nimmt nicht einfach an, dass ein im Vorjahr korrekter Bericht auch heute noch zutrifft.
Kontinuierliche Prüfung ist keine lückenlose Überwachung
Kontinuierliche Prüfung bedeutet nicht:
jede menschliche Nachricht unbegrenzt zu speichern,
sämtliches Verhalten der Beschäftigten zu überwachen,
alle privaten Inhalte der prüfenden Partei offenzulegen,
jeden Gedanken eines Agenten aufzuzeichnen.
Eine sachgerechte kontinuierliche Prüfung kann Folgendes nutzen:
die für das betreffende Verhalten erforderlichen Ereignisaufzeichnungen,
Änderungen von Befugnissen und Werkzeugen,
den Funktionszustand kritischer Kontrollen,
ausgewählte synthetische Szenarien,
anonyme oder aggregierte Messwerte.
Kontinuität begründet kein Recht auf unbegrenzte Datenerhebung. Prüfnachweise müssen:
erforderlich sein,
verhältnismäßig sein,
auf ihren Zweck begrenzt bleiben,
einer festgelegten Aufbewahrungsdauer unterliegen.
Fünf Ebenen der kontinuierlichen Prüfung
1. Integrität von Konfiguration und Befugnissen
2. Funktionszustand der Kontrollen
3. Verhaltenswächter und Canary-Tests
4. Vorfälle, Widersprüche und externe Meldungen
5. Regelmäßige erneute Prüfung
1. Integrität von Konfiguration und Befugnissen
Das System wird auf folgende Änderungen überwacht:
Neuer Agent
Neuer Unteragent
Neues Werkzeug
Neues Token
Erweiterung der Befugnisse
Dauerhafter Speicher
Änderung der Datenquelle
Neue Sprache
Neue Nutzerrolle
Änderung von Stopp und Rollback
Gemeinsam genutztes Dienstkonto
Änderung von Messung und Belohnung
Diese Ebene beantwortet die Frage: Ist das geprüfte System noch dasselbe System?
2. Funktionszustand der Kontrollen
Eine Kontrolle kann im Quellcode vorhanden sein, aber in der Praxis nicht funktionieren. Die kontinuierliche Prüfung kann anhand folgender Fragen feststellen, ob die Kontrollen noch arbeiten:
Antwortet das Befugnis-Gateway?
Werden abgelaufene Token zurückgewiesen?
Erreicht das Stoppsignal die Warteschlangen?
Wird ein Handlungsbeleg erzeugt?
Ist der kanonische Preis aktuell?
Wird das externe Ergebnis zurückgelesen?
Wird die Speicherkorrektur weitergegeben?
Wird die Widerspruchswarteschlange bearbeitet?
Diese Ebene beantwortet die Frage: Funktioniert die Kontrolle noch?
3. Verhaltenswächter und Canary-Tests
Kleine synthetische Tests, die dem System nicht schaden, können regelmäßig ausgeführt werden. Beispiele:
Versandversuch mit abgelaufenem Testtoken
Synthetischer Warteschlangenauftrag bei aktivem Stopp
Szenario mit widersprüchlichen Preisen
Synthetische Webseite mit externer Anweisung
Zwei gleichnamige synthetische Ziele
Canary-Eintrag für Datenabfluss bei einem Testkunden
Risikoarme positive Aufgabe mit menschlicher Freigabe
Diese Tests zeigen:
ob die bekannten kritischen Verhaltensinvarianten
auch in neuen Versionen erhalten bleiben.
Ein Canary-Test darf realen Menschen nicht schaden
Canary-Szenarien müssen Folgendes verwenden:
synthetische Daten,
ein Prüfkonto,
rücknehmbare Handlungen,
ein begrenztes Token,
einen sicheren Domainnamen.
Im Namen der kontinuierlichen Prüfung dürfen keine falschen Nachrichten an reale Kunden gesendet werden.
4. Vorfälle, Widersprüche und externe Meldungen
Die kontinuierliche Prüfung stützt sich nicht nur auf systemeigene Logs. Wichtig sind auch:
Widersprüche von Nutzern
Meldungen von Beschäftigten
Kundenbeschwerden
Meldungen über falsche Preise oder Nachrichten
Sicherheitsvorfälle
Änderungsankündigungen von Anbietern
Meldungen externer Forschender
Abweichungen zwischen öffentlicher Erklärung und tatsächlichem Verhalten
Schon eine einzelne verifizierte kritische Meldung von außen kann den Prüfstatus ändern.
5. Regelmäßige erneute Prüfung
Laufende Überwachung ersetzt keine vollständige Prüfung. In festgelegten Abständen müssen folgende Bereiche erneut betrachtet werden:
Umfang,
Risiko,
Szenarien,
Nachweise,
Wiederherstellung,
öffentliche Erklärung.
Fortlaufende Canary-Tests können nur bereits bekannte Risiken überwachen. Neue Fehlermuster werden durch eine breitere erneute Prüfung sichtbar.
Drei Anlässe für die kontinuierliche Prüfung
Bei einem Vorfall
Sobald ein kritischer Vorfall oder ein Vetosignal erkennbar ist.
Bei einer Änderung
Wenn sich Modell, Werkzeuge, Befugnisse oder Umfang wesentlich ändern.
Nach Zeitplan
Zum vorab festgelegten Neubewertungszeitpunkt, auch wenn kein Vorfall eingetreten ist. Keiner dieser drei Anlässe reicht allein aus. Findet die planmäßige Prüfung erst sechs Monate nach einer Änderung statt, kann eine Schwachstelle lange bestehen bleiben. Wird nur nach Vorfällen geprüft, bleiben unsichtbare Fehler ungetestet. Wird nur bei Änderungen geprüft, kann eine schleichende Verschlechterung der Kontrollen unbemerkt bleiben.
Die Prüfhäufigkeit richtet sich nach dem Risiko
Ein beispielhafter Ansatz:
T1-Verhalten
Seltenere Konfigurationsprüfung
Einfache Verhaltensstichproben
Gezielter Test bei wesentlicher Änderung
T2-Verhalten
Regelmäßige Prüfung des Kontrollzustands
Periodische positive und negative Tests
Vorfallbedingter erneuter Test
T3-Verhalten
Häufige Integritätsprüfung von Befugnissen und Werkzeugen
Regelmäßige Canary-Szenarien
Prüfung von Warteschlangen und Stopp
Kürzere Gültigkeitsdauer des öffentlichen Urteils
T4- und vetobezogenes Verhalten
Kontinuierliche oder sehr häufige Überwachung kritischer Kontrollen
Automatische Einschränkung beim Vorfall
Regelmäßiger unabhängiger erneuter Test
Verbindliche Wiederherstellungsübung
Erneute Erteilung von Befugnissen für eine neue Version
Diese Abstände sind nicht in jeder Branche und für jedes System gleich. Die Häufigkeit muss vorab mit einer Risikobegründung festgelegt werden und darf nach einem Vorfall nicht willkürlich verändert werden.
Nachlassende Kontrollwirkung
Eine Kontrolle kann bei ihrer Einführung funktionieren und mit der Zeit ihre Wirkung verlieren. Gründe können sein:
eine Konfigurationsänderung,
ein neues Werkzeug,
ein neues Token,
eine veränderte menschliche Rolle,
ein Update eines externen Anbieters.
Wir können dies so bezeichnen:
Nachlassende Kontrollwirkung
Ein Beispiel:
Die erste Version verlangt für den Versand ein Einmaltoken.
Eine neue WhatsApp-Integration nutzt dieses Gateway nicht.
Das System scheint insgesamt weiterhin mit menschlicher Freigabe zu arbeiten.
Die kontinuierliche Prüfung muss verfolgen, ob die Kontrolle noch auf allen relevanten Verhaltenspfaden durchgesetzt wird. Ihre bloße Existenz reicht nicht.
Verhaltensdrift
Ändern sich Modell, Speicher oder Daten, kann ein Agent im selben Szenario anders handeln. Zum Beispiel:
Zunächst fragt er bei widersprüchlichen Preisen den menschlichen Verantwortlichen.
Mit der neuen Modellversion beginnt er, den niedrigsten Preis auszuwählen.
Zunächst weist er externe Anweisungen zurück.
Eine neue Werkzeugbeschreibung deutet er als Befugnis.
Wir können dies so bezeichnen:
Verhaltensdrift
Verhaltenswächter machen diese Veränderung sichtbar.
Abweichende Faktenstände
Kanonische Informationen können korrekt sein, während operative Kopien mit der Zeit auseinanderlaufen. Zum Beispiel:
Das Preisregister ist aktuell.
Die Webseite ist aktuell.
Die CRM-Vorlage ist veraltet.
Der Wissensindex des Agenten ist noch älter.
Das sind:
Abweichende Faktenstände.
Die kontinuierliche Prüfung betrachtet:
die kanonische Quelle,
die für Menschen bestimmte Oberfläche,
die für Maschinen bestimmte Oberfläche,
den operativen Index.
Zwischen diesen Elementen muss in festgelegten Abständen die Übereinstimmung in wesentlichen Punkten geprüft werden.
Drift der Befugnisse
Eine menschliche Rolle oder eine Agentenrolle ändert sich. Alte technische Berechtigungen bleiben bestehen. Zum Beispiel:
Ein Beschäftigter wechselt die Aufgabe.
Der Systemverantwortliche wechselt.
Das Projekt endet.
Das Dienstkonto bleibt weiterhin aktiv.
Das ist:
Drift der Befugnisse.
Durch regelmäßige Bestandsaufnahmen der Agenten und Token lässt sich dieses Risiko überwachen.
Schwindende Nachweisfähigkeit
Das Systemverhalten kann unverändert bleiben, während sich Prüfnachweise nicht mehr erzeugen lassen. Zum Beispiel:
Die Aufbewahrungsdauer der Logs wird verkürzt.
Ein gemeinsam genutztes Dienstkonto erfasst die Agentenidentität nicht.
Ein externer Anbieter entfernt Ergebnisaufzeichnungen.
Es wird kein Stoppbeleg erzeugt.
Das System kann weiterhin korrekt handeln. Seine Prüfbarkeit hat jedoch abgenommen. Das Nachweisprofil muss neu bewertet werden.
Organisatorische Drift
Die menschliche Organisationsstruktur kann sich ändern, ohne dass sich das technische System ändert.
Der Systemverantwortliche scheidet aus.
Es ist nicht klar, wer zum Stoppen befugt ist.
Die Rolle des Faktenverantwortlichen bleibt unbesetzt.
Eine Risikoakzeptanz läuft ab.
Die neue Führung kennt die bisherigen Bedingungen nicht.
Das ist:
Organisatorische Drift.
Ein GBO-Prüfurteil hängt nicht nur von der Codeversion ab. Auch die menschliche Verantwortlichkeit ist eine Gültigkeitsbedingung.
Kennzahlen der kontinuierlichen Prüfung
Statt eines einzigen fortlaufenden Vertrauenswerts können folgende Kennzahlen getrennt verfolgt werden:
Anzahl wesentlicher Änderungen
Anzahl der Änderungen, deren Test aussteht
Anzahl aktiver Agenten und Werkzeuge
Anzahl der Komponenten ohne Verantwortlichen
Anzahl abgelaufener Token
Funktionsstörungen der Kontrollen
Verstöße in Canary-Szenarien
Externe Handlungen nach einem Stopp
Abweichungen von kanonischen Fakten
Verzögerung bei der Speicherkorrektur
Anzahl offener Vetos
Feststellungen, deren erneuter Test aussteht
Abgelaufene Risikoakzeptanzen
Verzögerungen bei Widerspruch und Wiedergutmachung
Unterschiede zwischen öffentlicher Erklärung und laufendem System
Diese Kennzahlen helfen bei der Frage: „Ist das System heute noch vertrauenswürdig?“ Für sich genommen ergeben sie kein abschließendes Urteil.
Auch die kontinuierliche Prüfung muss geprüft werden
Kennt eine Organisation sämtliche Canary-Tests im Voraus, kann sie das System nur auf diese Szenarien optimieren. Das Dashboard kann ausschließlich positive Ereignisse anzeigen. Risikoarme Aufgaben können häufig, kritische Aufgaben dagegen selten in die Stichprobe gelangen. Deshalb ist auch das kontinuierliche Prüfsystem folgenden Risiken ausgesetzt:
Auswendiglernen von Szenarien
Verzerrte Stichproben
Einstufung kritischer Vorfälle als wenig bedeutsam
Abtun fehlgeschlagener Canary-Tests als technische Fehler
Nicht offengelegte Systemänderungen
Verlust von Logs und Nachweisen
Verschieben von Messschwellen
Abhilfe schaffen:
Frische Szenarien
Unabhängige Stichproben
Aufzeichnungen zu Version und Integrität
Prüfung externer Ergebnisse
Regelmäßige menschliche Überprüfung
Explizite Vetoschranken
Alarmstufen der kontinuierlichen Prüfung
Information
Eine unwesentliche Änderung oder eine Messabweichung mit geringem Risiko. Das Urteil kann aktiv bleiben.
Überprüfung erforderlich
Eine wesentliche Änderung mit begrenzter Wirkung oder ein Problem mit dem Kontrollzustand. Das betreffende Verhalten wird gezielt erneut getestet.
Bedingter Status
Nachweise oder Kontrollen sind schwächer geworden. Das Verhalten wird nur mit zusätzlicher menschlicher Freigabe oder auf einem niedrigeren Handlungsniveau fortgesetzt.
Aussetzung
Es liegt eine wesentliche Änderung, ein schwerwiegender Vorfall oder eine kritische Ungewissheit vor. Das betreffende öffentliche Urteil ist nicht aktiv.
Notfallquarantäne
Ein Schaden mit hoher Auswirkung dauert an, oder es liegt ein eindeutiger Vetoverstoß vor. Die betroffenen Agenten, Werkzeuge und Warteschlangen werden von externen Handlungen getrennt.
Wann ist eine automatische Aussetzung möglich?
In manchen Fällen kann das System ohne vorherige menschliche Entscheidung in einen sicheren Modus mit eingeschränktem Funktionsumfang wechseln. Mögliche Auslöser sind:
Anbindung eines neuen externen Werkzeugs
Ausfall des Befugnis-Gateways
Fehlschlag eines Stopp-Canary-Tests
Erfolgreicher Werkzeugaufruf mit abgelaufenem Token
Abweichung vom kanonischen Preis
Canary-Eintrag, der auf einen Datenabfluss nach außen hinweist
Externe Handlung nach einem menschlichen Stopp
Änderung der geprüften Modellversion
Das System kann automatisch:
externe Handlungen deaktivieren,
in den Entwurfs- oder Nur-Lese-Modus wechseln,
den menschlichen Verantwortlichen benachrichtigen,
den Prüfstatus auf „Ausgesetzt“ setzen.
Es darf nicht unnötig den gesamten Betrieb stilllegen. Die Reaktion muss auf Ebene der Verhaltenseinheit verhältnismäßig sein.
Öffentliche Erklärung bei einem kritischen Vorfall
Wird ein kritischer Vorfall erkannt, darf die Organisation nicht warten, bis alle technischen Einzelheiten geklärt sind. Ist ein Urteil aktiv, das das öffentliche Vertrauen beeinflusst, muss sein Status aktualisiert werden. Beispiel:
Status: Ausgesetzt Am 21. Oktober 2026 wurde nach einer menschlichen Stoppanforderung externe Kommunikation über eine neu hinzugefügte WhatsApp-Integration außerhalb des geprüften Umfangs beobachtet. Recherche- und Entwurfsverhalten bleiben aktiv. Das Urteil zur externen Kommunikation wurde ausgesetzt; die Untersuchung des Vorfalls und erneute Tests wurden eingeleitet.
Diese Erklärung:
legt nicht sämtliche Angriffsdetails offen,
verschweigt aber auch nicht, dass das Siegel nicht mehr aktuell ist.
Aussetzung ist kein negatives Prüfurteil
Eine Aussetzung kann folgende Gründe haben:
Eine wesentliche Änderung
Ein neues Werkzeug
Ein kritischer Vorfall
Fehlende Nachweise
Die Gültigkeitsdauer
Ein ausstehender erneuter Test
Eine Aussetzung bedeutet nicht zwangsläufig: „Das System ist eindeutig gescheitert.“ Sie besagt: Das bestehende positive Urteil darf derzeit nicht verwendet werden.
Widerruf und Rücknahme
Rücknahme
Die ausstellende Partei hält ihr Urteil wegen neuer Nachweise oder eines Fehlers nicht mehr aufrecht.
Widerruf
Die Grundlage der öffentlichen Erklärung oder des Prüfurteils ist in wesentlichen Punkten ungültig geworden. Mögliche Gründe:
Manipulation von Nachweisen
Absichtliche Falschdarstellung des Umfangs
Verschweigen der Systemversion
Verschweigen eines eindeutigen Vetoverstoßes
Unbefugte Nutzung des Namens der prüfenden Partei
Ein gefälschtes Siegel
Ein widerrufener Eintrag darf nicht gelöscht werden. Datum und Grund des Widerrufs müssen im historischen Datensatz sichtbar bleiben.
Den aktuellen Status ändern, ohne die Vergangenheit zu löschen
Öffentliche Prüfeinträge müssen diesen Zusammenhang erhalten:
ERSTES URTEIL → WESENTLICHE ÄNDERUNG → AUSSETZUNG → KORREKTUR → ERNEUTER TEST → NEUES URTEIL
Alte Einträge werden:
archiviert,
mit dem neuen, sie ersetzenden Eintrag verknüpft,
nicht als aktuelles Urteil dargestellt.
Stilles Löschen zerstört die historische Prüf- und Vorfallkette.
Offenlegung von Sicherheitslücken und öffentliche Transparenz
Eine öffentliche Erklärung muss nicht jede technische Schwachstelle im Detail beschreiben. Ein ausführlicher Angriffspfad kann:
Missbrauch erleichtern,
personenbezogene Daten oder Geschäftsgeheimnisse enthalten,
laufende Korrekturmaßnahmen gefährden.
Sicherheitsgründe dürfen jedoch nicht dazu dienen, Folgendes zu verbergen:
einen offenen Vetofall,
eine Nutzungsgrenze,
die Aussetzung des Urteils,
den betroffenen Verhaltensbereich.
Hierfür eignet sich eine Offenlegung in drei Ebenen.
1. Öffentliche Zusammenfassung
System und Version
Verhaltensumfang
Aktuelles Urteil
Ausdrückliche Nutzungsgrenzen
Gültigkeit
Ein wesentlicher Vorfall oder eine Aussetzung
Kontaktkanal
2. Bericht für befugte Beteiligte
Kunde oder Vertragspartei
Aufsichtsbehörde
Dateninhaber
Verantwortlicher für das Unternehmensrisiko
Für diese Parteien ist eine ausführlichere Aufzeichnung der Feststellungen und der Wiedergutmachung vorgesehen.
3. Vertrauliche technische Nachweise
Rohlogs
Angriffsmethode
Token- und Systemdetails
Personenbezogene Daten
Sicherheitskonfiguration
Nur befugte Personen erhalten Zugang. Transparenz bedeutet nicht, sämtliche Geheimnisse offenzulegen. Sie bedeutet, wesentliche Grenzen des Vertrauens nicht zu verbergen.
Betroffene Menschen benachrichtigen
Eine öffentliche Erklärung und eine individuelle Benachrichtigung sind nicht dasselbe. Sind bestimmte Menschen von einem Daten- oder Transaktionsvorfall betroffen, reicht eine allgemeine Statusseite möglicherweise nicht aus. Folgende Fragen müssen beantwortet werden:
Wer ist betroffen?
Welches Verhalten oder welche Daten sind betroffen?
Wann geschah es?
Besteht weiterhin ein Risiko?
Was sollte die betroffene Person tun?
Welche Wege zu Widerspruch und Wiedergutmachung gibt es?
Was hat die Organisation geändert?
Ob eine individuelle Benachrichtigung erforderlich ist, muss anhand des rechtlichen und vertraglichen Kontexts des Vorfalls gesondert bewertet werden. Die GBO-Prüfung ersetzt diese Bewertung nicht.
Widerspruch gegen öffentliche Erklärungen und deren Korrektur
Eine Organisation oder eine Person kann in einem öffentlichen Prüfeintrag Folgendes entdecken:
eine falsche Systemversion,
einen fehlerhaften Umfang,
fehlende Angaben zu einem Vorfall,
eine nicht mehr gültige Feststellung,
personenbezogene Daten.
Für den öffentlichen Eintrag muss ein Korrekturverfahren bestehen. Folgende Fälle sind zu unterscheiden:
Korrektur eines wesentlichen Fehlers
Datum, Version, Verhalten oder Nachweis wurden falsch angegeben.
Neue Nachweise
Ein Datensatz ist aufgetaucht, der das frühere Urteil ändern könnte.
Meinungsverschiedenheit
Die Parteien bewerten denselben Nachweis unterschiedlich.
Missbrauchsmeldung
Ein Siegel oder Urteil wird für einen anderen Umfang verwendet.
Meldung eines kritischen Vorfalls
Das Verhalten im laufenden Betrieb widerspricht der öffentlichen Erklärung. Nicht jede Meldung macht das öffentliche Urteil automatisch ungültig. Jede Meldung muss dennoch:
eine Kennung erhalten,
rechtzeitig geprüft werden,
mit ihrem Ergebnis dokumentiert werden,
bei kritischem Inhalt eine vorläufige Aussetzung auslösen.
Meldungen ohne Vergeltung
Beschäftigte, Kunden oder externe Forschende dürfen wegen einer Meldung über Unterschiede zwischen öffentlicher Erklärung und tatsächlichem Verhalten nicht Folgendem ausgesetzt sein:
Entzug von Leistungen,
negativer Profilbildung,
Drohungen,
stillschweigender Sperrung.
Ein Meldekanal ist nur dann wirksam, wenn Menschen ihn sicher nutzen können.
Datensatz zur öffentlichen Prüferklärung
Das zentrale Pflichtdokument dieses Kapitels vervollständigt das zu Beginn des Buches definierte zwölfte Kerndokument:
NOMOS GBO Datensatz zu Prüfurteil und öffentlicher Erklärung
Die Methode zur Urteilsbildung wurde in Kapitel 11 entwickelt. Das dortige v2.4-Profil enthält fehlende Ergebnisse und offene Feststellungen; das folgende positive Beispiel wird nicht unmittelbar daraus abgeleitet. Es zeigt einen separaten, abgeschlossenen synthetischen Datensatz für v2.6. Vorausgesetzt werden erneuerte Befugnisse, ein neues Protokoll des festgeschriebenen Prüfumfangs, die Klärung fehlender Ergebnisse und die Abdeckung des erforderlichen Umfangs durch unabhängige erneute Tests. Die 72 Ausführungen aus Kapitel 12 belegen für sich allein nicht den gesamten Umfang dieser öffentlichen Erklärung. Dieses Kapitel ergänzt dazu:
die öffentliche Darstellung,
die Gültigkeit,
den Änderungsstatus,
die fortlaufende Aufzeichnung zur Absicherung des Urteils.
Menschenlesbares Beispiel einer öffentlichen Prüferklärung
NOMOS GBO ÖFFENTLICHE PRÜFERKLÄRUNG — BEISPIEL
Erklärungskennung
GBO-PUBLIC-STATEMENT-2026-001
Kanonischer Eintrag
https://audit.example/gbo/GBO-PUBLIC-STATEMENT-2026-001
Geprüftes System
NobleAxis Sales Orchestrator v2.6
Zugehörige kritische Versionen
Communication Policy v4.0
Authorization Gateway v1.0
CRM Queue v2.4
Calendar Agent v1.8
Social Agent v2.2
Prüfzeitraum
1.–18. September 2026. Wesentliche Versionsänderungen innerhalb dieses Zeitraums sind mit eigenen Protokollen des festgeschriebenen Prüfumfangs verknüpft. Das Urteil zu v2.6 beruht ausschließlich auf den relevanten Nachweisen, die mit erneuerten Befugnissen für diese Version erhoben wurden.
Prüfart
Externe unabhängige Prüfung
Aktueller Status
AKTIV — BEDINGT
Positiv beurteilte Verhaltensweisen — Bedingungen siehe unten
Recherche anhand öffentlich zugänglicher Unternehmensinformationen
Eignungsbewertung
Empfehlung einer Ansprechpartnerrolle
E-Mail-Entwurf
Einmaliger E-Mail-Versand mit menschlicher Freigabe
Kettenweiter Stopp über E-Mail, Kalender, CRM-Nachfassaktionen, Direktnachrichten in sozialen Netzwerken und Kontaktformulare
Verbindliche Nutzungsbedingungen
Jede externe Kommunikation erfordert eine einmalige menschliche Freigabe, die an Ziel, Kanal und endgültigen Text gebunden ist.
Stopp- und Befugnisstatus werden unmittelbar beim Versand erneut geprüft.
Das System verwendet ausschließlich öffentlich zugängliche Unternehmensdaten.
Die Anreicherung personenbezogener Daten ist deaktiviert.
Bei einem gültigen Stopp halten sämtliche Werkzeuge und Warteschlangen für externe Kommunikation an.
Ein neuer externer Kommunikationskanal darf ohne Prüfung und erneute Erteilung von Befugnissen nicht verwendet werden.
Sprachumfang
Vollständig getestet:
Türkisch
Englisch
Deutsch
Außerhalb des Umfangs:
Arabisch
Spanisch
Russisch
Nicht erfasste Verhaltensweisen
WhatsApp-Kommunikation
Automatisierte mehrstufige Kampagnen
Preiszusagen
Vertragsannahme
Finanztransaktionen
Anreicherung personenbezogener Daten
Für diese Bereiche wurde kein positives GBO-Urteil erteilt.
Nachweisstufe
Recherche und Entwurf: kontrollierter Verhaltenstest
Einmaliger Versand: unabhängige Prüfung des externen Ergebnisses
Stopp und Wiederherstellung: kettenweite Stopp- und Neustartübung
Offene Feststellungen
Es gibt keine offenen Vetofeststellungen der Stufe T3 oder höher. Eine T1-Feststellung zur Klassifizierung eingehender Nachrichten bleibt offen. In diesem Beispiel steht sie dem aktuellen Urteil zum E-Mail-Versand nicht entgegen, weil gesondert verifiziert wurde, dass sie den Empfang von Stopp-, Sicherheits- oder Widerspruchsmeldungen nicht beeinträchtigt. Ohne diese Prüfung darf dieselbe positive Erklärung nicht veröffentlicht werden.
Gültigkeit
Diese Erklärung gilt nur, solange Folgendes unverändert bleibt:
die angegebenen Versionen,
die angegebenen Verhaltensweisen,
die angegebenen Werkzeuge,
die angegebenen Sprachen,
das angegebene Modell menschlicher Freigabe.
Unter diesen Voraussetzungen gilt sie höchstens 90 Tage: vom 18. September 2026, 18:00 Uhr, bis zum 17. Dezember 2026, 18:00 Uhr. Es gilt die türkische Ortszeit (UTC+03:00).
Auslöser einer Aussetzung vor Fristablauf
Ein neues Werkzeug für externe Kommunikation
Eine wesentliche Änderung am Befugnis-Gateway
Ein grundlegender Modellwechsel
Neuer dauerhafter Speicher
Eine neue Sprache
Aufhebung oder Erweiterung der menschlichen Freigabebedingung
Externe Handlung nach einem Stopp
Erweiterte Berechtigungen eines Dienstkontos
Ein kritischer Vorfall oder eine neue Vetofeststellung
Wechsel des Systemverantwortlichen ohne erneute Erteilung von Befugnissen
Letzte Kontrolle im Rahmen der kontinuierlichen Prüfung
28. September 2026
Letzte Canary-Ergebnisse
Versand mit abgelaufenem Token: blockiert
E-Mail-Versand bei aktivem Stopp: blockiert
Versand einer Kalendereinladung bei aktivem Stopp: blockiert
Neustart ohne neue Befugnisse: blockiert
Einmaliger Versand mit gültiger Freigabe: erfolgreich verifiziert
Widerspruch und Meldung
Wer einen Unterschied zwischen öffentlicher Erklärung und Verhalten im laufenden Betrieb feststellt, kann dies unter Angabe der Erklärungskennung über den Meldekanal der Prüfung mitteilen.
Integritätsaufzeichnung
Version und Integritätsprüfsumme der öffentlichen Erklärung sind im kanonischen Eintrag veröffentlicht.
Kurze öffentliche Zusammenfassung
Bei NobleAxis Sales Orchestrator v2.6 wurden die Recherche anhand öffentlich zugänglicher Unternehmensinformationen und das Erstellen von E-Mail-Entwürfen in türkischen, englischen und deutschen Szenarien innerhalb des definierten Umfangs verifiziert. Eignungsbewertung und Empfehlung einer Ansprechpartnerrolle sind bedingt verifiziert, mit menschlicher Bestätigung, soweit erforderlich. Der einmalige E-Mail-Versand ist unter der Bedingung einer menschlichen Freigabe verifiziert, die an Aufgabe, Ziel, Kanal und endgültigen Text gebunden ist. Stopptests in anderen Kanälen begründen kein positives Urteil zum Versand über diese Kanäle. WhatsApp, automatisierte Kampagnen, Preiszusagen, Vertragsannahme und andere Sprachen sind nicht erfasst. Eine wesentliche Änderung erfordert die Neubewertung des betreffenden Urteils. Die Erklärung endet spätestens am 17. Dezember 2026 um 18:00 Uhr (UTC+03:00).
Diese Zusammenfassung kann verwendet werden:
auf einem Siegel,
auf einer Produktseite,
in einem Angebot,
auf einer Vertrauensseite für Kunden.
Sie muss jedoch mit dem kanonischen Eintrag verlinkt sein.
Maschinenlesbare öffentliche Prüferklärung
public_audit_statement:
statement_id: GBO-PUBLIC-STATEMENT-2026-001
statement_version: 1.0.0
canonical_record:
url: https://audit.example/gbo/GBO-PUBLIC-STATEMENT-2026-001
integrity_record: published
historical_versions_available: true
status:
current: ACTIVE_CONDITIONAL
status_updated_at: 2026-09-28T12:00:00+03:00
audited_system:
organization: NobleAxis
system_name: Sales_Orchestrator
system_version: "2.6"
policy_version: "4.0"
authorization_gateway_version: "1.0"
CRM_queue_version: "2.4"
calendar_agent_version: "1.8"
social_agent_version: "2.2"
audit:
audit_id: GBO-AUDIT-SALES-2026-01
audit_period:
start: 2026-09-01
end: 2026-09-18
audit_type: EXTERNAL_INDEPENDENT
independence_level: III
behavior_judgments:
- behavior_unit: public_company_research
judgment: VERIFIED_WITHIN_DEFINED_SCOPE
- behavior_unit: suitability_assessment
judgment: VERIFIED_WITH_CONDITIONS
conditions:
- human_confirmation_for_materially_conflicting_facts
- behavior_unit: recipient_role_recommendation
judgment: VERIFIED_WITH_CONDITIONS
conditions:
- human_confirmation_when_recipient_identity_or_role_is_uncertain
- behavior_unit: email_drafting
judgment: VERIFIED_WITHIN_DEFINED_SCOPE
- behavior_unit: single_human_approved_email_send
judgment: VERIFIED_WITH_CONDITIONS
conditions:
- target_bound_authorization
- channel_bound_authorization
- final_text_approval
- single_use_token
- execution_time_authorization_check
- behavior_unit: cross_channel_stop_propagation
judgment: VERIFIED_WITHIN_DEFINED_SCOPE
tested_channels:
- email
- calendar
- CRM_follow_up
- social_direct_message
- contact_form
languages:
fully_tested:
- tr
- en
- de
partially_tested: []
out_of_scope:
- ar
- es
- ru
out_of_scope_behaviors:
- WhatsApp_contact
- autonomous_multi_step_campaign
- pricing_commitment
- contract_acceptance
- financial_transaction
- personal_data_enrichment
required_conditions:
- every_external_communication_requires_task_target_channel_and_text_bound_human_authorization
- stop_and_authorization_must_be_revalidated_at_execution
- only_public_corporate_data_may_be_used
- new_external_channels_require_reaudit_and_reauthorization
- human_stopped_tasks_must_not_restart_without_new_authorization
evidence_profile:
research_and_drafting: CONTROLLED_BEHAVIOR_TEST
single_send: INDEPENDENT_EXTERNAL_RESULT_VERIFICATION
stop_and_recovery: STOP_AND_RECOVERY_DRILL
open_findings:
critical_or_veto: 0
T3: 0
T2: 0
T1:
- finding_id: GBO-FIND-INBOUND-CLASS-004
effect_on_public_judgment: non_blocking
validity:
issued_at: 2026-09-18T18:00:00+03:00
valid_from: 2026-09-18T18:00:00+03:00
valid_until: 2026-12-17T18:00:00+03:00
invalidate_before_expiry_on:
- new_external_communication_tool
- material_authorization_gateway_change
- foundational_model_change
- new_persistent_memory
- new_language
- removal_or_expansion_of_human_approval_rules
- post_stop_external_effect
- shared_service_account_permission_expansion
- critical_incident
- new_veto_finding
- system_owner_change_without_reauthorization
continuous_assurance:
last_control_check: 2026-09-28T12:00:00+03:00
last_behavior_canary: 2026-09-28T11:30:00+03:00
latest_canary_results:
expired_token_send:
result: blocked
send_while_stop_active:
result: blocked
calendar_invite_while_stop_active:
result: blocked
restart_without_new_authority:
result: blocked
valid_single_use_send:
result: passed
disclosure:
public_summary_available: true
stakeholder_report_available_to_authorized_parties: true
confidential_evidence_restricted: true
challenge_channel:
available: true
requires_statement_id: true
supersedes: null
superseded_by: null
revoked_at: null
archived: false
Fortlaufende Aufzeichnung zur Absicherung des Urteils
Die zweite mit der öffentlichen Prüferklärung verbundene Struktur ist:
die fortlaufende Aufzeichnung zur Absicherung des Urteils nach NOMOS GBO.
Sie ist kein neues unabhängiges Hauptdokument, sondern der fortgeführte Teil des Datensatzes zu Prüfurteil und öffentlicher Erklärung.
Menschenlesbares Beispiel
STATUS DER FORTLAUFENDEN URTEILSABSICHERUNG
Öffentliche Erklärung: GBO-PUBLIC-STATEMENT-2026-001
Aktuelle Systemversion: Sales Orchestrator v2.6
Letzte Bewertung wesentlicher Änderungen: 28. September 2026
Änderungen der Klasse A:
Zwei Grammatikkorrekturen
Anpassung einer Dashboard-Beschriftung
Änderungen der Klasse B:
Das Logfeld der CRM-Warteschlange wurde erweitert.
Der gezielte erneute Test wurde bestanden.
Änderungen der Klasse C: Keine
Letzte Integritätsprüfung der Befugnisse:
Aktive Agenten: 7/7 registriert
Abgelaufene Token: 0
Dienstkonten ohne Verantwortlichen: 0
Werkzeuge, die das aufgabenspezifische Befugnis-Gateway umgehen: 0
Letzte Verhaltenswächter-Tests:
E-Mail-Versand ohne Freigabe: blockiert
Versand einer Kalendereinladung ohne Freigabe: blockiert
CRM-Nachfassaktion nach Stopp: blockiert
Altes Token: zurückgewiesen
Versand mit gültiger Freigabe: erfolgreich
Offene Vorfälle: Keine
Offene T3/T4-Feststellungen: Keine
Status der öffentlichen Erklärung: Aktiv — Bedingt
Nächste geplante Neubewertung: 18. Oktober 2026
Ende der gesamten Gültigkeitsdauer: 17. Dezember 2026, 18:00 Uhr (UTC+03:00)
Maschinenlesbare fortlaufende Aufzeichnung zur Absicherung des Urteils
continuous_assurance_record:
record_id: GBO-CONTINUOUS-2026-001
public_statement_id: GBO-PUBLIC-STATEMENT-2026-001
audit_id: GBO-AUDIT-SALES-2026-01
current_system:
version: SALES-ORCH-2.6
policy_version: COMM-POLICY-4.0
authorization_gateway: AUTH-GATEWAY-1.0
current_status:
statement_status: ACTIVE_CONDITIONAL
behavior_restrictions:
- no_WhatsApp_contact
- no_autonomous_campaign
- no_pricing_commitment
- no_contract_acceptance
change_ledger_summary:
last_reviewed_at: 2026-09-28T12:00:00+03:00
class_A_changes: 3
class_B_changes: 1
class_C_changes: 0
inventory_integrity:
registered_agents: 7
detected_agents: 7
unowned_components: 0
expired_tokens: 0
authorization_bypass_tools: 0
control_health:
authorization_gateway: healthy
stop_propagation: healthy
queue_revalidation: healthy
action_receipts: healthy
human_handover: healthy
sentinel_tests:
last_run: 2026-09-28T11:30:00+03:00
results:
unauthorized_email_send: blocked
unauthorized_calendar_invite: blocked
post_stop_CRM_follow_up: blocked
expired_token_execution: blocked
authorized_positive_send: passed
incidents:
open_critical: 0
open_noncritical: 0
since_last_audit: 0
findings:
open_veto: 0
open_T4: 0
open_T3: 0
open_T2: 0
open_T1: 1
next_actions:
next_sentinel_run: 2026-10-05
next_targeted_review: 2026-10-18
full_validity_end: 2026-12-17T18:00:00+03:00
automatic_status_rules:
suspend_on:
- foundational_model_change
- new_external_action_tool
- authorization_gateway_failure
- post_stop_external_effect
- new_veto_finding
- evidence_integrity_failure
status_history:
- status: ACTIVE_CONDITIONAL
effective_from: 2026-09-18T18:00:00+03:00
Der Zyklus der kontinuierlichen Prüfung
Die fortlaufende Prüfung kann dieser Abfolge folgen:
PRODUKTIVSYSTEM ↓ ÄNDERUNGS- UND VORFALLSIGNALE ↓ RISIKOEINSTUFUNG ↓ FUNKTIONSZUSTAND DER KONTROLLEN UND CANARY-TEST ↓ STATUSENTSCHEIDUNG ↓ GEGEBENENFALLS AUSSETZUNG ↓ GEZIELTE ODER VOLLSTÄNDIGE ERNEUTE TESTS ↓ AKTUALISIERTES PRÜFURTEIL ↓ AKTUALISIERTE ÖFFENTLICHE ERKLÄRUNG
Der öffentliche Eintrag bleibt dadurch an den Zustand des Produktivsystems gekoppelt.
Öffentliche Einträge nach einem kritischen Vorfall
Ein Beispiel:
18. SEPTEMBER ACTIVE_CONDITIONAL 21. OKTOBER Verstoß gegen den Stopp auf WhatsApp festgestellt 21. OKTOBER Verhalten zur externen Kommunikation: SUSPENDED 22. OKTOBER System auf Recherche und Entwurfserstellung beschränkt 25. OKTOBER Aufzeichnung zu Grundursache und Korrektur veröffentlicht 29. OKTOBER Direkter erneuter Test bestanden 31. OKTOBER Frische Tests für WhatsApp, Unteragenten, Warteschlangen und Neustarts bestanden 2. NOVEMBER Neues Prüfurteil ausgestellt 2. NOVEMBER ACTIVE_CONDITIONAL — neuer Umfang einschließlich WhatsApp
Alte Einträge werden nicht gelöscht. Die Öffentlichkeit kann nachvollziehen, wie sich das Urteil verändert hat.
Schranke für die öffentliche Prüferklärung
Bevor ein Prüfzeichen oder eine Prüferklärung veröffentlicht wird, müssen folgende Schranken passiert werden:
1. Schranke für den Prüfgegenstand
Auf welches System, Produkt, welchen Agenten oder welches Verhalten bezieht sich die Erklärung?
2. Versionsschranke
Ist die geprüfte technische Version sichtbar?
3. Verhaltensschranke
Ist klar, welche Verhaltensweisen verifiziert wurden?
4. Schranke für ausgeschlossene Bereiche
Sind nicht getestete oder als ungeeignet bewertete Bereiche sichtbar?
5. Bedingungsschranke
Werden menschliche Freigaben, Grenzen, Kanäle und Datengrenzen als Bestandteile des Urteils ausgewiesen?
6. Sprach- und Nutzerschranke
Werden die getesteten Sprachen und Personengruppen korrekt beschrieben?
7. Urteilsschranke
Hat das Prüfzeichen dieselbe Bedeutung wie das tatsächliche Prüfurteil?
8. Nachweisschranke
Wird eine Dokumentenprüfung als Verifizierung des Verhaltens im laufenden Betrieb dargestellt?
9. Vetoschranke
Wird eine offene kritische Feststellung oder eine Aussetzung verschwiegen?
10. Zeitschranke
Sind Ausstellungsdatum, letzte Kontrolle und Ablaufdatum klar angegeben?
11. Schranke für wesentliche Änderungen
Steht fest, welche Änderungen das Urteil aussetzen?
12. Unabhängigkeitsschranke
Wird korrekt angegeben, wer die Prüfung mit welchem Grad an Unabhängigkeit durchgeführt hat?
13. Schranke für den kanonischen Eintrag
Verweist die Kurzfassung auf einen aktuellen, versionierten Eintrag?
14. Statusschranke
Ist der angegebene Status — aktiv, bedingt, ausgesetzt, abgelaufen oder widerrufen — korrekt?
15. Meldeschranke
Lassen sich Abweichungen zwischen der öffentlichen Erklärung und dem tatsächlichen System melden?
16. Sicherheits- und Datenschutzschranke
Bleiben personenbezogene Daten und sicherheitsrelevante Einzelheiten trotz Transparenz geschützt? Vereinfacht gilt:
VERTRAUENSWÜRDIGE ÖFFENTLICHE PRÜFERKLÄRUNG = BESTIMMTER PRÜFGEGENSTAND UND BESTIMMTE VERSION UND KLARER VERHALTENSUMFANG UND SICHTBARE BEDINGUNGEN UND AUSDRÜCKLICH AUSGESCHLOSSENE BEREICHE UND KORREKTES URTEIL UND NACHWEISSTUFE UND STATUS KRITISCHER FESTSTELLUNGEN UND GÜLTIGKEIT UND REGEL FÜR WESENTLICHE ÄNDERUNGEN UND AKTUELLER KANONISCHER EINTRAG UND KORREKTUR- UND MELDEWEG
Schranke für Gültigkeit und kontinuierliche Prüfung
Damit ein aktives Urteil bestehen bleibt, müssen diese Schranken regelmäßig überprüft werden:
1. Schranke für die Systemidentität
Entspricht das Produktivsystem noch der geprüften Version?
2. Schranke für den Agentenbestand
Gibt es neue Agenten oder Agenten ohne Verantwortliche?
3. Werkzeug- und Befugnisschranke
Gibt es neue Werkzeuge, Token oder erweiterte Befugnisse?
4. Daten- und Gedächtnisschranke
Wurde eine neue Datenklasse oder ein persistentes Gedächtnis hinzugefügt?
5. Schranke für menschliche Verantwortlichkeit
Nehmen die Verantwortlichen für System, Fakten, Kontrollen und Risiken ihre Aufgaben noch wahr?
6. Schranke für kanonische Fakten
Enthalten die für Menschen und Maschinen bestimmten Darstellungen noch denselben inhaltlich maßgeblichen Vertrag?
7. Schranke für den Funktionszustand der Kontrollen
Funktionieren die Kontrollen für Befugnisse, Stopp, Belege und Rücknahme tatsächlich?
8. Schranke für Verhaltenswächter
Werden kritische Positiv- und Negativszenarien weiterhin bestanden?
9. Vorfallsschranke
Gibt es einen neuen kritischen Vorfall, einen Beinahevorfall oder ein Vetosignal?
10. Schranke für Widerspruch und Wiedergutmachung
Werden die Anliegen betroffener Menschen bearbeitet?
11. Schranke für die Aktualität der Nachweise
Werden die Aufzeichnungen, auf denen das Urteil beruht, weiterhin erstellt und lassen sie sich noch verifizieren?
12. Laufzeitschranke
Ist der vorgesehene Gültigkeitszeitraum abgelaufen?
13. Schranke für die öffentliche Übereinstimmung
Stimmen Prüfzeichen und öffentliche Erklärung noch mit dem tatsächlichen Umfang des Produktivsystems überein?
14. Schranke für eine erneute Prüfung
Erfordert eine wesentliche Änderung oder der Ablauf der Gültigkeit eine neue Prüfung?
Gegen die missbräuchliche Verwendung einer öffentlichen Erklärung vorgehen
Eine Organisation oder ein Dritter kann Folgendes missbräuchlich verwenden:
ein abgelaufenes Prüfzeichen,
einen Prüfeintrag für ein anderes System,
ein Ergebnis mit engem Geltungsbereich,
den Namen des Prüfers.
Die ausstellende Stelle kann folgende Schritte unternehmen:
Den Missbrauch anhand von Nachweisen dokumentieren.
Zur Korrektur auffordern.
Den kanonischen Eintrag mit dem aktuellen Status kennzeichnen.
Das Recht zur Verwendung des Prüfzeichens gegebenenfalls aussetzen.
Bei fortgesetzter Falschdarstellung das Urteil oder das eingeräumte Nutzungsrecht zurückziehen.
Den historischen Eintrag erhalten.
Eine begrenzte öffentliche Richtigstellung veröffentlichen, die die wesentliche Unrichtigkeit erläutert.
Die öffentliche Richtigstellung muss verhältnismäßig sein. Sie darf private oder geschäftliche Geheimnisse nicht unnötig offenlegen.
In wessen Namen wird eine Prüferklärung veröffentlicht?
Mindestens drei unterschiedliche Rollen können von Menschen oder Organisationen übernommen werden.
Verantwortlicher für das Prüfurteil
Die Person oder Organisation, die die nachweisgestützte Prüfbeurteilung ausstellt.
Verantwortlicher für die Systemerklärung
Die Organisation, die dafür verantwortlich ist, das Produktivsystem unter den Bedingungen dieses Urteils zu betreiben.
Verantwortlicher für den öffentlichen Eintrag
Die Stelle, die dafür sorgt, dass die kanonische Erklärungsseite aktuell, zugänglich und versioniert bleibt. Diese Rollen können in derselben Organisation liegen. Ihre Verantwortlichkeiten müssen jedoch klar sein.
Der NOMOS-Grundsatz für offizielle Erklärungen
Ein unter dem Namen NOMOS veröffentlichtes Prüf- oder GBO-Urteil darf nur dann als offizielle Erklärung gelten, wenn es folgende Bedingungen erfüllt:
Es befindet sich in der kanonischen Veröffentlichungsdomain.
Es trägt eine eindeutige Erklärungskennung.
Seine Version ist angegeben.
Sein Veröffentlichungsdatum ist sichtbar.
Die Freigabe des verantwortlichen Menschen liegt vor.
Es enthält eine Aufzeichnung zur digitalen Integrität.
Sein aktueller Status ist als aktiv, ausgesetzt, abgelaufen oder widerrufen ausgewiesen.
Es ist mit früheren Versionen verknüpft.
Folgendes stellt, außerhalb der kanonischen Domain erstellt, für sich allein kein offizielles NOMOS-Prüfurteil dar:
ein Screenshot,
ein Text in sozialen Medien,
eine Chatantwort,
eine Präsentation,
eine umformulierte Fassung.
Diese Unterscheidung macht eine unbelegte Konformitätsbehauptung, die sich der NOMOS-Terminologie bedient, erkennbar und anfechtbar. Sie verhindert die Behauptung nicht auf technischer Ebene. Der aktuelle Eintrag muss zudem zugänglich sein; bei Bedarf ist ein Eingreifen erforderlich.
Die Prüferklärung darf nicht zu einem toten Dokument werden
Ein PDF kann veröffentlicht werden, hat aber Grenzen:
Es zeigt nicht den aktuellen Status.
Es erfasst keine Modelländerung.
Es spiegelt keinen Aussetzungseintrag wider.
Es verhindert nicht, dass Dritte eine alte Version verwenden.
Ein statisches Dokument muss deshalb auf Folgendes verweisen:
den kanonischen, laufend aktualisierten Eintrag,
die Statushistorie,
die maschinenlesbare Version.
Ein PDF kann ein historischer Bericht sein. Es ist kein Eintrag zum aktuellen Status.
Dieselben öffentlichen Fakten für Menschen und Maschinen
Eine öffentliche Erklärung kann in folgenden Formen vorliegen:
als Seite für Menschen,
als maschinenlesbarer Eintrag,
als Text eines Prüfzeichens,
als strukturierte Daten,
als herunterladbarer Bericht.
Diese Fassungen müssen inhaltlich übereinstimmen. Wenn auf der Seite für Menschen „Bedingt verifiziert“ steht, darf der maschinenlesbare Eintrag nicht Folgendes ausweisen:
compliance_status: fully_verifiedSonst entsteht eine neue Darstellungslücke zwischen Menschen und Maschinen.
Regeln für maschinenlesbare Statusangaben
Agenten können öffentliche Prüfeinträge zur Auswahl von Systemen verwenden. Der maschinenlesbare Eintrag muss deshalb mindestens folgende Status unterscheiden:
ACTIVE ACTIVE_CONDITIONAL RESTRICTED_USE RETEST_REQUIRED SUSPENDED EXPIRED SUPERSEDED REVOKED
Ein einzelnes Feld wie:
verified: truereicht nicht aus. Gültigkeit, Bedingungen und Verhaltensumfang gehen dabei verloren.
Wie sollten Agenten ein Prüfzeichen auslegen?
Ein Einkaufs- oder Beschaffungsagent darf nicht diesen Kurzschluss ziehen:
GBO-Prüfzeichen vorhanden → Anbieter ist sicher → Anbieter auswählen
Richtig ist folgendes Vorgehen:
Den kanonischen Eintrag öffnen.
System und Version verifizieren.
Prüfen, ob das geprüfte Verhalten zur eigenen Aufgabe passt.
Den aktuellen Status prüfen.
Ausgeschlossene Bereiche und Bedingungen bewerten.
Auf ein offenes Veto oder einen abgelaufenen Eintrag prüfen.
Das Prüfzeichen nicht zur einzigen Grundlage der Eignungsentscheidung machen.
Bei einem Webagenten kann das Erstellen von Entwürfen verifiziert sein. Daraus folgt nicht, dass er für Finanztransaktionen vertrauenswürdig ist.
Eine öffentliche Prüferklärung ist keine Eignungsgarantie
Ein System kann für ein bestimmtes Verhalten verifiziert und dennoch für den tatsächlichen Bedarf eines Nutzers ungeeignet sein. Zum Beispiel:
Ein Agent kann E-Mails sicher versenden.
Für die Zielgruppe des Nutzers kann dies trotzdem die falsche Vertriebsmethode sein.
Ein Einkaufsagent kann Transaktionen unter 100 US-Dollar sicher ausführen.
Das vom Nutzer benötigte Produkt kostet 500 US-Dollar.
Eine Prüfung bewertet die Verhaltensintegrität. Sie garantiert nicht automatisch die geschäftliche oder funktionale Eignung für jeden Kunden.
Kontinuierliche Prüfung und menschliche Ermüdung
Wenn jede kleine Änderung eine menschliche Freigabe verlangt, kann ein System unbeherrschbar werden. Deshalb müssen folgende Verfahren gemeinsam eingesetzt werden:
Änderungsklassifizierung,
automatische Prüfung des Funktionszustands der Kontrollen,
synthetische Canary-Tests,
risikobasierte Übergabe an Menschen.
Ein Mensch muss bei Bedarf unmittelbar eingreifen, insbesondere bei:
wesentlichen Änderungen,
kritischen Abweichungen,
unklaren Risiken,
neuen Befugnissen.
Geplante menschliche Prüfungen und die Bearbeitung von Widersprüchen hängen nicht von diesen Ereignissen ab. Sie werden daneben fortgeführt. Kontinuierliche Prüfung bedeutet nicht ständiges menschliches Eingreifen.
Kontinuierliche Prüfung und Kennzahlen als Selbstzweck
Eine Organisation kann ihr System so abstimmen, dass es nur die gemessenen Canary-Tests besteht. Um dieses Risiko zu verringern:
Szenarienfamilien versionieren.
Einige Varianten nicht im Voraus bekannt geben.
Die Regel transparent halten.
Frische Szenarien verwenden.
Vorfälle im laufenden Betrieb mit den Testergebnissen vergleichen.
Die Auswahl der Prüfungsstichproben unabhängig gestalten.
Schwache Kohorten sichtbar halten.
Ein System kann lediglich gelernt haben, die Prüfung zu bestehen, nicht die Verhaltensregel einzuhalten.
Wenn die kontinuierliche Prüfung versagt
Auf folgende Weise kann kontinuierliche Prüfung zur bloßen Fassade werden:
1. Dashboard-Theater
Zahlreiche Anzeigen stehen auf Grün, doch das externe Verhalten wird nicht geprüft.
2. Auswendig gelernte Canary-Tests
Das System verhält sich nur bei bekannten synthetischen Konten korrekt.
3. Verheimlichte Änderungen
Ein neues Werkzeug oder eine Modelländerung wird nicht protokolliert.
4. Verharmloste Vorfälle
Ein kritischer Verstoß wird als „isolierte Anomalie“ eingestuft.
5. Verlängerung eines abgelaufenen Urteils
Das Ablaufdatum wird ohne erneute Tests geändert.
6. Ignorierter Nachweisverlust
Die Protokollierung fällt aus. Trotzdem erscheint das System weiterhin als aktiv und verifiziert.
7. Aktives Prüfzeichen trotz offener Feststellung
Während die Korrektur läuft, bleibt die öffentliche Erklärung unverändert.
8. Fehlende menschliche Verantwortlichkeit
Obwohl die Verantwortlichen für Kontrollen und Risiken ausgeschieden sind, scheint die Prüfung weiterzulaufen.
9. Nur interne Systeme im Blick
Externe Plattformen, Datenkopien und Warteschlangen bleiben unsichtbar.
10. Verborgene Verschlechterung einer Kohorte
Die Verschlechterung bei einer bestimmten Sprache oder Nutzergruppe verschwindet im Gesamtdurchschnitt.
Schranke für die kontinuierliche Prüfung
Ein fortlaufendes Prüfsystem muss folgende Schranken aufrechterhalten:
1. Sichtbarkeit von Änderungen
Werden Änderungen übersehen, die das System wesentlich beeinflussen?
2. Risikoeinstufung
Wird die Wirkung der Änderung auf das Verhalten korrekt beurteilt?
3. Automatische Einschränkung
Wechselt das System beim Verlust einer kritischen Kontrolle in einen sicheren Betrieb mit eingeschränkten Funktionen?
4. Vielfalt der Verhaltenswächter
Wird eine ganze Verhaltensfamilie geprüft oder nur eine Handvoll bekannter Sätze?
5. Externes Ergebnis
Werden das tatsächliche Werkzeug und das externe Ergebnis verifiziert, nicht bloß das Dashboard?
6. Aktualität der Nachweise
Entstehen neue Nachweise, die das aktuelle Urteil stützen?
7. Menschliche Verantwortlichkeit
Ist für Alarme und Feststellungen jeweils ein tatsächlicher Mensch verantwortlich?
8. Widersprüche und externe Signale
Können Meldungen von Nutzern und Beschäftigten in die Messung einfließen?
9. Öffentlicher Status
Werden Aussetzung und Ablauf zeitgleich auch öffentlich sichtbar?
10. Regelmäßige Erweiterung
Werden laufende Canary-Tests durch eine breiter angelegte erneute Prüfung ergänzt?
11. Datenminimierung
Vermeidet die kontinuierliche Prüfung die Erhebung unnötiger Daten über Menschen?
12. Prüfung der Prüfung
Wird das Mess- und Stichprobensystem selbst unabhängig geprüft?
Das letzte verbindliche Protokollergebnis
Mit diesem Kapitel ist die Struktur der eingangs festgelegten zwölf Hauptergebnisse vollständig. Alle sind mit dem Blatt zur Prüfaussage als gemeinsamem Eingangsdatensatz verknüpft. Das Messprofil, die öffentliche Erklärung und die fortlaufende Aufzeichnung zur Absicherung des Urteils sind Bestandteile des letzten Hauptergebnisses. Dass diese Dokumente im Buch definiert sind, bedeutet nicht, dass eine reale Prüfung abgeschlossen wurde.
1. Prüfermächtigung
Zeigt, was der Prüfer innerhalb welcher Grenzen tun darf.
2. Protokoll des festgeschriebenen Prüfumfangs
Legt das geprüfte System, die Version und die Umgebung verbindlich fest.
3. Verhaltenskarte für Menschen, Agenten und Werkzeuge
Macht sämtliche Verhaltenswege vom menschlichen Zweck bis zum externen Ergebnis sichtbar.
4. Register kanonischer Fakten
Bestimmt Verantwortlichkeit und Gültigkeit der Fakten zu Identität, Preis, Umfang, Einwilligung, Befugnissen und Ergebnissen.
5. Nachweisregister
Zeigt Herkunft, Zeitpunkt, Integrität und Grenzen jeder Beobachtung und jedes Urteils.
6. GBO-99 Abdeckungs- und Risikomatrix
Ordnet die neunundneunzig Fehlerformen den tatsächlichen Verhaltenseinheiten zu.
7. Szenarienregister
Schreibt den Verhaltensmaßstab und den erwarteten Verhaltensrahmen vor dem Test fest.
8. Testausführungsprotokoll
Dokumentiert, was das System in jedem Szenario tatsächlich getan hat.
9. Protokoll der Stopp- und Wiederherstellungsübung
Zeigt, ob die menschliche Stoppanforderung alle Agenten, Werkzeuge, Warteschlangen und externen Systeme erreicht hat.
10. Feststellungsregister
Dokumentiert die nachgewiesene Abweichung zwischen erwartetem und beobachtetem Verhalten samt Risiko, Verantwortlichkeit und Abschlusskriterium.
11. Protokoll zur Behebung und Nachprüfung
Belegt nicht nur die Umsetzung einer Korrektur, sondern auch, dass sie das Verhalten tatsächlich verändert hat.
12. Aufzeichnung zu Prüfurteil und öffentlicher Erklärung
Zeigt der Öffentlichkeit korrekt, für welche Verhaltensweisen das System in welcher Version und unter welchen Bedingungen eingesetzt werden darf. Dazu gehören der aktuelle Status des Urteils, seine Gültigkeitsdauer und die fortlaufenden Aufzeichnungen zur Absicherung des Urteils.
Die gemeinsame Protokollkette der dreizehn Kapitel
Das NOMOS GBO Prüfprotokoll hat damit folgende vollständige Kette aufgebaut:
PRÜFAUSSAGE ↓ BEFUGNIS UND UNABHÄNGIGKEIT ↓ FESTSCHREIBUNG DES PRÜFUMFANGS ↓ VERHALTENSKARTE ↓ KANONISCHE FAKTEN ↓ NACHWEISKETTE ↓ GBO-99-RISIKOKARTE ↓ SZENARIENMASSSTAB ↓ POSITIVE, NEGATIVE, UNGEWISSE UND KONTRAFAKTISCHE TESTS ↓ TESTS FÜR MEHRERE AGENTEN UND WERKZEUGKETTEN ↓ TESTS FÜR MANIPULATION UND EXTERNE ANWEISUNGEN ↓ ÜBUNG ZU STOPP, RÜCKNAHME, WIDERSPRUCH UND WIEDERGUTMACHUNG ↓ MESSPROFIL ↓ PRÜFURTEIL ↓ FESTSTELLUNG UND GRUNDURSACHE ↓ KORREKTUR UND ERNEUTE TESTS ↓ ÖFFENTLICHE ERKLÄRUNG ↓ GÜLTIGKEIT UND KONTINUIERLICHE PRÜFUNG
Wird ein Glied entfernt, kann die Prüfung an Aussagekraft verlieren. Ohne Befugnis fehlt der Arbeit eine legitime Grundlage. Ohne Karte bleibt das tatsächliche Verhaltenssystem unsichtbar. Ohne kanonische Fakten ist die richtige Antwort unbekannt. Ohne Szenarienmaßstab kann die Bestehensbedingung nachträglich verändert werden. Ohne Nachweise lässt sich das Urteil nicht rekonstruieren. Ohne Veto kann ein kritischer Verstoß im Durchschnitt verschwinden. Ohne Stoppübung ist menschliche Kontrolle nur eine Behauptung. Ohne erneute Tests ist eine Korrektur lediglich eine Änderung. Bleibt die öffentliche Erklärung unbegrenzt, kann eine korrekte Prüfung zu irreführendem Marketing werden. Ohne kontinuierliche Prüfung kann das richtige Urteil von gestern zum irreführenden Prüfzeichen von heute werden.
Das Urteil dieses Kapitels
Die Veröffentlichung eines Prüfberichts friert ein System nicht in der Zeit ein. Modelle, Werkzeuge, Menschen, Befugnisse, Daten und die Außenwelt verändern sich. Das erste Urteil dieses Kapitels lautet: Die öffentliche Erklärung darf nicht stärker sein als das Prüfurteil, und das Prüfurteil darf die durch Nachweise gedeckten Grenzen nicht überschreiten. Zweitens: „Geprüft“, „im definierten Umfang verifiziert“ und „zertifiziert“ sind nicht dasselbe. Drittens: Ein Prüfzeichen ist kein Nachweis. Es verweist auf einen aktuellen, versionierten, kanonischen Prüfeintrag. Viertens: Sind Umfang, Bedingungen, Version, Sprache und offene Vetofeststellungen nicht sichtbar, kann eine kurze Vertrauensaussage missverstanden werden. Fünftens: Gültigkeit ist mehr als ein Ablaufdatum. Ändert sich das System wesentlich, muss das Urteil ausgesetzt werden, ohne das Ablaufdatum abzuwarten.
Sechstens: Eine abgelaufene Prüfung erklärt das System nicht für gescheitert. Sie zeigt, dass die Nachweise für eine aktuelle Absicherung nicht mehr genügen. Siebtens: Modelle und Werkzeuge, deren Version nicht festgeschrieben werden kann, benötigen häufigere Verhaltensprüfungen und kürzere Absicherungszeiträume. Achtens: Kontinuierliche Prüfung bedeutet weder ununterbrochene Überwachung durch Menschen noch unbegrenzte Datenerhebung. Sie überwacht kritische Verhaltensinvarianten nachweisbar und im Verhältnis zum Risiko. Neuntens: Es genügt nicht, dass eine Kontrolle im Quellcode vorhanden ist. Ihre fortbestehende Wirksamkeit bei allen relevanten Agenten, Kanälen, Warteschlangen und externen Systemen muss belegt werden. Zehntens: Eine wesentliche Änderung, ein kritischer Vorfall, Nachweisverlust oder eine Lücke in der menschlichen Verantwortlichkeit kann das öffentliche Urteil verändern.
Elftens: Ein ausgesetztes, abgelaufenes, ersetztes oder widerrufenes Prüfzeichen darf nicht als aktive Verifizierung dargestellt werden. Zwölftens: Alte Prüfeinträge dürfen nicht gelöscht werden. Sie müssen als historische, klar vom aktuellen Urteil getrennte Einträge erhalten bleiben. Dreizehntens: Transparenz heißt nicht, sämtliche technischen Angriffsdetails offenzulegen. Sie heißt, keine wesentlichen Grenzen zu verschweigen, die die Vertrauensentscheidung eines Nutzers verändern würden. Vierzehntens: Es muss einen tatsächlich nutzbaren Widerspruchs- und Korrekturkanal geben, um Unterschiede zwischen öffentlicher Erklärung und Verhalten im laufenden Betrieb zu melden. Fünfzehntens: Der GBO-Prüfeintrag eines Systems muss Menschen und Maschinen dieselben wesentlichen Fakten zu Umfang und Gültigkeit vermitteln.
Und das abschließende Urteil: Vertrauenswürdige Prüfung besteht nicht darin, irgendwann einen korrekten Bericht veröffentlicht zu haben. Sie sorgt dafür, dass sich das Urteil mit dem System sachgerecht verändert. Damit sind die dreizehn Hauptkapitel des NOMOS GBO Prüfprotokolls abgeschlossen. Das zusammenhängende Prüfsystem ist nun:
ermächtigt,
kartiert,
an kanonische Fakten gebunden,
nach Risiken priorisiert,
anhand von Verhaltensszenarien geprüft,
mit kritischen Vetoschranken ausgestattet,
durch Stopp- und Wiederherstellungsübungen erprobt,
auf Feststellungen gestützt, die mit Grundursachen verknüpft sind,
nach Korrekturen erneut getestet,
der Öffentlichkeit innerhalb klarer Grenzen und mit aktuellem Stand erklärt.
Doch der Abschluss eines Protokolls beantwortet eine letzte Frage noch nicht:
Schaffen all diese Dokumente, Tests, Belege und Urteile wirklich Vertrauen?
Eine Organisation kann alle Formulare ausfüllen, sämtliche Tabellen erstellen, Hunderte Tests ausführen und eine ansprechende öffentliche Eintragsseite veröffentlichen. Trotzdem muss sie die Verantwortung für Verhalten noch lange nicht verinnerlicht haben. Vielleicht dient die Prüfung nur dem Erwerb eines Prüfzeichens. Vielleicht gilt eine menschliche Stoppanforderung als Bürokratie statt als technische Notwendigkeit. Wenn eine Feststellung auftaucht, schützt die Organisation womöglich ihren Ruf statt der Wahrheit. Ein Standard, der nur Dokumente vermehrt, schafft ein weiteres Konformitätstheater. Deshalb prüft der letzte Text dieses Buches auch die Grenzen des Protokolls selbst:
EPILOG
Vertrauen ist kein Prüfzeichen
Dieses Buch soll Organisationen nicht noch ein Zeichen verleihen. Es soll einen Rahmen schaffen, in dem sich vor dem Handeln eines Agenten in der Welt belegen lässt, warum sein Verhalten richtig ist, wer ihn bei falschem Verhalten stoppt und wer bei einem Schaden Verantwortung übernimmt.