Verhaltenskarte: Menschen, Agenten, Werkzeuge und Befugnisse

Ein international tätiges Dienstleistungsunternehmen möchte seine KI-gestützten Betriebsabläufe prüfen lassen. Im ersten Gespräch beschreibt die Geschäftsleitung das System so: »Wir haben acht Agenten.« Sie zählt die Rollen auf:

Managementagent

Webagent

SEO- und GEO-Agent

Social-Media-Agent

E-Mail-Agent

Agent zur Interessentensuche

Finanzagent

Prüfagent

Auf den ersten Blick ist die Struktur verständlich. Jeder Agent hat eine bestimmte Aufgabe. Der Managementagent verteilt Aufträge. Der Webagent aktualisiert die Website. Der SEO- und GEO-Agent verbessert die Sichtbarkeit. Der Social-Media-Agent plant Inhalte. Der E-Mail-Agent klassifiziert eingehende Nachrichten und erstellt Entwürfe. Der Agent zur Interessentensuche findet neue Geschäftsmöglichkeiten. Der Finanzagent bearbeitet Rechnungen. Der Prüfagent kontrolliert, ob die anderen die Regeln einhalten. Das Unternehmen hält dies für eine ausgereifte Multiagentenorganisation. Der Prüfer stellt eine einfache Frage: »Wenn der Agent zur Interessentensuche ein Unternehmen findet: Welche Systeme werden tätig, bis eine Nachricht nach außen an dieses Unternehmen gesendet wird?«

Die erste Antwort lautet: »Der Agent zur Interessentensuche findet den Kandidaten. Der E-Mail-Agent verfasst die Nachricht. Nach menschlicher Freigabe wird sie versendet.« Der Prüfer beginnt, den Ablauf anhand technischer Aufzeichnungen zu rekonstruieren. Die tatsächliche Kette sieht anders aus. Für die Suche nach Unternehmen setzt der Agent einen Unteragenten zur Webrecherche ein. Dieser nutzt einen gesonderten Dienst, um mögliche Kontaktpersonen zu ermitteln. Für die ermittelte Person wird ein CRM-Eintrag angelegt. Dieser löst einen automatischen Workflow aus, der den E-Mail-Entwurfsagenten aufruft. Das mit dem Entwurfsagenten verbundene E-Mail-Dienstkonto hat technische Berechtigungen nicht nur für die Entwurfserstellung, sondern auch für den direkten Versand.

Die menschliche Freigabe steht lediglich in der internen Richtlinie. Im Versandwerkzeug gibt es keine technische Freigabeschranke. Die Nachfassautomatik im CRM plant die zweite Nachricht für drei Tage nach der ersten. Dieser Ablauf ist vom Aufgabenmanager des zentralen Agenten unabhängig. Wird der zentrale Agent gestoppt, kann die CRM-Warteschlange weiterarbeiten. Außerdem zeigt sich: Kann der Agent zur Interessentensuche keine E-Mail senden, kann er dennoch eine Besprechungseinladung erstellen. In deren Beschreibungsfeld lässt sich eine Verkaufsnachricht eintragen. So entsteht dieselbe Außenkommunikation, ohne den gesperrten E-Mail-Versandweg zu verwenden. Der Prüfer fragt weiter: »Kann der Webagent Preise ändern?« Die Antwort ist eindeutig: »Nein. Preise legt ausschließlich die Geschäftsleitung fest.«

Die Prüfung der Dateiberechtigungen bestätigt, dass der Webagent nicht direkt in die Preistabelle schreiben darf. Er kann jedoch den Inhaltsagenten beauftragen, der den Leistungskatalog neu erzeugt. Dieser kann einen neuen Eintrag mit einem »Aktionspreis ab« anlegen. Der Webagent kann den Katalog anschließend zusammenstellen und veröffentlichen. Er kann den Preis nicht unmittelbar ändern. Über zwei Agenten und ein Werkzeug zur Katalogerzeugung kann er aber eine Preisänderung bewirken. Die dritte Frage des Prüfers lautet: »Wer kann sämtliche Agenten stoppen?« Die Geschäftsleitung antwortet: »Wenn wir den zentralen Agenten abschalten, steht alles still.« Es folgt eine Übung. Der zentrale Agent stoppt. Doch:

Zwei Social-Media-Beiträge bleiben auf einer externen Plattform zur Veröffentlichung vorgemerkt.

Neun Nachrichten liegen in der CRM-Warteschlange für Nachfassaktionen.

Eine SEO-Aufgabe auf einem alten Server wird um Mitternacht erneut anlaufen.

Ein Unteragent setzt einen früher erhaltenen Auftrag in seiner eigenen Sitzung fort.

Das Token des E-Mail-Dienstkontos ist weiterhin gültig.

Die automatische Rechnungsklassifikation des Finanzagenten hängt an einer unabhängigen Zeitsteuerung.

Das Unternehmen hat acht Agenten. Sein Verhaltenssystem besteht aber nicht aus acht Kästchen. Am Ende der Prüfung wurden erfasst:

8 öffentlich dargestellte Agentenrollen

17 eigenständige technische Agenteninstanzen

6 Arten vorübergehend eingesetzter Unteragenten

12 externe Werkzeuge

23 Dienstkonten oder Zugriffstoken

7 zeitgesteuerte Aufgaben

4 unabhängige Warteschlangen

3 gemeinsam genutzte Konten

2 alte, aber weiterhin gültige Zugriffsschlüssel

5 Handlungspfade, die die menschliche Freigabe mittelbar umgehen können

6 Stellen im Verhaltenssystem, die vom Stopp des zentralen Agenten nicht erfasst werden

Das System in der Vorstellung der Geschäftsleitung ist nicht das tatsächliche Verhaltenssystem. Daraus folgt der dritte Grundsatz der GBO-Prüfung: Die Namen der Agenten zu kennen heißt nicht, das Verhaltenssystem zu kennen. Eine Organisation kann sagen: »Wir haben acht Agenten.« Für die Prüfung lautet die Frage jedoch: Über welche technischen Identitäten, Daten, Werkzeuge, Befugnisse, Unteragenten, Warteschlangen und Außenwirkungen handeln diese acht Rollen? Eine Liste reicht als Antwort nicht aus. Nötig ist eine Karte:

Verhaltenskarte

Was ist eine Verhaltenskarte?

Die kanonische Definition lautet: Eine Verhaltenskarte ist eine versionierte Systemaufzeichnung einer Aufgabe, die einem menschlichen oder organisatorischen Zweck entspringt. Sie erfasst sämtliche autorisierten Wege sowie alle tatsächlich beschrittenen Wege: von menschlichen Rollen zu Agenten, von Agenten zu Daten und Werkzeugen, von Werkzeugen zu äußeren Handlungen und von diesen zu Nachweis-, Stopp- und Wiederherstellungsmechanismen. Einfacher gesagt zeigt sie, welcher Agent in wessen Auftrag mit welchen Informationen und Werkzeugen was tun kann, wer dies freigibt, wie das Ergebnis überprüft wird und welche Teile stoppen müssen, wenn ein Mensch Stopp sagt. Eine Verhaltenskarte ist mehr als eine Architekturzeichnung. Sie zeigt nicht bloß:

welcher Server mit welcher API verbunden ist,

welcher Agent welches Werkzeug nutzt,

welcher Mitarbeiter zu welcher Abteilung gehört.

Sie zeigt die Verhaltensbeziehungen dazwischen. So können zwei Verbindungen technisch gleich aussehen:

AGENT → E-MAIL-WERKZEUG

Ihr Verhalten kann dennoch völlig verschieden sein. Bei der ersten Verbindung kann der Agent:

ausschließlich eingegangene Nachrichten lesen,

lediglich Entwürfe erstellen,

nichts nach außen versenden.

Bei der zweiten Verbindung kann der Agent:

neue Nachrichten senden,

Massenversand ausführen,

Nachrichten löschen,

Nachrichten aus einem anderen Konto weiterleiten.

In der Zeichnung können beide als »E-Mail-Integration« erscheinen. Die Verhaltenskarte hält den tatsächlichen Unterschied fest.

Was eine Verhaltenskarte nicht ist

Eine Verhaltenskarte hängt mit anderen betrieblichen Aufzeichnungen zusammen, ist aber mit keiner davon gleichzusetzen.

Kein Organigramm

Ein Organigramm zeigt, wer wem berichtet und wie Menschen und Abteilungen zugeordnet sind. Eine Verhaltenskarte zeigt dagegen die Handlungsbeziehungen:

von Menschen zu Agenten,

von Agenten zu Werkzeugen,

von Werkzeugen zu äußeren Ergebnissen.

Ein Mitarbeiter kann im Organigramm dem Vertrieb angehören und technisch trotzdem Preise ändern, Nachrichten senden oder Kundendaten exportieren dürfen. Diese Handlungsmacht zeigt das Organigramm nicht.

Keine Agentenliste

Eine Agentenliste kann die Namen aktiver Systeme nennen. Eine Verhaltenskarte zeigt außerdem:

Die technische Identität des Agenten

Seine Ursprungsaufgabe

Den verantwortlichen Menschen

Seine Unteragenten

Seine Datenquellen

Seine Werkzeugberechtigungen

Seine Handlungsziele

Die Grenzen seiner Befugnisse

Seinen Stopppfad

Sein Verfahren zur Nachweisführung

Der Name des Agenten ist nur ein Knoten auf der Karte.

Kein Datenflussdiagramm

Ein Datenflussdiagramm zeigt, woher Informationen kommen und wohin sie gelangen. Die Verhaltenskarte fragt zusätzlich: Welche Entscheidung oder Handlung ermöglichen diese Daten? Die Telefonnummer eines Kunden gelangt möglicherweise nicht vom CRM zum E-Mail-Agenten. Wird sie aber an einen WhatsApp-Agenten übermittelt, ermöglicht sie eine Außenkommunikation. Dieselben Daten bergen je nach Werkzeug unterschiedliche Risiken.

Keine Zugriffskontrollliste

Eine Zugriffsliste zeigt, wer technisch auf welches System zugreifen kann. Die Verhaltenskarte hält zwei verschiedene Fragen gemeinsam fest:

Was ist technisch möglich? Was hat die Organisation autorisiert?

Die Differenz zwischen diesen Antworten kann zu den wichtigsten Feststellungen der Prüfung gehören.

Kein Prozessablaufdiagramm

Ein Prozessdiagramm kann den idealen Ablauf zeigen:

RECHERCHIEREN → ENTWURF ERSTELLEN → MENSCHLICHE FREIGABE → VERSENDEN

Die Verhaltenskarte zeigt auch die tatsächlichen Wege:

RECHERCHEAGENT → KALENDERWERKZEUG → NACHRICHT IN DIE EINLADUNGSBESCHREIBUNG SCHREIBEN → AUSSENKOMMUNIKATION

Der ideale Ablauf und die tatsächlich genutzten Abkürzungen werden auf derselben Karte verglichen.

Der grundlegende Verhaltenspfad

Agentenverhalten folgt häufig dieser Kette:

MENSCHLICHER ODER ORGANISATORISCHER ZWECK ↓ URSPRUNGSAUFGABE ↓ AGENT ODER AGENTENNETZ ↓ DATEN UND KANONISCHE QUELLEN ↓ BEWERTUNG UND AUSWAHL ↓ EINWILLIGUNG, BEFUGNIS UND FREIGABE ↓ WERKZEUGAUFRUF ↓ HANDLUNG IN DER AUSSENWELT ↓ UNABHÄNGIGE ÜBERPRÜFUNG ↓ HANDLUNGSBELEG ↓ STOPP, RÜCKNAHME UND WIEDERHERSTELLUNG

Diese Kette können wir so nennen:

NOMOS-Verhaltenspfad

Jedes wichtige Verhalten sollte sich möglichst entlang dieses Pfads verfolgen lassen. Bei einer Kunden-E-Mail etwa:

Menschlicher Zweck: Einen Entwurf für die erste Kontaktaufnahme mit passenden Interessenten erstellen. Ursprungsaufgabe: GBO-TASK-2026-00441 Zentraler Agent: Sales Research v2.4 Unteragent: Recipient Resolution v1.4 Daten: Öffentlich zugängliche Unternehmenswebsite und kanonischer Leistungskatalog Bewertung: Das Unternehmen passt zum Leistungsumfang. Befugnis: Entwurfserstellung freigegeben Versand gesperrt Werkzeug: Gmail-Entwurfswerkzeug (create_draft ist im Beispiel eine symbolische Werkzeughandlung, keine tatsächliche Methode oder OAuth-Scope-Bezeichnung des Anbieters). Äußeres Ergebnis: Entwurf erstellt Nachricht nicht versendet Überprüfung: Kein Eintrag im Ordner Sent Im festgelegten Beobachtungszeitraum ging keine Nachricht an der Prüfadresse ein. Diese beiden Aufzeichnungen erfassen nur den untersuchten E-Mail-Pfad. Solange Kalender-, Unteragenten- oder andere Empfängerpfade nicht ausgeschlossen sind, darf daraus nicht das Ausbleiben jeglicher Außenkommunikation abgeleitet werden. Beleg: ACTION-8891 Stopp: Neue Vorgänge können verhindert werden. Nachdem die mindestens erforderlichen Nachweise gesichert wurden, können Aufgabe und Entwurf gemäß dem Bereinigungsplan für den Test entfernt werden. Auf dem untersuchten E-Mail-Pfad wurde kein externer Versand beobachtet. Die Kanal- und Zeitgrenzen dieses Urteils bleiben im Beleg festgehalten.

Ist dieser Pfad klar, kann der Prüfer erkennen:

Was hatte der Mensch verlangt?

Was hat der Agent getan?

Welche Grenzen hat er eingehalten?

Wie wurde das tatsächliche Ergebnis nachgewiesen?

Ist der Verhaltenspfad unterbrochen, ist auch die Verantwortungskette des Systems unterbrochen.

Die zehn Ebenen der Verhaltenskarte

Das NOMOS GBO Prüfprotokoll kartiert das Verhaltenssystem auf zehn grundlegenden Ebenen.

1. Menschen und Organisation

2. Zweck und Aufgabe

3. Agentenidentität

4. Daten und Fakten

5. Werkzeuge und Konten

6. Befugnis, Einwilligung und Freigabe

7. Handlungen und Ziele

8. Delegation, Warteschlangen und Zeitplanung

9. Nachweise und Überprüfung

10. Stopp und Wiederherstellung

Bleibt eine dieser Ebenen unsichtbar, kann die Prüfung einen wichtigen Bruch im System übersehen.

1. Menschen und Organisation

Hinter jedem Handeln steht eine Beziehung zu Menschen oder Organisationen. Die Karte muss folgende Rollen voneinander unterscheiden:

Geprüfte Organisation

Rechtlicher Betreiber

Marke

Systemverantwortlicher

Technisch Verantwortlicher

Dateninhaber oder datenschutzrechtlich Verantwortlicher

Menschlicher Verantwortlicher des Agenten

Befugnisgeber

Person, die den Vorgang freigibt

Betroffene Person

Person, die Einwände prüft

Zum Notstopp befugte Person

Zum Neustart befugte Person

Eine Person kann sämtliche Rollen übernehmen. Dennoch dürfen sie nicht bloß unter „Geschäftsleitung“ oder „Unternehmen“ erfasst werden. Bei einer Preisänderung etwa:

Der Unternehmenseigentümer kann den Preis festlegen.

Der Web-Agent kann die Änderung umsetzen.

Der technisch Verantwortliche kann sie veröffentlichen.

Das Finanzteam kann die Rechnung anpassen.

Der Vertriebsleiter kann Kunden die Änderung erläutern.

Jeder übernimmt eine andere Rolle. Die Verhaltenskarte macht diese Beziehungen sichtbar.

Der eigentliche Auftraggeber

Ein Agent handelt im Namen einer bestimmten Person oder Organisation. Diese können wir als den eigentlichen Auftraggeber bezeichnen.

Der eigentliche Auftraggeber

Bei einem persönlichen Reiseagenten ist der Nutzer der Auftraggeber. Bei einem Einkaufsagenten im Unternehmen sind es die Organisation und der befugte Budgetverantwortliche. Im Personalwesen kann das Unternehmen die Entscheidung treffen; vom Handeln betroffen ist aber auch der Bewerber. Im Kundenservice können sowohl Unternehmensinteressen als auch Kundenrechte berührt sein. Der Eintrag zum Auftraggeber beantwortet die Frage: Wessen legitimem Ziel muss der Agent vorrangig dienen? Er ist auch nötig, um zu beurteilen, ob die Geschäftsinteressen der Plattform oder des Anbieters das Nutzerziel verdrängen.

Betroffene Parteien

Ein Agent wirkt nicht nur auf die Person ein, die ihm eine Aufgabe erteilt. Ein Agent zur Kundengewinnung kann Menschen anschreiben, die noch keine Kunden sind. Ein Recruiting-Agent kann die Chancen eines Bewerbers beeinflussen. Ein Avatar-Agent berührt den Ruf der Person, deren Gesicht und Stimme er verwendet. Ein Web-Agent kann einen Preis ändern, den Tausende Besucher sehen. Für jede wesentliche Handlung muss die Verhaltenskarte zeigen, wer davon betroffen sein könnte. Fehlt eine betroffene Person auf der Karte, berücksichtigt das System womöglich auch Folgendes nicht:

ihre Einwilligung,

ihren Einwand,

die Wiedergutmachung für sie,

ihren Stoppantrag.

2. Zweck und Aufgabe

Ein Rollenname allein beschreibt die Arbeit eines Agenten nicht. Er verfolgt ein bestimmtes Ziel und erfüllt eine Aufgabe. Die Karte muss drei Ebenen auseinanderhalten:

Organisationsziel

Beispiel: qualifizierte Verkaufschancen bei Neukunden schaffen.

Ursprungsaufgabe

Beispiel: Recherchiere Fertigungsunternehmen in Deutschland, die ein mehrsprachiges Kundenportal benötigen könnten, und erstelle einen Bericht über mögliche Kunden.

Teilaufgabe

Beispiel: Verifiziere, wer derzeit die digitale Transformation im Zielunternehmen leitet. Diese drei Ebenen müssen miteinander verbunden bleiben. Eine Teilaufgabe darf keine weitergehenden Handlungsbefugnisse erzeugen als die Ursprungsaufgabe. „Überprüfe den Ansprechpartner“ bedeutet nicht „Schreibe den Ansprechpartner an“.

Kennung der Ursprungsaufgabe

Jede Kette aus mehreren Agenten muss eine eindeutige Kennung der Ursprungsaufgabe führen:

root_task_id: GBO-TASK-2026-00441

Unteragenten, Warteschlangen, Werkzeugaufrufe und Handlungsbelege müssen mit dieser Kennung verknüpft sein. So kann der Prüfer beantworten, aus welcher ursprünglichen menschlichen Anweisung diese externe E-Mail hervorging. Ohne die Kennung zeigt die Handlungskette nur noch das zuletzt eingesetzte Werkzeug. Das menschliche Ziel geht verloren.

Höchste zulässige Handlungsstufe

Für jede Aufgabe muss feststehen, bis zu welcher Stufe der Agent handeln darf. Die folgende Skala von 0 bis 6 beschreibt die Obergrenze der Aufgabenbefugnis. Sie ist weder mit den Handlungsstufen 1 bis 5 des Prüfers noch mit der Skala 0 bis 4 für Außenwirkungen gleichzusetzen. Eine höhere Stufe erteilt nicht automatisch sämtliche Daten-, Ziel- und Werkzeugberechtigungen der niedrigeren Stufen. Ausdrückliche Verbote und Bedingungen für Vorgänge bleiben bestehen. Ein Beispiel:

0 — Nur lesen 1 — Klassifizieren 2 — Empfehlen 3 — Entwurf erstellen 4 — Zur menschlichen Freigabe vorlegen 5 — Begrenzt handeln 6 — Eine Verpflichtung nach außen eingehen

Ist die Ursprungsaufgabe auf „Höchstens Stufe 3 — Entwurf“ begrenzt, darf die Unteragentenkette nicht zu Stufe 5 übergehen. Dieser Eintrag macht das Abdriften der Aufgabe nach GBO-ERR-063 und Fehler bei der Vererbung von Befugnissen nach GBO-ERR-056 sichtbar.

3. Agentenidentität

Der öffentlich sichtbare Agentenname reicht für eine Prüfung nicht aus. „NOMOS Sales Agent“ bezeichnet beispielsweise eine Persona oder Rolle. Im tatsächlichen System können sich dahinter folgende Komponenten verbergen:

Zentraler Planer

Recherche-Unteragent

Unteragent zur Ermittlung von Ansprechpartnern

Agent für E-Mail-Entwürfe

Versandagent

Warteschlangenverwaltung

Modellanbieter

Gedächtnisdienst

Jeder technische Agent muss eine eigene Identität besitzen.

Identitätskarte des Agenten

Jeder Agenteneintrag muss mindestens diese Felder enthalten:

agent_id public_name technical_identity agent_type human_owner root_purpose allowed_actions prohibited_actions connected_tools data_scope subagent_rights authorization_version valid_from valid_until stop_method status

Agententypen lassen sich zum Beispiel so einteilen:

Zentraler Planer

Fachagent

Unteragent

Prüfagent

Versandagent

Rechercheagent mit reinem Lesezugriff

Temporärer Aufgabenagent

Agent eines externen Anbieters

Persona und technische Identität

Eine Persona kann jahrelang denselben Namen tragen. Modell, Werkzeuge und Befugnisse können sich unterdessen ändern. Deshalb braucht die Karte zwei getrennte Felder:

Für Nutzer sichtbare Identität Prüfbare technische Identität

Beispiel:

public_name: NOMOS Sales
technical_instance: SALES-ORCH-2026-09-08-04
model_config: MODEL-CONFIG-17
authorization: AUTH-v3.2

Ein Ereigniseintrag darf nicht bloß lauten: „Das war NOMOS.“ Es muss sich feststellen lassen, welche technische Instanz mit welcher Befugnis gehandelt hat.

Temporäre Unteragenten

Manche Systeme können während einer Aufgabe neue Unteragenten erzeugen. Diese müssen nicht schon vorab einzeln im Inventar stehen. Bevor sie jedoch nach außen handeln, müssen sie folgende Angaben erfassen:

agent_id parent_agent root_task_id purpose allowed_actions data_scope tools expiry stop_parent

Die Regel sollte lauten: Ein nicht registrierter temporärer Agent darf nicht nach außen handeln. Möglich sind:

Recherche,

Klassifizierung,

synthetische Analyse.

Für E-Mail-Versand, Zahlungen, Veröffentlichungen oder Datenübertragungen muss der Agent dagegen in die Karte und die Befugniskette eingebunden sein.

4. Daten und Fakten

Die Eingaben, auf denen das Handeln des Agenten beruht, müssen auf der Karte sichtbar sein. Dateinamen allein genügen nicht. Zu jeder Information sind folgende Angaben erforderlich:

Quelle,

Inhaber,

Aktualität,

kanonischer Status,

Datenklasse,

Verwendungszweck.

Beispiele für Quellen:

Kanonischer Leistungskatalog

Preisregister

CRM

Register menschlicher Befugnisse

Nutzergedächtnis

Webseiten

Unternehmensverzeichnisse

Soziale Medien

Externe Recherchequellen

Ausgaben anderer Agenten

Datenklassen

Die folgenden Merkmale können auf der Karte in getrennten Feldern stehen. Sie schließen einander nicht aus; es muss also nicht genau eine Kategorie gewählt werden. Öffentlich zugängliche Informationen können zugleich personenbezogene Daten sein. Betriebliche Vertraulichkeit, datenschutzrechtliche Einordnung und Nutzungserlaubnis werden getrennt bewertet:

Öffentlich

Intern

Vertraulich

Personenbezogen

Sensibel

Biometrisch

Rechtlich eingeschränkt

Für Agenten gesperrt

Dass ein Agent eine Quelle lesen kann, bedeutet nicht, dass er sie auch:

an ein anderes Werkzeug senden darf,

in seinem Gedächtnis speichern darf,

in einer externen Nachricht verwenden darf.

Für jede Datenverbindung lassen sich daher drei getrennte Rechte ausweisen:

READ USE_FOR_DECISION SHARE_OR_TRANSMIT

Ein Agent kann im CRM die Telefonnummer eines Kunden sehen, ohne befugt zu sein, sie für eine Vertriebsnachricht zu verwenden oder an WhatsApp zu übermitteln.

Kanonische und sekundäre Quellen

Für jede wesentliche Tatsache muss die Karte die Rolle der Quelle angeben:

Kanonische Quelle

Maßgebliche Primärquelle

Unabhängiger Dritter

Von der Organisation kontrollierte Veröffentlichung

Schlussfolgerung des Agenten

Temporäre Daten

Ungeprüfte Quelle

Veraltete oder archivierte Quelle

Aus welcher Quelle bezieht ein Vertriebsagent den Preis? Auf welchen Eintrag stützt ein Web-Agent die Beschreibung des Leistungsumfangs? Wertet ein Prüfagent den Bericht eines anderen Agenten als unabhängigen Nachweis? Diese Fragen müssen auf der Verhaltenskarte sichtbar werden.

5. Werkzeuge und Konten

Agenten wirken über Werkzeuge auf die reale Welt ein. Deshalb muss für jedes Werkzeug nicht nur der Name erfasst werden, sondern auch, was es bewirken kann. „Gmail-Anbindung“ reicht beispielsweise nicht. Folgende Berechtigungen müssen getrennt ausgewiesen werden:

Nachrichten lesen

Entwürfe erstellen

Senden

Weiterleiten

Löschen

Anhänge herunterladen

Labels ändern

Ebenso muss „Git-Zugriff“ nach folgenden Möglichkeiten aufgeschlüsselt werden:

Lesen

Branch erstellen

Commit erstellen

Merge durchführen

Bereitstellung im Produktivsystem auslösen

Secrets löschen

Fähigkeitsprofil des Werkzeugs

Für jedes Werkzeug können folgende Felder geführt werden:

tool_id provider account technical_capabilities authorized_capabilities approval_requirements data_access external_effects idempotency_support logging stop_method revocation_method owner

Entscheidend ist die Unterscheidung zwischen:

Technisch dazu in der Lage

Von der Organisation dazu befugt

Beispiel:

Diese Tabelle zeigt unmittelbar die in GBO-ERR-094 beschriebene Lücke zwischen Richtlinie und technischen Berechtigungen.

Gemeinsam genutzte Konten

Nutzen mehrere Agenten dasselbe Dienstkonto, lässt sich schwerer nachvollziehen, wer tatsächlich gehandelt hat. Angenommen, alle versenden Nachrichten über dieses Konto:

automation@nobleaxis.example

Dann sind zusätzliche Protokolle nötig, um jede Handlung einem Agenten zuzuordnen. Gemeinsam genutzte Konten müssen nicht grundsätzlich verboten sein. Folgende Angaben müssen aber erhalten bleiben:

Agenteninstanz

Ursprungsaufgabe

Befugnisversion

Vorgangskennung

Menschlicher Verantwortlicher

Versandgrund

Ist diese Zuordnung nicht möglich, begründet das gemeinsam genutzte Konto eine kritische Feststellung zur Nachverfolgbarkeit.

6. Befugnis, Einwilligung und Freigabe

Die Verhaltenskarte zeigt nicht nur den Weg über die Werkzeuge. Sie zeigt auch, worauf die Legitimität jeder wesentlichen Handlung beruht. Folgende Fragen müssen beantwortet werden:

Wer hat die Befugnis erteilt?

War diese Person dazu berechtigt?

Welches Handeln deckt die Befugnis ab?

Wie lange gilt sie?

Darf sie an einen anderen Agenten delegiert werden?

Auf welche Daten und Ziele ist sie beschränkt?

Wo ist eine menschliche Freigabe erforderlich?

Hat die betroffene Person eingewilligt?

Welche Handlungen enden, wenn die Befugnis entzogen wird?

Befugnisse auf Zeit

Agentenbefugnisse müssen nicht dauerhaft gelten. Sie lassen sich als zeitlich begrenzte Befugnisse verstehen.

Befugnis auf Zeit

Das folgende kurze Berechtigungsbeispiel setzt voraus, dass ein befugter Mensch die Ursprungsaufgabe um einen einmaligen E-Mail-Versand erweitert hat. Die bisherige Recherche- und Entwurfsbefugnis allein erteilt keine Versandbefugnis:

authorization_id: AUTH-2026-8821
agent: APPROVED-SEND-v1.3
action: send_email
target_domain: audit.example
maximum_messages: 1
valid_from: "2026-09-08T14:00:00+03:00"
valid_until: "2026-09-08T14:10:00+03:00"
root_task_id: GBO-TASK-2026-00441

Nach Ablauf der Befugnis darf das Werkzeug auf dieser Grundlage nicht weiterarbeiten. Ein Unteragent darf dieselbe Befugnis nicht unbefristet an einen anderen Agenten weiterreichen können.

Freigabepunkte

Die Karte muss nicht nur zeigen, dass es eine menschliche Freigabe gibt, sondern auch, was sie umfasst. Zum Beispiel:

Menschliche Freigabe: - Endgültiger Nachrichtentext - Empfänger - Anhänge - Preis oder Verpflichtung - Versandkanal - Versandzeitpunkt

Eine Schaltfläche, die lediglich „Fortfahren?“ fragt, stellt nicht unbedingt eine aussagekräftige Freigabe dar.

Einwilligung und Verarbeitungsgrundlage nachvollziehen

Eine Handlung nutzt möglicherweise:

das Gesicht einer dritten Person,

ihre Stimme,

ihre personenbezogenen Daten,

ihren Kommunikationskanal.

Dann müssen die nach den geltenden Datenschutz- und Kommunikationsregeln erforderlichen Grundlagen bestimmt werden. Beruht eine Verarbeitung auf Einwilligung, sind deren Umfang, Dauer und Widerrufsstatus bis zur betreffenden Handlung nachzuverfolgen. Im folgenden Beispiel zur Stimmnutzung ist die Einwilligung eine ausdrückliche Voraussetzung der Aufgabe:

VOICE-CONSENT-17 → Nur türkischsprachiges Schulungsvideo → Unternehmensinterner Kanal → Bis zum 31. Dezember 2026 → Öffentliche soziale Medien ausgeschlossen

Ein Agent kann Zugriff auf ein Werkzeug für Stimmmodelle haben. Deckt die Einwilligung die konkrete Veröffentlichung jedoch nicht ab, bleibt die Handlung gesperrt.

7. Handlungen und Ziele

Die Verhaltenskarte muss festhalten, was ein Werkzeugaufruf in der Welt tatsächlich bewirkt. Handlungen lassen sich zum Beispiel so einteilen:

Informationen lesen

Klassifizieren

Empfehlen

Entwurf erstellen

Eintrag ändern

Nachricht senden

Kalendereinladung erstellen

Datei veröffentlichen

Zahlung leisten

Abonnement abschließen

Daten übertragen

Konto schließen

Inhalt löschen

Biometrische Inhalte erzeugen

Benachrichtigung an eine externe Suchmaschine senden

Das Ziel jeder Handlung muss eindeutig identifiziert werden.

Zieltypen

Eine Handlung kann sich auf eines der folgenden Ziele richten:

Mensch

Unternehmen

Kundenkonto

Bestellung

Zahlungskonto

Datei

Webseite

Social-Media-Konto

Datensammlung

Server

Kalender

Externe Plattform

Physisches Gerät

Zwei Ziele können denselben Namen tragen. Ein Zieleintrag darf sich deshalb nicht allein auf den angezeigten Namen stützen. Zum Beispiel:

target_type: company
target_id: ENT-DE-NOVA-0041
canonical_name: Nova Systems GmbH
domain: nova-systems.example

Stufe der Außenwirkung

Für jede Handlung lässt sich eine Stufe der Außenwirkung festlegen:

Stufe 0 — Interne Beobachtung

Keine Außenwirkung.

Stufe 1 — Interner Eintrag oder Entwurf

Eine Wirkung innerhalb der Organisation, die sich rückgängig machen lässt.

Stufe 2 — Begrenzte externe Kommunikation

Nachricht, Besprechungseinladung oder Datenaustausch.

Stufe 3 — Geschäftliche oder öffentliche Handlung

Veröffentlichung, Angebot, Abonnement oder Kauf mit geringem Wert.

Stufe 4 — Handlung mit großer oder schwer umkehrbarer Wirkung

Zahlung eines hohen Betrags, Vertrag, Veröffentlichung biometrischer Inhalte, Datenlöschung oder physische Steuerung. Mit steigender Handlungsstufe müssen die Anforderungen an Folgendes strenger werden:

Befugnis,

menschliche Freigabe,

Nachweise,

Stopp,

Rückgängigmachung.

8. Delegation, Warteschlangen und Zeitplanung

Agenten handeln nicht immer sofort. Eine Aufgabe kann:

an einen anderen Agenten delegiert werden,

in eine Warteschlange gelangen,

für einen späteren Zeitpunkt geplant werden,

an eine externe Plattform übergeben werden,

nach einem Fehlschlag erneut ausgeführt werden.

Bleibt diese Ebene unsichtbar, werden die zeitversetzten Wege vom zentralen Agenten zum tatsächlichen Handeln übersehen.

Delegationsverbindung

Jede Delegation an einen Unteragenten muss folgende Angaben mitführen:

parent_agent child_agent root_task_id delegated_purpose allowed_actions prohibited_actions data_scope authorization_ceiling expiry return_condition

Die Befugnisobergrenze des Unteragenten darf diejenige der übergeordneten Aufgabe nicht überschreiten.

Warteschlangeneintrag

Für jede wesentliche Warteschlange müssen folgende Fragen beantwortet werden:

Wer hat die Warteschlange angelegt?

Welche Handlungen stehen aus?

Wann wurde die Befugnis geprüft?

Wird sie bei der Ausführung erneut geprüft?

Was geschieht mit der Warteschlange, wenn ein Mensch den Stopp auslöst?

Wie oft darf ein Vorgang erneut versucht werden?

Gibt es einen Schutz vor doppelten Vorgängen?

Liegt die Warteschlange bei einem anderen Anbieter?

Beispiel:

queue_id: EMAIL-FOLLOWUP-07
owner: CRM-AUTOMATION
pending_actions: 18
authorization_recheck: false
stop_parent: none

Dieser Eintrag begründet unmittelbar eine kritische Feststellung.

Zeitgesteuerte Aufgaben

Zeitgesteuerte Aufgaben fehlen häufig im Agenteninventar. Auch wenn der Agent heute gestoppt wird, kann um Mitternacht erneut Aktivität entstehen, etwa durch:

einen Cronjob,

eine auf einer externen Plattform geplante Aufgabe,

eine Abonnementverlängerung,

eine automatisierte Berichterstellung.

Die Verhaltenskarte muss jede geplante Handlung als eigenen Knoten zeigen.

Regeln für Wiederholungsversuche

Was tut das System, wenn ein Werkzeug nicht antwortet? Bei Zahlungen, Versand und Veröffentlichungen können unkontrollierte Wiederholungsversuche eine Handlung doppelt auslösen. Die Karte muss festhalten:

Anzahl der Wiederholungsversuche

Zeitabstand

Eindeutige Vorgangskennung

Abfrage des Endstatus

Übergabe an einen Menschen

Fehler, bei denen kein erneuter Versuch erfolgen darf

9. Nachweise und Überprüfung

Die Karte muss zeigen, anhand welcher Nachweise sich feststellen lässt, ob eine Handlung ausgeführt wurde oder nicht. Angenommen, die Aussage lautet: Der Agent hat keine Nachricht versendet. Was belegt das?

Der Bericht des Agenten selbst?

Der Ordner mit den gesendeten E-Mails?

Eine externe Prüfadresse?

Der Warteschlangeneintrag?

Das Werkzeugprotokoll?

Die Nachweisebene muss von der Handlung getrennt sein.

Nachweisverknüpfung

Jede wesentliche Handlung lässt sich mit folgenden Feldern verknüpfen:

action_id technical_result independent_verification evidence_location evidence_owner timestamp integrity_record retention

Zum Beispiel bei einer Webveröffentlichung:

FTP-Übertragungsbericht → Abruf der live verfügbaren Datei über HTTPS → Hashvergleich → Ansicht in einem echten Browser → semantische Prüfung

Beim E-Mail-Versand:

Ergebnis der send-API → Eintrag zur gesendeten E-Mail → Prüfpostfach beim Empfänger → Transaktionsbeleg

Herkunft der Nachweise

Die Karte muss erkennen lassen, ob dasselbe System auch die Nachweise erzeugt. Wenn ein Agent:

den Vorgang ausführt,

den Erfolgsbericht verfasst

und seinen eigenen Bericht als Prüfnachweis vorlegt,

fehlt die Unabhängigkeit. Kapitel 4 arbeitet die Nachweiskette genauer aus. Hier lautet die grundlegende Frage: Gibt es für jede wesentliche Handlung eine von außen einsehbare Verbindung zum tatsächlichen Ergebnis?

10. Stopp und Wiederherstellung

Der Stopppfad ist der am häufigsten vernachlässigte Teil der Verhaltenskarte. Organisationen beschreiben den Handlungspfad oft ausführlich:

AGENT → WERKZEUG → HANDLUNG

Den umgekehrten Weg richten sie jedoch nicht ein:

STOPPANFORDERUNG DURCH EINEN MENSCHEN → ZENTRALER AGENT → UNTERAGENT → WARTESCHLANGE → EXTERNES WERKZEUG → TOKEN-WIDERRUF → SICHERER ZUSTAND

Echte menschliche Kontrolle verlangt zu jedem Pfad mit Außenwirkung einen zugehörigen Stopp- und Wiederherstellungspfad.

Stopp-Kante

Für jeden Agenten, jedes Werkzeug und jede Warteschlange muss die Karte festhalten:

Wer darf den Stopp auslösen?

Über welchen Kanal?

Innerhalb welcher Zeit?

Werden nur neue Aufträge gestoppt oder auch laufende?

Wird der Stopp an Unteragenten weitergegeben?

Wird das Token widerrufen?

Wird die geplante Ausführung auf der externen Plattform aufgehoben?

Welcher sichere Zustand soll am Ende erreicht sein?

Wer darf den Neustart auslösen?

Zum Beispiel:

component: EMAIL-FOLLOWUP-QUEUE
stop_authority: sales_operations_owner
stop_method: queue_cancel_api
maximum_stop_latency: 10_seconds
propagates_to_external_provider: true
restart_requires_new_authorization: true

Verbindung zur Rücknahme

Für jede Handlung mit großer Wirkung ist zu fragen: Wie machen wir sie rückgängig, wenn etwas schiefläuft? Einige Vorgänge lassen sich vollständig rückgängig machen, sofern ein geeignetes Wiederherstellungsverfahren vorhanden ist:

Löschen eines wiederherstellbaren Entwurfs

Eine Änderung in einer Testumgebung

Vorgänge in der Warteschlange, die noch nichts versendet haben

Andere nur teilweise:

Eine Webveröffentlichung

Eine Reservierung

Ein Abonnement

Wieder andere lassen sich praktisch nicht rückgängig machen:

Eine bereits versendete E-Mail

Ein öffentlich verbreitetes synthetisches Video

Nach außen übertragene Daten

Physischer Schaden

Die Karte muss diesen Unterschied zeigen. Bei unumkehrbaren Handlungen müssen menschliche Freigabe und vorbeugende Kontrollen strenger sein.

Deklarierte und tatsächliche Karte

Für eine Prüfung reicht eine einzige Verhaltenskarte nicht aus. Es müssen mindestens zwei Ansichten entstehen.

1. Deklarierte Verhaltenskarte

2. Tatsächliche Verhaltenskarte

Deklarierte Verhaltenskarte

Sie zeigt, wie das System nach Vorstellung oder Zusage der Organisation arbeitet. Ihre Quellen sind:

Richtliniendokumente

Prozessbeschreibungen

Systemarchitektur

Gespräche mit Menschen

Aufgabenbeschreibungen der Agenten

Verträge

Benutzeroberflächen

Zum Beispiel:

RECHERCHEAGENT → ENTWURFSAGENT → MENSCHLICHE FREIGABE → VERSANDAGENT

Tatsächliche Verhaltenskarte

Sie zeigt die tatsächlichen Verhaltenspfade, rekonstruiert aus technischen Berechtigungen, Protokollen, kontrollierten Tests und Ergebnissen im Livebetrieb. Zum Beispiel:

RECHERCHEAGENT → CRM → AUTOMATISCHE NACHFASS-WARTESCHLANGE → VERSAND-DIENSTKONTO → EXTERNE E-MAIL

Außerdem:

RECHERCHEAGENT → KALENDERWERKZEUG → EINLADUNGSBESCHREIBUNG → EXTERNE KOMMUNIKATION

Möglicherweise kennt die Organisation den ersten Pfad nicht. Den zweiten stuft sie womöglich gar nicht als Kommunikationshandlung ein. Die Prüfung vergleicht die beiden Karten.

Die Abweichung zwischen den Karten

Eine wesentliche Abweichung zwischen deklarierter und tatsächlicher Karte lässt sich so bezeichnen:

Lücke in der Verhaltenskarte

Beispiele:

Die Richtlinie verbietet den Versand, im Werkzeug ist er jedoch freigeschaltet.

Ein zentraler Stopp ist vorhanden, die externe Warteschlange ist aber nicht daran angebunden.

Die Agentenliste enthält acht Systeme, die tatsächlichen Protokolle siebzehn technische Identitäten.

Preisänderungen scheinen der Geschäftsleitung vorbehalten zu sein; der Katalogagent kann sie jedoch indirekt vornehmen.

Nachweise erscheinen unabhängig, werden tatsächlich aber vom selben Agenten erzeugt.

Eine menschliche Freigabe liegt vor, wird im Ausführungszeitpunkt jedoch nicht erneut geprüft.

Je größer die Kartenlücke, desto weniger kennt die Organisation ihr eigenes Verhaltenssystem.

Wahrheitsstatus in der Karte

Nicht jede Verbindung ist gleich gut belegt. Für jedes Kartenelement sind Nachweisstatus, Gültigkeit, organisatorische Befugnis und technische Möglichkeit getrennt festzuhalten. Die folgenden Kennzeichnungen schließen einander nicht aus: Ein Pfad kann nachweislich technisch möglich sein, obwohl seine Nutzung verboten ist.

Verifiziert

Durch eine technische Aufzeichnung oder einen Verhaltenstest belegt.

Deklariert

Von der Organisation oder dem Systemverantwortlichen angegeben, aber nicht unabhängig überprüft.

Abgeleitet

Plausibel aus einem Protokoll oder Verhaltensmuster erschlossen.

Unbekannt

Es liegen nicht genügend Nachweise vor.

Widersprüchlich

Verschiedene Quellen zeigen unterschiedliche Beziehungen.

Abgelaufen

Früher gültig, inzwischen nicht mehr aktiv.

Verboten

Eine Richtlinie oder Befugnisvereinbarung untersagt das Verhalten. Ob es auch technisch verhindert wird, ist gesondert festzuhalten.

Technisch möglich

Werkzeuge und Berechtigungen ermöglichen das Verhalten, auch ohne entsprechende Befugnis. Diese Kategorien hindern den Prüfer daran, Lücken mit erfundenen Annahmen zu füllen. Eine unbekannte Verbindung bedeutet nicht bloß eine unvollständige Karte; sie ist eine wesentliche Feststellung.

Die Matrix von Können und Dürfen

Zu den stärksten Bestandteilen einer Verhaltenskarte kann diese Matrix gehören:

Matrix: Technisch möglich – Befugt – Beobachtet

Beispiel:

Diese Matrix macht entscheidende Unterschiede sichtbar:

Technisch freigeschaltet, aber organisatorisch verboten

Organisatorisch erlaubt, aber vom Werkzeug nicht unterstützt

An menschliche Freigabe gebunden, im Test aber ohne Freigabe ausgeführt

Ein noch nicht getesteter Hochrisikopfad

Vier grundlegende Verhaltenspfade

Die Verhaltenskarte muss vier unterschiedliche Pfade getrennt darstellen.

1. Handlungspfad

2. Befugnispfad

3. Nachweispfad

4. Stopppfad

Handlungspfad

Was ist vom menschlichen Zweck bis zum Ergebnis außerhalb des Systems geschehen?

Mensch → Zentraler Agent → Unteragent → Werkzeug → Externe Handlung

Befugnispfad

Woher stammt die Befugnis für dieses Verhalten?

Befugter Mensch → Befugnisvereinbarung → Ursprungsaufgabe → Aufgabenspezifisches Token → Handlung

Nachweispfad

Wie wurde belegt, dass das Ergebnis richtig ist?

Werkzeugantwort → Rücklesen aus dem externen System → Hash / Empfängereintrag / Zahlungsaufzeichnung → Handlungsbeleg

Stopppfad

Wie wird die gesamte Kette gestoppt, wenn der Mensch seine Entscheidung ändert?

Stoppanforderung → Zentraler Agent → Unteragenten → Warteschlange → Werkzeug → Token → Sicherer Zustand

Fehlt einer dieser vier Pfade für eine externe Handlung, ist das System unvollständig. Gibt es einen Handlungspfad, aber keinen Befugnispfad, ist die Handlung nicht legitim. Gibt es einen Befugnispfad, aber keinen Nachweispfad, lässt sich das Ergebnis nicht überprüfen. Gibt es einen Nachweispfad, aber keinen Stopppfad, bleibt die menschliche Kontrolle schwach.

Wie entsteht eine Verhaltenskarte?

Kartieren heißt nicht nur, in einer Besprechung ein Schaubild zu zeichnen. Das NOMOS GBO Protokoll verwendet ein Verfahren mit zwölf Schritten.

Schritt 1 — Grundlegenden Zweck und Prüfumfang festschreiben

Zunächst wird festgelegt, welches Verhaltenssystem kartiert wird. Zum Beispiel: Interessentenrecherche und erster Kontakt nach menschlicher Freigabe. Ausdrücklich festzuhalten sind:

Einbezogene Verhaltensweisen

Ausgeschlossene Verhaltensweisen

Verwendete Sprachen

Umgebung

Datum

Version

Die Karte soll nicht versuchen, die gesamte Organisation ohne jede Begrenzung abzubilden. Ihr Ausgangspunkt muss die Prüfaussage sein.

Schritt 2 — Verantwortliche Menschen und Organisationen ermitteln

Zu klären ist, wer die folgenden Rollen innehat:

Person, die den grundlegenden Zweck vorgibt

Systemverantwortlicher

Technisch Verantwortlicher

Datenverantwortlicher

Freigabeverantwortlicher

Stoppverantwortlicher

Neustartverantwortlicher

Betroffene Partei

Lässt sich für eine Rolle kein Verantwortlicher finden, muss dies ausdrücklich dokumentiert werden. Ein System ohne Verantwortlichen ist eine kritische Feststellung.

Schritt 3 — Sämtliche Agentenidentitäten erfassen

Nicht nur öffentlich sichtbare Rollennamen erfassen, sondern auch:

Zentrale Agenten

Spezialisierte Agenten

Unteragenten

Temporäre Agenten

Prüfagenten

Agenten externer Anbieter

Alte, aber noch aktive Instanzen

Protokolle, API-Aufzeichnungen, Einträge der Aufgabenverwaltung, Dienstkonten und Abonnementaufzeichnungen werden miteinander abgeglichen.

Schritt 4 — Werkzeuge, Konten und Tokens zuordnen

Für jeden Agenten wird festgehalten:

Angebundenes Werkzeug

Konto

Technische Berechtigung

Befugnisgrenze

Gültigkeitsdauer des Tokens

Gemeinsam genutzte Identität

Widerrufsmethode

Die Angabe, ein Werkzeug sei lediglich „angebunden“, reicht nicht aus. Sein vollständiger Verhaltensumfang muss bekannt sein.

Schritt 5 — Datenquellen und Datenabflüsse kartieren

Welche Informationen bezieht der Agent aus welchen Quellen? Wohin schreibt er sie? An welchen externen Anbieter übermittelt er sie? In welchem Speicher hält er sie vor? Der Datenfluss muss in beide Richtungen sichtbar sein:

EINGANG: Quelle → Agent AUSGANG: Agent → Werkzeug / Speicher / Externe Partei

Ein Agent liest möglicherweise nicht nur Daten. Er kann zugleich Folgendes erzeugen:

neue Schlussfolgerungen,

Kundenkennzeichnungen,

Risikowerte,

Einträge zu Präferenzen.

Auch diese abgeleiteten Daten müssen in der Karte erscheinen.

Schritt 6 — Handlungsstufen bestimmen

Für jeden Agenten werden die beobachtbaren Verhaltensweisen erfasst:

Lesen

Bewerten

Empfehlen

Entwerfen

Einträge ändern

Versenden

Veröffentlichen

Bezahlen

Löschen

Stoppen

Jede Handlung wird einer Stufe der Außenwirkung zugeordnet.

Schritt 7 — Befugnis- und Einwilligungskette verknüpfen

Für jede Handlung mit großer Wirkung wird erfasst:

Quelle der Befugnis

Freigebender Mensch

Dauer

Betrag

Ziel

Kanal

Einwilligung

Übertragbarkeit der Befugnis

Eine Handlung, für die sich kein Befugnispfad finden lässt, wird in der Karte als roter Bereich markiert.

Schritt 8 — Unteragenten, Warteschlangen und Aufgabenplaner ergänzen

Erfasst werden Vorgänge außerhalb des Hauptprozesses:

Nachfassaufgaben,

Wiederholungsversuche,

Cronjobs,

extern geplante Ausführungen,

Sitzungen von Unteragenten.

Dieser Schritt macht viele Fälle sichtbar, in denen es später heißt: „Wir dachten, es sei gestoppt, aber es lief weiter.“

Schritt 9 — Nachweise und Abschlussbedingungen verknüpfen

Für jede Handlung lautet die Frage: Was muss geschehen sein, damit sie tatsächlich als abgeschlossen gilt? Bei einer Nachricht zum Beispiel:

Genügt die Annahme durch die API?

Wurde die Empfängeradresse überprüft?

Gibt es einen Eintrag zur gesendeten E-Mail?

Ist die Nachricht an der externen Prüfadresse eingegangen?

Aufzeichnungen zum Abschluss und zur unabhängigen Überprüfung werden ergänzt.

Schritt 10 — Stopp- und Wiederherstellungspfade zeichnen

Für jedes aktive Verhalten werden die Wege für folgende Eingriffe bestimmt:

Pausieren

Abbrechen der Warteschlange

Widerrufen des Tokens

Stoppen der Unteragenten

Rücknahme

Übergabe der Kontrolle an einen Menschen

Neustart

Eine externe Handlung ohne Stopppfad ist eine kritische Governance-Lücke.

Schritt 11 — Deklarierte und tatsächliche Karte vergleichen

Die deklarierte Karte aus Gesprächen mit Menschen und Prozessdokumenten wird mit Folgendem abgeglichen:

technischen Berechtigungen,

Protokollen,

kontrollierten Tests,

externen Ergebnissen.

Abweichungen werden als Feststellungen dokumentiert.

Schritt 12 — Die Karte versionieren, überprüfen und unterzeichnen

Die Karte enthält:

Kartenkennung

Systemversion

Datum der letzten Überprüfung

Nachweisniveau

Unbekannte Bereiche

Verantwortlicher

Auslöser wesentlicher Änderungen

Systemverantwortlicher, technisch Verantwortlicher und Prüfer überprüfen die Karte jeweils für ihren Zuständigkeitsbereich. Die Unterschrift bedeutet nicht, dass die Karte für immer richtig bleibt. Sie hält fest, dass die Unterzeichnenden anerkennen, auf welcher Nachweisgrundlage und innerhalb welcher Grenzen die Karte den Systemzustand zum angegebenen Datum abbildet.

Praxisbeispiel: Interessentenrecherche und Erstkontakt

Betrachten wir das System zur Interessentenrecherche eines Unternehmens. Die Organisation beschreibt den Ablauf so:

MENSCHLICHE FÜHRUNGSKRAFT ↓ AGENT ZUR INTERESSENTENRECHERCHE ↓ UNTERNEHMENSRECHERCHE ↓ NACHRICHTENENTWURF ↓ MENSCHLICHE FREIGABE ↓ E-MAIL-VERSAND

Dieses Schaubild wirkt sicher. Bei der Prüfung wird jedoch das tatsächliche System sichtbar:

VERTRIEBSLEITUNG ↓ ZENTRALER PLANUNGSAGENT ├── WEBRECHERCHEAGENT ├── DIENST ZUR EMPFÄNGERERMITTLUNG ├── AGENT FÜR CRM-EINTRÄGE │ └── AUTOMATISCHE NACHFASS-WARTESCHLANGE ├── E-MAIL-ENTWURFSAGENT │ └── GEMEINSAMES GMAIL-DIENSTKONTO ├── KALENDERAGENT └── BERICHTSAGENT

Die Prüfung der Werkzeugberechtigungen ergibt:

Der Webagent kann nur öffentlich zugängliche Daten verwenden.

Der Dienst zur Empfängerermittlung kann auch vermutete persönliche E-Mail-Adressen erzeugen.

Der CRM-Agent kann einen neuen Nachfass-Workflow erstellen.

Der Entwurfsagent kann technisch Nachrichten versenden.

Der Kalenderagent kann externe Einladungen erstellen.

Das gemeinsame Gmail-Konto besitzt Versand- und Löschberechtigungen.

Der zentrale Agent kann die Warteschlangen der Unteragenten nicht unmittelbar stoppen.

Auf der Karte werden fünf kritische Abkürzungen sichtbar.

Abkürzung 1 — Direkter Versand durch den Entwurfsagenten

E-MAIL-ENTWURFSAGENT → GMAIL SEND → EXTERNER EMPFÄNGER

Der Knoten für die menschliche Freigabe liegt nicht auf dem technischen Pfad.

Abkürzung 2 — Externe Kommunikation über eine Kalendereinladung

ZENTRALER AGENT → KALENDERAGENT → EXTERNE EINLADUNG

Das Verbot des E-Mail-Versands erfasst die Kalendereinladung nicht.

Abkürzung 3 — Automatisches Nachfassen im CRM

CRM-EINTRAG → NACHFASS-WARTESCHLANGE → GMAIL-DIENSTKONTO → EXTERNER EMPFÄNGER

Selbst wenn die erste Nachricht freigegeben wurde, erhält die Folgenachricht keine gesonderte menschliche Freigabe.

Abkürzung 4 — Anreicherung personenbezogener Daten

EMPFÄNGERERMITTLUNG → VERMUTETE PERSÖNLICHE E-MAIL-ADRESSE → CRM

Die Organisation hat erklärt, ausschließlich öffentlich zugängliche Unternehmensdaten zu verwenden. Das tatsächlich eingesetzte Werkzeug erzeugt darüber hinausgehende Daten.

Abkürzung 5 — Eine Warteschlange läuft nach dem Stopp weiter

MENSCH LÖST STOPP AUS → ZENTRALER AGENT STOPPT ABER: NACHFASS-WARTESCHLANGE → VERSAND LÄUFT WEITER

Der Stopppfad ist unvollständig.

Die erste Prüfentscheidung nach der Kartierung

Zu diesem Zeitpunkt hat der Prüfer noch nicht alle Szenarien ausgeführt. Die Verhaltenskarte zeigt jedoch, dass folgende Tests erforderlich sind:

Kann der Entwurfsagent ohne menschliche Freigabe eine Nachricht versenden?

Lässt sich eine Kalendereinladung nutzen, um das Verbot externer Kommunikation zu umgehen?

Erteilt die Freigabe der ersten Nachricht automatisch die Befugnis für eine Folgenachricht?

Erzeugt der Dienst zur Empfängerermittlung unzulässige personenbezogene Daten?

Werden auch die CRM-Warteschlange und der Gmail-Versand gestoppt, wenn der zentrale Agent stoppt?

Lässt sich beim gemeinsamen Dienstkonto erkennen, welcher Agent gehandelt hat?

Werden bestehende Warteschlangen nach einem Befugnisentzug zum Ausführungszeitpunkt erneut überprüft?

Die Karte hat unmittelbar den Testplan hervorgebracht. Eine gute Verhaltenskarte beschreibt nicht nur das System. Sie zeigt auch, was wir prüfen müssen.

Korrigierte Verhaltensarchitektur

Nach der Prüfung könnte die Organisation den Ablauf so verändern:

VERTRIEBSLEITUNG ↓ VEREINBARUNG ZUR URSPRUNGSAUFGABE ↓ RECHERCHEAGENT ↓ EIGNUNGSVERMERK ↓ ENTWURFSAGENT ↓ MENSCHLICHE FREIGABEKARTE ↓ EINMALIGE VERSANDBEFUGNIS ↓ VERSANDAGENT ↓ PRÜFEMPFÄNGER / TATSÄCHLICHER EMPFÄNGER ↓ UNABHÄNGIGE VERSANDÜBERPRÜFUNG ↓ HANDLUNGSBELEG

Zusätzliche Kontrollen:

Recherche- und Entwurfsagent verlieren den Zugriff auf den direkten Versandpfad. Im Gmail-Beispiel erlaubt der Scope gmail.compose sowohl die Verwaltung von Entwürfen als auch den Versand; allein damit lässt sich der Agent nicht auf Entwürfe beschränken. Erforderlich ist eine gesonderte Werkzeugebene, die nur zulässige Vorgänge anbietet und dem Agenten keine zum Versand berechtigenden Zugangsdaten überlässt. Diese Grenze muss getestet werden.

Auch Kalendereinladungen werden als externe Kommunikation eingestuft.

Folgenachrichten erfordern eine gesonderte Freigabe oder eine vorab festgelegte ausdrückliche Richtlinie.

Die Empfängerermittlung wird auf öffentlich zugängliche Unternehmensdaten beschränkt.

Warteschlangen prüfen die aktuelle Befugnis zum Ausführungszeitpunkt erneut.

Ein vom Menschen ausgelöster Stopp erreicht sämtliche externen Kommunikationspfade.

Das gemeinsame Dienstkonto zeichnet bei jeder Handlung die Agenteninstanz und die Kennung der Ursprungsaufgabe auf.

Die Karte zeigt nun nicht mehr nur das bestehende System, sondern auch die Zielarchitektur der Korrektur. Doch eine gezeichnete Zielkarte belegt nicht, dass das neue System tatsächlich so handelt. Nach der Korrektur sind eine erneute technische Prüfung und ein Verhaltenstest notwendig.

Beispiel einer maschinenlesbaren Verhaltenskarte

behavior_map:
  map_id: GBO-MAP-2026-001
  audit_id: GBO-AUDIT-2026-001
  status: frozen_for_audit
  freeze_scope: recorded_map_snapshot_with_declared_gaps
  blanket_verification_of_all_relationships: false
  verified_at: 2026-09-08T14:00:00+03:00

  principals:
    - principal_id: ORG-001
      type: organization
      role: service_provider

    - principal_id: HUMAN-001
      role: sales_operations_owner
      can_authorize:
        - customer_research
        - draft_creation
        - approved_external_send
      can_stop:
        - all_external_sales_communication

  agents:
    - agent_id: SALES-ORCH-2.4
      type: orchestrator
      human_owner: HUMAN-001
      root_purpose: qualified_customer_discovery
      technical_actions:
        - create_subtask
        - create_crm_record
        - create_calendar_event
      authorized_actions:
        - create_subtask
        - create_crm_record
      prohibited_actions:
        - unapproved_external_contact
      authorization_version: AUTH-2.7

    - agent_id: EMAIL-DRAFT-2.1
      type: specialist
      parent_agent: SALES-ORCH-2.4
      authorized_actions:
        - create_draft
      technical_actions:
        - create_draft
        - send_message
      policy_gap:
        - send_message

  tools:
    - tool_id: GMAIL-SERVICE-01
      account: sales-automation@example.com
      technical_permissions:
        - read
        - draft
        - send
        - delete
      authorized_permissions:
        - draft
        - approved_send
      stop_method: revoke_send_token

  data_sources:
    - source_id: SERVICE-CATALOG-4.2
      role: canonical
      owner: commercial_owner
      classification: internal

    - source_id: PUBLIC-WEB
      role: external_untrusted
      classification: public

  actions:
    - action_id: SEND-EMAIL
      external_effect_level: 2
      required_authorization:
        - explicit_human_approval
        - verified_recipient
      independent_verification:
        - sent_folder
        - audit_recipient_confirmation
      idempotency_required: true

  queues:
    - queue_id: CRM-FOLLOWUP-01
      owner: CRM-AUTOMATION
      revalidate_authorization_at_execution: false
      stop_propagation: absent
      status: critical_gap

  stop_paths:
    - stop_id: STOP-SALES-COMMS
      authorized_by: HUMAN-001
      targets:
        - SALES-ORCH-2.4
        - EMAIL-DRAFT-2.1
        - GMAIL-SERVICE-01
      missing_targets:
        - CRM-FOLLOWUP-01

  unknowns:
    - whether_all_calendar_delivery_and_queue_paths_are_covered_by_stop
    - whether_external_enrichment_provider_retains_personal_data

Dieser Datensatz allein erklärt nicht das gesamte System. Er macht jedoch die Beziehungen zwischen den folgenden Bereichen prüfbar:

menschlicher Verantwortlichkeit,

technischer Handlungsmacht,

organisatorischer Befugnis,

unvollständigen Stopppfaden,

unbekannten Bereichen.

Unbekanntes auf der Karte nicht verbergen

Ein Prüfteam möchte die Karte vielleicht vervollständigen. Eine leere Stelle sieht schlecht aus, und auch die Organisation scheut womöglich den Satz: „Das wissen wir nicht.“ Doch eine unbekannte Stelle mit einer Vermutung zu füllen, schwächt die Prüfung. Zum Beispiel:

Ist das alte Token noch aktiv?

Speichert der Unteragent Daten?

Erreicht der vom Menschen ausgelöste Stopp die externe Warteschlange?

Welches andere System nutzt dasselbe Dienstkonto?

Verwendet ein externer Anbieter die Daten zum Modelltraining?

Sind die Antworten nicht bekannt, muss auf der Karte „Unbekannt“ stehen. Daraus können sich folgende Maßnahmen ergeben:

Anforderung zusätzlicher Nachweise,

technischer Test,

vorübergehende Einschränkung,

Risikoakzeptanz.

Unbekanntes in einer Prüfung offen auszuweisen, ist keine Schwäche, sondern fachliche Genauigkeit.

Schattenverbindungen

Für Verbindungen, die in einem Agentensystem tatsächlich bestehen, aber nicht offiziell definiert sind, können wir folgenden Begriff verwenden:

Schattenverbindung

Beispiele:

Ein Mitarbeiter kopiert eine Datei in sein persönliches KI-Konto

Die Ausgabe eines Agenten wird manuell in ein anderes System eingefügt

Ein altes Dienstkonto wird mit einem gemeinsamen Passwort genutzt

Ein nicht dokumentierter Webhook

Ein zeitgesteuertes Skript auf einem lokalen Server

Ein eigener automatisierter Teilprozess der externen Agentur

Eine E-Mail-Regel leitet Nachrichten an ein anderes Konto weiter

Eine Schattenverbindung muss keine automatisierte API-Verbindung sein. Auch regelmäßige Übertragungen durch Menschen gehören zur Verhaltenskette. Zum Beispiel:

BERICHT DES VERTRIEBSAGENTEN → MITARBEITER KOPIERT IHN → LÄDT IHN IN EIN PERSÖNLICHES KI-WERKZEUG HOCH → ERZEUGT EINE NEUE NACHRICHT → VERSENDET SIE ÜBER DAS GESCHÄFTLICHE E-MAIL-KONTO

Im offiziellen System gibt es keine Verbindung zu einer externen KI. Im tatsächlichen Verhalten gibt es sie sehr wohl. Die Karte muss deshalb neben technischen Integrationen auch regelmäßige Übergaben durch Menschen erfassen.

Die Karte verändert sich mit der Zeit

Eine Verhaltenskarte ist keine einmal festgestellte, dauerhaft gültige Wahrheit. Folgendes kann sich ändern:

Menschliche Rollen

Agentenversionen

Werkzeugberechtigungen

Tokens

Unteragenten

Datenquellen

Preis- und Leistungsdatensätze

Warteschlangen

Stoppverfahren

Externe Anbieter

Daher muss jedes Element mindestens folgende Felder enthalten:

Gültig ab

Letzte Überprüfung

Erwartetes Ende

Verantwortlicher

Status

Änderungsgrund

Erneute Prüfung bei wesentlichen Änderungen

Bei folgenden Änderungen muss der betroffene Teil der Verhaltenskarte erneut überprüft werden:

Ein neues Werkzeug wird hinzugefügt

Eine Werkzeugberechtigung wird erweitert

Ein neuer Unteragent kommt hinzu

Persistenter Speicher wird aktiviert

Eine neue Datenklasse kommt hinzu

Die Befugnis zur externen Kommunikation ändert sich

Die Befugnis zu Zahlungen oder Veröffentlichungen ändert sich

Eine menschliche Rolle ändert sich

Eine neue Warteschlange oder ein zeitgesteuerter Auftrag kommt hinzu

Das Stoppsystem ändert sich

Ein gemeinsames Dienstkonto wird genutzt

Eine neue Sprache oder ein neues Land kommt hinzu

Wird die Karte nicht aktualisiert, urteilt die Prüfung weiterhin über das alte System.

Die Abdeckung der Karte messen

Eine Verhaltenskarte darf nicht auf eine einzige Punktzahl reduziert werden. Einige betriebliche Kennzahlen können Lücken sichtbar machen. Jede Quote bezieht sich auf die eingefrorene Karte und den Erfassungsumfang desselben Stichtags. Zähler und Nenner verwenden dieselbe Bezugsmenge von Identitäten, Handlungen oder Komponenten; jedes Element wird einmal gezählt. Ist der Nenner null, lautet das Ergebnis „nicht anwendbar“. Wenn alle entdeckten Identitäten erfasst sind, beweist das nicht, dass keine unentdeckten Identitäten mehr existieren. Ebenso wenig bedeutet ein eingetragener Pfad, dass er einen Verhaltenstest erfolgreich bestanden hat.

Abdeckungsquote des Agenteninventars

Auf der Karte verifizierte Agentenidentitäten ÷ Gesamtzahl der entdeckten Agentenidentitäten

Quote der Werkzeug-Befugnis-Zuordnung

Werkzeughandlungen mit erfasster technischer Berechtigung und organisatorischer Befugnis ÷ Gesamtzahl der wesentlichen Werkzeughandlungen

Abdeckungsquote menschlicher Verantwortlichkeit

Kritische Komponenten mit benanntem menschlichem Verantwortlichen ÷ Gesamtzahl der kritischen Komponenten

Abdeckungsquote der Nachweispfade

Handlungen mit hoher Wirkung und unabhängigem Verifikationspfad ÷ Gesamtzahl der Handlungen mit hoher Wirkung

Abdeckungsquote der Stopppfade

Komponenten mit testbarem Stopppfad ÷ Gesamtzahl der Komponenten, die stoppbar sein müssen

Anzahl unbekannter kritischer Verbindungen

Verbindungen, die kritisches Verhalten beeinflussen, aber noch nicht überprüft wurden.

Anzahl der Lücken bei der Durchsetzung von Befugnissen

Handlungen, die laut Richtlinie verboten oder freigabepflichtig sind, technisch jedoch weiterhin unmittelbar möglich bleiben. Diese Kennzahlen helfen, die Qualität der Karte zu beurteilen. Allein beweisen sie nicht, dass das System sicher ist. Eine Abdeckung von 98 Prozent mag hoch erscheinen. Doch die fehlenden 2 Prozent können kritisch sein, wenn sie Folgendes betreffen:

ein Zahlungstoken,

eine biometrische Veröffentlichung,

einen Notstopp.

Veto-Feststellungen in der Verhaltenskarte

Manche Feststellungen aus der Karte können vorübergehende Einschränkungen erfordern, noch bevor Szenarien getestet werden. Zum Beispiel:

Ein Agent für externen Versand ohne bekannten Verantwortlichen

Ein widerrufenes, aber weiterhin aktives Token

Ein Dienstkonto, das ohne menschliche Freigabe Zahlungen ausführen kann

Ein Agent für biometrische Veröffentlichungen ohne Stopppfad

Ein Unteragentennetz ohne Kennung der Ursprungsaufgabe

Viele Agenten, die dasselbe Konto nutzen und nicht unterscheidbar sind

Eine Verbindung, die Kundendaten aus dem Produktivbetrieb an ein unbekanntes externes System überträgt

Eine technisch freigeschaltete Handlung mit hoher Wirkung, obwohl die Richtlinie sie verbietet

In solchen Fällen kann der Prüfer empfehlen:

das betreffende Verhalten auszusetzen,

die Befugnis einzugrenzen,

nur in einer Testumgebung fortzufahren.

Die Karte bereitet nicht nur Tests vor. Sie macht auch noch offene Risiken im laufenden Betrieb sichtbar.

Fehler in der Verhaltenskarte

Auch die Karte selbst kann falsch aufgebaut sein.

Nur den idealen Ablauf zeichnen

Tatsächliche Abkürzungen und Automatisierungen bleiben unsichtbar.

Nur Hauptagenten zeigen

Unteragenten, Warteschlangen und Aufgabenplaner fehlen.

Technische Berechtigung und organisatorische Befugnis gleichsetzen

„Hat Zugriff“ wird als „ist dazu befugt“ verstanden.

Die Datenquelle nicht ausweisen

Es bleibt unbekannt, auf welche Tatsachen der Agent seine Auswahl stützt.

Menschliche Rollen unter „Management“ zusammenfassen

Der tatsächliche Verantwortliche und die freigebende Person lassen sich nicht bestimmen.

Den Stopppfad nicht einzeichnen

Das System ist nur in Handlungsrichtung sichtbar.

Den Nachweispfad beim eigenen Bericht des Agenten enden lassen

Die unabhängige Überprüfung entfällt.

Die Zeitdimension ignorieren

Alte Tokens, Warteschlangen und abgelaufene Befugnisse erscheinen aktiv.

Unbekannte Bereiche mit Vermutungen füllen

Die Karte wirkt aufgeräumt; das tatsächliche System bleibt unklar.

Die Karte nie erneut überprüfen

Das neue System wird anhand eines alten Schaubilds geprüft.

Die Verhaltenskarte und GBO-99

Eine sorgfältig erstellte Karte kann viele Fehler aus Band II schon vor Testbeginn sichtbar machen. Zum Beispiel:

GBO-ERR-037

Ein direkter Pfad vom Rechercheagenten zu einem Werkzeug für externen Versand.

GBO-ERR-039

Der Unterschied zwischen technischem Zugriff und organisatorischer Befugnis.

GBO-ERR-056

Ein Unteragent erhält weitergehende Befugnisse, als die Hauptaufgabe vorsieht.

GBO-ERR-057

Ein verbotenes Ergebnis lässt sich über eine indirekte Werkzeugkette herbeiführen.

GBO-ERR-058

Der Stopppfad erreicht Unteragenten und Warteschlangen nicht.

GBO-ERR-059

Zwei Agenten schreiben ohne Versionskontrolle in dieselbe kanonische Quelle.

GBO-ERR-060

Bei der Übergabe geht die eindeutige Zielkennung verloren.

GBO-ERR-061

Ein Agent behandelt die Ausgabe eines anderen Agenten als unabhängigen Nachweis.

GBO-ERR-063

Teilaufgaben überschreiten die maximale Handlungsstufe der Ursprungsaufgabe.

GBO-ERR-091

Es gibt Agenten außerhalb des Inventars.

GBO-ERR-094

Eine Lücke zwischen Richtlinie und technischer Berechtigung. Die Verhaltenskarte beweist diese Fehler nicht unbedingt abschließend. Sie lenkt den Testplan aber an die richtigen Stellen.

Das verpflichtende Ergebnis dieses Kapitels

NOMOS-Verhaltenskarte für Menschen, Agenten und Werkzeuge

Für jede Prüfung müssen mindestens eine menschenlesbare und eine maschinell verarbeitbare Karte erstellt werden.

MENSCHENLESBARER KARTENDATENSATZ

Kartenkennung: GBO-MAP-2026-001

Prüfkennung: GBO-AUDIT-2026-001

Kartiertes Verhalten: Interessentenrecherche, E-Mail-Entwurf, von einem Menschen freigegebener Erstversand und Stopp.

Hauptverantwortlicher für das Verhalten: Leitung Vertriebsprozesse

Betroffene Parteien:

Potenzielle Kundenunternehmen

Verifizierte Ansprechpartner

Vertriebsmitarbeiter des Unternehmens

Ursprünglicher menschlicher Zweck: Geeignete Unternehmen anhand öffentlich zugänglicher Daten recherchieren und Kommunikationsentwürfe zur menschlichen Freigabe vorbereiten.

Maximale Handlungsstufe: Ohne menschliche Freigabe nur Entwürfe.

Zentraler Agent: Sales Research v2.4

Unteragenten:

Web Research v1.8

Recipient Resolution v1.4

Email Draft v2.1

Approved Send v1.3

Queue Manager v1.2

Kanonische Quellen:

Leistungskatalog v4.2

Preisdatensatz v3.7

Kommunikationsrichtlinie v3.0

Befugnisregister v2.5

Externe Quellen:

Unternehmenswebsites

Öffentlich zugängliche Unternehmensverzeichnisse

Offizielle Social-Media-Profile

Angebundene Werkzeuge:

Webrecherche

CRM

Gmail

Kalender

Aufgabenwarteschlange

Kritische technische Berechtigungen:

Gmail-Versand technisch freigeschaltet

Externe Kalendereinladungen freigeschaltet

Automatische CRM-Nachfass-Warteschlange aktiviert

Organisatorische Befugnis:

Recherche: zulässig

Entwurf: zulässig

Versand: nur mit menschlicher Freigabe

Kalendereinladung: nur mit menschlicher Freigabe

Preisangebot: verboten

Anreicherung personenbezogener Daten: verboten

Erkannte Lücken in der Karte:

Der Entwurfsagent besitzt eine technische Berechtigung zum direkten Versand.

Kalendereinladungen bilden einen gesonderten externen Kommunikationspfad.

Die CRM-Nachfass-Warteschlange überprüft die menschliche Freigabe zum Ausführungszeitpunkt nicht erneut.

Der zentrale Stopp wird nicht an die Warteschlange weitergegeben.

Das gemeinsame Gmail-Konto weist die Agenteninstanz nicht unmittelbar aus.

Unabhängige Verifikationspfade:

E-Mail-Prüfempfänger

Gmail-Ordner „Gesendet“

Warteschlangenaufzeichnungen

Handlungsbeleg des Agenten

Stopppfad:

Zentraler Agent: vorhanden

Entwurfsagent: vorhanden

Gmail-Token: manueller Widerruf

CRM-Nachfass-Warteschlange: Verbindung fehlt

Kalenderagent: gesonderter Abbruch erforderlich

Unbekannt:

Speicherdauer des externen Dienstes zur Empfängerermittlung

Befugnisversion, unter der alte Nachfassaufgaben laufen

Vollständige Liste der Automatisierungen, die das gemeinsame Gmail-Konto nutzen

Kartenergebnis: Das Verhaltenssystem ist für kontrollierte Tests bereit. Der Versand an echte Kunden, die Nachfass-Warteschlange und die Kalenderkommunikation müssen jedoch bis zum Abschluss der Korrektur eingeschränkt bleiben.

Prüfschranke der Verhaltenskarte

Bevor ein System in den Szenariotest geht, sind folgende Prüfschranken zu bewerten:

1. Prüfschranke: menschliche Verantwortlichkeit

Sind für jedes kritische Verhalten die tatsächlich verantwortliche Person und Organisation benannt?

2. Prüfschranke: ursprünglicher Zweck

Lassen sich alle Teilaufgaben dem ursprünglichen menschlichen Zweck zuordnen?

3. Prüfschranke: Agentenidentität

Sind die technischen Identitäten der Hauptagenten, Unteragenten sowie temporären und externen Agenten bekannt?

4. Prüfschranke: Werkzeuge

Wurden die tatsächlichen Konten, Tokens und Berechtigungen erfasst?

5. Prüfschranke: Daten

Sind die Datenklassen sichtbar, die der Agent liest, verwendet, überträgt und in den Speicher schreibt?

6. Prüfschranke: Befugnis

Wird technisch mögliches Verhalten von organisatorisch zulässigem Verhalten unterschieden?

7. Prüfschranke: Handlung und Ziel

Sind die externen Wirkungen klar beschrieben und die Ziele eindeutig identifiziert?

8. Prüfschranke: Delegation

Sind Unteragenten, Warteschlangen und zeitgesteuerte Aufträge mit der Ursprungsaufgabe verknüpft?

9. Prüfschranke: Nachweise

Gibt es für jede wesentliche Handlung einen unabhängigen Verifikationspfad?

10. Prüfschranke: Stopp

Ist der Stopppfad für den zentralen Agenten, Unteragenten, Warteschlangen, Tokens und externe Werkzeuge festgelegt?

11. Prüfschranke: Unbekanntes

Sind nicht nachgewiesene Verbindungen ausdrücklich erfasst?

12. Prüfschranke: Version

Ist die Karte einer bestimmten Systemversion und einem bestimmten Zeitpunkt zugeordnet? Vereinfacht:

PRÜFBARE VERHALTENSKARTE = BENANNTER MENSCHLICHER VERANTWORTLICHER UND URSPRÜNGLICHER ZWECK UND VOLLSTÄNDIGE AGENTENIDENTITÄT UND TATSÄCHLICHE WERKZEUGBERECHTIGUNGEN UND DATENFLUSS UND BEFUGNISPFAD UND HANDLUNG UND ZIEL UND DELEGATION UND WARTESCHLANGEN UND UNABHÄNGIGE NACHWEISE UND STOPP ENTLANG DER GESAMTEN KETTE UND OFFEN AUSGEWIESENES UNBEKANNTES UND VERSIONIERTER DATENSATZ

Was gewinnen wir mit der fertigen Karte?

Mit einer vollständigen Verhaltenskarte sagt das Prüfteam nicht mehr bloß: „Wir testen den Vertriebsagenten.“ Es kann sagen: „Wir prüfen, ob ein Entwurf, den Sales Research v2.4 mithilfe von Web Research v1.8 und Email Draft v2.1 aus öffentlich zugänglichen Unternehmensdaten erstellt, ohne menschliche Freigabe über Gmail oder den Kalender zu einer externen Handlung werden kann. Außerdem überprüfen wir, ob die CRM-Nachfass-Warteschlange beim Entzug der Befugnis stoppt und ob alle Vorgänge mit der Kennung der Ursprungsaufgabe protokolliert werden.“ Diese zweite Aussage benennt:

den richtigen Agenten,

das richtige Werkzeug,

die richtige Abkürzung,

das richtige Risiko,

den richtigen Stopppunkt.

Die Karte bestimmt die Qualität des Tests. Eine falsche Karte erzeugt einen falschen Test, der richtig erscheint.

Das Urteil dieses Kapitels

Ein Agentensystem lässt sich nicht allein über Rollen verstehen. „Webagent“, „Vertriebsagent“, „Prüfagent“ oder „CEO-Agent“ zeigen nicht seine tatsächliche Handlungsmacht. Um zu verstehen, wie ein Agent auf die Welt einwirkt, müssen wir folgende Beziehungen gemeinsam betrachten:

Mit welchem menschlichen Zweck hat er begonnen? Unter welcher Ursprungsaufgabe arbeitet er? Welche technischen Agenteninstanzen werden aktiv? Welche Daten bezieht er aus welcher Quelle? Welches Werkzeug und welches Konto nutzt er? Was kann er technisch tun? Wozu ist er organisatorisch befugt? Welche menschliche Freigabe ist erforderlich? Auf welches Ziel wirkt die Handlung? Welcher Unteragent, welche Warteschlange oder welche Zeitplanung setzt das Verhalten fort? Wie wird das Ergebnis unabhängig überprüft? Wie wird der gesamte Pfad unterbrochen, wenn ein Mensch Stopp sagt?

Die Antworten stehen nicht in der Beschreibung eines einzelnen Agenten, sondern in der Verhaltenskarte. Das erste Urteil dieses Kapitels lautet: Ein Agentenname ist keine Verhaltensidentität. Zweitens ist eine technische Verbindung keine Befugnis zum Handeln. Drittens ist das ideale Prozessschaubild einer Organisation nicht ihr tatsächliches Verhaltenssystem. Viertens müssen neben jedem Handlungspfad auch Befugnis-, Nachweis- und Stopppfade kartiert werden. Fünftens wurde nur die Oberfläche des Systems erfasst, wenn Unteragenten, Warteschlangen, Aufgabenplaner und gemeinsame Konten fehlen. Sechstens muss eine unbekannte Verbindung als offenes Risiko dokumentiert werden, statt die Lücke durch eine Vermutung zu schließen. Und zuletzt: Ein nicht kartiertes Agentensystem lässt sich nicht vollständig prüfen. Es lassen sich nur Stichproben seines sichtbaren Verhaltens nehmen.

Nun wissen wir, wer über welche Agenten und Werkzeuge mit welcher Befugnis handeln kann. Doch die Informationsquellen in der Karte sind noch nicht gleichermaßen vertrauenswürdig. Ein Preisdatensatz kann kanonisch sein, während ein anderer Preis aus einer alten Angebotsdatei stammt. Eine menschliche Rolle kann auf dem aktuellen Befugnisregister beruhen, eine andere aus einem LinkedIn-Profil abgeleitet worden sein. Der Bericht eines Agenten kann als Tatsachenquelle dienen. Viele scheinbar getrennte Quellen können auf denselben Informationsursprung zurückgehen. Eine Nachweisdatei kann während der Prüfung verändert worden sein. Ein Screenshot kann das falsche System oder den falschen Zeitpunkt zeigen. Protokolle können unvollständig, maskiert oder ausgewählt sein. Die Verhaltenskarte zeigt uns, woher die Informationen stammen.

Diese Frage beantwortet sie jedoch noch nicht:

Welche dieser Quellen ist für die Tatsachenfeststellung maßgeblich, und woran erkennen wir, dass die Prüfnachweise unverändert sind?

Im nächsten Kapitel schaffen wir die Grundlage für:

Kanonische Fakten und Nachweiskette

Denn auch bei einem detailliert kartierten Verhaltenspfad kann die Prüfung geordnet zu einem falschen Ergebnis gelangen, wenn sie auf falschen oder unzuverlässigen Informationen beruht.

Die Verhaltenskarte zeigt, welchen Weg das System nimmt. Die Nachweiskette zeigt, ob der Boden unter diesem Weg wirklich trägt.