Vier Ausfälle, die keine Fehlermeldung auslösen.
Projekte der künstlichen Intelligenz scheitern selten an der Fähigkeit des Modells. Sie scheitern an Mängeln, die keine Meldung erzeugen, ein plausibles Ergebnis liefern und alle Kontrollen bestehen, die man spontan durchführt.
Was ein Projekt blockiert, ist fast nie das Modell
Die veröffentlichten Arbeiten zum Scheitern von Projekten der künstlichen Intelligenz stimmen in einem Punkt überein: Die Vorhaben, die nie in den Betrieb gelangen, machen grosse Mehrheiten aus, und die genannten Ursachen sind nicht die Fähigkeit der Modelle. Es sind die fehlende Bewertung, die Einbindung in das bestehende System und die Zuverlässigkeit unter realen Bedingungen.
Diese Formulierung bleibt abstrakt, solange man nicht gesehen hat, wie einer dieser Ausfälle aussieht. Hier vier Fälle, die wir selbst erlebt haben. Technisch haben sie nichts gemeinsam, und doch teilen sie denselben Zug: keiner erzeugt einen Fehler. Jeder besteht eine oberflächliche Kontrolle, und jeder wäre von einem Nutzer entdeckt worden statt von uns.
Ein Vorschau-Schalter, und die Anbindung liefert nichts
Eine Anbindung an einen Drittdienst war angeschlossen, wurde im Betrieb aufgerufen und antwortete auf jede Anfrage korrekt. Nutzbares lieferte sie dennoch nicht: Ein Parameter, der standardmässig auf «Vorschau» stand, liess jedes Dokument mit dem entsprechenden Vermerk durchgestrichen herauskommen.
Die übliche Kontrolle konnte das Problem nicht sehen. Der Aufruf ging hinaus, der Dienst antwortete, das Dokument kam an. Alles, was man normalerweise prüft, stand auf Grün.
Das Lehrreichste liegt anderswo. Diesen Parameter umzustellen war kein technisches Detail: Es änderte, wer was bezahlt, und damit die buchhalterische und steuerliche Behandlung des Vorgangs. Drei Dateien ohne erkennbaren Zusammenhang mussten am selben Tag bewegt werden.
Eine Zugriffshärtung, und die Tabelle gibt nichts mehr zurück
Wir haben auf einer Datenbanktabelle die zeilenweise Abschottung aktiviert und dokumentiert, dass kein Zugriff aus der Anwendung erwünscht sei. Was der Datenbankmotor daraus macht, unterscheidet sich von dem, was der Satz nahelegt: Die Abschottung zu aktivieren, ohne eine Richtlinie zu definieren, bedeutet nicht «dem Dienst vorbehalten», es bedeutet niemand.
Ergebnis: Eine in der Datenbank einwandfrei vorhandene Zeile wurde von der Anwendung als null gezählt, und der Nutzerpfad meldete, eine gültige Kennung sei nicht mehr gültig. Kein Fehler, keine Ablehnung, keine Spur. Das Symptom ist genau dasselbe wie bei einer unbekannten Kennung.
Die tiefere Ursache ist nicht die Datenbank, es ist die Prüfmethode. Eine Zugriffshärtung prüft man spontan in der Richtung «es schreibt nicht mehr», während in Wirklichkeit das Lesen bricht, und zwar lautlos. Null Zeilen ist eine gültige Antwort, nicht zu unterscheiden von einer berechtigten Leere.
Eine geänderte Variable, ein Prozess, der sie nicht gelesen hat
Eine Einstellung wird in der Konfigurationsdatei korrigiert. Der Wert stimmt, die Datei wird ausgerollt, und das Verhalten ändert sich nicht. Also ändert man etwas anderes, sucht anderswo und beginnt schliesslich, an der Einstellung selbst zu zweifeln.
Die meisten Programme lesen ihre Konfiguration beim Start und behalten sie im Speicher. Solange der Prozess nicht neu gestartet wurde, arbeitet er mit dem alten Wert, was auch immer in der Datei auf der Festplatte steht.
Schwarz auf weiss wirkt dieser Fall trivial. Er kostet dennoch Stunden, weil er sich als etwas anderes verkleidet: Das beobachtete Symptom lautet «meine Korrektur wirkt nicht», was auf die Korrektur lenkt und nie auf den Lebenszyklus des Prozesses. Die Prüfung besteht darin, zu beweisen, dass der antwortende Prozess tatsächlich der neue ist, nicht darin, den Wert in der Datei nochmals zu lesen.
Ein Deployment aus der Arbeitskopie
Der vierte Fall ist der banalste und der am schwersten aufzuholende. Ein Deployment, das aus dem Arbeitsordner statt aus dem Code-Repository gebaut wird, nimmt alles mit, was auf dem Rechner herumliegt: eine geänderte, nicht eingecheckte Datei, ein vergessener Versuch, eine lokal gemachte und nie versionierte Korrektur.
Das funktioniert, oft lange. Dann enthält der Betrieb plötzlich Code, den niemand in der Historie wiederfindet, und wer das Thema übernimmt, sucht stundenlang nach einer Änderung, die nie anderswo als auf einer einzigen Maschine existiert hat.
Das Gegenmittel passt in einen Satz: Was ausgerollt wird, stammt aus dem Repository, und ein Deployment beginnt mit der Prüfung, dass der Arbeitsbaum sauber ist. Eine langweilige Regel, deren Wert sich erst an dem Tag zeigt, an dem jemand anderes das System übernimmt.
Was diese vier Fälle gemeinsam haben
Keiner löst einen Fehler aus. Alle liefern ein plausibles Ergebnis. Und alle bestehen die Kontrolle, die man spontan durchführt, weil diese Kontrolle prüft, ob der Mechanismus läuft, statt zu prüfen, ob er die richtige Wirkung erzielt.
Es ist dieselbe Lehre in vier Gestalten. Eine Kontrolle, die nicht scheitern kann, kontrolliert nichts. Eine Anfrage vorbeiziehen zu sehen beweist nicht, dass sie eine Wirkung hatte. Einen laufenden Container zu sehen beweist nicht, dass er die richtige Version ausliefert. Null Zeilen zu sehen beweist nicht, dass es nichts zu sehen gibt.
Diese Prüfungen kosten je einige Minuten. Sie sind genau das, was einen beeindruckenden Prototyp von einem tragfähigen System trennt, und sie kommen in keiner Vorführung vor.