Fragen & Antworten.

Der Anzeige einer Software kann man nicht glauben, wenn es um die tatsächliche Verkabelung geht. Unsere Abgas-Software zeigte für das Prüfgerät sauber RS232 an, und ich habe eine halbe Stunde nach seriellen Kabeln und COM-Ports gesucht. Am alten Anmelde-PC hingen aber nur Strom und Netzwerk, und das Gerät saß mit eigener Adresse im Netz. Eine Software zeigt, was einmal eingetragen wurde, nicht was hinten am Rechner steckt.

Die alte Windows-Platte muss man beim PC-Wechsel meistens gar nicht mitnehmen. Ich wollte unsere AU-Software auf einen neuen Rechner klonen und habe vorher ins Handbuch geschaut: Das Programm hat eine eigene Datensicherung, die die Lizenzdatei mitnimmt. Also altes System sichern, neuen PC sauber aufsetzen, die 82 Megabyte große Demoversion installieren, zurücksichern, fertig. Bevor man ein System mit Gewalt umzieht, lohnt die Frage, ob es dafür längst einen vorgesehenen Weg gibt.

Ein Achsmessstand mit WLAN braucht trotzdem ein Netzwerkkabel, weil sein Funk längst belegt ist. Unser Beissbarth-Messstand spannt zwei eigene Funkstrecken auf, eine zu den Messköpfen und eine für das Bedien-Tablet, ins Werkstattnetz kommt er darum nur über Ethernet. Wenn der Prospekt LAN/WLAN-Zugriff verspricht, heißt das: andere Geräte erreichen den Messstand, nicht: der Messstand wählt sich ins Firmen-WLAN ein. Ein Prospekt beantwortet die Frage, die der Hersteller stellt, nicht die, die man selbst hat.

Wenn der Laptop im Firmen-WLAN keine Drucker findet, sind die Drucker deswegen noch lange nicht weg. Ich stand mit dem MacBook auf unserem Schotterparkplatz, die Druckerliste blieb leer, dabei antworteten alle sieben Geräte sofort, sobald ich sie direkt über ihre feste Adresse ansprach. Die automatische Ansage, mit der sich Drucker im Netz zu erkennen geben, kommt schlicht nicht über jede Netzgrenze. Also habe ich die Drucker von Hand über ihre Adresse eingerichtet, seitdem druckt es. Nicht gefunden ist nicht dasselbe wie nicht da.

Dass zu einem System irgendein Passwort im Tresor liegt, reicht nicht, es muss das richtige sein. Als ich am UniFi-Controller unseres WLAN eine Port-Einstellung ändern wollte, fand ich im Tresor nur ein Konto mit Lesezugriff; das Admin-Konto mit vollen Rechten war nie abgelegt worden. Von zwei Konten fehlte ausgerechnet das wichtigere, und der vorhandene Eintrag gaukelte Vollständigkeit vor. Eine halbe Dokumentation ist tückischer als gar keine, denn die Lücke fällt erst auf, wenn man sie braucht.

Einen Fehler, der keinen Schaden anrichtet, behebt man trotzdem, sobald er regelmäßig im Protokoll steht. Unser Dokumentenarchiv Paperless startet jeden Morgen um sechs kurz neu, und unser Import-Programm klopfte im Fünf-Minuten-Takt genau in diese Lücke: jeden Tag rote Fehlermeldungen, nie ein echter Schaden. Jetzt fragt das Programm vorher kurz an, ob das Archiv erreichbar ist, und zieht sich sonst still bis zum nächsten Takt zurück. Ein Protokoll voller harmloser Fehler erzieht zum Überlesen, und irgendwann überliest man den einen, der zählt.

Wenn eine Kundennummer an einen neuen Kunden vergeben wird, erben die alten Dokumente stillschweigend den falschen Besitzer. Unser Werkstatt-Programm Loco-Soft verwendet frei gewordene Nummern wieder, und prompt lag eine frisch gescannte Rechnung in der Akte des Vorgängers. Unser nächtlicher Abgleich meldete daraufhin zwölf verdächtige Fälle, nach genauem Vergleich blieben zwei echte übrig, und umgehängt wird nur, wenn das Dokument selbst den neuen Namen belegt. Eine Nummer, die zweimal vergeben wird, ist kein Schlüssel mehr, sondern eine Falle.

Sechstausend alte Dokumente holt man ins Archiv, indem man der Automatik Zeit gibt statt Tempo. Bei uns wandern gerade 6.215 Bilddateien alter Fahrzeug- und Kundenakten aus Loco-Soft in die Dokumentenablage, und die Texterkennung braucht gut vierzig Sekunden pro Stück. Der Import läuft deshalb nur nachts und belegt bewusst nur einen von zwei Arbeitsprozessen, damit tagsüber niemand am Tresen wartet und die nächtliche Datensicherung Luft behält. Nach rund sechs Nächten ist der Bestand drin. Eine gute Migration merkt niemand, und genau das ist ihr Erfolg.

Die Duplikat-Warnung eines Programms reicht als Schutz nicht, denn eine Meldung ist keine Sperre. Unser Dokumentenarchiv Paperless meldete bei jedem erneuten Upload brav, dass ein Dokument mit gleichem Inhalt schon existiert, und importierte die Datei trotzdem. So sammelten sich 527 Kopien desselben Fotos an, bis ich die Prüfung selbst eingebaut habe: ein Inhalts-Vergleich vor jedem Upload. Was ein System nur meldet, muss man selbst verhindern.

Eine Automatik darf einen Vorgang nicht wiederholen, nur weil die Antwort ausbleibt, denn keine Antwort heißt nicht gescheitert. Bei uns ließ ein einziges 138-Megapixel-Foto die Texterkennung in Paperless länger laufen als die zwei Minuten, die mein Skript wartete. Es wertete das Schweigen als Fehlschlag und lud dieselbe Datei immer wieder neu hoch, am Ende standen 526 Duplikate im Archiv. Seitdem unterscheidet das Skript drei Ausgänge: gelungen, gescheitert und noch offen. Wer Schweigen als Scheitern deutet, wiederholt Dinge, die längst gelungen sind.

Ins Dokumentenarchiv gehört ein Foto nicht in voller Auflösung, sondern in der Auflösung, die das Archiv wirklich braucht. Ein einzelnes 138-Megapixel-Bild aus unseren alten Fahrzeugakten trieb die Texterkennung von Paperless über jede Zeitgrenze, und die Automatik erzeugte daraus über fünfhundert Duplikate. Seit wir solche Riesenbilder vor dem Hochladen auf 300 DPI verkleinern, also volle A4-Druckqualität, ist die Erkennung in siebenundzwanzig Sekunden fertig, und das Original bleibt unangetastet auf dem Quell-Laufwerk liegen. Mehr Auflösung ist nicht mehr Wert, sie ist nur mehr Last.

Ein KI-Chatbot erfindet Quellen-Links, weil er nur die Textausschnitte sieht, die man ihm vorlegt, und fehlende Adressen plausibel ergänzt. Unsere interne Loco-Soft-Hilfe, ein Chat über 1.176 Hilfeseiten, nannte anfangs Verweise, die es nie gab: die Dateinamen lagen der Maschine schlicht nicht vor. Seit die echte Adresse der Original-Hilfeseite am Anfang und am Ende jeder Seite steht und nur wörtlich vorliegende Adressen zitiert werden dürfen, stimmen die Links, drei von drei Stichproben geprüft. Eine KI zitiert nicht, was sie weiß, sondern was man ihr vor die Augen legt.

Das alte System lösche ich nicht, sobald das neue läuft, ich halte es nur an. Beim Umstieg unseres Doku-Chatbots für die Loco-Soft-Hilfe auf eine neue Software habe ich den Eigenbau samt Datenbank mit über viertausend Textbausteinen gestoppt, aber liegen lassen. Geprüft habe ich das neue System bisher an zwei echten Fragen aus der Werkstatt, und zwei Stichproben sind noch kein Dauerbetrieb. Ein angehaltenes System ist ein Rückweg, ein gelöschtes ist keiner.

Ein eingespielter Handgriff kann einen Fehler in der Automatik tagelang verstecken. In unserem Dokumentensystem Paperless kamen neue Scans mit falschen Sichtbarkeitsrechten an, 208 Dokumente konnte nur ein einziger Nutzer sehen. Drei Tage fiel das niemandem auf, weil ich als Postverteiler ohnehin jeden Beleg von Hand zuordne und die Rechte dabei unbewusst mit reparierte. Erst als der Empfang einen fehlenden Scan meldete, flog der Fehler auf. Wo ein Mensch täglich stillschweigend nachbessert, sieht der Prozess gesund aus, obwohl die Maschine krank ist.

Dass einer KI-Wissensdatenbank Dokumente fehlen, merkt man an fachlich falschen Antworten, nicht an einer Fehlermeldung. Unsere Loco-Soft-Hilfe auf Open WebUI beantwortete eine Storno-Frage falsch, und erst die Nachzählung zeigte: von 1.176 Dokumenten waren nur 819 wirklich drin, den Rest hatten wir für Duplikate gehalten. Seitdem gleiche ich nach jedem Import die Zahl im System mit der Quelle ab, erst bei 1176 zu 1176 gilt er als fertig. Die Maschine antwortet aus dem, was sie hat, nicht aus dem, was da sein müsste.

Fehler in einer neuen Software sollten wir zuerst bemerken, nicht die Mitarbeiter, die täglich damit arbeiten. Unser Dokumenten-System läuft seit gut einer Woche im Echtbetrieb, und die Kollegen fühlten sich in dieser Zeit wie Beta-Tester, weil sie Störungen vor uns fanden. Jetzt prüfe ich nach jeder Änderung selbst aus Mitarbeiter-Sicht, ob ein frischer Tresen-Scan sichtbar ankommt, und überwache die Fehlerordner, statt auf Meldungen zu warten. Die Akzeptanz einer neuen Software entscheidet sich nicht an ihren Funktionen, sondern daran, wer ihre Fehler zuerst findet.

Eine KI-Zusammenfassung soll keine Geldbeträge nennen, die stehen im Dokument selbst und in einem geprüften Feld. Unser lokales Modell Gemma hatte in eine Beleg-Zusammenfassung 499,70 Euro geschrieben, wo der maschinell geprüfte Zahlcode 174,82 Euro auswies. Beim Zählen fanden wir 1.862 alte Zusammenfassungen mit Beträgen, und niemand kann korrekt von erfunden unterscheiden. Seitdem gilt bei uns: Zusammenfassungen beschreiben, was ein Dokument ist, nicht was es kostet. Was die Maschine nicht behaupten darf, kann sie auch nicht falsch behaupten.

Mit dem Admin-Zugang zu testen reicht nicht, denn der Admin sieht Dinge, die sonst niemand sieht. In unserer Dokumentenablage (Paperless) waren drei Tage lang 208 eingescannte Belege für die Kollegen unsichtbar, weil die Automatik sie stillschweigend dem technischen Benutzer zuordnete. Unsere Tests liefen mit genau diesem Benutzer, also sah alles korrekt aus, bis der Empfang meldete, dass Scans nicht ankommen. Seitdem prüfen wir jede Änderung zusätzlich mit einem einfachen Mitarbeiter-Konto. Man muss ein System mit den Augen dessen testen, der damit arbeiten soll, nicht mit den eigenen.

Auf einen KI-Fehler muss man nicht sofort mit neuer Prüf-Logik antworten, manchmal ist Warten die bessere Reparatur. Als unser Modell in Beleg-Zusammenfassungen Beträge erfand, haben drei Zeilen im Prompt die Neuzugänge sauber gemacht. Die alten Einträge komplett neu analysieren zu lassen würde auf heutiger Hardware rund acht Nächte dauern, also warten wir damit auf den nächsten Modell-Sprung, statt Wächter-Code in die Pipeline zu bauen. Eine Pipeline, die mit jedem Fehler wächst, wird irgendwann selbst zum Fehler.

Zwei laufende Exemplare eines wichtigen Programms reichen als Absicherung nicht, wenn beide im Gleichtakt altern. Unser Dokumentensystem Paperless hatte zwei Webserver-Prozesse als Reserve, doch beide starteten morgens zur selben Minute, verbrauchten gleich schnell Speicher und wurden deshalb fast gleichzeitig ausgetauscht. Genau in dieses Fenster fiel die Meldung vom Empfang, die Seite reagiere nicht. Seit drei Prozesse mit kleinerer Schwelle laufen, springt bei jedem Wechsel eine warme Reserve ein, die Seite antwortet in einer Drittelsekunde. Eine Reserve schützt nur, wenn sie nicht im selben Takt ausfällt wie das, was sie ersetzen soll.