#Verifizieren

Eine Erkennungsregel verschärft man, indem man die neue Fassung vorher gegen den kompletten Echtbestand laufen lässt. Unsere Dokumentenerkennung hielt jede siebzehnstellige Zeichenfolge für eine Fahrgestellnummer und las so eine Barcode-Nummer als Fahrzeug. Bevor ich die Regel um die Bedingung Buchstaben und Ziffern gemischt ergänzte, habe ich sie gegen 7.499 echte Fahrgestellnummern aus Loco-Soft geprüft, und keine einzige fiel heraus. Wer eine Regel nur am Fehlerfall testet, hat sie nur halb getestet.

Den ersten Treffer im Text soll eine Automatik nicht nehmen, sondern den besten. Unsere Dokumentenerkennung im Paperless hielt Modellbezeichnungen auf Rechnungen für ein Kennzeichen, brach danach ab und übersah das echte Kennzeichen weiter unten auf dem Blatt. In 388 von 17.076 Dokumenten ging so die Kundenzuordnung verloren. Jetzt hat der Fahrzeugbestand Vorrang vor dem ersten Fund, 1.449 falsche Treffer sind weg und kein einziges echtes Kennzeichen ist dabei verlorengegangen. Wer beim ersten Treffer aufhört, sucht nicht, er rät.

Ob ein Fehler am Server liegt oder am Rechner davor, verrät das Protokoll des Servers. Bei Vaultwarden scheiterte jede Einladung mit einer Meldung, die nach Server klang, also nach Ablauf, Zugang oder Mailversand. Im Protokoll stand zu den Klickversuchen jedoch kein einziger Aufruf: Die Oberfläche im Browser brach ab, bevor sie überhaupt fragte. Wo nichts ankommt, kann auch nichts falsch beantwortet werden, dann liegt die Ursache davor.

Eine leere Auswertung beweist nicht, dass nichts passiert ist, sie beweist oft nur, dass nichts aufgezeichnet wird. Ich habe im WLAN-Controller nach Verbindungsabbrüchen eines Geräts gesucht, keinen einzigen Eintrag gefunden und das fast als Entwarnung notiert. Dann habe ich die Tabelle selbst gezählt: null Datensätze insgesamt, für alle Geräte, seit Inbetriebnahme. Seitdem prüfe ich zuerst, ob eine Quelle überhaupt etwas liefert, bevor ich ihr Schweigen als Antwort nehme. Kein Befund ist noch kein Ergebnis.

Dreimal so viele Prozesse zählte ich, weil das Systemprotokoll bei jedem Absturz die komplette Liste noch einmal ausgibt. Bei drei Abstürzen standen dort 111 Einträge, tatsächlich liefen 37. Hätte ich der Zahl geglaubt, hätte ich einen größeren Server bestellt, statt die Obergrenze der Arbeitsprozesse von 89 auf 49 zu senken. Ein Protokoll zeigt Ereignisse, keine Bestände, und wer beides verwechselt, kauft die falsche Lösung.

Fast keine Suchbegriffe zeigt die Statistik, weil Google seltene Anfragen aus Datenschutzgründen gar nicht erst ausweist. Am ersten Messtag tauchten meine Seiten neunmal in den Ergebnissen auf, verteilt auf zehn Adressen, ausgewiesen war genau eine einzige Suchanfrage. Welche Seite gefunden wurde, konnte ich lesen, wonach gesucht wurde, noch nicht. Kleine Zahlen tragen keine feine Auswertung, und wer sie trotzdem deutet, liest sein eigenes Wunschbild.

Eine Warnung, die fast immer falsch ist, muss man reparieren, bevor irgendjemand anfängt nach ihr zu handeln. Meine neue Prüfung vergleicht die aus dem Beleg gelesene Fahrzeugnummer mit dem Stamm in Loco-Soft und markierte 124 Dokumente. Beim Durchsehen blieb genau ein echter Zahlendreher übrig, der Rest waren Lesefehler der Texterkennung und dreizehn Platzhalter-Nummern im Stamm, siebzehn Nullen und Doppelkreuze. Eine Lampe, die grundlos leuchtet, schaut nach kurzer Zeit niemand mehr an.

Ob ein Fehler im Protokoll neu ist, weiß man erst, wenn man ihn im alten Zustand nachzählt. Nach dem Umzug unseres Dokumentenarchivs auf eigene Hardware meldete das Protokoll rund zweihundert Mal am Tag, die Datenbankverbindung sei geschlossen, und ich hielt das prompt für eine Folge des Umzugs. Im alten Container stand dieselbe Meldung 320 Mal, seit Monaten, ohne jeden Schaden: die Software baut die Verbindung einfach neu auf. Ein Fehler, der auffällt, weil man gerade hinsieht, ist deshalb noch keiner, der gerade entstanden ist.

Dass dasselbe Programm im einen Browser alles zeigt und im anderen nichts, liegt fast immer am Rechner davor, nicht am Server. Bei unserem Passwort-Tresor Vaultwarden hatte sich die Erweiterung im einen Browser still auf die Juli-Fassung aktualisiert, im anderen lief noch die vom Juni. Die neuere stolperte über ein altes Feld: leere Liste, kein Fehler, Anmeldung ganz normal. Deshalb führte die Suche im Protokoll ins Leere, es gab dort nichts zu finden. Wenn zwei gleiche Arbeitsplätze sich verschieden verhalten, steckt die Ursache in dem, was sie unterscheidet.

Null kopierte Dateien heißt nicht, dass die Sicherung steht, es kann schlicht der Betriebsrhythmus sein. Unser Abgleich in den externen, unveränderlichen Speicher meldete über Tage null neue Dokumente, und ich war schon dabei, den Fehler zu suchen: es war Wochenende, und samstags wie sonntags scannt in der Werkstatt niemand. Die Gegenprobe war nicht das Protokoll des Absenders, sondern die Dateiliste am Ziel. Eine Sicherung beweist man dort, wo sie ankommt, nicht dort, wo sie losgeschickt wird.

Bei einer Rufumleitung klingelt sofort alles mit, weil die Zahl im Rufprofil die Dauer eines Schrittes meint und keine Verzögerung. In unserer AGFEO ES 546 habe ich für die Anmeldung einen Ablauf gebaut: dreißig Sekunden nur der Apparat am Tresen, danach zehn Sekunden Apparat und Zweitgerät gemeinsam, dann die Voicebox. Ich hatte die zehn Sekunden als Wartezeit gelesen und lag daneben, denn alle Ziele eines Blocks läuten gleichzeitig. Eine Zahl im Konfigurationsfeld sagt nicht, was sie bedeutet, das sagt erst der Testanruf.

Eine alte Firmen-Website, die noch online steht, schadet, weil sie der neuen Konkurrenz macht. Bei mir liefen zwei Adressen aus der Vergangenheit weiter, eine alte Marken-Domain und eine alte WordPress-Seite, beide mit meinem Namen und sehr ähnlichen Texten. Für eine Suchmaschine sind das zwei Personen, die um dieselbe Aufmerksamkeit ringen. Ich habe jetzt nachgemessen: beide antworten mit einer dauerhaften Weiterleitung auf die eine Seite. Zwei Stimmen mit demselben Namen sind leiser als eine.

Wenn eine Übertragung mittendrin abbricht, bleibt eine unbrauchbare Datei liegen, die von außen aussieht wie eine fertige Sicherung. Bei uns scheiterte der nächtliche Offsite-Lauf beim Schreiben eines 3,4 Gigabyte großen Archivs auf die Storage Box am Arbeitsspeicher, und danach lag die Datei dort mit falscher Prüfsumme und einem Änderungsdatum aus dem Jahr 1970. Seitdem vergleicht das Skript nach jedem Lauf die Prüfsummen auf dem Ziel und meldet sich, wenn eine nicht passt. Eine halbe Kopie ist gefährlicher als keine, weil sie den Platz der ganzen einnimmt.

Ein grünes Backup beweist nicht, dass die Kopie außer Haus liegt, sondern nur, dass die Sicherung geschrieben wurde. Bei uns lief der Job monatelang sauber, während die Übertragung auf den externen Speicher stillstand, weil der Schlüssel dort nicht mehr akzeptiert wurde. Aufgefallen ist es erst beim Nachziehen: 107 Gigabyte auf einen Schlag. Seitdem meldet nicht nur jeder Job, sondern auch jeder Transfer, dass er angekommen ist. Erst die Kopie am zweiten Ort ist die Sicherung.

Die eingerichtete Speicher-Grenze griff im Ernstfall nicht, weil sie ohne Zeitlimit auf das Ende laufender Anfragen wartete. In unserem Dokumentenarchiv Paperless sollte ein Prozess oberhalb von einem Gigabyte sanft ersetzt werden, doch unter dem Dauerstrom eingehender Akten-Scans wartete der Austausch geduldig, während der Prozess binnen Minuten auf vier bis sechs Gigabyte wuchs und das System ihn schließlich hart beendete. Seit der Austausch nach 45 Sekunden erzwungen wird, hält die Grenze auch unter Last. Eine Grenze ohne Frist ist keine Grenze, sie ist eine Bitte.

Ein Duplikat erkennt man sicher an der Prüfsumme des Inhalts, nicht am Dateinamen. Beim Aufräumen doppelt eingespielter Belege in Paperless fiel mein Skript, als der genaue Abgleich ins Leere lief, auf den Titel zurück und löschte vier echte Rechnungen über einen Fahrzeugverkauf. Zurückgeholt habe ich sie aus dem Papierkorb, der 613 Einträge lang war. Seitdem vergleicht es nur noch über die Prüfsumme, und fehlt die, hält es an, statt zu raten. Zwei Namen ähneln sich leicht, zwei Inhalte nie.

Der Fehlerliste einer Automatik kann man nicht blind glauben, weder bei dem was fehlt noch bei dem was ankam. Nach einem Serverausfall lagen rund 235 Tresen-Belege eines ganzen Arbeitstags im Ordner für Fehlversuche, im Paperless-Archiv fehlten sie tatsächlich. Neun weitere Gruppen standen ebenfalls als Fehlversuch da und waren trotzdem doppelt angekommen. Erst der Abgleich Datei für Datei gegen das Zielsystem zeigte, was wirklich stimmt. Ein Programm weiß oft nur, ob es die Antwort gehört hat, nicht, ob die Arbeit getan wurde.

Ob eine Firewall wirklich dicht ist, prüft man von einem fremden Rechner aus, nicht aus dem eigenen Netz. Beim Absichern unseres neuen Hetzner-Servers zeigte mein Port-Scan hinter dem VPN einen offenen Port 80, der von außen gar nicht offen war. Erst die Prüfung von einem neutralen Host ergab das echte Bild: öffentlich erreichbar ist nur noch der Fernzugang. Eine Tür testet man von der Seite, von der ein Einbrecher kommen würde.

Ein überlasteter Server braucht nicht automatisch mehr Rechenleistung, oft fehlt nur Arbeitsspeicher. Unser cpx42 bei Hetzner lahmte, doch die CPU lag zu 62 Prozent im Leerlauf, während 4,3 Gigabyte in den langsamen Swap ausgelagert waren. Ein größerer Cloud-Server hätte teure Rechenkerne mitbezahlt, die wir nie gebraucht hätten, also nahmen wir stattdessen eine gebrauchte Maschine mit 256 Gigabyte RAM. Wer erst nachmisst, welcher Teil wirklich klemmt, kauft nicht den falschen Motor für ein Getriebeproblem.

Ein Fehler schlägt erst zu, wenn die Notkorrektur ausfällt, weil sie ihn vorher nur übertüncht hat. In unserem Dokumentenarchiv, Paperless, setzte eine vergessene Automatik jedem neuen Beleg einen Besitzer, und ein zweiter Schritt nahm ihn Sekunden später wieder weg. In jedem Test sah alles sauber aus. Erst als dieser Schritt an einem Ausfall scheiterte, blieben 208 Belege unsichtbar. Heute räumt das System den Besitzer selbst weg, ausfallsicher an der Quelle. Eine Abhilfe, die den Fehler ständig übermalt, ist kein Fix, sie verschiebt nur den Tag, an dem er auffliegt.

Beim Alten ist nach einer abgebrochenen Änderung nichts, das muss man jedes Mal nachsehen. Beim Umbau unserer Überwachung mit Uptime Kuma habe ich ein Feld im falschen Format zurückgeschickt, das Speichern brach mit einem Fehler ab, und trotzdem war die Alarm-Verknüpfung des Monitors danach gelöscht. Das Programm räumt erst auf und legt dann neu an, gescheitert ist nur der zweite Schritt. Ich habe hinterher alle neunundzwanzig Monitore nachgeprüft. Eine Fehlermeldung sagt, dass etwas nicht fertig wurde, nicht dass nichts passiert ist.

Dass ein Alarm im Ernstfall wirklich ankommt, weiß man erst, wenn man ihn einmal absichtlich auslöst. Bei uns war das Dokumentenarchiv sieben Stunden nicht erreichbar, und Uptime Kuma blieb stumm: der Monitor war nie mit einem Meldekanal verknüpft, sein Zeitlimit stand auf null, und der E-Mail-Kanal selbst zeigte auf einen toten Anschluss. Drei Fehler auf einmal, und jeder einzelne hätte jede Warnung verhindert. Aufgeflogen ist das erst, als wir eine Testmeldung schickten und keine ankam. Eine Überwachung, die man nie testet, überwacht am Ende nur sich selbst.

Im nächtlichen Kundenexport fehlten Telefon und E-Mail, weil dieser Export die Kommunikationsdaten schlicht nie mitzieht. Für unsere neue KI-Telefonannahme brauchte ich zu jeder anrufenden Nummer den passenden Kunden, und in der exportierten Tabelle standen zwar alle 7.495 Kunden, aber keine einzige Rufnummer. Erst über die zweite Schnittstelle von Loco-Soft kamen 5.764 Nummern zusammen. Eine Tabelle, die vollständig aussieht, ist damit noch lange nicht vollständig.

Eine amtliche Prüfung testet man, indem man einen echten Vorgang wieder auflöst, statt einen zu erfinden. Beim Umzug unserer AU-Software auf den neuen Rechner habe ich die verbuchte Untersuchung in AÜK Plus gelöscht, das gibt das Siegel frei, und die Messdaten vom Prüfgerät erneut geschickt, das verbraucht es wieder. Netto null, und die zentrale Datenbank erkennt den Datensatz an seiner Kennung wieder. Eine erfundene Untersuchung wäre offiziell gewesen, ein zweites Mal gegangener Weg ist nur ein Weg.

Das Prüfgerät kann sehr wohl die Ursache sein, und dann sucht man tagelang am falschen Ende. Ich war überzeugt, unser WLAN filtere die Druckersuche weg, und habe am Gateway extra einen Dienst nachgerüstet, damit die Geräte wieder gefunden werden. Dann habe ich mit dem Diensthandy gegengeprüft: alle drei Drucker sofort da. Auf meinem Laptop liefen neun VPN-Tunnel, die jede Suchanfrage abfingen. Den nachgerüsteten Dienst habe ich wieder abgebaut. Wer misst, misst immer auch sein Messgerät.

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.

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.

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.

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.

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.

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.

Ob eine neue Software im Betrieb ein Erfolg wird, entscheiden nicht die Techniker, sondern die Mitarbeiter, die täglich damit arbeiten. Unser neues Dokumenten-System Paperless lief seit über einer Woche technisch sauber, jeder Abgleich per Schnittstelle war grün, aber am Tresen fühlten sich die Kollegen wie Beta-Tester, weil frisch eingescannte Belege für sie unsichtbar blieben. Seitdem melde ich mich nach jeder Änderung als normaler Mitarbeiter an und prüfe, ob ein Tresen-Scan wirklich ankommt, statt nur der Technik zu glauben. Ein Update ist erst fertig, wenn es niemandem auffällt.

Dass eine Verbesserung nichts Bestehendes verschlechtert, stellt man sicher, indem man alt und neu über den kompletten Bestand laufen lässt, ohne etwas zu verändern. Bevor unsere überarbeitete Beleg-Erkennung live ging, die unserem lokalen Gemma-Modell die Kundennummern zuliefert, habe ich beide Fassungen read-only über 22.242 Archiv-PDFs geschickt: über dreitausend Kundennummern zusätzlich erkannt, keine einzige verloren, die wenigen Abweichungen einzeln geprüft. Erst diese Zahlen gaben die Freigabe für den Abend. Besser ist eine Änderung erst, wenn gemessen ist, dass nichts Vorhandenes verloren geht.

Wenn eine KI einen Betrag erfindet, der nirgends auf dem Beleg steht, lässt man das Feld lieber leer als falsch. Unser Belegleser mit Gemma schrieb einmal 164,50 Euro auf einen Werkstattauftrag, auf dem gar keine Summe stand, frei erfunden und trotzdem völlig plausibel. Seitdem trage ich einen Betrag nur ein, wenn zwei Quellen sich einig sind, der QR-Code auf der Rechnung oder KI und Textsuche gemeinsam. Steht die Zahl nur an einer Stelle, bleibt das Feld leer. Eine leere Zahl fällt auf und wird geprüft, eine erfundene wird gebucht.

Die Bildvorschau reicht nicht, wenn daneben das volle PDF liegt. Beim Import von über sechstausend Altdateien aus dem Werkstatt-Laufwerk lag zu jedem Beleg eine jpg-Vorschau und ein pdf mit fast gleichem Namen, also hielt ich beide für dasselbe in zwei Formaten. Der direkte Vergleich zeigte etwas anderes: die jpg ist nur grob aufgelöst, das pdf das eigentliche Dokument. Hätte ich nicht nachgesehen, wären tausende Belege in schlechter Qualität im Archiv gelandet. Gleicher Name heißt nicht gleicher Inhalt.

KI-erstellte Prüfungsfragen taugen nur zum Üben, wenn sie kein Muster verraten. Als ich mir für die GP1-Prüfung Fragen zum Thema Bremsen bauen ließ, lag die richtige Antwort fast immer auf B und war die längste, ausführlichste Option. So knackt man die Frage allein am Muster, ohne ein Wort Fachwissen, und geübt hat man am Ende nichts. Seitdem lasse ich alle vier Antworten gleich lang halten und die Lösung zufällig über A bis D streuen. Ein Test, den man ohne Wissen besteht, misst kein Wissen.

An einer unterbrochenen Relaisspule misst man nicht unendlich, weil parallel zur Spule ein Löschwiderstand liegt. Beim Lernen für die GP1 schlug ich ein Relais im Tabellenbuch nach und begriff: ist die Spule durch, zeigt das Messgerät den Löschwiderstand, nicht die erwartete Unterbrechung. Der Widerstand baut beim Abschalten die Selbstinduktionsspannung ab und schützt die Kontakte. Ein zweiter Weg neben dem gesuchten kann einen Bruch verdecken, also muss man wissen, was sonst noch parallel liegt, bevor man ein Messergebnis deutet.

Jeden Zweifelsfall dem Menschen vorlegen soll eine Automatik gerade nicht, sonst ertrinkt er in Rückfragen und schaut irgendwann gar nicht mehr hin. Bei der ersten digitalisierten Akte liefen acht Belege glatt durch, nur bei einem meldete das System einen Konflikt, weil die Texterkennung ein B und eine 8 in der Fahrgestellnummer verwechselt hatte. Genau dieser eine Fall gehört auf den Tisch, die anderen sieben nicht. Eine Automatik ist so viel wert wie die Ruhe, die sie schafft, nicht die Meldungen, die sie erzeugt.

Einen Tag, den niemand vergeben hat, hängt nicht der Code an, sondern das System selbst. In unserem Dokumentenarchiv Paperless bekam jeder eingelesene Beleg die Markierung ZU BEARBEITEN, obwohl mein Import-Skript sie nie setzte. Der Grund war eine einzige Voreinstellung: der Tag galt als Eingangskorb und wird damit automatisch an alles gehängt, was hereinkommt. Dieselbe Mechanik hatte schon einmal 581 Belege stumm markiert. Wenn etwas auftaucht, das du nicht gesetzt hast, such nicht im eigenen Code, sondern in den Voreinstellungen.

Ein falscher Gesundheitscheck kann einen laufenden Dienst lahmlegen, und genau das ist mir passiert. Als ich eine alte Domain stilllegte, prüfte der Healthcheck plötzlich die falsche Seite, meldete den Container als krank, und Traefik nahm daraufhin alle drei gesunden Webseiten vom Netz, obwohl der Server intern weiter sauber auslieferte. Erst der Blick auf den Health-Status statt auf die Konfiguration brachte mich zur Ursache. Ein Test, der das Falsche prüft, ist gefährlicher als gar keiner, weil er Gesundes für krank erklärt.

Manche Fehler bemerkt man erst, wenn ein Neuer dazukommt, weil alle anderen längst eingeloggt sind und aus dem Zwischenspeicher weiterlaufen. Bei unserem selbst gehosteten Chat über Matrix und Element kam kein frischer Login mehr durch die Startseite, jede bestehende Sitzung lief munter weiter, sodass tagelang niemand etwas merkte. Schuld war ein einziger Signaturschlüssel in einem Format, das der Browser beim Start nicht lesen konnte. Wer ein System nur mit dem eigenen, längst eingerichteten Zugang prüft, sieht genau die Tür nicht, durch die der Nächste hereinkommt.

Ein einziges Maß reicht nicht, um ein Bauteil als in Ordnung zu bewerten. Bei einer Bremstrommel in der Ausbildung habe ich nur den Durchmesser gegen die Verschleißgrenze von 201 Millimetern geprüft und sie freigegeben. Übersehen hatte ich die zweite Messung, längs und quer: 200,95 minus 200,75 macht 0,20 Millimeter Unrundheit, und ab 0,10 ist die Trommel oval und damit Ausschuss. Zwei Messungen an einem Teil sind fast nie Redundanz, sie prüfen eine zweite Eigenschaft.

Unsere KI-Bilder zeigten eine Tischlerei statt einer Kfz-Werkstatt, weil im Prompt der eigentliche Anker fehlte. Die erste Bildserie mit Nano Banana 2 war warm, ruhig und sauber belichtet, traf aber die Branche nicht: Holzwerkbank in einer Steinscheune statt Hebebühne und Motorraum. Erst als ich Auto, Diagnosegerät und freie Werkstatt ausdrücklich in jeden Prompt geschrieben habe, kam das, was gemeint war. Eine Maschine macht genau das, was dasteht, nicht das, was ich meine.

Der Anruf-Link führte ins Leere, weil nur die sichtbare Nummer stimmte, der im Link hinterlegte Wert aber fehlerhaft war. Im Impressum stand die Telefonnummer für das Auge sauber mit Vorwahl da, im tel-Verweis dahinter steckte sie in einer Form, die kein Telefon wählen kann. Beim bloßen Lesen fällt das niemandem auf, erst der Daumen auf dem Handy merkt es. Was man liest und was die Maschine wählt, sind zwei verschiedene Dinge, und am Telefon zählt nur das Zweite.

Wenn ein Drucker nicht druckt, liegt es oft nicht am Drucker selbst. Unser Kyocera war im Netz erreichbar, im Leerlauf und ohne eine einzige Fehlermeldung, während der Rechner hartnäckig bei Verbindung wird hergestellt stehen blieb. Der Fehler saß nicht im Gerät, sondern im Weg dorthin. Bevor man das Teure austauscht, prüft man besser die Leitung, die zu ihm führt.

Der Drucker hängt immer wieder, weil er bei jedem Auftrag erst per Funk im Netz gesucht werden muss. Unser Kyocera war über Bonjour angebunden, und mit der Zeit hatten sich fünf Warteschlangen für ein einziges Gerät angesammelt. Ich habe die vier Duplikate gelöscht und ihn auf seine feste IP-Adresse umgestellt, seitdem druckt er ohne Stocken. Eine feste Adresse ist verlässlicher als eine, die bei jedem Druck neu erraten wird.

Für eine Prüfung lernt man nicht alles, sondern gezielt das, was wirklich drankommt. Meine Gesellenprüfung Teil 1 im Sommer hat diesmal nur zwei Themen, Kühlsystem und Bremsanlage. Ich habe meine autoFACHMANN-Kurse damit abgeglichen und gesehen, dass die Fehlersuche am Kühlsystem schon zu hundert Prozent saß, 44 von 44 Punkten. So bleibt die ganze übrige Zeit für die Bremse, das einzige, was wirklich noch fehlt. Wer alles gleich wichtig nimmt, lernt am Ende nichts richtig.

Vor dem Kauf neuen Werkzeugs messe ich erst mit dem, was schon im Haus ist. Bei einem Reparaturprojekt stand ich kurz davor, für hunderte Euro Spezialwerkzeug zu bestellen, für einen Weg, den ich vielleicht nie gehen muss. Ein einziger Test mit einem J-Link, den wir längst in der Firma hatten, kostet nichts und konnte den ganzen teuren Ast überflüssig machen. Erst messen, dann bestellen, sonst kauft man Lösungen für Probleme, die man noch gar nicht hat.

Den Rechnungsbetrag lässt man besser von der KI lesen als von einer festen Textregel. Bei einem Test an fünf echten Rechnungen las unser lokales Modell, Gemma über Ollama, fünf von fünf Beträgen richtig, die alte Regel nur einen von fünf, weil sie viermal den Nettobetrag statt der Bruttosumme erwischte. Den Wert der KI nehme ich seitdem zuerst, die alte Regel läuft nur noch als stille Gegenprobe mit. Eine starre Regel trifft, was im Text zuerst steht, nicht das, was gemeint ist.

Dass eine lautlose Synchronisation seit Monaten Dateien verschluckt, merkt man erst, wenn man zählt. Auf dem Server lagen 25.929 Dateien, lokal nur 22.005, fast viertausend fehlten. Der klassische Nextcloud-Sync war seit dem ersten April tot, und der neue File Provider brach an einem einzigen nicht unterstützten Symlink die ganze Enumeration ab. Eine Fehlermeldung hatte ich nie gesehen, alles sah ruhig aus. Ein stiller Fehler ist gefährlicher als ein lauter, weil niemand nach ihm sucht.

Ein erfolgreicher Download heißt noch lange nicht, dass die richtigen Daten ankamen. Beim Beschaffen einer großen Geräte-Datenbank über die Kommandozeile galt mein Abruf als geglückt, und meine Abbruch-Bedingung griff sofort, doch geladen waren nur vierzehn Bytes einer Fehlerseite aus dem falschen Verzeichnis. Erst der zweite Versuch holte die echte Datei, knapp achtzehn Megabyte. Ein grünes Häkchen prüft, ob etwas ankam, nicht, ob das Richtige ankam.

Ungeprüft veröffentlicht eine KI bei mir gar nichts. Zwischen dem Modell, das die Notizen schreibt, und der Website sitzt ein fester Torwächter, ein Skript, das jeden Entwurf gegen Secrets, Stil, Schema und Dubletten prüft und alles Zweifelhafte in die Quarantäne legt. Erst was diese starren Regeln passiert, geht live, abgeglichen gegen fünfundachtzig bestehende Notizen. Eine Maschine darf schreiben, aber entscheiden, was öffentlich wird, soll eine Regel, nicht eine zweite Meinung.

Datumsfelder soll keine KI frei aus einem Dokument lesen, dafür gehört eine feste Regel. Beim ersten Praxiseinsatz unserer Beleg-Pipeline las das lokale Modell Gemma aus einem Datum 2026 schlicht 2024, und auf einem Personalausweis griff es das Ablauf- statt des Ausstellungsdatums. Seitdem ziehe ich strukturierte Felder wie Datum und Nummer per fester Regel, und die KI darf nur den Freitext deuten. Eine Maschine, die rät, soll das nur dort tun, wo Raten erlaubt ist.

Eine Fehlermeldung sagt nicht immer, wo der Fehler wirklich liegt. Eine iOS-App verweigerte die Verbindung zu meinem Paperless und meldete, das Backend unterstütze die nötige API-Version drei nicht. Tatsächlich spricht meine Version die API-Stufen eins bis sieben, die drei war also längst dabei und der Haken saß ganz woanders. Eine Meldung zeigt, was ein Programm gerade vermutet, nicht zwingend, was kaputt ist.

Eine Fahrzeugnummer darf eine KI nur nach festen Regeln geradebiegen, niemals nach Gefühl. In einer eigenen Funktion macht das System aus einem O eine Null, aus einem I eine Eins und aus einem Q eine Neun, weil eine Fahrgestellnummer diese drei Zeichen nie enthält. Danach prüft eine Regel hart auf genau siebzehn erlaubte Zeichen, sonst bricht es ab. Korrigieren darf nur, wer die Grenzen kennt, an denen das Korrigieren aufhört.

Ein großer Monitor kann eine wackelige Datenbank tatsächlich zum Kippen bringen, wenn auch nur auf Umwegen. Bei uns meldete ein einziger von vielen Rechnern immer wieder einen Verbindungsfehler zur Datenbank, der Anbieter schob es auf den Laptop. Tatsächlich rendert der Ultra-Wide-Bildschirm an diesem Platz die doppelte Zahl an Kalender-Terminen pro Seite, und das über zwanzig Jahre alte Programm feuert für jeden Termin eine eigene Abfrage, bis die ohnehin überlastete MariaDB kurz wegbricht. Der Fehler sitzt nie im Browser, sondern immer dort, wo die Abfrage landet.

Das Urteil. Eine KI liefert Vorschläge schnell und in Mengen, aber welcher davon stimmt, entscheidet ein Mensch. Genau diese Fähigkeit, das Brauchbare vom Plausiblen zu trennen, wird wichtiger, je besser die Werkzeuge werden. Wer sie schult, bleibt gefragt.

Ob eine Software noch gepflegt wird, erkennt man am Versionsverlauf, nicht an einem einzelnen Forenbeitrag. Bei der Suche nach einer Handy-App für unser Dokumentenarchiv Paperless las ich, das Android-Programm sei seit dem vergangenen Herbst aufgegeben. Die Veröffentlichungsseite zeigte aber Version 4.5.0 vom April, also ganz frische Arbeit. Erst der Blick auf die echten Releases, nicht auf das Gerücht, hat die Frage entschieden. Wer ein Werkzeug einführt, schaut auf das, was geliefert wird, nicht auf das, was jemand behauptet.

Nur mit Gegenprüfung. Eine KI hat mir beim Einrichten von Vaultwarden eine Einstellung empfohlen, die vollkommen plausibel klang und schlicht nicht existierte. Seitdem gleiche ich jede Konfig-Auskunft mit der offiziellen Vorlage oder dem Quellcode ab, bevor ich sie übernehme. Plausibel ist nicht dasselbe wie wahr, und eine KI sagt das Falsche genauso ruhig wie das Richtige.

Weil ein falsch gesetzter Schalter, den niemand dokumentiert hat, genauso wirkt wie ein großer Defekt. Bei der Mail-Einrichtung lag es am Ende an einem einzigen Port, 465 statt 587, der anders sein musste als überall beschrieben. Stunden hingen an einer Zeile. Wer sie findet und aufschreibt, schenkt dem nächsten den ganzen Tag.

Erst wenn ich ihn mit eigenen Augen geprüft habe, im Browser, am echten Fall. Erledigt im Kopf ist nicht erledigt in der Realität. Zwischen beiden liegt genau der Fehler, den sonst der Kunde findet. Umsetzen und nachprüfen sind ein Schritt, nicht zwei.