An einem Tag verschickte eines meiner Überwachungssysteme 83 Alarme mit der Meldung, Zugangsdaten seien geändert worden. Geändert wurde nichts. Am nächsten Morgen erklärte ein zweites System zwei laufende Server für ausgefallen. Beide hatten sauber gemessen — und beim Zusammenfassen die entscheidende Unterscheidung verloren. Daraus lässt sich ein Prüfkatalog ableiten, der für jeden Bot gilt, der mit echten Menschen spricht.
Wer unterhält sich ernsthaft mit einem Bot?
Diese Frage stand am Anfang eines Austauschs über Beschwerde-Bots. Die Antwort ist unbequem: Ich selbst. Bei einem großen Mobilfunkanbieter habe ich eine Beschwerde vollständig über den Bot abgewickelt — erst Anmeldung mit den eigenen Kennungen, dann der geführte Dialog. Am Ende stand eine Gutschrift, schneller als über jede Hotline.
Der Haken: Sie kam schneller, als sie hätte kommen dürfen. Der Bot hat an einer Stelle falsch abgebogen und großzügiger entschieden, als der Fall es hergab. Für mich war das komfortabel. Für den Betreiber war es ein Fehler, der niemandem auffiel, weil das Ergebnis nach einem gültigen Vorgang aussah.
Genau das ist das Muster, um das es hier geht. Nicht der Bot, der abstürzt — der fällt sofort auf. Sondern der Bot, der überzeugend das Falsche tut.
Fall 1: 83 Alarme über einen Vorfall, den es nie gab
Ein Überwachungsdienst auf einem meiner Server protokolliert Zugriffe auf Dateien mit Zugangsdaten. Wird eine dieser Dateien angefasst, geht eine Meldung raus. Sinnvolle Sache.
An einem Donnerstag kamen 83 dieser Meldungen. Alle mit demselben roten Text: Zugangsdaten geändert. Alle mit einer dreistelligen Ereigniszahl. Zum Vergleich: In den Monaten davor waren es drei bis fünf Meldungen pro Tag.
Die Auswertung der Rohdaten ergab ein eindeutiges Bild:
| Datei | Lesezugriffe | Schreibzugriffe |
|---|---|---|
| Konfigurationsdatei eines Dienstes | 1.807 | 0 |
| alle übrigen überwachten Dateien | je 1 | 0 |
Kein einziger Schreibzugriff. Die Datei war seit über einer Woche unverändert. Was tatsächlich geschah: Ein Dienst las seine eigene Konfiguration etwa 24-mal pro Minute — und die Überwachungsregel protokollierte neben Änderungen eben auch Lesezugriffe.
Der Alarmtext kannte diesen Unterschied nicht. Er zählte Ereignisse und nannte das Ergebnis geändert.
Das eigentliche Risiko ist dabei nicht die Belästigung. Es ist die Abstumpfung: Solange 320 harmlose Lesezugriffe pro Meldung durchlaufen, wäre ein echter Schreibzugriff auf eine Schlüsseldatei optisch nicht aufgefallen — er wäre nur eine etwas höhere Zahl in derselben Zeile gewesen.
Fall 2: Zwei Server, für ausgefallen erklärt, während sie antworteten
Am nächsten Morgen meldete ein anderes System — eine tägliche Zustandsübersicht meiner Server — zwei Rechner als nicht erreichbar. Rot markiert, mit der Empfehlung, dringend die Ursache des Ausfalls zu untersuchen.
Die Protokolle der beiden Server sagten das Gegenteil. Um 07:00:02 hatten sie die Verbindung angenommen und die Anmeldung bestätigt. Um 07:00:30 — also 29 Sekunden nach dem Start — lief der Abfragebefehl dort immer noch. Kein Ausfall. Nur eine Zeitüberschreitung, weil das Zeitlimit bei 15 Sekunden lag.
Der Grund für die Langsamkeit war eine Netzwerkstrecke, die über einen Umweg lief statt direkt. Aber das ist nicht der interessante Teil. Der interessante Teil steckt im Datenmodell:
| Was tatsächlich vorlag | Was gespeichert wurde |
|---|---|
| Verbindung kam nicht zustande — echter Ausfall | erreichbar: nein |
| Server antwortet, Abfrage nur zu langsam | erreichbar: nein |
| Angemeldet, aber Antwort unvollständig | erreichbar: nein |
Drei grundverschiedene Sachverhalte, ein einziges Ja-Nein-Feld. Und das Bittere daran: Die Unterscheidung war vorhanden. Neben dem Feld stand ein Fehlertext, und der war eindeutig verschieden — bei den beiden Servern hieß er sinngemäß Zeitüberschreitung, bei einem tatsächlich abgeschalteten Rechner Verbindung konnte nicht aufgebaut werden. Diesen Text hat schlicht niemand ausgewertet.
Der Punkt, an dem es für Bots gefährlich wird
Die Tageslage in Fall 2 wird nicht von einem Menschen geschrieben, sondern von einem Sprachmodell, das die verdichteten Daten vorgelegt bekommt. Seine Anweisung lautete: Server unerwartet nicht erreichbar, das ist ein kritischer Befund.
Das Modell hat exakt getan, was es sollte. Es hat aus erreichbar: nein einen Ausfall gemacht, den Vorgang sauber eingeordnet, eine plausible Vermutung zur Ursache formuliert und eine sinnvolle Empfehlung abgeleitet. Sprachlich einwandfrei. Inhaltlich falsch — weil die Prämisse falsch war.
Das ist die Lehre, die weit über Serverüberwachung hinausreicht: Ein Sprachmodell erbt jede Ungenauigkeit der Vorverarbeitung und gibt ihr eine überzeugende Form. Es korrigiert die Datenlage nicht, es formuliert sie aus. Ein Mensch, der dieselbe Zeile liest, stutzt vielleicht. Ein Modell, dem man gesagt hat, dieses Feld bedeute Ausfall, stutzt nicht.
Übertragen auf den Beschwerde-Bot: Der entscheidende Fehler passiert selten im Dialog. Er passiert dort, wo aus einem Gespräch eine Kategorie wird — Kulanzfall, berechtigte Reklamation, Härtefall. Ist diese Zuordnung zu grob, folgt alles Weitere korrekt aus einer falschen Grundlage. Und weil das Ergebnis wie ein regulärer Vorgang aussieht, prüft es niemand nach.
Ein Prüfkatalog, der Grenzfälle erzwingt
Aus beiden Fällen lässt sich ableiten, was ein Prüfkatalog leisten muss. Die üblichen Tests hätten hier nichts gefunden — bei sauberer Eingabe funktionierten beide Systeme einwandfrei. Diese Fragen hätten geholfen:
- Kann das System zwischen unterschiedlichen Fehlerarten unterscheiden, oder hat es nur ein Ja-Nein-Feld? Zusammengelegte Zustände sind die häufigste Ursache für plausible Falschmeldungen.
- Unterscheidet es einen Messfehler von einem Sachverhalt? Keine Antwort in fünf Sekunden ist eine Aussage über die Messung, nicht über den gemessenen Gegenstand.
- Wird Information beim Verdichten weggeworfen, die vorher vorhanden war? In beiden Fällen stand die Wahrheit in den Rohdaten und ging eine Stufe später verloren.
- Was passiert bei langsam statt bei kaputt? Der Grenzfall zwischen funktioniert und funktioniert nicht ist der am schlechtesten getestete Bereich überhaupt.
- Darf das System weiß nicht sagen? Ein Bot ohne diese Möglichkeit muss raten — und wird dabei überzeugend klingen.
- Lässt sich nachvollziehen, worauf eine Entscheidung beruhte? Ohne Protokoll der Entscheidungsgrundlage ist eine falsche Auskunft hinterher nicht rekonstruierbar.
Der wirksamste Test ist dabei der unbequemste: Grenzfälle absichtlich erzeugen. Ich habe die Reparatur in Fall 2 verifiziert, indem ich das Zeitlimit künstlich auf eine Sekunde gesetzt habe — ein Wert, bei dem die Abfrage unmöglich fertig werden kann. Erst dieser erzwungene Fehlerfall hat bewiesen, dass das System den langsamen Server jetzt korrekt als antwortet, aber zu langsam einordnet statt als ausgefallen.
Beim Beschwerde-Bot wäre das Äquivalent: nicht die klare Reklamation testen, sondern die widersprüchliche. Die, in der zwei Anliegen vermischt sind. Die, bei der die Kundennummer nicht zum Namen passt. Die, in der jemand mitten im Dialog das Thema wechselt.
Was ich daraus mitnehme
Wo der Bot am Ende steht, ist tatsächlich zweitrangig — Webseite, Messenger, Telefon. Entscheidend ist, ob er mit echten Inhalten geprüft wurde und ob er zugeben darf, dass er etwas nicht weiß.
Bei den beiden geschilderten Systemen habe ich die Zustände inzwischen getrennt und einen billigen Gegentest eingebaut: Läuft eine Abfrage in die Zeitüberschreitung, setzt das System einen minimalen Folgebefehl ab. Antwortet der Rechner darauf, ist bewiesen, dass er läuft — und die Meldung lautet nicht mehr ausgefallen, sondern zu langsam. Kosten: fünf Sekunden im Fehlerfall.
Der Aufwand für diese Unterscheidung war gering. Der Unterschied im Ergebnis ist erheblich: aus 83 Fehlalarmen an einem Tag wurden null, ohne dass die Überwachung an Substanz verliert. Echte Änderungen an Schlüsseldateien lösen weiterhin Alarm aus — jetzt aber sichtbar, weil sie nicht mehr im Rauschen untergehen.
In den nächsten Tagen folgen weitere Artikel aus dem echten Betrieb: Umgang mit Zugangsschlüsseln, Sicherung und Wiederherstellung, Notfallschlüssel und Notfallkarte. Alles Themen, bei denen dieselbe Frage wiederkehrt — woran erkennt man eigentlich, dass etwas funktioniert, und nicht nur, dass es eine Erfolgsmeldung geschrieben hat.
Transparenz: Die geschilderten Vorfälle stammen aus meiner eigenen Infrastruktur, die Zahlen sind gemessene Werte aus den jeweiligen Protokollen. Der Mobilfunkanbieter aus dem Einstieg wird bewusst nicht genannt — die Beobachtung stammt aus einem einzelnen persönlichen Vorgang und ist von außen nicht überprüfbar. Alle Projekte sind selbstfinanziert, es bestehen keine bezahlten Kooperationen. Der Artikel wurde mit KI-Unterstützung (Claude) recherchiert und geschrieben; die genannten Messwerte wurden gegen die Originalprotokolle geprüft, die redaktionelle Verantwortung liegt bei Marco Fuhrmann. Der Beitrag beschreibt technische Erfahrungen und stellt keine Rechtsberatung dar — insbesondere die Hinweise zum Umgang mit personenbezogenen Daten ersetzen keine datenschutzrechtliche Prüfung im Einzelfall.