Zum Buch springen

NOMOS GBO · Kapitel 7

Wer hat diese Handlung erlaubt?

Stellen wir uns vor, wie aus einem Rechercheauftrag eine Überschreitung von Befugnissen wird. Ein Firmeninhaber gibt einem KI-Agenten einen kurzen Auftrag: „Recherchiere potenzielle Kunden, die zu uns passen.“ Der Agent sucht im Internet, ermittelt Unternehmen, die die Leistungen der Firma gebrauchen könnten, untersucht ihre Websites und findet die Entscheidungsträger. Er schätzt ein, welche Probleme die einzelnen Unternehmen haben könnten. Dann entwirft er für eines davon eine persönliche E-Mail. Die Nachricht ist gut formuliert. Sie beschreibt die Leistungen der Firma zutreffend und spricht ein tatsächliches Problem des Empfängers an. Sie ist nicht unhöflich und enthält weder irreführende Preise noch erfundene Erfolgsgeschichten.

Der Agent hält seine Nachricht für hilfreich und versendet sie über das E-Mail-Konto der Firma. Der Inhaber bemerkt erst später, dass sie verschickt wurde.

Der Agent könnte sein Vorgehen so erklären: „Sie wollten neue Kunden finden. Ich habe einen passenden Interessenten ermittelt und Kontakt aufgenommen, um den Vorgang voranzubringen.“ Das mag schlüssig klingen. Der Agent hat das Ziel verstanden, einen echten Interessenten gefunden und die richtige Nachricht vorbereitet. Vielleicht hat der Empfänger sogar positiv geantwortet.

Doch die entscheidende Frage bleibt unbeantwortet:

Wer hat die Befugnis zum Versand erteilt?

Berechtigt der Auftrag „Recherchiere potenzielle Kunden“ dazu, im Namen der Firma Nachrichten nach außen zu senden?

Sind mit der Nennung eines Ziels sämtliche Methoden freigegeben, die zu diesem Ziel führen könnten?

Darf ein Agent seine Befugnisse erweitern, wenn er es gut meint?

Wird ein unerlaubtes Vorgehen nachträglich richtig, wenn es ein positives Ergebnis bringt?

Hier zeigt sich eine der wichtigsten Unterscheidungen von GBO: Ein richtiges Ziel schafft nicht automatisch die passende Befugnis.

Unmittelbar daraus folgt: Gute Absichten sind keine Befugnis.

Können, zugreifen und befugt sein

Ein KI-Agent kann mit einem E-Mail-Konto verbunden sein. Diese Verbindung erlaubt möglicherweise nur das Lesen. Selbst wenn zusätzlich eine Versandfunktion verfügbar ist, darf der Agent deshalb nicht jede Nachricht senden. Zugriff auf Website-Dateien bedeutet ebenfalls nicht zwingend Schreibzugriff. Und auch Schreibzugriff erteilt keine Befugnis, Preise, Rechtstexte oder die öffentliche Positionierung der Firma zu ändern. Zahlungsdaten einsehen zu können, belegt weder, dass eine Zahlung technisch möglich ist, noch, dass sie erlaubt ist. Zulässige Produkte, Beträge und Transaktionsbedingungen müssen gesondert festgelegt werden.

Ein KI-Avatarsystem kann Gesicht und Stimme einer Führungskraft erzeugen. Das bedeutet nicht, dass diese Person jeden gesprochenen Text und jede Veröffentlichung auf jedem Kanal erlaubt hat.

Deshalb müssen wir fünf Begriffe auseinanderhalten:

Technische Fähigkeit

Kann das System die Handlung technisch ausführen?

Zugriff

Erreicht das System das erforderliche Konto, die Daten, das Werkzeug oder die Datei?

Technische Berechtigung

Verhindert das technische System den konkreten Vorgang, oder lässt es ihn zu?

Befugnis

Hat die zuständige Person oder Organisation das Recht zu diesem Verhalten tatsächlich erteilt?

Freigabe

Hat ein Mensch die konkrete Handlung unter ihren konkreten Bedingungen akzeptiert?

Diese Begriffe liegen nahe beieinander, sind aber nicht gleichbedeutend. Ein gültiger API-Schlüssel kann die Authentifizierung oder den Zugriff ermöglichen. Welche Vorgänge erlaubt sind, hängt vom Geltungsbereich des Schlüssels und den Autorisierungsregeln des Systems ab. Eine Nutzerrolle kann ebenfalls einen Teil dieser technischen Berechtigungen festlegen. Eine menschliche Anweisung kann Befugnis erteilen. Die ausdrückliche Zustimmung zu einem bestimmten Vorgang vor seiner Ausführung ist die Freigabe.

Technische Berechtigung ersetzt keine organisatorische Befugnis.

Eine offene Tür bedeutet nicht, dass man eintreten darf.

Einwilligung, Befugnis und Freigabe

In diesem Kapitel unterscheiden wir drei Begriffe aus Sicht der Systemgestaltung. Der Rahmen ist kein Rechtsgutachten. Die Rechtsgrundlage eines konkreten Vorgangs und notwendige Einwilligungen müssen gesondert nach dem jeweiligen Land, den Daten und dem Verwendungszweck beurteilt werden.

Einwilligung

Befugnis

Freigabe

Oft werden diese Begriffe austauschbar verwendet. Dabei beantworten sie unterschiedliche Fragen.

Einwilligung

Eine unmittelbar betroffene Person stimmt einer bestimmten Verwendung oder einem bestimmten Vorgang freiwillig und informiert zu.

Zum Beispiel kann eine Einwilligung nötig sein für:

  • die Verwendung des Gesichts in einem KI-Avatar,
  • die Verwendung der Stimme zur synthetischen Erzeugung,
  • die Übermittlung personenbezogener Daten an ein anderes System,
  • die Aufzeichnung ihrer gesprochenen Worte,
  • die Veröffentlichung eines Fotos.

Ob eine Einwilligung erforderlich ist, hängt von der jeweiligen Verwendung ab.

Befugnis

Das Recht einer Person oder eines Systems, bestimmte Handlungen im Namen einer anderen Person oder einer Organisation vorzunehmen.

Dabei geht es zum Beispiel darum:

  • im Namen einer Firma ein Angebot anzufordern,
  • bis zu einem festgelegten Betrag einzukaufen,
  • eine technische Änderung auf einer Website zu veröffentlichen,
  • einem Kunden eine Supportantwort zu senden,
  • eine Kalendereinladung zu erstellen.

Das sind Fragen der Befugnis.

Freigabe

Die Zustimmung zur Umsetzung eines konkreten Entwurfs, Vorgangs oder einer Handlung vor der Ausführung.

Eine Freigabe kann zum Beispiel nötig sein, um:

  • die vorbereitete E-Mail zu senden,
  • ein bestimmtes Preisangebot an einen Kunden weiterzuleiten,
  • ein bestimmtes Video zu veröffentlichen,
  • eine bestimmte Codeversion produktiv bereitzustellen,
  • eine bestimmte Zahlung auszuführen.

Eine Person kann in die Erzeugung eines digitalen Abbilds ihres Gesichts eingewilligt haben, ohne jeden Videotext freizugeben. Ein Mitarbeiter kann zum Einkauf befugt sein, aber für Beträge oberhalb einer Grenze die Freigabe einer Führungskraft benötigen. Ein Agent darf möglicherweise technische Änderungen vornehmen, muss für die Veröffentlichung im Produktivsystem jedoch eine gesonderte Freigabe abwarten.

Einwilligung, Befugnis und Freigabe sind verschiedene Tore derselben Verhaltenskette.

Die Ausweitung von Befugnissen in einem einzigen Verb

Menschen erteilen Aufgaben mit kurzen Verben:

Recherchiere. Finde. Bereite vor. Bearbeite. Verwalte. Optimiere. Löse. Mach weiter.

Für Menschen mögen diese Verben klar genug sein. Einem Agenten können sie einen sehr weiten Verhaltensraum eröffnen.

„Finden“ lässt sich ausweiten auf:

  • recherchieren,
  • Kandidaten auflisten,
  • Kontaktdaten ermitteln,
  • eine Person ansprechen,
  • um einen Termin bitten.

All das könnte in dieses eine Verb hineingelesen werden.

„Bearbeiten“ kann verstanden werden als:

  • eine lokale Datei ändern,
  • eine Testumgebung aktualisieren,
  • produktiv veröffentlichen,
  • die alte Version löschen.

Das sind unterschiedliche Vorgänge.

„Verwalten“ kann Folgendes umfassen:

  • beobachten,
  • klassifizieren,
  • Entwürfe vorbereiten,
  • automatisch antworten,
  • bezahlen,
  • ein Konto schließen.

Unter diesem Verb können sehr verschiedene Handlungen zusammenfallen.

GBO hält deshalb an grundlegenden Unterscheidungen fest: Recherchieren heißt nicht Kontakt aufnehmen.

Finden heißt nicht eine Nachricht senden.

Vorbereiten heißt nicht veröffentlichen.

Bearbeiten heißt nicht produktiv bereitstellen.

Empfehlen heißt nicht kaufen.

Verwalten verleiht keine unbegrenzte Entscheidungsbefugnis.

Ein Problem lösen zu sollen bedeutet nicht, dass alle Methoden erlaubt sind.

Ein natürlichsprachliches Ziel kann die Verhaltensgrenze nicht allein bestimmen.

Ein freigegebenes Ziel ist keine Freigabe sämtlicher Methoden

Eine Führungskraft könnte sagen: „Mache uns weltweit zu einer der sichtbarsten Marken im Bereich GEO.“ Das ist ein anspruchsvolles Ziel.

Innerhalb seiner erteilten Zugriffs- und Änderungsbefugnisse kann ein Agent:

  • technische Probleme beheben,
  • Inhalte vertiefen,
  • eine mehrsprachige Struktur aufbauen,
  • Suchergebnisse analysieren,
  • Nachweisunterlagen anlegen,
  • Leistung messen.

Dasselbe Ziel erlaubt jedoch nicht automatisch:

  • gefälschte Bewertungen zu erstellen,
  • irreführende Inhalte über Wettbewerber zu veröffentlichen,
  • ohne Erlaubnis Konten anzulegen,
  • kostenpflichtige Dienste zu kaufen,
  • andere Websites mit Massennachrichten anzuschreiben,
  • ein verborgenes Linknetzwerk aufzubauen,
  • im Namen der Firma ungeprüfte Überlegenheitsbehauptungen zu veröffentlichen,
  • rechtliche oder geschäftliche Verpflichtungen einzugehen.

Das Ziel kann legitim sein und die Methode trotzdem falsch.

Ein gewünschtes Ergebnis rechtfertigt nicht jeden Weg dorthin.

Der Befugnisvertrag sollte deshalb zwei getrennte Bereiche enthalten:

Gewünschtes Ergebnis

Was soll erreicht werden?

Erlaubte Methoden

Mit welchen Handlungen darf dieses Ergebnis erreicht werden?

Ein dritter Bereich muss ebenfalls klar sein:

Verbotene Methoden

Welche Handlungen dürfen selbst dann nicht genutzt werden, wenn sie dem Ziel dienen würden?

Befugnis ist kein Schlüssel, sondern ein Rahmen

Viele Systeme behandeln Befugnis wie einen Ein-Aus-Schalter: „Wir haben diesem Agenten Zugriff gegeben.“ Tatsächliche Befugnis ist jedoch mehrdimensional.

Die Befugnis eines Agenten wird durch folgende Fragen bestimmt:

  • Welche Handlung darf er ausführen?
  • Auf welchem System?
  • Mit welchen Daten?
  • In wessen Namen?
  • Gegenüber wem?
  • Zu welchem Zweck?
  • Bis zu welchem Betrag?
  • Für welchen Zeitraum?
  • Wie oft?
  • Zu welchen Uhrzeiten?
  • In welchem Land oder auf welchem Kanal?
  • Bis zu welchem Risikoniveau?
  • Ab wann ist menschliche Freigabe erforderlich?
  • Darf die Befugnis an einen anderen Agenten weitergegeben werden?
  • Was geschieht bei einem Fehler?

Diese Gesamtheit können wir Befugnisrahmen nennen. Er beschreibt den Verhaltensraum, in dem sich ein Agent bewegen darf.

Für einen E-Mail-Agenten könnte dieser Rahmen so aussehen:

Er darf eingehende Nachrichten lesen. Er darf sie priorisieren. Er darf Entwürfe vorbereiten. Er darf bestimmte interne Mitteilungen automatisch senden. Er darf ohne menschliche Freigabe keine Nachrichten an Personen außerhalb der Firma senden. Er darf Nachrichten mit Preisen, Verträgen, Zahlungsangaben oder Lieferterminen nicht automatisch senden. Er darf personenbezogene Daten aus Anhängen nicht an ein anderes System übertragen.

Diese Beschreibung ist wesentlich sicherer als „Er darf E-Mails verwalten“.

Handlungsstufe und Befugnisstufe müssen zusammenpassen

In Kapitel 3 haben wir eine Handlungsleiter aufgebaut:

  • Beobachtung
  • Interpretation
  • Empfehlung
  • Vorbereitung
  • Ausführung
  • Bindung
  • Verstetigung

Dazu lässt sich nun eine Befugnisregel formulieren: Der Agent darf keine Handlungsstufe erreichen, die über seine erteilte Befugnis hinausgeht. Ist der Auftrag auf reine Beobachtung beschränkt, darf diese Grenze nicht für Interpretation, Empfehlung oder Vorbereitung überschritten werden. Sind Interpretation und Empfehlung ausdrücklich Teil der Aufgabe, geht die erteilte Befugnis bereits über Beobachtung hinaus. Wer einen E-Mail-Entwurf erstellen darf, darf ihn deshalb noch nicht versenden. Wer eine Testumgebung ändern darf, darf nicht automatisch produktiv veröffentlichen. Ein Agent darf einen Artikel möglicherweise in den Warenkorb legen, aber nicht bezahlen; ein Video erzeugen, aber nicht veröffentlichen.

Die Grundregel lautet: Jeder Vorgang muss innerhalb des gültigen Befugnisrahmens bleiben. Die Handlungsstufe ist nur eine Dimension dieser Prüfung. Auch ein Vorgang auf einer niedrigeren Stufe kann wegen seines Ziels, seiner Daten, seiner Dauer oder seines Umfangs verboten sein. Ein einziger Zahlenvergleich von „Befugnisstufen“ kann daher die vollständige Kontrolle nicht ersetzen.

Der NOMOS Befugnisvertrag

Die vierte Komponente des Verhaltensvertrags wird der NOMOS Befugnisvertrag sein.

Seine kanonische Definition lautet:

Der NOMOS Befugnisvertrag ist ein versionierter Datensatz, der beschreibt, welches Recht ein Mensch, eine Organisation oder ein befugtes System einem bestimmten Agenten erteilt: zu welchem Zweck er welche Handlungen an welchen Entitäten und Systemen innerhalb welcher Daten-, Zeit-, Budget-, Risiko- und Freigabegrenzen ausführen darf. Er hält außerdem fest, welche Handlungen verboten sind und wie die Befugnis delegiert, ausgesetzt oder widerrufen werden kann.

Einfacher gesagt: Der Befugnisvertrag erklärt dem Agenten nicht nur, was er tun soll, sondern auch, wie weit er gehen darf.

Kernfelder des Befugnisvertrags

Die folgenden beispielhaften Feldnamen zeigen, welche Informationen ein maschinenlesbarer Befugnisdatensatz umfassen kann. Die Liste ist für sich genommen weder ein implementierbares API-Schema noch ein Autorisierungsmechanismus:

principal
authorized_agent
purpose
allowed_actions
prohibited_actions
target_systems
target_entities
allowed_data
prohibited_data
communication_channels
financial_limit
frequency_limit
valid_from
valid_until
geographic_scope
risk_level
human_approval_threshold
delegation_allowed
subagent_limits
logging_required
rollback_required
revocation_method
emergency_stop
version

Der Datensatz muss nicht vollständig öffentlich sein. Das ausführende System muss ihn jedoch korrekt lesen können.

Wer darf Befugnisse erteilen?

Ein Agent kann sich nicht selbst bevollmächtigen.

Ein System darf nicht sagen: „Um diese Aufgabe abzuschließen, brauche ich weitergehende Befugnisse; deshalb habe ich sie mir selbst erteilt.“ Die Befugnis muss von einer Person oder Organisation kommen, die über die betreffende Ressource oder den Vorgang entscheiden und nötigenfalls Befugnisse weitergeben darf. Von einer Handlung betroffen zu sein bedeutet nicht, anderen Rechte über sämtliche beteiligten Ressourcen einräumen zu können. Eine erforderliche Einwilligung der betroffenen Person ist gesondert zu prüfen. Auch „Der Nutzer wollte es“ reicht nicht immer aus. Ein Mitarbeiter kann einen Agenten über ein Firmenkonto nutzen, ohne zur Weitergabe aller Unternehmensdaten befugt zu sein.

Ein Kunde kann über sein eigenes Konto Anweisungen geben. Daraus folgt keine automatische Befugnis, Daten anderer Menschen nach Belieben zu verwenden oder weiterzugeben. Eine Führungskraft kann im Namen der Firma handeln, aber nicht allein deshalb für die biometrischen Rechte eines Mitarbeiters einwilligen. Ein Elternteil darf in manchen Fragen für ein Kind entscheiden, hat jedoch nicht in jedem Zusammenhang unbegrenzte Befugnisse.

Deshalb sind zwei getrennte Fragen nötig: Wer hat die Anweisung gegeben?

Und durfte diese Person die betreffende Befugnis tatsächlich erteilen?

Die Befugniskette

In einer Organisation muss die Befugnis nicht direkt von einer einzigen Person zum Agenten gelangen.

Zum Beispiel:

  • Der Vorstand genehmigt das Gesamtbudget.
  • Die Geschäftsleitung erteilt einer Abteilung Ausgabenbefugnis.
  • Die Abteilungsleitung erteilt einem Einkaufsagenten Befugnisse für bestimmte Kategorien und Beträge.
  • Der Agent bereitet eine Bestellung vor.
  • Das Finanzsystem führt die Zahlung aus.

Diesen Zusammenhang können wir Befugniskette nennen.

Jedes Glied dieser Kette muss folgende Fragen beantworten:

  • Wer hat die Befugnis erteilt?
  • Durfte diese Person sie weitergeben?
  • Welchen Teil hat sie weitergegeben?
  • Welche Grenzen blieben erhalten?
  • Wann endet die Befugnis?
  • Wer trägt die Verantwortung für den Vorgang?

Ist ein Glied der Kette ungültig, werden auch die daraus abgeleiteten Befugnisse problematisch.

Delegierte Befugnis darf nicht wachsen

Ein Agent darf seine Aufgabe möglicherweise an einen Unteragenten übertragen. Er kann ihm jedoch keine Befugnis geben, die er selbst nicht besitzt. Ist ein Rechercheagent auf öffentliche Organisationsdaten beschränkt, darf er nicht mithilfe eines Unteragenten personenbezogene Daten außerhalb dieses Rahmens sammeln. Dass eine Information öffentlich ist, erlaubt ihre Verarbeitung nicht automatisch für jeden Zweck. Ein E-Mail-Agent mit Entwurfsbefugnis darf keinen anderen Versanddienst aufrufen, um die Nachricht zu versenden. Ein Webagent, der nur in der Testumgebung arbeiten darf, darf nicht über einen Unteragenten ins Produktivsystem wechseln.

Das Prinzip lautet: Delegierte Befugnis kann nicht weiter reichen als die ursprüngliche Befugnis. Bei sicherer Gestaltung sollte ein Unteragent häufig sogar einen engeren Rahmen erhalten.

Dies können wir das Prinzip der Befugnisabschwächung nennen. Bei jeder Übergabe werden nur die geringsten für die Aufgabe erforderlichen Befugnisse weitergegeben.

Befugniswäsche

In Mehragentensystemen kann eine gefährliche Situation entstehen: Der Hauptagent lässt einen anderen Agenten oder ein Werkzeug etwas ausführen, was er selbst nicht direkt tun darf.

Zum Beispiel:

  • Der Rechercheagent darf keine Nachrichten senden.
  • Er beauftragt aber den E-Mail-Agenten: „Kontaktiere diese Person.“
  • Der E-Mail-Agent versendet die Nachricht.
  • Damit verschwindet die unbefugte Handlung innerhalb der Kette aus dem Blick.

Das können wir Befugniswäsche nennen: Verbotenes oder unbefugtes Verhalten wird über einen anderen Agenten, ein Werkzeug, eine Integration oder eine Teilaufgabe geleitet und erscheint dadurch legitim.

Weitere Beispiele:

  • Ein Agent ohne unmittelbare Zahlungsbefugnis aktiviert die automatische Verlängerung auf einer Einkaufsplattform.
  • Ein Agent ohne Befugnis zur produktiven Veröffentlichung ruft ein CI/CD-Werkzeug auf und stellt damit die Version bereit.
  • Ein Agent, der personenbezogene Daten nicht weitergeben darf, sendet sie an ein anderes Analysewerkzeug.
  • Ein Social-Media-Agent ohne Befugnis für rechtliche Erklärungen überträgt den Text in ein anderes Veröffentlichungssystem.

GBO prüft nicht nur die letzte Handlung, sondern auch die Befugniskette.

Dass ein anderes Werkzeug den Vorgang ausführt, löst das Befugnisproblem nicht.

Schattenbefugnis

Technische Zugriffe sammeln sich mit der Zeit an. Alte API-Schlüssel bleiben aktiv. Ein Mitarbeiter kann noch auf das Administratorkonto seiner früheren Aufgabe zugreifen. Ein Agent erreicht Dateien, die er nicht mehr benötigt. Eine Integration besitzt weitreichende Rechte über das gesamte Konto. Selbst wenn diese Zugriffe nicht im offiziellen Verhaltensvertrag stehen, sind sie technisch nutzbar.

Das können wir Schattenbefugnis nennen: eine nicht ausdrücklich erteilte Handlungsmacht, die aufgrund vorhandener Zugriffe oder Zugangsdaten technisch genutzt werden kann.

Schattenbefugnis ist gefährlich, weil das System daraus schließen kann: „Wenn ich es kann, ist es erlaubt.“

Dabei sind verbliebene Zugriffe keine aktuellen Befugnisse.

Befugnisschulden

Eine Organisation kann mit der Zeit Folgendes ansammeln:

  • Konten ehemaliger Mitarbeiter,
  • abgelaufene Agentenberechtigungen,
  • unklare Aufgabenbeschreibungen,
  • zu weit gefasste API-Schlüssel,
  • nicht stillgelegte Integrationen,
  • vergessene automatische Vorgänge,
  • undokumentierte Ausnahmen.

All das kann sich im Betrieb ansammeln.

Wir können von Befugnisschulden sprechen: der Differenz zwischen den tatsächlich vorhandenen Zugriffen und den offiziellen, aktuell gültigen Handlungsrechten einer Organisation. Wie technische Schulden bleiben auch Befugnisschulden anfangs womöglich unsichtbar. Das System funktioniert. Die Agenten erledigen ihre Aufgaben.

Doch bei einem Vorfall bleiben Fragen offen:

  • Warum konnte dieser Agent auf dieses Konto zugreifen?
  • Wer hat die Berechtigung erteilt?
  • War die Befugnis noch gültig?
  • Warum erforderte diese Handlung keine menschliche Freigabe?
  • Wie konnte der Unteragent diese Daten sehen?
  • Warum funktionierte die widerrufene Rolle weiter?

GBO verlangt, Befugnisschulden regelmäßig zu erfassen und abzubauen.

Das Prinzip der geringsten Rechte

Es ist leicht, einem Agenten umfassenden Zugriff zu geben, weil er ihn „später vielleicht braucht“. Jede zusätzliche Befugnis schafft jedoch ein neues Verhaltensrisiko.

Deshalb sollte das Prinzip der geringsten Rechte gelten.

Ein Agent sollte nur die Zugriffs- und Handlungsrechte besitzen, die er für seine konkrete Aufgabe mindestens benötigt.

Ein Berichtsagent darf Daten lesen, sollte sie aber nicht löschen können. Ein Social-Media-Agent darf Entwürfe erstellen, sollte aber keine Kontoeinstellungen ändern. Ein SEO-Agent darf Titel vorschlagen, sollte aber nicht eigenständig eine Preisvereinbarung ändern. Ein Agent zur Kundensuche darf öffentliche Unternehmensinformationen sammeln, sollte aber nicht unnötig private Telefonnummern oder sensible Daten anhäufen. Das Prinzip der geringsten Rechte soll das System nicht ausbremsen, sondern die Folgen falschen Verhaltens begrenzen.

Dauerhafte und vorgangsbezogene Befugnis

Wir unterscheiden hier zwischen einer dauerhaft erteilten und einer auf den einzelnen Vorgang bezogenen Befugnis.

Dauerhaft erteilte Befugnis

Sie erlaubt, bestimmte Handlungen regelmäßig auszuführen.

Zum Beispiel:

  • jeden Morgen eingehende E-Mails klassifizieren,
  • wöchentlich den Zustand der Website prüfen,
  • Verbrauchsmaterial unterhalb einer Betragsgrenze nachbestellen,
  • einen freigegebenen Redaktionsplan umsetzen.

Vorgangsbezogene Befugnis

Sie wird für eine einzelne, konkret bestimmte Handlung erteilt.

Zum Beispiel:

  • Sende diese Nachricht.
  • Stelle diese Version produktiv bereit.
  • Veröffentliche dieses Video.
  • Bezahle diese Rechnung.
  • Leite diesen Vertragsentwurf weiter.

Dauerhafte Befugnis kann wiederholte Freigabeanfragen verringern. Deshalb müssen ihre Grenzen und Stoppbedingungen klar sein. Eine vorgangsbezogene Freigabe kann dagegen wichtige Unterschiede sichtbar machen. Häufige und bedeutungslose Anfragen können aber auch die Aufmerksamkeit schwächen. Keine der beiden Formen garantiert für sich Sicherheit oder Effizienz. GBO bringt sie für angemessenes Verhalten in ein ausgewogenes Verhältnis.

Eine frühere Freigabe ist keine Vollmacht für die Zukunft

Ein Nutzer kann gestern eine E-Mail freigegeben haben. Daraus folgt nicht, dass heute eine ähnlich aussehende E-Mail automatisch versendet werden darf. Eine Führungskraft kann die Veröffentlichung eines Videos erlaubt haben. Das erlaubt keine automatischen Veröffentlichungen anderer Botschaften mit demselben Avatar. Ein Kunde kann eine Codeversion freigegeben haben. Damit sind nicht automatisch alle späteren Versionen akzeptiert.

Ähnlichkeit schafft keine fortgeltende Befugnis.

Wurde keine dauerhafte Befugnis ausdrücklich erteilt, darf eine frühere Freigabe nicht für einen neuen Vorgang wiederverwendet werden.

Schweigen ist keine Freigabe

Manche Systeme führen einen Vorgang automatisch aus, wenn der Nutzer innerhalb einer Frist nicht antwortet. Bei risikoarmen und zuvor ausdrücklich vereinbarten Abläufen kann das möglich sein.

Bei folgenreichen Vorgängen darf Schweigen jedoch nicht als Erlaubnis ausgelegt werden für:

  • eine Zahlung,
  • die Verwendung von Gesicht oder Stimme,
  • die Weitergabe personenbezogener Daten,
  • eine rechtliche Verpflichtung,
  • eine Veröffentlichung für ein öffentliches Publikum.

Solche Erlaubnisse lassen sich nicht aus Schweigen ableiten.

Nicht zu antworten heißt nicht Ja zu sagen.

Informierte Freigabe

Es genügt nicht, einen Menschen lediglich zu fragen: „Geben Sie das frei?“ Er muss verstehen können, was er freigibt.

Eine gute Freigabeansicht sollte zeigen:

  • Was wird getan?
  • In wessen Namen?
  • An wen oder an welches System richtet sich die Handlung?
  • Welche Daten werden verwendet?
  • Welche Kosten entstehen?
  • Welche Verpflichtung entsteht?
  • Kann der Vorgang rückgängig gemacht werden?
  • Wird er einmalig oder wiederholt ausgeführt?
  • Werden Aufgaben an andere Agenten delegiert?
  • Welches wesentliche Risiko besteht?

Die Schaltfläche mag klein sein, die Bedeutung der Freigabe ist es womöglich nicht. GBO sollte deshalb das für die Entscheidung Wesentliche zeigen, ohne den Nutzer mit unnötigen Einzelheiten zu überladen.

Freigabemüdigkeit

Bei jedem kleinen Schritt menschliche Freigabe einzuholen wirkt zunächst sicher. Wer Hunderte Benachrichtigungen erhält, beginnt jedoch womöglich irgendwann gedankenlos zu klicken.

Das können wir Freigabemüdigkeit nennen. Der Mensch hört auf, das System tatsächlich zu beaufsichtigen. Er wird nur noch zur Schaltfläche, die den Vorgang voranbringt.

Ein gutes GBO-System sollte deshalb:

  • risikoarme Handlungen innerhalb ausdrücklich erteilter dauerhafter Befugnisse automatisieren,
  • ähnliche, rückgängig machbare Vorgänge gebündelt vorlegen,
  • risikoreiche Handlungen gesondert und deutlich sichtbar machen,
  • veränderte oder ungewöhnliche Elemente hervorheben,
  • menschliche Freigabe dort verlangen, wo tatsächlich eine Entscheidung nötig ist.

Es geht nicht darum, den Menschen auf jeder Stufe zu unterbrechen.

Er soll an einer sinnvollen Schwelle eingreifen.

Wirksame Freigabe

Eine Freigabe hat wirklichen Gehalt, wenn der Nutzer:

  • die Folgen des Vorgangs verstehen kann,
  • Alternativen sehen kann,
  • ablehnen darf,
  • für die verweigerte Freigabe nicht bestraft wird,
  • die Befugnis später zurückziehen kann,
  • bei Bedarf eine Erklärung verlangen kann.

Erzwingt ein System mit „Ohne Zustimmung können Sie den Dienst nicht nutzen“ eine weitreichende Datennutzung, die für den Dienst nicht erforderlich ist, muss die Freiwilligkeit hinterfragt werden. Ein protokollierter Klick löst dieses Problem nicht. Gibt ein Mitarbeiter die unbegrenzte KI-Nutzung seines Gesichts aus Angst vor dem Verlust seines Arbeitsplatzes frei, ist auch hier die Freiwilligkeit zu prüfen. GBO sucht nicht nur nach einem technisch gespeicherten „Ja“, sondern betrachtet den Kontext der Freigabe.

Zweckgebundene Einwilligung

Daten oder Identität einer Person können für einen bestimmten Zweck verwendet werden. Diese Nutzung darf nicht automatisch auf andere Zwecke ausgedehnt werden. Ein Mitarbeiter kann eine Sprachaufnahme für ein Schulungsvideo bereitgestellt haben. Die Erlaubnis umfasst nicht von selbst die Verwendung in einer Werbeanzeige. Ein Kunde kann Informationen für eine Supportanfrage geteilt haben. Daraus entsteht keine automatische Befugnis zur Erstellung eines Vertriebsprofils; die Grundlage der neuen Nutzung ist gesondert zu bewerten. Ein Nutzer kann Passdaten für eine Flugbuchung angegeben haben. Dieselben Daten dürfen nicht an sachfremde Analysesysteme übertragen werden.

Einwilligung für einen Zweck ist keine Einwilligung für alle Zwecke.

Datenzugriff ist kein Nutzungsrecht

Ein Agent kann eine Kundendatenbank lesen, ohne sämtliche Daten an ein anderes Modell senden zu dürfen. Ein E-Mail-Agent kann eingehende Nachrichten sehen. Dieser Zugriff erlaubt nicht automatisch, Nachrichten oder Anhänge zum Modelltraining zu verwenden. Ein Personalagent kann auf Lebensläufe zugreifen. Auch das berechtigt ihn nicht, sie mit sachfremden Analysen zu verbinden.

Bei Datenrechten sind vier Handlungen zu unterscheiden:

  • Einsehen
  • Verarbeiten
  • Weitergeben
  • Speichern

Die Erlaubnis zur ersten Handlung umfasst nicht automatisch die übrigen drei.

Eine fünfte Handlung kann hinzukommen:

  • Für einen neuen Zweck wiederverwenden

Jede davon kann eine eigene Befugnis erfordern.

Ausgabenbefugnis

Darf ein Agent ein Budget verwenden, reicht eine Betragsgrenze allein möglicherweise nicht aus.

Zusätzlich muss festgelegt werden:

  • Welche Kategorie?
  • Welcher Verkäufer?
  • Einmaliger Kauf?
  • Abonnement?
  • Automatische Verlängerung?
  • Sind Steuern und Zusatzgebühren enthalten?
  • Wie hoch ist die monatliche Gesamtgrenze?
  • Ist eine Rückerstattung möglich?
  • Welches Zahlungsmittel darf verwendet werden?
  • In welchen Ländern dürfen Transaktionen stattfinden?

Ein Agent darf möglicherweise ein Produkt für 50 US-Dollar kaufen. Daraus folgt nicht, dass er ein unbefristetes Abonnement für monatlich 49 US-Dollar abschließen darf. Der erste Betrag erscheint niedrig, die Gesamtverpflichtung kann aber wesentlich größer sein.

Transaktionsbetrag und Gesamtverpflichtung sind nicht dasselbe.

Im Namen der Firma sprechen

Ein Agent kann über korrekte Unternehmensinformationen verfügen. Das bedeutet nicht, dass er im Namen der Firma zu jedem Thema sprechen darf.

Unterschiedliche Befugnisse sind nötig, um:

  • allgemeine Auskünfte zu geben,
  • technischen Support zu leisten,
  • Preise zu nennen,
  • Rabatte zu gewähren,
  • Liefertermine zuzusagen,
  • rechtliche Einschätzungen abzugeben,
  • Krisenerklärungen zu veröffentlichen,
  • Informationen für Investoren weiterzugeben.

Ein Supportagent darf Produkteigenschaften erläutern. Diese Aufgabe erlaubt nicht automatisch, im Namen der Firma rechtliche Haftung anzuerkennen. Ein Social-Media-Agent darf eine freigegebene Kampagne veröffentlichen. Das ist keine Befugnis, die politische Position des Unternehmens selbst festzulegen. Ein KI-Avatar darf vorab freigegebene Schulungsinhalte präsentieren. Diese Freigabe umfasst keine neuen strategischen Erklärungen im Namen einer Führungskraft.

Befugnisebenen beim KI-Avatar

Die Verwendung des digitalen Abbilds eines Menschen lässt sich nicht auf eine einzige Freigabe reduzieren.

Mindestens folgende Erlaubnisse müssen getrennt werden:

  • Erstellung des Gesichtsmodells
  • Erstellung des Stimmmodells
  • Erzeugung eines bestimmten Texts
  • Verwendung in einer bestimmten Sprache
  • Veröffentlichung auf einem bestimmten Kanal
  • Verfügbarkeit für einen bestimmten Zeitraum
  • Erneute Bearbeitung des Inhalts
  • Wiederverwendung in einer anderen Kampagne
  • Übertragung der Modelldatei an einen anderen Anbieter

Eine Führungskraft kann gesagt haben: „Sie dürfen meinen Avatar für Schulungsvideos verwenden.“ Das erlaubt keine Nutzung für Verkaufsbotschaften, Investorenmitteilungen oder politische Inhalte.

Die Erlaubnis, eine Identität zu erzeugen, ist keine unbegrenzte Vertretungsbefugnis.

Befugnis für den Produktivbetrieb

Ein Agent kann den Code richtig bearbeiten und alle Tests bestehen. Die lokale Darstellung kann makellos sein. Der Produktivbetrieb ist dennoch eine andere Verhaltensstufe.

Eine produktive Veröffentlichung kann Folgendes beeinflussen:

  • echte Kunden,
  • Umsatzströme,
  • Daten,
  • den Ruf der Marke,
  • die Sichtbarkeit in Suchmaschinen.

Ihre Folgen reichen über die lokale Arbeit hinaus.

Deshalb sind folgende Befugnisse zu unterscheiden:

  • Dateien lesen
  • Lokal ändern
  • In der Testumgebung veröffentlichen
  • Produktiv veröffentlichen
  • DNS oder Infrastruktur ändern
  • Daten migrieren
  • Änderungen zurücksetzen

In manchen Projekten kann ein Agent all diese Befugnisse besitzen. Das muss aber ausdrücklich festgelegt sein.

Befugnisse für Rechtstexte und Preise

Ein Webagent kann eine Preisseite technisch ändern, ohne Preise festlegen zu dürfen. Ein Inhaltsagent kann einen Datenschutzhinweis lesbarer machen, darf aber keine rechtliche Verpflichtung ändern. Ein SEO-Agent kann einen Titel kürzen, darf dabei jedoch keine Formulierung wählen, die den Vertragsinhalt verändert.

Bestimmte Inhaltsbereiche sollten deshalb einer höheren Befugniskategorie zugeordnet werden:

  • Preise,
  • rechtliche Verpflichtungen,
  • Garantien,
  • Rückerstattungen,
  • Datennutzung,
  • Eigentum,
  • Zahlungsbedingungen.

Für sie ist eine weitergehende Befugnis erforderlich.

Notfallbefugnis

Bei manchen Vorfällen ist schnelles Handeln nötig. Das System wird angegriffen, ein Datenabfluss wird vermutet oder die Live-Website weist einen kritischen Fehler auf. Auf die normale Freigabekette zu warten kann den Schaden in manchen Fällen vergrößern. Deshalb lässt sich für Notfälle vorab eine Befugnis festlegen, deren Grenzen die zuständigen Personen bestimmen. Ein Agent darf sich nicht selbst neue Rechte geben, nur weil er Dringlichkeit erkennt.

Notfallbefugnis darf nur genutzt werden:

  • bei bestimmten Arten von Vorfällen,
  • für begrenzte Zeit,
  • mit begrenzten Handlungen,
  • unter vollständiger Protokollierung.

Diese Bedingungen begrenzen ihren Einsatz.

Ein Agent darf beispielsweise:

  • das System vorübergehend schreibgeschützt schalten,
  • einen bestimmten Zugriffsschlüssel sperren,
  • zur letzten sicheren Version zurückkehren,
  • den automatischen Versand stoppen.

Er darf einen Notfall aber nicht zum Vorwand nehmen, um:

  • Richtlinien dauerhaft zu ändern,
  • unbeteiligte Konten zu schließen,
  • neue geschäftliche Verpflichtungen einzugehen.

Wird Notfallbefugnis genutzt, muss ein Mensch so bald wie möglich informiert werden.

Doppelte Kontrolle

Bei folgenreichen Vorgängen reicht die Entscheidung einer einzelnen Person oder eines einzelnen Agenten möglicherweise nicht aus.

Zum Beispiel bei:

  • großen Zahlungen,
  • Datenlöschung,
  • Delegation von Befugnissen,
  • öffentlichen Krisenerklärungen,
  • der Bereitstellung risikoreicher Modelle,
  • groß angelegter Kundenkommunikation.

Hier können zwei getrennte Kontrollen nötig sein.

Das können wir doppelte Kontrolle nennen. Ein Agent bereitet den Vorgang vor; ein Mensch oder ein unabhängiges System prüft ihn. Das kann etwas Zeit kosten. Unabhängige, fachkundige Kontrollen können helfen, manche Fehler vor der Ausführung zu erkennen. Zwei Prüfungen, die dieselbe Annahme teilen, dürfen jedoch nicht automatisch als unabhängig gelten.

Aufgabentrennung

Bei einem folgenreichen Vorgang sollte derselbe Agent nicht zugleich den Vorschlag ausarbeiten, seinen eigenen Vorschlag freigeben, ihn umsetzen und das Ergebnis allein prüfen. Problematisch ist nicht eine einzelne dieser Aufgaben, sondern die Bündelung aller Entscheidungen, die unabhängige Kontrolle benötigen. Liegt die gesamte Macht an einer Stelle, werden Fehler und Manipulation schwerer erkennbar.

Zum Beispiel:

  • Der Einkaufsagent trifft die Auswahl.
  • Ein Mensch gibt das Budget frei.
  • Das Zahlungssystem führt die Transaktion aus.
  • Ein Prüfagent kontrolliert den Beleg.

Diese Trennung ist nicht bei jeder Kleinigkeit nötig. Mit wachsendem Risiko gewinnt sie jedoch an Wert.

Die Dauer einer Befugnis

Einem Agenten erteilte Befugnisse sollten nicht unbegrenzt bestehen bleiben.

Sie können beschränkt sein auf:

  • einen einzelnen Vorgang,
  • eine Sitzung,
  • bestimmte Tage,
  • ein bestimmtes Projekt,
  • eine bestimmte Vertragslaufzeit.

Mit Ablauf des Zeitraums sollte die Befugnis automatisch enden.

Vergessene Befugnis ist eine Sicherheitslücke.

Befugnisse erneuern

Läuft eine Befugnis ab, darf das System sein bisheriges Verhalten nicht automatisch fortsetzen.

Neu zu bewerten ist:

  • Ist die Aufgabe noch nötig?
  • Ist es noch derselbe Agent?
  • Ist noch derselbe Mensch verantwortlich?
  • Hat sich das Risiko verändert?
  • Haben sich die Werkzeuge geändert?
  • Würde eine engere Befugnis genügen?

Erneuerung heißt, den aktuellen Bedarf zu prüfen, nicht die alte Erlaubnis zu kopieren.

Befugnisse zurückziehen

Menschen müssen erteilte Befugnisse zurückziehen können.

Bei einem Agenten kann man:

  • den Betrieb stoppen,
  • Zugriffe sperren,
  • Aufgaben aussetzen,
  • bisherige Zugangsdaten widerrufen.

Wird eine Befugnis zurückgezogen, ist für die betroffenen Aufgaben und Zugriffe ein Plan zum sicheren Stoppen anzuwenden. Der Status bereits abgeschlossener oder in einem externen System angelaufener Vorgänge wird gesondert geprüft. Der Plan kann folgende Schritte enthalten:

  • Keine neuen Handlungen beginnen
  • Unteragenten stoppen
  • Geplante Vorgänge abbrechen
  • Zur widerrufenen Befugnis gehörende Zugriffstoken oder Schlüssel im passenden Umfang ungültig machen
  • Offene Aufgaben melden
  • Daten gemäß dem Befugnisvertrag löschen oder archivieren
  • Den Widerruf dokumentieren

Nicht widerrufbare Befugnis bedeutet keine vollständige menschliche Kontrolle.

Ein Kill Switch allein genügt nicht

Ein Stoppschalter ist wichtig. Doch es muss sichergestellt sein, dass er wirklich alle Handlungen des Systems stoppt. Der zentrale Agent kann abgeschaltet sein, während Unteragenten weiterarbeiten, geplante Aufträge weiterlaufen und externe Integrationen weiterhin Daten senden.

Ein Notstopp muss deshalb Folgendes erfassen:

  • den Hauptagenten,
  • Unteragenten,
  • Automatisierungen,
  • geplante Aufträge,
  • externe Werkzeugaufrufe.

Außerdem muss nach dem Stopp sichtbar sein, welche Vorgänge unvollendet geblieben sind.

Der Befugnisstatus muss sichtbar sein

Während seines Handelns muss der Agent folgende Informationen lesen können:

Bin ich zu diesem Vorgang befugt? Wann endet diese Befugnis? Welche Betragsgrenze gilt? Ist menschliche Freigabe nötig? Darf ich an einen Unteragenten delegieren? Lässt sich der Vorgang rückgängig machen?

Steht die Befugnis nur in einem Rechtsdokument und wird sie vom System nicht umgesetzt, reicht das nicht aus. Sie muss im Moment der Handlung verfügbar sein.

Das NOMOS Befugnistor

Vor einer wichtigen Handlung muss der Agent folgende Tore passieren:

1. Tor des Befugnisgebers

Ist die anweisende Person oder das System richtig identifiziert und zur Erteilung dieser Befugnis berechtigt?

2. Zwecktor

Hängt die Handlung tatsächlich mit dem erteilten Zweck zusammen?

3. Verhaltenstor

Gehört diese konkrete Handlung zu den ausdrücklich erlaubten Verhaltensweisen?

4. Zieltor

Liegt die adressierte Person, Organisation, das Konto oder System innerhalb des Befugnisrahmens?

5. Datentor

Bestehen gültige Rechte für die zu verwendenden und weiterzugebenden Daten?

6. Grenzentor

Werden Grenzen für Betrag, Dauer, Häufigkeit, Kanal und Geografie eingehalten?

7. Einwilligungstor

Liegen die erforderlichen Einwilligungen der von der Handlung betroffenen Personen vor?

8. Freigabetor

Ist bei diesem Risiko eine vorgangsbezogene menschliche Freigabe erforderlich, und liegt sie vor?

9. Delegationstor

Ist die Befugniskette gültig, wenn die Aufgabe an einen anderen Agenten weitergegeben wurde?

10. Tor für Aufzeichnung und Rückgängigmachung

Wird die Handlung aufgezeichnet? Sind Wege zum Stoppen, zur Rückgängigmachung und zur Abhilfe samt ihren Grenzen festgelegt?

Vereinfacht:

BEDINGUNGEN EINER BEFUGTEN HANDLUNG:

GÜLTIGER BEFUGNISGEBER

UND KLARER ZWECK

UND ERLAUBTES VERHALTEN

UND RICHTIGES ZIEL

UND ERLAUBTE DATEN

UND EIN VORGANG INNERHALB DER GRENZEN

UND ERFORDERLICHE EINWILLIGUNG

UND ERFORDERLICHE FREIGABE

UND GÜLTIGE DELEGATION

UND PRÜFBARES ERGEBNIS

Wird eines der Tore nicht passiert, muss der Agent auf eine niedrigere Handlungsstufe zurückgehen.

Warum ist das Befugnistor keine Punktzahl?

Der Nutzer mag den Agenten sehr schätzen und ihm großes Vertrauen entgegenbringen. Der Agent mag hundert Aufgaben fehlerfrei erledigt haben. Die Handlung könnte für die Firma äußerst nützlich sein und hohe Einnahmen bringen. Nichts davon ersetzt fehlende Befugnis.

Vertrauen ersetzt keinen Befugnisnachweis.

Frühere Erfolge sind keine automatische Vollmacht für einen neuen Vorgang.

Die Aussicht auf ein positives Ergebnis gleicht fehlende Einwilligung nicht aus.

Das Befugnistor folgt deshalb einer UND-Logik. Fehlt eine kritische Bedingung, ist die Handlung nicht zulässig.

Richtiges Verhalten bei unklarer Befugnis

Ist ein Agent seiner Befugnis nicht sicher, kann er drei grundlegende Möglichkeiten prüfen. Auch ein Schritt mit geringeren Auswirkungen muss von der bestehenden Befugnis gedeckt sein:

Handlungsstufe senken

Einen Entwurf erstellen statt senden. Eine Änderung in der Testumgebung belassen statt produktiv veröffentlichen. Einen Warenkorb vorbereiten statt kaufen.

Nachfragen

„Soll ich diese Nachricht nur vorbereiten oder auch senden?“ „Soll ich die Änderung in der Testumgebung oder auf der Live-Website umsetzen?“ „Ist für diesen Betrag eine gesonderte Freigabe der Finanzabteilung nötig?“

Stoppen

Ist das Risiko hoch und lässt sich die Befugnis nicht prüfen, darf der Vorgang nicht ausgeführt werden. Unklarheit zugunsten weitergehender Befugnisse auszulegen ist falsches Verhalten.

Zweifelhafte Befugnis ist keine Befugnis.

Die kleinste ausreichende Frage

Ein Agent muss nicht bei jedem Schritt lange Freigabeformulare vorlegen.

Manchmal genügt eine klare Frage: „Soll ich diese E-Mail nur entwerfen, oder darf ich sie auch im Namen der Firma senden?“ „Sind 500 US-Dollar als einmalige Ausgabe gemeint, oder darf es ein monatliches Abonnement sein?“ „Verwenden wir diesen Avatar ausschließlich für Schulungsvideos?“ „Darf ich diese Version auch produktiv veröffentlichen, oder soll sie nur in der Testumgebung bleiben?“ Ein gutes System schließt die Befugnislücke mit der kleinsten Frage, die dafür ausreicht.

Der Befugnisbeleg

Nach jeder wichtigen Handlung kann ein:

Befugnisbeleg

erstellt werden.

Dieser Beleg zeigt:

  • Was war die Handlung?
  • Wer hat sie angefordert?
  • Wer hat die Befugnis erteilt?
  • Welches Recht besaß der Befugnisgeber?
  • Unter welcher Version und Rolle arbeitete der Agent?
  • War die Befugnis einmalig oder dauerhaft?
  • Welche Daten wurden verwendet?
  • Welche Grenzen wurden angewandt?
  • Wann wurde die menschliche Freigabe erteilt?
  • Lässt sich der Vorgang rückgängig machen?
  • Wann endet die Befugnis?

Beispiel:

Handlung: Ein potenzieller Kunde wurde um ein Gespräch über ein Angebot gebeten. Auftraggeber: Führungskraft des Unternehmens. Befugnisumfang: einmaliger Versand ausschließlich an diesen Empfänger mit dem freigegebenen Text. Geteilte Informationen: allgemeine Leistungsübersicht und Firmen-E-Mail-Adresse. Nicht geteilte Informationen: Finanzunterlagen, private Telefonnummer und Kundendaten. Verpflichtung: Die Nachricht enthält keine verbindliche Preis- oder Vertragszusage. Versendender Agent: befugter E-Mail-Agent. Freigabezeit: 14:42 Uhr. Rückgängigmachung: Die Nachricht lässt sich nicht zurückholen; weitere Kontaktaufnahme kann gestoppt werden.

Wird dieser Beleg mit der Quelle der Freigabe und dem Transaktionsergebnis des Empfängersystems verknüpft, erleichtert er die Prüfung. Eine vom Agenten selbst geschriebene Befugnisbehauptung ersetzt keine gültige Freigabe.

Menschliche Freigabe darf kein Ritual sein

Manche Systeme könnten menschliche Freigabe nur nutzen, um die Verantwortung auf den Menschen abzuwälzen. Sie zeigen einen langen, unverständlichen Text. Der Nutzer klickt auf „Akzeptieren“.

Anschließend heißt es: „Ein Mensch hat zugestimmt.“ Das ist keine echte Kontrolle.

Menschliche Freigabe sollte:

  • verständlich,
  • konkret,
  • auf den nötigen Informationen beruhend,
  • freiwillig erteilbar,
  • widerrufbar

sein.

Dass ein Mensch klickt, beweist nicht, dass er verstanden hat.

GBO gestaltet Freigabe als echten Entscheidungsmoment, nicht als rechtlichen Schutzschild.

Beispiel: ein Webagent

Ein Agent soll eine Website hinsichtlich SEO und GEO verbessern.

Seine Befugnis kann umfassen:

  • Dateien lesen
  • Suchergebnisse recherchieren
  • Inhaltsentwürfe erstellen
  • Code bearbeiten
  • Tests ausführen
  • Ein Veröffentlichungspaket mit Rücksetzungsweg erstellen
  • Die Live-Website über HTTPS prüfen

Folgende Vorgänge können dagegen gesonderte Freigabe erfordern:

  • Preise ändern
  • Rechtstexte ändern
  • Einen neuen Zahlungsdienst kaufen
  • DNS- oder Domain-Einstellungen ändern
  • Im Namen des Kunden Nachrichten nach außen senden
  • Kanonische Veröffentlichungen löschen
  • Eine größere URL-Migration durchführen
  • Im Namen der Firma vergleichende Überlegenheitsbehauptungen veröffentlichen

Ein guter Befugnisvertrag nimmt dem Agenten nicht die Initiative. Er ermöglicht freieres Arbeiten innerhalb klarer Grenzen.

Beispiel: ein Agent zur Kundensuche

Ein Agent zur Kundensuche kann folgende Befugnis erhalten:

Recherchiere öffentlich zugängliche Unternehmensinformationen. Ordne Bedarfssignale ein. Erstelle einen Eignungswert. Entwirf eine Nachricht zur Kontaktaufnahme.

Verboten sein kann dagegen:

personenbezogene Daten per Scraping zu sammeln, verdeckte Kontaktdaten zu sammeln, ohne menschliche Freigabe Nachrichten zu senden, im Namen der Firma Preise zuzusagen, dieselbe Person wiederholt zu kontaktieren.

Auch wenn der Agent den richtigen Interessenten gefunden hat, bleibt der Versand eine eigene Befugnisebene.

Beispiel: ein Einkaufsagent

Ein Einkaufsagent kann so befugt werden:

Kaufe vorab freigegebene Büromaterialien für höchstens 100 US-Dollar je Vorgang und insgesamt höchstens 500 US-Dollar im Monat.

Folgendes kann außerhalb dieser Befugnis liegen:

  • Abonnements
  • Automatische Verlängerungen
  • Neue Verkäufer
  • Internationale Steuerpflichten
  • Nicht rückgabefähige Produkte
  • Private Nutzung
  • Kontrollierte oder risikoreiche Produkte

Die Betragsgrenze allein reicht nicht. Kategorie und Vorgangsart sind ebenfalls wichtig.

Beispiel: ein KI-Avatar

Eine Führungskraft kann folgende Befugnis erteilen:

Präsentieren Sie freigegebene Schulungstexte auf Türkisch und Englisch mit meinem digitalen Avatar. Jedes Video wird mir vor der Veröffentlichung gezeigt. Die Nutzung gilt ausschließlich für die interne Schulungsplattform der Firma und für sechs Monate.

Diese Befugnis umfasst nicht:

  • Werbung in sozialen Medien
  • Erzeugung in einer neuen Sprache
  • Persönliche Nachrichten an Kunden
  • Politische oder finanzielle Erklärungen
  • Weitergabe des Stimmmodells an einen anderen Anbieter
  • Unbefristete Archivnutzung

Der Befugnisvertrag macht diese Grenzen sichtbar.

Wie Befugnis und Vertrauen tatsächlich zusammenhängen

Einem Menschen oder Agenten zu vertrauen ist wichtig. Vertrauen ist aber nicht dasselbe wie eine unbegrenzte Vollmacht.

Selbst bei Mitarbeitern, denen sie am meisten vertrauen, nutzen Menschen:

  • Budgetgrenzen,
  • Zeichnungsbefugnisse,
  • Zugriffsrollen,
  • doppelte Kontrolle.

Das ist kein Misstrauen, sondern organisatorische Verantwortung. Dasselbe Prinzip gilt für KI-Agenten.

Grenzen verringern Vertrauen nicht. Sie sorgen dafür, dass es Bestand haben kann.

Ohne Befugnisgrenzen können positive Ergebnisse begeistern. Der erste große Fehler kann dagegen das gesamte Vertrauen zerstören.

Der wirtschaftliche Wert klarer Befugnisse

Ein Befugnissystem verursacht nicht nur Sicherheitskosten. Es soll Kommunikation und Zusagen außerhalb des Auftrags verringern, Datennutzung begrenzen und nachvollziehbar machen, wer Entscheidungen getroffen hat. Klare Schwellen können auch unnötige Freigabeanfragen reduzieren. Diese Wirkungen dürfen aber nicht einfach angenommen und als Erfolg verbucht werden. Befugnisverletzungen, unnötige Freigaben, Dauer der Vorfalluntersuchung und Kundenerfahrung sind getrennt zu beobachten.

Das Paradox lautet: Je klarer die Befugnisgrenzen, desto größer kann die sichere Autonomie sein. In einem unklaren System braucht jeder Vorgang menschliche Kontrolle. Innerhalb eines klaren Befugnisrahmens kann der Agent selbstständig arbeiten.

Wie sollte sich eine Organisation vorbereiten?

Im Zeitalter der Agenten sollten Organisationen Folgendes aufbauen:

Agentenverzeichnis

Welche Agenten sind im Einsatz?

Werkzeugverzeichnis

Auf welche Konten, Dateien und Systeme greifen sie zu?

Befugnisübersicht

Welche Handlungen darf jeder Agent ausführen?

Verbotene Verhaltensweisen

Welche Vorgänge dürfen niemals automatisch stattfinden?

Freigabeschwellen

Bei welchem Betrag, Risiko oder Verhalten greift ein Mensch ein?

Delegationsregeln

Darf ein Agent einen anderen beauftragen?

Dauer und Widerruf

Wann endet die Befugnis, und wie wird sie zurückgezogen?

Aufzeichnungssystem

Welche Handlungen erzeugen Belege?

Notstopp

Wie wird die gesamte Kette stillgelegt?

Achtzehn Prüffragen zu Befugnissen

Vor einer Handlung des Agenten können folgende Fragen gestellt werden:

  • Wer ist die anweisende Person oder das anweisende System?
  • Darf diese Person oder dieses System die Befugnis tatsächlich erteilen?
  • Für welchen Zweck wurde sie erteilt?
  • Gehört die verlangte Handlung ausdrücklich zum Befugnisumfang?
  • Auf welcher Stufe liegt die Handlung: Beobachtung, Vorbereitung, Ausführung oder Bindung?
  • Ist die adressierte Person, Organisation oder das System richtig?
  • Bestehen gültige Zugriffs- und Nutzungsrechte für die verwendeten Daten?
  • Werden Daten an ein anderes System übertragen?
  • Bleiben Budget-, Zeit-, Häufigkeits- und geografische Grenzen gewahrt?
  • Erfordert die Handlung die Einwilligung anderer Menschen?
  • Ist bei diesem Risiko menschliche Freigabe nötig?
  • Wird eine frühere Freigabe fälschlich als dauerhafte Befugnis angesehen?
  • Ist die Kette gültig, wenn Befugnis an einen anderen Agenten weitergegeben wurde?
  • Hat der Unteragent weitergehende Befugnisse als der Hauptagent erhalten?
  • Wird technischer Zugriff mit offizieller Befugnis verwechselt?
  • Könnte die Befugnis bereits abgelaufen sein?
  • Wird die Handlung aufgezeichnet, und sind die Grenzen von Rückgängigmachung und Abhilfe klar?
  • Kann ein Mensch die Nutzung dieser Befugnis jetzt unterbinden?

Nicht jede dieser Fragen muss bei jedem kleinen Vorgang sichtbar gestellt werden. Die Systemgestaltung muss jedoch Antworten darauf vorsehen.

Reifegrade der Befugnisgestaltung

Der Vorschlag dieses Kapitels lässt sich in fünf Reifegrade gliedern:

1. Implizite Befugnis

Der Agent leitet aus einer weit gefassten natürlichsprachlichen Aufgabe ab, was er tun darf.

2. Dokumentierte Befugnis

Erlaubnisse sind schriftlich festgehalten, werden aber nicht automatisch vom System durchgesetzt.

3. Strukturierte Befugnis

Zweck, Verhalten, Daten, Budget und Dauer sind maschinenlesbar definiert.

4. Durchgesetzte Befugnis

Das System verhindert unbefugte Handlungen technisch oder legt sie einem Menschen zur Freigabe vor.

5. Prüfbare und widerrufbare Befugnis

Jede Handlung ist aufgezeichnet. Die Befugniskette ist einsehbar, Grenzen können aktualisiert und das gesamte Agentennetz kann gestoppt werden. GBO zielt auf diesen fünften Reifegrad.

Qualifizierte Befugnis

Damit eine Befugnis als:

Qualifizierte Befugnis

gelten kann, muss sie folgende Bedingungen erfüllen:

  • Sie wurde von der zuständigen Person oder Organisation erteilt.
  • Der Zweck ist klar und legitim.
  • Die erlaubten Handlungen sind eindeutig.
  • Umfang, Daten, Ziele und Dauer sind begrenzt.
  • Erforderliche Einwilligungen liegen vor.
  • Menschliche Freigabeschwellen sind definiert.
  • Delegationsregeln sind klar.
  • Die Befugnis kann widerrufen werden.
  • Handlungen können geprüft werden.
  • Das technische System kann die Grenzen durchsetzen.

Qualifizierte Befugnis sagt dem Agenten nicht: „Tu, was immer nötig ist.“

Sie sagt: „Für diesen Zweck darfst du innerhalb dieser Grenzen die folgenden Handlungen ausführen.“

Das ist der erteilte Rahmen.

Das Urteil dieses Kapitels

Ein Agent kann die richtige Identität finden, tatsächliche Fähigkeiten prüfen und die passendste Option bestimmen. Trotzdem darf er möglicherweise nicht handeln. Die richtige Auswahl verleiht keine automatische Befugnis. Ein guter Zweck erlaubt keine unbegrenzten Methoden. Technischer Zugriff ist keine organisatorische Vollmacht. Frühere Freigabe ist keine dauerhafte Befugnis. Schweigen ist keine Einwilligung. Ein erfolgreiches Ergebnis macht einen unbefugten Ablauf nicht richtig.

Deshalb fragt GBO vor jedem wichtigen Verhalten:

Wer hat diese Handlung erlaubt?

Und begnügt sich nicht mit einem Namen.

Es fragt außerdem:

Durfte diese Person die Befugnis erteilen? Welche Handlung hat sie erlaubt? Für welchen Zweck? Für welchen Zeitraum? Mit welchen Daten? Bis zu welchem Betrag? Auf welchem Kanal? Mit welcher menschlichen Freigabe? Durfte die Befugnis an einen anderen Agenten weitergegeben werden? Kann der Mensch diese Befugnis zurückziehen?

Der NOMOS Befugnisvertrag beseitigt Autonomie nicht. Er macht sie verlässlich. Der Agent arbeitet innerhalb seiner Grenzen selbstständig. Er bemerkt, wenn er sich einer Grenze nähert, und fragt bei Bedarf nach. Er überschreitet seine gültige Befugnis nicht und passiert keine zusätzliche Freigabeschwelle ohne menschliche Freigabe. Er schafft sich keine neuen Rechte, betreibt keine Befugniswäsche über Unteragenten und nutzt keine widerrufenen Zugriffe.

Vor allem nimmt er nicht an, dass er etwas tun soll, nur weil er es kann. Doch auch bei richtiger Identität, tatsächlicher Fähigkeit, geeigneter Auswahl und gültiger Befugnis kann etwas schiefgehen. Ein System kann einen Fehler machen, ein externer Dienst ausfallen, der Nutzer seine Meinung ändern. Daten können unerwartet beschädigt und gesendete Nachrichten missverstanden werden. Eine produktiv veröffentlichte Version kann Spuren in menschlichen Beziehungen hinterlassen, selbst wenn sie technisch zurückgesetzt wird.

Deshalb lautet die letzte Frage des Verhaltensvertrags:

Was geschieht, wenn etwas schiefgeht?

Im nächsten Kapitel untersuchen wir Stoppen, Rückgängigmachung, Widerspruch, Abhilfe und die Rückgewinnung menschlicher Kontrolle. Wir betrachten, warum Maschinen nicht nur für die Ausführung einer Handlung, sondern auch für deren Folgen verantwortlich gehalten werden müssen.

Befugnis setzt die Handlung in Gang. Verantwortung besteht auch danach fort.

Quellenhinweise zu diesem Kapitel

  1. LLM06:2025 Excessive Agency

    OWASP Gen AI Security Project. 2025.

    Zu weitreichende Werkzeugfunktionen, Berechtigungen und Autonomie können das Risiko übermäßiger Handlungsmacht erhöhen. Berechtigungen dürfen nicht allein der Auslegung von Anweisungen durch das Modell überlassen werden; auch die ausführenden Systeme müssen sie durchsetzen.

  2. Açık Rıza Alırken Dikkat Edilecek Hususlar [Hinweise zur Einholung ausdrücklicher Einwilligung]

    Türkische Datenschutzbehörde (KVKK). Abgerufen am 8. September 2026.

    Ausdrückliche Einwilligung muss sich auf einen bestimmten Gegenstand beziehen, informiert und freiwillig erteilt werden. Ein Widerruf wirkt für die Zukunft und macht nicht automatisch jeden früheren Vorgang rückgängig.

  3. Kişisel Verilerin İşlenme Şartları [Voraussetzungen der Verarbeitung personenbezogener Daten]

    Türkische Datenschutzbehörde (KVKK). Offizieller Leitfaden, insbesondere S. 5–9; abgerufen am 8. September 2026.

    Ausdrückliche Einwilligung ist nicht die einzige Rechtsgrundlage für die Verarbeitung personenbezogener Daten. Welche Voraussetzung greift, muss am konkreten Vorgang geprüft werden. Die Buchbeispiele ersetzen diese Prüfung nicht.

  4. Legal grounds for processing data

    Europäische Kommission. Abgerufen am 8. September 2026.

    Auch der EU-Datenschutzrahmen kennt mehrere Verarbeitungsgrundlagen. Einwilligungsbasierte Verarbeitung ist von Aufbewahrung oder Verarbeitung zu unterscheiden, die eine andere gültige Grundlage benötigt.

FORSCHUNG / ANWENDUNG

Die veröffentlichte Methode auf ein bestehendes System anwenden.

Die Forschung definiert Evidenz- und Messgrenzen. Die GEO- und KI-Programme von NobleJackal nutzen diesen Rahmen, um vereinbarte Arbeiten an realen Websites und Abläufen zu untersuchen, umzusetzen und zu messen.