Ein Nachmittag, ein KI-Agent, ein Mailserver ohne Experten

Ausgangslage

Ein Mailserver unter Ubuntu mit Postfix, seit Jahren im Betrieb, gewachsen und angepasst. Und niemand mehr im Haus, der ihn kannte — der Kollege, der ihn aufgesetzt und gepflegt hatte, war nicht mehr da.

Das ist keine Ausnahmesituation, sondern der Normalfall im Mittelstand. Systeme überleben die Menschen, die sie gebaut haben. Was bleibt, sind Konfigurationsdateien, die jemand vor Jahren aus guten Gründen so und nicht anders geschrieben hat, und ein Team, das sie nicht anfassen will, weil niemand weiß, was daran hängt.

Die üblichen Auswege sind beide teuer. Externe Postfix-Expertise einkaufen löst das akute Problem und hinterlässt dieselbe Lücke wie vorher. Das System ablösen ist ein Projekt, das niemand für einen laufenden Mailserver aufsetzen will.

Ansatz

Eine Arbeitssitzung mit dem IT-Team — am echten Problem auf dem echten Server, nicht an einem konstruierten Beispiel.

Der KI-Agent bekam Shell-Zugriff auf das System. Er konnte Logdateien und Konfiguration selbst lesen, Diagnosebefehle ausführen, Änderungen vornehmen und Dienste neu starten. Das Team saß daneben, verfolgte jeden Schritt und konnte jederzeit eingreifen.

Der Inhalt der Sitzung war ausdrücklich nicht „so bedient man dieses Werkzeug“. Es ging um die Arbeitsweise:

• Wie man ein Problem so beschreibt, dass ein Agent damit anfangen kann — Symptom, Zeitpunkt, was zuletzt geändert wurde, statt „die Mails kommen nicht an“
• Wie man prüft, was der Agent behauptet, bevor man es glaubt. Ein Agent, der eine Postfix-Direktive erklärt, kann sie falsch erklären; die Gegenprobe steht in der Konfiguration und im Log, nicht in der Antwort
• Wo man ihn stoppt. Welche Schritte man laufen lässt und welche man erst versteht, bevor man sie zulässt
• Wie man das Ergebnis festhält, damit die nächste Person nicht wieder bei null anfängt — was das eigentliche Problem hinter dem verschwundenen Wissen ist

Der Punkt, an dem es anders hätte laufen können

Voller Shell-Zugriff auf einem produktiven Mailserver — und das ist die umgekehrte Entscheidung zu praktisch allem anderen in diesem Portfolio.

Die Systeme, die ich baue, halten sich bewusst zurück. Die Lizenzauswertung empfiehlt und handelt nie. Das Kostenportal ändert nichts in der Cloud. Das Passwortportal verweigert die Herausgabe, wenn es den Vorgang nicht protokollieren kann. Überall dort ist Zurückhaltung richtig.

Hier war sie es nicht, und der Unterschied liegt nicht in der Technik, sondern in der Aufsicht.

Ein automatisiertes System läuft unbeaufsichtigt, wiederholt, auf Fällen, die niemand ansieht. Dort ist jede Schreiboperation ein Risiko, das sich vervielfältigt. Eine begleitete Arbeitssitzung ist das Gegenteil davon: ein Mensch sitzt daneben, sieht jeden Schritt, kennt den Kontext und kann abbrechen. Dem Agenten die Ausführung zu verweigern hätte hier nur bedeutet, dass jemand abtippt, was auf dem Bildschirm steht — das bringt Übertragungsfehler und keinen Sicherheitsgewinn.

Trotzdem war das Risiko real, und drei Dinge haben es tragbar gemacht: Es war eine Sitzung unter Aufsicht, nicht ein Dauerzustand. Postfix-Änderungen sind Konfigurationsdateien und Dienstneustarts, also rücknehmbar — kein Löschen von Daten. Und das Team hätte jeden Schritt auch von Hand ausführen können; es fehlte das Wissen, was zu tun ist, nicht die Berechtigung.

Wo eine dieser drei Bedingungen fehlt, gilt die Entscheidung nicht.

Ergebnis

Das Postfix-Problem war am selben Nachmittag gelöst. Das ist aber nicht das Ergebnis, das zählt.

Das eigentliche Ergebnis ist, dass das Team die Methode übernommen hat und sie inzwischen auf weitere Systeme anwendet, bei denen das Wissen im Haus fehlt. Der reparierte Mailserver war der Anlass, nicht das Produkt — geliefert wurde die Fähigkeit, sich einem unbekannten System zu nähern, ohne vorher Spezialist dafür zu sein.

Was diese Arbeitsweise nicht leistet, gehört dazu: Der Agent ersetzt kein Verständnis. Er verkürzt den Weg zur Ursache, aber wer nicht prüft, was er behauptet, tauscht nur eine Abhängigkeit gegen eine andere — vom Kollegen, der gegangen ist, zum Modell, das plausibel klingt. Genau deshalb war das Prüfen der Behauptungen der längste Teil der Sitzung, nicht das Ausführen.