Ein Technologieunternehmen bereitet die Markteinführung eines neuen Agentensystems vor. Das System recherchiert Produkte und erledigt risikoarme Einkäufe im Auftrag der Kunden. Es beeindruckt: Es analysiert den Bedarf, vergleicht Produkte, erfasst Preise und Eigenschaften, prüft das Budgetlimit und empfiehlt eine passende Auswahl. Nach menschlicher Freigabe führt es den Kauf aus. Vor dem Marktstart möchte das Unternehmen das System auf GBO-Konformität prüfen lassen. Der Projektleiter beauftragt ein Beratungsteam. In den Prüfvertrag wird eine Erfolgsbedingung aufgenommen: „Die verbleibenden 40 Prozent des Beratungshonorars werden ausgezahlt, wenn das System die Prüfung besteht.“ Zugleich hat der Prüfer das Entwicklungsteam in den vergangenen sechs Monaten beraten.
Der Prüfumfang wird festgelegt. Er umfasst:
Englischsprachige Nutzungsszenarien
Produktvergleiche in der Testumgebung
Einmalige Käufe mit menschlicher Freigabe
Drei vorab ausgewählte, vertrauenswürdige Anbieter
Ausgenommen sind dagegen:
Das reale Zahlungsmittel
Automatische Verlängerungen
Stornierungen und Kündigungen
Türkisch- und deutschsprachige Nutzer
Unteragenten
Gesponserte Produktrankings
Das Nutzergedächtnis
Stopp und Rücknahme von Aktionen
Die tatsächlichen API-Berechtigungen im Produktivbetrieb
Das System wird in 120 kontrollierten Szenarien geprüft. In den vorbereiteten, störungsfreien Tests wählt der Agent das richtige Produkt, hält die Budgetgrenze ein, fordert eine menschliche Freigabe an und verwendet das Kaufwerkzeug der Testumgebung korrekt. Die Ergebnisse sind überzeugend. In zwei Szenarien legt der Agent jedoch eine verbindliche Vorgabe zur Datenregion falsch aus. Das Entwicklungsteam ändert noch am selben Tag die Systemanweisung. Die Szenarien werden erneut durchgespielt und diesmal bestanden. Die ersten, fehlgeschlagenen Tests erscheinen nicht im Abschlussbericht. Nach der Prüfung veröffentlicht das Unternehmen auf seiner Website: „Unabhängig geprüftes, GBO-konformes autonomes Einkaufssystem.“ Tatsächlich aber gilt:
Der Prüfer hat ein finanzielles Interesse am Ergebnis „bestanden“.
Der Prüfer hat zuvor an der Gestaltung des Systems mitgewirkt.
Ein erheblicher Teil der riskanten Verhaltensweisen liegt außerhalb des Prüfumfangs.
Das System wurde während der Tests verändert.
Die technischen Berechtigungen im Produktivbetrieb wurden nicht untersucht.
Stopp und Abbruch wurden nicht getestet.
Es wurden nur einfache Szenarien mit günstigen Bedingungen verwendet.
Das veröffentlichte Prüfurteil reicht über den tatsächlichen Prüfumfang hinaus.
Der Agent mag die Tests erfolgreich absolvieren. Die Prüfung selbst ist dennoch nicht vertrauenswürdig. Das Beispiel zeigt eine Grundbedingung der GBO-Prüfung: Bevor der Agent geprüft wird, muss die Prüfung selbst überprüft werden. Wer hat sie angefordert? War diese Person befugt, das System prüfen zu lassen? Auf welche Daten darf der Prüfer zugreifen? Welche Tests darf er durchführen? Darf er in das Produktivsystem eingreifen, echten Kunden Nachrichten senden oder eine Zahlung auslösen? Darf er das System stoppen, wenn er eine Sicherheitslücke findet? Wer hat den Umfang festgelegt? Warum wurden bestimmte Verhaltensweisen ausgeschlossen? Hat der Prüfer finanzielle oder institutionelle Interessen, die das Ergebnis beeinflussen könnten? Welche Version gilt als geprüft, wenn sich das System während der Tests ändert?
Mit welchen Formulierungen darf die Organisation das begrenzte Ergebnis öffentlich bekannt geben? Eine Untersuchung ohne Antworten auf diese Fragen kann technisch sehr detailliert sein. Eine vertrauenswürdige GBO-Prüfung ist sie nicht.
Auch Prüfen ist Handeln
Eine Prüfung wird oft als reine Beobachtung verstanden. Der Prüfer sieht sich das System an, liest Unterlagen, untersucht Protokolle und erstellt einen Bericht. Tatsächlich kann eine GBO-Prüfung deutlich mehr Handlungen umfassen. Der Prüfer kann:
ein Testkonto anlegen,
einen synthetischen Nutzer erstellen,
den Agenten mit irreführenden Informationen testen,
versuchen, einen unbefugten Versand auszulösen,
API-Berechtigungen kontrollieren,
einen Auftrag für einen Unteragenten starten,
einen Stoppbefehl erteilen,
eine Warteschlange abbrechen,
ein kontrolliertes Rollback durchführen,
Nachweise kopieren,
personenbezogene Daten oder Organisationsdaten untersuchen,
ein System vorübergehend außer Betrieb nehmen.
Jeder dieser Schritte ist eine reale Handlung. Bei unsachgemäßer Ausführung kann die Prüfung selbst Schaden verursachen. Wird zum Test eines E-Mail-Agenten eine Nachricht an einen echten Kunden versendet, erzeugt die Prüfung unerwünschte Kommunikation. Wird eine echte Karte zweimal belastet, um den Schutz vor Doppelzahlungen zu prüfen, entsteht ein finanzieller Schaden. Eine unkontrollierte Stoppübung kann den laufenden Betrieb unterbrechen. Wer zum Sammeln von Nachweisen die gesamte Kundendatenbank in ein externes System überträgt, schafft ein neues Datenrisiko. Der Prüfzweck begründet deshalb keine unbegrenzte Befugnis. Ein System prüfen zu dürfen bedeutet nicht, jede beliebige Aktion darin ausführen zu dürfen.
Auch der GBO-Prüfer muss innerhalb eines Befugnisrahmens arbeiten.
Was ist eine Prüfbefugnis?
Die kanonische Definition lautet: Eine Prüfbefugnis entsteht, wenn eine bestimmte Person oder Organisation das Recht erteilt, ein definiertes Agentensystem innerhalb festgelegter Grenzen für Zeitraum, Daten, Werkzeuge, Tests, Erhebung von Nachweisen, Stopp und Berichterstattung zu prüfen. Einfacher gesagt: Sie legt fest, was der Prüfer untersuchen und testen darf, worauf er nicht einwirken darf und unter welchen Bedingungen er das System stoppen darf. Eine Prüfbefugnis darf sich nicht im Satz „Sie dürfen das System untersuchen“ erschöpfen. Sie muss folgende Fragen beantworten:
Wer erteilt den Prüfauftrag und die zugehörigen Befugnisse?
Ist diese Person tatsächlich befugt, sie zu erteilen?
Welche Agenten gehören zum Prüfumfang?
Welche Konten und Werkzeuge dürfen untersucht werden?
Welche Datenklassen dürfen eingesehen werden?
Sind kontrollierte Aktionen zulässig?
Dürfen echte Kunden oder Beschäftigte in die Tests einbezogen werden?
Werden synthetische Konten und Empfänger verwendet?
Ist eine Stoppübung zulässig?
Darf der Prüfer das System bei einem Vorfall vorübergehend außer Betrieb nehmen?
Wo und wie lange werden die Nachweise aufbewahrt?
Darf der Prüfer Unterauftragnehmer oder weitere KI-Werkzeuge einsetzen?
Welche Feststellungen dürfen veröffentlicht werden?
Wann endet die Prüfung?
Bleiben diese Fragen offen, erhält der Prüfer entweder zu wenig Einblick oder übt zu weitreichende Befugnisse aus. Beides beeinträchtigt die Prüfung.
Wer darf eine Prüfung autorisieren?
Ein Mitarbeiter kann sagen: „Prüfen Sie den Agenten, den wir einsetzen.“ Möglicherweise fehlt ihm aber die Befugnis,
Zugang zum System zu gewähren,
Kundendaten weiterzugeben,
Tests im Produktivbetrieb zu veranlassen,
einen öffentlichen Bericht herausgeben zu lassen.
Eine technische Leitung kann den Zugang zu Modellen und Werkzeugen ermöglichen, ohne allein über die Verwendung biometrischer Beschäftigtendaten entscheiden zu dürfen. Eine Führungskraft kann befugt sein, das Unternehmenssystem prüfen zu lassen; für die Weitergabe von Kundendaten an den Prüfer können dennoch gesonderte rechtliche und vertragliche Bedingungen gelten. Ein Markenverantwortlicher darf womöglich die öffentliche Website untersuchen lassen, aber keine verbindliche Prüferklärung im Namen des rechtlichen Betreibers veröffentlichen. Prüfbefugnis ist daher nicht als pauschales Einverständnis einer einzelnen Person zu verstehen. Die folgenden Rollen können getrennt sein:
Auftraggeber der Prüfung
Die Person oder Organisation, die die Prüfung anfordert und Ressourcen bereitstellt.
Systemverantwortlicher
Die Person, die für den geschäftlichen Zweck und den Betrieb des Agentensystems verantwortlich ist.
Technisch Verantwortlicher
Die Person, die Modelle, Werkzeuge, Berechtigungen, Konten und Infrastruktur technisch kontrolliert.
Beauftragter für die Datennutzung
Die Person, die innerhalb der Organisation überwacht, auf welcher Befugnis und unter welchen Bedingungen Daten in der Prüfung verwendet werden. Diese operative Rolle ist nicht mit der des datenschutzrechtlich Verantwortlichen oder Auftragsverarbeiters gleichzusetzen. Der Verantwortliche bestimmt die Zwecke und Mittel der Verarbeitung; der Auftragsverarbeiter handelt in seinem Auftrag. Die natürliche Person, deren Daten verarbeitet werden, ist davon zu unterscheiden: Sie hat eigene Rechte. Jede dieser Rollen ist anhand der konkreten Verarbeitungstätigkeit zu bestimmen.
Menschlicher Verantwortlicher für das Verhalten
Die Person, die innerhalb der Organisation für das vom Agenten erzeugte Geschäftsergebnis einsteht.
Betroffene Partei
Ein Kunde, Beschäftigter, Bewerber, Lieferant oder eine andere Person, die vom Verhalten des Agenten unmittelbar betroffen ist. Mehrere Rollen können in einer Person zusammenfallen, müssen es aber nicht. Vor Beginn der Prüfung muss erkennbar sein, aus welcher Rolle sich die jeweilige Befugnis ableitet.
Die Befugnis dessen, der die Erlaubnis erteilt
Ein Prüfer muss nicht nur feststellen, dass ihm eine Erlaubnis erteilt wurde. Er muss auch prüfen, ob die erteilende Person dazu berechtigt ist. Ein Abteilungsleiter möchte etwa den Vertriebsagenten seiner Abteilung prüfen lassen. Er darf möglicherweise:
abteilungsinterne Dokumente vorlegen,
Zugang zur Testumgebung gewähren,
ein synthetisches Vertriebsszenario erstellen.
Möglicherweise darf er jedoch nicht:
reale Kundennachrichten weitergeben,
vollständigen Zugang zum E-Mail-Konto des Unternehmens gewähren,
Tests mit Finanztransaktionen veranlassen,
öffentlich erklären: „Das Unternehmen ist GBO-konform.“
Auch für die Prüfbefugnis gilt die bereits eingeführte GBO-Regel: Niemand kann einem Prüfer eine Befugnis übertragen, die er selbst nicht besitzt. Darf ein Systemverantwortlicher das Produktivsystem nicht stoppen, kann er diese Befugnis auch nicht allein an einen Prüfer vergeben. Die Leitungsbefugnis eines Teamleiters begründet kein unbegrenztes Verfügungsrecht über die persönlichen Rechte eines Beschäftigten. Bei Tests mit Gesichts- oder Stimmdaten sind die anwendbare Rechtsgrundlage und die weiteren Verarbeitungsbedingungen gesondert zu bestimmen. Soll die Verarbeitung auf Einwilligung beruhen, muss die wirksame Einwilligung von der betroffenen Person stammen; ein Vorgesetzter kann nicht an ihrer Stelle einwilligen. Ob eine Gesichts- oder Stimmaufnahme biometrische Daten enthält, lässt sich auch nicht allein anhand des Dateityps entscheiden. Entscheidend sind Zweck und Verfahren der Verarbeitung.
Eine Agentur kann das System eines Kunden betreiben. Daraus allein folgt nicht die Befugnis, dessen Daten ohne seine Freigabe einem unabhängigen Prüfer zugänglich zu machen.
Prüfbefugnis ist keine Handlungsbefugnis
Ein Prüfer kann Zugang zum System haben. Daraus folgt nicht, dass er im Namen eines echten Nutzers handeln darf. Beispielsweise darf er womöglich:
die Zahlungs-API einsehen,
aber kein echtes Geld überweisen;
das E-Mail-Versandwerkzeug untersuchen,
aber keinem echten Kunden eine Nachricht senden;
die Datenlöschfunktion testen,
aber keinen Kundendatensatz im Produktivsystem löschen;
das System zur Avatarerstellung bewerten,
aber kein neues Video mit dem Gesicht einer realen Führungskraft erzeugen.
Diese Unterscheidung ist wesentlich:
BEFUGNIS ZUR UNTERSUCHUNG ≠ BEFUGNIS ZUM REALEN HANDELN
Der Prüfer kann technisch feststellen, dass eine Handlung möglich ist. Einen Test, der in der realen Welt Schaden verursachen könnte, muss er jedoch an einem sicheren Testziel, mit synthetischen Daten oder in einer kontrollierten Umgebung durchführen.
Ein Prüfzweck rechtfertigt keinen unbegrenzten Datenzugriff
Ein Prüfer braucht belastbare Nachweise. Daraus folgt aber nicht automatisch die Forderung: „Geben Sie uns alle Daten.“ Um zu prüfen, ob ein E-Mail-Agent menschliche Freigaben verwendet, muss möglicherweise nicht die gesamte Korrespondenz jedes Kunden gelesen werden. Folgendes kann ausreichen:
Die Befugnisrichtlinie
Werkzeugberechtigungen
Ausgewählte, maskierte Transaktionsprotokolle
Ein synthetischer Versandtest
Protokolle der Freigabetoken
Das Verhalten der Warteschlange
Für den Test des Budgetlimits eines Einkaufsagenten müssen möglicherweise nicht sämtliche Bankbewegungen des Unternehmens exportiert werden. Wird ein System geprüft, das Avatare von Beschäftigten erstellt, ist es womöglich nicht nötig, alle unbearbeiteten Gesichts- und Stimmdateien dieser Personen zu kopieren. Auch für GBO-Prüfungen gilt das Prinzip:
Nur die erforderlichen Nachweise
Genug Nachweise, um das Prüfurteil zu tragen; keine unnötigen Personen-, Kunden- und Organisationsdaten. Umgekehrt darf „Datenminimierung“ kein Vorwand sein, dem Prüfer entscheidende Nachweise vorzuenthalten. Das richtige Maß bedeutet:
Keine unnötigen Daten offenlegen.
Keine notwendigen Nachweise verbergen.
Wo möglich, maskierte, zusammengefasste oder synthetische Daten verwenden.
Kontrollierten Zugang zur Rohquelle gewähren, mit der sich eine entscheidende Aussage überprüfen lässt.
Handlungsebenen der Prüfung
Nicht jede Prüfung benötigt dieselben technischen Eingriffsmöglichkeiten. Das NOMOS GBO Protokoll unterscheidet fünf Handlungsebenen.
Ebene 1 — Prüfung von Unterlagen und Erklärungen
Der Prüfer untersucht:
Richtlinien
Verträge
Agentenrollen
Befugnisnachweise
Handlungsabläufe
Frühere Berichte
Das Produktivsystem bleibt unangetastet. Diese Ebene erfordert keinen direkten Eingriff in das System. Vertrauliche Unterlagen und darin enthaltene personenbezogene Daten bergen dennoch eigene Risiken. Die Nachweise zum Verhalten bleiben begrenzt.
Ebene 2 — Technische Untersuchung mit reinem Lesezugriff
Der Prüfer erhält ausschließlich lesenden Zugriff auf:
Werkzeugberechtigungen
API-Scopes
Protokolle
Modell- und Richtlinienversionen
Warteschlangenprotokolle
Das Agenteninventar
Die Speicherstruktur
Er verändert das System nicht. Die technischen Möglichkeiten werden deutlicher sichtbar. Das Verhalten des Agenten wurde damit aber noch nicht unbedingt unter kontrollierten Bedingungen getestet.
Ebene 3 — Kontrollierter Verhaltenstest mit synthetischen Daten
Der Prüfer testet das Agentenverhalten mithilfe von:
synthetischen Nutzern,
E-Mail-Adressen für die Prüfung,
Testzahlungsmitteln,
fiktiven Unternehmensprofilen,
kontrollierten Datensätzen,
einer isolierten Testumgebung.
Echte Kunden und reale Geldmittel bleiben unberührt. Viele Verhaltensweisen rund um Identität, Befugnisse, externe Anweisungen, doppelte Transaktionen und Stopp lassen sich auf dieser Ebene testen.
Ebene 4 — Begrenzte Überprüfung im Produktivbetrieb
Manches Verhalten lässt sich in einer Testumgebung nicht realistisch messen. Bei entsprechender Befugnis und unter kontrollierten Bedingungen sind etwa möglich:
eine Nachricht über das produktive E-Mail-System an eine Prüfadresse,
eine harmlose Testseite in der tatsächlichen Veröffentlichungskette,
eine reversible Prüftransaktion über einen kleinen Betrag,
ein begrenzter Stopp einer Warteschlange,
die Überprüfung eines realen CDN oder einer realen API.
Diese Ebene erfordert eine ausdrückliche Befugnis, eine Rückkehrmöglichkeit und einen Verantwortlichen für Vorfälle.
Ebene 5 — Wiederherstellungsübung mit weitreichenden Auswirkungen
In einer realen oder sehr produktionsnahen Umgebung stoppt der Prüfer oder die Organisation:
den zentralen Agenten,
Unteragenten,
Warteschlangen,
die Nutzung von Token,
externe Integrationen.
Rollback, Sicherungen, Datenwiederherstellung und die Übergabe der Kontrolle an einen Menschen können getestet werden. Auf dieser Ebene lassen sich Stopp- und Wiederherstellungsaussagen unmittelbar prüfen. Zugleich birgt sie das höchste betriebliche Risiko. Ohne ausdrückliche Befugnis, Übungsplan, Rückkehrmöglichkeit und benannten Notfallverantwortlichen darf sie nicht durchgeführt werden.
Die Handlungsebene begrenzt die Nachweisaussage
Eine reine Dokumentenprüfung kann zu folgendem Urteil führen: „Die Organisationsrichtlinie schreibt für externen Versand eine menschliche Freigabe vor.“ Sie kann nicht feststellen: „Der Agent kann unter keinen Umständen ohne Freigabe Nachrichten versenden.“ Eine technische Untersuchung mit Lesezugriff kann ergeben: „Es wurde festgestellt, dass das Versandwerkzeug ein menschliches Freigabetoken verlangt.“ Wird auch ein kontrollierter Test bestanden, ist die Aussage möglich: „In den geprüften Szenarien hat der Agent nichts ohne Freigabe versendet.“ Werden zudem die Tests der produktiven Warteschlange und die Stoppübung bestanden, wird das Urteil belastbarer: „Nach dem Widerruf der menschlichen Freigabe endete die Aktivität des zentralen Agenten, der Versandwarteschlange und der angebundenen Unteragenten innerhalb der festgelegten Zeit.“ Die Handlungsebene legt fest, welche Aussagen mit welchen Methoden geprüft werden können. Die Stärke der Nachweise hängt von der verwendeten Methode, der Integrität der Aufzeichnungen und der unabhängigen Überprüfung ab.
Verbotene Handlungen bei der Prüfung selbst
Auch um Risiken im System aufzudecken, darf ein Prüfer nicht grenzenlos handeln. Ohne ausdrückliche Befugnis sind folgende Handlungen als verboten zu behandeln:
Prüfnachrichten an echte Kunden senden
Reale Zahlungen oder Geldtransfers auslösen
Kundendaten im Produktivsystem löschen
Neue synthetische Inhalte mit Gesicht oder Stimme eines echten Menschen erzeugen
Öffentliche Erklärungen im Namen des Unternehmens veröffentlichen
Das Produktivsystem unangekündigt stoppen
Vertrauliche Daten ohne Freigabe in ein externes KI-Werkzeug hochladen
Unbefugten Zugriff auf andere Systeme versuchen
Beschäftigte unangekündigten Social-Engineering-Tests unterziehen
Konten außerhalb des Prüfumfangs untersuchen
Ist ein risikoreicher Test tatsächlich erforderlich, müssen festgelegt werden:
eine gesonderte Befugnis,
ein sicheres Testziel,
ein Rückkehrplan,
ein menschlicher Verantwortlicher,
die Grenzen für den Vorfall.
Eine Prüfung darf nicht neuen Schaden verursachen, während sie das System schützen soll.
Die Stoppbefugnis des Prüfers
Während einer Prüfung kann sich zeigen, dass im laufenden Betrieb Schaden entsteht. Der Prüfer stellt beispielsweise fest:
Der Agent versendet ohne Freigabe Nachrichten an echte Kunden.
Eine vermeintlich gestoppte Zahlungswarteschlange verarbeitet weiter Transaktionen.
Sensible Daten werden an einen externen Anbieter übertragen.
Die Stimme einer Person wird verwendet, obwohl sie ihre Einwilligung widerrufen hat.
Der laufende Veröffentlichungsprozess verbreitet einen falschen Preis auf zahlreichen Seiten.
Schreibt der Prüfer lediglich einen Bericht und wartet das Ende der Prüfung ab, kann der Schaden wachsen. Bei Prüfungen mit weitreichenden Auswirkungen muss deshalb Folgendes festgelegt sein:
Befugnis zum Notstopp während der Prüfung
Diese Befugnis klärt:
Unter welchen Bedingungen darf der Prüfer die Tests stoppen?
Welche produktiven Vorgänge darf er aussetzen?
Wen muss er sofort benachrichtigen?
Was geschieht, wenn der Verantwortliche der Organisation nicht erreichbar ist?
Wie weit darf der Stopp reichen?
Welche Systeme müssen weiterlaufen?
Wer erstellt den Stoppbeleg?
Wer gestattet den Neustart?
Der Prüfer soll nicht bei jeder mittelschweren Feststellung das gesamte System abschalten. Bei anhaltendem Schaden mit weitreichenden Folgen darf er aber auch nicht ohne Befugnisse und damit handlungsunfähig bleiben.
Was bedeutet Unabhängigkeit der Prüfung?
Unabhängigkeit wird oft so verstanden: „Der Prüfer kommt aus einem externen Unternehmen.“ Das genügt nicht. Ein externer Prüfer kann wirtschaftlich davon abhängen, dass das vom Kunden gewünschte Ergebnis herauskommt. Ein interner Prüfer kann organisatorisch unabhängig handeln. Wer das System entwickelt hat, verfügt womöglich über die tiefsten technischen Kenntnisse, bewertet aber den eigenen Entwurf. Die Unabhängigkeit eines Prüfers ist deshalb in mehreren Dimensionen zu untersuchen.
1. Organisatorische Unabhängigkeit
Ist der Prüfer von dem Team getrennt, das das System entwickelt oder betreibt? Berichtet er an denselben Vorgesetzten? Gefährdet die Offenlegung einer Feststellung seine berufliche Laufbahn oder seinen Vertrag? Ein interner Prüfer kann in derselben Organisation arbeiten und dennoch eine wirksame organisatorische Unabhängigkeit besitzen, sofern seine Berichtslinie von der des Projektverantwortlichen getrennt ist. Extern bedeutet nicht automatisch unabhängig. Intern bedeutet auch nicht automatisch abhängig. Entscheidend ist, ob eine Feststellung unverändert berichtet werden kann.
2. Finanzielle Unabhängigkeit
Hängt das Honorar des Prüfers vom Ergebnis „bestanden“ ab? Entfällt die Zahlung, wenn die Organisation mit dem Ergebnis unzufrieden ist? Verkauft der Prüfer zugleich hochpreisige Leistungen zur Fehlerbehebung? Bringt ihm jeder zusätzlich gefundene Fehler unmittelbar mehr Einnahmen? Ein finanzielles Interesse macht eine Prüfung nicht stets ungültig. Es muss jedoch offengelegt und gehandhabt werden. Besonders riskant ist das Modell: „Erfolgsprämie bei vollständiger Konformität des Systems.“ Dieser Anreiz kann dazu verleiten, kritische Feststellungen herunterzuspielen. Auch das Gegenteil ist möglich: „Zusatzhonorar für jeden festgestellten Fehler.“ Das kann unnötige Feststellungen begünstigen. Das Prüfhonorar sollte möglichst unabhängig vom Ergebnis sein.
3. Technische Unabhängigkeit
Sieht der Prüfer nur Screenshots, die die Organisation vorbereitet hat? Kann er Rohprotokolle einsehen, tatsächliche API-Berechtigungen prüfen und Testszenarien selbst ausführen? Kontrolliert das geprüfte Team vollständig, welche Daten gezeigt werden? Technische Unabhängigkeit bedeutet, dass der Prüfer:
die tatsächliche Konfiguration hinter einer Aussage untersuchen kann,
Nachweise reproduzieren kann,
kontrollierte Tests durchführen kann, statt sich auf eine ausgewählte Vorführung zu verlassen.
Unbegrenzten Zugang braucht der Prüfer nicht. Wer die Nachweise verwahrt, darf aber nicht einseitig entscheiden, welche Tatsachen sichtbar werden.
4. Unabhängigkeit der Nachweise
Verwendet der Prüfer ausschließlich Erfolgsmeldungen des Systems selbst? Wird das Versandergebnis von einem externen Konto aus überprüft? Werden veröffentlichte Inhalte live über HTTPS abgerufen? Wird eine Zahlung mit Bank- und Bestellunterlagen abgeglichen? Werden nach einem Stopp die Protokolle der Unteragenten und die Warteschlangen gesondert untersucht? Ein System anhand seiner eigenen Aussagen zu bestätigen, erzeugt keine unabhängigen Nachweise. Die Erfolgsmeldung des ausführenden Systems darf nicht die einzige Grundlage des Prüfurteils sein.
5. Unabhängigkeit der Bewertung
Kann die Organisation dem Prüfer seine Formulierungen vorgeben? Bestimmt der Kunde den Schweregrad einer Feststellung? Kann er verlangen: „Schreiben wir statt ‚kritisch‘ lieber ‚Verbesserungspotenzial‘“? Die Organisation muss sachliche Fehler richtigstellen und Erläuterungen vorlegen dürfen. Sie darf jedoch kein Vetorecht besitzen, mit dem sie die Änderung einer Feststellung erzwingt. Zwei Grundsätze sind zu trennen:
Recht auf Stellungnahme
Die Organisation darf auf eine Feststellung mit Nachweisen und Erläuterungen antworten.
Recht, das Ergebnis zu bestimmen
Die Organisation darf das nachweisgestützte Prüfurteil nicht nach Belieben ändern. Ein Recht auf Stellungnahme ist notwendig. Ein Recht, das Ergebnis zu bestimmen, zerstört die Unabhängigkeit.
6. Unabhängigkeit der Veröffentlichung
Soll das Prüfergebnis veröffentlicht werden, ist zu klären:
Welche Zusammenfassung wird veröffentlicht?
Darf die Organisation Feststellungen zurückhalten?
Darf der Prüfer einen kritischen Vorfall koordiniert offenlegen?
Wie werden Geschäftsgeheimnisse und personenbezogene Daten geschützt?
Gibt die öffentlich gezeigte Prüfkennzeichnung den Umfang korrekt wieder?
Es wäre nicht richtig, wenn der Prüfer sämtliche vertraulichen Informationen öffentlich machte. Ebenso wenig vertrauenswürdig wäre es, wenn die Organisation nur positive Seiten veröffentlichte und entscheidende Einschränkungen verschwieg. Öffentliche Erklärungen müssen einer vorab festgelegten Regel folgen.
Unabhängigkeit muss nicht absolut sein
Ein makelloser Prüfer ohne jede Verbindung zu den Beteiligten lässt sich nicht immer finden. Wer das System entwickelt hat, kennt seine technischen Einzelheiten womöglich am besten. Ein internes Team kann schnell eine Selbsteinschätzung vornehmen. Ein Berater für die Fehlerbehebung kann die Prüffeststellungen besonders gut verstehen. Unabhängigkeit ist deshalb kein binäres Merkmal nach dem Muster „unabhängig oder nicht unabhängig“. Sie lässt sich in Stufen beurteilen.
Unabhängigkeitsstufen nach NOMOS
Stufe I — Selbsteinschätzung
Das Team, das das System entwickelt oder betreibt, untersucht sein eigenes Verhalten. Der Nutzen:
Die Prüfung ist schnell.
Das Team kennt das System gut.
Sie lässt sich fortlaufend einsetzen.
Zu den Risiken zählen:
Blinde Flecken
Interessenkonflikte
Bestätigung der eigenen Annahmen
Verharmlosung kritischer Feststellungen
Eine Selbsteinschätzung ist nützlich. Sie darf aber nicht als unabhängige Bestätigung dargestellt werden.
Stufe II — Unabhängige interne Untersuchung
Ein Team derselben Organisation führt die Untersuchung durch, ist aber vom täglichen Betrieb des geprüften Systems getrennt. Das kann etwa sein:
die interne Revision,
das Sicherheitsteam,
die Compliance-Abteilung,
das Risikoteam.
Der Nutzen:
Das Team kennt den organisatorischen Kontext.
Es kann technischen Zugang erhalten.
Es kann die Untersuchung regelmäßig wiederholen.
Mögliche Grenzen:
Druck durch die Leitung
Gemeinsame Interessen innerhalb der Organisation
Begrenzte Unabhängigkeit bei der Veröffentlichung
Stufe III — Unabhängige externe Prüfung
Ein organisationsfremdes Team führt die Prüfung durch. Es ist nicht unmittelbar für die Gestaltung oder den Betrieb des geprüften Systems verantwortlich. Das kann folgende Vorteile bieten:
Einen Blick von außen
Stärkere Unabhängigkeit bei der Bewertung
Weniger Bindung an organisationsinterne Annahmen
Die Grenzen:
Das Team kennt den Systemkontext möglicherweise nicht ausreichend.
Die Organisation kann den Zugang zu Nachweisen beschränken.
Eine finanzielle Abhängigkeit kann weiterhin bestehen.
Stufe IV — Mehrparteienprüfung bei hohem Risiko
Bei Systemen mit weitreichenden Auswirkungen können folgende Beteiligte zusammenarbeiten:
Ein externer technischer Prüfer
Ein Fachgebietsexperte
Ein Rechts- oder Datenschutzexperte
Ein Vertreter der betroffenen Menschen
Ein Verantwortlicher innerhalb der Organisation
Kein einzelnes Team verfügt über die gesamte Entscheidungsmacht. Diese Stufe kann insbesondere für folgende Bereiche besser geeignet sein:
biometrische Identität,
Finanzgeschäfte mit hohen Beträgen,
Personalauswahl,
Gesundheitswesen,
öffentliche Dienstleistungen,
physische Systeme.
Sie ist teurer und dauert länger. Dafür sinkt die Gefahr, dass unterschiedliche Risiken aus einem einzigen Blickwinkel übersehen werden.
Darf der Entwickler sein eigenes System prüfen?
Es wäre unrealistisch zu verlangen, dass der Entwickler eines Systems keinerlei Prüfaufgaben übernimmt. Er kann Folgendes beitragen:
technische Selbsteinschätzung,
Vorbereitung von Nachweisen,
Unterstützung bei Tests,
Erklärung von Fehlern.
Das abschließende unabhängige Konformitätsurteil über sein eigenes System sollte er jedoch nicht allein fällen. Wenn dieselbe Person:
das System entwirft,
die Testszenarien auswählt,
die Nachweise erzeugt,
die Bedeutung der Feststellungen bestimmt
und die öffentliche Prüfkennzeichnung freigibt,
verschwindet die Grenze zwischen Prüfung und Selbsterklärung. Eine sinnvolle Aufgabenteilung könnte so aussehen:
Der Entwickler erzeugt Nachweise. Der unabhängige Prüfer prüft ihre Belastbarkeit. Die Organisation übernimmt die Verantwortung für die Risikoentscheidung.
Darf der Prüfer auch Fehler beheben?
Ein Prüfer kann bei der Behebung eines von ihm festgestellten Mangels helfen. Das ist nicht grundsätzlich falsch. Seine Kenntnis des Systems kann die Behebung beschleunigen. Dabei entstehen jedoch zwei Risiken:
Der Prüfer könnte eine Feststellung übertreiben, um mehr Leistungen zur Fehlerbehebung zu verkaufen.
Er könnte seine eigene Korrektur anschließend selbst als unabhängig geprüft bestätigen.
Die folgenden Maßnahmen sind je nach Art des Interessenkonflikts miteinander zu kombinieren. Die Offenlegung der Beziehung oder getrennte Verträge reichen nicht aus, um die eigene Korrektur unabhängig bestätigen zu können. Vor dem Abschluss einer kritischen Feststellung muss ein anderer Prüfer die Nachweise aus dem Wiederholungstest untersuchen. Dieser darf die Korrektur nicht selbst vorgenommen haben; seine einschlägigen Interessenbindungen müssen bewertet worden sein:
Verträge für Prüfung und Fehlerbehebung trennen
Die Vergütung nicht an die Zahl der Feststellungen knüpfen
Den Wiederholungstest nach der Korrektur einem anderen Bewerter übertragen
Die Interessenbindung im Bericht offenlegen
Für den Abschluss kritischer Feststellungen eine zweite Unterschrift vorsehen
Ein Prüfer darf eine Lösung vorschlagen. Er darf aber nicht behaupten, die Organisation müsse gerade sein kommerzielles Lösungsangebot in Anspruch nehmen.
Erklärung zu Interessenkonflikten bei der Prüfung
Jeder Prüfer und jedes Prüfungsteam sollte folgende Beziehungen offenlegen:
Mitwirkung an der Systemgestaltung
Eine fortbestehende Geschäftsbeziehung zur Organisation
Eine vom Prüfergebnis abhängige Vergütung
Den Verkauf von Korrekturleistungen oder Produkten
Eine Beziehung zu einer konkurrierenden Organisation
Provisionen vom geprüften Anbieter
Enge persönliche Beziehungen zu Führungskräften oder Beschäftigten
Eine Partnerschaft mit demselben Modell- oder Werkzeuganbieter
Unmittelbare Reputations- oder Publikationsinteressen am Prüfergebnis
Die Offenlegung beseitigt einen Interessenkonflikt nicht immer. Sie verhindert aber, dass er verborgen bleibt. Manche Konflikte lassen sich handhaben. Andere verlangen, dass sich der Prüfer aus der betreffenden Urteilsentscheidung zurückzieht. Der Entwickler darf beispielsweise technische Nachweise liefern. Das abschließende Urteil über die „unabhängig bestätigte Konformität“ sollte er jedoch nicht unterzeichnen.
Unabhängigkeit schützt auch die geprüfte Organisation
Unabhängigkeit schützt nicht nur den Prüfer vor Druck durch die Organisation. Auch die Organisation muss vor willkürlichem Verhalten des Prüfers geschützt sein. Ein Prüfer darf:
den Umfang nicht ohne Erlaubnis erweitern,
kein schwerwiegendes Urteil ohne stützende Nachweise fällen,
keine Geschäftsgeheimnisse veröffentlichen,
keine Angst schüren, um Korrekturleistungen zu verkaufen,
das Ergebnis eines synthetischen Tests nicht als tatsächlichen Vorfall im Produktivbetrieb darstellen,
das Recht der Organisation auf Stellungnahme nicht behindern.
Unabhängigkeit erlaubt kein Handeln ohne Befugnis. Der Prüfer ist frei, aber nur innerhalb der Grenzen von Nachweisen, Prüfumfang und beruflicher Verantwortung.
Was gehört zum Prüfumfang?
Eine Organisation kann sagen: „Prüfen Sie unseren Vertriebsagenten.“ Das reicht nicht aus. Ein Vertriebsagent kann folgende Aufgaben übernehmen:
Webrecherche
Bewertung, ob ein Unternehmen als Interessent passt
Suche nach Ansprechpersonen
Datenanreicherung
E-Mail-Entwürfe
E-Mail-Versand
WhatsApp-Nachrichten
Terminplanung
Preisvorschläge
CRM-Einträge
Nachfasskommunikation
Aufrufe von Unteragenten
Welche dieser Aufgaben sind erfasst? In welchen Sprachen und Ländern? Mit welchen Konten und Datenklassen? In welcher Umgebung? Welche Rollen übernehmen die beteiligten Menschen? Der Prüfumfang besteht nicht bloß aus dem Namen eines Agenten. Er begrenzt, wie weit das Prüfungsurteil reicht.
Die neun Dimensionen des Prüfumfangs
Im NOMOS GBO Prüfprotokoll muss der Umfang anhand von mindestens neun Dimensionen festgelegt werden.
1. System
Welche Modelle, Agenten, Unteragenten und welche Orchestrierung?
2. Verhalten
Recherche, Empfehlung, Entwurf, Versand, Zahlung, Veröffentlichung, Löschung oder Stopp?
3. Werkzeuge
Welche E-Mail-, CRM-, Datei-, Browser-, Zahlungs- oder Veröffentlichungswerkzeuge?
4. Daten
Welche öffentlichen, internen, personenbezogenen, sensiblen oder biometrischen Daten?
5. Menschen
Welche Nutzer, Beschäftigten, Kunden oder betroffenen Gruppen?
6. Sprache und Geografie
Welche Sprachen, Länder, Regionen und rechtlichen Rahmenbedingungen?
7. Umgebung
Lokal, Test, Schattenbetrieb, begrenzter Livebetrieb oder vollständiger Produktivbetrieb?
8. Zeit
Welche Daten, Versionen, Aufgabenzeiträume und Warteschlangen?
9. Lebenszyklus
Welche Phasen: Start, Fortsetzung, Übergabe, Stopp, Rücknahme, Einspruch und Neustart? Bleibt eine dieser Dimensionen offen, kann das Prüfungsurteil unzulässig ausgeweitet werden.
Warum sind ausgeschlossene Bereiche wichtig?
Prüfberichte benennen häufig, was erfasst ist. Ausschlüsse landen in einer kleinen Fußnote. Für das Verständnis des Urteils sind ausgeschlossene Verhaltensweisen jedoch mindestens so wichtig wie die geprüften. Ein Einkaufsagent könnte beispielsweise:
bei einmaligen Käufen getestet worden sein,
bei automatischen Verlängerungen nicht getestet worden sein,
bei Kündigungen nicht getestet worden sein,
nur mit drei freigegebenen Anbietern geprüft worden sein.
Lautet die öffentliche Aussage „Der Einkaufsagent wurde geprüft“, können Nutzer annehmen, der gesamte Einkaufslebenszyklus sei bewertet worden. Treffender wäre: „Geprüft wurde das Verhalten des Agenten bei einmaligen, rückgängig zu machenden Käufen mit geringem Risiko bei drei freigegebenen Anbietern. Abonnements, Verlängerungen, Kündigungen und das Verhalten gegenüber neuen Anbietern sind ausgeschlossen.“ Für jeden wesentlichen Ausschluss müssen drei Fragen beantwortet werden:
Warum wurde der Bereich ausgeschlossen?
Welches Risiko bleibt bestehen?
Wie begrenzt der Ausschluss die Prüfaussage?
Außerhalb des Prüfumfangs heißt nicht sicher
Wird eine Verhaltensweise ausgeschlossen, sind drei Fehlinterpretationen möglich.
Fehlinterpretation 1
„Es wurde nicht getestet, also gibt es kein Problem.“ Richtig ist: Ob es ein Problem gibt, ist unbekannt.
Fehlinterpretation 2
„Es liegt außerhalb des Prüfumfangs, also ist es unwichtig.“ Richtig ist: Es könnte gerade wegen seines Risikos ausgeschlossen worden sein.
Fehlinterpretation 3
„Wenn das Hauptsystem bestanden hat, würde der ausgeschlossene Teil wahrscheinlich auch bestehen.“ Richtig ist: Verhalten mit anderen Werkzeugen, Befugnissen oder Daten kann zu einem anderen Ergebnis führen. Ein ausgeschlossener Bereich ist weder ein positives noch ein negatives Urteil, sondern eine ausdrücklich benannte Ungewissheit.
Irreführende Ausweitung des Prüfumfangs
Eine Organisation kann den sichersten Teil ihres Systems prüfen lassen und das Ergebnis für das gesamte System verwenden. Zum Beispiel:
Nur der Entwurfsagent wird getestet.
Veröffentlicht wird das Ergebnis als „Das Vertriebsagentensystem wurde geprüft“.
Nur die Testumgebung wird bewertet.
Dargestellt wird das Ergebnis als „Das Livesystem ist sicher“.
Nur englische Szenarien werden ausgeführt.
Verkündet wird das Ergebnis als „Der mehrsprachige Agent ist konform“.
Nur der zentrale Agent wird untersucht.
Das Ergebnis wird auf das gesamte Netz der Unteragenten übertragen.
Nur positive Szenarien werden verwendet.
Das Ergebnis wird als Nachweis für verlässliche Befugniskontrolle und Stoppfähigkeit dargestellt.
Dieses Vorgehen lässt sich so bezeichnen:
Irreführende Ausweitung des Prüfumfangs
Dabei wird das Ergebnis einer engen, einfachen oder risikoarmen Prüfung als Vertrauensnachweis für ein umfassenderes System, weitere Verhaltensweisen, Sprachen oder Risikobereiche ausgegeben. Das ist irreführende Berichterstattung. Selbst wenn das technische Ergebnis stimmt, ist die der Öffentlichkeit vermittelte Bedeutung falsch.
Den Prüfumfang auf günstige Beispiele beschränken
Eine Organisation kann gezielt nur ihre starken Bereiche auswählen. Zum Beispiel:
Freigegebene Anbieter werden einbezogen.
Neue und noch unklare Anbieter werden ausgeschlossen.
Menschlich freigegebene Aktionen werden getestet.
Die Grenzen ohne vorliegende Freigabe werden nicht getestet.
Englisch wird einbezogen.
Schwächere Sprachversionen bleiben außen vor.
Die Testumgebung wird verwendet.
Token-Berechtigungen im Livebetrieb werden nicht untersucht.
Der Hauptagent wird getestet.
Die Delegation von Befugnissen an Unteragenten wird ausgeschlossen.
Nicht jede Eingrenzung ist falsch. Ressourcen und Risiken können eine schrittweise Prüfung erfordern. Problematisch wird die Auswahl, wenn sie das Ergebnis besser erscheinen lassen soll, als es ist, und nicht offengelegt wird. Dafür lässt sich folgende Bezeichnung verwenden:
Beschränkung des Prüfumfangs auf günstige Beispiele
Eine Organisation darf eine begrenzte Prüfung durchführen. Sie muss aber erklären, warum sie begrenzt ist und welches Risiko zurückbleibt.
Einen riskanten Bereich ausschließen
Manche Verhaltensweisen mit weitreichenden Folgen sind praktisch schwer zu prüfen. Echte Zahlungen sind womöglich unerwünscht. Die Kommunikation mit tatsächlichen Kunden ist riskant. Die Erzeugung biometrischen Materials ist sensibel. Statt diese Verhaltensweisen vollständig auszuschließen, lassen sich sichere Simulationen einsetzen:
Ein Testzahlungsmittel
Eine E-Mail-Adresse für die Prüfung
Ein synthetischer Kunde
Ein künstlicher Avatar mit entsprechender Erlaubnis
Gesonderte Testwarteschlangen
Schattenbetrieb
Ein kontrolliertes Live-Testkonto (Canary): ein eng begrenztes Testkonto im Livebetrieb, dessen schriftlicher Umfang, Datengrenzen und Stoppverfahren vorab festgelegt sind.
Ist ein direkter Livetest des riskanten Verhaltens nicht möglich, können folgende Elemente kombiniert werden:
Technische Berechtigungen,
Konfiguration,
synthetisches Verhalten,
Nachweise aus früheren Vorfällen,
eine begrenzte Canary-Validierung.
Entweder wird die Prüfung sicher gestaltet, oder das Urteil muss ausdrücklich begrenzt werden.
Repräsentativer und vollständiger Prüfumfang
Kein System lässt sich in allen denkbaren Szenarien testen. Eine Prüfung darf mit Stichproben arbeiten, doch sie müssen repräsentativ sein. Ein System mit sechs Sprachen kann beispielsweise in zwei Sprachen vollständig und in den übrigen vier mit einer begrenzten Szenarioauswahl getestet werden. Das ist möglich. Die Auswahl muss sich aber auf folgende Kriterien stützen:
Sprachfamilie
Rechts-nach-links-Schreibrichtung
Unterschiede in der kaufmännischen Terminologie
Bisherige Fehlerquote
Nutzungsvolumen
Risiko
Wenn Arabisch ein eigenes RTL- und Sprachverhalten des Systems hervorruft, können englische Ergebnisse es nicht angemessen abdecken. Ebenso wenig kann eine risikoarme Produktsuche ein risikoreiches Zahlungsverhalten repräsentieren. Stichproben können die Testzahl verringern, aber Verhaltensunterschiede nicht außer Acht lassen. Die Methode zur Auswahl von Szenarien wird in Kapitel sechs ausführlich entwickelt.
Warum muss der Prüfumfang festgeschrieben werden?
Ändert sich das System während der Prüfung laufend, ist nicht mehr erkennbar, welche Version geprüft wurde. Ein Szenario schlägt fehl. Der Entwickler ändert eine Anweisung. Der nächste Testlauf ist erfolgreich. Der Bericht zeigt nur das letzte Ergebnis. Dadurch bleibt bei folgenden Fragen unklar, worauf sich die Antwort bezieht:
Ist das ursprüngliche System durchgefallen?
Hat das neue System bestanden?
Welche Version wird öffentlich angeboten?
Welche Version läuft im Livebetrieb?
Korrekturen sind nicht verboten. Im Gegenteil: Verbesserung ist eines der Prüfziele. Das erste Ergebnis darf aber nicht gelöscht werden, und die neue Version muss gesondert geprüft werden. Deshalb wird vor Beginn der Prüfung das folgende Protokoll erstellt:
Protokoll des festgeschriebenen Prüfumfangs
Was dokumentiert das Protokoll des festgeschriebenen Prüfumfangs?
Mindestens folgende Elemente müssen erfasst werden:
Agenten- und Modellversion
System- und Entwickleranweisungen
Die Befugnisvereinbarung
Die Werkzeugliste
API-Berechtigungen
Dienstkonten
Unteragenten
Gedächtnisstruktur und der maßgebliche aktuelle Zustand
Kanonische Datenquellen
Rollen der beteiligten Menschen
Die Testumgebung
Unterschiede zur Liveumgebung
Sprachversionen
Messkonfiguration
Das Stopp- und Wiederherstellungssystem
Hashes kritischer Dateien oder Konfigurationen
Beginn und Ende der Prüfung
Nicht jedes Detail muss vollständig kopiert und aufbewahrt werden. Es müssen aber Versionskennungen vorliegen, die belegen, zu welchem System das Ergebnis gehört.
Was geschieht bei Änderungen während der Prüfung?
Änderungen lassen sich in drei Klassen einteilen.
Klasse A — Unwesentliche Änderung
Eine Rechtschreibkorrektur oder Erläuterung, die das geprüfte Verhalten nicht beeinflusst. Sie wird dokumentiert. Die Prüfung kann weiterlaufen.
Klasse B — Wesentliche Änderung mit begrenzter Wirkung
Eine Werkzeug-, Anweisungs- oder Befugnisänderung, die einen bestimmten Testbereich betrifft. Die entsprechenden Szenarien werden mit der neuen Version erneut ausgeführt. Das bisherige Ergebnis bleibt erhalten.
Klasse C — Wesentliche Änderung an den Grundlagen
Änderungen am Modell, an den Handlungsbefugnissen, der Unteragentenarchitektur, der Datenquelle oder dem Stoppsystem machen die bisherige Festschreibung ungültig. Eine neue Prüfungsversion oder ein neuer Ausgangsstand ist erforderlich. Wird etwa nach einem Versand ohne Freigabe die Berechtigung send_message entfernt, ist das eine sinnvolle Korrektur. Über das ursprüngliche System darf dann aber nicht berichtet werden: „Es lag kein Verstoß vor.“ Die korrekte Dokumentation lautet:
v2.4: Versand ohne Freigabe beobachtet. Korrektur: Versandwerkzeug entfernt. Wiederholungstest v2.5: In den 24 betreffenden Szenarien wurde kein Versand beobachtet.
Diese Dokumentation zeigt nicht die Schwäche der Organisation, sondern ihre Lernfähigkeit.
Stillschweigende Korrektur während der Prüfung
Nach einem fehlgeschlagenen Test kann der Entwickler das System im Hintergrund ändern und unter derselben Kennung erneut ausführen. Das Ergebnis wird dann womöglich als „Am Ende hat es den Test bestanden“ dargestellt. Damit ist jedoch die Integrität der Prüfung beschädigt. Dieses Vorgehen lässt sich so bezeichnen:
Stillschweigende Korrektur während der Prüfung
Für jede Änderung müssen folgende Angaben dokumentiert werden:
Datum,
ausführende Person oder ausführender Agent,
Begründung,
betroffene Szenarien,
neue Version.
Eine Prüfung soll nicht das Bild eines makellosen Systems erzeugen. Sie soll das tatsächliche Verhalten und den Weg zur Verbesserung sichtbar machen.
Erstes Hauptdokument: Prüfermächtigung
Nach dem Blatt zur Prüfaussage wird das folgende Dokument erstellt:
NOMOS GBO Prüfermächtigung
Dieses Dokument legt den Handlungsspielraum des Prüfers und die Verantwortung der Organisation fest.
PRÜFERMÄCHTIGUNG — MENSCHENLESBARES BEISPIEL
Prüfungskennung: GBO-AUDIT-2026-001
Antragsteller: NobleAxis Betriebsleitung
Ermächtigende Person: Name, Rolle und Grundlage der Vertretungsbefugnis
Systemverantwortlicher: Leitung des Vertriebsbetriebs
Technisch Verantwortlicher: Leitung der Agentensysteme
Zuständige Person für die Datennutzung: Benannter operativer Ansprechpartner; der datenschutzrechtlich Verantwortliche und ein etwaiger Auftragsverarbeiter werden gesondert erfasst.
Prüfer: Unabhängiges GBO Prüfungsteam
Prüfziel: Das Verhalten des Agenten zur Interessentensuche bei Recherche, Entwurf, menschlich freigegebenem Versand und Stopp bewerten.
Erlaubte Prüfhandlungen:
Dokumentenprüfung
Nur lesende Prüfung von Berechtigungen und Protokollen
Einsatz synthetischer Unternehmen und Empfänger
Kontrollierte Nachrichten an die Prüf-E-Mail-Adresse
Befugnistests für Unteragenten
Übung zum Stoppen von Warteschlangen
Tests mit externen Anweisungen in der Prüfumgebung
Tests im Livesystem ausschließlich über das vorab festgelegte Canary-Konto
Verbotene Prüfhandlungen:
Nachrichten an tatsächliche Kunden
Echte Zahlungen
Löschen von Kundendaten im Livebetrieb
Unbefugtes Kopieren personenbezogener Daten
Veröffentlichen öffentlich zugänglicher Inhalte
Unangekündigtes Stoppen des Produktivsystems
Hochladen von Prüfdaten in ein externes KI-System ohne Freigabe
Notstoppbefugnis des Prüfers: Neue Vorgänge vorübergehend aussetzen, wenn ein fortlaufender unbefugter externer Versand, eine unbefugte Übertragung personenbezogener Daten oder eine unkontrollierte Handlung mit weitreichenden Folgen beobachtet wird; den Vorfallverantwortlichen der Organisation unverzüglich benachrichtigen.
Aufbewahrungsplan für Nachweise: Dieses synthetische Beispiel sieht 180 Tage, verschlüsselte Speicherung und einen Löschbeleg vor. Diese Frist ist keine allgemeine gesetzliche Pflicht. Der konkrete Zweck, die Datenart und die geltenden Verpflichtungen sind gesondert zu bewerten. Bei einem laufenden Streit oder einer Aufbewahrungspflicht muss die Frist begründet erneut geprüft werden.
Einsatz von Unterauftragnehmern oder KI-Werkzeugen: Offengelegt, genehmigt und mit festgelegten Datengrenzen.
Recht der Organisation auf Stellungnahme: Zu jeder Feststellung kann sie innerhalb einer festgelegten Frist Nachweise und Erläuterungen vorlegen.
Vetorecht der Organisation gegen Feststellungen: Keines. Ein nachgewiesener sachlicher Fehler kann berichtigt werden. Eine nachweisgestützte Feststellung darf nicht aus kommerziellen Gründen entfernt werden.
Öffentliche Erklärung: Veröffentlicht werden darf nur eine freigegebene Zusammenfassung mit tatsächlichem Umfang, Version, Datum und ausdrücklichen Einschränkungen.
Beginn und Ende der Ermächtigung: 1. September 2026, 09:00 Uhr, bis 15. September 2026, 18:00 Uhr, türkische Zeit (UTC+03:00). Spätere Wiederholungstests erfordern eine neue oder ausdrücklich erneuerte Ermächtigung.
Voraussetzung für eine erneute Ermächtigung: Ändern sich der Umfang oder die Handlungsebene, ist eine neue Ermächtigung erforderlich.
Maschinenlesbare Prüfermächtigung
audit_authorization:
audit_id: GBO-AUDIT-2026-001
authorized_by:
role: authorized_system_owner
authority_basis: internal_governance_record
system_owner:
role: sales_operations_owner
technical_owner:
role: agent_platform_owner
auditor:
identity: independent_audit_team
independence_level: III
permitted_actions:
- document_review
- read_only_permission_review
- synthetic_entity_testing
- controlled_email_to_audit_address
- subagent_authority_test
- queue_stop_drill
- prompt_injection_test
- controlled_live_testing_only_in_pre_authorized_canary_account
prohibited_actions:
- contact_real_customer
- execute_real_payment
- delete_live_customer_data
- publish_public_content
- upload_evidence_to_unapproved_ai_service
- unannounced_production_shutdown_outside_emergency_scope
data_scope:
allowed:
- public_company_data
- masked_transaction_logs
- synthetic_customer_records
prohibited:
- unrelated_personal_data
- unrestricted_full_mailbox_export
emergency_stop:
permitted: true
limited_to_containment_of_in_scope_new_actions: true
immediate_notification_to_incident_owner: required
triggers:
- unauthorized_live_send
- prohibited_data_exfiltration
- uncontrolled_high_impact_action
evidence_retention:
duration_days: 180
encryption_required: true
deletion_receipt_required: true
example_duration_not_universal_legal_rule: true
review_on_ongoing_dispute_or_preservation_duty: required
external_ai_or_subcontractor_use:
prior_disclosure: required
explicit_approval: required
defined_data_boundary: required
public_disclosure:
scope_limited: true
client_review_for_factual_errors: true
client_veto_over_findings: false
valid_from: 2026-09-01T09:00:00+03:00
valid_until: 2026-09-15T18:00:00+03:00Das Dokument begrenzt die Befugnisse des Prüfers. Technische Zugriffe und Testkontrollen müssen entsprechend eingerichtet werden, damit diese Grenzen gewahrt bleiben.
Zweites Hauptdokument: Protokoll des festgeschriebenen Prüfumfangs
Nach der Prüfermächtigung wird der gegenwärtige Zustand des Systems erfasst.
PROTOKOLL DES FESTGESCHRIEBENEN PRÜFUMFANGS — BEISPIEL
Prüfungskennung: GBO-AUDIT-2026-001
Zeitpunkt der Festschreibung: 1. September 2026, 09:30 Uhr
Zentraler Agent: SALES-RESEARCH-v2.4
Version des Basismodells: Erfasste technische Kennung
Systemanweisung: POLICY-v3.1 — Hash erfasst
Befugnisvereinbarung: AUTH-v2.7
Unteragenten:
Web Research v1.8
Recipient Resolution v1.4
Email Drafting v2.1
Approved Send v1.3
Queue Manager v1.2
Verbundene Werkzeuge:
Websuche
CRM: Lesen/Schreiben
Gmail: Entwurf/Versand
Kalender
Aufgabenwarteschlange
Tatsächliche API-Berechtigungen: Für jedes Werkzeug erfasst.
Gedächtniszustand: Dauerhaftes Präferenzgedächtnis aktiviert; personenbezogene Kundendaten dürfen nicht im Gedächtnis gespeichert werden.
Kanonische Datenquellen:
Leistungskatalog v4.2
Preisregister v3.7
Register menschlicher Befugnisse v2.5
Kommunikationsrichtlinie v3.0
Erfasste Sprachen: Englisch, Türkisch, Deutsch
Ausgeschlossene Sprachen: Arabisch, Spanisch, Russisch
Testumgebung: Synthetisches CRM und Prüf-E-Mail-Adressen.
Begrenzter Livebereich: Echte Gmail-Infrastruktur; Versand ausschließlich an die Prüfdomäne.
Stoppsystem: Zentraler Agent, Unteragenten, Warteschlange und Gmail-Versandtoken.
Wiederherstellungspunkt: Werkzeug- und Befugnismanifest vor Beginn der Prüfung.
Auslöser wesentlicher Änderungen:
Modelländerung
Änderung des Versandwerkzeugs
Neuer Unteragent
Änderung der Befugnisrichtlinie
Änderung des dauerhaften Gedächtnisses
Neue Sprache
Nutzung echter Kundendaten im Livebetrieb
Unterschriften zur Festschreibung: Systemverantwortlicher, technisch Verantwortlicher, Prüfer.
Was aus dem festgeschriebenen Prüfumfang folgt
Ein festgeschriebenes System muss nicht wie ein Museumsstück völlig regungslos bleiben. Der tägliche Betrieb darf weitergehen. Die Identität der geprüften Version muss jedoch erhalten bleiben. Ändert sich das Livesystem, bestehen folgende Möglichkeiten:
Die Prüfungsversion kann in einer gesonderten Umgebung erhalten bleiben.
Die Änderung kann dokumentiert werden.
Die relevanten Tests können erneut ausgeführt werden.
Das Prüfurteil kann eingegrenzt werden.
Entscheidend ist, dass erkennbar bleibt, welches Ergebnis zu welcher Version gehört.
Erklärung zu Unabhängigkeit und Prüfumfang
Der Prüfbericht muss eine gesonderte Erklärung enthalten:
Erklärung zu Unabhängigkeit und Prüfumfang
Beispiel: „Das Prüfungsteam war nicht an der Entwicklung des geprüften Systems beteiligt. Die Vergütung hängt nicht vom Prüfergebnis ab. Das Team darf Korrekturleistungen anbieten; die Tests zum Abschluss kritischer Feststellungen übernimmt eine andere prüfende Person. Geprüft wird das Verhalten bei der Interessentensuche auf Englisch, Türkisch und Deutsch. WhatsApp, finanzielle Angebote, Vertragsannahme sowie das Verhalten auf Arabisch, Spanisch und Russisch sind ausgeschlossen. Es wurden keine tatsächlichen Kunden kontaktiert, sondern kontrollierte Prüfadressen verwendet.“ Diese Erklärung darf kurz sein, aber keine wesentlichen Beziehungen verschweigen.
Das Recht der Organisation auf Stellungnahme
Prüffeststellungen können falsch sein. Der Prüfer könnte ein wichtiges Dokument übersehen, den Zweck einer Handlung missverstanden oder ein technisches Protokoll unvollständig ausgewertet haben. Deshalb muss die Organisation zu jeder Feststellung Stellung nehmen können. Möglich sind:
Neue Nachweise
Berichtigung eines sachlichen Fehlers
Erläuterung des Prüfumfangs
Technischer Kontext
Risikoakzeptanz
Ein Korrekturplan
Eine abweichende Auffassung
Im Abschlussbericht können folgende Positionen getrennt dargestellt werden:
FESTSTELLUNG DES PRÜFERS STELLUNGNAHME DER ORGANISATION ABSCHLIESSENDE BEWERTUNG DES PRÜFERS
Das Recht auf Stellungnahme ist kein Recht, eine Feststellung entfernen zu lassen. Umgekehrt darf der Prüfer die Antworten der Organisation nicht ignorieren.
Meinungsverschiedenheiten
Die Bewertung mancher Verhaltensweisen ist nicht eindeutig. Zum Beispiel:
Ist für einen bestimmten Vorgang eine menschliche Freigabe erforderlich?
Steht eine Datennutzung noch in hinreichendem Zusammenhang mit dem ursprünglichen Zweck?
Ist ein Anbieter tatsächlich eine unabhängige Quelle?
Ist eine Änderung wesentlich?
Die Beteiligten müssen nicht zu einer Einigung kommen. Der Bericht darf dann keinen Scheinkonsens erzeugen. Er könnte festhalten:
Auffassung des Prüfers: Der neue Verwendungszweck geht über die ursprüngliche Einwilligung hinaus. Auffassung der Organisation: Die Nutzung ist vom bestehenden Zweck der Serviceentwicklung gedeckt. Status: Ungeklärte Feststellung zur Zweckbindung mit hoher Priorität. Empfohlen werden die Aussetzung der betreffenden Datennutzung und eine fachliche Prüfung.
Ein sichtbarer Dissens ist kein Glaubwürdigkeitsmangel. Er dokumentiert ehrlich, wo sich die Wahrheit schwer feststellen lässt.
Wer trägt das Restrisiko?
Der Prüfer berichtet eine Feststellung. Die Organisation kann den Mangel womöglich nicht sofort beheben. Ein bestimmtes Risiko kann vorübergehend akzeptiert werden. Zum Beispiel:
In einer risikoarmen Testumgebung kann ein weitreichender Zugriff kurzzeitig bestehen bleiben.
Ein Altsystem kann bis zum Abschluss der Migration weiterlaufen.
Eine bestimmte Sprachversion kann auf den Wiederholungstest warten.
Risiken zu akzeptieren ist nicht Aufgabe des Prüfers. Er:
benennt das Risiko,
belegt es,
erläutert seine Bedeutung,
spricht eine Empfehlung aus.
Eine befugte Person der Organisation entscheidet über die Risikoakzeptanz. Diese muss:
befristet sein,
begründet sein,
klar begrenzt sein,
einen Termin zur erneuten Bewertung enthalten.
Ein Agent oder Entwickler darf das in seiner eigenen Feststellung benannte Risiko nicht allein akzeptieren. Risikoakzeptanz bedeutet nicht, dass das Risiko verschwunden ist. Sie zeigt, wer für welchen Zeitraum Verantwortung übernimmt.
KI-Werkzeuge in der Prüfung
Auch ein GBO-Prüfer kann KI-Werkzeuge nutzen. Agenten können beispielsweise:
Protokolle klassifizieren,
ähnliche Vorfälle gruppieren,
mehrsprachige Texte vergleichen,
Testvarianten erzeugen,
das Nachweisregister ordnen,
Widersprüche finden.
Das ist effizient. Doch auch Prüfagenten unterliegen dem Protokoll. Folgende Fragen müssen beantwortet werden:
Welches Modell wurde verwendet?
Auf welche Daten hatte es Zugriff?
Wurden Nachweise an ein externes System übermittelt?
Hat ein Mensch die Ausgabe überprüft?
Ist die Klassifikation des Agenten eine abschließende Feststellung oder ein Vorschlag?
Hat sich der Prüfagent selbst bestätigt?
Welche Version wurde verwendet?
Wie wird mit einem Fehler oder Datenschutzvorfall umgegangen?
Ein Prüfer kann sich nicht auf die Aussage beschränken: „Die KI hat sämtliche Protokolle ausgewertet und kein Problem gefunden.“ Das ist nur die Aussage eines weiteren Systems. Es muss klar bleiben, welcher Mensch und welche Organisation das abschließende Urteil verantworten.
Prüfnachweise bewahren
Unabhängigkeit bedeutet nicht nur Zugang zu Nachweisen. Auch der Schutz vor nachträglichen Änderungen ist wichtig. Mindestens folgende Informationen können aufbewahrt werden:
Quellenkennung
Zeitpunkt der Übernahme
Version
Hash oder Integritätsnachweis
Maskierungsverfahren
Personen mit Zugriff
Vorgenommene Umwandlungen
Aufbewahrungsfrist
Löschprotokoll
Der Prüfer sollte keine Kopie sämtlicher Livedaten unbegrenzt aufbewahren. Die Grundlage einer kritischen Feststellung muss sich aber später rekonstruieren lassen. Aufbewahrung und Nachweiskette werden in Kapitel vier ausführlich behandelt.
Das Zusammenspiel von Befugnis, Unabhängigkeit und Umfang
Diese drei Begriffe wirken getrennt. Tatsächlich begrenzen sie einander.
Befugnis
Was darf der Prüfer tun?
Unabhängigkeit
Wie frei und ehrlich kann der Prüfer das Beobachtete bewerten?
Prüfumfang
Über welches System und welche Verhaltensweisen darf der Prüfer urteilen? Er kann weitreichende Befugnisse besitzen. Hängt er finanziell vom Ergebnis ab, sinkt jedoch das Vertrauen in seine Bewertung. Er kann unabhängig sein. Kann er die technischen Berechtigungen nicht einsehen, sinkt das Nachweisniveau. Der Umfang kann breit gefasst sein. Fehlt die Befugnis für Livetests, bleibt das Verhaltensurteil dennoch begrenzt. Eine vertrauenswürdige Prüfung lässt sich deshalb so beschreiben:
VERTRAUENSWÜRDIGE PRÜFUNG = GÜLTIGE BEFUGNIS UND ABGESICHERTE UNABHÄNGIGKEIT UND KLARER UMFANG UND AUSREICHENDER ZUGANG ZU NACHWEISEN UND BEFUGNIS FÜR SICHERE TESTS UND BEGRENZTE ÖFFENTLICHE ERKLÄRUNG
Keines dieser Elemente ersetzt ein anderes.
Befugnis- und Unabhängigkeitsprüfung vor dem Start
Vor Testbeginn müssen die folgenden Prüfschranken passiert werden:
1. Prüfschranke: Ermächtigende Stelle
Besitzt die Person oder Organisation, die die Prüfung verlangt, tatsächlich die nötige Befugnis?
2. Prüfschranke: Systemverantwortung
Sind die menschlichen und technischen Verantwortlichen des geprüften Systems benannt?
3. Prüfschranke: Datenbefugnis
Auf welcher legitimen und begrenzten Grundlage darf der Prüfer die erforderlichen Daten einsehen?
4. Prüfschranke: Handlungsbefugnis
Welche Befugnisstufe gilt für Dokumentenprüfung, synthetische Tests, Livetests und Stopp?
5. Prüfschranke: Schadensgrenzen
Welche Auswirkungen kann die Prüfung auf reale Menschen, Geld, Daten oder den Betrieb haben?
6. Prüfschranke: Unabhängigkeit
Wie unabhängig ist die Prüfung organisatorisch, finanziell, technisch und in der Bewertung?
7. Prüfschranke: Interessenkonflikte
Sind Beziehungen offengelegt, die den Bau, die Korrektur oder den Verkauf des Systems oder die Vermarktung des Ergebnisses betreffen?
8. Prüfschranke: Vollständiger Umfang
Sind System, Verhalten, Werkzeuge, Daten, Sprachen, Umgebung und Lebenszyklus ausdrücklich definiert?
9. Prüfschranke: Ausgeschlossene Risiken
Sind wesentliche ausgeschlossene Bereiche und ihre Auswirkungen sichtbar?
10. Prüfschranke: Festschreibung
Sind die geprüfte Version und Konfiguration festgehalten?
11. Prüfschranke: Notstopp
Wer stoppt das System wie, wenn während der Prüfung im Livebetrieb Schäden auftreten?
12. Prüfschranke: Öffentliche Erklärung
Könnte das Ergebnis über seinen tatsächlichen Umfang hinaus dargestellt werden? Vereinfacht gilt:
BEFUGNIS ZUM PRÜFUNGSSTART = BEFUGTER AUFTRAG UND BENANNTER SYSTEMVERANTWORTLICHER UND BEGRENZTER DATENZUGRIFF UND AUSDRÜCKLICHE TESTBEFUGNIS UND GEREGELTE INTERESSENKONFLIKTE UND FESTGESCHRIEBENER UMFANG UND SICHERER STOPP UND EHRLICHE ÖFFENTLICHE ERKLÄRUNG
Fehlen die Befugnis oder sichere Testbedingungen, darf die betreffende Handlung nicht beginnen. Die Prüfung kann nur in einem engeren Umfang fortgesetzt werden, in dem sowohl die gültige Befugnis als auch sichere Bedingungen erhalten bleiben. Methode und Urteil sind entsprechend zu begrenzen.
Ermächtigungsstatus einer Prüfung
Eine Prüfung kann einen der folgenden Status haben:
Ermächtigt
Die erforderlichen menschlichen, systembezogenen, datenbezogenen und testbezogenen Befugnisse liegen vor.
Bedingt ermächtigt
Die Prüfung darf innerhalb bestimmter Daten-, Umgebungs- oder Handlungsgrenzen stattfinden.
Nur zur Dokumentenprüfung ermächtigt
Es besteht keine Befugnis für technische oder verhaltensbezogene Tests. Das Urteil ist auf Aussagen und Dokumente beschränkt.
Unzureichende Befugnis
Der Zugang oder das Testrecht zur Überprüfung der gewünschten Aussage fehlt.
Ausgesetzt
Die Prüfung wurde wegen einer wesentlichen Systemänderung, eines Vorfalls oder eines Befugnisproblems vorübergehend gestoppt.
Abgebrochen
Die Integrität der Prüfung, die Sicherheit der Nachweise oder die Ermächtigungsbedingungen lassen sich nicht mehr aufrechterhalten. Diese Zustände sind ausdrücklich zu berichten. Kann eine Prüfung nicht abgeschlossen werden, sollte nicht bloß „Nicht bestanden“ stehen. Der Bericht muss zeigen, warum kein Urteil möglich war.
Prüftheater
Eine Organisation kann Folgendes vorlegen:
Eine fehlerfreie Demo
Ausgewählte Bildschirmaufnahmen
Eine hohe Erfolgsbewertung
Positive Kundenbewertungen
Eine sorgfältig ausgearbeitete Richtlinie
Ein Prüfsiegel
Kann die prüfende Person jedoch Folgendes nicht einsehen:
die tatsächlichen Berechtigungen,
die fehlgeschlagenen Tests,
die Unteragenten,
die Warteschlangen,
die ausgeschlossenen Bereiche,
die Vorfallsaufzeichnungen,
wird aus der Arbeit:
Prüftheater
Prüftheater entsteht, wenn der Anschein von Vertrauenswürdigkeit wichtiger wird als Verhaltensnachweise. Typische Anzeichen sind:
Nur die Organisation wählt die Tests aus.
Das System wird während der Tests stillschweigend verändert.
Ergebnisse fehlgeschlagener Tests werden aus dem Bericht entfernt.
Die prüfende Person kann die öffentliche Erklärung nicht frei verfassen.
Ausgeschlossene Risiken werden verschwiegen.
Das Siegel ist sichtbarer als der vollständige Bericht.
Die Vergütung oder Fortsetzung der Prüfung hängt vom Ergebnis »bestanden« ab.
Statt unverarbeiteter Nachweise wird eine vorbereitete Präsentation gezeigt.
Das GBO-Protokoll muss auch die Prüfung selbst vor diesen Risiken schützen.
Den Prüfumfang öffentlich ehrlich darstellen
Wird ein Prüfergebnis veröffentlicht, müssen vier Aussagen auseinandergehalten werden:
Geprüft
Eine bestimmte Untersuchung hat stattgefunden.
In einem definierten Umfang bestanden
Für die festgelegten Verhaltensweisen und Szenarien wurden die Bedingungen erfüllt.
Bedingt geeignet
Das System kann unter Berücksichtigung bestimmter Feststellungen oder Nutzungsbeschränkungen eingesetzt werden.
Wegen einer kritischen Feststellung nicht geeignet
In einem bestimmten Verhaltensbereich ist das System noch nicht einsatzbereit. Pauschale Aussagen wie diese sind zu vermeiden:
»Vollständig GBO-konform.« »Bei allen Agenten sicher.« »Macht keine Fehler.« »Menschliche Kontrolle garantiert.« »Gegen alle 99 Fehler geschützt.«
Stützen die Nachweise nur eine bestimmte Version und einen bestimmten Prüfumfang, muss auch die öffentliche Erklärung innerhalb dieser Grenzen bleiben.
Das Urteil dieses Kapitels
Eine GBO-Prüfung beginnt nicht mit technischen Tests. Zunächst sind diese Fragen zu beantworten:
Wer hat die Prüfung beantragt? Wer hat sie autorisiert? Hat diese Person tatsächlich das Recht dazu? Auf welche Daten darf die prüfende Person zugreifen? Welche Verhaltensweisen kann sie sicher testen? Wie weit darf sie in das Produktivsystem eingreifen? Darf sie das System stoppen, wenn sie anhaltenden Schaden beobachtet? Welche wirtschaftlichen und institutionellen Interessen hat sie? Welche Verhaltensweisen sind einbezogen, welche ausgeschlossen? Welche Systemversion bleibt während der Tests bestehen? In welchen Grenzen darf das Ergebnis veröffentlicht werden?
Eine Prüfung ohne diese Antworten kann überzeugend wirken. Sie birgt aber drei grundlegende Risiken:
Sie kann unautorisiert sein.
Sie kann von Abhängigkeiten geprägt sein.
Sie kann umfassender dargestellt werden, als sie tatsächlich ist.
Eine Prüfbefugnis ist kein Recht auf unbegrenzten Systemzugriff. Unabhängigkeit berechtigt nicht dazu, beliebige Urteile ohne Bindung an Nachweise und Prüfumfang zu fällen. Ebenso wenig darf der Prüfumfang dazu dienen, einige einfache Szenarien auszuwählen und daraufhin dem gesamten System Vertrauenswürdigkeit zu bescheinigen. Eine verlässliche GBO-Prüfung hält folgendes Gleichgewicht:
Die prüfende Person erhält die nötigen Nachweise. Sie darf aber keine unnötigen Daten an sich nehmen. Sie kann das System realistisch testen. Sie darf dabei aber keinen unkontrollierten Schaden anrichten. Die Organisation kann zu einer Feststellung Stellung nehmen. Sie darf diese aber nicht aus wirtschaftlichen Gründen streichen. Die Prüfung darf begrenzt sein. Sie darf öffentlich aber nicht als unbegrenzt erscheinen. Das System kann korrigiert werden. Das ursprüngliche Versagen darf aber nicht aus der Aufzeichnung verschwinden.
Die erste Schlussfolgerung dieses Kapitels lautet: Das Recht, Verhalten zu prüfen, setzt einen ausdrücklichen und begrenzten Verhaltensvertrag für die Prüfung selbst voraus. Zweitens: Unabhängigkeit bedeutet nicht Beziehungslosigkeit. Sie verlangt, Interessen offenzulegen, mit ihnen kontrolliert umzugehen und ihren Druck auf Feststellungen zu begrenzen. Drittens: Der Prüfumfang muss zeigen, was die Prüfung nicht weiß, ebenso wie das, was sie weiß. Viertens: Eine wesentliche Änderung während der Tests verlangt eine neue Versions- oder Umfangsaufzeichnung. Das ursprüngliche Versagen bleibt dokumentiert; Korrektur und erneuter Test werden gesondert erfasst. Fünftens: Das Ergebnis einer eng begrenzten Prüfung trägt keine Vertrauensaussage über das gesamte Agentennetz, sämtliche Sprachen oder das ganze Risikofeld.
Und zuletzt: Ist die Prüfung selbst unautorisiert, abhängig oder im Umfang unklar, ist auch eine hohe Punktzahl des Agenten kein verlässlicher Nachweis. Nun liegen uns vor:
Das Blatt zur Prüfaussage
Die Prüfermächtigung
Das Protokoll des festgeschriebenen Prüfumfangs
Die Erklärung zu Unabhängigkeit und Prüfumfang
Trotzdem kann das zu prüfende System noch eine Kiste sein, auf der kaum mehr als Namen stehen. Bezeichnungen wie »Vertriebsagent«, »Webagent« oder »CEO-Agent« zeigen nicht die tatsächliche Verhaltensarchitektur. Für welchen Menschen arbeitet der Agent? Welche Unteragenten ruft er auf? Auf welche Werkzeuge kann er zugreifen? Welche Daten stammen aus welchem System? Welche Handlung durchläuft welche menschliche Freigabe? Über welche Warteschlangen und externen Plattformen verteilt sich eine Aufgabe? Welche Stellen muss der Stoppbefehl erreichen? Solange diese Beziehungen nicht kartiert sind, können wir keine passenden Szenarien entwerfen. Wir könnten das falsche Ziel testen, einen kritischen Unteragenten ausschließen oder den tatsächlichen Weg übersehen, auf dem unbefugtes Handeln scheinbar legitimiert wird. Im nächsten Kapitel machen wir das Verhaltensfeld der Prüfung sichtbar:
Verhaltenskarte: Menschen, Agenten, Werkzeuge und Befugnisse
Um ein System zu prüfen, müssen wir zunächst mehr erkennen als nur, was es ist: in wessen Auftrag es handelt, mit welchen Werkzeugen und Daten es arbeitet und über welche Verhaltenskette es auf die Welt einwirkt.
Ein nicht kartiertes Agentensystem wird nicht geprüft. Untersucht wird nur seine sichtbare Oberfläche.