Wenn man das bozo bit setzt, schaltet sich das Lernen ab

• bozo bit bezeichnet in der Softwarebranche die Haltung, dass das Urteilsvermögen und die Aussagen einer bestimmten Person keinen Wert mehr haben und es nicht mehr lohnt, ihr zuzuhören
• Wer die Beteiligten eines Vorfalls als unfähig abgrenzt, verringert die Chance einer Organisation, aus dem Vorfall zu lernen
• Die Reaktion auf den AI-Vorfall bei PocketOS entspricht Cook und Woods’ distancing through differencing
• Ein US-Werk, das einen Fabrikbrand im Ausland als Problem anderer betrachtete, übersah die geteilten Gemeinsamkeiten des Systems
• Wenn AI-Vorfälle mit „sie hätten es wissen müssen“ abgetan werden, führt das nur schwer zu Verbesserungen der Sicherheit

---

Wenn man Vorfälle als Problem anderer abtut, hört das Lernen auf

• bozo bit ist in der Softwarebranche ein Ausdruck für die Haltung, das Urteilsvermögen einer bestimmten Person nicht mehr zu respektieren und ihre Aussagen nicht mehr für hörenswert zu halten
• Wenn man nach der Nachricht über einen Vorfall sagt: „Wie kann man nur X nicht tun?“, betrachtet man die Betroffenen als inkompetent und trennt sie gedanklich von der eigenen Organisation
• Der X-Post des PocketOS-Gründers Jer Crane An AI Agent Just Destroyed Our Production Data. It Confessed in Writing erhielt als AI-bezogener Vorfall große Aufmerksamkeit, und online gab es viele Beiträge, die PocketOS für unfähig hielten
• Diese Haltung verringert die Gelegenheit, aus Vorfällen zu lernen, und entspricht dem, was Cook und Woods distancing through differencing nennen

• Distanzierung durch Unterschiede (distancing through differencing)

  • Richard Cook und David Woods verwendeten diesen Begriff in ihrem Aufsatz von 2006 Distancing Through Differencing: An Obstacle to Organizational Learning Following Accidents
  • Der Text erschien als ein Kapitel in Resilience Engineering: Concepts and Precepts
  • Wenn man sich auf die Unterschiede zwischen den vom Vorfall Betroffenen und einem selbst konzentriert, kommt man leicht zu dem Schluss, dass es keine Lehren für den eigenen Betrieb und die eigene Praxis gibt
  • Die Schlussfolgerung „Dieser Vorfall kann hier nicht passieren“ ist eine typische Form dieses Phänomens

Wiederkehrende Vorfälle und übersehene Gemeinsamkeiten

• Cook und Woods behandeln den Fall eines chemischen Brands in einem US-Produktionswerk
• In einem ausländischen Werk desselben Unternehmens hatte es zuvor einen ähnlichen Brand gegeben, und die US-Beschäftigten wussten davon
• Die US-Beschäftigten hielten die Mitarbeitenden im Ausland jedoch für weniger qualifiziert, weniger motiviert und weniger vorsichtig und entschieden deshalb, dass es für sie nichts daraus zu lernen gebe
• Selbst nachdem es im US-Werk zu einem Brand gekommen war, führten Beschäftigte anderer Schichten desselben Werks die Ursache auf die geringe Qualifikation der Schicht zurück, in der der Vorfall passiert war
• Solche Unterscheidungen verhindern, dass man die Gemeinsamkeiten des Systems erkennt, die die Beteiligten des Vorfalls und man selbst teilen
• Cook und Woods argumentieren, dass man Ereignisse, die oberflächlich unterschiedlich wirken, nicht vorschnell verwerfen sollte: Auf einer Analyseebene ist jedes Ereignis einzigartig, auf einer anderen zeigen sich gemeinsame Muster
• Wenn man den PocketOS-Vorfall einfach mit dem Schluss abtut, man habe „AI verantwortungslos eingesetzt“, bleibt nichts mehr zu lernen übrig
• Railway, das von PocketOS genutzt wurde, war ein Anbieter mit offener Delete-API und erklärte später in Your AI wants to nuke your database. Guardrails fix that, Änderungen vorgenommen zu haben, um die Sicherheit des Gesamtsystems zu erhöhen
• Auch künftig wird es in der Branche weiterhin AI-bezogene Vorfälle geben, und die Haltung „sie hätten wissen müssen, dass man X nicht tun sollte“ ist eine Falle von distancing through differencing
• Es gibt einen Unterschied zwischen Fällen, in denen jemand absichtlich übermäßige Risiken einging, und Fällen, in denen jemand unbewusst übermäßige Risiken einging; nur weil jemand nicht wusste, was er nicht wusste, ist es schwer, die Person individuell zu verurteilen
• Wenn man über distancing through differencing hinausgeht, kann sich auch die Reaktion einer Organisation verändern

[GN⁺]

Lobste.rs-Kommentare

• Der Wert des bozo bit besteht darin, dass manche Leute eine verlässliche Quelle inverser Information sind
  Solche Menschen kommen gewohnheitsmäßig immer wieder zu falschen Schlussfolgerungen, missverstehen sogar sehr direkt formulierte Dokumente und liefern Entwürfe, die das Ziel nicht lösen und stattdessen neue Probleme schaffen
  Bei jemandem das bozo bit zu setzen bedeutet, entschieden zu haben, dass der Versuch, aus der Kommunikation dieser Person Wissen zu gewinnen, Zeitverschwendung ist
  Dieser Artikel wirft das bozo bit mit einem anderen Phänomen zusammen, bei dem man fest davon überzeugt ist, dass ein bestimmtes Problem unmöglich auftreten kann, und von dort aus rückwärts Gründe konstruiert
  Ein geläufiger Begriff dafür ist Rationalisierung im Nachhinein, und seit Jahrhunderten oder gar Jahrtausenden wird viel darüber gesprochen, dass man das vermeiden sollte
  Zurück zu dem Beispiel im Artikel mit der Firma, die einem LLM Admin-Rechte auf der Produktionsdatenbank gegeben hat: Die Reaktion „Das passiert mir wegen X nicht“ ist berechtigt, wenn X ungefähr bedeutet: „Ich würde einem LLM gar nicht erst Admin-Rechte auf einer Produktionsdatenbank geben, weil das so bizarr und wahnsinnig gefährlich ist“
  Das ist ähnlich wie bei Menschen, die etwas Gefährliches essen und dann eine Katastrophe erleben. Wenn ich eine Meldung lese, dass jemand eine Nacktschnecke gegessen hat und an einem Gehirnparasiten gestorben ist, kann ich ziemlich sicher sein, nicht an genau dieser Ursache zu sterben
  Der Autor stellt sich vor, das liege daran, dass ich glaube, besser oder klüger zu sein als die verstorbene Person, aber der tatsächliche Gedankengang ist eher: „Ich bin zu 100 % sicher, dass ich selbst dann nicht freiwillig Nacktschnecken essen würde, wenn ich auf einer einsamen Insel voller saftiger Nacktschnecken verhungern würde, also tauchen durch Nacktschnecken übertragene Parasiten in meinem Risikomodell nicht auf“
  Auch dem Teil, dass „sie hätten es wissen müssen“ inkohärent sei, kann ich schwer zustimmen. Menschen wird ständig vorgeworfen, etwas nicht gewusst zu haben, und das gehört zum Erwachsensein dazu
  Wenn ein dreijähriges Kind eine Nacktschnecke gegessen hätte, würde ich es nicht tadeln, aber wenn ein 30-jähriger Kollege eine Nacktschnecke gegessen hätte, würde ich ihn selbstverständlich tadeln. Für offensichtlich dumme Handlungen darf man jemanden verantwortlich machen

  • Für die Frage, wie man jemanden dafür tadeln könne, „etwas nicht zu wissen“, gibt es bereits den Begriff vorsätzliche Unwissenheit
    Ich finde, der Artikel bringt einen guten Punkt vor, über den ich vorher nicht nachgedacht hatte, aber für mich hatte er auch einige klare Mängel, und das ist der erste
    Der zweite ist, dass ich mich beim Lesen über Amerikaner gefragt habe: „Ist dieses distancing through differencing, dieses Sich-absetzen-durch-Unterscheidung, wirklich dasselbe wie das, was ich tue, wenn ich AI-bedingte Löschvorfälle im Betrieb ignoriere?“
    Anders gesagt: Wenn man keinerlei Ahnung hat, wie die Gefahr in einer anderen Fabrik entstanden ist, und einfach abtut, dass so etwas einen selbst nicht treffen werde, dann ist das nicht gerechtfertigt
    Wenn man aber hört, dass ein Manager einen neuartigen, experimentellen und nichtdeterministischen humanoiden Roboter auf die Fabrikfläche gebracht hat, damit er frei dabei helfen kann, dass Facharbeiter schneller arbeiten, dann kann man dieses Wegwischen nicht im selben Licht sehen
    Trotzdem akzeptiere ich die Schlussfolgerung. Leichtsinn ist schließlich nichts Binäres
    Wenn ich das nächste Mal so eine absurde Geschichte höre, werde ich wohl kurz innehalten und denken: „Auch wenn ich nicht so nachlässig bin wie sie, was von dem, was ich tue, sollte ich vorsichtiger angehen und mit zusätzlichen Schutzmechanismen versehen?“
  • Ich würde nicht fragen, warum ein dreijähriges Kind eine Nacktschnecke gegessen hat
    Aber wenn ein 30-jähriger Kollege eine Nacktschnecke gegessen hätte, würde ich den Hergang gründlich untersuchen
    Wenn ich jemanden „beschuldigen“ wollte, würde ich zuerst fragen, warum wir überhaupt Menschen einstellen, die Nacktschnecken essen, und ob wir das immer noch tun
  • Das Wichtigste, das ich aus diesem Artikel mitnehme, ist, dass der Autor nicht weiß, was das bozo bit ist

• Es gibt ein paar berechtigte Punkte
  Bei „Ich möchte erklären, warum diese Reaktion kontraproduktiv ist. Und ich möchte den Fachbegriff für dieses mit dem Einschalten des bozo bit verwandte Phänomen benennen. Es heißt distancing through differencing“ ist diese Reaktion produktiv und zugleich kontraproduktiv
  Sie ist produktiv, weil es eine enorme Optimierung ist, in einer Welt, in der ohnehin schon mehr Vorfälle auf einen einprasseln, als man bewältigen kann, nicht jede einzelne Eingabe bewerten zu müssen
  Gleichzeitig ist sie aus den im Artikel genannten Gründen auch kontraproduktiv
  Der eigentliche Trick besteht darin, zu wissen, was man ernst nehmen und worauf man achten sollte. Wenn ich diesen Trick gelernt habe, sage ich Bescheid

• Was genau soll ich aus der Geschichte lernen, dass jemand einer AI direkten Zugang zur Produktionsumgebung gegeben hat?

  • Wenn man den LLM-Vorfall wohlwollend liest, kann man ihn als Lehre verstehen, dass Produktionszugriff Zugriffskontrolle haben sollte und destruktive Aktionen eine Vier-Augen-Freigabe brauchen
    Ich habe einmal in einer damals schnell wachsenden Firma gearbeitet, in der viele Engineering-Praktiken eher zu einem Garagen-Startup als zu einem multinationalen Konzern mit 1000 Mitarbeitern gepasst hätten
    Damals waren drei Dinge wahr. Erstens wurden Services bereitgestellt, indem man im Git-Checkout-Verzeichnis auf dem Laptop cd ausführte und dann <tool> deploy <service-name> aufrief; deployt wurde dabei genau der aktuell ausgecheckte Git-Commit
    Zweitens war die Zugriffskontrolle des Deployment-Systems wegen einer Kultur des Vertrauens in die Kollegen minimal. Es gab eine Allowlist für Deployments, und wer darauf stand, konnte jeden beliebigen Service deployen
    Drittens war das zentrale Git-Repository groß und das Büro-WLAN überlastet, sodass ein Klonen lange dauerte. Damit neue Mitarbeiter schneller loslegen konnten, enthielt das Laptop-Provisioning-Image bereits einen Git-Checkout des Haupt-Repositorys
    Eines Tages bekam das Datenbankteam einen neuen Praktikanten, und als er dem Wiki-Tutorial Database Team 101 folgte, führte er den empfohlenen Befehl <tool> deploy --prod <database> aus, um zu prüfen, ob seine Deployment-Rechte funktionierten
    Es stellte sich heraus, dass das Laptop-Provisioning-Image veraltet war und der Praktikant die Onboarding-Einheit zu git pull origin master noch nicht absolviert hatte
    Die Geschichte „ein LLM hat die Produktion kaputtgemacht“ und die Geschichte „ein Praktikant hat die Produktion kaputtgemacht“ sind ähnlich, aber aus Letzterer lässt sich leichter lernen. Die einzelnen Fehler sind kleiner

• Aus der Perspektive der Störungsanalyse ist das Setzen des bozo bit und das anschließende Nicht-Weiterlernen eine Form davon, bei einem einzelnen beitragenden Faktor stehenzubleiben — nämlich bei menschlichem Versagen! — obwohl man eigentlich den gesamten Fehlerbaum betrachten müsste
  In dem angeführten Beispiel aktiviert der Knoten im Fehlerbaum „hat einem LLM Produktionszugriff gegeben“ beim Leser die Heuristik „Idioten ignorieren“
  Der benachbarte Knoten „das System erlaubte unbestätigte Löschungen per API“ ist jedoch eine wertvolle Lehre, die man verpassen kann, wenn man beim ersten auffälligen Knoten stehenbleibt
  Außerdem sollte der Fehlerbaum auch die Kindknoten enthalten, die der Frage nachgehen, warum diese gefährliche Aktion in der GUI entfernt wurde, aber in der API verblieb, und warum das LLM überhaupt Produktionszugriff bekommen konnte

  • Andererseits kann man fragen, ob die Wahrscheinlichkeit geringer ist, aus Berichten aus bozo-Umfeldern einen sinnvollen Fehlerbaum zu rekonstruieren
    Auf der anderen Seite könnte die eigentliche Frage sein, ob es darin Knoten gibt, die unter bozo-Bedingungen umso heller leuchten
    Ob diese Knoten falsch identifiziert oder falsch verbunden sind, ist womöglich nicht besonders wichtig. Denn letztlich brauche ich keinen Fehlerbaum für ihre vergangenen Fehlschläge, sondern ich muss prüfen, was ich in meinem eigenen Fehlerbaum übersehe, um meine künftigen Fehlschläge zu verhindern

• Dieser Artikel überspringt auffällig den Teil, in dem erklärt werden müsste, warum es falsch ist, beim bozo des Kernbeispiels das bozo bit gesetzt zu haben
  Er springt stattdessen zu Beispielen aus Aufsätzen weiter und behandelt das Kernbeispiel des eigenen Textes nicht
  Dadurch wirkt es so, als wolle der Autor einen anderen bozo einfach durchwinken

• Ich habe etwas gelernt: AI-Tools nicht benutzen