Was, wenn der Operator Mist baut? Warum Fehler eingeplant sind.

Diese Frage kommt in jedem ernsthaften Gespräch über KI-Operatoren, meistens als Letztes und immer im selben Tonfall: Ja, schön, aber was passiert, wenn das Ding Mist baut?

Es ist die richtige Frage. Nur die übliche Antwort taugt nichts. Die übliche Antwort lautet, dass die Modelle immer besser werden und der Fall damit seltener wird. Das mag stimmen und hilft trotzdem nicht, denn seltener ist nicht nie, und ein Unternehmen, dessen Plan für den Fehlerfall auf Seltenheit beruht, hat keinen Plan.

Ein System, das nur funktioniert, solange nichts schiefgeht, ist kein System. Es ist eine Wette.

Der Fehler ist eingeplant, nicht überraschend

Wer aus der Fertigung kommt, kennt diese Haltung. Dort geht niemand davon aus, dass eine Maschine nie außerhalb der Toleranz produziert. Man plant den Fall ein: Prüfung an definierten Punkten, klare Kriterien, ein definierter Weg, wenn das Teil durchfällt. Genau diese Übersetzung in die Wissensarbeit ist die Grundlage von Rocket Routine OS.

Ein KI-Operator wird Fehler machen. Er wird etwas falsch verstehen, eine Nuance verfehlen, eine Formulierung überstrapazieren, eine Ausnahme übersehen. Die interessante Frage ist deshalb nie, ob das passiert, sondern was dein System in diesem Moment tut. Vier Mechanismen greifen dabei ineinander, und keiner davon heißt "genauer hinschauen".

Erstens: verhindern, bevor es entsteht

Der billigste Fehler ist der, der gar nicht erst möglich ist. Poka Yoke heißt genau das, aus dem Toyota-Produktionssystem in die Wissensarbeit übersetzt: den Prozess so bauen, dass die Abweichung strukturell nicht entstehen kann, statt hinterher die Kontrolle zu verschärfen.

Bei einem KI-Operator sitzt das im Role Contract. Wenn dort steht, dass die Rolle nichts veröffentlichen darf, dann kann der Operator keinen schlechten Text online stellen, egal wie überzeugt er davon ist. Der Fehler ist damit nicht ausgeschlossen, aber sein Wirkungsradius ist es. Das ist der Unterschied zwischen einem Fehler im Entwurf und einem Fehler beim Kunden.

Zweitens: früh abfangen

Was trotzdem entsteht, muss auffallen, bevor es ausgeliefert wird. Dafür gibt es die Qualitätsbestätigung: eine definierte Prüfung gegen einen definierten Standard, nicht ein Bauchgefühl beim Drüberlesen. Die Kennzahl dazu ist die FTT (First Time Through), der Anteil der Arbeitseinheiten, die diese Prüfung im ersten Anlauf ohne Nacharbeit bestehen.

Die FTT ist mehr als eine Qualitätszahl. Sie ist das Frühwarnsystem. Sinkt sie über mehrere Durchläufe, sagt dir das etwas über den Operator, den Standard oder die Aufgabe, lange bevor jemand ein Ergebnis beim Kunden sieht.

Drittens: sauber eskalieren

Manche Fälle darf der Operator nicht selbst entscheiden. Dafür stehen im Role Contract Eskalations-Trigger: konkrete Schwellenwerte und Bedingungen, bei denen ein Fall die Ebene wechselt. Fällt die FTT unter einen definierten Wert, berührt eine Routineaufgabe plötzlich eine grundsätzliche Frage, stößt der Operator an seine eigenen Grenzen, dann geht der Fall nach oben, weil die Regel es vorschreibt und nicht, weil zufällig jemand aufmerksam war.

Welche Entscheidung überhaupt auf welcher Ebene gehört, ist vorher geklärt und nicht Verhandlungssache im Ernstfall. Das ist die Zuordnung nach Wirkung, Root, Trunk, Branch, Leaf, und sie entscheidet auch, was dich tatsächlich erreicht.

Viertens: zurückstufen, wenn nötig

Verantwortung ist bei einem KI-Operator kein Schalter, sondern eine Stufe. Über die Adoption Levels arbeitet sich eine Rolle von Shadow über Copilot bis Autopilot nach oben, und zwar auf Basis gemessener FTT-Evidenz.

Diese Leiter funktioniert in beide Richtungen. Häufen sich die Fehler auf Autopilot, geht die Rolle zurück auf Copilot, bis die Evidenz wieder stimmt. Das ist die unspektakulärste und wirksamste Antwort auf die Ausgangsfrage: Ein Operator, der Mist baut, verliert Reichweite, nicht das Unternehmen Geld. Die Rückstufung ist dabei kein Misstrauensvotum, sie ist die normale Reaktion eines Systems auf Daten.

Company 0: zwei Fehler, zwei Regeln

Das lässt sich schlecht behaupten und leicht zeigen, deshalb an unserem eigenen Betrieb. Die Content-Produktion bei Rocket Routine läuft über einen KI-Operator, ich prüfe und gebe frei.

In einem Review fielen elf Stellen in einem einzigen Artikel auf, an denen der Operator zur selben rhetorischen Konstruktion gegriffen hatte. Kein Drama, aber ein Muster, das Texte nach Maschine klingen lässt. In einem späteren Review fiel mir auf, dass derselbe Operator das Verb "tragen" dreimal in einem Text benutzt hatte, zweimal davon unidiomatisch.

Beide Male war der Fix nicht, den einen Artikel zu glätten. Beide Male wurde daraus eine Regel in den Edit-Patterns, die den Operator ab sofort bei jedem Text bindet: höchstens eine dieser Konstruktionen pro Artikel, und "tragen" höchstens einmal. Dieser Artikel hier ist unter beiden Regeln geschrieben.

Der Operator, der den Fehler gemacht hat, ist derselbe, der ihn jetzt nicht mehr machen kann, weil die Korrektur im System liegt und nicht im Gedächtnis einer Person.

Das ist der eigentliche Punkt. Ein Learning ist erst real, wenn es ein Artefakt ändert. Sonst hast du ein nettes Gespräch geführt und beim nächsten Durchlauf dasselbe Problem.

Was das für dich heißt

Wenn dich die Frage nach dem Fehlerfall umtreibt, ist das ein gutes Zeichen. Sie ist nur an der falschen Stelle gestellt, solange sie auf das Modell zielt. Stell sie an dein System und beantworte vier Dinge:

• Was kann der Operator strukturell gar nicht kaputt machen, weil sein Zugriff dort endet?
• Woran wird geprüft, ob ein Ergebnis den Standard erfüllt, und wer sieht diese Zahl?
• Welcher konkrete Schwellenwert zieht einen Fall zu einem Menschen hoch?
• Was passiert nach einem Fehler mit dem Artefakt, das ihn zugelassen hat?

Bleibt eine dieser Fragen offen, ist die ehrliche Antwort auf "was, wenn der Operator Mist baut" im Moment: Dann merkt es hoffentlich jemand. Das ist der Zustand, aus dem ein Betriebssystem herausführt.