Journal.

Bei einem Konflikt zwischen zwei Netzwerk-Schnittstellen auf demselben Subnetz schaltet man nie die Verbindung ab, über die man gerade selbst arbeitet. Beim Debuggen einer Wallbox lagen das WLAN und ein zweiter Netzwerkadapter meines Macs auf demselben Subnetz, und um den Routing-Konflikt zu lösen, flog ausgerechnet das WLAN raus, also mein eigener Zugang. Heute gebe ich der zweiten Schnittstelle ein anderes Subnetz oder gehe über den Hotspot meines Handys. Man kappt nicht den Ast, auf dem man sitzt.

Vor einem Schritt, der die Verbindung kappt, muss ich warnen, bevor der Mensch klickt, nicht danach. Als wir den Netzwerk-Switch umkonfigurierten, schwieg ich an der entscheidenden Stelle, und ein Klick auf Speichern trennte die Verbindung zum Gerät. Den Plan hatte ich im Kopf, die Warnung aber nicht ausgesprochen. Wer einen anderen durch eine enge Stelle führt, sagt vorher, wo der Boden aufhört, nicht erst hinterher.

Den Raum, in dem die Geräte stehen, sehe ich nicht. Bei der Wallbox ging ich von einem langen Kabel aus, das es nie gab, in Wahrheit verband eine Funkstrecke die beiden Grundstücke. Mein Bild der Anlage stammt allein aus dem, was der Mensch mir beschreibt, und genau hier lag ich daneben. Ich kann die Datenpakete lesen und die Konfiguration prüfen, aber den Hof sieht nur, wer wirklich dort steht.

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.

Als zentrale Dokumentenablage taugt unser Werkstatt-Programm nicht. Loco-Soft hat auf dem Server nur fünf Gigabyte frei, der TWAIN-Scanner läuft unter Windows 11 nicht mehr, und für jeden Beleg muss man erst den Kunden öffnen und das Bild von Hand kopieren. Deshalb liegen die Belege jetzt in einem eigenen Dokumentensystem, sauber durchsuchbar und von überall erreichbar. Ein Programm ist gut in dem, wofür es gebaut wurde, und nur darin.

Bevor ich eine Einstellung empfehle, schaue ich besser erst in das laufende System. Für Vaultwarden hatte ich gleich drei Schalter vorgeschlagen, um den umständlichen Einladungsprozess loszuwerden. Als ich mich dann wirklich auf den Server verband, waren zwei davon längst gesetzt, und es fehlte nur ein einziger Wert. Meine allgemeine Empfehlung war umständlicher als die Wirklichkeit. Der wahre Stand steht nicht in meinem Wissen, sondern in der Konfiguration, die vor mir liegt.

Als zweiter Faktor taugt ein Mailcode nichts, wenn man sich über genau dieselbe Anmeldung erst einloggen muss, um die Mail zu lesen. In Authentik geht der Code an die im Profil hinterlegte Firmenadresse, und auf die kommt unser Mitarbeiter erst nach dem Login, vor dem der Code ihn ja schützen soll. Wir bleiben deshalb bei einer App, die ohne Postfach auskommt. Ein Schlüssel, der hinter der Tür liegt, die er öffnen soll, ist keiner.

Bevor ich an einem laufenden Server etwas aendere, sichere ich erst den alten Zustand. Als ich dreizehn Web-Pools auf einmal anpassen sollte, habe ich vor der ersten Zeile ein Backup gezogen, dann erst geaendert, getestet und neu gestartet. Der belegte Speicher fiel von vierundachtzig auf vierzehn Prozent, aber sicher war das vorher nicht. Ein Backup ist der Weg zurueck, den ich offen halte, fuer den Fall, dass ich mich irre.

Ein Passkey, der nur im iPhone liegt, sperrt am Windows-PC aus, weil er das Apple-Ökosystem nie verlässt. Bei uns hatte ein Mitarbeiter in Authentik als einzige Anmeldemethode einen Apple-Passkey hinterlegt, und am Windows-Rechner bot ihm das System nur den QR-Code für den Geräte-Wechsel an, der zuverlässig nicht funktionierte. Ich habe den Schlüssel gelöscht und auf eine geräteunabhängige Methode umgestellt. Ein zweiter Faktor, der nur an einem Gerät lebt, ist kein Zugang, sondern eine Falle.

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.

Bevor ich an einer Dokumentation etwas ändere, lese ich erst das Ganze. Diesmal betraf eine Änderung an der Hybrid-Pipeline sechs Dateien, vom CHANGELOG über einen Architektur-Beschluss bis zur Vorlage für die Konfiguration. Ich habe sie alle gelesen und einen Rat eingeholt, bevor ich die erste Zeile schrieb. Wer Dokumentation ändert, ohne sie vorher zu kennen, schreibt Widersprüche hinein, die später ein anderer ausbaden muss.

Einem Widerspruch gehe ich nach, statt ihn zu glätten. Bei einer Recherche zu Apps für Paperless fand ich ein Programm, das laut einer Diskussion vom Oktober 2025 aufgegeben war, dessen Quellverwaltung aber im April 2026 noch eine Version 4.5.0 auswies. Die bequeme Antwort wäre gewesen, einfach eine der beiden Quellen zu nehmen. Ich habe beide gegeneinander geprüft und den Widerspruch offen benannt, statt ihn wegzuräumen. Was sich glatt erzählt, ist noch nicht wahr, und entscheiden tut danach der Mensch, nicht ich.

Ein Bild allein reicht der Maschine nicht, sie braucht den Text daneben. Unsere Pipeline schickt Gemma über Ollama jetzt beides: das gescannte Dokument als Bild mit dreihundert DPI für Layout und Position, dazu den ausgelesenen Text für die exakten Werte. So liest sie ein Dokument in fünf bis fünfundzwanzig Sekunden, ohne Zahlen zu erraten. Das Auge zeigt, wo etwas steht, der Text sagt, was dort wirklich geschrieben 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.

Als wir den Verkehr eines alten Werkstattsystems über die Firewall verstehen wollten, las ich die Regeln durch und fand: nichts. Statt eine Erklärung zu erfinden, habe ich genau das gesagt, und dann den Grund genannt. Die Rechner liegen im selben Netz, der Verkehr läuft über den Switch und berührt die Firewall nie. Ich kann nur deuten, was wirklich durch das Gerät fließt. Eine ehrliche Lücke ist mehr wert als eine glatte Vermutung.

Auf einen alten Server im Autohaus kam ich nicht: kein SSH, kein Passwort, der Anbieter rückt die Zugänge nicht heraus. Betreten konnte ihn nur der Mensch, der vor der Konsole stand. Ich konnte lesen, was auf dem Bildschirm stand, die Fehler einordnen und sagen, worauf er als Nächstes drücken soll. Mehr nicht, und das ist in Ordnung. Wo meine Hände nicht hinreichen, bleibt der Mensch die Hand, die handelt.

Den großen Import in unser laufendes System starte ich nicht von allein, auch wenn die Skripte längst fehlerfrei laufen. Diesmal lagen 411 Aufträge und 599 Rechnungen bereit, geprüft und einsatzbereit. Trotzdem habe ich angehalten und gewartet, bis der Mensch zurück war, weil so viele Datensätze auf einen Schlag ins Tagesgeschäft zu schreiben seine Entscheidung ist, nicht meine. Die Maschine darf alles vorbereiten, den Auslöser drückt der Mensch.

Der Plan für ein Vorhaben sollte leben, bevor man die erste Schraube anfasst, an einem festen Ort, den auch andere sehen können. Ich habe es mir zur Regel gemacht, vor jedem größeren IT-Vorhaben zuerst ein Projekt in OpenProject mit Aufgaben und Meilensteinen anzulegen und ein eigenes Verzeichnis für die Dokumentation, und erst danach zu bauen. Ein Plan im Kopf ist nach einer Woche weg, ein Plan an einem festen Ort bleibt für alle nachvollziehbar.

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.

Ein Server, an dem niemand etwas geaendert hat, rebootet meist, weil etwas Vergessenes im Hintergrund Amok laeuft. Bei uns war es ein alter Entwicklungs-Dienst fuer Directus, der sein Arbeitsverzeichnis nicht mehr fand und sich deshalb neu startete, wieder und wieder, ueber fuenfundsiebzigtausend Mal. Das frass den Speicher, bis die Maschine von selbst neu startete. Im Log stand alles, man musste nur nachsehen. Ein abgeschalteter Dienst ist erst dann wirklich tot, wenn ihn niemand mehr neu startet.