Seien wir ehrlich: Diese Zahl hätte auch aus einer schlechten Pointe stammen können. 71 zu 29. Fast schon zu sauber, um wahr zu sein. Ist sie aber. Die neue IBM IBV CHRO Study, veröffentlicht am 21. September, hat zwischen April und Juni 2026 zusammen mit Oxford Economics 1.500 CHROs in 21 Geografien und 23 Branchen sowie 8.800 Mitarbeitende in 28 Ländern befragt. Das Ergebnis ist keine Randnotiz aus einer HR-Konferenz. Das ist ein Weckruf für jeden, der gerade Agenten in seine Prozesse pumpt und glaubt, das Tempo allein sei schon der Fortschritt.
Die Lücke, die niemand einplant
Klartext: Wenn 71 Prozent der Personalchefs sagen, Supervising, Validating und Override von KI-Outputs sei die wichtigste Fähigkeit ihrer Belegschaft — und nur 29 Prozent der Belegschaft selbst diese Urteilskraft überhaupt als relevant einstuft, dann reden zwei Gruppen komplett aneinander vorbei. Die eine Gruppe baut Agenten. Die andere Gruppe soll sie kontrollieren. Aber kaum jemand aus der zweiten Gruppe hat verstanden, dass genau das ihr Job geworden ist.
Das Problem ist nicht mangelnde Intelligenz der Mitarbeitenden. Das Problem ist ein Missverständnis, das in den letzten zwei Jahren systematisch gewachsen ist: Wer glaubt, KI mache die Arbeit, der denkt logischerweise nicht darüber nach, wie er diese Arbeit prüft. Warum sollte er auch? Die Tools klingen selbstbewusst, liefern flüssige Antworten, wirken kompetent. Genau das ist die Falle. Fluency wird mit Richtigkeit verwechselt — und diese Verwechslung kostet am Ende Zeit, Geld und manchmal Reputation.
Die Studie zeigt noch etwas Bemerkenswertes: 60 Prozent der Mitarbeitenden fürchten laut Studie eine schleichende Erosion ihrer eigenen Fähigkeiten, an erster Stelle beim kritischen Denken. Die CHROs selbst sehen das ähnlich, aber mit anderer Gewichtung: 57 Prozent nennen Critical Thinking als Prioritätsskill, 48 Prozent explizit Human Judgment. Bei den Mitarbeitenden landen Critical Thinking und Problem Framing gemeinsam bei 49 Prozent — beide Seiten spüren also, dass hier etwas verloren geht. Nur reagiert bislang kaum jemand konsequent darauf.
Warum Override kein Nice-to-have ist
Vergessen Sie den Begriff „KI-Kompetenz“ für einen Moment. Der ist inzwischen so ausgelutscht, dass er fast nichts mehr bedeutet. Was die Studie eigentlich beschreibt, ist präziser: Es geht um die Fähigkeit, einen KI-Output anzuhalten, bevor er Schaden anrichtet. Override ist kein Bonus-Skill für Spezialisten. Override ist die letzte Verteidigungslinie, bevor ein Fehler das Unternehmen verlässt und beim Kunden, beim Amt oder in der Bilanz landet.
Und hier wird es unangenehm für viele Organisationen: 46 Prozent der CHROs geben an, in die AI-Strategie ihres Unternehmens gar nicht eingebunden zu sein. Fast die Hälfte. Die Personen, die theoretisch für Skills, Trainings und Verantwortlichkeiten zuständig wären, sitzen bei der Grundsatzentscheidung nicht am Tisch. Das ist, als würde man ein Flugzeug bauen und den Piloten erst nach dem Erstflug einweihen.
Wer glaubt, das sei übertrieben, sollte sich die andere Zahl ansehen: Organisationen, die ihre Workflows klar in human-led, AI-assisted und AI-executed aufteilen, erzielen laut Studie 18 Prozent Risikoreduktion und 20 Prozent Qualitätsverbesserung. Das ist kein Nischeneffekt. Das ist der Unterschied zwischen einem Prozess mit Leitplanken und einem Prozess ohne. Wer diese Klarheit nicht schafft, verzichtet freiwillig auf einen zweistelligen Qualitätsgewinn — und wundert sich dann, warum die Fehlerquote steigt, während alle von Effizienz reden.
Invisible Work: Die Arbeit, die niemand sieht — außer den CHROs
Ein Detail aus der Studie, das mir besonders hängen geblieben ist: 80 Prozent der CHROs berichten von „invisible work“ — also von der Arbeit, die entsteht, wenn Menschen KI-Outputs validieren, Fehler korrigieren, Kontext nachliefern oder Ausnahmefälle händisch bearbeiten müssen. Diese Arbeit taucht in keiner Produktivitätsmetrik auf. Sie wird nicht gefeiert, nicht bezahlt, nicht mal benannt. Sie passiert einfach, weil sie passieren muss, damit der schöne Automatisierungs-Case am Ende nicht im Chaos endet.
Gleichzeitig sagen laut Studie 43 Prozent der Mitarbeitenden: Wenn die KI Mist baut, landet die Schuld bei ihnen. Nicht beim System. Nicht beim Anbieter. Nicht beim Management, das den Agenten eingeführt hat. Bei ihnen. Das ist eine giftige Kombination: unsichtbare Mehrarbeit plus sichtbare Haftung. Wer sich wundert, warum die Zustimmung zu KI-Projekten in vielen Belegschaften eher sinkt als steigt, findet hier eine ziemlich plausible Erklärung.
Die harte Wahrheit: Wenn niemand offiziell für den Override verantwortlich ist, wird trotzdem irgendjemand dafür verantwortlich gemacht — meist informell, meist zu spät, meist die falsche Person.
Sicherheit beim Override: Wer traut sich überhaupt, Nein zu sagen?
An dieser Stelle wird die Studie richtig unbequem. Denn selbst dort, wo Unternehmen theoretisch wollen, dass Mitarbeitende einen KI-Output stoppen, fehlt oft das Fundament dafür: das Gefühl, das auch tun zu dürfen. 41 Prozent der CHROs glauben laut Studie, dass sich ihre Mitarbeitenden nicht sicher genug fühlen, um einen KI-Output zu challengen oder zu überschreiben. Nicht, weil sie es fachlich nicht könnten. Sondern weil die Konsequenzen eines falschen Widerspruchs unklar sind — und die Konsequenzen eines nicht erfolgten Widerspruchs eben auch.
Dazu passt eine weitere Zahl, die man sich zweimal durchlesen sollte: 36 Prozent der Befragten sprechen von unklarer Verantwortlichkeit, wenn ein KI-gestützter Prozess schiefgeht. Mehr als ein Drittel der Organisationen weiß im Ernstfall schlicht nicht, wer haftet, wer erklärt, wer aufräumt. Das ist keine Frage von Prozesshandbüchern, die man mal aktualisieren müsste. Das ist eine Frage von Führung, die sich vor der Antwort drückt, weil die Antwort unangenehm ist.
Interessant wird es, wenn man sich ansieht, was den Unterschied macht. Dort, wo CHROs die Ownership für KI-gestützte Entscheidungen bewusst als human-led definieren und die Verantwortung tatsächlich teilen, fühlen sich laut Studie 76 Prozent der Mitarbeitenden sicher genug, einen Output zu hinterfragen. Dort, wo die Rolle der Menschen nur als beratend, als „advisory“, definiert ist — ohne echte Entscheidungsmacht am Ende — sinkt dieser Wert auf gerade einmal 43 Prozent. Das ist keine kleine Delle. Das ist ein Unterschied von mehr als 30 Prozentpunkten, nur weil eine Organisation klar sagt: Der Mensch entscheidet, nicht nur der Mensch nickt ab.
Nickle LaMoreaux, CHRO von IBM, bringt es in der Studie auf den Punkt: Vertrauen in KI-Systeme entsteht nicht durch bessere Modelle allein, sondern dadurch, dass Menschen wissen, dass ihr Urteil zählt — und dass sie für dieses Urteil nicht bestraft werden. Genau das ist der Unterschied zwischen einer Organisation, die Override als Lippenbekenntnis behandelt, und einer, die es als echten Teil der Entscheidungsarchitektur verankert.
Was folgt daraus praktisch? Advisory-Rollen sind bequem für das Management, weil sie so aussehen, als würden Menschen eingebunden — ohne dass am Ende irgendjemand wirklich Macht über den Prozess hat. Genau diese Bequemlichkeit ist der Grund, warum in vielen Unternehmen die Sicherheit beim Override so niedrig bleibt. Wer will schon einen Kampf riskieren, dessen Ausgang ohnehin feststeht, weil die eigene Stimme rein beratend ist?
Was ein echtes Judgment-Gate eigentlich braucht
Machen Sie sich nichts vor: Ein Judgment-Gate ist kein Kästchen in einem Prozessdiagramm, das man nachträglich einzeichnet, um die Compliance-Abteilung zufriedenzustellen. Ein echtes Gate braucht drei Dinge, die in den seltensten Unternehmen alle drei vorhanden sind.
- Einen klar benannten Owner, der die Befugnis UND die Zeit hat, einen KI-Output zu stoppen — nicht nur theoretisch, sondern in der Praxis, ohne dass er dafür eine Eskalationskette durch drei Abteilungen ziehen muss.
- Eine Definition, wann ein Fall automatisch an einen Menschen geht — bevor er live geht, nicht danach, wenn der Kunde sich schon beschwert hat.
- Eine Kultur, in der Override nicht als Bremsklotz für die Effizienz gilt, sondern als das, was es ist: die eigentliche Wertschöpfung dieser ganzen Automatisierungswelle.
Ohne diese drei Elemente bleibt jede Skills-Initiative Kosmetik. Man kann Mitarbeitende in „Kritischem Denken“ schulen, so viel man will — wenn am Ende niemand die formale Erlaubnis hat, einen Agenten-Output tatsächlich zu kippen, bleibt das Training folgenlos. Genau das erklärt, warum trotz aller Trainingsbudgets die Judgment-Lücke in der Studie so groß bleibt.
Ähnliche Muster sehen wir übrigens auch in anderen Bereichen der Automatisierung. Bei der Skills-Debatte rund um Salesforce und Agentforce taucht die gleiche Frage auf: Wer definiert eigentlich, wann ein Agent zu weit gegangen ist? Und in technischeren Kontexten, etwa bei Context Engineering mit Graphdatenbanken, zeigt sich: Je komplexer die zugrunde liegenden Datenstrukturen, desto schwieriger wird es, im Nachhinein zu erklären, warum ein Agent eine bestimmte Entscheidung getroffen hat. Ohne Gate an der richtigen Stelle wird diese Erklärung erst gesucht, wenn der Schaden schon passiert ist.
Genau das ist der Punkt, an dem viele Unternehmen sich selbst in die Tasche lügen. Sie messen Nutzungsraten, Zeitersparnis, generierte Outputs — und nennen das Erfolg. Aber Fluency ist nicht Judgment. Ein Sprachmodell, das flüssig und selbstsicher antwortet, ist nicht automatisch ein Modell, das richtig liegt. Wer diesen Unterschied nicht institutionalisiert — durch echte Gates, echte Owner, echte Eskalationswege — der beschleunigt am Ende nur die Geschwindigkeit, mit der Fehler passieren. Schneller falsch ist nicht besser als langsamer falsch. Es ist nur teurer in der Aufräumphase.
Judgment built-in vs. Judgment nachträglich: Warum Vertrauen kein Zufall ist
Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptOffice desk with closed laptop and judgment-gate sticky notes, soft daylight, photorealistic, no logos, no brand names, no readable text, 16:9Es gibt in der Studie eine Zahl, die eigentlich in jede Vorstandspräsentation zum Thema KI-Rollout gehört: In Organisationen, die menschliches Urteil von Anfang an in den Workflow einbauen — also nicht als nachträgliche Kontrolle, sondern als festen Bestandteil der Architektur — steigt laut Studie bei 62 Prozent der Mitarbeitenden das Vertrauen in die eigenen KI-gestützten Prozesse. In Organisationen, die das nicht tun, sinkt dieses Vertrauen bei 57 Prozent. Zwei fast identische Prozentwerte, aber mit komplett entgegengesetztem Vorzeichen — je nachdem, ob Urteilskraft mitgedacht oder nachträglich draufgeklatscht wird.
Das ist der eigentliche Kern der ganzen Debatte. Vertrauen in KI ist kein Ergebnis von besseren Modellen, mehr Trainingsdaten oder glänzenderen Demos. Vertrauen entsteht, wenn Menschen wissen, dass ihr Urteil im Prozess einen festen Platz hat — nicht als Feigenblatt, sondern als echte Entscheidungsinstanz. Wird Judgment nachträglich eingebaut, als Reaktion auf einen Vorfall, wirkt es wie eine Bestrafung: Jetzt müssen wir extra kontrollieren, weil etwas schiefgegangen ist. Wird es von Anfang an mitgedacht, wirkt es wie ein Qualitätsmerkmal: Hier wird bewusst entschieden, wo der Mensch das letzte Wort hat.
Der Unterschied zwischen 62 Prozent steigendem und 57 Prozent sinkendem Vertrauen ist im Kern eine Designentscheidung. Keine technische. Eine organisatorische. Und sie fällt lange bevor der erste Agent live geht — nämlich in dem Moment, in dem jemand entscheidet, ob Judgment ein Baustein der Architektur ist oder ein Reparaturversuch nach dem ersten Vorfall.
Fluency ohne Urteil: Amit Das‘ unbequeme Formel
Amit Das, Director und CHRO bei Bennett Coleman & Co. (The Times of India), wird in der IBM-Studie mit einem Satz zitiert, der es wert ist, wörtlich wiedergegeben zu werden: „Fluency without judgment simply helps an organization make mistakes faster.“ Auf Deutsch: Sprachliche Gewandtheit ohne Urteilskraft hilft einer Organisation lediglich dabei, Fehler schneller zu machen.
Das ist keine nette Pointe für eine Präsentation. Das ist eine Diagnose. Jedes Modell, das flüssig, selbstsicher und überzeugend klingt, verschleiert genau das Risiko, das hinter dieser Flüssigkeit steckt: Man merkt den Fehler oft erst, wenn der Output längst im System weiterverarbeitet wurde. Ohne eingebautes Urteil beschleunigt jede neue Modellgeneration also nicht automatisch den Erfolg — sie beschleunigt im Zweifel auch das Tempo, mit dem falsche Entscheidungen durchs Unternehmen laufen.
Wer diesen Satz ernst nimmt, verändert die Reihenfolge seiner Prioritäten. Nicht: Erst Fluency, dann irgendwann Kontrolle. Sondern: Kontrolle ist die Voraussetzung dafür, dass Fluency überhaupt einen Wert hat. Genau darin liegt der Unterschied zwischen einer Organisation, die KI nutzt, und einer Organisation, die von KI benutzt wird.
Wer trägt die Verantwortung, wenn niemand sie tragen will?
Die Zahl mit dem invisible work — 80 Prozent der CHROs, die diese unsichtbare Zusatzarbeit wahrnehmen — verdient noch mal einen genaueren Blick. Denn sie zeigt ein strukturelles Problem, das über einzelne Teams hinausgeht. Wenn Validierung, Fixes und Ausnahmebehandlung als Nebenprodukt der Automatisierung entstehen, aber in keiner Rollenbeschreibung, keinem Kapazitätsplan und keiner Bonusstruktur auftauchen, dann wird diese Arbeit systematisch unterschätzt. Und was unterschätzt wird, wird auch unterbesetzt.
Das Ergebnis: Die Person, die den Fehler am Ende bemerkt — oder nicht bemerkt — arbeitet oft unter Zeitdruck, ohne offiziellen Auftrag, ohne Rückendeckung. Kein Wunder, dass 43 Prozent der Mitarbeitenden das Gefühl haben, im Schadensfall selbst am Pranger zu stehen. Diese Wahrnehmung ist nicht paranoid. Sie ist eine ziemlich präzise Beschreibung der aktuellen Realität in vielen Organisationen — verstärkt durch die 36 Prozent, die unklare Verantwortlichkeit beim Namen nennen, und die 41 Prozent CHROs, die selbst zugeben, dass ihre Belegschaft sich beim Widerspruch nicht sicher fühlt.
Meine persönliche Meinung dazu, unverblümt: Ein Unternehmen, das Agenten einführt, aber keine explizite Verantwortungskette für Fehlerfälle definiert, handelt fahrlässig gegenüber der eigenen Belegschaft. Punkt. Man kann nicht Effizienzgewinne feiern und gleichzeitig die Frage „Wer haftet, wenn’s schiefläuft?“ unbeantwortet lassen. Das ist keine Detailfrage für die Rechtsabteilung. Das ist eine Führungsfrage, die auf Vorstandsebene gehört — und, wenn man es ernst meint, auch eine Frage für die Regulierung. Wer sich mit den kommenden Berichtspflichten rund um KI-Kompetenz und Enforcement auf EU-Ebene beschäftigt, merkt schnell: Unklare Accountability wird nicht nur intern zum Problem, sie wird irgendwann auch dokumentationspflichtig.
Die 18 und 20 Prozent, die zu wenige nutzen
Zurück zu den positiven Zahlen, weil sie zeigen, dass der Weg nicht kompliziert ist — er wird nur selten konsequent umgesetzt. 18 Prozent weniger Risiko, 20 Prozent mehr Qualität — das ist der Effekt, wenn Organisationen ihre Workflows tatsächlich in human-led, AI-assisted und AI-executed unterteilen. Keine komplizierte Technologie nötig. Keine neue Softwarelizenz. Nur die Bereitschaft, ehrlich zu benennen, wo ein Mensch das letzte Wort hat und wo eine Maschine allein entscheiden darf.
Das Problem: Diese Klarheit fehlt in den meisten Organisationen komplett. Man spricht von „KI-unterstützten Prozessen“, ohne je zu definieren, was genau unterstützt heißt. Bekommt der Mensch am Ende die Entscheidung vorgelegt, oder nur eine nachträgliche Benachrichtigung? Kann er den Output tatsächlich stoppen, oder läuft der Prozess längst weiter, während er noch liest? Diese Unschärfe ist der eigentliche Nährboden für die Judgment-Lücke, die die Studie so deutlich zeigt.
Was CHROs jetzt konkret tun müssten
Genug Analyse. Was folgt daraus praktisch? Vier Dinge, die keine Raketenwissenschaft sind, aber Konsequenz erfordern.
- CHRO in die AI-Strategie holen — von Anfang an, nicht als nachträgliche Info-Runde. 46 Prozent Nicht-Einbindung ist keine Randnotiz, das ist ein struktureller Fehler mit Ansage. Wer Skills, Trainings und Verantwortlichkeiten organisiert, muss wissen, was technisch überhaupt geplant ist — bevor es live geht.
- Override-Owner explizit benennen, pro Prozess, nicht pro Abteilung. „Das macht dann irgendwer im Team“ ist keine Governance. Das ist ein Blackout, der auf den nächsten Vorfall wartet.
- Invisible Work sichtbar machen — in Kapazitätsplänen, in Metriken, in Gehaltsgesprächen. Wer validiert, korrigiert und Ausnahmen bearbeitet, leistet echte Arbeit. Diese Arbeit gehört gemessen, nicht wegdiskutiert.
- Ownership human-led definieren, nicht nur advisory. Der Unterschied zwischen 76 Prozent und 43 Prozent Sicherheit beim Override entsteht genau hier. Beratung ohne Entscheidungsmacht erzeugt Unsicherheit, keine Kontrolle.
Keiner dieser vier Punkte erfordert ein neues Tool. Sie erfordern Führungsentscheidungen, die manchmal unbequem sind, weil sie Verantwortung an konkrete Namen binden — und nicht an vage Prozessbeschreibungen, die im Ernstfall niemandem gehören.
Die unbequeme Pointe
Am Ende bleibt eine simple, aber unangenehme Erkenntnis: Die Technologie ist in den meisten Fällen nicht das Problem. Modelle werden besser, schneller, günstiger — das ist fast schon Routine geworden. Das eigentliche Defizit liegt in der organisatorischen Antwort darauf. Wer Agenten skaliert, ohne parallel Urteilskraft zu institutionalisieren, verwechselt Ausbaugeschwindigkeit mit Reife. Und wer Amit Das‘ Formel von der Fluency ohne Urteil ignoriert, wird genau das erleben, was sie beschreibt: schnellere Fehler, nicht schnelleren Erfolg.
71 Prozent der CHROs haben verstanden, worauf es ankommt. Die Frage ist, ob sie auch die organisatorische Härte aufbringen, das durchzusetzen — gegen Zeitdruck, gegen Kostenlogik, gegen die Versuchung, einfach weiterzumachen, weil es kurzfristig funktioniert. Und ob die 71 Prozent der Belegschaft, die diese Priorität noch nicht teilen, überhaupt die Chance bekommen, sie zu verstehen — durch klare Rollen, echte Trainings und ein System, das Override nicht bestraft, sondern belohnt.
Schluss damit, Geschwindigkeit mit Fortschritt zu verwechseln. Ein Agent, der schnell liefert, aber niemanden hat, der ihn stoppen kann, liefert am Ende nur schneller Chaos. Das ist keine Innovation. Das ist Tempo-Theater mit Applausschild.
Was das für Ihre Organisation bedeutet
Hand aufs Herz: Wenn Sie gerade an Ihre eigene Organisation denken und nicht sofort sagen können, wer bei Ihnen offiziell den Override-Hut trägt — dann haben Sie Ihre Antwort. Die Studie liefert die Zahlen, aber die eigentliche Übung ist simpel: Fragen Sie in der nächsten Teamrunde, wer bei einem fehlerhaften KI-Output tatsächlich eingreifen darf. Wenn die Antwort „eigentlich jeder“ oder „müssten wir noch klären“ lautet, wissen Sie, wo Sie stehen.
Fragen Sie außerdem, ob die Rolle Ihrer Mitarbeitenden im Prozess als human-led definiert ist oder nur als advisory. Der Unterschied zwischen 76 und 43 Prozent Sicherheit beim Widerspruch entscheidet sich genau an dieser Formulierung — nicht an der Qualität des Modells, das Sie einsetzen. Und fragen Sie, ob Ihr Rollout Judgment von Anfang an eingebaut hat oder erst nachträglich, als Reaktion auf einen Vorfall. Die 62 Prozent steigendes Vertrauen gegenüber 57 Prozent sinkendem Vertrauen sind kein Zufall, sondern das direkte Resultat dieser einen Designentscheidung.
Wer sich zusätzlich fragt, wie verwundbar die eigene Organisation für manipulierte oder gefälschte KI-Outputs ist, findet in der Debatte um Schutzmaßnahmen gegen Deepfakes eine passende Ergänzung: Auch dort geht es letztlich um dieselbe Grundfrage — wer im Unternehmen hat die Befugnis und die Sicherheit, im entscheidenden Moment Nein zu sagen?
Die IBM-Studie mit ihren 1.500 CHROs aus 21 Geografien und 23 Branchen sowie 8.800 Mitarbeitenden aus 28 Ländern ist kein akademisches Papier für die Schublade. Sie beschreibt eine Lücke, die in den nächsten Monaten größer wird, wenn niemand sie schließt — schlicht, weil Agenten schneller ausgerollt werden als Governance-Strukturen entstehen. Wer diese Lücke ignoriert, kauft sich Tempo. Wer sie schließt, kauft sich Kontrolle. Beides zusammen geht selten von allein. Wer tiefer einsteigen will, findet die vollständige Methodik und weitere Auswertungen im IBM IBV C-Suite Study Hub zum CHRO.

