KI-Rollouts scheitern selten an der Technik

Wenn Unternehmen heute KI einführen, dann führen sie meistens nicht eine Anwendung, sondern eine ganze Plattform ein, die über Monate wächst. Das verändert nicht nur die Technik, sondern auch die Art, wie wir Veränderung begleiten müssen. In diesem Teil schauen wir uns an, warum unsere klassischen Rollout-Muster dabei nicht mehr greifen, woran KI-Einführungen im Arbeitsalltag tatsächlich scheitern und welche Aufgaben daraus entstehen. Im dritten Teil geht es dann um die Rolle, die diese Arbeit übernimmt.

Die Funktion ist live, doch nutzt sie jemand?

Fangen wir mit einer Situation an, die uns in verschiedenen Varianten immer wieder begegnet. Ein Unternehmen führt einen KI-Assistenten für die Erstellung von Produkttexten ein. Die Integration läuft, die Zugänge sind verteilt, die Einführungsveranstaltung war gut besucht und das Feedback im Raum war freundlich. Sechs Wochen später schauen wir in die Nutzungsdaten und sehen: Nur ein kleiner Teil der vorgesehenen Nutzergruppe arbeitet mit dem Assistenten. Alle anderen machen es weiter wie vorher.

Die erste Reaktion darauf kennen wir alle: Es muss mehr geschult werden. Manchmal stimmt das sogar. Meistens liegt das Problem aber an einer völlig anderen Stelle. Was fehlt, ist nämlich nicht das Wissen darüber, wo man klicken muss. Was fehlt, sind Antworten auf einige unangenehm konkrete Fragen:

• Wer verantwortet eigentlich den Text, den die KI erzeugt hat?
• Nach welchen Kriterien wird er geprüft, und von wem?
• Was passiert mit den Fällen, die das Modell erkennbar nicht gut kann?
• Wie verhält sich der neue Ablauf zu dem alten, den vermutlich niemand offiziell außer Kraft gesetzt hat?

Solange diese Fragen offen sind, entscheiden sich Menschen für den Weg, für den sie nicht belangt werden können – und das ist der Alte. Das ist kein Trainingsdefizit und auch keine Veränderungsverweigerung, sondern eine vollkommen vernünftige Reaktion auf eine unklare Lage. Wir haben es hier also nicht mit einem Schulungsproblem zu tun, sondern mit einer Organisationsfrage, die vor der Einführung offen geblieben ist.

Warum unsere alten Rollout-Muster nicht mehr passen

Klassische Software-Einführungen hatten eine schöne, übersichtliche Dramaturgie: Auswahlphase, Einführungsprojekt, Go-live-Termin, Schulungen, Betrieb. Change Management war in diesem Muster ein Projektbestandteil mit Anfang und Ende, und den Erfolg konnten wir am Termin und an der Zahl der geschulten Personen festmachen. Damit ließ sich arbeiten.

Bei einer KI-Plattform funktioniert das nicht mehr. Der Rollout dauert typischerweise sechs bis zwölf Monate, und in dieser Zeit wird die Plattform immer wieder erweitert: Neue Datenquellen kommen hinzu, Unternehmenswissen wird angebunden, Fachanwendungen werden integriert, für einzelne Bereiche entstehen Assistenzfunktionen, und einzelne Arbeitsschritte werden teilweise oder ganz automatisiert. Jede dieser Erweiterungen ist technisch betrachtet ein Release. Organisatorisch betrachtet ist sie unter Umständen eine Veränderung des Arbeitsalltags. Ein KI-Rollout ist deshalb weniger ein Umzug als eine Renovierung im bewohnten Haus: Es wird Raum für Raum umgebaut, und alle wohnen währenddessen weiter darin.

Für die Beschäftigten entsteht die Veränderung deshalb nicht an einem Stichtag, sondern fortlaufend. Wer bei der ersten Erweiterung dabei war, arbeitet drei Monate später mit einer Plattform, die deutlich mehr kann als die ursprünglich kennengelernte. Gleichzeitig kommen neue Nutzergruppen hinzu, die den ersten Teil des Rollouts nie miterlebt haben und ihn auch nicht nachholen können. Es gibt keinen Zeitpunkt, an dem alle auf demselben Stand sind, und – das ist der springende Punkt – es wird auch keinen geben.

Ein Change-Projekt mit Kick-off, Kommunikationsplan und Abschlussbericht passt auf diese Realität schlicht nicht. Was passt, ist eine Rolle, die den ganzen Zeitraum über mitläuft: nah am Rollout, nah an den Fachbereichen und nah an den Menschen, die damit arbeiten sollen.

Wir haben eine KI-Plattform … und jetzt?

Der entscheidende Unterschied bei KI-Einführungen liegt nicht in der Bedienung, sondern darin, dass Verantwortung verschoben wird. Und das passiert nicht bei jeder Erweiterung im gleichen Maß.

Eine neue Suchfunktion über Produkt- und Materialwissen ist eine zusätzliche Möglichkeit. Sie verändert, wie jemand an Informationen kommt, aber nicht, wer für ein Ergebnis einsteht. Eine automatisierte Aufbereitung von Lieferantendaten ist etwas anderes: Wenn Daten nicht mehr vorgeschlagen, sondern übernommen und weitergeleitet werden, dann verändert sich der Arbeitsablauf selbst; und damit auch die Frage, wer am Ende haftet.

Bevor wir eine solche Automatisierung einführen, sollten fünf Punkte geklärt und dokumentiert sein:

1. Umfang der Automatisierung → Welcher Arbeitsschritt wird lediglich vorbereitet, und welcher wird vollständig übernommen?
2. Prüfung → Wer kontrolliert das Ergebnis, mit welchem Maßstab und in welchem Zeitfenster?
3. Freilauf → Unter welchen Bedingungen darf der Ablauf ohne menschliche Prüfung weiterlaufen?
4. Ausnahmen → Welche Fälle bleiben grundsätzlich beim Menschen, und wie erkennen wir sie rechtzeitig?
5. Eingriff → Wer greift ein, wenn Daten oder Ergebnis nicht stimmen, und wie wird der Fehler korrigiert?

Eine Produktdemo beantwortet keine dieser Fragen. Sie zeigt uns, dass die Funktion läuft. Ob die Arbeit läuft, ist damit noch nicht gezeigt.

Nicht jede Änderung braucht dieselbe Begleitung

Daraus sollten wir aber nicht schließen, dass jede technische Änderung eine eigene Change-Begleitung braucht. Bei einer Plattform mit vielen Integrationen wäre das der schnellste Weg zu einer Change-Bürokratie, die niemandem hilft und unsere Aufmerksamkeit dort bindet, wo am meisten kommuniziert wird, statt dort, wo sich Arbeit tatsächlich verändert. Bleiben wir beim Bild der Renovierung: In manchen Räumen wird nur gestrichen, in anderen kommt ein Möbelstück dazu, und in wenigen fällt eine Wand. Hilfreicher als ein Vorgehen für alle ist deshalb eine einfache Unterscheidung nach Veränderungsintensität, die uns als Priorisierungshilfe dient und ausdrücklich kein Freigabeverfahren ist:

Die Unterscheidung zwischen einer neuen Nutzungsmöglichkeit und einer Veränderung des Arbeitsablaufs ist dabei die wichtigste – und genau die, die in der Praxis am häufigsten übersehen wird.

Warum Change-Begleitung über den Erfolg der Investition entscheidet

Diese Aufgabe wird gerne als weiches Thema behandelt, weil sie nach Kommunikation aussieht. Sie erfüllt aber vier Funktionen, die den messbaren Erfolg einer KI-Investition unmittelbar betreffen.

Erstens sorgt sie für Orientierung. Beschäftigte und Führungskräfte müssen wissen, was als Nächstes eingeführt wird, warum es eingeführt wird und was sich dadurch konkret in ihrer Arbeit verändert. Fehlt diese Orientierung, entstehen Gerüchte, und Gerüchte über KI-Einführungen haben in den letzten Jahren ein sehr spezifisches Thema bekommen, nämlich den eigenen Arbeitsplatz.

Zweitens ermöglicht sie Nutzung. Die betroffene Gruppe braucht kein allgemeines Verständnis der Plattform, sondern genau die Information, Übung und Unterstützung, die sie für ihre eigenen Aufgaben benötigt. Eine gute Einführung für den Kundenservice sieht deshalb anders aus als eine gute Einführung für das Produktmanagement, auch wenn wir dieselbe Funktion einführen.

Drittens macht sie Hindernisse früh sichtbar. Missverständnisse, ungeklärte Verantwortlichkeiten, technische Probleme und unpassende Arbeitsabläufe treten bei jeder Einführung auf. Entscheidend ist, wie schnell sie bei der zuständigen Stelle landen und ob sie dort tatsächlich bearbeitet werden. Ohne jemanden, der diese Rückmeldungen sammelt und einordnet, versickern sie in Einzelgesprächen und tauchen drei Monate später als Grundsatzkritik wieder auf.

Viertens verbessert sie den Rollout mit jeder Erweiterung. Erfahrungen aus früheren Einführungen lassen sich wiederverwenden: Formulierungen, die funktioniert haben, Beispiele, die verstanden wurden, Fragen, die immer wieder kommen. Hält das niemand fest, beginnt jede Integration kommunikativ und organisatorisch wieder bei null. Bei einer Plattform, die über Monate wächst, ist das eine erstaunlich teure Form von Vergesslichkeit.

Wichtig ist dabei der Maßstab, den wir anlegen. Der Erfolg dieser Arbeit zeigt sich nicht in der Zahl von Präsentationen, Trainings oder Logins. Entscheidend ist, ob die vorgesehenen Arbeitsabläufe funktionieren und ob die Beschäftigten sicher mit ihnen umgehen können.

KI als Verstärker: Wir bekommen, was wir schon hatten

Martin Fowler hat, gestützt auf den DORA Report 2025, eine Formulierung geprägt, die sich in Organisationen unangenehm gut bestätigt:

KI wirkt als Verstärker für alles, was in einem Prozess bereits vorhanden ist.

Wer gute Praktiken etabliert hat, liefert schneller. Wer schlechte hat, baut schneller Schulden auf. Fowler meint damit in erster Linie die Softwareentwicklung, aber der Satz gilt für die Organisation genauso.

Eine KI-Plattform behebt keine unklaren Zuständigkeiten. Sie macht sie schneller sichtbar. Arbeitsabläufe, in denen nie ausbuchstabiert wurde, wer bei Zweifelsfällen entscheidet, haben über Jahre funktioniert, solange alles manuell und entsprechend langsam lief: Die Unklarheit wurde durch persönliche Absprachen und ausreichend Zeit ausgeglichen. Sobald ein Teil des Ablaufs automatisiert weiterläuft, fällt die Lücke auf – als Nacharbeit, als Eskalation oder als Ergebnis, das niemand bewusst freigegeben hat.

Daraus folgt eine sehr konkrete Konsequenz für alle, die über Budget und Nutzen entscheiden müssen. Wenn eine Automatisierung Zeit sparen oder Fehler reduzieren soll, dann müssen wir die Ausgangsbasis vor der Einführung festhalten: durchschnittliche Bearbeitungszeit, Umfang der Nacharbeit, Fehlerhäufigkeit. Versäumen wir das, können wir hinterher nicht mehr belegen, ob die Veränderung tatsächlich genutzt hat, weil uns der Vergleichswert fehlt. Der Nutzen wird dann behauptet statt gemessen, und in der nächsten Budgetrunde ist das eine ziemlich schwache Position.

Es ist derselbe Mechanismus, den wir von Quality Gates in der Entwicklung kennen: Eine Metrik, die wir erst nach dem Start definieren, misst nicht die Veränderung, sondern nur den Zustand, in dem wir uns ohnehin befinden. Und noch eine Einschränkung gehört dazu: Aggregierte Nutzungszahlen helfen uns nur begrenzt weiter. Sie zeigen, dass eine Funktion aufgerufen wird, aber nicht, ob sie für die vorgesehene Aufgabe eingesetzt wurde und ob das Ergebnis brauchbar war. Diese Information bekommen wir nur im Gespräch mit den Menschen, die damit arbeiten. Aus einem Dashboard lässt sie sich nicht ablesen.

Widerstand ist selten Bockigkeit; meistens ist es Trauer

Es gibt einen zweiten Grund, warum KI-Einführungen im Arbeitsalltag hängen bleiben, und der ist deutlich unbequemer als jede Prozessfrage.

Für viele Beschäftigte steht bei dieser Veränderung nicht nur ein Werkzeug zur Debatte, sondern das, was ihre berufliche Kompetenz ausgemacht hat. Wer zwanzig Jahre darauf hingearbeitet hat, ein bestimmtes Ergebnis in einer bestimmten Qualität selbst herzustellen, verliert nicht einfach eine Aufgabe, sondern den Maßstab für den eigenen Beitrag – und häufig auch die Rolle, die daran hing, etwa als die Person, die man bei schwierigen Fällen fragt.

Die Datenlage stützt dieses Unbehagen. Das Stanford Digital Economy Lab hat Gehaltsabrechnungsdaten von Millionen US-Beschäftigten ausgewertet und dabei festgestellt, dass die Beschäftigung bei Softwareentwicklern zwischen 22 und 25 Jahren seit Ende 2022 um rund 20 Prozent zurückgegangen ist. Parallel dazu zeigen Entwicklerbefragungen ein bemerkenswertes Muster: Die Nutzung von KI-Werkzeugen ist inzwischen nahezu flächendeckend, während das Vertrauen in die Qualität ihrer Ergebnisse im selben Zeitraum gesunken ist. Ein Werkzeug täglich zu benutzen und ihm dabei weniger zu trauen als im Vorjahr – das ist ein Zustand, der Unsicherheit erzeugt.

Eine Geschichte aus der Praxis

Für unsere Praxis heißt das zweierlei. Zum einen können wir diesen Teil der Veränderung nicht mit einem Adoptionsprogramm oder einem zusätzlichen Training bearbeiten, weil er nicht auf fehlendem Wissen beruht. Zum anderen ist er nicht optional: Wer die Verunsicherung im Team ignoriert, bekommt sie als stille Nichtnutzung zurück – und die ist in Nutzungsdaten kaum von einem Bedienproblem zu unterscheiden.

Und genau hier liegt eine Kompetenz, die wir in agilen Rollen seit Jahren ausbilden: Organisationsdynamik lesen, Konflikte aushalten, Menschen durch Veränderung begleiten, ohne dabei die inhaltliche Richtung aufzugeben.

Und wer macht das jetzt?

Halten wir kurz fest, was wir bis hierher gesehen haben. KI-Einführungen scheitern im Arbeitsalltag selten an der Bedienung. Sie scheitern daran, dass niemand geklärt hat, wer ein Ergebnis verantwortet, wann es freigegeben ist und was mit den Ausnahmen passiert. Woran es außerdem scheitert: Der Rollout hat keinen Stichtag mehr, und unsere Projektlogik ist darauf nicht ausgelegt. Sie scheitern daran, dass KI organisatorische Lücken nicht schließt, sondern schneller sichtbar macht. Und sie scheitern daran, dass wir Trauer als Adoptionsproblem behandeln.

Damit ist die Aufgabe umrissen: Jemand muss den technischen Rollout fortlaufend mit der tatsächlichen Arbeit im Unternehmen verbinden. Jemand muss vor jeder Erweiterung fragen, wer betroffen ist und was sich ändert. Jemand muss Hindernisse einsammeln und dorthin zurückspielen, wo sie behoben werden können. Und jemand muss den Raum halten, in dem Menschen sagen dürfen, dass ihnen diese Veränderung etwas wegnimmt.

Die naheliegende Antwort auf die Frage, wer das übernimmt, lautet: wir. Nur eben nicht unter dem Namen, unter dem wir bisher angetreten sind – denn genau dieser Name wird uns gerade zum Problem. Warum das so ist, wie die Rolle konkret aussieht, was sie ausdrücklich nicht übernimmt und woran wir erkennen, dass sie funktioniert, schauen wir uns im zweiten Teil an.

---

Quellen und Bezüge

• Martin Fowler zum Verstärker-Effekt von KI, gestützt auf den DORA Report 2025
• Stanford Digital Economy Lab, Auswertung von ADP-Gehaltsabrechnungsdaten zur Beschäftigung junger Softwareentwickler; Erik Brynjolfsson
• Andrew Murphy, „The Five Stages of Losing Our Craft“, Februar 2026
• Rollenkonzept „Agile Change Manager KI-Rollout“ nach der internen Leistungsbeschreibung von Johann-Peter Hartmann, Mayflower
• Datenlage und Kontext aus dem Vortrag „KI killt Agile. Wer steuert die Transformation?“ von Johann-Peter Hartmann