Deine KI-Ersparnis steht im Prüfstau deines Teams

Du wirst es nicht an dir selbst merken. Brain Fry trifft die Leute, die prüfen, nicht die, die entscheiden. Bei dir kommt es als Kennzahl an: Die Fehlerquote steigt, obwohl alle mehr schaffen. Freigaben dauern länger. Jemand Gutes kündigt und nennt im Austrittsgespräch keinen Grund, den du beheben könntest.

Anfang März hat die Harvard Business Review den Begriff in Umlauf gebracht, dahinter steckt eine BCG-Studie mit 1'488 Vollzeitbeschäftigten in grossen US-Unternehmen. Der Befund: Wer den Tag damit verbringt, KI-Ergebnisse zu überwachen statt selbst etwas zu produzieren, berichtet mehr Fehler, mehr Entscheidungsüberlastung und häufiger die Absicht zu kündigen. Es sind Selbstauskünfte aus einer Umfrage, keine gemessenen Fehlerquoten. Die Richtung ist belastbar, die Nachkommastellen nicht.

Was du siehst, und was deine Leute erleben

Vor der KI hat dein Team fünf Vorgänge pro Woche geprüft, weil fünf entstanden sind. Heute entstehen fünfzig, weil ein Modell Code, Werbetexte oder eine ganze Landingpage in Minuten erzeugt. Die Erzeugung ist billig geworden, die Prüfung nicht. Der Stau steht jetzt vor der letzten menschlichen Instanz.

Für die Person auf diesem Stuhl ist das nicht einfach mehr Arbeit, sondern eine andere Arbeit. Aus dem Vorgang ist die gestaltende Hälfte verschwunden und die kontrollierende ist übrig geblieben. Wer beides hatte, erlebt den Rest als Verlust, auch wenn die Stückzahl steigt. Es fühlt sich an wie Fliessband, weil es eines ist.

Der für dich teuerste Teil des Befundes ist die Kündigungsabsicht. Es trifft nicht die Schwächsten, sondern die mit dem meisten Erfahrungswissen, denn nur die bekommen die Prüfung überhaupt zugeteilt. Und dieses Wissen ist nirgends dokumentiert, sondern steckt in ihren Köpfen. Das ist kein Personalthema, das ist ein Klumpenrisiko.

Der erste Fehler passiert in deiner Messung

Die Studie beschreibt Firmen, die den Token-Verbrauch ihrer Leute als Leistungsindikator belohnen. Das ist die extreme Variante eines verbreiteten Fehlers: Du misst die Hälfte, die billig geworden ist. Anzahl generierter Entwürfe, Adoptionsrate, ausgelieferte Pull Requests vor dem Review. Wer das belohnt, belohnt das Wachsen der Warteschlange.

Zwei Grössen sagen dir, was wirklich passiert. Erstens der Durchsatz bis zur Auslieferung, nicht bis zur Erzeugung. Zweitens die Zahl der Fehler, die trotz Prüfung durchgerutscht sind, gemessen an dem Punkt, an dem sie später auffallen. Steigt die erste Zahl nicht und die zweite schon, hast du keine Effizienz gekauft, sondern Tempo vor einer verstopften Stelle.

Prüftiefe zu differenzieren ist eine Erlaubnis, keine Technik

Nicht jeder Vorgang verdient dieselbe Tiefe. Ein Modell irrt nicht gleichmässig, sondern an bestimmten Stellen systematisch. Drei Grössen entscheiden gemeinsam: wie oft es hier danebenliegt, was der Fehler kostet, und ob er später ohnehin auffliegt. Ein Tippfehler im Newsletter ist häufig, billig und wird dir von der ersten Leserin gemeldet. Eine falsch gesetzte Berechtigungsprüfung ist selten, teuer und bleibt still, bis sie es nicht mehr ist.

Hier liegt der Punkt, den nur du lösen kannst. Kein Mitarbeiter prüft von sich aus oberflächlicher, denn im Fehlerfall steht er allein da. Ohne eine geschriebene Regel, welche Vorgangsklassen flach geprüft werden und wer die Konsequenz trägt, prüft jeder alles, aus Selbstschutz. Risikobasiertes Prüfen ist keine Methode, die man einführt, sondern eine Rückendeckung, die man gibt.

Ein KI-Review ist eine Investition mit Messpflicht

Der naheliegende Griff ist, ein zweites Modell vorprüfen zu lassen. Das kann funktionieren, es ist aber der schwächste der drei Hebel, und schlecht eingekauft verschlimmert er das Problem. Ein KI-Review erzeugt Findings, und Findings muss wieder jemand prüfen. Wenn zwei von drei Fehlalarme sind, hast du die Prüflast erhöht, und zwar mit genau der Sorte Arbeit, die ermüdet.

Bevor du so etwas ausrollst, lass die Trefferquote an zwanzig bereits geprüften Vorgängen messen. Zähle, was das Modell findet und was es erfindet. Ein Finding lohnt sich nur, wenn es billiger zu beurteilen ist, als die Stelle selbst zu suchen: mit Fundstelle, mit Verweis auf die verletzte Regel, mit konkretem Gegenvorschlag. «Der Text könnte klarer sein» kostet mehr, als es spart.

Das Wertvollste in deiner Abteilung steht nirgends

Menschen prüfen nicht willkürlich. Über Monate bildet sich ein Katalog: die Stellen, an denen es schon einmal schiefging, die Formulierung, die in der Freigabe immer beanstandet wird, die Zahl, die nie stimmt. Deine Leute arbeiten ihn ab, teils bewusst, teils ohne es zu merken. Dieser Katalog ist der eigentliche Wert der Prüfarbeit, und er verlässt das Haus mit der Person.

Lass ihn aufschreiben. Nicht an einem Vorgang, sondern an zehn, sonst hältst du Zufall für Muster. Was sich wiederholt, ist das Verfahren, der Rest sind Einzelfälle.

Der Haken ist banal und wird trotzdem fast immer übersehen: Wer fünfzig Vorgänge pro Woche prüft, hat keine Zeit dafür. Das passiert nicht nebenbei und nicht aus Eigeninitiative. Wenn du es willst, stellst du dafür Zeit frei und nimmst sie aus dem Durchsatz. Sonst passiert es nie, und das ist der häufigste Grund, warum dieser Ansatz scheitert.

Genau hier liegt auch der Unterschied zwischen normaler Anstrengung und Brain Fry. Wenn jemand bei dreissig von fünfzig Vorgängen dieselbe Korrektur macht und diese Korrektur nirgends hinfliesst, macht er sie nächste Woche wieder. Prüfen ermüdet nicht, weil es anstrengend ist, sondern weil es folgenlos bleibt. Jede Korrektur, die zum zweiten Mal gemacht wird, ist eine Regel, die noch niemand geschrieben hat.

Automatisieren, und zwar ohne Modell

Wenn die Regeln stehen, gehören sie in ein Werkzeug, das stur ist. Ein Workflow in n8n, ein Skript, ein Linter, ein Pflichtfeld im Formular. Was zählt, ist die Eigenschaft: gleiche Eingabe, gleiches Urteil, heute wie in drei Monaten.

Deshalb gehört an diese Stelle kein Sprachmodell. Ein Modell driftet. Es beurteilt denselben Vorgang morgen anders, es verschiebt sich mit dem nächsten Release, und niemand merkt es, weil das Ergebnis weiterhin plausibel klingt. Ein Prüfverfahren, das sich unbemerkt selbst ändert, ist kein Prüfverfahren, sondern eine zweite Meinung. Und die Regel bricht ab, statt durchzuwinken: Ein sichtbar gestoppter Vorgang ist billiger als einer, der still falsch durchläuft.

Was danach noch bei Menschen landet, sind die Spezialfälle. Dafür hast du sie eingestellt.

Drei Einwände, die stimmen

Der erste ist der Widerstand deiner Leute, und er ist berechtigt gemeint: Wer sein Prüfwissen aufschreibt, fragt sich, ob er sich überflüssig macht. Wenn du diese Frage nicht von dir aus beantwortest, bekommst du einen unvollständigen Katalog und merkst es nicht. Die ehrliche Antwort ist, dass der schwierige Teil bei ihnen bleibt und der stumpfe verschwindet, und dass sie das nur glauben, wenn du es vorher schriftlich sagst.

Der zweite ist der Kalibrierungsverlust. Wer nur noch Ausnahmen zu sehen bekommt, verliert das Gefühl für den Normalfall und hält bald alles für eine Ausnahme. Ein kleiner Anteil Normalfälle bleibt deshalb in der Stichprobe, nicht weil er nötig wäre, sondern weil er das Urteilsvermögen eicht.

Der dritte ist die Alterung. Ein Katalog prüft, was letztes Quartal schiefging. Wechselt das Modell, wechselt die Fehlerverteilung. Und nicht alles ist deterministisch prüfbar: Vollständigkeit, Form, Konsistenz, Zahlen, Grenzwerte und Verweise ja, ob ein Text gut ist nicht. Der automatisierbare Teil ist oft der kleinere. Er ist aber der ermüdende, und deshalb lohnt er sich.

Was du davon hast

Der Engpass verschwindet nicht. Er wandert weiter, zur Entscheidung, zur Verantwortung, zur Auslieferung. Das Ziel ist kein Betrieb ohne Engpass, sondern einer, in dem der Engpass nicht auf einem einzelnen Menschen sitzt, der ihn mit seiner Aufmerksamkeit bezahlt.

Was diese Person zurückbekommt, taucht in keiner Effizienzrechnung auf: die Pause, das Gespräch am Kaffeeautomaten, den Feierabend ohne Restrauschen. Das ist kein Wohlfühlargument. Es ist die Bedingung dafür, dass sie die schwierigen Fälle morgen noch erkennt, und die schwierigen Fälle sind die einzigen, die du ihr noch gibst.

Die KI hat deinem Team die schöne Hälfte der Arbeit abgenommen. Was übrig bleibt, automatisierst du, oder es kostet dich die Leute.