Wann menschliche Aufsicht in einem KI-System nicht funktioniert

Wenn wir KI-Systeme für Organisationen entwickeln, gehört die menschliche Freigabe zu den ersten Wünschen. Dieser Beitrag beschreibt, wie man erkennt, ob diese Freigabe im System wirklich funktioniert.

Wenn über KI-Governance gesprochen wird, ist der am häufigsten gehörte Satz dieser: "Es gibt eine menschliche Genehmigung, die Entscheidung wird nicht der Maschine überlassen."

Höre ich diesen Satz, stelle ich nur eine Frage. Wie hoch ist Ihre Genehmigungsquote?

Es kommt keine Antwort, weil sie nicht gemessen wird. An den wenigen Stellen, an denen sie doch gemessen wird, liegt das Ergebnis meist über achtundneunzig Prozent. Das heißt, die aufsichtführende Person widerspricht dem Modell einmal bei fünfzig Entscheidungen. In diesem Bild von menschlicher Aufsicht zu sprechen ist formal richtig, aber funktional falsch. Faktisch trifft das System die Entscheidung, der Mensch unterschreibt nur.

Warum der Genehmigungsknopf nicht funktioniert

Der Grund ist keine böse Absicht, sondern das Design.

Zeigt man einer nutzenden Person dreihundert Vorschläge am Tag und verlangt, jeden einzelnen zu genehmigen, automatisiert sich diese Person in kurzer Zeit. Ist die Trefferquote des Modells hoch, beschleunigt sich das noch, denn auch in den wenigen Fällen, in denen sie ablehnt, behält das Modell meist recht, und die Person hört auf, dem eigenen Urteil zu vertrauen.

In der Literatur nennt man das Automatisierungsüberkompensation, und es ist ein bekanntes Phänomen. Das heißt, je besser das System funktioniert, desto schwächer wird die menschliche Aufsicht. Das ist eine Tatsache, die beim Entwurf der Aufsicht berücksichtigt werden muss.

Die drei Bedingungen, die Aufsicht aussagekräftig machen

Damit Aufsicht funktional sein kann, müssen drei Dinge gleichzeitig gegeben sein.

Die aufsichtführende Person muss die Grundlage des Vorschlags sehen können. Wird nicht gezeigt, aufgrund welcher Eingaben das Modell zu diesem Ergebnis gelangt ist, kann die Person nur das Ergebnis bewerten, und um das Ergebnis zu bewerten, müsste sie von Grund auf selbst neu entscheiden. Das macht Aufsicht in der Praxis unmöglich.

Ablehnung muss kostenlos sein. Eine nutzende Person, die bei einer Ablehnung ein zusätzliches Formular ausfüllen, eine Begründung schreiben und die Zustimmung ihrer Vorgesetzten einholen muss, entscheidet sich gegen das Ablehnen. Der Ablehnungsweg muss mindestens so einfach sein wie der Genehmigungsweg.

Die Ablehnung muss eine Folge haben. Werden abgelehnte Vorschläge irgendwo vermerkt, ohne dass jemand sie ansieht, bemerkt die aufsichtführende Person das und verliert mit der Zeit das Interesse. Dass abgelehnte Fälle in die Weiterentwicklung des Modells einfließen, hält die Aufsicht lebendig.

Was Sie nicht messen, gibt es als Aufsicht nicht

Selbst wenn diese drei Bedingungen erfüllt sind, ist Messung weiterhin nötig.

Mindestens drei Kennzahlen müssen verfolgt werden. Die Ablehnungsquote, die durchschnittlich pro Entscheidung aufgewendete Zeit und die Trefferquote der abgelehnten Entscheidungen im Nachhinein. Ist die Zeit pro Entscheidung auf Sekunden gesunken, wird keine Aufsicht ausgeübt. Nähert sich die Ablehnungsquote null, gilt dasselbe Ergebnis.

Nur sehr wenige Organisationen haben eine Antwort, wenn diese Kennzahlen in einer Prüfung abgefragt werden. Dabei sind es keine schwierigen Messungen, sie lassen sich aus Daten ableiten, die das System ohnehin bereits erzeugt.

Das Widerspruchsrecht bestimmt die Architektur

Artikel 11 des Gesetzes Nr. 6698 räumt der betroffenen Person das Recht ein, gegen ein nachteiliges Ergebnis Widerspruch einzulegen, das ausschließlich durch die Analyse mittels automatisierter Systeme entstanden ist.

Die technische Folge dieser Vorschrift ist unmittelbar. Geht ein Widerspruch ein, müssen Sie zeigen können, wie die Entscheidung zustande kam. Können Sie das nicht, können Sie die Entscheidung nicht verteidigen.

Daraus ergibt sich diese architektonische Regel. In einem Ablauf, der Konsequenzen für eine Person hat, darf kein Modell verwendet werden, das keine Begründung liefert. Das muss von Anfang an als Einschränkung bei der Modellauswahl festgeschrieben werden. Erklärbarkeit nachträglich hinzuzufügen, ist bei den meisten Architekturen nicht möglich.

Aufzeichnen allein reicht nicht, es muss das Richtige aufgezeichnet werden

Beim Stichwort Audit-Trail denkt man zuerst an das Führen eines Protokolls, aber entscheidend ist der Inhalt dieses Protokolls.

Damit eine Entscheidung im Nachhinein überprüft werden kann, müssen fünf Dinge gemeinsam festgehalten werden. Die in das System eingegebenen Daten, die Version des Modells, das erzeugte Ergebnis, die Begründung, auf der das Ergebnis beruht, und die endgültige Entscheidung des Menschen. Werden diese fünf in getrennten Systemen gehalten, lassen sie sich später nicht mehr zuordnen. Wurde die Modellversion nicht festgehalten, kann Monate später die Frage nicht beantwortet werden, was das Modell zu diesem Zeitpunkt sagte.

Die nicht festgehaltene Modellversion ist in der Praxis die Lücke, die ich am häufigsten sehe. Das Modell wird aktualisiert, alte Entscheidungen versucht man mit dem neuen Modell zu erklären, und es passt nicht zusammen.

Der Unterschied zwischen Sicherheit und Unsicherheit muss sichtbar gemacht werden

Ein letzter Punkt. Das System muss ein mit geringer Sicherheit erzeugtes Ergebnis erkennbar von einem mit hoher Sicherheit erzeugten unterscheiden.

Fehlt diese Unterscheidung, vertraut die nutzende Person allen gleichermaßen und erhält gerade dort keine Warnung, wo der Fehler am wahrscheinlichsten ist. Dabei lässt sich die Unsicherheit des Modells selbst meist messen. Diese Messung in die Oberfläche zu bringen, ist die günstigste und wirksamste Verbesserung der Aufsicht.

Müsste ich für ein KI-Projekt heute eine einzige Sache auswählen, die zu tun ist, würde ich genau diese wählen.