Wenn die KI plausibel falsch liegt
Die teure Fehlerart ist nicht der Absturz und nicht die erfundene Angabe, sondern das Ergebnis, das vollständig plausibel aussieht und trotzdem falsch ist. Ein Beispiel aus unserer eigenen Arbeit und die drei Prüfwege, die wir seither in jedes Projekt einbauen.
Wer über die Risiken von KI im Betrieb liest, findet meistens zwei Sorgen: Das System könnte ausfallen, oder es könnte etwas erfinden. Beides ist richtig, und beides ist beherrschbar. Ein Ausfall meldet sich. Eine erfundene Angabe fällt auf, sobald jemand nachschlägt.
Die teure Fehlerart ist eine dritte, über die selten jemand spricht: Das System liefert ein Ergebnis, das vollständig plausibel aussieht und trotzdem falsch ist. Nichts stürzt ab, nichts wirkt erfunden, die Zahlen sind rund. Nur stimmen sie nicht.
Wie das in der Praxis aussieht
Ein Beispiel aus unserer eigenen Arbeit. Wir bauen für einen Kunden einen Abgleich zwischen seinem Warenwirtschaftssystem und dem Bestellportal seines Lieferanten. Die Frage ist einfach: Welche Artikel im Shop kann der Lieferant überhaupt noch liefern?
Das System meldete: Bei 57 Prozent der Artikel wurde eine passende Produktseite gefunden. Daraus liess sich die Schlussfolgerung ziehen, dass der Kunde 128 Artikel führt, die niemand mehr beschaffen kann. Eine unangenehme, aber verwertbare Nachricht.
Sie war falsch. Die tatsächliche Quote lag bei 98 Prozent.
Die Ursache war ein Muster im Suchcode, das eine von zwei Adressformen des Portals nicht kannte. Ganze Warengruppen schienen dadurch leer. Und weil die Stichproben, mit denen wir das Ergebnis prüften, dasselbe Muster benutzten, bestätigten sie den Fehler, statt ihn zu finden.
Warum das so schwer zu bemerken ist
Ein Ergebnis wirkt richtig, wenn es zu den Erwartungen passt. 57 Prozent klingt nach einer plausiblen Quote. Ein Sortiment, in dem ein Teil der Artikel ausgelaufen ist, kennt jeder Händler. Nichts an dieser Zahl fordert zum Widerspruch auf.
Dazu kommt ein zweiter Punkt, der in der Praxis viel wiegt: Ein Prüfwerkzeug, das denselben Denkfehler enthält wie das geprüfte System, bestätigt sich selbst. Drei übereinstimmende Messungen sind wertlos, wenn alle drei mit demselben falschen Massstab entstanden sind. Genau das war hier der Fall.
Aufgefallen ist der Fehler nicht durch eine Prüfung, sondern durch einen Menschen, der die Ware kennt. Der Satz, der alles auslöste, war sinngemäss: «Diese Artikel müssen da sein, da bin ich mir sicher.» Erst danach haben wir das Werkzeug selbst in Frage gestellt statt nur sein Ergebnis.
Was dagegen hilft
Aus mehreren solchen Vorfällen ist bei uns eine Arbeitsweise entstanden. Sie besteht aus drei einfachen Regeln.
Erstens: ein unabhängiger Zeuge an jeder Stelle. Wenn ein System eine Produktseite liest und nichts findet, kann das zwei Gründe haben: Es gibt nichts, oder das System kann es nicht lesen. Beides sieht gleich aus. Wir lassen deshalb ein zweites, unabhängiges Merkmal mitprüfen. Zeigt die Seite Verfügbarkeitssymbole, ist sie nicht leer, egal was der Auswertungscode sagt. Der Unterschied zwischen «nichts da» und «nichts gelesen» ist damit sichtbar.
Zweitens: Zahlen im Verlauf statt einzeln. Eine Trefferquote von 67 Prozent ist für sich genommen weder gut noch schlecht. Sie wird erst dann zur Aussage, wenn man weiss, dass sie gestern bei 95 lag. Wir halten deshalb die Kennzahlen jedes Laufs fest und melden einen Einbruch, statt jeden Tag eine Zahl zu zeigen, die niemand einordnen kann.
Drittens: Stillstand muss sich melden. Ein Fehler schreit, aber Ausbleiben ist still. «Keine Meldung bekommen» und «alles in Ordnung» sehen von aussen identisch aus, und zwar beliebig lange. Jede Automatisierung, die etwas Regelmässiges tun soll, braucht deshalb etwas, das ihr Nichtstun bemerkt und meldet.
Was das für ein KMU bedeutet
Der wichtigste Punkt ist nicht technisch. Er betrifft die Rollenverteilung.
Ein KI-System kann rechnen, lesen und vergleichen. Was es nicht kann, ist wissen, ob ein Ergebnis zur Wirklichkeit des Betriebs passt. Diese Prüfung leistet nur jemand, der die Ware, die Kundschaft und die Abläufe kennt. In unserem Beispiel hat der Kunde den Fehler gefunden, nicht das System und nicht wir.
Daraus folgt eine unbequeme, aber nützliche Erkenntnis: Eine Automatisierung, die niemand mehr fachlich hinterfragt, ist gefährlicher als gar keine. Sie erzeugt Zahlen, auf die Entscheidungen gebaut werden, und niemand merkt, wenn der Boden darunter fehlt.
Wer Automatisierung einführt, sollte deshalb weniger fragen «Wie genau ist das System?» und mehr «Woran würde ich merken, dass es falsch liegt?». Wenn darauf keine Antwort existiert, fehlt nicht Vertrauen, sondern ein Prüfweg.
Wie wir damit umgehen
In jedem Projekt, das laufend Daten verarbeitet, bauen wir diese Prüfwege von Anfang an mit ein: unabhängige Merkmale, Kennzahlen über die Zeit, eine Meldung bei Stillstand. Das kostet Aufwand, der auf den ersten Blick nichts leistet, weil er im Normalbetrieb nichts tut.
Er zahlt sich in dem Moment aus, in dem etwas schiefgeht, ohne dass es jemand sehen könnte. Und dieser Moment kommt, auch bei sorgfältig gebauten Systemen. Der Unterschied liegt darin, ob er nach einem Tag auffällt oder nach einem halben Jahr.
Wie leicht der dritte Prüfweg fehlt, haben wir kurz darauf selbst erlebt. Die Auswertung lief, die Berichte waren fertig, alles war eingerichtet. Nur die zeitgesteuerten Läufe hatte niemand eingeschaltet. Am nächsten Morgen kam keine Meldung, und das fiel auch niemandem auf, denn eine ausbleibende Nachricht sieht genauso aus wie eine Nachricht, dass alles in Ordnung ist.
Bemerkt hat es der Kunde, mit der einfachen Frage, warum denn nichts gekommen sei. Seither prüft ein eigener kleiner Dienst jeden Morgen, ob die Kette überhaupt gelaufen ist, und meldet sich, wenn sie schweigt. Er läuft bewusst getrennt vom überwachten Ablauf, denn eine Kontrolle, die im selben Programm steckt wie das Kontrollierte, schweigt mit ihm.
