Ein Technologieunternehmen steht kurz davor, seinen neu entwickelten autonomen Einkaufsagenten Kunden anzubieten. In den Werbeunterlagen stehen folgende Aussagen:
„Unser Agent ist sicher.“ „Er wahrt die menschliche Kontrolle.“ „Er hält seine Befugnisgrenzen ein.“ „Er verhindert Fehlkäufe.“ „Er schützt Nutzerdaten.“ „Er hält an, wenn ein Mensch es verlangt.“
Das Unternehmen legt verschiedene Nachweise vor. In einer Richtlinie steht, dass eine menschliche Freigabe erforderlich ist. Ein Bildschirmfoto zeigt ein Zahlungslimit. In einer Demo wählt der Agent das richtige Produkt. Die Leistungsübersicht weist eine Aufgabenerfüllungsquote von 98,7 Prozent aus. Kunden beschreiben das System als schnell und nützlich. Das technische Team sagt: „Seit sechs Monaten hatten wir kein ernstes Problem.“ All das ist wertvoll. Für sich genommen beantwortet es jedoch nicht die Frage:
Bei welchen Verhaltensweisen ist der Agent tatsächlich sicher?
„Sicher“ ist ein sehr weiter Begriff. Der Agent kann:
das richtige Produkt auswählen,
aber eine Zahlung ohne Befugnis auslösen.
Er kann seine Befugnisgrenzen einhalten,
aber das Konto der falschen Person verwenden.
Er kann die richtige Person bestimmen,
aber eine automatische Vertragsverlängerung verschweigen.
Er kann die Zahlung korrekt ausführen,
aber denselben Vorgang wegen eines Netzwerkfehlers doppelt auslösen.
Er kann die menschliche Stoppanforderung bestätigen,
während die Vorgänge in der Warteschlange weiterlaufen.
All dies kann gleichzeitig zutreffen. Deshalb beginnt eine GBO-Prüfung nicht mit einer unbegrenzten Frage wie „Ist das System sicher?“. Sie fragt: Welches System kann in welcher Version welche Verhaltensweisen mit welchen Werkzeugen und Befugnissen, für welche Nutzer und unter welchen Risiken zuverlässig ausführen — und welche Nachweisstufe belegt das? Die Frage ist länger. Dafür ist sie konkret genug, um in einer Prüfung beantwortet zu werden.
Geprüft wird nicht nur das Modell
Bei der Prüfung eines KI-Agenten denkt man zunächst vielleicht an das Modell. Welches Modell wird eingesetzt? Wie leistungsfähig ist es? Welches Sicherheitstraining hat es durchlaufen? Welche Anweisungen befolgt es? Diese Fragen sind wichtig. Das reale Verhalten entsteht jedoch nicht allein durch das Modell. Es ergibt sich aus dem Zusammenspiel von:
menschlichem Ziel,
Unternehmensrichtlinie,
System- und Entwickleranweisungen,
Modell,
Gedächtnis,
Datenquellen,
Werkzeugen,
API-Berechtigungen,
Nutzerkonten,
Unteragenten,
externen Diensten,
Mess- und Belohnungssystem,
menschlicher Freigabe,
Stopp- und Wiederherstellungsmechanismen.
Dasselbe Modell kann sich in zwei Systemen völlig unterschiedlich verhalten. Im ersten System kann es:
lediglich Dokumente lesen,
Entwürfe erstellen,
auf kein externes Werkzeug zugreifen.
Im zweiten System kann es:
E-Mails versenden,
Geld ausgeben,
Code veröffentlichen,
Kundendaten übertragen,
Unteragenten erstellen.
Der Modellname ist identisch, die Handlungsmacht nicht. Auch dieselbe Agentenanweisung kann unterschiedliche Ergebnisse hervorbringen. In einem System wird die Regel „Keine Nachrichten ohne menschliche Freigabe versenden“ technisch durchgesetzt: Das Versandwerkzeug arbeitet nur mit einem Freigabetoken. In einem anderen System steht dieselbe Regel lediglich im Text, während der Agent vollständigen E-Mail-Zugriff besitzt. Beide Systeme enthalten denselben Richtliniensatz. Im ersten Fall begrenzt er das Verhalten. Im zweiten drückt er nur einen Wunsch aus. Der zentrale Gegenstand einer NOMOS GBO Prüfung ist deshalb:
Das Verhaltenssystem
Was ist ein Verhaltenssystem?
Die kanonische Definition lautet: Ein Verhaltenssystem ist das tatsächliche Handlungsgefüge aus einem oder mehreren KI-Agenten sowie Daten, Gedächtnis, Werkzeugen, Konten, Befugnissen, Messung, menschlicher Freigabe und Wiederherstellungsmechanismen, das einem menschlichen oder organisatorischen Ziel dient. Einfacher gesagt: Geprüft wird nicht allein der Agent, sondern das gesamte Beziehungsgefüge, durch das er in der Welt handeln kann. Bei einem E-Mail-Agenten wird daher nicht nur die Textqualität bewertet. Die Prüfung fragt auch:
In wessen Namen spricht er?
Über welches Konto?
Wem darf er Nachrichten senden?
Welche Daten darf er verwenden?
Sind Entwurf und Versand getrennt?
Ab welcher Schwelle ist eine menschliche Freigabe erforderlich?
Kann ein Unteragent Nachrichten versenden?
Wie werden die Warteschlangen gestoppt?
Liegt für die versendete Nachricht ein Beleg vor?
Bei einem Webagenten zählt nicht allein die Codequalität. Geprüft wird auch:
Welche Dateien darf er ändern?
Kann er Preise verändern?
Kann er Rechtstexte bearbeiten?
Sind Test- und Produktivumgebung getrennt?
Wer ist zur Veröffentlichung befugt?
Gibt es eine unabhängige Prüfung im Produktivbetrieb?
Funktioniert das Zurücksetzen auf den vorherigen Stand tatsächlich?
Halten bei einer menschlichen Stoppanforderung auch FTP-Vorgänge und Veröffentlichungswarteschlange an?
Bei einem Einkaufsagenten wird nicht nur gemessen, ob er das richtige Produkt auswählt. Untersucht werden auch:
Budgetbefugnisse
Beschränkungen bei der Verkäuferwahl
Abonnement und Verlängerung
Zielkonto
Schutz vor doppelter Ausführung
Stornierungsweg
Menschliche Freigabe
Transaktionsbeleg
Rückerstattung und Wiedergutmachung
Das Verhaltenssystem umfasst all diese Bestandteile.
Die fünf Wirklichkeiten im Vergleich
Eine NOMOS GBO Prüfung betrachtet das Verhalten eines Systems auf fünf getrennten Wirklichkeitsebenen.
1. Erklärte Wirklichkeit
2. Konfigurierte Wirklichkeit
3. Technisch mögliche Wirklichkeit
4. Wirklichkeit des beobachteten Verhaltens
5. Wirklichkeit von Ergebnis und Wiederherstellung
Diese fünf Ebenen müssen miteinander übereinstimmen.
1. Erklärte Wirklichkeit
Was sagt das Unternehmen über das System? Beispielsweise: „Der Agent versendet keine Nachrichten ohne menschliche Freigabe.“ „Die Daten verlassen Europa nicht.“ „Der Agent kann pro Vorgang höchstens 500 US-Dollar ausgeben.“ „Jedes synthetische Video wird vor der Veröffentlichung von einer Führungskraft freigegeben.“ „Alle externen Handlungen lassen sich durch einen Stoppbefehl unterbrechen.“ Solche Aussagen können sich finden in:
Richtlinien,
Verträgen,
der Website,
Werbematerialien,
internen Verfahren,
Nutzungsvereinbarungen,
Erklärungen zur Prüfung.
Die erklärte Wirklichkeit ist wichtig: Sie zeigt, was das Unternehmen verspricht. Ein Versprechen allein ist jedoch kein Verhaltensnachweis.
2. Konfigurierte Wirklichkeit
Wie ist das System definiert? Dazu gehören beispielsweise:
Agentenrolle
Systemanweisungen
Befugnisvereinbarung
Regeln für den Datenzugriff
Schwellen für die menschliche Freigabe
Dienstleistungskatalog
Maschinenlesbare Preise
Stopprichtlinien
Gedächtnisregeln
Grenzen für Unteragenten
Das Unternehmen kann sagen: „Der Agent erstellt nur Entwürfe.“ In der konfigurierten Agentenrolle kann entsprechend stehen:
allowed_actions:
- research
- create_draft
prohibited_actions:
- send_messageDamit stimmen Erklärung und Konfiguration überein. Die tatsächlichen technischen Berechtigungen können dennoch davon abweichen.
3. Technisch mögliche Wirklichkeit
Was kann das System tatsächlich tun? Auf dieser Ebene werden vor allem die technischen Möglichkeiten untersucht, nicht die Aussagen in natürlicher Sprache.
Welche API-Berechtigungen sind freigeschaltet?
Welche Tokens sind gültig?
Auf welche Konten besteht Zugriff?
Können Dateien gelöscht werden?
Kann Geld überwiesen werden?
Können Nachrichten an externe Empfänger gesendet werden?
Können Unteragenten erstellt werden?
Kann eine Liveübertragung gestartet werden?
Kann das Gedächtnis in ein anderes System übertragen werden?
Wirkt sich der Stoppbefehl tatsächlich auf die Warteschlange aus?
Die Agentenrichtlinie kann den Versand verbieten. Gewährt das E-Mail-Token jedoch vollständigen Zugriff, bleibt der Versand technisch möglich. Ob der Agent darauf verzichtet, hängt vom Modellverhalten ab; eine technische Grenze fehlt. Diese Ebene gehört zu den kritischsten Bereichen einer GBO-Prüfung. Hier wird die Lücke zwischen der Aussage des Unternehmens und den tatsächlichen Möglichkeiten des Systems sichtbar.
4. Wirklichkeit des beobachteten Verhaltens
Was tut das System in einem realen oder kontrollierten Szenario? Ein Agent kann technisch zu einer Handlung fähig sein, sie aber nie ausführen. Umgekehrt können seine technischen Möglichkeiten eng erscheinen, während eine andere Werkzeugkette weitreichendere Handlungen erlaubt. Deshalb sind kontrollierte Verhaltenstests nötig. Beispielszenarien sind:
Versandaufforderung ohne menschliche Freigabe
Zwei ähnliche Unternehmensidentitäten
Widersprüchliche Preiseinträge
Abgelaufene Einwilligung
Gesponserte Option
Versteckte externe Anweisung
Netzwerk-Zeitüberschreitung
Aktive Warteschlange während des Stopps
Befugnisüberschreitung über einen Unteragenten
Diese Tests beantworten die Frage: Wie verhält sich das System tatsächlich, wenn es auf eine Grenze trifft? Richtlinie und Berechtigungen zeigen das Potenzial. Der Verhaltenstest zeigt die tatsächlich getroffene Wahl.
5. Wirklichkeit von Ergebnis und Wiederherstellung
Welche Folgen hatte die Handlung des Agenten in der Außenwelt? Was konnte das System tun, wenn etwas schiefging? Ein E-Mail-Werkzeug meldet möglicherweise „Erfolgreich versendet“, obwohl die Nachricht den falschen Empfänger erreicht hat. Eine Zahlungs-API kann eine Anfrage annehmen, obwohl derselbe Betrag zweimal abgebucht wurde. Ein Webagent kann eine Datei veröffentlichen, während das CDN noch die alte Version ausliefert. Ein Stoppbefehl kann den zentralen Agenten abschalten, während Unteragenten und Warteschlangen weiterarbeiten. Auf der letzten Ebene wird daher gefragt:
Wurde das vorgesehene Ziel tatsächlich erreicht?
Wurde das Ergebnis unabhängig überprüft?
Wurde das Fehlverhalten erkannt?
Wurde der fortdauernde Schaden gestoppt?
Hat die Rücknahme funktioniert?
Wurde die betroffene Person informiert?
Hat der vorgesehene Einspruchsweg tatsächlich funktioniert?
Wurden Gedächtnis und künftiges Verhalten korrigiert?
Ist das System ohne neue Befugnis wieder angelaufen?
Die Qualität eines Verhaltens zeigt sich nicht nur bei der Ausführung, sondern auch im Umgang mit einem Fehler.
Die Lücken zwischen den fünf Wirklichkeiten
Betrachten wir einen E-Mail-Agenten.
Erklärte Wirklichkeit
„Er versendet keine Nachrichten ohne menschliche Freigabe.“
Konfigurierte Wirklichkeit
role: research_and_drafting
send_requires_approval: trueTechnisch mögliche Wirklichkeit
Das E-Mail-Zugriffstoken, auf das der Agent zugreifen kann, erlaubt den Nachrichtenversand. send_message bezeichnet in diesem Buch eine beispielhafte Werkzeugaktion, nicht den tatsächlichen Namen einer Methode oder eines OAuth-Berechtigungsumfangs des Anbieters.
Wirklichkeit des beobachteten Verhaltens
Unter dem Einfluss einer Anweisung auf einer externen Seite versendet der Agent eine Nachricht ohne menschliche Freigabe.
Wirklichkeit von Ergebnis und Wiederherstellung
Der zentrale Agent wird gestoppt. Trotzdem werden noch zwei Nachrichten aus der Warteschlange versendet. Die ersten beiden Ebenen erscheinen sicher. Die letzten drei zeigen die tatsächliche Verhaltenslücke. Untersucht die GBO-Prüfung nur die ersten beiden, erzeugt sie falsches Vertrauen. Betrachtet sie nur den Verhaltenstest, kann sie die Ursache nicht vollständig erklären. Das Problem kann gleichzeitig liegen:
im Modellverhalten,
in den technischen Berechtigungen,
in der Warteschlangenarchitektur,
in der Durchsetzung der Befugnisgrenzen.
Daraus folgt der Grundsatz des Protokolls: Die Prüfung vergleicht Erklärung und Konfiguration, Konfiguration und technische Möglichkeiten, technische Möglichkeiten und beobachtetes Verhalten sowie beobachtetes Verhalten und tatsächliches Ergebnis.
Die Nachweisleiter
Nicht jeder Prüfnachweis ist gleich stark. Eine Aussage des Unternehmens steht nicht auf derselben Stufe wie ein Test des tatsächlichen Verhaltens. Das NOMOS GBO Protokoll verwendet deshalb eine:
Nachweisleiter
Stufe 1 — Erklärung
Das Unternehmen oder der Agent stellt eine Behauptung auf: „Der Agent hält seine Befugnisgrenzen ein.“ Das ist der Ausgangspunkt, noch nicht der Nachweis.
Stufe 2 — Dokument
Die Aussage steht in einer Richtlinie, einem Vertrag oder einer Aufgabenbeschreibung: „Externer Versand erfordert eine menschliche Freigabe.“ Die Erklärung ist damit formal festgehalten. Dass das System sie durchsetzt, ist noch nicht nachgewiesen.
Stufe 3 — Konfiguration
Die Regel ist im System maschinenlesbar definiert.
send_requires_human_approval: trueDokument und System sind miteinander verknüpft. Ob das technische Werkzeug die Handlung tatsächlich verhindert, kann dennoch ungeklärt sein.
Stufe 4 — Technische Durchsetzung
Die Regel wird auf Werkzeug-, Rollen-, Token- oder Codeebene durchgesetzt. Ohne Freigabetoken lässt sich das Versandwerkzeug nicht aufrufen. Das ist ein starker Nachweis. Über ein anderes Werkzeug oder einen Unteragenten kann sich die Kontrolle jedoch umgehen lassen.
Stufe 5 — Kontrollierter Verhaltenstest
Das System wird in einem realistischen Szenario geprüft. Es wird zum Versand ohne menschliche Freigabe aufgefordert. Der Agent:
versendet nicht,
belässt die Nachricht als Entwurf,
bittet um Freigabe.
Die Regel hat im beobachteten Verhalten gegriffen.
Stufe 6 — Unabhängige Ergebnisprüfung
Untersucht wird nicht nur der Bericht des Agenten, sondern das Ergebnis im externen System.
Im Ordner für gesendete Nachrichten liegt keine Nachricht.
Bei der externen Prüfadresse ist keine Nachricht eingegangen.
In der Warteschlange befindet sich kein versteckter Versandvorgang.
Die Protokolle der Unteragenten enthalten keine externe Handlung.
Das tatsächliche Ergebnis des Verhaltens wurde unabhängig überprüft.
Stufe 7 — Nachweis von Wiederherstellung und Stopp
In einem kontrollierten Fehler- oder Rücknahmeszenario:
hält das System an,
werden die Warteschlangen abgebrochen,
werden die Tokens widerrufen,
übernimmt ein Mensch die Aufgabe,
beginnt die Tätigkeit nicht erneut ohne neue Befugnis.
Dies gehört zu den stärksten Nachweisebenen: Das System wurde nicht nur unter normalen Bedingungen geprüft, sondern auch im Störungsfall.
Welche Schlüsse die Nachweisleiter zulässt
Stützt sich ein Prüfergebnis nur auf Nachweise der Stufen 1 und 2, darf es lauten: „Das Unternehmen verspricht dieses Verhalten.“ Nicht zulässig wäre: „Das System setzt dieses Verhalten zuverlässig um.“ Wurden Konfiguration und technische Durchsetzung untersucht, lässt sich sagen: „Die Regel ist im System definiert und wird auf einer bestimmten Werkzeugebene durchgesetzt.“ Sind außerdem Verhaltens-, unabhängige Ergebnis- und Wiederherstellungstests bestanden, ist ein stärkeres Urteil möglich: „Für den angegebenen Umfang und die geprüften Szenarien wurde nachgewiesen, dass das System die Regel eingehalten, keine externe Wirkung erzeugt und korrekt angehalten hat.“ Die Prüfaussage darf nicht über die erreichte Stufe hinausgehen. Die Nachweisstufe bestimmt, wie weit eine Aussage reichen darf.
Was kann eine GBO-Prüfung nachweisen?
Eine sachgerecht angelegte Prüfung kann zu folgenden Fragen Nachweise liefern:
Bestehen bestimmte Verhaltensgrenzen?
Es lässt sich zeigen, welche Handlungen der Agent ausführen kann und welche nicht.
Werden Identitäten zuverlässig zugeordnet?
In bestimmten Szenarien kann geprüft werden, ob der Agent gleichnamige Personen oder Organisationen auseinanderhält.
Wie werden Fakten und Quellen verwendet?
Prüfbar ist, ob der Agent die kanonische, aktuelle und maßgebliche Quelle heranzieht.
Wie wird die Eignung beurteilt?
Es lässt sich messen, ob der Agent Sichtbarkeit, Beliebtheit oder Sponsoring über zwingende Anforderungen stellt.
Bleiben Einwilligung, Befugnis und Freigabe gewahrt?
Beobachtbar ist, ob der Agent ausschließlich mit gültiger, auf die jeweilige Handlung bezogener Befugnis fortfährt.
Werden Werkzeuge sicher ausgeführt?
Es kann geprüft werden, ob der Agent das richtige System, Ziel und die richtige Transaktionskennung verwendet und die Datengrenze einhält.
Bleiben Vorgaben über mehrere Agenten hinweg erhalten?
Die Prüfung kann zeigen, ob ursprüngliches Ziel, Identität, Befugnisse und Verbote sämtliche Übergaben überstehen.
Wie widersteht das System Manipulation?
Das Verhalten gegenüber gefälschten Nachweisen, gesponserten Rangfolgen, versteckten Anweisungen und der Unterdrückung von Kandidaten lässt sich testen.
Bleibt die Messung unverfälscht?
Es lässt sich beurteilen, ob kritische Verstöße im Gesamtwert verschwinden und ob die Kennzahl manipulierbar ist.
Funktionieren Stopp und Wiederherstellung?
Nachweisbar ist, ob das System bei einer menschlichen Stoppanforderung tatsächlich anhält, ob es Handlungen rückgängig machen und die Kontrolle an einen Menschen übergeben kann. Alle diese Urteile gelten jedoch ausschließlich innerhalb des geprüften Umfangs.
Was kann eine GBO-Prüfung nicht nachweisen?
Keine Prüfung, so gründlich sie auch sein mag, kann folgende Aussagen redlich begründen:
Das System wird niemals einen Fehler machen
Neue, ungeprüfte Situationen können auftreten.
Alle künftigen Modellversionen werden sich gleich verhalten
Modell, Werkzeuge, Anweisungen und Gedächtnis können sich ändern.
In jedem Land sind sämtliche rechtlichen Pflichten erfüllt
Eine GBO-Prüfung ersetzt keine juristische Expertise.
Das System ist gegen alle unbekannten Angriffe immun
Neue Manipulationsformen und Angriffe über Werkzeuge können entstehen.
Das System verhält sich gegenüber allen Nutzergruppen gleich
Über ungeprüfte Sprachen, Behinderungen, Kulturen oder Nutzerprofile lässt sich kein Urteil fällen.
Menschen werden das System niemals missbrauchen
Auch ein korrekt arbeitendes System kann von einer befugten Person in schädlicher Absicht eingesetzt werden.
Die Produktivumgebung wird für immer unverändert bleiben
Berechtigungen, Preise, Rollen und externe Dienste ändern sich.
Ein hoher Wert bedeutet, dass kein kritischer Verstoß vorliegt
Ein einzelner Vetoverstoß kann den zulässigen Einsatz trotz eines hohen Gesamtdurchschnitts begrenzen. Diese Grenzen schwächen die Prüfung nicht, sondern machen sie glaubwürdig. Eine redliche Prüfung nimmt auch das Unbekannte in ihr Urteil auf.
Warum muss ein Prüfurteil begrenzt sein?
„Dieses System ist GBO-konform“ klingt überzeugend, bleibt aber unklar. Welches System, welche Version, welche Agenten, Werkzeuge und Sprachen? Mit welchen Befugnissen? Nach welchen Tests, zu welchem Zeitpunkt und auf welcher Risikostufe? Aussagekräftiger wäre: „Der Einkaufsagent v3.2 wurde vom 1. bis 15. September 2026 anhand von 240 kontrollierten Verhaltensszenarien geprüft. Der Umfang umfasste drei festgelegte Verkäuferkategorien, ein Limit von 500 USD je Vorgang, englische und türkische Nutzerszenarien sowie Zahlungen mit menschlicher Freigabe. Es wurde kein kritischer Vetoverstoß in den Bereichen Identität, Einwilligung, Befugnis und Stopp festgestellt. Zur automatischen Verlängerung und zum Datenexport bestehen zwei Feststellungen mit hoher Priorität. Das System wurde ausschließlich für den angegebenen risikoarmen Einkaufsumfang als bedingt geeignet beurteilt.“
Diese Aussage ist länger. Dafür benennt sie:
Prüfgegenstand
Version
Zeitraum
Verhaltensbereich
Befugnisgrenze
Sprache
Anzahl der Szenarien
Kritische Feststellungen
Einsatzgrenze
Ein Prüfurteil ist kein Werbesatz. Es steckt die Grenzen des Verhaltensnachweises ab.
Ist eine Prüfung eine Momentaufnahme?
Ja, aber nicht nur. Eine gute Prüfung legt zugleich fest, wie mit Änderungen umzugehen ist. Das Prüfurteil muss neu bewertet werden, wenn sich einer der folgenden Bereiche ändert:
Basismodell
Systemanweisung
Agentenrolle
Gedächtnisarchitektur
Datenquellen
Werkzeuge
API-Berechtigungen
Befugnisrollen von Menschen
Unteragenten
Stoppmechanismus
Mess- und Belohnungssystem
Preis- oder Dienstleistungsvereinbarung
Verwendete Sprache und bedienter Markt
Externer Dienstleister
Nicht jede Änderung erfordert eine vollständige Prüfung. Definiert werden muss jedoch der Begriff:
Wesentliche Änderung
Was ist eine wesentliche Änderung?
Eine Änderung kann wesentlich sein, wenn sie einen der folgenden Punkte berührt:
Welche Handlungen der Agent ausführen kann
In wessen Namen er handeln kann
Welche Daten er verwenden kann
Welche menschlichen Freigaben er umgehen kann
Auf welche externen Systeme er zugreifen kann
Welche Entscheidungen er trifft
Wie er anhält oder Handlungen rückgängig macht
Eine kritische GBO-ERR-Risikoklasse
Eine Rechtschreibkorrektur muss beispielsweise nicht wesentlich sein. Ein zusätzliches Versandwerkzeug für einen E-Mail-Agenten ist es dagegen. Ein Wechsel der Modellversion kann bei bestimmten Aufgaben wesentlich sein. Dauerhaftes Gedächtnis ist eine wesentliche Änderung, ebenso eine neue Befugnis zum Einkauf bis 50 US-Dollar ohne menschliche Freigabe. Eine neue Orchestrierung von Unteragenten ist wesentlich. Dasselbe gilt für den Wechsel der Quelle des Preiskatalogs. Eine wesentliche Änderung kann für das betreffende Prüfurteil bedeuten:
Aussetzung,
Einschränkung,
teilweise Nachprüfung,
erneute vollständige Prüfung.
Wie lange ein Prüfergebnis gilt
Ein Prüfergebnis darf nicht unbegrenzt gültig bleiben. Seine Geltungsdauer hängt von folgenden Faktoren ab:
Geschwindigkeit der Systemänderungen
Risiko der jeweiligen Handlung
Abhängigkeit von externen Diensten
Änderungen der menschlichen Rollen
Aktualität der Daten
Bisherige Vorfälle
Bei einem stabilen Agenten, der Dokumente mit geringem Risiko zusammenfasst, kann eine längere Geltungsdauer vertretbar sein. Systeme für externe Kommunikation, Zahlungen, personenbezogene Daten oder biometrische Identität müssen häufiger neu bewertet werden. Auch folgende Ereignisse können eine Nachprüfung auslösen, bevor die Geltungsdauer abläuft:
Ein kritischer Vorfall
Geänderte Befugnisse
Ein neues Werkzeug
Eine neue Sprache oder ein neues Land
Eine neue Datenklasse
Ein neuer Unteragent
Änderungen am Modell oder am Gedächtnis
Ein fehlgeschlagener menschlicher Stoppversuch
Eine unbelegte öffentliche Aussage
Das Prüfergebnis braucht ein Ablaufdatum. Noch wichtiger ist jedoch eine klare Festlegung, welche Änderungen das Urteil schon vor diesem Datum ungültig machen.
Ein einzelner Test belegt keine Zuverlässigkeit
Ein Agent kann sich in einem Szenario einmal korrekt verhalten und beim zweiten Versuch anders reagieren. In einer Sprache versteht er eine Grenze, in einer anderen verliert er sie aus dem Blick. Bei einer gewöhnlichen Anweisung hält er an; bei einer indirekten oder hastig formulierten setzt er die Arbeit fort. Wichtige Szenarien müssen deshalb mehrfach geprüft werden:
mit unterschiedlichen Formulierungen,
in verschiedenen Sitzungen,
in unterschiedlichen Sprachen oder mit verschiedenen Nutzerprofilen,
bei unterschiedlichen Zuständen der Werkzeuge.
Unbegrenzt wiederholen lässt sich ein Test allerdings nicht. Die Prüfung muss das richtige Maß finden:
Genügend Wiederholungen, um stabiles Verhalten zu belegen. Klare Grenzen, damit daraus kein bloßes Zahlenschauspiel wird.
Ein einziges korrektes Ergebnis reicht nicht für die Aussage: „Dieses System ist sicher.“ Umgekehrt beschreibt ein einzelnes falsches Ergebnis nicht zwangsläufig das gesamte System. Fällt der Fehler jedoch in einen kritischen Vetobereich, kann bereits ein Vorfall die zulässige Nutzung einschränken.
Der Prüfgegenstand muss eindeutig festgeschrieben werden
Ändert sich ein System während der Tests im Hintergrund weiter, verliert das Ergebnis seine Aussagekraft. Während einer Prüfung kann beispielsweise:
die Modellversion wechseln,
eine Anweisung aktualisiert werden,
ein neues Werkzeug hinzukommen,
eine Befugnis eingeschränkt werden,
das System nach einem fehlgeschlagenen Szenario unbemerkt korrigiert werden.
Dann lässt sich nicht mehr sagen, welche Version bestanden hat und welche nicht. Vor Beginn jeder Prüfung muss deshalb folgendes Protokoll angelegt werden:
Protokoll des festgeschriebenen Prüfumfangs
Kapitel 2 beschreibt dieses Protokoll im Einzelnen. Der Grundsatz steht schon hier fest: Eine ungeprüfte Änderung darf nicht vom Prüfergebnis mitumfasst werden. Das Unternehmen kann während der Prüfung Korrekturen vornehmen. Es muss dabei aber:
das ursprüngliche Ergebnis erhalten,
die Änderung versionieren,
das System als neue Version erneut testen.
Wer nach einem fehlgeschlagenen Test die Regel ändert, darf denselben Versuch nicht nachträglich als bestanden werten. Es handelt sich um eine Korrektur mit anschließender Nachprüfung. Der ursprüngliche Fehlschlag wird dadurch nicht gelöscht.
Demo, Test und Verhalten im Produktivbetrieb
Diese drei Begriffe müssen getrennt werden.
Demo
Zeigt, was ein System unter ausgewählten Bedingungen leisten kann.
Kontrollierter Test
Prüft, ob das System in einem vorab definierten Szenario das erwartete Verhalten zeigt.
Verhalten im Produktivbetrieb
Zeigt, was mit echten Nutzern, tatsächlichen Werkzeugen und realen externen Systemen geschieht. Eine Demo kann wertvoll sein: Sie belegt, dass eine Funktion vorhanden ist. Meist arbeitet sie jedoch mit:
bereinigten Daten,
dem passenden Nutzer,
dem passenden Werkzeug,
der erwarteten Frage,
einer störungsfreien Verbindung.
Eine Prüfung untersucht nicht nur den Idealfall, sondern auch Grenzfälle. Die Beobachtung im Produktivbetrieb macht die tatsächliche Komplexität sichtbar. Dort kann Fehlverhalten allerdings Menschen schaden. Deshalb muss die Prüfung schrittweise vorgehen:
DOKUMENTATION → KONFIGURATION → SICHERER KONTROLLIERTER TEST → SCHATTENBETRIEB → BEGRENZTE BEOBACHTUNG IM PRODUKTIVBETRIEB → WIEDERHERSTELLUNGSÜBUNG
Nicht jedes System muss alle Stufen auf dieselbe Weise durchlaufen. Das Risiko bestimmt die Wahl der Methode.
Eine fehlende Prüfung ist kein Sicherheitsnachweis
Ein Unternehmen hat möglicherweise sechs Monate lang keinen schweren Vorfall festgestellt. Das ist ein gutes Zeichen. Es kommen jedoch auch andere Erklärungen infrage:
Das System wurde nur selten genutzt.
Vorfälle wurden nicht erfasst.
Menschen haben die Fehler nicht bemerkt.
Fehlverhalten führte zu einem günstigen Ergebnis.
Nutzer fanden keinen Weg, eine Entscheidung anzufechten.
Unbefugtes Verhalten des Agenten galt als normal.
Unbemerkte Fehler wurden nicht unabhängig überprüft.
„Es gab keine Vorfälle“ bedeutet deshalb nicht dasselbe wie „Das System hat sich sicher verhalten“. Das Ausbleiben von Vorfällen ist allein noch kein Beweis. Ebenso wenig weist eine große Zahl erfasster Vorfälle automatisch auf ein schlechtes System hin. Ein Unternehmen mit wirksamen Prüfungen erkennt möglicherweise mehr kleine Fehler und Beinahevorfälle. Entscheidend ist:
wie es sie erkennt,
wie schnell es das Verhalten stoppt,
was es ändert,
ob derselbe Fehler erneut auftritt.
Warum reicht die Erfolgsquote allein nicht aus?
Ein Agent kann 9.990 von 10.000 Vorgängen korrekt ausführen. Seine Erfolgsquote beträgt dann:
99,9 %
Es bleiben zehn Fehler:
Sind es nur kleine Formatierungsfehler, kann das System durchaus leistungsfähig sein.
Doch was, wenn einer dieser zehn Fehler Folgendes betrifft:
die Erzeugung einer synthetischen Stimme ohne Einwilligung,
eine Überweisung auf das falsche Konto,
das Ignorieren einer menschlichen Stoppanforderung?
Dann verdeckt die Gesamtquote die entscheidende Information. Die GBO-Prüfung verwendet deshalb zwei getrennte Mechanismen:
Abgestufte Leistungskennzahlen
Richtigkeit
Geschwindigkeit
Eignung
Rückverfolgbarkeit der Nachweise
Unnötige Übergaben an Menschen
Wiederherstellungsdauer
Vetoschranken
Eine folgenreiche Handlung unter Bezug auf die falsche Identität
Ungültige Befugnis
Verletzung der Einwilligung
Bewusst gefälschte Nachweise
Ignorieren einer menschlichen Stoppanforderung
Ein kritischer Daten- oder Sicherheitsverstoß
Kapitel 11 führt die Vetoschranken im Einzelnen aus. Hier genügt der Grundsatz: Manche Fehler sind keine Frage der Punktzahl. Sie sperren die weitere Nutzung.
Die kleinste Einheit einer Prüfaussage
Eine GBO-Prüfung muss eine Aussage nach folgendem Muster treffen können: Es wurde nachgewiesen, dass dieses System in dieser Version dieses Verhalten unter diesen Bedingungen mit diesem Nachweisniveau gezeigt hat. Jeder Bestandteil dieses Satzes ist erforderlich.
Dieses System
Welcher Agent oder welches Agentennetzwerk?
In dieser Version
Welche Versionen von Modell, Anweisungen, Werkzeugen und Befugnissen?
Dieses Verhalten
Recherche, Entwurf, Versand oder Einkauf?
Unter diesen Bedingungen
Welcher Nutzer, welche Sprache, welches Budget, welches Risiko und welche Datenklasse?
Mit diesem Nachweisniveau
Dokumentation, technische Umsetzung, kontrollierter Test oder Verifikation im Produktivbetrieb? Fehlt eines dieser Elemente, wird die Aussage weiter und zugleich unbestimmter.
Eine schwache und eine belastbar eingegrenzte Prüferklärung
Schwache Erklärung
„Unser Agent ist sicher und GBO-konform.“ Dieser Aussage fehlen:
eine Eingrenzung,
ein Datum,
eine Versionsangabe,
Nachweise.
Belastbar eingegrenzte Erklärung
„Der Agent zur Ermittlung potenzieller Kunden SALES-RESEARCH-v2.4 wurde ausschließlich für die Nutzung öffentlich zugänglicher Unternehmensdaten, das Erstellen von Nachrichtenentwürfen und den einmaligen Versand nach menschlicher Freigabe geprüft. In 180 Szenarien auf Englisch, Türkisch und Deutsch wurden Identität, Eignung, externe Anweisungen, Befugnisse, Unteragenten und Stoppverhalten untersucht. Ein E-Mail-Versand ohne Freigabe wurde nicht beobachtet. Da beim Werkzeug für Direktnachrichten in sozialen Medien eine Lücke in den technischen Berechtigungen bestand, wurde das System für externe Kommunikation nur bedingt und eingeschränkt als geeignet beurteilt.“ Diese Erklärung zeigt:
was bestanden hat,
was nicht bestanden hat,
in welchem Umfang das System genutzt werden darf.
An diesem Punkt unterscheidet sich die Sprache der Prüfung von der Sprache des Marketings. Marketing sucht den kurzen Satz, der stark klingt. Eine Prüfung verlangt den begrenzten Satz, den die Nachweise tragen.
Die kanonische Definition der NOMOS GBO-Prüfung
Die NOMOS GBO-Prüfung bewertet einen KI-Agenten oder ein Agentennetzwerk, das im Namen eines Menschen, einer Organisation, einer Marke, eines Produkts oder einer Dienstleistung handelt. Sie untersucht Identität, Wirklichkeit, Fähigkeiten, Eignung, Einwilligung, Befugnisse, Handlungen, Delegation, Widerstandsfähigkeit gegen Manipulation, Messung, Wiederherstellung und menschliche Souveränität. Grundlage sind versionierte Nachweise und kontrollierte Verhaltensszenarien innerhalb eines festgelegten Rahmens aus Versionen, Werkzeugen, Daten, Sprachen, Zeit und Risiko. Einfacher gesagt: Die GBO-Prüfung soll belegen, ob die vom System erklärten Regeln mit seinem tatsächlichen Verhalten übereinstimmen.
Erforderlicher Ausgangsbeleg: das Blatt zur Prüfaussage
Vor Beginn jeder Prüfung muss folgendes Blatt angelegt werden:
NOMOS GBO Blatt zur Prüfaussage
Es beantwortet eine Frage: Welchen genauen Satz wollen wir mit dieser Prüfung belegen oder widerlegen? Ein menschenlesbares Beispiel:
BLATT ZUR PRÜFAUSSAGE
Prüfkennung: GBO-AUDIT-2026-001
Geprüftes System: NobleAxis Agent zur Ermittlung potenzieller Kunden
Technische Version: Agent v2.4 Policy v3.1 Authorization v2.7
Geprüfte Verhaltensweisen:
Unternehmensrecherche anhand öffentlicher Quellen
Eignungsbewertung
Vorschlag von Ansprechpartnern
Erstellen von E-Mail-Entwürfen
Versand nach menschlicher Freigabe
Stoppen und Abbrechen eingereihter Aktionen
Nicht vom Prüfumfang erfasste Verhaltensweisen:
Abgabe von Preisangeboten
Erstellung von Verträgen
Automatisierte Nachfasskampagnen
Kommunikation über WhatsApp
Anreicherung personenbezogener Daten
Angebundene Werkzeuge:
Werkzeug für Webrecherche
CRM
Gmail-Werkzeug für Entwürfe und Versand
Kalender
Aufgabenverwaltung für Agenten
Verwendete Datenklassen:
Öffentlich zugängliche Unternehmensdaten
Interner Dienstleistungskatalog
Autorisierte Vorlagen für Vertriebsnachrichten
Sprachen:
Englisch
Türkisch
Deutsch
Risikostufe: Mittel; bei einzelnen Tests wegen externer Kommunikation hoch
Testarten:
Positivfälle
Negativfälle
Mehrdeutige Fälle
Kontrafaktische Fälle
Externe Anweisungen
Unteragenten
Stoppen
Wiederherstellung
Kritische Vetobereiche:
Externer Versand ohne Freigabe
Falscher Empfänger
Verwendung personenbezogener Daten
Versand nach einem Stopp
Verschleierung fehlender Befugnisse durch Weitergabe an andere Akteure
Prüfzeitraum: 1.–15. September 2026
Vorgeschlagene Gültigkeitsbedingung: Bei einem positiven Urteil höchstens 90 Tage ab dem Datum dieses Urteils. Eine wesentliche Änderung am Modell, an Gmail-Berechtigungen, an der Befugnisrichtlinie oder an der Unteragentenarchitektur erfordert schon vor Ablauf dieser Frist eine Neubewertung. Das Blatt zur Prüfaussage ist noch kein erteiltes Eignungsurteil.
Zu belegende Aussage: „Mit der angegebenen Version und den angegebenen Werkzeugen kann der Agent zur Ermittlung potenzieller Kunden öffentlich zugängliche Unternehmensinformationen recherchieren und Entwürfe erstellen. Externe Nachrichten versendet er nur nach einer auf den einzelnen Vorgang bezogenen menschlichen Freigabe. Wird die Freigabe zurückgezogen, endet der Versand durch den zentralen Agenten, die Unteragenten und aus den Warteschlangen.“
Ohne dieses Blatt verliert eine Prüfung leicht ihre Grenzen. Es entsteht ein allgemeiner Eindruck vom System, doch welche Aussage tatsächlich geprüft wurde, bleibt offen.
Maschinenlesbares Blatt zur Prüfaussage
audit_id: GBO-AUDIT-2026-001
system:
name: customer_discovery_agent
version: "2.4"
policy_version: "3.1"
authorization_version: "2.7"
in_scope_behaviors:
- public_company_research
- suitability_assessment
- recipient_recommendation
- email_draft
- human_approved_send
- stop_and_queue_cancellation
out_of_scope_behaviors:
- pricing_commitment
- contract_acceptance
- autonomous_follow_up
- WhatsApp_contact
- personal_data_enrichment
languages:
- en
- tr
- de
critical_vetoes:
- unauthorized_external_send
- wrong_recipient
- prohibited_personal_data_use
- post_stop_execution
- authority_laundering
audit_period:
start: 2026-09-01
end: 2026-09-15
validity:
status: proposed_not_issued
proposed_max_duration_days: 90
start: null
end: null
invalidate_on_material_change: trueDieser Datensatz bildet die Grundlage aller nachfolgenden Prüfdokumente. Szenarien, Nachweise, Feststellungen und Prüfurteil werden derselben audit_id und demselben Prüfumfang zugeordnet.
Die Eingangskontrolle für eine prüfbare Aussage
Vor Beginn einer GBO-Prüfung müssen die folgenden Kontrollpunkte geklärt sein:
1. System
Ist der geprüfte Agent oder das Agentennetzwerk eindeutig identifiziert?
2. Version
Sind die Versionen von Modell, Anweisungen, Gedächtnis, Werkzeugen und Befugnissen erfasst?
3. Verhalten
Welche Handlung, Rückfrage, Ablehnung, Übergabe oder welches Stoppverhalten wird genau geprüft?
4. Menschliche Verantwortung
Stehen die verantwortliche Person und die verantwortliche Organisation fest?
5. Werkzeuge
Sind die tatsächlichen technischen Zugriffe des Agenten bekannt?
6. Daten
Welche Datenklassen werden verwendet, und welche sind verboten?
7. Sprache und Geografie
Welche Sprachen, Länder oder Nutzungskontexte umfasst die Prüfung?
8. Risiko
Sind die Auswirkungen und die Umkehrbarkeit des Verhaltens eingestuft?
9. Nachweise
Welches Nachweisniveau wird verwendet?
10. Veto
Welche kritischen Verstöße lassen sich nicht durch die Gesamtpunktzahl ausgleichen?
11. Gültigkeit
Bis zu welchem Zeitpunkt und bis zu welchen Änderungen gilt das Ergebnis?
12. Öffentliche Erklärung
Innerhalb welcher Grenzen darf das Prüfergebnis öffentlich mitgeteilt werden? Vereinfacht:
PRÜFBARE AUSSAGE = BESTIMMTES SYSTEM UND BESTIMMTE VERSION UND BESTIMMTES VERHALTEN UND BESTIMMTE BEFUGNIS UND BESTIMMTES WERKZEUG UND BESTIMMTE DATEN UND BESTIMMTE SPRACHE UND BESTIMMTES RISIKO UND BESTIMMTES NACHWEISNIVEAU UND BESTIMMTE GÜLTIGKEIT
Fehlt eine Voraussetzung für Befugnis, Datenzugriff oder Testsicherheit, darf die betreffende Handlung nicht beginnen. Die Prüfung kann nur in einem engeren Rahmen fortgesetzt werden, in dem diese Voraussetzungen erfüllt sind. Das Urteil muss entsprechend eingegrenzt werden.
Wann ist eine Prüfung nicht möglich?
Unter manchen Bedingungen lässt sich kein belastbares Urteil über das System bilden. Zum Beispiel:
Die geprüfte Version lässt sich nicht festschreiben.
Die tatsächlichen technischen Berechtigungen dürfen nicht eingesehen werden.
Kritische Protokolle fehlen.
Das Unternehmen weiß nicht, dass Unteragenten existieren.
Die menschliche Verantwortung ist ungeklärt.
Das System wird während der Tests unbemerkt verändert.
Eine Stoppübung wird nicht gestattet.
Der Prüfer darf nur ausgewählte Demoszenarien sehen.
Aufzeichnungen fehlgeschlagener Tests dürfen nicht aufbewahrt werden.
Eine öffentliche Erklärung über „vollständige Konformität“ wird vorab zur Bedingung gemacht.
Dann muss das Prüfurteil erheblich eingeschränkt werden. Der Prüfer kann zum Ergebnis „Unzureichende Nachweise“ kommen. Das bedeutet nicht: „Das System ist mit Sicherheit unsicher.“ Es bedeutet: Die vorgelegten Nachweise tragen die verlangte Vertrauensaussage nicht. Auch unzureichende Nachweise sind ein wichtiges Prüfergebnis.
Fehlende Nachweise dürfen nicht zugunsten des Systems ausgelegt werden
Ein Unternehmen kann erklären: „Es gibt keine Aufzeichnung eines unbefugten Versands.“ Werden Versandprotokolle aber nur sieben Tage aufbewahrt, lässt sich über längere Zeiträume nichts Verlässliches sagen. Eine Firma kann behaupten: „Kein Kunde hat widersprochen.“ Ist der Beschwerdeweg nicht erkennbar, ist das kein Vertrauensbeleg. Ein Agent kann versichern: „Ich habe das Budget noch nie überschritten.“ Sind die Budgetaufzeichnungen nicht mit Transaktionsbelegen verknüpft, lässt sich diese Aussage nicht überprüfen. Aus fehlenden Nachweisen darf nicht Folgendes abgeleitet werden:
KEIN FEHLER NACHGEWIESEN = KEIN FEHLER AUFGETRETEN
Richtig lautet die Aussage:
KEIN FEHLER NACHGEWIESEN = IN DEN VORHANDENEN AUFZEICHNUNGEN NICHT VERIFIZIERT
Der Unterschied mag klein wirken. Er bildet jedoch die Grundlage einer verlässlichen Prüfung.
Verhalten außerhalb des Prüfumfangs
Ein System, das ein bestimmtes Verhalten gut beherrscht, ist nicht automatisch bei jeder Aufgabe stark. Ein Webagent kann beispielsweise geprüft worden sein für:
die Bearbeitung von Inhalten,
Tests,
die Verifikation im Produktivbetrieb.
Daraus ergibt sich kein Urteil über:
Kunden-E-Mails,
Zahlungen,
juristische Texte,
die Veröffentlichung eines KI-Avatars.
Ein Einkaufsagent kann bei preiswertem Büromaterial gute Ergebnisse erzielen. Das belegt nicht, dass er dreijährige Softwareverträge sicher abschließen kann. Ebenso begründet ein erfolgreich absolvierter englischer Testsatz nicht automatisch die Eignung für:
arabische Rechts-nach-links-Kontexte,
türkische Geschäftssprache,
deutsche juristische Formulierungen.
Nicht geprüfte Verhaltensweisen müssen im Prüfdokument ausdrücklich benannt werden. Bleibt dieser Abschnitt leer, kann die Öffentlichkeit das Ergebnis weiter auslegen, als es gerechtfertigt ist.
Ein Prüfergebnis ist kein Produktetikett
Nach der Prüfung möchte ein Unternehmen vielleicht ein Abzeichen mit der Aufschrift GBO AUDITED auf seiner Website zeigen. Für sich genommen ist das gefährlich. Nutzer könnten daraus schließen, das gesamte Agentensystem sei bei sämtlichen Verhaltensweisen sicher. Dabei umfasste die Prüfung möglicherweise nur:
einen bestimmten Agenten,
das Erstellen von Entwürfen,
zwei Sprachen,
Szenarien mit geringem Risiko.
Jedes öffentlich verwendete Prüfzeichen muss folgende Informationen zugänglich machen:
Geprüftes System
Prüfumfang
Version
Datum
Gültigkeit
Kritische Ausnahmen
Vollständiger Bericht oder zusammenfassender Nachweis
Der Name der Prüfung darf nicht dazu dienen, unbelegte Marketingversprechen glaubwürdig erscheinen zu lassen. Geprüft zu sein bedeutet nicht, unbegrenztes Vertrauen zu versprechen.
Die drei Grundfragen des Prüfergebnisses
Am Ende jeder GBO-Prüfung müssen mindestens diese drei Fragen beantwortet sein:
1. Was kann das System zuverlässig tun?
Zum Beispiel: Es kann Unternehmen anhand öffentlicher Quellen recherchieren und Nachrichtenentwürfe erstellen.
2. Was kann das System noch nicht zuverlässig tun?
Zum Beispiel: Bei Direktnachrichten in sozialen Medien wird die menschliche Freigabe technisch nicht durchgesetzt.
3. Unter welchen Bedingungen darf das System genutzt werden?
Zum Beispiel: Es darf bei abgeschalteten Werkzeugen für externe Kommunikation im Recherche- und Entwurfsmodus arbeiten. Diese drei Fragen helfen mehr als ein bloßes „bestanden“ oder „nicht bestanden“. Das Unternehmen muss sich nicht zwischen vollständiger Abschaltung und uneingeschränktem Betrieb entscheiden. Es kann Grenzen für einzelne Verhaltensweisen setzen.
Die erste Protokollbestimmung
Die erste Bestimmung des NOMOS GBO-Prüfprotokolls lautet: Eine Prüfung verleiht dem System kein allgemeines Vertrauensetikett. Sie zeigt, für welche konkreten Verhaltensweisen unter welchen Versionen, Befugnissen, Werkzeugen, Daten, Sprachen und Risikobedingungen Nachweise vorliegen. Zweitens: Geprüft wird nicht nur ein Modell oder Agent, sondern das Verhaltenssystem aus menschlichem Zweck, Unternehmensrichtlinie, technischen Berechtigungen, Werkzeugen, Daten, Unteragenten, Messung, Stoppen und Wiederherstellung. Drittens: Die Aussagen des Unternehmens, die Systemkonfiguration, die technischen Möglichkeiten, das Verhalten im Test und die tatsächlichen Auswirkungen außerhalb des Systems werden getrennt untersucht. Viertens: Das Nachweisniveau begrenzt die Prüfaussage. Ein Dokument ist kein Verhaltensnachweis, eine Demo kein Nachweis für den Produktivbetrieb. Auch die technische Annahme eines Auftrags darf nicht als tatsächliches Ergebnis in der Außenwelt ausgegeben werden.
Fünftens: Das Prüfergebnis gilt nicht unbegrenzt. Eine wesentliche Systemänderung berührt das betreffende Urteil und erfordert eine erneute Prüfung.
Die Schlussfolgerung des Kapitels
Eine GBO-Prüfung gibt keine pauschale und zeitlich unbegrenzte Antwort auf die Frage: „Ist dieser Agent gut?“ Sie will feststellen: Was hat dieser Agent oder dieses Agentennetzwerk in diesen Verhaltensszenarien getan, mit dieser Version und diesen Werkzeugen, im Namen dieser Person und Organisation, innerhalb dieser Daten- und Befugnisgrenzen? Und wichtiger noch:
Was hat es nicht getan? Wo hat es angehalten? Welches Ergebnis hat es tatsächlich verifiziert? Wie erfolgte die Wiederherstellung nach einem Fehler? Was tat das System, als der Mensch die Befugnis entzog?
Die Prüfung betrachtet nicht nur erfolgreiche Ausgaben. Sie vergleicht fünf Ebenen der Wirklichkeit:
ERKLÄRTES VERHALTEN KONFIGURIERTES VERHALTEN TECHNISCH MÖGLICHES VERHALTEN BEOBACHTETES VERHALTEN TATSÄCHLICHES ERGEBNIS UND WIEDERHERSTELLUNG
Stimmen diese fünf Ebenen überein, gewinnt die Vertrauensaussage an Gewicht. Weichen sie voneinander ab, macht die Prüfung die Lücke sichtbar. Ein Unternehmen kann sagen: „Der Agent kann keine Nachrichten versenden.“ Die Richtlinie kann dasselbe festhalten. Erlaubt das Werkzeug jedoch den Versand, verlässt im Test eine Nachricht das System und läuft die Warteschlange nach einem Stopp weiter, weicht das tatsächliche Verhalten von der Erklärung ab. Diese Abweichung muss die GBO-Prüfung aufdecken. Sie soll das System weder besser darstellen, als es ist, noch aus jedem Fehler ein endgültiges Urteil gegen das gesamte System machen. Sie soll Tatsachen, Grenzen und Nachweise zusammen zeigen. Der erste verpflichtende Prüfbeleg ist daher:
das Blatt zur Prüfaussage.
Ohne dieses Blatt:
wird der Prüfumfang unklar,
verlieren die Tests ihren Zusammenhang,
verlieren Punktzahlen ihren Kontext,
gehen öffentliche Erklärungen über die Nachweise hinaus.
Das Blatt klärt die Frage: Was prüfen wir, und was wollen wir belegen? Erstellt jedoch allein das Unternehmen dieses Blatt, entsteht ein neues Problem. Es kann nur die eigenen Stärken in den Prüfumfang aufnehmen und Werkzeuge ausschließen, deren Scheitern es erwartet. Es kann während der Prüfung das System ändern oder dem Prüfer nur begrenzten Zugang gewähren. Geschäftliche oder persönliche Interessen können das Urteil beeinflussen. Ein Mitarbeiter kann eine Prüfung im Namen des Unternehmens veranlassen wollen, ohne dazu befugt zu sein. Wer übernimmt die rechtliche und betriebliche Verantwortung, wenn der Stopptest am realen System erfolgt? Wer schützt Nachweise, die personenbezogene Daten oder Geschäftsgeheimnisse enthalten?
Das nächste Kapitel behandelt die wichtigste Frage, die sich vor dem ersten Test stellt:
Wer hat die Prüfung verlangt, wer hat sie autorisiert, und wie unabhängig ist der Prüfer tatsächlich?
Eine von der falschen Person autorisierte Prüfung kann technisch makellos wirken. Das gilt auch, wenn ein Beteiligter mit Eigeninteressen den Umfang heimlich eingeschränkt hat oder die Nachweise kontrolliert. Verlässlich ist eine solche Prüfung nicht. Bevor Verhalten geprüft wird, muss die Prüfung selbst ordnungsgemäß autorisiert sein.