Kapitel 1. ZeitgemäßesRisikomanagement durch maschinelles Lernen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Der Aufbau des besten maschinellen Lernsystems beginnt mit kulturellen Kompetenzen und Geschäftsprozessen. In diesem Kapitel werden zahlreiche kulturelle und verfahrenstechnische Ansätze vorgestellt, die wir nutzen können, um die ML-Leistung zu verbessern und die ML-Systeme unserer Unternehmen vor realen Sicherheits- und Leistungsproblemen zu schützen. Es enthält auch eine Fallstudie, die veranschaulicht, was passiert, wenn ein ML-System ohne angemessene menschliche Aufsicht eingesetzt wird. Das Hauptziel der in diesem Kapitel behandelten Ansätze ist es, bessere ML-Systeme zu schaffen. Das kann bedeuten, dass die Leistung von In-silico-Testdaten verbessert wird. In Wirklichkeit geht es aber darum, Modelle zu entwickeln, die nach dem Einsatz in vivo die erwartete Leistung erbringen, damit wir kein Geld verlieren, Menschen verletzen oder andere Schäden verursachen.

Hinweis

In vivo ist lateinisch für "unter den Lebenden". Wir werden diesen Begriff manchmal verwenden, um die Interaktion mit Lebenden zu beschreiben, z. B. wie ML-Modelle in der realen Welt funktionieren, wenn sie mit menschlichen Nutzern interagieren. In silico bedeutet "mit Hilfe von Computermodellen oder Computersimulationen", und wir verwenden diesen Begriff, um die Tests zu beschreiben, die Datenwissenschaftler/innen oft in ihren Entwicklungsumgebungen durchführen, bevor sie ML-Modelle einsetzen.

Das Kapitel beginnt mit einer Erörterung der aktuellen rechtlichen und behördlichen Rahmenbedingungen für KI und einigen sich abzeichnenden Leitlinien für bewährte Methoden, um Systementwickler über ihre grundlegenden Verpflichtungen in Bezug auf Sicherheit und Leistung zu informieren. Außerdem stellen wir in diesem Teil des Kapitels vor, wie sich das Buch am National Institute of Standards and Technology (NIST) AI Risk Management Framework (RMF) orientiert. Da diejenigen, die die Geschichte nicht studieren, sie zwangsläufig wiederholen werden, wird in diesem Kapitel auf KI-Vorfälle hingewiesen und erörtert, warum das Verständnis von KI-Vorfällen wichtig für die Sicherheit und Leistung von ML-Systemen ist. Da viele Sicherheitsaspekte von ML-Systemen über die technischen Spezifikationen hinausgehen, werden in diesem Kapitel Modellrisikomanagement (MRM), IT-Sicherheitsrichtlinien und Praktiken aus anderen Bereichen kombiniert, um zahlreiche Ideen zur Verbesserung der ML-Sicherheitskultur und -prozesse in Unternehmen vorzustellen. Das Kapitel schließt mit einer Fallstudie, in der es um Sicherheitskultur, rechtliche Konsequenzen und KI-Vorfälle geht.

Keiner der in diesem Kapitel besprochenen Ansätze zum Risikomanagement ist ein Allheilmittel. Wenn wir ein erfolgreiches Risikomanagement betreiben wollen, müssen wir aus der Vielzahl der verfügbaren Kontrollen diejenigen auswählen, die für unsere Organisation am besten geeignet sind. Größere Organisationen sind in der Regel in der Lage, mehr Risikomanagement zu betreiben als kleinere Organisationen. Leser/innen in großen Organisationen können möglicherweise viele Kontrollen in verschiedenen Abteilungen, Bereichen oder internen Funktionen durchführen. Leser/innen in kleineren Organisationen müssen ihre Risikomanagementmaßnahmen mit Bedacht wählen. Letztendlich hängt ein Großteil des Risikomanagements im Technologiebereich vom menschlichen Verhalten ab. Unabhängig davon, welche Risikokontrollen ein Unternehmen einführt, müssen diese mit strengen Regeln und Richtlinien für die Mitarbeiter, die ML-Systeme aufbauen und warten, einhergehen.

Bewährte Methoden

In der Datenwissenschaft gibt es heute kaum professionelle Standards und Lizenzen, aber es zeichnen sich erste verbindliche Richtlinien ab. Die ISO beginnt damit, technische Standards für KI festzulegen. Wenn wir sicherstellen, dass unsere Modelle mit den ISO-Normen übereinstimmen, wäre das eine Möglichkeit, einen unabhängigen Standard auf unsere ML-Arbeit anzuwenden. Vor allem für Datenwissenschaftler/innen in den USA ist das NIST AI RMF ein sehr wichtiges Projekt, das man im Auge behalten sollte.

Version 1 des KI-Rahmenwerks wurde im Januar 2023 veröffentlicht. Das Rahmenwerk stellt die Merkmale der Vertrauenswürdigkeit von KI-Systemen vor: Validität, Zuverlässigkeit, Sicherheit, Widerstandsfähigkeit, Transparenz, Rechenschaftspflicht, Erklärbarkeit, Interpretierbarkeit, Bias-Management und verbesserter Datenschutz. Anschließend werden Handlungsempfehlungen für vier organisatorische Funktionen - Planen, Messen, Verwalten und Regeln - vorgestellt, um Vertrauenswürdigkeit zu erreichen. Die Anleitungen für die Funktionen Abbilden, Messen, Verwalten und Leiten sind in detailliertere Kategorien und Unterkategorien unterteilt. Diese Kategorien von Anleitungen findest du in der RMF oder im AI RMF Playbook, das noch detailliertereVorschläge enthält.

Hinweis

Das NIST AI Risk Management Framework ist ein freiwilliges Instrument zur Verbesserung der Vertrauenswürdigkeit von KI- und ML-Systemen. Das AI RMF ist keine Vorschrift und das NIST ist keine Regulierungsbehörde.

Um unserem eigenen Rat und dem von Regulierungsbehörden und Herausgebern verbindlicher Leitlinien zu folgen und dieses Buch nützlicher zu machen, werden wir in jedem Kapitel in Teil I darauf hinweisen, wie der Inhalt unserer Meinung nach mit dem AI RMF übereinstimmt. Im Anschluss an diesen Absatz finden die Leser/innen einen Kasten, in dem die Unterüberschriften der Kapitel den Unterkategorien der AI RMF zugeordnet sind. Anhand der Tabelle können die Leser/innen nachvollziehen, wie die in den einzelnen Kapiteln behandelten Ansätze ihnen dabei helfen können, die RMF der AI einzuhalten. Da die Ratschläge zu den Unterkategorien für ML-Praktiker in manchen Fällen abstrakt klingen, haben wir die RMF-Kategorien in eine praxisorientiertere Sprache übertragen, die bei der Umsetzung der RMF in der Praxis hilfreich ist. In der Callout-Box kannst du nachlesen, wie wir Kapitel 1 mit der RMF für KI in Einklang bringen, und du findest ähnliche Tabellen am Anfang jedes Kapitels in Teil I.

AI-Vorfälle

In vielerlei Hinsicht besteht das grundlegende Ziel der ML-Sicherheitsprozesse und des damit verbundenen Modell-Debugging, das auch in Kapitel 3 behandelt wird, darin, KI-Vorfälle zu verhindern und zu entschärfen. Hier definieren wir KI-Vorfälle locker als jedes Ergebnis des Systems, das Schaden verursachen könnte. Wie die Hand-Regel zeigt, erhöht sich der Schweregrad eines KI-Vorfalls durch den Schaden, den der Vorfall verursacht, und verringert sich durch die Sorgfalt, die die Betreiber zur Schadensbegrenzung aufbringen.

Da komplexe Systeme zum Scheitern neigen, mangelt es nicht an KI-Vorfällen, die als Beispiele dienen können. KI-Vorfälle können von lästig bis tödlich reichen - von Sicherheitsrobotern in Einkaufszentren, die eine Treppe hinunterfallen, über selbstfahrende Autos, die Fußgänger töten, bis hin zur massenhaften Umleitung von Gesundheitsressourcen von denen, die sie am dringendsten brauchen. Wie in Abbildung 1-2 dargestellt, lassen sich KI-Vorfälle grob in drei Kategorien einteilen:

Missbräuche

Neben gezielten Hacks und Angriffen auf andere KI-Systeme kann KI auch für ruchlose Zwecke eingesetzt werden. Der Tag könnte bereits gekommen sein, an dem Hacker KI nutzen, um die Effizienz und Schlagkraft ihrer allgemeineren Angriffe zu erhöhen. Was die Zukunft bringen könnte, ist sogar noch beängstigender. Schreckgespenster wie autonome Drohnenangriffe und ethnisches Profiling durch autoritäre Regime sind bereits am Horizont zu erkennen.

Angriffe

Beispiele für alle wichtigen Angriffsarten - Vertraulichkeits-, Integritäts- und Verfügbarkeitsangriffe (siehe Kapitel 5 für weitere Informationen) - sind von Forschern veröffentlicht worden. Bei Angriffen auf die Vertraulichkeit werden Trainingsdaten oder Modelllogik von den Endpunkten des KI-Systems entwendet. Angriffe auf die Integrität umfassen die Manipulation von Trainingsdaten oder Modellergebnissen durch gegnerische Beispiele, Umgehung, Impersonation oder Poisoning. Verfügbarkeitsangriffe können durch standardmäßige Denial-of-Service-Ansätze, durch Schwammbeispiele, die die Systemressourcen übermäßig beanspruchen, oder durch algorithmische Diskriminierung erfolgen, die von einem Angreifer veranlasst wird, um bestimmten Gruppen von Nutzern die Systemdienste zu verweigern.

Versäumnisse

Bei Fehlern in KI-Systemen handelt es sich in der Regel um algorithmische Diskriminierung, Sicherheits- und Leistungsmängel, Verletzungen des Datenschutzes, unzureichende Transparenz oder Probleme mit Systemkomponenten Dritter.

KI-Vorfälle sind eine Realität. Und wie die Systeme, aus denen sie entstehen, können auch KI-Vorfälle komplex sein. KI-Vorfälle haben mehrere Ursachen: Versagen, Angriffe und Missbrauch. Außerdem vermischen sie traditionelle Vorstellungen von Computersicherheit mit Anliegen wie Datenschutz und algorithmischer Diskriminierung.

mlha 0102
Abbildung 1-2. Eine grundlegende Taxonomie von KI-Vorfällen (angepasst an "What to Do When AI Fails")

Der Vorfall mit dem Chatbot Tay im Jahr 2016 ist ein aufschlussreiches Beispiel. Tay war ein hochmoderner Chatbot, der von einigen der weltweit führenden Experten bei Microsoft Research trainiert wurde, um mit Menschen auf Twitter zu interagieren und das Bewusstsein für KI zu schärfen. Sechzehn Stunden nach seiner Veröffentlichung - und 96.000 Tweets später - hatte sich Tay als Neonazi-Pornograf ausgegeben und musste abgeschaltet werden. Was war passiert? Twitter-Nutzer lernten schnell, dass Tays lernfähiges System leicht vergiftet werden kann. Rassistische und sexuelle Inhalte, die an den Bot getwittert wurden, flossen in seine Trainingsdaten ein und führten ebenso schnell zu anstößigen Ergebnissen. Data Poisoning ist ein Angriff auf die Integrität, aber aufgrund des Kontextes, in dem er durchgeführt wurde, führte dieser Angriff zu einer algorithmischen Diskriminierung. Es ist auch wichtig zu erwähnen, dass die Entwickler von Tay als Weltklasse-Experten in einem extrem gut finanzierten Forschungszentrum anscheinend einige Sicherheitsvorkehrungen getroffen haben. Tay hat auf bestimmte brisante Themen mit vorgefertigten Antworten reagiert. Doch das reichte nicht aus und Tay entwickelte sich zu einem Fall von öffentlicher Sicherheit und algorithmischer Diskriminierung für Microsoft Research.

Du denkst, das war ein einmaliger Vorfall? Falsch gedacht. Erst kürzlich wiederholten sich aufgrund des Hypes und des Versäumnisses, die Risiken in Bezug auf Leistung, Sicherheit und Datenschutz systematisch zu durchdenken, viele der offensichtlichsten Fehler von Tay bei der Veröffentlichung des Chatbots Lee Luda von Scatter Lab. Bei der Entwicklung von ML-Systemen sollten die Pläne mit bekannten Vorfällen in der Vergangenheit verglichen werden, in der Hoffnung, ähnliche Vorfälle in Zukunft zu verhindern. Genau darum geht es bei den jüngsten Bemühungen um eine Datenbank für KI-Vorfälle und den damit verbundenen Veröffentlichungen.

KI-Vorfälle können auch ein unpolitischer Motivator für eine verantwortungsvolle Technologieentwicklung sein. Kulturelle und politische Standpunkte zu Themen wie algorithmischer Diskriminierung und Datenschutz können sehr unterschiedlich sein - im Guten wie im Schlechten. Es kann sehr schwierig sein, ein Team dazu zu bringen, sich auf ethische Überlegungen zu einigen. Es ist vielleicht einfacher, sie dazu zu bringen, peinliche und potenziell kostspielige oder gefährliche Zwischenfälle zu vermeiden, was ein grundlegendes Ziel jedes ernsthaften Data Science Teams sein sollte. Der Begriff "KI-Vorfälle" ist für das Verständnis von ML-Sicherheit von zentraler Bedeutung. Ein zentrales Thema dieses Kapitels sind kulturelle Kompetenzen und Geschäftsprozesse, mit denen KI-Vorfälle verhindert und entschärft werden können. In den nächsten Abschnitten werden wir uns mit diesen Maßnahmen befassen und zum Abschluss des Kapitels einen echten Vorfall untersuchen.

Kulturelle Kompetenzen für dasRisikomanagement beim maschinellenLernen

Die Kultur einer Organisation ist ein wesentlicher Aspekt der verantwortungsvollen KI. In diesem Abschnitt geht es um kulturelle Kompetenzen wie Verantwortlichkeit, das Trinken unseres eigenen Champagners, Fachwissen und das altbekannte Sprichwort "schnell handeln und Dinge kaputt machen".

Organisatorische Verantwortlichkeit

Ein Schlüssel zur erfolgreichen Minderung von ML-Risiken ist eine echte Rechenschaftspflicht für KI-Vorfälle in Unternehmen. Wenn niemandes Job auf dem Spiel steht, wenn ein ML-System fehlschlägt, angegriffen oder für schändliche Zwecke missbraucht wird, dann ist es gut möglich, dass sich niemand in der Organisation wirklich um die Sicherheit und Leistung von ML kümmert. Neben Entwicklern, die Risiken durchdenken, Software-Qualitätssicherungstechniken (QS) anwenden und Debugging-Methoden modellieren, brauchen Unternehmen Personen oder Teams, die ML-Systemtechnologien validieren und die damit verbundenen Prozesse prüfen. Unternehmen brauchen auch jemanden, der für die Reaktionspläne auf KI-Vorfälle verantwortlich ist. Aus diesem Grund wenden führende Finanzinstitute, deren Einsatz von prädiktiven Modellen seit Jahrzehnten reguliert ist, ein Verfahren an, das als Modellrisikomanagement bekannt ist. Das MRM orientiert sich an den SR 11-7 Modellrisikomanagement-Richtlinien der Federal Reserve, die aus der Finanzkrise von 2008 hervorgegangen sind. An der Umsetzung von MRM sind häufig verantwortliche Führungskräfte und mehrere Teams beteiligt, die für die Sicherheit und Leistung von Modellen und ML-Systemen verantwortlich sind.

Die Umsetzung von MRM-Standards erfordert in der Regel mehrere verschiedene Teams und eine Führungsrolle. Dies sind einige der wichtigsten Grundsätze, die das kulturelle Rückgrat für MRM bilden:

Schriftliche Richtlinien und Verfahren

Die organisatorischen Regeln für die Erstellung und Nutzung von ML sollten schriftlich festgehalten werden und für alle Beteiligten im Unternehmen verfügbar sein. Diejenigen, die mit ML-Systemen zu tun haben, sollten an Schulungen zu den Richtlinien und Verfahren teilnehmen. Diese Regeln sollten auch überprüft werden, um zu verstehen, wann sie aktualisiert werden müssen. Niemand sollte sich darauf berufen können, dass er die Regeln nicht kennt, die Regeln sollten transparent sein und die Regeln sollten nicht ohne Zustimmung geändert werden. Die Richtlinien und Verfahren sollten klare Mechanismen enthalten, um ernsthafte Risiken oder Probleme an die Unternehmensleitung zu eskalieren, und sie sollten wahrscheinlich Verfahren und Schutzmaßnahmen für Whistleblower vorsehen.

Effektive Herausforderung

Eine wirksame Anfechtung setzt voraus, dass Experten mit der Fähigkeit, ein System zu ändern, die das angefochtene ML-System nicht gebaut haben, die Validierung und Prüfung durchführen. In der MRM-Praxis werden wirksame Anfechtungen in der Regel auf drei "Verteidigungslinien" verteilt, wobei gewissenhafte Systementwickler die erste Verteidigungslinie bilden und unabhängige, qualifizierte und befähigte technische Validierer und Prozessauditoren die zweite bzw. dritte Linie bilden.

Verantwortungsvolle Führung

Eine bestimmte Führungskraft innerhalb eines Unternehmens sollte dafür verantwortlich sein, dass es nicht zu KI-Vorfällen kommt. Diese Position wird oft als Chief Model Risk Officer (CMRO) bezeichnet. Es ist auch nicht unüblich, dass die Beschäftigungsbedingungen und die Vergütung des CMRO an die Leistung des ML-Systems gekoppelt sind. Die Rolle des CMRO bietet eine sehr einfache kulturelle Kontrolle der ML-Sicherheit und -Leistung. Wenn sich unser Chef wirklich für die Sicherheit und Leistung des ML-Systems interessiert, fangen auch wir an, uns dafür zu interessieren.

Anreize

Data Science-Mitarbeiter und das Management müssen Anreize erhalten, ML verantwortungsvoll einzusetzen. Komprimierte Zeitpläne für Produkte können dazu führen, dass zuerst ein minimales lebensfähiges Produkt erstellt wird, während strenge Tests und Korrekturen erst am Ende des Lebenszyklus des Modells und unmittelbar vor dem Einsatz in der Produktion durchgeführt werden. Darüber hinaus werden ML-Test- und -Validierungsteams oft nach denselben Kriterien bewertet wie ML-Entwicklungsteams, was zu einer grundlegenden Fehlanpassung führt, bei der Tester und Validierer dazu ermutigt werden, schnell zu arbeiten, anstatt die Qualität zu sichern. Die Anpassung des Zeitplans, der Leistungsbewertung und der Gehaltsanreize an die Funktion des Teams trägt dazu bei, eine Kultur der verantwortungsvollen ML und Risikominderung zu festigen.

Natürlich können kleine oder junge Unternehmen vielleicht nicht einen ganzen Vollzeitmitarbeiter für die Überwachung der Risiken von ML-Systemen abstellen. Aber es ist wichtig, dass eine Person oder Gruppe zur Rechenschaft gezogen wird, wenn ML-Systeme Zwischenfälle verursachen, und dass sie belohnt wird, wenn die Systeme gut funktionieren. Wenn ein Unternehmen davon ausgeht, dass jeder für ML-Risiken und KI-Vorfälle verantwortlich ist, ist in Wirklichkeit niemand verantwortlich.

Kultur der effektiven Herausforderung

Unabhängig davon, ob unsere Organisation bereit ist, MRM-Praktiken in vollem Umfang einzuführen oder nicht, können wir dennoch von bestimmten Aspekten des MRM profitieren. Vor allem die kulturelle Kompetenz des effektiven Hinterfragens kann auch außerhalb des MRM-Kontextes angewendet werden. Im Kern bedeutet effektives Hinterfragen, dass die Schritte, die bei der Entwicklung von ML-Systemen unternommen werden, aktiv in Frage gestellt werden. Eine Organisationskultur, die das ernsthafte Hinterfragen von ML-Systemen fördert, wird mit größerer Wahrscheinlichkeit effektive ML-Systeme oder -Produkte entwickeln und Probleme erkennen, bevor sie sich zu schädlichen Vorfällen ausweiten. Eine wirksame Infragestellung darf nicht missbräuchlich sein und muss für alle Mitarbeiter gelten, die ein ML-System entwickeln, insbesondere für sogenannte "Rockstar"-Ingenieure undDatenwissenschaftler. Effektives Hinterfragen sollte auch strukturiert sein, z. B. in Form von wöchentlichen Meetings, in denen das aktuelle Designdenken hinterfragt und alternative Designentscheidungen ernsthaft in Betracht gezogen werden.

Vielfältige und erfahrene Teams

Vielfältige Teams können bei der Gestaltung, Entwicklung und Prüfung von ML-Systemen breitere und bisher unverbundene Perspektiven einbringen. Bei Teams ohne Vielfalt ist das oft nicht der Fall. Viele haben die unglücklichen Ergebnisse dokumentiert, die entstehen können, wenn Datenwissenschaftler/innen die demografische Vielfalt beim Training oder den Ergebnissen von ML-Systemen nicht berücksichtigen. Eine mögliche Lösung für diese Art von Versäumnissen besteht darin, die demografische Vielfalt in ML-Teams zu erhöhen, statt sie zu vernachlässigen. Bei der Zusammenstellung von Teams ist auch die Erfahrung in der Wirtschaft oder anderen Bereichen wichtig. Fachexperten spielen eine wichtige Rolle bei der Auswahl und Entwicklung von Merkmalen und beim Testen der Systemergebnisse. In der Hektik, mit der ML-Systeme entwickelt werden, kann die Beteiligung von Fachleuten auch als Sicherheitscheck dienen. Generalistischen Datenwissenschaftlern fehlt oft die nötige Erfahrung, um mit domänenspezifischen Daten und Ergebnissen umzugehen. Die Bedeutung von Eingabedaten oder Ausgabeergebnissen falsch zu verstehen, ist ein Rezept für eine Katastrophe, die zu KI-Vorfällen führen kann, wenn ein System eingesetzt wird. Wenn es darum geht, dass Datenwissenschaftler/innen die Bedeutung von Fachwissen vergessen oder ignorieren, verdienen die Sozialwissenschaften leider eine besondere Aufmerksamkeit. In einem Trend, der als "stille Kolonisierung der Sozialwissenschaften durch die Technik" bezeichnet wird, haben mehrere Organisationen bedauerliche ML-Projekte verfolgt, die versuchen, Entscheidungen zu ersetzen, die eigentlich von ausgebildeten Sozialwissenschaftlern getroffen werden sollten, oder die die kollektive Weisheit der sozialwissenschaftlichen Fachkenntnisse ganz einfach ignorieren.

Unseren eigenen Champagner trinken

Auch bekannt als "unser eigenes Hundefutter essen", bezieht sich die Praxis, unseren eigenen Champagner zu trinken, auf die Verwendung unserer eigenen Software oder Produkte innerhalb unserer eigenen Organisation. Oft handelt es sich dabei um eine Form von Pre-Alpha- oder Pre-Beta-Tests. Durch das Trinken unseres eigenen Champagners können Probleme erkannt werden, die sich aus der Komplexität von In-Vivo-Einsatzumgebungen ergeben, bevor Fehler und Ausfälle Kunden, Nutzer oder die Öffentlichkeit beeinträchtigen. Da schwerwiegende Probleme wie Konzeptdrift, algorithmische Diskriminierung, Lernen mit Abkürzungen und Unterspezifikation mit den üblichen ML-Entwicklungsprozessen nur schwer zu erkennen sind, bietet das Trinken unseres eigenen Champagners ein begrenztes und kontrolliertes, aber auch realistisches Testfeld für ML-Systeme. Wenn Unternehmen demografisch und fachlich heterogene Teams beschäftigen und Experten aus dem Bereich, in dem das ML-System eingesetzt werden soll, einbeziehen, ist es natürlich wahrscheinlicher, dass wir mit unserem eigenen Champagner eine Vielzahl von Problemen aufdecken. Unseren eigenen Champagner zu trinken, bringt auch die klassische Goldene Regel in die KI. Wenn wir uns nicht wohl dabei fühlen, ein System bei uns selbst oder in unserer eigenen Organisation einzusetzen, dann sollten wir das System wahrscheinlich nicht verwenden.

Hinweis

Ein wichtiger Aspekt, der bei der Entwicklung von Einsatzgebieten berücksichtigt werden muss, sind die Auswirkungen unserer ML-Systeme auf die Ökosysteme und den Planeten - zum Beispiel:

  • Der Kohlenstoff-Fußabdruck von ML-Modellen

  • Die Möglichkeit, dass ein ML-System die Umwelt schädigt, indem es einen KI-Vorfall verursacht

Wenn wir uns Sorgen um die Auswirkungen unseres Modells auf die Umwelt machen, sollten wir die ML-Governance mit den umfassenderen Umwelt-, Sozial- und Governance-Bemühungen unserer Organisation verknüpfen.

Sich schnell bewegen und Dinge kaputt machen

Das Mantra "schnell sein und Dinge kaputt machen" ist für viele "Rockstar"-Ingenieure und Datenwissenschaftler fast schon eine religiöse Überzeugung. Leider scheinen diese Top-Praktiker auch zu vergessen, dass Dinge kaputt gehen, wenn sie schnell gehen und Dinge kaputt machen. Da ML-Systeme immer mehr wichtige Entscheidungen treffen, die autonome Fahrzeuge, Kreditvergabe, Beschäftigung, Universitätsnoten und -besuche, medizinische Diagnosen und Ressourcenverteilung, Hypotheken, Kautionszahlungen, Bewährung und vieles mehr betreffen, bedeutet "etwas kaputt machen" mehr als fehlerhafte Apps. Es kann bedeuten, dass eine kleine Gruppe von Datenwissenschaftlern und -ingenieuren vielen Menschen in großem Umfang echten Schaden zufügt. Die Beteiligung an der Entwicklung und Umsetzung von ML-Systemen mit großer Wirkung erfordert ein Umdenken, um ungeheuerliche Leistungs- und Sicherheitsprobleme zu verhindern. Praktikerinnen und Praktiker müssen ihre Prioritäten nicht mehr auf die Anzahl der Softwarefunktionen oder die Genauigkeit der Testdaten eines ML-Modells legen, sondern auf die Auswirkungen und die nachgelagerten Risiken ihrer Arbeit.

Organisatorische Abläufe für dasRisikomanagement beim maschinellenLernen

Organisatorische Prozesse spielen eine Schlüsselrolle, wenn es darum geht, dass ML-Systeme sicher und leistungsfähig sind. Wie die kulturellen Kompetenzen, die im vorigen Abschnitt besprochen wurden, sind auch die organisatorischen Prozesse eine wichtige nichttechnische Determinante für die Zuverlässigkeit von ML-Systemen. Dieser Abschnitt über Prozesse beginnt mit der Aufforderung an die Praktiker/innen, alle bekannten oder vorhersehbaren Fehlermöglichkeiten ihrer ML-Systeme zu berücksichtigen, zu dokumentieren und zu versuchen, sie zu entschärfen. Anschließend gehen wir näher auf MRM ein. Während sich der Abschnitt "Kulturelle Kompetenzen für dasRisikomanagementbeim maschinellenLernen" auf die Menschen und die Denkweise konzentrierte, die für den Erfolg von MRM notwendig sind, werden in diesem Abschnitt die verschiedenen Prozesse beschrieben, die MRM einsetzt, um Risiken in fortgeschrittenen prädiktiven Modellierungs- und ML-Systemen zu minimieren. MRM ist zwar ein erstrebenswerter Prozessstandard, aber es gibt noch weitere wichtige Prozesskontrollen, die normalerweise nicht zum MRM gehören. In diesem Abschnitt werfen wir einen Blick über das traditionelle MRM hinaus und beleuchten wichtige Risikokontrollprozesse wie die Paar- oder Doppelprogrammierung und die Anforderungen an die Sicherheitsgenehmigung für die Codebereitstellung. Dieser Abschnitt schließt mit einer Diskussion über die Reaktion auf KI-Vorfälle. Egal, wie sehr wir uns bei der Entwicklung und Implementierung eines ML-Systems um Schadensminimierung bemühen, wir müssen uns dennoch auf Ausfälle und Angriffe vorbereiten.

Vorhersage von Ausfallmodi

ML-Sicherheits- und Ethikexperten sind sich weitgehend einig, dass es wichtig ist, vorhersehbare Fehlermöglichkeiten von ML-Systemen zu durchdenken, zu dokumentieren und zu versuchen, sie zu entschärfen. Leider sind sie sich auch größtenteils einig, dass dies keine triviale Aufgabe ist. Glücklicherweise sind in den letzten Jahren neue Ressourcen und wissenschaftliche Erkenntnisse zu diesem Thema entstanden, die den Entwicklern von ML-Systemen helfen können, Vorfälle systematischer vorherzusagen. Wenn ganzheitliche Kategorien potenzieller Ausfälle identifiziert werden können, wird die Härtung von ML-Systemen für eine bessere Leistung und Sicherheit in der realen Welt zu einer proaktiven und effizienten Aufgabe. In diesem Unterabschnitt werden wir eine solche Strategie sowie einige weitere Verfahren zur Vorhersage zukünftiger Vorfälle in ML-Systemen vorstellen.

Bekannte Misserfolge in der Vergangenheit

Wie in "Verhinderung von wiederholten KI-Fehlern in der realen Welt durch Katalogisierung von Vorfällen" beschrieben : Die KI-Zwischenfalldatenbank" beschrieben, besteht eine der effizientesten Möglichkeiten, potenzielle KI-Zwischenfälle in unseren ML-Systemen zu vermeiden, darin, unser Systemdesign mit früheren fehlgeschlagenen Designs zu vergleichen. Ähnlich wie Verkehrsexperten, die Vorfälle untersuchen und katalogisieren, um dann die Ergebnisse zu nutzen, um ähnliche Vorfälle zu verhindern und neue Technologien zu testen, haben mehrere ML-Forscher, Kommentatoren und Handelsorganisationen damit begonnen, KI-Vorfälle zu sammeln und zu analysieren, in der Hoffnung, wiederholte und ähnliche Ausfälle zu verhindern. Die wohl bekannteste und ausgereifteste Datenbank für KI-Vorfälle ist die AI Incident Database. Diese durchsuchbare und interaktive Ressource ermöglicht es registrierten Nutzern, eine visuelle Datenbank mit Schlüsselwörtern zu durchsuchen und verschiedene Arten von Informationen über öffentlich aufgezeichnete Vorfälle zu finden.

Ziehe diese Ressource bei der Entwicklung von ML-Systemen zu Rate. Wenn ein System, das dem System ähnelt, das wir gerade entwickeln, implementieren oder einsetzen, in der Vergangenheit einen Vorfall verursacht hat, ist dies einer der stärksten Indikatoren dafür, dass unser neues System einen Vorfall verursachen könnte. Wenn wir in der Datenbank etwas sehen, das uns bekannt vorkommt, sollten wir innehalten und genauer darüber nachdenken, was wir tun.

Versagen der Vorstellungskraft

Sich die Zukunft mit Kontext und Details vorzustellen, ist nie einfach. Und oft ist es der Kontext, in dem ML-Systeme arbeiten, zusammen mit unvorhergesehenen oder unwissenden Details, die zu KI-Vorfällen führen. In einem kürzlich veröffentlichten Workshop-Papier mit dem Titel "Overcoming Failures of Imagination in AI Infused System Development and Deployment" (Überwindung von Vorstellungsfehlern bei der Entwicklung und dem Einsatz von KI-Systemen) stellen die Autoren einige strukturierte Ansätze vor, um Hypothesen über diese schwer vorstellbaren zukünftigen Risiken aufzustellen. Neben den Überlegungen, wer (z. B. Investoren, Kunden, gefährdete Nichtnutzer), was (z. B. Wohlbefinden, Chancen, Würde), wann (z. B. sofort, häufig, über lange Zeiträume) und wie (z. B. Handeln, Ändern von Überzeugungen) von KI-Vorfällen betroffen ist, fordern sie die Systementwickler/innen auch auf, Folgendes zu berücksichtigen:

  • Annahmen, dass die Auswirkungen des Systems nur vorteilhaft sind (und zugeben, wenn Unsicherheiten bei den Auswirkungen des Systems bestehen)

  • Der Problembereich und die angewandten Anwendungsfälle des Systems, im Gegensatz zu den mathematischen und technischen Aspekten

  • Alle unerwarteten oder überraschenden Ergebnisse, Benutzerinteraktionen und Reaktionen auf das System

Die Verursachung von KI-Vorfällen ist für Unternehmen peinlich, wenn nicht sogar kostspielig oder illegal. KI-Vorfälle können auch den Verbrauchern und der allgemeinen Öffentlichkeit schaden. Doch mit etwas Weitsicht hätten viele der derzeit bekannten KI-Vorfälle gemildert, wenn nicht sogar ganz vermieden werden können. Es ist auch möglich, dass wir bei der sorgfältigen Untersuchung und Konzeption von KI-Fehlern feststellen, dass unser Design oder System komplett überarbeitet werden muss. In diesem Fall ist eine Verzögerung der Systemimplementierung oder -einführung wahrscheinlich weniger kostspielig als der Schaden, der unserem Unternehmen oder der Öffentlichkeit entstehen könnte, wenn das fehlerhafte System veröffentlicht wird.

Risikomanagement-Prozesse modellieren

Die Prozessaspekte des MRM erfordern eine gründliche Dokumentation der Modellierungssysteme, eine menschliche Überprüfung der Systeme und eine laufende Überwachung der Systeme. Diese Prozesse machen den größten Teil des Verwaltungsaufwands für die SR 11-7 MRM-Richtlinie der Federal Reserve aus, die von der Federal Reserve und dem Office of the Comptroller of the Currency für prädiktive Modelle, die in wesentlichen Anwendungen der Verbraucherfinanzierung eingesetzt werden, beaufsichtigt wird. Auch wenn nur große Unternehmen in der Lage sein werden, alle Möglichkeiten des MRM voll auszuschöpfen, kann jeder ernsthafte ML-Praktiker etwas von dieser Disziplin lernen. Im folgenden Abschnitt werden die MRM-Prozesse in kleinere Komponenten unterteilt, damit die Leser/innen über die Anwendung von MRM-Aspekten in ihrem Unternehmen nachdenken können.

Risikoeinstufung

Wie zu Beginn dieses Kapitels beschrieben, ist das Produkt aus der Wahrscheinlichkeit, dass ein Schaden eintritt, und dem wahrscheinlichen Verlust, der daraus resultiert, eine anerkannte Methode, um das Risiko eines bestimmten ML-Systems zu bewerten. Das Produkt aus Risiko und Verlust hat im Kontext des MRM einen formelleren Namen: Materialität. Wesentlichkeit ist ein leistungsfähiges Konzept, das es Unternehmen ermöglicht, ML-Systemen realistische Risikostufen zuzuweisen. Noch wichtiger ist, dass diese Risikoeinstufung eine effiziente Zuweisung der begrenzten Entwicklungs-, Validierungs- und Prüfungsressourcen ermöglicht. Natürlich sollten die Anwendungen mit dem höchsten Risikograd die größte menschliche Aufmerksamkeit und Prüfung erhalten, während die Anwendungen mit dem niedrigsten Risikograd möglicherweise von automatischen maschinellen Lernsystemen (AutoML) bearbeitet und nur einer minimalen Prüfung unterzogen werden können. Da die Risikominderung für ML-Systeme eine fortlaufende, kostspielige Aufgabe ist, ist die richtige Aufteilung der Ressourcen zwischen Systemen mit hohem, mittlerem und niedrigem Risiko ein Muss für eine effektive Steuerung.

Modell-Dokumentation

Die MRM-Standards verlangen auch, dass die Systeme gründlich dokumentiert werden. Erstens sollte die Dokumentation die Rechenschaftspflicht der Systembeteiligten, die laufende Systemwartung und eine gewisse Reaktion auf Vorfälle ermöglichen. Zweitens muss die Dokumentation systemübergreifend standardisiert sein, um möglichst effiziente Audit- und Überprüfungsprozesse zu ermöglichen. Die Dokumentation ist der Dreh- und Angelpunkt für die Einhaltung der Vorschriften. Dokumentationsvorlagen, die in der folgenden Liste auf sehr hohem Niveau dargestellt werden, sind Dokumente, die Datenwissenschaftler und Ingenieure ausfüllen, wenn sie einen standardisierten Arbeitsablauf durchlaufen oder in den späteren Phasen der Modellentwicklung. Dokumentationsvorlagen sollten alle Schritte enthalten, die ein verantwortlicher Praktiker durchführen sollte, um ein solides Modell zu erstellen. Wenn Teile des Dokuments nicht ausgefüllt sind, deutet das auf Schlamperei im Ausbildungsprozess hin. Da die meisten Dokumentationsvorlagen und -rahmen auch verlangen, dass der Name und die Kontaktdaten in das fertige Modelldokument eingefügt werden, sollte es kein Geheimnis sein, wer seine Aufgaben nicht erfüllt. Die folgende Liste der Abschnitte ist eine grobe Kombination aus typischen Abschnitten in der MRM-Dokumentation und den Abschnitten, die in den Anhängen des EU-Gesetzes über künstliche Intelligenz empfohlen werden:

  • Grundlegende Informationen

    • Namen von Entwicklern und Interessenvertretern

    • Aktuelles Datum und Revisionstabelle

    • Zusammenfassung des Modellsystems

    • Business oder Wert Rechtfertigung

    • Verwendungszwecke und Nutzer

    • Mögliche Schäden und ethische Erwägungen

  • Informationen zu Entwicklungsdaten

    • Quelle für Entwicklungsdaten

    • Datenwörterbuch

    • Datenschutz-Folgenabschätzung

    • Annahmen und Beschränkungen

    • Software-Implementierung für die Datenvorverarbeitung

  • Modell Informationen

    • Beschreibung des Trainingsalgorithmus mit Peer-Reviewed-Referenzen

    • Spezifikation des Modells

    • Leistung Qualität

    • Annahmen und Beschränkungen

    • Software-Implementierung für Trainingsalgorithmus

  • Informationen zur Prüfung

    • Qualitätsprüfung und -sanierung

    • Diskriminierungstests und Abhilfemaßnahmen

    • Sicherheitsprüfung und Behebung von Mängeln

    • Annahmen und Beschränkungen

    • Software-Implementierung für Tests

  • Informationen zum Einsatz

    • Pläne und Mechanismen zur Überwachung

    • Vorgelagerte und nachgelagerte Abhängigkeiten

    • Pläne und Mechanismen für Einsprüche und Aufhebungen

    • Audit-Pläne und -Mechanismen

    • Pläne für das Änderungsmanagement

    • Pläne für die Reaktion auf Vorfälle

  • Referenzen (wenn wir Wissenschaft betreiben, dann bauen wir auf den Schultern von Giganten und haben mehrere von Experten begutachtete Referenzen in einem formatierten Literaturverzeichnis!)

Natürlich können diese Dokumente Hunderte von Seiten lang sein, vor allem bei Systemen mit hoher Materialität. Die vorgeschlagenen Standards für Datenblätter und Modellkarten können auch für kleinere oder jüngere Organisationen hilfreich sein, um diese Ziele zu erreichen. Wenn die Leser/innen das Gefühl haben, dass eine lange Modelldokumentation für ihre Organisation heute unmöglich ist, dann könnten vielleicht diese beiden einfacheren Rahmenwerke die Lösung sein.

Modellüberwachung

Ein Grundprinzip der ML-Sicherheit ist, dass die Leistung von ML-Systemen in der realen Welt schwer vorherzusagen ist und daher überwacht werden muss. Daher sollte die Leistung des Systems im Einsatz häufig und bis zur Außerbetriebnahme überwacht werden. Die Systeme können auf eine Vielzahl problematischer Bedingungen überwacht werden, wobei die häufigste die Eingabeabweichung ist. Während die Trainingsdaten von ML-Systemen Informationen über die Betriebsumgebung eines Systems in einer statischen Momentaufnahme kodieren, ist die Welt alles andere als statisch. Konkurrenten können in den Markt eintreten, neue Vorschriften können erlassen werden, der Geschmack der Verbraucher kann sich ändern und Pandemien oder andere Katastrophen können auftreten. All dies kann dazu führen, dass sich die Live-Daten, die in unser ML-System einfließen, von den Merkmalen der Trainingsdaten unterscheiden, was zu einer verminderten oder sogar gefährlichen Systemleistung führt. Um solche unangenehmen Überraschungen zu vermeiden, werden die besten ML-Systeme sowohl auf abdriftende Eingangs- und Ausgangsverteilungen als auch auf abnehmende Qualität, auch bekannt als model decay, überwacht. Während die Qualität der Leistung die häufigste zu überwachende Größe ist, können ML-Systeme auch auf anomale Eingaben oder Vorhersagen, spezifische Angriffe und Hacks sowie auf abweichende Fairnessmerkmale überwacht werden.

Modell-Inventare

Jedes Unternehmen, das ML einsetzt, sollte in der Lage sein, einfache Fragen wie diese zu beantworten:

  • Wie viele ML-Systeme sind derzeit im Einsatz?

  • Wie viele Kunden oder Nutzer sind von diesen Systemen betroffen?

  • Wer sind die verantwortlichen Akteure für jedes System?

MRM erreicht dieses Ziel durch den Einsatz von Modellinventaren. Ein Modellinventar ist eine kuratierte und aktuelle Datenbank mit allen ML-Systemen einer Organisation. Modellinventare können als Aufbewahrungsort für wichtige Informationen zur Dokumentation dienen, sollten aber auch mit Überwachungsplänen und -ergebnissen, Prüfungsplänen und -ergebnissen, wichtigen vergangenen und bevorstehenden Systemwartungen und -änderungen sowie Plänen zur Reaktion auf Vorfälle verknüpft werden.

Systemvalidierung und Prozessauditierung

Im Rahmen der traditionellen MRM-Praktiken wird ein ML-System vor seiner Veröffentlichung zwei Hauptprüfungen unterzogen. Bei der ersten Prüfung handelt es sich um eine technische Validierung des Systems, bei der erfahrene Prüfer - nicht selten promovierte Datenwissenschaftler - versuchen, Lücken im Systemdesign und in der Implementierung zu finden und mit den Systementwicklern zusammenzuarbeiten, um alle entdeckten Probleme zu beheben. Bei der zweiten Prüfung werden die Prozesse untersucht. Audit- und Compliance-Mitarbeiter analysieren sorgfältig das Systemdesign, die Entwicklung und den Einsatz sowie die Dokumentation und zukünftige Pläne, um sicherzustellen, dass alle gesetzlichen und internen Prozessanforderungen erfüllt werden. Da sich ML-Systeme im Laufe der Zeit verändern und abwandern, muss die Überprüfung immer dann stattfinden, wenn ein System eine größere Aktualisierung erfährt oder in einem vereinbarten Rhythmus.

Die Leserinnen und Leser denken vielleicht (mal wieder), dass ihre Organisation nicht die Ressourcen für solch umfangreiche Überprüfungen hat. Das ist natürlich eine Realität für viele kleine oder jüngere Organisationen. Die Schlüssel für die Validierung und Prüfung, die in fast jeder Organisation funktionieren sollten, sind, dass Techniker, die das System nicht entwickelt haben, es testen, dass es eine Funktion gibt, die nicht-technische interne und externe Verpflichtungen prüft, und dass wichtige ML-Systemimplementierungen von den zuständigen Behörden genehmigt werden.

Veränderungsmanagement

Wie alle komplexen Softwareanwendungen bestehen ML-Systeme in der Regel aus einer großen Anzahl verschiedener Komponenten. Vom ML-Backend-Code über die Anwendungsprogrammierschnittstellen (APIs) bis hin zu den grafischen Benutzeroberflächen (GUIs) können Änderungen in jeder Komponente des Systems zu Nebenwirkungen in anderen Komponenten führen. Wenn dann noch Probleme wie Datendrift, neue Datenschutz- und Antidiskriminierungsvorschriften und komplexe Abhängigkeiten von Drittanbietersoftware hinzukommen, wird das Änderungsmanagement in ML-Systemen zu einem ernsthaften Problem. Wenn wir uns in der Planungs- oder Entwurfsphase eines unternehmenskritischen ML-Systems befinden, müssen wir das Änderungsmanagement wahrscheinlich zu einer erstklassigen Prozesskontrolle machen. Ohne explizite Planung und Ressourcen für das Änderungsmanagement lassen sich prozessuale oder technische Fehler, die im Laufe der Entwicklung des Systems auftreten, wie die Verwendung von Daten ohne Zustimmung oder API-Fehlanpassungen, nur schwer verhindern. Außerdem werden solche Probleme ohne Änderungsmanagement vielleicht nicht einmal entdeckt, bis sie einen Vorfall verursachen.

Wir werden im Laufe des Buches immer wieder auf MRM zurückkommen. Es ist eines der bewährtesten Rahmenwerke für die Steuerung und das Risikomanagement von ML-Systemen. Natürlich ist MRM nicht der einzige Ort, an dem du dich für verbesserte ML-Sicherheits- und Leistungsprozesse inspirieren lassen kannst, und im nächsten Unterkapitel werden wir Lehren aus anderen Praxisbereichen ziehen.

Hinweis

Die Lektüre der 21-seitigen SR 11-7 Modell-Risikomanagement-Leitlinien ist eine schnelle Möglichkeit, sich im ML-Risikomanagement weiterzubilden. Achte bei der Lektüre besonders auf den Fokus auf kulturelle und organisatorische Strukturen. Der Umgang mit technologischen Risiken hat oft mehr mit Menschen zu tun als mit allem anderen.

Jenseits des Modell-Risikomanagements

Aus den bewährten Methoden der Finanzprüfung, des Datenschutzes, der Softwareentwicklung und der IT-Sicherheit lassen sich viele Lehren für das ML-Risikomanagement ziehen. In diesem Unterkapitel werden Ideen beleuchtet, die nicht in den Bereich des traditionellen MRM fallen: Modellprüfungen, Folgenabschätzungen, Einsprüche, Überschreibungen, Opt-Outs, Pair- oder Double Programming, Least Privilege, Bug Bounties und Incident Response, alles aus der Perspektive der Sicherheit und Leistung von ML.

Modell-Audits und -Bewertungen

Audit ist ein gebräuchlicher Begriff im MRM, aber er hat auch eine andere Bedeutung als die, als die er normalerweise bekannt ist - die dritte Verteidigungslinie in einem eher traditionellen MRM-Szenario. In den letzten Jahren ist der Begriff " Modellaudit" in den Vordergrund gerückt. Ein Modellaudit ist ein offizielles Prüf- und Transparenzverfahren, das sich auf ein ML-System konzentriert, das die Einhaltung bestimmter Richtlinien, Vorschriften oder Gesetze überwacht. Modellprüfungen werden in der Regel von unabhängigen Dritten durchgeführt, wobei die Interaktion zwischen Prüfer und geprüfter Organisation begrenzt ist. Eine gute Übersicht über Modellprüfungen findest du in dem kürzlich erschienenen Papier "Algorithmic Bias and Risk Assessments: Lehren aus der Praxis". Das Papier "Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing" (Die KI-Rechenschaftslücke schließen: Definition eines durchgängigen Rahmens für die interne Prüfung von Algorithmen) stellt einen soliden Rahmen für Prüfungen und Bewertungen vor und enthält sogar Beispiele für Arbeitsunterlagen. Der verwandte Begriff " Modellbewertung" scheint eine eher informelle und kooperative Test- und Transparenzübung zu meinen, die von externen oder internen Gruppen durchgeführt werden kann.

ML-Audits und -Bewertungen können sich auf Vorurteile oder andere schwerwiegende Risiken konzentrieren, z. B. Sicherheit, Datenschutz und Sicherheitslücken. Unabhängig von ihrem Schwerpunkt müssen die Prüfungen und Prüfer fair und transparent sein. Diejenigen, die Prüfungen durchführen, sollten sich an klare ethische oder professionelle Standards halten, die 2023 kaum noch existieren. Ohne solche Mechanismen der Rechenschaftspflicht oder verbindliche Richtlinien können Audits ein ineffektives Risikomanagement sein, oder schlimmer noch, sie sind eine Art "Tech-Washing", bei dem schädliche ML-Systeme zertifiziert werden. Trotz dieser Mängel sind Prüfungen eine beliebte Taktik zur Risikokontrolle bei politischen Entscheidungsträgern und Forschern und werden in Gesetzen verankert, wie z. B. in dem bereits erwähnten New York City Local Law 144.

Folgenabschätzungen

Folgenabschätzungen sind ein formaler Dokumentationsansatz, der in vielen Bereichen verwendet wird, um die potenziellen Probleme, die ein System nach seiner Einführung verursachen könnte, vorherzusagen und aufzuzeichnen. Wahrscheinlich aufgrund ihres Einsatzes im Bereich des Datenschutzes werden Folgenabschätzungen allmählich auch in organisatorischen ML-Richtlinien und Gesetzesvorschlägen verwendet. Folgenabschätzungen sind ein wirksames Mittel, um die Schäden, die ein KI-System verursachen könnte, zu durchdenken und zu dokumentieren und so die Verantwortlichkeit der Entwickler und Betreiber von KI-Systemen zu erhöhen. Aber Folgenabschätzungen allein reichen nicht aus. Erinnern wir uns an die Definition von Risiko und Erheblichkeit, die wir zuvor dargelegt haben, so ist die Auswirkung nur ein Faktor des Risikos. Die Auswirkungen müssen mit den Wahrscheinlichkeiten kombiniert werden, um ein Risikomaß zu bilden, und dann müssen die Risiken aktiv gemindert werden, wobei die Anwendungen mit dem höchsten Risiko am meisten überwacht werden müssen. Folgenabschätzungen sind nur der Anfang eines umfassenderen Risikomanagementprozesses. Wie andere Risikomanagementprozesse auch, müssen sie in einem Rhythmus durchgeführt werden, der sich an das zu bewertende System anpasst. Wenn sich ein System schnell verändert, müssen die Folgenabschätzungen häufiger durchgeführt werden. Ein weiteres potenzielles Problem mit Folgenabschätzungen entsteht, wenn sie von den ML-Teams entworfen und umgesetzt werden, die auch die Bewertung durchführen. In diesem Fall besteht die Versuchung, den Umfang der Folgenabschätzung einzuschränken und mögliche negative Auswirkungen herunterzuspielen. Folgenabschätzungen sind ein wichtiger Teil eines umfassenderen Risikomanagements und von Governance-Strategien, aber sie müssen so oft durchgeführt werden, wie es ein bestimmtes System erfordert, und wahrscheinlich von unabhängigen Aufsichtsexperten.

Einspruch, Außerkraftsetzung und Opt-out

In den meisten ML-Systemen sollten Möglichkeiten für Nutzer/innen oder Betreiber/innen eingebaut sein, gegen unvermeidliche Fehlentscheidungen Einspruch zu erheben und diese aufzuheben. In vielen Disziplinen gibt es dafür viele Namen: Einspruchsmöglichkeiten, Interventionsmöglichkeiten, Abhilfemaßnahmen oder Mitteilungen über nachteilige Maßnahmen. Das kann so einfach sein wie die Funktion "Unangemessene Vorhersagen melden" in der Google-Suchleiste oder so anspruchsvoll wie die Präsentation von Daten und Erklärungen für die Nutzer/innen und die Ermöglichung von Einspruchsverfahren für nachweislich falsche Datenpunkte oder Entscheidungsmechanismen. Ein anderer ähnlicher Ansatz, der als Opt-out bekannt ist, besteht darin, dass die Nutzer/innen ihre Geschäfte mit einem Unternehmen auf die altmodische Art und Weise abwickeln können, ohne eine automatisierte Verarbeitung zu durchlaufen. Viele Datenschutzgesetze und die wichtigsten US-Verbraucherfinanzierungsgesetze sehen Regressansprüche, Opt-outs oder beides vor. Vielen Nutzern automatisch falsche Entscheidungen aufzuzwingen, ist eine der klarsten ethischen Fehlentscheidungen im ML. Wir sollten nicht in eine ethische, rechtliche und rufschädigende Falle tappen, die so klar und so bekannt ist, aber viele Systeme tun es trotzdem. Das liegt wahrscheinlich daran, dass es Planung und Ressourcen für Prozesse und Technologie braucht, die von Anfang an bei der Entwicklung eines ML-Systems festgelegt werden, um Einspruch, Überschreibung und Opt-out richtig zu machen.

Paarweise und doppelte Programmierung

Da sie in der Regel komplex und stochastisch sind, ist es schwer zu wissen, ob eine ML-Algorithmus-Implementierung korrekt ist! Aus diesem Grund implementieren einige führende ML-Organisationen ML-Algorithmen doppelt, um die Qualität zu sichern. Eine solche doppelte Implementierung wird in der Regel durch eine von zwei Methoden erreicht: Pair Programming oder Double Programming. Bei der Paarprogrammierung programmieren zwei technische Experten einen Algorithmus, ohne zusammenzuarbeiten. Dann tun sie sich zusammen und klären alle Unstimmigkeiten zwischen ihren Implementierungen. Bei der Doppelprogrammierung implementiert derselbe Fachmann denselben Algorithmus zweimal, aber in sehr unterschiedlichen Programmiersprachen, z. B. in Python (objektorientiert) und SAS (prozedural). Anschließend müssen sie alle Unterschiede zwischen ihren beiden Implementierungen ausgleichen. Bei beiden Ansätzen werden in der Regel zahlreiche Fehler entdeckt, die sonst unbemerkt bleiben würden, bis das System eingesetzt wird. Paar- und Doppelprogrammierung kann auch mit dem Standard-Workflow von Datenwissenschaftlern übereinstimmen, die Algorithmen als Prototypen entwickeln, während engagierte Ingenieure sie für den Einsatz härten. Damit dies funktioniert, müssen die Ingenieure jedoch die Möglichkeit haben, die Prototypen der Datenwissenschaftler zu hinterfragen und zu testen, und sollten nicht darauf beschränkt werden, die Prototypen einfach neu zu programmieren.

Sicherheitsberechtigungen für die Modellbereitstellung

Das Konzept der geringsten Rechte aus der IT-Sicherheit besagt, dass kein Systembenutzer jemals mehr Rechte haben sollte, als er braucht. Das Konzept der geringsten Rechte ist eine grundlegende Prozesskontrolle, die wahrscheinlich deshalb, weil ML-Systeme so viele andere IT-Systeme berühren, bei der Entwicklung von ML-Systemen und bei so genannten "Rockstar"-Datenwissenschaftlern oft über Bord geworfen wird. Leider ist dies ein Antipattern für die Sicherheit und Leistung von ML. Außerhalb der Welt von ML und "Rockstar"-Datenwissenschaftlern ist es seit langem bekannt, dass Ingenieure ihren eigenen Code nicht ausreichend testen können und dass andere in einer Produktorganisation - Produktmanager, Anwälte oder Führungskräfte - die endgültige Entscheidung darüber treffen sollten, wann Software freigegeben wird.

Aus diesen Gründen sollten die IT-Berechtigungen, die für den Einsatz eines ML-Systems erforderlich sind, auf mehrere Teams innerhalb der IT-Organisation verteilt werden. Während der Entwicklungssprints müssen die Datenwissenschaftler/innen und Ingenieur/innen natürlich die volle Kontrolle über ihre Entwicklungsumgebung behalten. Wenn jedoch wichtige Veröffentlichungen oder Überprüfungen anstehen, werden die IT-Berechtigungen für Korrekturen, Erweiterungen oder neue Funktionen für benutzerorientierte Produkte von Datenwissenschaftlern und Ingenieuren auf Produktmanager, Tester, Anwälte, Führungskräfte oder andere übertragen. Solche Prozesskontrollen verhindern, dass nicht genehmigter Code eingesetzt wird.

Bug Bounties

Bug Bounties sind ein weiteres Konzept, das wir aus der Computersicherheit übernehmen können. Traditionell bietet ein Unternehmen Belohnungen für das Auffinden von Problemen in seiner Software an, insbesondere für Sicherheitslücken. Da ML größtenteils aus Software besteht, können wir Bug Bounties auch für ML-Systeme einsetzen. Wir können Bug Bounties nicht nur einsetzen, um Sicherheitsprobleme in ML-Systemen zu finden, sondern auch, um andere Arten von Problemen in Bezug auf Zuverlässigkeit, Sicherheit, Transparenz, Erklärbarkeit, Interpretierbarkeit oder Datenschutz zu finden. Mit Bug Bounties schaffen wir durch finanzielle Belohnungen Anreize für das Feedback der Community in einem standardisierten Prozess. Wie wir bereits an anderer Stelle in diesem Kapitel hervorgehoben haben, sind Anreize für das Risikomanagement von entscheidender Bedeutung. Im Allgemeinen ist Risikomanagement mühsam und ressourcenintensiv. Wenn wir wollen, dass unsere Nutzer/innen große Probleme in unseren ML-Systemen für uns finden, müssen wir sie bezahlen oder auf andere Weise belohnen. Bug Bounties sind in der Regel öffentliche Unternehmungen. Wenn das einige Unternehmen nervös macht, können interne Hackathons, bei denen verschiedene Teams nach Fehlern in ML-Systemen suchen, einige der gleichen positiven Effekte haben. Natürlich sind die Ergebnisse umso besser, je mehr Anreize zur Teilnahme bestehen.

Reaktion auf KI-Vorfälle

Unter heißt es in der gepriesenen Leitlinie SR 11-7: "Selbst beigeschickter Modellierung und robuster Validierung kann das Modellrisiko nicht ausgeschaltet werden". Wenn die Risiken von ML-Systemen und ML-Modellen nicht beseitigt werden können, dann werden diese Risiken irgendwann zu Vorfällen führen. Die Reaktion auf Zwischenfälle ist im Bereich der Computersicherheit bereits eine ausgereifte Praxis. Ehrwürdige Institutionen wie NIST und SANS veröffentlichen seit Jahren Richtlinien für die Reaktion auf Computer-Sicherheitsvorfälle. Da es sich bei ML um eine weniger ausgereifte und risikoreichere Technologie handelt als bei der allgemeinen Unternehmensinformatik, sind formale Pläne und Praktiken zur Reaktion auf KI-Vorfälle ein Muss für KI-Systeme, die hohe Auswirkungen haben oder unternehmenskritisch sind.

Formelle KI-Vorfallreaktionspläne ermöglichen es Unternehmen, schneller und effektiver auf unvermeidliche Vorfälle zu reagieren. Die Reaktion auf Vorfälle spielt auch eine Rolle bei der zu Beginn des Kapitels besprochenen Hand-Regel. Mit einstudierten Reaktionsplänen können Unternehmen KI-Vorfälle erkennen, eindämmen und beseitigen, bevor sie sich zu einem kostspieligen oder gefährlichen öffentlichen Spektakel auswachsen. Reaktionspläne für KI-Vorfälle sind eine der grundlegendsten und universellsten Möglichkeiten, um KI-bezogene Risiken zu minimieren. Bevor ein System eingeführt wird, sollten Reaktionspläne für Vorfälle erstellt und getestet werden. Für junge oder kleine Unternehmen, die kein vollständiges Modell-Risikomanagement einführen können, ist die Reaktion auf KI-Vorfälle eine kostengünstige und wirksame KI-Risikokontrolle, die man in Betracht ziehen sollte. In Anlehnung an die Reaktion auf Computervorfälle kann die Reaktion auf KI-Vorfälle in sechs Phasen unterteilt werden:

Phase 1: Vorbereitung

Neben der klaren Definition eines KI-Vorfalls für unsere Organisation umfasst die Vorbereitung auf KI-Vorfälle auch personelle, logistische und technische Pläne für den Fall, dass ein Vorfall eintritt. Es müssen Budgets für die Reaktion auf einen Vorfall bereitgestellt, Kommunikationsstrategien entwickelt und technische Sicherheitsvorkehrungen für die Standardisierung und Bewahrung der Modelldokumentation, die Out-of-Band-Kommunikation und die Abschaltung von KI-Systemen getroffen werden. Eine der besten Möglichkeiten, sich auf KI-Vorfälle vorzubereiten und zu proben, sind Tabletop-Diskussionsübungen, bei denen wichtige Mitarbeiter/innen der Organisation einen realistischen Vorfall durchspielen. Gute Einstiegsfragen für einen KI-Vorfall sind z.B. die folgenden:

  • Wer hat das organisatorische Budget und die Befugnis, auf einenKI-Vorfall zu reagieren?

  • Kann das betreffende KI-System offline genommen werden? Von wem? Zu welchen Kosten? Welche vorgelagerten Prozesse werden betroffen sein?

  • Welche Aufsichtsbehörden oder Vollzugsbehörden müssen kontaktiert werden? Wer wird sie kontaktieren?

  • Welche externen Anwaltskanzleien, Versicherungsagenturen oder Public-Relations-Firmen müssen kontaktiert werden? Wer wird sie kontaktieren?

  • Wer kümmert sich um die Kommunikation? Intern, zwischen den Ansprechpartnern? Extern, mit Kunden oder Nutzern?

Phase 2: Identifizierung

Identifizierung bedeutet, dass Unternehmen KI-Fehler, -Angriffe oder -Missbrauch erkennen. Identifizierung bedeutet auch, auf KI-bezogene Missbräuche zu achten. In der Praxis bedeutet dies in der Regel, dass allgemeinere Ansätze zur Identifizierung von Angriffen, wie z. B. die Überwachung von Netzwerkeinbrüchen, und eine speziellere Überwachung von KI-Systemfehlern, wie z. B. Konzeptabweichung oder algorithmische Diskriminierung, eingesetzt werden. Oft besteht der letzte Schritt der Identifizierungsphase darin, die Geschäftsführung, die Notfallhelfer und andere in den Notfallplänen festgelegte Personen zu benachrichtigen.

Phase 3: Eindämmung

Eindämmung bedeutet, den unmittelbaren Schaden des Vorfalls zu begrenzen. Dabei ist zu beachten, dass die Schäden selten auf das System beschränkt sind, in dem der Vorfall seinen Anfang nahm. Wie allgemeinere Computer-Vorfälle können auch KI-Vorfälle Netzwerkeffekte haben, die sich auf die Technologien eines Unternehmens und seiner Kunden ausbreiten. Die tatsächlichen Eindämmungsstrategien hängen davon ab, ob der Vorfall auf einen externen Angreifer, ein internes Versagen oder eine unzulässige Nutzung oder einen Missbrauch eines KI-Systems zurückzuführen ist. Falls nötig, ist die Eindämmung auch ein guter Zeitpunkt, um mit der Öffentlichkeit zu kommunizieren.

Phase 4: Ausrottung

Bei der Ausrottung geht es darum, alle betroffenen Systeme zu sanieren. Dazu gehört zum Beispiel die Abschottung der angegriffenen Systeme von Vektoren der Ein- oder Ausschleusung oder die Abschaltung eines diskriminierenden KI-Systems und dessen vorübergehende Ersetzung durch ein vertrauenswürdiges regelbasiertes System. Nach der Ausmerzung sollte es keine neuen Schäden durch den Vorfall geben.

Phase 5: Erholung

Wiederherstellung bedeutet sicherzustellen, dass alle betroffenen Systeme wieder normal funktionieren und dass Kontrollen vorhanden sind, um ähnliche Vorfälle in Zukunft zu verhindern. Die Wiederherstellung bedeutet oft, dass KI-Systeme neu geschult oder implementiert werden müssen und getestet werden muss, ob sie auf dem dokumentierten Niveau von vor dem Vorfall arbeiten. Die Wiederherstellung kann auch eine sorgfältige Analyse der technischen oder Sicherheitsprotokolle für das Personal erfordern, insbesondere im Falle eines versehentlichen Ausfalls oder eines Insider-Angriffs.

Phase 6: Gelernte Lektionen

Lessons Learned bezieht sich auf Korrekturen oder Verbesserungen von AI-Reaktionsplänen auf der Grundlage der Erfolge und Herausforderungen, die bei der Reaktion auf den aktuellen Vorfall aufgetreten sind. Die Verbesserungen der Reaktionspläne können prozess- oder technologieorientiert sein.

Wenn du den folgenden Fall liest, denke über die Phasen der Reaktion auf einen Vorfall nach und überlege, ob ein KI-Vorfallreaktionsplan eine wirksame Risikokontrolle für Zillow gewesen wäre.

Fallstudie: Der Aufstieg und Fall von Zillows iBuying

Im Jahr 2018 stieg das Immobilienunternehmen Zillow in das Geschäft mit dem Kauf von Häusern ein, um sie gewinnbringend weiterzuverkaufen, bekannt als iBuying. Das Unternehmen war davon überzeugt, dass sein proprietärer, ML-gestützter Zestimate-Algorithmus mehr als nur die Aufmerksamkeit auf seine äußerst beliebten Webprodukte lenken könnte. Wie Bloomberg berichtet, beschäftigte Zillow zu Beginn des Hauskaufs Experten, um die von den Algorithmen generierten Zahlen zu validieren. Zunächst bewerteten lokale Immobilienmakler die Immobilie. Die Zahlen wurden mit dem Zestimate kombiniert, und ein Expertenteam überprüfte jedes Angebot, bevor es abgegeben wurde.

Laut Bloomberg hat Zillow diese Expertenteams bald abgeschafft, um "Angebote schneller zu veröffentlichen" und die Geschwindigkeit und den Umfang eines rein algorithmischen Ansatzes vorzuziehen. Als sich der Zestimate Anfang 2021 nicht an den rasant ansteigenden Immobilienmarkt anpasste, griff Zillow Berichten zufolge ein, um die Attraktivität seiner Angebote zu erhöhen. Als Folge dieser Änderungen begann das Unternehmen, fast 10.000 Immobilien pro Quartal zu erwerben. Mehr Immobilienverkäufe bedeuten mehr Personal und mehr Renovierungsfirmen, aber wie Bloomberg es ausdrückt, "konnten Zillows Menschen nicht mithalten". Trotz einer Aufstockung des Personals um 45 % und der Einstellung von "Armeen" von Auftragnehmern war das iBuying-System nicht profitabel. Das iBuying-Projekt war mit der Kombination aus Personal- und Lieferengpässen, dem überhitzten Wohnungsmarkt und der Komplexität der Bearbeitung einer großen Anzahl von Hypotheken einfach überfordert.

Im Oktober 2021 kündigte Zillow an, dass es bis Ende des Jahres keine Angebote mehr machen würde. Aufgrund von Zillows Appetit auf schnelles Wachstum sowie von Arbeits- und Lieferengpässen hatte das Unternehmen einen riesigen Bestand an Immobilien abzubauen. Um das Bestandsproblem zu lösen, hat Zillow die meisten Häuser zum Wiederverkauf mit Verlust angeboten. Am 2. November gab Zillow schließlich bekannt, dass es seinen Bestand um mehr als 500 Millionen US-Dollar abschreiben würde. Zillows Ausflug in das Geschäft mit dem automatisierten Hausverkauf war damit beendet.

Fallout

Zusätzlich zu dem großen finanziellen Verlust, den das fehlgeschlagene Unternehmen erlitt, kündigte Zillow an, rund 2.000 Mitarbeiter zu entlassen - ein ganzes Viertel des Unternehmens. Im Juni 2021 lag der Kurs der Zillow-Aktie bei etwa 120 Dollar pro Aktie. Zum Zeitpunkt der Erstellung dieses Artikels, also fast ein Jahr später, liegen die Aktien bei etwa 40 US-Dollar und haben damit über 30 Milliarden US-Dollar an Wert verloren. (Natürlich kann nicht der gesamte Kursrückgang auf den iBuying-Vorfall zurückgeführt werden, aber er hat sicherlich zu dem Verlust beigetragen). Der Niedergang von Zillows iBuying hat viele miteinander verwobene Ursachen und kann nicht von der Pandemie abgekoppelt werden, die im Jahr 2020 ausbrach und den Immobilienmarkt auf den Kopf stellte. Im nächsten Abschnitt werden wir untersuchen, wie wir das, was wir in diesem Kapitel über Unternehmensführung und Risikomanagement gelernt haben, auf die Missgeschicke von Zillow anwenden können.

Gelernte Lektionen

Was lehrt uns dieses Kapitel über die iBuying-Saga von Zillow? Aus der öffentlichen Berichterstattung geht hervor, dass die Entscheidung von Zillow, die menschliche Überprüfung von Algorithmen mit hoher Relevanz zu vernachlässigen, wahrscheinlich ein Faktor bei dem gesamten Vorfall war. Wir fragen uns auch, ob Zillow das finanzielle Risiko, das es auf sich nahm, ausreichend durchdacht hatte, ob angemessene Governance-Strukturen vorhanden waren und ob die iBuying-Verluste nicht besser als KI-Vorfall behandelt worden wären. Wir kennen die Antworten auf viele dieser Fragen in Bezug auf Zillow nicht, daher konzentrieren wir uns stattdessen auf Erkenntnisse, die die Leser/innen in ihren eigenen Unternehmen anwenden können:

Lektion 1: Validiere mit Fachexperten.

In diesem Kapitel haben wir die Bedeutung vielfältiger und erfahrener Teams als organisatorische Kernkompetenz für eine verantwortungsvolle ML-Entwicklung betont. Zweifelsohne hat Zillow intern und extern Zugang zu erstklassigem Fachwissen über Immobilienmärkte. Im Interesse von Geschwindigkeit und Automatisierung - manchmal auch als "schnelles Handeln und Brechen" oder "Produktgeschwindigkeit" bezeichnet - hat Zillow jedoch die Experten aus dem Prozess des Immobilienerwerbs herausgenommen und sich stattdessen auf seinen Zestimate-Algorithmus verlassen. Wie Bloomberg im Mai 2022 berichtete, hat Zillow seine Preisexperten angewiesen, die Algorithmen nicht mehr zu hinterfragen, wie mit dem Prozess vertraute Personen berichten. Diese Entscheidung könnte sich als fatal für das Unternehmen erwiesen haben, vor allem in einem sich schnell verändernden, von Pandemien getriebenen Immobilienmarkt. Trotz des Hypes ist die KI noch nicht schlauer als der Mensch. Wenn wir mit ML risikoreiche Entscheidungen treffen, sollten wir den Menschen nicht aus den Augen verlieren.

Lektion 2: Prognostiziere Fehlermöglichkeiten.

Die Coronavirus-Pandemie von 2020 hat in vielen Bereichen und Märkten einen Paradigmenwechsel bewirkt. ML-Modelle, die in der Regel davon ausgehen, dass die Zukunft der Vergangenheit ähnelt, haben wahrscheinlich in vielen Branchen auf breiter Front gelitten. Wir sollten nicht erwarten, dass ein Unternehmen wie Zillow eine Pandemie am Horizont sieht. Aber wie wir bereits erörtert haben, ist die gründliche Untersuchung der Fehlermöglichkeiten unseres ML-Systems eine entscheidende Kompetenz für ML in Hochrisikosituationen. Wir kennen die Details von Zillows Model Governance Frameworks nicht, aber der Untergang von Zillows iBuying unterstreicht, wie wichtig es ist, effektiv zu hinterfragen und schwierige Fragen zu stellen, z. B. "Was passiert, wenn sich die Kosten für die Durchführung von Renovierungen in den nächsten zwei Jahren verdoppeln?" und "Wie hoch sind die Geschäftskosten, wenn wir innerhalb von sechs Monaten zwei Prozent zu viel für Häuser bezahlen?" Bei einem so risikoreichen System sollten die wahrscheinlichen Ausfallarten aufgezählt und dokumentiert werden, wahrscheinlich unter Aufsicht des Vorstands, und das tatsächliche finanzielle Risiko sollte allen leitenden Entscheidungsträgern klar gemacht worden sein. In unserem Unternehmen müssen wir wissen, was es kostet, wenn wir mit ML falsch liegen, und dass die Führungsebene bereit ist, diese Kosten in Kauf zu nehmen. Vielleicht wurden die leitenden Angestellten von Zillow genau über die finanziellen Risiken von iBuying informiert, vielleicht aber auch nicht. Was wir jetzt wissen, ist, dass Zillow ein großes Risiko eingegangen ist, das sich nicht ausgezahlt hat.

Lektion 3: Governance zählt.

Der CEO von Zillow ist berühmt für seine Risikobereitschaft und hat bewiesen, dass er große Wetten gewinnen kann. Aber wir können einfach nicht jede Wette gewinnen, die wir eingehen. Deshalb müssen wir die Risiken bei der automatisierten Entscheidungsfindung beherrschen und kontrollieren, vor allem in Szenarien mit hohem Risiko. SR 11-7 besagt: "Die Strenge und Komplexität der Validierung sollte der allgemeinen Verwendung von Modellen durch die Bank angemessen sein". Zillow ist keine Bank, aber im Bloomberg-Postmortem vom Mai 2022 wird es so formuliert: Zillow versuchte, "vom Verkauf von Online-Werbung zum Betriebeines Hedgefonds und eines ausgedehnten Baugeschäfts überzugehen". Zillow hat die Wesentlichkeit seiner Algorithmen drastisch erhöht, scheint aber die Kontrolle über diese Algorithmen nicht drastisch erhöht zu haben. Wie bereits erwähnt, deuten die meisten öffentlichen Berichte darauf hin, dass Zillow die menschliche Aufsicht über seine Algorithmen während seines iBuying-Programms verringert und nicht erhöht hat. Eine separate Risikofunktion, die mit der organisatorischen Befugnis ausgestattet ist, Modelle zu stoppen, die in Produktion gehen, und die über ein angemessenes Budget und Personal verfügt, die direkt dem Vorstand unterstellt ist und unabhängig von den Geschäfts- und Technologiefunktionen unter der Leitung des CEO und des CTO arbeitet, ist in großen Konsumfinanzunternehmen üblich. Wenn diese Organisationsstruktur wie beabsichtigt funktioniert, ermöglicht sie objektivere und risikobasierte Entscheidungen über die Leistung von ML-Modellen und vermeidet Interessenkonflikte und Bestätigungsfehler, die auftreten können, wenn Führungskräfte aus Wirtschaft und Technik ihre eigenen Systeme auf Risiken hin bewerten. Wir wissen nicht, ob Zillow eine unabhängige Modell-Governance-Funktion hatte - das ist heutzutage außerhalb der Konsumfinanzierung ziemlich selten. Aber wir wissen, dass keine Risiko- oder Überwachungsfunktion in der Lage war, das iBuying-Programm zu stoppen, bevor die Verluste ins Unermessliche stiegen. Es ist zwar ein harter Kampf, den man als einzelner Techniker führen muss, aber es ist eine praktikable Methode zur Risikominderung, unserem Unternehmen zu helfen, seine ML-Systeme unabhängig zu prüfen.

Lektion 4: KI-Vorfälle treten in großem Umfang auf.

Zillows iBuying-Unfug ist nicht lustig. Es ging Geld verloren. Karrieren gingen verloren - Tausende von Mitarbeitern wurden entlassen oder haben gekündigt. Das sieht nach einem 30 Milliarden Dollar schweren KI-Vorfall aus. Bei der Reaktion auf Vorfälle müssen wir darauf vorbereitet sein, dass Systeme fehlschlagen, wir müssen sie überwachen und wir müssen dokumentierte und geprobte Pläne für die Eindämmung, Ausrottung und Wiederherstellung haben. Aus den öffentlichen Berichten geht hervor, dass Zillow sich der Probleme mit iBuying bewusst war, aber die Unternehmenskultur war mehr darauf ausgerichtet, große Gewinne zu erzielen, als sich auf einen Ausfall vorzubereiten. In Anbetracht der Höhe des finanziellen Verlusts hätten die Eindämmungsbemühungen von Zillow effektiver sein können. Zillow war in der Lage, seine akutesten Probleme mit der Erklärung der Abschreibung von rund einer halben Milliarde Dollar im November 2021 zu beseitigen. Die Führung von Zillow hat Pläne für eine neue Immobilien-Super-App, aber angesichts des Aktienkurses zum Zeitpunkt der Erstellung dieses Artikels ist eine Erholung noch in weiter Ferne und die Anleger sind müde. Komplexe Systeme driften in Richtung Scheitern. Vielleicht kann ein disziplinierterer Umgang mit Vorfällen unser Unternehmen retten, wenn es mit ML große Wetten eingeht.

Die letzte und wichtigste Lektion, die wir aus der Zillow Offers-Saga mitnehmen können, steht im Mittelpunkt dieses Buches. Aufstrebende Technologien sind immer mit Risiken verbunden. Die ersten Automobile waren gefährlich. Flugzeuge stürzten früher viel häufiger gegen Berghänge. ML-Systeme können diskriminierende Praktiken aufrechterhalten, Sicherheits- und Datenschutzrisiken bergen und sich unerwartet verhalten. Ein grundlegender Unterschied zwischen ML und anderen aufkommenden Technologien ist, dass diese Systeme schnell und in großem Maßstab Entscheidungen treffen können. Als Zillow seinen Zestimate-Algorithmus einsetzte, konnte es den Einkauf auf Hunderte von Häusern pro Tag hochskalieren. Das Ergebnis war eine Abschreibung von einer halben Milliarde Dollar, noch größere Aktienverluste und der Verlust von Tausenden von Arbeitsplätzen. Dieses Phänomen des schnellen Scheiterns in großem Maßstab kann sogar noch verheerender sein, wenn es um den Zugang zu Kapital, Sozialhilfeprogramme oder die Entscheidung geht, wer eine neue Niere bekommt.

Get Maschinelles Lernen für hochriskante Anwendungen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial