Was passiert, wenn etwas schiefgeht?

Stellen wir uns einen Fehler bei einer Veröffentlichung vor. Auf der Website eines Unternehmens soll eine wichtige Preisänderung vorgenommen werden.

Der KI-Agent erhält den Auftrag: „Trage die neuen Dienstleistungspreise auf der Website ein, gleiche alle Sprachfassungen ab und veröffentliche sie nach den erforderlichen Tests.“ Der Agent findet die richtigen Dateien. Er aktualisiert die Preisangaben und bearbeitet die Leistungsseiten in sechs Sprachen. Er erzeugt die strukturierten Daten neu und startet den Build. Die Tests laufen erfolgreich durch. Die Veröffentlichung geht live. Auf den ersten Blick ist alles gelungen. Einige Stunden später bemerkt der Vertrieb ein Problem: Der Agent hat den Jahrespreis einer Zusatzleistung als Monatspreis der Hauptleistung verstanden. Die Zahl stimmt. Die Dienstleistung gibt es. Technisch ist die Veröffentlichung einwandfrei.

Canonical-Verweise, hreflang, Sitemap, strukturierte Daten und sämtliche Sprachfassungen passen genau zueinander. Doch sie verbreiten alle denselben Fehler mit vollkommener Konsistenz. Und der Fehler betrifft nicht nur eine Seite.

Der Preis steht nun:

• auf der sichtbaren Leistungsseite,
• im maschinenlesbaren Katalog,
• im FAQ-Schema,
• in den Suchmetadaten,
• in den sechs Sprachfassungen,
• in Benachrichtigungen an Dritte.

Die Dateien sind technisch veröffentlicht. Der Gesamtauftrag ist trotzdem gescheitert: Eine falsche geschäftliche Angabe wurde auf technisch konsistente Oberflächen übertragen. Was passiert jetzt?

Wäre das Problem vollständig gelöst, wenn man die alten Dateien wiederherstellte?

Was, wenn Suchmaschinen den falschen Preis bereits erfasst haben?

Wenn ein KI-System die Angabe gelesen hat?

Wenn ein Kunde einen Screenshot gemacht hat?

Wenn im Verkaufsgespräch Erwartungen auf Grundlage dieses Preises entstanden sind?

Wird die in sechs Sprachen verbreitete Falschangabe nur technisch zurückgenommen, oder erhalten auch die betroffenen Menschen eine Erklärung?

Und vor allem: Warum ist dieser Fehler durch die Veröffentlichungskontrollen gelangt?

Der Verhaltensvertrag von GBO kann nicht nur beschreiben, wie die richtige Handlung eingeleitet wird. Er muss auch festlegen, was geschieht, wenn eine falsche Handlung beginnt oder eine scheinbar richtige Handlung unerwarteten Schaden verursacht.

Die letzte Frage des zweiten Teils lautet deshalb:

Was passiert, wenn etwas schiefgeht?

Die Möglichkeit eines Fehlers mitdenken

Auch bei einem gut konzipierten und getesteten Agentensystem darf man nicht von einem fehlerfreien Betrieb ausgehen. Informationen können veraltet sein. Eine Identität kann falsch zugeordnet werden. Der Zweck des Nutzers kann nur teilweise verstanden worden sein. Befugnisse können zu weit ausgelegt werden. Ein externer Dienst kann unerwartet antworten. Die Netzwerkverbindung kann abbrechen. Eine Dateiübertragung kann auf halbem Weg stoppen. Eine API kann denselben Vorgang zweimal ausführen. Ein Mensch kann die falsche Freigabe erteilen. Ein Agent kann einen Zustand verändern, den die Tests nicht abdecken. Ein Modell kann aus richtigen Quellen einen falschen Zusammenhang ableiten. Selbst ein technisch erfolgreicher Vorgang kann für einen Menschen schädliche Folgen haben.

Zuverlässigkeit beruht nicht allein auf der Erwartung fehlerfreien Betriebs. Entscheidend ist sowohl, dass eine festgelegte Funktion korrekt und beständig erfüllt wird, als auch, was bei einer Abweichung geschieht. Fehler früh zu erkennen, ihre Folgen einzudämmen, einen sicheren Zustand wiederherzustellen, Menschen zu informieren und Abhilfe zu prüfen, gehört zum Systementwurf. Ein System, das nur an erfolgreichen Tagen gut funktioniert, ist nicht ausgereift. Reife zeigt sich, wenn die Dinge anders laufen als geplant.

Fehler und Schaden sind nicht dasselbe

Nicht jeder Fehler verursacht Schaden. Ein Agent kann ein Wort falsch schreiben, ohne dass dies nennenswerte Folgen hat. Ein Bericht kann uneinheitliche Datumsformate enthalten: ein korrigierbarer Qualitätsmangel. Manche scheinbar kleinen Fehler können dagegen großen Schaden anrichten. Ein Komma kann die Bedeutung eines Preises verändern. Eine falsche E-Mail-Adresse kann vertrauliche Informationen an eine andere Person leiten. Eine falsch verstandene Uhrzeit im Kalender kann dazu führen, dass ein wichtiges Treffen verpasst wird. Eine Konfigurationszeile kann eine ganze Website für Suchmaschinen sperren. Wird ein Stimmmodell dem falschen Konto zugeordnet, kann die Identität eines anderen Menschen verwendet werden.

Wir müssen deshalb zwei Begriffe unterscheiden:

Fehler

Die Abweichung von einer erwarteten Information, Entscheidung, Ausführung oder einem erwarteten Ergebnis des Systems.

Schaden

Die nachteilige Wirkung dieser Abweichung auf Menschen, Organisationen, Geld, Rechte, Vertrauen, Ansehen, Daten oder Systeme. Ein Fehler kann auftreten und entdeckt werden, bevor Schaden entsteht. Das ist der günstigste Fall. Nach Eintritt eines Schadens lässt sich der fehlerhafte Vorgang möglicherweise noch rückgängig machen; die Lage ist dann schwieriger. Die technische Rücknahme beseitigt zudem nicht unbedingt alle bereits entstandenen Schäden. GBO will nicht nur die Fehlerquote senken.

Es soll verhindern, dass aus Fehlern Schäden werden, und Menschen einen wirksamen Weg zur Wiederherstellung eröffnen, wenn dennoch Schaden entsteht.

Scheitern hat viele Formen

„Der Vorgang ist fehlgeschlagen“ ist eine sehr weit gefasste Aussage. Agentenverhalten kann auf unterschiedliche Weise scheitern.

Richtiger Vorgang mit falschen Informationen

Der Agent setzt die erhaltenen Informationen korrekt um. Doch die Informationen sind falsch. Beispielsweise wird ein falscher Preis korrekt auf allen Seiten eingetragen.

Falscher Vorgang mit richtigen Informationen

Der Agent hat die richtigen Daten, ändert aber die falsche Datei, schreibt der falschen Person oder nutzt das falsche Konto.

Erfolgreicher Vorgang ohne Befugnis

Die Handlung ist technisch einwandfrei. Der Agent ist jedoch nicht dazu befugt.

Teilweise Ausführung

Fünf von sechs Sprachen werden aktualisiert. Eine Zahlung erfolgt, aber es entsteht kein Bestelldatensatz. Dateien werden hochgeladen, die Sitemap bleibt jedoch veraltet.

Doppelte Ausführung

Wegen einer Zeitüberschreitung hält das System einen Vorgang für gescheitert und versucht es erneut. Der Nutzer wird zweimal belastet oder dieselbe Nachricht zweimal verschickt.

Unbemerkter Fehlschlag

Das System meldet Erfolg, doch in der Außenwelt wurde der Vorgang nicht ausgeführt. Das Übertragungswerkzeug sagt „abgeschlossen“, obwohl einige Dateien noch auf dem alten Stand sind.

Verzögerter Fehlschlag

Zunächst wirkt der Vorgang korrekt. Das Problem tritt erst Stunden oder Tage später auf. Ein Abonnement verlängert sich automatisch. Falsche Informationen verbreiten sich in den Suchergebnissen.

Kettenreaktion

Ein einzelner Fehler wird in andere Systeme weitergetragen. Der falsche Preis verbreitet sich im Katalog, auf der Website, beim Vertriebsagenten, in Suchmaschinen und in Angebotsunterlagen.

Scheitern auf menschlicher Ebene

Das technische System arbeitet wie erwartet. Doch ein Mensch wird falsch informiert, erteilt unter Druck eine Freigabe oder versteht die Folgen einer Entscheidung nicht. Jede dieser Fehlerarten erfordert eine andere Form der Wiederherstellung. Eine einzige Schaltfläche „Rückgängig“ löst nicht alle Probleme.

Technischer Erfolg ist noch kein tatsächlicher Erfolg

Ein Vorgang kann folgende technische Ergebnisse liefern:

• HTTP 200
• Build erfolgreich
• Datei hochgeladen
• API-Aufruf angenommen
• Mailserver hat die Nachricht erhalten
• Zahlungsdienstleister hat die Anfrage verarbeitet
• IndexNow hat die Benachrichtigung angenommen

Das sind nützliche Nachweise. Für sich genommen belegen sie jedoch nicht das übergeordnete Ergebnis. HTTP 200 beweist nicht, dass dem Nutzer der richtige Inhalt angezeigt wird. Eine hochgeladene Datei beweist nicht, dass das Livesystem korrekt arbeitet. Die Annahme durch einen Mailserver beweist weder die Zustellung an die richtige Person noch das richtige Verständnis der Nachricht. Die Annahme einer Crawling-Benachrichtigung ist kein Nachweis für Indexierung oder Ranking. Eine verarbeitete Zahlung zeigt nicht, dass das richtige Produkt gekauft wurde.

GBO hält deshalb an dieser Unterscheidung fest: Die Annahme eines Vorgangs ist nicht dasselbe wie die Erfüllung seines Zwecks. Eine technische Antwort allein darf nicht genügen, um die Handlung eines Agenten als abgeschlossen zu betrachten. Auch der erwartete Zustand in der wirklichen Welt muss überprüft werden.

Auch Erfolgsmeldungen müssen geprüft werden

Agenten machen nicht nur Fehler. Mitunter bewerten sie ein Ergebnis als erfolgreicher, als es tatsächlich ist.

Ein System kann sagen: „Die Veröffentlichung ist abgeschlossen.“ Dabei ist lediglich die Dateiübertragung beendet. Die live über HTTPS ausgelieferte Fassung wurde noch nicht geprüft.

Ein Agent kann sagen: „An die Suchmaschinen übermittelt.“ Das ist noch keine Indexierung.

Ein Modell kann sagen: „Der Nutzer war zufrieden.“ Vielleicht hat er lediglich nicht geantwortet.

Ein Vertriebsagent kann sagen: „Ein qualifizierter Interessent wurde gefunden.“ Das tatsächliche Budget und die Entscheidungsbefugnis des Interessenten sind aber noch nicht bestätigt. Deshalb muss auch die Sprache des Erfolgs dem Vertrag folgen.

Was ist belegt? Was ist noch nicht belegt? Welches Ergebnis ist nur ein Zwischenschritt? Welche Unsicherheit besteht weiter?

Ein zuverlässiger Agent benennt die Grenzen seines Erfolgs klar.

Erst stoppen, dann erklären

Wird ein Fehler entdeckt, möchten Menschen oft zuerst seine Ursache verstehen. Das ist eine natürliche Reaktion. Läuft der schädliche Vorgang weiter, hat die Eindämmung Vorrang – innerhalb der zuvor festgelegten Befugnisse und des Plans für einen sicheren Stopp. Dabei kommt es auf die Art des Stopps an: Auch wahlloses Abschalten kann schaden. Verschickt ein Agent E-Mails an die falschen Personen, muss zunächst die Versandwarteschlange gestoppt werden. Hat sich ein falscher Preis verbreitet, sollte das automatische Angebotssystem vorübergehend pausieren. Werden Daten an ein unbefugtes Ziel übertragen, muss die Verbindung unterbrochen werden. Veröffentlicht ein Avatar falsche Inhalte, sind der betroffene Veröffentlichungsablauf und der Zugriff nach dem Vorfallplan einzuschränken.

Beschädigt eine Softwareversion Daten, muss der Datenverkehr auf eine sichere Version umgeleitet werden.

Der erste Grundsatz im Umgang mit Vorfällen lautet daher: Solange Schaden entsteht, zuerst das Verhalten stoppen. Die Ursache kann anschließend untersucht werden. Eine Erklärung ist wichtig, hat aber keinen Vorrang vor der Unterbindung laufender Schäden.

Sicher anhalten

Erkennt ein Agent ein Problem, darf er das System nicht in einem beliebigen Zustand zurücklassen.

Wenn möglich, sollte ein sicherer Zustand vorab definiert sein. Damit ist die Betriebsweise gemeint, in der das System bei Unsicherheit oder Fehlern den geringsten Schaden verursacht.

Für einen E-Mail-Agenten bedeutet ein sicherer Zustand:

Keine neuen Nachrichten versenden, eingehende Nachrichten aber ohne Verlust aufbewahren.

Für eine Website:

Zur letzten verifizierten Version zurückkehren oder vorübergehend nur die betroffene Funktion abschalten.

Für einen Einkaufsagenten:

Keine neuen Zahlungen auslösen, offene Warenkörbe und Entwürfe erhalten.

Für ein Avatarsystem:

Die Erzeugung und Veröffentlichung neuer Inhalte stoppen, Nachweisaufzeichnungen aber nicht löschen.

Für ein Kundenportal:

Sensible Vorgänge deaktivieren und den grundlegenden Lesezugriff nach Möglichkeit erhalten. Der sichere Zustand ist nicht für jedes System gleich. Er muss im Voraus festgelegt werden.

Was geschieht, wenn der Agent stoppt?

Bleibt diese Frage offen, kann der Not-Aus selbst zum neuen Problem werden.

Im Fehlerfall auf der sicheren Seite bleiben

Ein System kann auf zwei Arten scheitern: Es setzt einen Vorgang trotz Unsicherheit fort oder stoppt bei Unsicherheit eine risikoreiche Handlung. Bei manchen risikoarmen Systemen kann es richtig sein, den Dienst weiterlaufen zu lassen. Geht es jedoch um Befugnisse, Zahlungen, personenbezogene Daten, Identität oder irreversible Vorgänge, ist die sichere Seite vorzuziehen.

Zum Beispiel:

• Lässt sich der Preis nicht bestätigen, kein Angebot versenden.
• Ist die Befugnis unklar, die Nachricht nicht veröffentlichen.
• Lässt sich die Identität nicht klären, keine Zahlung auslösen.
• Liegt kein Einwilligungsnachweis vor, weder Gesicht noch Stimme verwenden.
• Stimmt der Hash nicht überein, die Liveversion nicht als erfolgreich bestätigen.
• Liegt kein Nachweis menschlicher Freigabe vor, keine Verpflichtung eingehen.

Das kann die Arbeit gelegentlich verlangsamen. Es hilft jedoch zu verhindern, dass ein erkanntes Risiko in einen unkontrollierten Vorgang übergeht.

Geschwindigkeit unter Unsicherheit ist keine Zuverlässigkeit.

Was bedeutet Rückgängigmachung?

Rückgängigmachung bedeutet, ein System in einen früheren sicheren Zustand zu versetzen. Doch „zur alten Version zurückkehren“ reicht nicht immer. Eine Website kann ihre alten Dateien verwenden. Eine Datenbank kann wiederhergestellt werden. Eine Zahlung lässt sich möglicherweise stornieren. Eine Nachricht kann aus der Versandwarteschlange entfernt werden. Das sind technische Möglichkeiten der Rücknahme. Manche Handlungen, die bereits nach außen gewirkt haben, lassen sich aber nicht vollständig rückgängig machen. Eine E-Mail kann gelesen, ein veröffentlichtes Video kopiert worden sein. Eine falsche Entscheidung kann das Vertrauen eines Menschen beeinträchtigt haben. Ein Kunde kann auf Grundlage eines falschen Preises geplant haben. Ein Bewerber kann ungerechtfertigt abgelehnt worden sein.

Eine gesundheitliche oder finanzielle Entscheidung kann bereits Folgen haben. Deshalb muss Rückgängigmachung auf drei Ebenen betrachtet werden.

Technische Rückgängigmachung

Lässt sich der frühere Systemzustand wiederherstellen?

Rückgängigmachung des Vorgangs

Lassen sich Bestellung, Zahlung, Reservierung, Vertrag oder Veröffentlichung stornieren beziehungsweise zurücknehmen?

Rückgängigmachung auf menschlicher Ebene

Lassen sich die Folgen für Privatsphäre, Vertrauen, Ansehen, Chancen oder Rechte tatsächlich beheben?

Die dritte Ebene ist oft die schwierigste.

Der Irrtum vom einfachen Rückgängigmachen

Ein Unternehmen kann sagen: „Keine Sorge, wir haben ein Backup.“ Ein Backup ist wichtig. Allein ist es aber noch kein Wiederherstellungsplan.

Eine Sicherungsdatei kann:

• veraltet sein,
• beschädigt sein,
• nicht zum richtigen System passen,
• personenbezogene Daten enthalten,
• Stunden für die Wiederherstellung benötigen,
• Änderungen in anderen Systemen nicht rückgängig machen.

Auch eine Schaltfläche „Löschen“ bedeutet nicht, dass die Handlung wirklich rückgängig gemacht wird. Ein Beitrag kann gelöscht werden, während Screenshots bleiben. Ein Datensatz kann gelöscht werden, nachdem er in andere Systeme kopiert wurde. Ein Avatarmodell kann entfernt werden, obwohl seine erzeugten Audiodateien bereits außerhalb des Systems liegen.

GBO fragt: Welchen Teil der entstandenen Wirkung macht die Rücknahme tatsächlich rückgängig?

Die Stufen der Irreversibilität

Um den Aufwand einer Rückgängigmachung zu betrachten, können wir folgende beispielhafte Stufen verwenden. Die Stufe ergibt sich nicht automatisch aus dem Namen des Vorgangs. Entscheidend sind die tatsächlichen Datenflüsse, Kopien und Außenwirkungen.

1. Vollständig rückgängig zu machen

Ein Beispiel wäre die Änderung eines Entwurfs, der nicht exportiert wurde, keine Nebenwirkungen hat und dessen sichere frühere Kopie erhalten ist.

2. Leicht rückgängig zu machen

Eine kleine veröffentlichte Systemänderung, die noch keine Außenwirkung entfaltet hat.

3. Teilweise rückgängig zu machen

Eine stornierbare Reservierung, Bestellung oder geplante Veröffentlichung; auch nach der Stornierung können Zeit- oder Geldverluste bleiben.

4. Im System korrigierbar, für Menschen möglicherweise dauerhaft spürbar Ein bereits gesehener falscher Preis, eine gelesene E-Mail oder eine kurzzeitige Datenoffenlegung. Selbst wenn der Quelldatensatz geändert wird, lassen sich die nach außen gelangten Informationen möglicherweise nicht zurückholen.

5. Nur schwer zu beheben

Öffentlich verbreiteter Identitätsmissbrauch, die Offenlegung vertraulicher Daten oder eine ungerechtfertigte Personalentscheidung.

6. Nicht rückgängig zu machen

Gelöschte einzigartige Daten, bereits eingetretener körperlicher Schaden, eine unwiederbringlich versäumte rechtliche Frist oder ein tödlicher Ausgang.

Je höher eine Handlung auf dieser Stufenleiter liegt, desto wichtiger werden:

• stärkere Identitätsprüfung,
• engere Befugnisse,
• klarere menschliche Freigabe,
• mehr unabhängige Kontrollen,
• ein detaillierterer Rücknahmeplan.

Mit zunehmender Irreversibilität steigen diese Anforderungen.

Je weniger rückgängig zu machen ist, desto mehr Verantwortung ist nötig – nicht mehr Autonomie.

Der Umkehrpunkt

Bei manchen Vorgängen ist eine Rücknahme bis zu einem bestimmten Zeitpunkt einfach.

Diesen Zeitpunkt können wir als Umkehrpunkt bezeichnen.

Bei einer E-Mail:

Bevor sie versendet wird.

Bei einem Kauf:

Vor der Zahlungsfreigabe.

Bei einer Softwareveröffentlichung:

Bevor eine irreversible Datenänderung beginnt oder der Datenverkehr auf die neue Version umgestellt wird; das muss nicht gleichzeitig geschehen. Gerade bei einer Datenmigration kann die Grenze schon beim ersten irreversiblen Schritt liegen, nicht erst beim Abschluss.

Bei einem Social-Media-Beitrag:

Bevor er öffentlich sichtbar wird.

Bei Inhalten mit einem KI-Avatar:

Bevor sie an externe Plattformen verteilt werden. Der Agent muss den Umkehrpunkt kennen. Wenn er sich ihm nähert, können eine menschliche Freigabe oder eine stärkere Prüfung erforderlich werden.

Das Rücknahmefenster

Manche Systeme bieten eine vorab geregelte Frist für Stornierung oder Rücknahme. Die folgenden Zeiten sind Beispiele für eine solche Gestaltung; sie dürfen nicht bei jedem Dienst vorausgesetzt werden. Eine Bestellung könnte innerhalb von zehn Minuten storniert werden. Eine E-Mail könnte mit einigen Sekunden Verzögerung versendet werden. Eine neue Version könnte zunächst nur einer kleinen Nutzergruppe zugänglich sein. Eine frühere Dateiversion könnte für eine bestimmte Zeit aufbewahrt werden.

Diese Frist können wir Rücknahmefenster nennen. Ein gutes System macht sie sichtbar: „Sie können diesen Vorgang innerhalb von fünf Minuten abbrechen.“ „Die neue Version läuft in den ersten dreißig Minuten mit kontrolliertem Datenverkehr.“ „Die Nachricht wird nach einer Wartezeit von zwei Minuten versendet.“ Kleine Verzögerungen können große Fehler verhindern.

Kontrollpunkte

Bei langen und komplexen Aufgaben sollte das System sichere Zwischenzustände schaffen.

Diese können wir Kontrollpunkte nennen.

In einem Webprojekt kann ein Kontrollpunkt Folgendes umfassen:

• einen Commit mit geprüftem Änderungsumfang,
• ein Versions-Tag,
• ein Deployment-Manifest,
• ein Backup,
• einen Hash-Nachweis.

Diese Aufzeichnungen können einen Rückkehrzustand festhalten.

Bei der Datenverarbeitung lassen sich festhalten:

• die Grenze der bereits verarbeiteten Datensätze,
• ein Zwischenergebnis,
• die Quellversion,
• eine Prüfsumme.

Damit wird der Zwischenstand dokumentiert.

In einem Agentengespräch kann aufgezeichnet werden:

• welche Kandidaten betrachtet wurden,
• welche Annahmen getroffen wurden,
• welche Befugnis aktuell gilt.

Kontrollpunkte sind nicht nur eine technische Erleichterung. Sie ermöglichen dem Agenten eine sichere Fortsetzung, wenn sein Kontext schrumpft oder die Aufgabe unterbrochen wird.

Die Startseite schützen

Bei einer eng begrenzten Änderung müssen unbeteiligte Bereiche unverändert bleiben. Wird eine Leistungsseite aktualisiert, dürfen Startseite, andere Leistungen oder gemeinsame Preisdatensätze nicht versehentlich beschädigt werden.

Das System kann dafür so vorgehen:

Die voraussichtlich zu ändernden Dateien benennen. Die Hashes kritischer Dateien erfassen, die unverändert bleiben müssen. Nach der Veröffentlichung beide Gruppen prüfen.

Das gilt nicht nur für Websites. Ein Einkaufsagent darf nur den freigegebenen Warenkorb ändern. Ein E-Mail-Agent darf nur an den angegebenen Empfänger senden. Ein Datenagent darf nur die erlaubten Felder verarbeiten.

Ein enger Auftrag muss einen engen Wirkungsbereich haben.

Der Wirkungsbereich

Eine der ersten Fragen nach einem Fehler lautet: Wie viel ist betroffen?

Das können wir als Wirkungsbereich bezeichnen.

Ein Fehler kann betreffen:

• einen einzelnen Nutzer,
• eine einzelne Datei,
• Seiten in sechs Sprachen,
• die gesamte Kundendatenbank,
• eine E-Mail-Liste mit Tausenden Personen,
• das gesamte Agentennetz.

Derselbe Fehler hat je nach Wirkungsbereich ein völlig anderes Gewicht. Deshalb sollte das System diesen Bereich bereits vor der Handlung begrenzen.

Zum Beispiel:

• Zunächst nur die sechs Ziel-URLs testen.
• Eine neue Nachrichtenkampagne mit einer kleinen Gruppe beginnen.
• Eine Softwareversion mit begrenztem Datenverkehr erproben.
• Eine neue Agentenbefugnis auf ein einzelnes Konto beschränken.
• Eine Datentransformation an einer Kopie durchführen.

So lässt sich der Wirkungsbereich verkleinern. Wir stellen damit dieselbe Frage wie der in der Sicherheitsliteratur verwendete Blast-Radius-Ansatz: Wie weit kann sich der Schaden ausbreiten, wenn etwas schiefgeht?

Schrittweise Einführung

Statt alle Nutzer gleichzeitig auf ein neues System umzustellen, kann die Änderung schrittweise ausgerollt werden. Zuerst das interne Team. Dann eine kleine Nutzergruppe. Danach mehr Datenverkehr. Schließlich das gesamte System.

Dabei werden vier Bereiche früh geprüft:

• Leistung,
• Fehler,
• Nutzerverhalten,
• Sicherheit.

Das hilft, Probleme rechtzeitig zu erkennen. Dieselbe Logik lässt sich auf Kommunikation anwenden: einen genehmigten Kommunikationsablauf mit einer kleinen Testgruppe erproben, für die Freigabe und Umfang klar sind; zunächst einen kontrollierten Kanal nutzen, bevor Inhalte in allen sozialen Kanälen erscheinen; vor dem Start in allen Ländern einen bestimmten Markt wählen. Eine schrittweise Einführung ist nicht immer möglich. Bei großem Wirkungsbereich ist sie jedoch eine starke Sicherheitsmaßnahme.

Sicherheit bei Wiederholungen

Ein Agent kann unsicher sein, ob ein Vorgang erfolgreich war. Die Netzwerkverbindung bricht ab. Das Zahlungssystem antwortet spät. Bei der E-Mail-API tritt eine Zeitüberschreitung auf. Versucht das System es erneut, kann der Vorgang doppelt ausgeführt werden.

Wichtige Handlungen müssen deshalb so gestaltet sein, dass eine wiederholte Anfrage nicht unbeabsichtigt zur doppelten Ausführung führt. Eine eindeutige Vorgangskennung kann zusammen mit einem Mechanismus verwendet werden, der sie speichert und Wiederholungen im richtigen Geltungsbereich prüft. Ein erneuter Versuch derselben Anfrage muss derselben Kennung zugeordnet sein. Allein das Erzeugen einer Kennung verhindert keine Dopplung. Auch das Verhalten des Gegensystems bei Wiederholungen, die zeitlichen Grenzen und gleichzeitige Anfragen müssen geprüft werden. Eine Zahlung darf nicht doppelt eingezogen werden. Dieselbe Kampagne darf nicht erneut an denselben Empfänger gehen. Dieselbe Dateiversion darf nicht als neuer Vorgang vervielfacht werden.

Der Agent muss zwischen „Keine Antwort erhalten“ und „Der Vorgang hat nicht stattgefunden“ unterscheiden.

Wie wird Teilerfolg behandelt?

Sind fünf von sechs Sprachen veröffentlicht, darf das System nicht sagen: „Die Veröffentlichung ist abgeschlossen.“

Es sollte sagen: „Fünf Sprachen sind fertig. Die arabische Fassung wurde nicht veröffentlicht, weil sie die RTL-Prüfung nicht bestanden hat.“ Wurde eine Zahlung ausgeführt, aber kein Bestelldatensatz angelegt, darf der Vorgang nicht geschlossen werden. Wurde eine E-Mail versendet, der Anhang aber nicht hochgeladen, ist das Ergebnis unvollständig.

Ein Bericht über Teilerfolg muss zeigen:

• was abgeschlossen ist,
• was noch fehlt,
• welches Risiko offenbleibt,
• was nutzbar ist,
• welcher nächste Schritt nötig ist,
• ob eine menschliche Entscheidung erforderlich ist.

Teilerfolg als vollständigen Erfolg darzustellen, verleitet nachgelagerte Systeme zu falschem Verhalten.

Unbemerkter Fehlschlag

Erscheint ein fehlgeschlagener Vorgang erfolgreich, beruhen spätere Entscheidungen auf einer falschen Grundlage. Ein Dateiübertragungswerkzeug sagt „abgeschlossen“, obwohl die Datei auf dem Zielserver unverändert ist. Ein Nachrichtensystem nimmt die Anfrage an, doch der Spamfilter verhindert die Zustellung. Strukturierte Daten werden erzeugt, fehlen aber im Live-HTML. Ein Agent glaubt, eine menschliche Freigabe erhalten zu haben; sie gilt jedoch für einen anderen Vorgang. Solche unbemerkten Fehlschläge erfordern unabhängige Überprüfung.

Die Erfolgsmeldung des ausführenden Systems darf nicht der einzige Nachweis sein.

Zum Beispiel:

• Nach der Dateiübertragung die Liveausgabe über HTTPS abrufen und mit der erwarteten Version vergleichen.
• Nach der lokalen Seite auch das Live-HTML prüfen.
• Nach der Zahlung Händler- und Bankdatensatz vergleichen.
• Nach dem Nachrichtenversand den Nachweis für richtigen Empfänger, Betreff und Anhang prüfen.
• Nach Nutzung der Befugnis die aktuell gültige Fassung erneut lesen.

Unabhängige Überprüfung

Ein Agent führt etwas aus. Eine andere Methode prüft das Ergebnis.

Das können wir unabhängige Überprüfung nennen. Das Veröffentlichungswerkzeug meldet den Upload; eine unabhängige HTTP-Prüfung vergleicht den Hash der Livedatei. Ein Codetest besteht; ein echter Browser prüft die Darstellung auf Mobilgeräten und am Desktop. Strukturierte Daten werden erzeugt; der semantische Inhalt der Liveseite wird gesondert gelesen. Ein Zahlungssystem meldet Erfolg; Buchhaltungsdatensatz und Händlerbestellung werden verglichen. Ein anderes Prüfwerkzeug ist hilfreich. Stützt es sich jedoch auf dieselbe falsche Quelle, entsteht dadurch allein noch keine Unabhängigkeit. Geprüft werden müssen sowohl das Ergebnis als auch die richtige Quelle, auf der Inhalt oder Entscheidung beruhen sollen.

Falsche Erfolgsmeldungen

Agenten können auch ohne bewusste Täuschung falsche Erfolgsmeldungen erzeugen. Das kann geschehen, wenn ein erfolgreicher Zwischenschritt mit dem Endergebnis verwechselt wird oder der Aufgabenabschluss stärker belohnt wird als die Prüfung.

GBO bevorzugt folgende Formulierungen: „Die Dateiübertragung ist abgeschlossen; der Liveinhalt ist noch nicht geprüft.“ „Die Crawling-Benachrichtigung wurde angenommen; das belegt keine Indexierung.“ „Die Testumgebung hat bestanden; die Leistung im Livebetrieb wurde nicht gemessen.“ „Die Angebotsanfrage wurde versendet; Kundeninteresse oder Verkaufsergebnis sind noch unbekannt.“ Diese Unterscheidung ist eine Grundlage des Vertrauens.

Was ist ein Vorfall?

Nicht jeder Fehler erfordert ein formelles Vorfallmanagement. Ein kleiner Schreibfehler kann direkt korrigiert werden.

Ein Sachverhalt muss jedoch als Vorfall behandelt werden, wenn er Auswirkungen auf folgende Bereiche hat:

• Daten,
• Identität,
• Geld,
• externe Kommunikation,
• ein Livesystem,
• rechtliche Verpflichtungen,
• Menschenrechte.

Folgen in diesen Bereichen verlangen eine Vorfallbehandlung.

Dafür lässt sich folgender Begriff definieren:

Vorfall im Agentenverhalten

Ein Vorfall im Agentenverhalten liegt vor, wenn ein KI-System vom geplanten, erlaubten oder erwarteten Verhalten abweicht und dadurch tatsächlichen Schaden oder ein begründetes Schadensrisiko für Menschen, Organisationen, Daten, Ressourcen, Rechte, Vertrauen oder Systemintegrität erzeugt. Ein Vorfall setzt nicht zwingend bereits eingetretenen Schaden voraus. Auch die Möglichkeit eines schweren Schadens kann als Vorfall gelten.

Die Schwere eines Vorfalls

Vorfälle sind nicht alle gleich. Eine praktische Einteilung ist möglich.

Niedrig

Ein kleiner, lokaler und leicht korrigierbarer Fehler.

Mittel

Begrenzte Auswirkungen auf Nutzer oder Prozesse; ein Mensch muss eingreifen.

Hoch

Finanzieller Schaden, personenbezogene Daten, externe Kommunikation, eine erhebliche Dienstunterbrechung oder verbreitete Falschdarstellung.

Kritisch

Ein umfangreiches Datenleck, hoher finanzieller Verlust, irreversibler rechtlicher oder körperlicher Schaden, Identitätsmissbrauch oder außer Kontrolle geratenes Agentenverhalten.

Mit zunehmender Schwere:

• werden automatische Handlungen in größerem Umfang gestoppt,
• werden höherrangige menschliche Verantwortliche informiert,
• wird eine unabhängige Untersuchung durchgeführt,
• werden externe Meldungen und rechtliche Pflichten geprüft.

Die ersten Minuten eines Vorfalls

Der Vorfallplan muss die folgenden Aufgaben zusammen behandeln. Die Reihenfolge ist beispielhaft: Eine dringende Meldung an den menschlichen Verantwortlichen und ein sicherer Stopp können bei Bedarf parallel erfolgen. Die Meldung muss nicht warten, bis alle anderen Schritte abgeschlossen sind.

1. Erkennen

Was ist tatsächlich geschehen?

2. Stoppen

Die laufende Handlung unterbrechen.

3. Eindämmen

Welche Konten, Nutzer, Dateien oder Systeme sind betroffen?

Die weitere Ausbreitung verhindern.

4. Nachweise sichern

Logs, Versionen, Nachrichten und Befugnisnachweise nicht löschen.

5. Einen sicheren Zustand herstellen

Die letzte verifizierte Version oder einen sicheren Betriebsmodus nutzen.

6. Den menschlichen Verantwortlichen informieren

Die der Schwere des Vorfalls entsprechende Person erreichen. „Sofort alles bereinigen“ ist in diesem Ablauf nicht unbedingt richtig. Gehen Nachweise verloren, lässt sich die Ursache nicht mehr verstehen.

Nachweise sichern

Bei einem Fehler muss das System:

• Logs erhalten,
• die alte Version bewahren,
• frühere Befugnisnachweise nicht nachträglich so umschreiben, als hätte eine Freigabe vorgelegen,
• den Nachrichtenverlauf erhalten,
• Zeitstempel bewahren.

Diese Aufzeichnungen dienen dem Lernen, der Prüfung und gegebenenfalls der Durchsetzung von Rechten. Zugriff und Aufbewahrungsdauer müssen ebenfalls auf die Erfordernisse des Vorfalls und die geltenden Pflichten begrenzt sein.

Was wussten wir? Welche Version wurde verwendet? Wer hat die Befugnis erteilt? Welches Werkzeug hat der Agent aufgerufen? Welcher Test wurde erfolgreich durchlaufen oder übersprungen? Wo begann die erste Abweichung?

Ohne Nachweise wird aus dem Vorfall eine Erzählung. Jede Seite erinnert sich anders. Aufzeichnungen mit überprüfbarer Herkunft, Integrität und Zeitangabe schaffen eine gemeinsame Untersuchungsgrundlage. Ein maschinell erzeugter Datensatz ist nicht automatisch richtig oder unveränderlich.

Das Vorfallprotokoll

Der Informationsumfang eines Vorfallprotokolls lässt sich mit diesen beispielhaften Feldnamen darstellen. Sie bilden für sich genommen kein ausführbares Schema:

incident_id

detected_at

detected_by

affected_systems

affected_people

agent_identity

authorization_version

action_receipts

initial_signal

actual_behavior

expected_behavior

impact

containment

rollback

notifications

recourse

compensation

root_cause

contract_change

closed_at

Nicht alle Einzelheiten müssen öffentlich sein. Für die interne Prüfung des Vorfalls muss aber eine ausreichende Spur vorhanden sein.

Korrektur und Abhilfe sind nicht dasselbe

Eine falsche Angabe kann von der Website entfernt worden sein. Das ist eine Korrektur. Hat ein Kunde auf dieser Grundlage bezahlt, kann eine Erstattung nötig sein. Das ist Abhilfe. Es kann sich herausstellen, dass ein Bewerber ungerechtfertigt abgelehnt wurde. Der Entscheidungsdatensatz lässt sich korrigieren, die Chance des Bewerbers kann jedoch bereits verloren sein. Daten eines Nutzers können an die falsche Person geschickt worden sein. Die Datei lässt sich löschen, doch die Privatsphäre wurde bereits beeinträchtigt.

Es gibt deshalb zwei getrennte Aufgaben:

Korrektur

Einen fehlerhaften Systemzustand richtigstellen.

Abhilfe

Versuchen, den Schaden zu beheben, der den betroffenen Menschen oder Organisationen durch das falsche Verhalten entstanden ist. Technische Teams konzentrieren sich häufig auf die Korrektur. GBO betrachtet auch die Abhilfe für Menschen als Teil des Verhaltensvertrags.

Kompensierende Handlung

Manche Vorgänge lassen sich nicht direkt rückgängig machen. Eine neue Handlung kann ihre Folgen mindern. Auch diese braucht eine eigene Befugnis und muss verhältnismäßig und sicher sein. Der erste Fehler verleiht dem Agenten nicht automatisch neue Kommunikations- oder Ausgabenbefugnisse.

Das können wir eine kompensierende Handlung nennen. Lässt sich eine falsche Überweisung nicht stornieren, kann die Möglichkeit einer Rückerstattung untersucht werden. Zu einer bereits versendeten falschen Nachricht kann nach Entscheidung einer befugten Person eine Korrektur oder Entschuldigung vorbereitet werden. Kunden, die von einem falschen Preis betroffen sind, können richtige Informationen und passende Optionen erhalten. Ist eine Reservierung nicht wiederherstellbar, lassen sich Alternativen prüfen. Wurde unberechtigt Zugriff gewährt, wird dieser nach dem Vorfallplan eingeschränkt; notwendige Schlüsselwechsel und Meldungen erfolgen in diesem Rahmen. Eine kompensierende Handlung stellt den früheren Zustand nicht vollständig wieder her. Sie soll Schaden mindern. Ob das gelingt und welche Folgen bestehen bleiben, muss gesondert bewertet werden.

Eine Entschuldigung allein ist keine Abhilfe

Ein System oder Unternehmen kann sagen: „Es tut uns leid, dass dieses Problem aufgetreten ist.“ Das ist wichtig.

Für wirksame Abhilfe müssen jedoch auch diese Fragen beantwortet werden:

• Was ist geschehen?
• Wer ist betroffen?
• Wurde das fortbestehende Risiko gestoppt?
• Welche Information war falsch oder welcher Vorgang unbefugt?
• Was wurde korrigiert?
• Welche Rechte hat die betroffene Person?
• Wie werden finanzielle oder aus dem Vorgang entstandene Verluste ausgeglichen?
• Wie wird die Gefahr einer Wiederholung verringert?

Eine Entschuldigung ersetzt keine Verantwortung.

Das Recht, Einspruch zu erheben

Ein Mensch muss eine Entscheidung oder Handlung eines Agenten anfechten können. „Diese Nachricht habe ich nicht freigegeben.“ „Dieser Preis wurde bei mir falsch angewandt.“ „Der Agent hat mich der falschen Person zugeordnet.“ „Ich habe der Übertragung meiner Daten in dieses System nicht zugestimmt.“ „Diese Worte des Avatars habe ich nicht gesagt.“ „Ich möchte sehen, auf welchen Nachweisen diese Auswahl beruht.“ Ein Einspruch ist mehr als ein Kundendienstticket. Er ist ein Weg, maschinelles Verhalten infrage zu stellen.

Ein wirksames Einspruchssystem muss Folgendes können:

• die Handlung auffinden,
• den zugehörigen Beleg zeigen,
• den Befugnisnachweis prüfen,
• eine menschliche Bewertung einleiten,
• den laufenden Vorgang stoppen,
• bei Bedarf korrigieren oder Abhilfe leisten.

Anfechtbarkeit

Ein System kann seine Entscheidung womöglich erklären. Das reicht nicht, wenn der Nutzer sie nicht von einer befugten Stelle überprüfen lassen kann.

Eine Erklärung kann lauten: „Aus diesem Grund haben wir Sie abgelehnt.“

Anfechtbarkeit bedeutet dagegen: „Wenn Sie diese Entscheidung für falsch halten, können Sie mit diesen Nachweisen eine erneute Prüfung beantragen.“ GBO strebt nicht nur erklärbares Verhalten an.

Anfechtbares Verhalten

Verhalten muss sich auch anfechten lassen. Denn ein erklärter Fehler bleibt ein Fehler. Menschen müssen auf die Entscheidung Einfluss nehmen können.

Wie muss ein Einspruchsverfahren aussehen?

Ein wirksames Einspruchsverfahren muss:

• auffindbar sein,
• verständlich sein,
• innerhalb angemessener Zeit stattfinden,
• Zugang zu einem Menschen bieten,
• ohne Vergeltungsmaßnahmen möglich sein,
• die Vorlage von Nachweisen erlauben,
• die Entscheidung tatsächlich ändern können.

Gibt es zwar einen Einspruchsbutton, werden aber alle Anträge automatisch abgelehnt, besteht kein echtes Einspruchsrecht. Menschliche Prüfung darf nicht nur die Maschinenentscheidung wiederholen.

Wer soll Einspruch erheben können?

Der in diesem Buch vorgeschlagene Einspruchsweg soll nicht nur dem Systemnutzer, sondern auch betroffenen Dritten offenstehen. Konkrete rechtliche Ansprüche auf Überprüfung sind gesondert zu beurteilen. Betroffen sein können der Empfänger einer im Firmennamen gesendeten Nachricht, eine Person, über die falsche Angaben verwendet wurden, ein Mensch, dessen Gesicht oder Stimme in einem KI-Avatar genutzt wird, ein automatisch abgelehnter Bewerber, ein Kunde, dessen Daten geteilt wurden, oder eine falsch dargestellte Organisation. Der Verhaltensvertrag betrachtet deshalb nicht nur die Beziehung zwischen Nutzer und Agent. Er berücksichtigt auch die Folgen für Dritte.

Das Recht auf Widerruf

Ein Mensch kann eine zuvor erteilte Einwilligung oder Befugnis zurückziehen.

Der Umfang des Widerrufs darf nicht damit verwechselt werden, frühere Vorgänge als ungeschehen zu behandeln. Für künftige Nutzungen und fortbestehende Folgen sind diese Fragen zu prüfen:

• Werden bestehende Veröffentlichungen entfernt?
• Werden Modelldateien gelöscht?
• Werden Unteragenten gestoppt?
• Werden geplante Inhalte gestrichen?
• Was geschieht mit Kopien bei externen Anbietern?
• Wie werden Archive und rechtlich erforderliche Aufzeichnungen geführt?

Wird die Erlaubnis zur Nutzung eines Gesichts oder einer Stimme widerrufen, reicht es möglicherweise nicht, nur die neue Erzeugung zu stoppen. Auch die Nutzungsbedingungen bestehender Inhalte müssen im Vertrag geregelt sein.

Ein Kontaktweg zu einem Menschen

Ein System darf bei Problemen nicht nur ein automatisiertes Formular anbieten. Ab einer festgelegten Schwere des Vorfalls muss ein tatsächlich verantwortlicher Mensch erreichbar sein.

Der Nutzer muss wissen:

Wen erreiche ich? Wann erhalte ich eine Antwort? Wird der Vorgang bis dahin angehalten? Welche Aufzeichnungen muss ich vorlegen?

GBO schließt den Menschen nicht aus dem System aus. Gerade bei der Wiederherstellung macht es seine Rolle deutlicher sichtbar.

Wer trägt die Verantwortung?

An einer Handlungskette können viele Parteien beteiligt sein:

• der Nutzer,
• die Organisation, die den Agenten betreibt,
• der Modellanbieter,
• der Werkzeuganbieter,
• der Datenanbieter,
• ein Unteragent,
• der freigebende Mensch,
• der Adressat der Handlung.

Bei einem Problem können alle sagen: „Ich habe nur einen Teil erledigt.“ Deshalb darf Verantwortung nicht erst nach dem Vorfall zum Thema werden. Sie muss vorher im Verhaltensvertrag geregelt sein.

Zum Beispiel:

• Der Mensch legt den Zweck fest und erteilt die abschließende Freigabe.
• Die Organisation setzt die Befugnisgrenzen durch.
• Der Agent erstellt einen Vorgangsbeleg.
• Der Werkzeuganbieter zeichnet die technische Antwort auf.
• Der menschliche Verantwortliche prüft den Einspruch.
• Die Organisation führt das Abhilfeverfahren durch.

Verantwortung kann verteilt werden. Sie darf nicht verschwinden.

„Das war die KI“ reicht als Erklärung nicht

Ein Unternehmen kann eine falsche Handlung nicht mit „Das hat die künstliche Intelligenz gemacht“ abtun.

Dieser Satz beantwortet keine der folgenden Fragen:

• Wer hat den Agenten beauftragt?
• Welche Befugnis wurde erteilt?
• Auf welche Werkzeuge durfte er zugreifen?
• Welche Kontrolle fehlte?
• War eine menschliche Freigabe erforderlich?
• Warum wurde der Vorfall nicht bemerkt?
• Wer wird den Schaden beheben?

KI darf nicht zum Vorhang werden, hinter dem Verantwortung verschwindet.

Die zugrunde liegende Ursache

Die sichtbare und die tatsächliche Ursache eines Vorfalls können verschieden sein. Ein falscher Preis wurde veröffentlicht.

Die sichtbare Ursache:

Der Agent hat die Zahl falsch verwendet.

Die zugrunde liegenden Ursachen könnten sein:

• unklare Namen zweier Leistungen,
• ein fehlender kanonischer Preisdatensatz,
• ein Widerspruch zwischen Maschinenkatalog und sichtbarer Seite,
• eine fehlende menschliche Freigabeschranke für Preisänderungen,
• ein Test, der nur das Zahlenformat statt der geschäftlichen Bedeutung prüfte,
• derselbe Agent, der die Änderung vornahm und sein eigenes Ergebnis freigab.

Ursachenanalyse lässt sich nicht auf die Frage „Warum hat das Modell falsch gedacht?“ reduzieren. Das Gesamtsystem muss untersucht werden.

Fünfmal warum?

Um ein Problem aufzuschlüsseln, können wir mehrfach „Warum?“ fragen. Die folgende Kette ist eine mögliche Erklärung, kein Beweis für die Ursache. Jeder Zusammenhang muss anhand von Aufzeichnungen geprüft werden; andere Ursachen sind ebenfalls zu untersuchen.

Warum wurde der falsche Preis veröffentlicht? Weil der Agent zwei Leistungen verwechselt hat.

Warum hat er sie verwechselt? Weil die Leistungsidentität in den Preisdatensätzen nicht klar war.

Warum war sie nicht klar? Weil es keinen einheitlichen kanonischen Katalog gab.

Warum gab es keinen Katalog? Weil die Preise nur in sichtbaren Texten geführt wurden.

Warum hat die Veröffentlichungskontrolle das nicht erkannt? Weil der Test das Format prüfte, nicht den geschäftlichen Zusammenhang.

Diese Kette schreibt den Fehler nicht allein dem Agenten zu. Sie zeigt eine Lücke im Systementwurf.

Den Vertrag korrigieren, nicht nur die Person

Macht ein Agent einen Fehler, lautet die erste Reaktion womöglich: „Mach das nicht noch einmal.“ Bleiben aber der unklare Auftrag, die weite Befugnis oder der fehlende Test bestehen, kehrt derselbe Fehler in anderer Form wieder.

Eine dauerhafte Verbesserung muss mindestens einen dieser Bereiche verändern:

• den Identitätsvertrag,
• den Fähigkeitsvertrag,
• den Eignungsvertrag,
• den Befugnisvertrag,
• den Wiederherstellungsvertrag,
• die Testschranken,
• die Werkzeugberechtigungen,
• die Schwelle für menschliche Freigaben,
• die Übergabe zwischen Agenten.

Eine gute Vorfallanalyse sucht nicht nach einem Schuldigen, sondern nach der Vertragslücke, die das falsche Verhalten ermöglicht hat.

Das hebt menschliche Verantwortung nicht auf. Es ist aber nützlicher, als nur eine Person zu bestrafen und das System unverändert zu lassen.

Der Unterschied zwischen Lernen und Strafe

Werden Vorfälle verschwiegen, kann das System nicht daraus lernen. Haben Beschäftigte oder Agentenbetreiber Angst, Fehler zu melden, können kleine Probleme wachsen.

Eine zuverlässige Organisation sollte folgende Kultur schaffen:

Frühes Melden wird gefördert. Das Verbergen von Fehlern wird nicht akzeptiert. Vorsätzlicher Missbrauch wird von gutgläubigen Fehlern unterschieden. Bei jedem Vorfall wird geprüft, ob ein Vertrag oder eine Kontrolle geändert werden muss; jede Änderung wird mit Begründung dokumentiert.

Das ist keine Kultur der Verantwortungslosigkeit, sondern eine Kultur wirklichen Lernens.

Beinahevorfall

Manchmal wird ein Problem gestoppt, bevor es zum Vorfall kommt. Ein Agent hat eine Nachricht an die falsche Person vorbereitet, doch ein Mensch bemerkt es. Ein falscher Preis gelangt in den Build, aber die Veröffentlichungskontrolle hält ihn auf. Eine Zahlung soll gerade doppelt gesendet werden, doch die Prüfung der eindeutigen Vorgangskennung verhindert es.

Das können wir einen Beinahevorfall nennen. Er ist nicht wertlos, nur weil kein Schaden entstanden ist. Im Gegenteil: Er zeigt, wo das System brechen könnte. Seine Untersuchung kann helfen, einen ähnlichen Vorfall zu verhindern, bevor Schaden entsteht.

Wiederherstellungsschulden

Beim Aufbau von Handlungssystemen konzentrieren sich Organisationen häufig auf die Produktion. Rücknahme und Abhilfe werden erst später bedacht.

Mit der Zeit sammeln sich an:

• veraltete Backups,
• ungetestete Rollback-Verfahren,
• unklare Zuständigkeiten für Vorfälle,
• unbrauchbare Logs,
• nicht widerrufbare Befugnisse,
• nicht gestoppte Unteragenten,
• undefinierte Einspruchswege.

Diese Rückstände summieren sich.

Das können wir Wiederherstellungsschulden nennen: die Lücke zwischen der Handlungsmacht eines Systems und seiner Fähigkeit, sich nach Fehlern zu erholen. Je mehr Vorgänge Agenten ausführen können, desto gefährlicher wird diese Schuld.

Wächst die Handlungskapazität, ohne dass die Wiederherstellungsfähigkeit mitwächst, wird das System nicht stärker, sondern fragiler.

Abhilfeschulden

Ein Unternehmen kann frühere Fehlhandlungen technisch korrigiert haben, ohne die betroffenen Menschen zu informieren oder ihre Schäden zu beheben.

Diese Rückstände können wir Abhilfeschulden nennen. Mit der Zeit führen sie zu Vertrauensverlust.

Das Unternehmen sagt vielleicht: „Das Problem ist behoben.“

Die betroffene Person sagt: „Mir wurde aber nie erklärt, was mit mir geschehen ist.“ GBO unterscheidet zwischen technischem Abschluss und einem Abschluss für die betroffenen Menschen.

NOMOS Wiederherstellungs- und Abhilfevertrag

Als fünften und letzten Bestandteil des Verhaltensvertrags schlagen wir den NOMOS Wiederherstellungs- und Abhilfevertrag vor.

Seine kanonische Definition lautet:

Der NOMOS Wiederherstellungs- und Abhilfevertrag ist ein versionierter Datensatz, der für eine falsche, unvollständige, unbefugte, gescheiterte oder unerwartet wirkende Agentenhandlung beschreibt, wie das Verhalten erkannt und gestoppt wird, wie sein Wirkungsbereich begrenzt wird, welcher sichere Zustand wiederhergestellt wird, wie Nachweise erhalten bleiben, wer informiert wird, wie Betroffene Einspruch erheben können, welche Korrekturen oder Abhilfemaßnahmen gegen den Schaden vorgesehen sind und wie der Verhaltensvertrag aktualisiert wird.

Einfacher gesagt: Dieser Vertrag beantwortet „Was tun wir, wenn etwas schiefgeht?“, bevor ein Vorfall eintritt.

Die zentralen Vertragsfelder

Der Informationsumfang des Vertrags lässt sich mit folgenden beispielhaften Feldnamen darstellen. Die Liste ist ein Entwurfsrahmen; Implementierungsschema und Kontrollen müssen gesondert entwickelt werden:

action_type

failure_modes

detection_signals

safe_state

automatic_stop_conditions

containment_scope

checkpoint

rollback_method

rollback_window

irreversible_point

human_owner

notification_rules

affected_party_contact

appeal_channel

compensation_policy

evidence_retention

root_cause_review

contract_update

recovery_test_date

version

Nicht alle Felder müssen öffentlich sein. Im Vorfall müssen sie jedoch dem System und den verantwortlichen Menschen zugänglich sein.

NOMOS Wiederherstellungstor

Bevor ein Agent handelt, muss er nicht nur den Erfolgsweg, sondern auch den Weg im Fehlerfall prüfen.

1. Erkennungstor

Woran lässt sich erkennen, dass die Handlung schiefgegangen ist?

2. Stopptor

Wie wird der laufende Vorgang gestoppt?

3. Eindämmungstor

Wie wird der Wirkungsbereich verkleinert?

4. Kontrollpunkttor

Gibt es einen verifizierten Zustand, zu dem zurückgekehrt werden kann?

5. Rücknahmetor

Ist eine technische oder vorgangsbezogene Rücknahme möglich? Wenn nicht: Sind ihre Grenzen, die erforderliche Freigabe und der Abhilfeplan klar?

6. Tor der menschlichen Verantwortung

Welcher Mensch oder welche Organisation ist für den Vorfall verantwortlich?

7. Benachrichtigungstor

Wer wird wann und mit welchen Angaben informiert?

8. Einspruchstor

Wie kann die betroffene Person die Entscheidung oder Handlung anfechten?

9. Abhilfetor

Was lässt sich zur Behebung nicht rückgängig zu machender Schäden tun, und was bleibt unbehebbar?

10. Lerntor

Welcher Vertrag oder welches System wird geändert, damit derselbe Fehler nicht wiederkehrt?

Einfach ausgedrückt:

BEDINGUNGEN VERANTWORTLICHER WIEDERHERSTELLUNG:

ERKENNUNG

UND STOPP

UND EINDÄMMUNG

UND SICHERE RÜCKKEHR

UND MENSCHLICHE VERANTWORTUNG

UND BENACHRICHTIGUNG

UND EINSPRUCH

UND ABHILFE

UND VERTRAGSKORREKTUR

Fehlt eines dieser Tore, kann das System zwar handeln. Auf Fehler ist es dann aber nicht vorbereitet.

Warum muss das Wiederherstellungstor vor der Handlung greifen?

Meist denken Menschen erst nach einem Fehler an die Wiederherstellung. Bei manchen Handlungen kann es dann schon zu spät sein. Hat sich ein Gesichtsmodell verbreitet, lassen sich womöglich nicht mehr alle Kopien finden. Ein an ein externes System übertragener Datensatz ist möglicherweise nicht vollständig löschbar. Ein unterschriebener Vertrag lässt sich womöglich nicht einseitig aufheben. Wurde eine Arzneimittelempfehlung umgesetzt, können körperliche Wirkungen bereits eingesetzt haben.

Vor einer risikoreichen Handlung muss deshalb gefragt werden: Was geschieht, wenn wir uns irren?

Gibt es keine Antwort, muss die Handlungsstufe gesenkt werden.

Menschliche Freigabe bei irreversiblen Handlungen

Lässt sich ein Verhalten nicht in sinnvoller Weise rückgängig machen, müssen die Grenzen der Rücknahme vorab ausdrücklich bewertet werden. Irreversibilität verbietet nicht automatisch jeden Vorgang. Eine stärkere Freigabe macht aber auch keinen unbefugten, verbotenen oder unvertretbar riskanten Vorgang legitim. Gültige Befugnis, Risikobewertung und die nötige menschliche Entscheidung müssen gemeinsam vorliegen.

Der Mensch muss sehen:

• das Ergebnis,
• das Risiko,
• die Alternative,
• die Grenzen der Abhilfe.

Diese Punkte müssen vor der Entscheidung erkennbar sein.

Ein wichtiger GBO-Grundsatz lautet: Je weniger sich rückgängig machen lässt, desto stärker muss die menschliche Freigabe sein. Das bedeutet nicht, dass Menschen stets die bessere Entscheidung treffen. Es sorgt aber dafür, dass die Verantwortung für irreversible Folgen sichtbar einer menschlichen Entscheidungsinstanz zugeordnet wird.

Wartezeit bei folgenreichen Handlungen

Bei manchen folgenreichen Vorgängen kann eine kurze Wartezeit sinnvoll sein:

• eine große Überweisung,
• massenhafte Datenlöschung,
• eine Nachricht an ein großes Publikum,
• die dauerhafte Schließung eines Kontos,
• die Veröffentlichung eines biometrischen Modells,
• eine öffentliche Krisenerklärung.

Ist das System entsprechend gestaltet, kann zwischen Freigabe und Ausführung eine Wartezeit liegen, während der ein Abbruch möglich ist. Ob nach der Ausführung noch storniert werden kann, muss gesondert geprüft werden. So erhält der Nutzer die Gelegenheit, eine übereilte oder falsche Freigabe zu bemerken. In Notfällen kann die Frist übersprungen werden. Auch dafür muss jedoch eine gesonderte Befugnis bestehen.

Beispiel: Veröffentlichung einer Website

Ein Agent erstellt eine neue Leistungsseite in sechs Sprachen.

Eine gute Wiederherstellungsplanung umfasst:

• eine Bestandsliste der geänderten Dateien,
• Hashes der Dateien, die unverändert bleiben müssen,
• einen sauberen Build,
• gezielte Vertragstests,
• vollständige Regressionstests,
• ein Backup,
• eine eng begrenzte Veröffentlichung,
• die Hash-Prüfung der Dateien auf dem Zielserver,
• Liveprüfung über HTTPS,
• Qualitätsprüfung auf Mobilgeräten und am Desktop,
• Leistungsmessung,
• die Meldung ausschließlich geänderter URLs,
• ein Rollback-Paket,
• ein Messprotokoll.

Wird ein Problem gefunden:

• wird die neue Veröffentlichung gestoppt,
• wird die letzte sichere Version verwendet,
• werden die betroffenen URLs ermittelt,
• werden kontrollierte Quelldatensätze korrigiert; für veraltete Ergebnisse in externen Such- und KI-Systemen werden vorhandene Melde- oder Korrekturwege genutzt und die tatsächlichen Aktualisierungen gesondert beobachtet,
• wird ein Vorfallprotokoll angelegt.

Das ist nicht nur technische Qualität. Es ist die Verantwortung nach der Handlung, die GBO fordert.

Beispiel: E-Mail

Ein Agent verschickt versehentlich eine unbefugte Nachricht an einen potenziellen Kunden. Ein technischer Rückruf ist nicht möglich. Die Nachricht liegt im Postfach des Empfängers.

Eine angemessene Wiederherstellung kann folgende Schritte umfassen:

• neue automatische Sendungen stoppen,
• weitere Nachrichten derselben Kampagne stornieren,
• ermitteln, was an welche Empfänger gesendet wurde,
• die geteilten Informationen prüfen,
• den menschlichen Vorgesetzten informieren,
• bei Bedarf eine Korrektur oder Entschuldigung vorbereiten,
• weitere Kontaktaufnahmen stoppen,
• die Versandbefugnis neu festlegen,
• zwischen Entwurf und Versand eine menschliche Freigabe einfügen.

„Wir können die Nachricht nicht zurückrufen“ bedeutet nicht, dass die Wiederherstellung beendet ist. Wo technische Rücknahme fehlt, ist Abhilfe für Menschen und für die Folgen des Vorgangs gefragt.

Beispiel: Einkauf

Der Agent kauft das falsche Produkt.

Zur Wiederherstellung gehören folgende Fragen:

• Lässt sich die Bestellung stornieren?
• Wurde das Produkt bereits versendet?
• Fallen Rücksendekosten an?
• Hat ein Abonnement begonnen?
• Ist die automatische Verlängerung aktiviert?
• Welcher Abteilung gehörte das verwendete Budget?
• Betrifft derselbe Fehler weitere Bestellungen?
• Warum war das Auswahlkriterium falsch?
• War die Schwelle für menschliche Freigaben ausreichend?

Eine Rückerstattung allein reicht möglicherweise nicht. Auch der Eignungs- und der Befugnisvertrag des Agenten müssen korrigiert werden.

Beispiel: KI-Avatar

Der Avatar einer Führungskraft wird mit einem nicht freigegebenen Text veröffentlicht.

Bei diesem Vorfall muss:

• die Veröffentlichung sofort gestoppt werden,
• der Inhalt aus kontrollierten Kanälen entfernt werden; bei externen Kopien sind vorhandene Antrags- und Beschwerdewege zu nutzen, nicht erreichbare Kopien müssen dokumentiert werden,
• die Weiterverbreitung anhand der Aufzeichnungen untersucht werden,
• der Zugriff auf Gesichts- und Stimmmodell ausgesetzt werden,
• die Führungskraft informiert werden,
• gegebenenfalls eine Korrektur an das Publikum erfolgen,
• der synthetische Charakter des Inhalts offengelegt werden,
• die überschrittene Veröffentlichungsbefugnis untersucht werden,
• für künftige Texte eine jeweils gesonderte Freigabe verpflichtend sein.

Auch nach dem Löschen des Videos kann das Ansehen der Führungskraft beeinträchtigt sein. Abhilfe bedeutet deshalb mehr als das Entfernen einer Datei.

Beispiel: Personalentscheidung

Ein Agent lehnt einen geeigneten Bewerber wegen falscher Daten ab. Die Entscheidung wird später bemerkt. Technisch lässt sich der Datensatz korrigieren. Der Bewerber kann sich aber bereits einer anderen Möglichkeit zugewandt haben.

Eine angemessene Wiederherstellung kann so aussehen:

• die Entscheidung aussetzen,
• ähnliche Entscheidungen prüfen,
• dem Bewerber eine erneute Bewertung ermöglichen,
• eine menschliche Prüfung durchführen,
• die Quelle der falschen Daten korrigieren,
• betroffene Bewerber ermitteln,
• die Auswahlkriterien erneut testen.

Das Beispiel zeigt: Es geht nicht nur um den Systemzustand. Auch die Chance eines Menschen steht auf dem Spiel.

Beispiel: Agentennetz

Ein zentraler Agent beauftragt einen Unteragenten mit Kundenrecherche. Der Unteragent ruft ein anderes E-Mail-Werkzeug auf und versendet eine Nachricht. Der Hauptagent hat nicht unmittelbar gesendet. Trotzdem hat Befugniswäsche stattgefunden. Zur Wiederherstellung reicht es nicht, das E-Mail-Werkzeug abzuschalten.

Zusätzlich müssen folgende Schritte erfolgen:

• Unteragenten in der betroffenen Auftragskette sicher stoppen,
• die Befugniskette prüfen,
• verbotenes Verhalten in den Auftragspaketen sichtbar machen,
• die Versandberechtigung auf Werkzeugebene entziehen,
• verhindern, dass Unteragenten die Befugnis erweitern,
• die menschliche Freigabeschranke zentralisieren.

Wiederherstellung testen

Ein vorhandener Rücknahmeplan beweist nicht, dass er funktioniert. Backups müssen regelmäßig getestet werden. Stoppt der Kill Switch tatsächlich auch die Unteragenten?

Wie viele Minuten dauert die Rückkehr zur alten Version?

Sind die wiederhergestellten Daten konsistent?

Funktioniert ein widerrufener API-Schlüssel tatsächlich nicht mehr?

Erreicht der Einspruchskanal einen echten Menschen?

Organisationen sollten ihre Wiederherstellung deshalb regelmäßig üben.

Wiederherstellungsübung

Eine solche Übung muss in einer ausdrücklich genehmigten Umgebung stattfinden, die das Risiko realer Schäden begrenzt. Bei Tests im Livesystem werden Wirkungsbereich, Datensicherheit, Abbruchbedingungen und Rücknahme vorab festgelegt.

Beispiele für Übungen

• Simulation einer Veröffentlichung mit falschem Preis
• Versuch einer doppelten Zahlung
• Versuch eines unbefugten E-Mail-Versands
• Versuch eines Unteragenten, seine Grenzen zu überschreiten
• Rollback-Test der Liveversion
• Szenario zum Widerruf einer identitätsbezogenen Befugnis
• Not-Aus-Test für einen KI-Avatar
• Reaktionszeit des Einspruchskanals
• Stopp eines Datenexports

Probleme, die in der Übung auffallen, können vor einem wirklichen Vorfall behoben werden.

Stufen der Wiederherstellungsbereitschaft

Dieser Ansatz lässt sich in fünf Bereitschaftsstufen zusammenfassen:

1. Reaktiv

Erst wenn ein Problem auftritt, wird überlegt, was zu tun ist.

2. Dokumentiert

Ein Rücknahmeplan ist vorhanden, wird aber nicht regelmäßig getestet.

3. Technisch rückgängig zu machen

Backup, Versionierung und Rollback-System sind vorhanden.

4. Abhilfe für Menschen und Vorgänge vorbereitet

Auch Benachrichtigung, Einspruch und Abhilfe sind geregelt.

5. Agentenbereite Wiederherstellung

Agenten erkennen Vorfallsignale, halten im sicheren Zustand an, rufen einen Menschen hinzu, erstellen einen Beleg und stoßen eine Vertragsaktualisierung an. GBO zielt auf die fünfte Stufe.

Zwanzig Prüffragen zur Wiederherstellung

Vor einer Agentenhandlung oder bei der Prüfung des Systems können folgende Fragen gestellt werden:

• Woran wird erkannt, dass die Handlung fehlgeschlagen ist?
• Werden technischer Erfolg und Erfolg in der realen Welt getrennt?
• Kann ein laufender Vorgang automatisch gestoppt werden?
• Ist der sichere Zustand vorab definiert?
• Wie groß ist der Wirkungsbereich?
• Kann die Änderung eng begrenzt bleiben?
• Gibt es einen letzten verifizierten Kontrollpunkt?
• Wurde das Rücknahmeverfahren tatsächlich getestet?
• Wie lang ist das Rücknahmefenster?
• Wo liegt der irreversible Punkt?
• Können Unteragenten und geplante Aufgaben gemeinsam gestoppt werden?
• Bleiben Vorfallprotokolle und Befugnisnachweise erhalten?
• Welcher Mensch ist für den Vorfall verantwortlich?
• Wann werden Betroffene informiert?
• Wie kann ein Mensch die Entscheidung oder Handlung anfechten?
• Kann über die technische Korrektur hinaus Abhilfe erforderlich sein?
• Wie werden Folgen behandelt, die in Drittsystemen verbleiben?
• Wie wird die zugrunde liegende Ursache untersucht?
• Welche Änderung wird am Verhaltensvertrag vorgenommen?
• Wann wurde der Wiederherstellungsplan zuletzt geübt?

Ohne Antworten kann das System an erfolgreichen Tagen funktionieren. Zuverlässig ist es nicht.

Qualifizierte Wiederherstellung

Ob eine Wiederherstellung als qualifiziert gilt, richtet sich nach klaren Anforderungen.

Qualifizierte Wiederherstellung

Dafür müssen alle folgenden Bedingungen gemeinsam vorliegen:

• Das Problem wurde früh erkannt.
• Der fortdauernde Schaden wurde gestoppt.
• Der Wirkungsbereich wurde eingegrenzt.
• Das technische System ist in einen sicheren Zustand zurückgekehrt.
• Die Nachweise zum Vorfall wurden erhalten.
• Betroffene Menschen wurden angemessen informiert.
• Einspruch und menschliche Prüfung sind möglich.
• Abhilfe für nicht rückgängig zu machende Schäden wurde geprüft.
• Die zugrunde liegende Ursache wurde ermittelt.
• Der Verhaltensvertrag wurde aktualisiert.
• Die neue Kontrolle wurde getestet.

Nur eine alte Datei wiederherzustellen, ist noch keine qualifizierte Wiederherstellung.

Scheitern nicht verbergen

Unternehmen können fürchten, mit der Bekanntgabe eines Fehlers Vertrauen zu verlieren. Eine Offenheit, die Schwere und Pflichten des Vorfalls angemessen berücksichtigt, kann Vertrauen aber stärken.

Diese Formulierung ist glaubwürdiger: „Im genannten Zeitraum wurde der Preisdatensatz dieser Leistung falsch veröffentlicht. Das Problem ist korrigiert. Betroffene Anfragen werden erneut geprüft. Der Veröffentlichungsvertrag wurde aktualisiert, damit sich der Fehler nicht auf weitere Sprachen und Systeme ausbreitet.“

Diese Formulierung schwächt dagegen Vertrauen: „Eine kleine technische Störung wurde behoben.“ War das Problem keine technische Störung, sondern ein Fehler in der geschäftlichen Bedeutung, darf es nicht so verharmlost werden.

Die Beschreibung eines Fehlers muss seinen tatsächlichen Folgen entsprechen.

Transparenz heißt nicht, alles zu veröffentlichen

Nicht alle internen Einzelheiten eines Vorfalls können öffentlich sein. Sicherheitsinformationen, personenbezogene Daten und Geschäftsgeheimnisse müssen geschützt werden. Tatsachen, die Betroffene kennen müssen, dürfen aber nicht verschwiegen werden.

Das richtige Maß ist ausreichende Offenheit darüber:

• was geschehen ist,
• welcher Zeitraum betroffen war,
• welche Daten oder Vorgänge betroffen waren,
• was unternommen wurde,
• welche Rechte die Person hat.

Zu diesen Punkten braucht es hinreichende Klarheit.

Der Wert von Fehlschlägen für GBO

Ein Vorfall ist nicht nur ein negativer Eintrag. Richtig untersucht, macht er eine Lücke im Vertrag des Systems sichtbar.

Ein falscher Preis:

kann eine Lücke im Vertrag zu Fähigkeit und geschäftlichem Leistungsumfang zeigen.

Eine unbefugte Nachricht:

kann eine Lücke bei Befugnis und Handlungsstufengrenze zeigen.

Die Auswahl des falschen Unternehmens:

kann eine Lücke im Identitäts- oder Eignungsvertrag zeigen.

Eine nicht rückgängig zu machende Veröffentlichung:

kann eine Lücke im Wiederherstellungsvertrag zeigen. Der Fehler ist nicht der Feind des Systems. Der verschwiegene Fehler, aus dem niemand lernt, ist es.

Die fünf Verträge wirken zusammen

Im zweiten Teil haben wir fünf grundlegende Verträge aufgebaut.

1. Identitätsvertrag

Wer bist du?

2. Fähigkeitsvertrag

Was kannst du tatsächlich tun?

3. Eignungsvertrag

Unter welchen Bedingungen solltest du ausgewählt werden?

4. Befugnisvertrag

Welche Handlung darfst du wie weit ausführen?

5. Wiederherstellungs- und Abhilfevertrag

Was passiert, wenn etwas schiefgeht?

Fehlt einer dieser fünf Verträge, wird das gesamte Verhalten geschwächt. Die Identität stimmt, aber die Fähigkeit ist unbekannt. Die Fähigkeit ist real, passt aber nicht zum Nutzer. Die Auswahl ist geeignet, aber es fehlt die Befugnis. Die Befugnis liegt vor, aber für Fehler gibt es keinen Rückweg. Deshalb ist der Verhaltensvertrag von GBO keine einzelne Datei. Er ist ein System sich ergänzender Teile.

Das Kernmodell des Verhaltensvertrags

Einfach ausgedrückt:

GRUNDBEDINGUNGEN FÜR RICHTIGES AGENTENVERHALTEN:

RICHTIGE IDENTITÄT

UND TATSÄCHLICHE FÄHIGKEIT

UND ÜBERPRÜFTE EIGNUNG

UND GÜLTIGE BEFUGNIS

UND VERANTWORTLICHE WIEDERHERSTELLUNG

Das ist kein Punktedurchschnitt. Bei schwacher Identität reicht hohe Fähigkeit nicht. Ohne Eignung reicht das Ansehen einer Marke nicht. Ohne Befugnis genügt die Aussicht auf ein gutes Ergebnis nicht. Ohne Wiederherstellung reicht hohe Leistung nicht. Jedes kritische Tor muss passiert werden.

Warum steht der Mensch weiterhin im Mittelpunkt?

Weil sich Schäden nicht auf den technischen Zustand des Systems beschränken.

Betroffen sind bei Menschen:

• Geld,
• Zeit,
• Ansehen,
• Privatsphäre,
• Chancen,
• Identität,
• Vertrauen.

Eine Maschine kann technisch zum alten Zustand zurückkehren. Ein Mensch erholt sich möglicherweise nicht ebenso leicht. Deshalb darf bei der Wiederherstellung nicht allein eine Systemkennzahl das letzte Wort haben. Auch die Lage des betroffenen Menschen muss betrachtet werden.

Der richtige Satz, wenn etwas schiefgeht

Ein zuverlässiger Agent sollte sagen können: „Ich habe eine Abweichung vom geplanten Verhalten erkannt. Ich habe bestätigt, dass neue Sendungen gestoppt sind; den Status zweier bereits in einem externen System gestarteter Vorgänge prüfe ich noch. Das sind die betroffenen Datensätze. Für die rückgängig zu machenden Teile liegt ein Plan vor; die übrigen Folgen erfordern menschliche Prüfung und Abhilfe.“

Das ist viel wertvoller als „Ein Fehler ist aufgetreten“. Der Satz zeigt Problem, Verhalten und Verantwortung gemeinsam.

Das Urteil dieses Kapitels

Ein starkes System zeichnet sich nicht nur dadurch aus, dass es richtige Handlungen schnell ausführt.

Ein starkes System:

• erkennt Fehler,
• stoppt fortdauernden Schaden,
• verkleinert den Wirkungsbereich,
• kehrt zum letzten sicheren Zustand zurück,
• prüft seine Erfolgsmeldung unabhängig,
• bewahrt Nachweise,
• informiert Menschen,
• ermöglicht Einspruch,
• versucht, Schaden zu beheben,
• aktualisiert den Verhaltensvertrag.

Fehlerfreiheit entsteht nicht allein durch ein Versprechen. Wiederherstellbarkeit lässt sich dagegen als Fähigkeit gestalten.

Darum ist GBO mehr als ein Optimierungsfeld: Es will Verhalten nicht vermehren, sondern verantwortbar machen. Ein Agent kann die richtige Person finden, die tatsächliche Fähigkeit verstehen, eine geeignete Auswahl treffen und mit gültiger Befugnis handeln. Trotzdem kann etwas schiefgehen. Das bedeutet nicht, dass das System gescheitert ist. Ohne einen Weg zur Wiederherstellung ist es jedoch unzuverlässig.

Der NOMOS Wiederherstellungs- und Abhilfevertrag fordert deshalb: Jede bedeutsame Handlung muss nicht nur mit einem Erfolgsplan, sondern auch mit einem Plan für Stopp, Rücknahme, Einspruch und Abhilfe entworfen werden.

Am Ende des zweiten Teils liegt der gesamte Kern des Verhaltensvertrags vor:

Ohne Identität gibt es kein richtiges Gegenüber. Ohne Fähigkeit gibt es kein reales Versprechen. Ohne Eignung gibt es keine richtige Auswahl. Ohne Befugnis gibt es keine legitime Handlung. Ohne Wiederherstellung gibt es kein dauerhaftes Vertrauen.

Bleiben diese Verträge nur im Buch, verändert sich die Welt nicht. Unternehmen, Institutionen, Produkte und Agentensysteme müssen sie in ihre tägliche Arbeit überführen. Im nächsten Teil wechseln wir deshalb von der Erklärung des Konzepts zur Anwendung.

Unsere erste Frage wird lauten:

Wie wird eine Organisation für Agenten bereit?

Agentenbereitschaft bedeutet nicht nur, eine API zu veröffentlichen oder eine Website mit „AI-ready“ zu kennzeichnen.

Eine agentenbereite Organisation hat:

• ihre Identität geklärt,
• ihre Fähigkeiten begrenzt,
• ihre Eignungsbedingungen erklärt,
• ihre Befugniskarte erstellt,
• ihren Wiederherstellungsweg für Fehler getestet.

Daran bemisst sich ihre Bereitschaft.

Einer Maschine einen Handlungskanal zu öffnen, macht daraus noch keine verantwortbare Handlung. Angemessene Befugnisse, Kontrolle und Rücknahmegrenzen erfordern eine durchdachte organisatorische Gestaltung.