Ein KI-Projekt aufzusetzen ist nicht mehr das Problem. Es zum Teil Ihres Unternehmens zu machen schon.

Eine Zeit lang hatten wir ein ziemlich einfaches Problem: herauszufinden, ob künstliche Intelligenz in Unternehmen überhaupt Wert schaffen kann. Inzwischen wird diese Frage weniger interessant.

Die Unternehmensberatung BearingPoint hat gerade eine Studie veröffentlicht, für die im August 1.050 Führungskräfte aus öffentlichen und privaten Organisationen in Europa, den USA und China befragt wurden. Von den Organisationen, die KI bereits in ihrer Arbeit einsetzen, sehen 74 % nach eigenen Angaben messbare Effekte bei Kosten oder Umsatz. Trotzdem sagen nur 13 %, sie hätten ihre Projekte vollständig nach dem Plan ausgeweitet, mit dem diese genehmigt worden waren. Das heißt nicht, dass die anderen gescheitert sind: Ein Pilotprojekt ist ja gerade dazu da, dass man es sich anders überlegen kann.

Interessanter ist ein Detail. Als größtes Hindernis werden laut Pressemitteilung die komplexen Vorschriften genannt. Gleich danach kommt die Einbindung in die Systeme und Abläufe, mit denen die Unternehmen seit Langem arbeiten, und mehr als die Hälfte der Führungskräfte hält es für entscheidend, sich auf verlässliche Daten stützen zu können. Das Modell hat also oft schon gezeigt, dass es die Arbeit kann. Es hakt erst danach.

Zahlen, die man vorsichtig lesen sollte

Diese Zahlen sind mit Vorsicht zu lesen. BearingPoint verkauft genau die Art von Arbeit, um die es in der Studie geht, und eine Umfrage unter Führungskräften ist keine amtliche Statistik. Sie beschreibt auch nicht zwangsläufig die Unternehmen in Italien. Italien ist in der Stichprobe zwar vertreten, taucht aber nur in der Infografik auf, in einer Rubrik „übriges Europa“ zusammen mit Österreich, Irland, den Niederlanden und der Schweiz, und bekommt nirgends eine eigene Zahl. Auch die 74 % sollte man zu Ende lesen. Sie beziehen sich auf die 685 Organisationen, die schon etwas im Betrieb haben, und auf der Studienseite steht außerdem, dass der Effekt bei knapp der Hälfte unter 4 % der Kosten und unter 2 % des Umsatzes bleibt.

Für Italien gibt es eine amtliche Statistik, und ihre Zahlen liegen deutlich niedriger. Nach Angaben des italienischen Statistikamts ISTAT setzten 16,4 % der Unternehmen mit mindestens zehn Beschäftigten im Jahr 2025 wenigstens eine KI-Technologie ein: 53,1 % der großen und 15,7 % der kleinen und mittleren. Von denen, die KI nutzen, nennt jedes dritte keinen betrieblichen Zweck dafür, ein Jahr zuvor waren es 15,5 %. Das Amt spricht von einer Nutzung, die sich immer weiter verbreitet, aber noch wenig Struktur hat.

Dieselbe Vorsicht gilt für die Prozentzahlen, die seit zwei Jahren darüber kursieren, wie viele KI-Projekte scheitern. Die 95 %, die dem MIT zugeschrieben werden, stammen aus einem Bericht, der seine eigenen Zahlen als „directionally accurate“ bezeichnet, also als Richtwerte, weil sie auf Interviews beruhen und nicht auf offiziellen Unternehmensdaten. Die „mehr als 80 %“, die als RAND-Zahl zitiert werden, sind eine Schätzung, die RAND aus einem Fortune-Artikel von 2022 übernimmt: Die 65 Interviews von RAND selbst galten den Ursachen des Scheiterns, nicht seiner Häufigkeit. Die 30 % von Gartner waren eine Prognose für 2025, abgegeben 2024. Gemessen wird jedes Mal etwas anderes, und nebeneinandergelegt zeigen die Zahlen vor allem, dass es auf die Frage „Wie viele scheitern?“ nicht nur eine Antwort gibt. Das passiert auch binnen weniger Stunden: Die englische Reuters-Meldung zur BearingPoint-Studie schreibt, weniger als ein Drittel der Unternehmen sei über Pilotprojekte hinausgekommen. In der Pressemitteilung steht diese Zahl nicht, und nach der Aufschlüsselung, die BearingPoint veröffentlicht, haben 65 % der Organisationen bereits etwas im Betrieb.

Manche wenden auch ein, die Mühe, eine neue Technik in eine komplexe Organisation zu bringen, sei so alt wie die Unternehmens-IT: Wir haben sie bei den ERP-Systemen erlebt und beim Umzug in die Cloud. Viele Unternehmen sind noch in der Phase des Ausprobierens, und es ist gesund, wenn ein Projekt die Richtung ändert, sobald sich einige Ausgangsannahmen als falsch erweisen. Die Studie selbst sagt, dass fast drei Viertel den ursprünglichen Zuschnitt angepasst oder weniger ausgeweitet haben als vorgesehen, und das ist etwas anderes als zu scheitern. Das sehe ich auch so, und deshalb baue ich meine Überlegung nicht darauf, dass 13 % wenig seien. Mich interessiert, wo die Probleme liegen, die immer häufiger nach der Demo auftauchen. Ich glaube, sie liegen in der Umgebung, in der wir das Modell arbeiten lassen wollen.

„Gut, dann nutzen wir es jetzt alle“

Wer in einem Unternehmen oder einer Behörde einen gelungenen Test abgenommen hat, kennt den Tag, an dem jemand zufrieden sagt: „Gut, dann nutzen wir es jetzt alle.“ Von da an ist die Frage eine andere. Solange es ein Test war, reichte es, dass das System mit fünfzig sorgfältig ausgewählten Dokumenten zurechtkam, während die Leute, die es gebaut hatten, daneben saßen. Jetzt muss es mit den echten Dokumenten funktionieren, die Regeln dazu einhalten, wer was sehen darf, mit Ausnahmen fertigwerden und für Menschen verständlich bleiben, die am Projekt nicht beteiligt waren.

Jeder Schritt beantwortet eine andere Frage. Die Demo zeigt, ob das System etwas kann. Im Pilotprojekt prüft man, ob es das auch an einem Teil unserer Arbeit kann, mit echten Daten und echten Nutzern. Danach ist zu klären, ob wir es so betreiben können, dass es verlässlich gleich arbeitet, und ob wir dabei Kosten und Zugriffe im Griff behalten. Die letzte Frage ist von anderer Art: Können wir es uns leisten, davon abhängig zu sein? Wenn eine Tätigkeit in die tägliche Arbeit einzieht, genügt es nicht, dass das System im Durchschnitt funktioniert. Man muss wissen, wer dafür geradesteht, woran man merkt, dass etwas schiefläuft, was passiert, wenn das Modell nicht mehr antwortet, welche Version ein bestimmtes Ergebnis erzeugt hat und wie man auf den alten Stand zurückkommt. Was in der Demo zu sehen ist, ist erst der Anfang der Arbeit.

Der Test gelingt, weil ihn jemand schützt

Ein Pilotprojekt kann gerade deshalb gelingen, weil es für ein paar Wochen fast alles aus dem Weg räumt, was den täglichen Einsatz schwierig macht. Man arbeitet mit sauberen Daten, sucht sich überzeugte Nutzer aus, schneidet den Umfang eng zu und kennt die Ausnahmen im Voraus. Das Technikteam sieht bei jedem Schritt zu, und wenn etwas Merkwürdiges passiert, bringt es jemand von Hand in Ordnung, bevor ein Problem daraus wird.

Für die Frage, ob eine Fähigkeit überhaupt vorhanden ist, sind das ideale Bedingungen, und sie sind das Gegenteil dessen, was danach kommt. Die Daten sind dann so, wie sie eben sind, die Nutzer waren an nichts beteiligt, das Technikteam arbeitet an etwas anderem, und das System muss sich in der Woche selbst erklären, in der derjenige im Urlaub ist, der es gebaut hat. In gewisser Weise gelingt der Test, weil die Organisation ihn schützt, und der Alltag nimmt ihm genau diesen Schutz.

Das Angebot zu schreiben war der leichte Teil

Ich stelle mir ein mittelgroßes Unternehmen vor, das Dienstleistungen an andere Firmen verkauft und einen Assistenten möchte, der dem Vertrieb beim Erstellen von Angeboten hilft. Im Pilotprojekt bekommt der Assistent die Preisliste, zehn bereits verschickte Angebote, die Leistungsbeschreibungen und eine Dokumentvorlage. In wenigen Minuten liefert er einen überraschend guten Entwurf, und man beschließt, ihn dem gesamten Vertrieb zu geben.

Dann stellt sich heraus, dass die offizielle Preisliste nicht immer mit der übereinstimmt, nach der tatsächlich gearbeitet wird. Manche Kunden haben Sonderkonditionen, die in einem E-Mail-Wechsel vereinbart und nirgends sonst festgehalten wurden. Einige Leistungsbeschreibungen gibt es in drei Fassungen, und nur eine ist aktuell. Eine Leistung lässt sich in bestimmten Kombinationen nicht verkaufen, und das weiß nur, wer schon lange im Haus ist. Manche Angebote brauchen die Freigabe derer, die die Arbeit später ausführen, oder die des Finanzchefs, andere können sofort raus.

Der Test hatte gezeigt, dass der Assistent ein Angebot schreiben kann. Der Schritt in den gesamten Vertrieb zeigt, dass das Schreiben der leichte Teil war und dass ein System, das wirklich mitarbeitet, die Organisation kennen muss. In einem Krankenhaus oder einem Rathaus stünden andere Punkte auf der Liste, und sie wäre mindestens ebenso lang.

Was die Leute bisher ausgeglichen haben

Ich glaube, die KI bringt Probleme zum Vorschein, die es schon vorher gab: widersprüchliche Daten, Wissen, das über Köpfe und Postfächer verstreut ist, über die Jahre angesammelte Berechtigungen, Abläufe, die nirgends aufgeschrieben sind. Solange in diesen Prozessen nur Menschen arbeiteten, glichen sie das laufend aus. Sie fragten einen Kollegen, sie erinnerten sich, wie man es beim letzten Mal gemacht hatte. Sie wussten, welchen Wert man von Hand aus dem einen System ins andere überträgt und welches Feld man ignoriert.

Wer mit einem ERP-System arbeitet, das zehn Jahre Geschichte hat, weiß, dass es drei Felder enthalten kann, die alle ungefähr „Kundenstatus“ heißen, und dass nur eines davon die Wahrheit sagt. Ein Assistent versteht die Sprache tadellos und kann trotzdem nicht wissen, in welches der drei er schauen soll. Der Fehler liegt darin, wie wir Informationen über die Jahre organisiert haben, und das Modell macht ihn lediglich auf einen Schlag sichtbar. Deshalb glaube ich, dass KI-Projekte vor allem etwas auf die Probe stellen, das kein Modell in der Hand hat: wie lesbar ein Unternehmen für jemanden ist, der nicht seit Jahren dort arbeitet.

Eine Mühe, die älter ist als die Software

Mancher wird sagen, ich gäbe der alten digitalen Transformation nur einen neuen Namen. Zum großen Teil stimmt das, und es ist das Nützlichste, was man sich eingestehen kann. Ein paar Jahre lang haben wir KI in Unternehmen wie eine eigene Welt behandelt, mit eigenem Vokabular und eigenen Spezialisten. Sobald ein System aber wirklich in die tägliche Arbeit einzieht, trifft es auf dieselben Probleme, mit denen Software seit Jahrzehnten zu tun hat: Daten, Zugriffe, Schnittstellen, Verantwortung.

Die Geschichte ist allerdings älter als die Software. 1990 wollte der Wirtschaftshistoriker Paul David verstehen, warum sich die Computer noch nicht in der Produktivitätsstatistik zeigten, und sah nach, wie es mit dem Elektromotor gewesen war. 1899, fast zwanzig Jahre nach den ersten Kraftwerken, lieferten Elektromotoren weniger als 5 % der Antriebskraft in amerikanischen Fabriken. Bis zur Hälfte dauerte es weitere zwanzig Jahre, und in der Produktivität zeigte sich die Wirkung erst in den 1920er-Jahren. Der Motor funktionierte vom ersten Tag an. Die Fabriken aber waren für Wasser- und Dampfkraft gebaut, mit Transmissionswellen unter der Decke und Riemen, die zu den Maschinen hinunterliefen, und solange diese Werke noch taugten, lohnte es sich für niemanden, sie neu zu bauen. Der Gewinn kam, als man anfing, jeder Maschine ihren eigenen Motor zu geben und das Gebäude entsprechend zu entwerfen.

Bei den ERP-Systemen lief es ähnlich. In einer Studie von 2002 berichten Erik Brynjolfsson, Lorin Hitt und Shinkyu Yang, dass bei einer typischen Einführung von SAP R/3 für rund zwanzig Millionen Dollar weniger als ein Fünftel auf Hardware und Software entfiel. Der Rest ging dafür drauf, Anforderungen zu klären, das Programm anzupassen, Abläufe neu zu gestalten und die Leute zu schulen.

Der Unterschied ist diesmal, dass die neue Komponente auf dieselbe Frage nicht immer dieselbe Antwort gibt und dass wir dazu neigen, ihr immer mehr Selbstständigkeit zu lassen. Das macht die alten Probleme heikler und schwerer aufzuschieben. Der neue Teil funktioniert also nur, wenn der alte Teil des Handwerks sauber gemacht ist.

Die Regeln stellen dieselben Fragen, nur schriftlich

Auch deshalb wundert es mich nicht, dass die Studie die komplexen Vorschriften als größtes Hindernis nennt. Im Gesundheitswesen oder in einer Behörde stellen die Normen schriftlich und im Voraus die Fragen, die der Arbeitsalltag ohnehin stellen würde, angefangen damit, wer für eine Entscheidung geradesteht und wie sie sich nachvollziehen lässt.

Der AI Act tut das fast wörtlich. Von den Betreibern eines Hochrisiko-KI-Systems verlangt Artikel 26, die menschliche Aufsicht Personen zu übertragen, „die über die erforderliche Kompetenz, Ausbildung und Befugnis verfügen“, und die Protokolle, die das System erzeugt, mindestens sechs Monate aufzubewahren. Der Digital Omnibus hat diese Pflichten auf Dezember 2027 verschoben, und ich habe schon beschrieben, warum der Aufschub wenig ändert, wenn man das System jetzt baut: Ein Protokoll, das es nicht vom ersten Tag an gibt, lässt sich später nicht rekonstruieren.

In der Studie gibt es eine Zahl, die in dieselbe Richtung weist und mit derselben Vorsicht zu nehmen ist. Im öffentlichen Sektor und im Gesundheitswesen ist fast die Hälfte der Organisationen noch beim Erkunden oder Erproben. Bei Banken und Versicherungen, die mindestens ebenso viele Regeln haben, sind es 22 %, und das ist die am weitesten fortgeschrittene Branche der ganzen Stichprobe. Ich weiß nicht, wie stark Größe und Budgets der Befragten ins Gewicht fallen. Aber wenn die Regeln an sich die Bremse wären, würde ich Banken und Versicherungen am Ende der Tabelle erwarten.

Für den, der das System baut, sind die Regeln eine Vorgabe für den Entwurf, und es lohnt sich, sie vom ersten Tag an so zu behandeln.

Was schwer zu finden geworden ist

Damit ändert sich auch, was am Markt schwer zu finden ist. Am Anfang zählte, wer zeigen konnte, was KI für ein Unternehmen leisten kann. Mir scheint, dieser Vorsprung schmilzt schnell: Die Modelle werden besser und billiger, und eine überzeugende Demo ist in wenigen Tagen gebaut. Schwer zu finden bleibt, wer einen Prozess verstehen und neu gestalten kann, wer Systeme verbindet, die nie dafür gedacht waren, miteinander zu reden, wer entscheidet, wer was sehen darf, und wer die Menschen begleitet, die mit dem Ergebnis arbeiten sollen. Es sind die altbekannten Disziplinen sorgfältig gemachter Software, die jetzt Platz für eine Komponente schaffen müssen, die weniger berechenbar ist als die übrigen.

Dieselbe Studie hält fest, dass weniger als ein Drittel der Organisationen vor dem Start eines KI-Projekts förmlich prüft, ob es sich ausweiten lässt. So kommen die Fragen nach Architektur, Daten, Verantwortung und Arbeitsorganisation oft erst auf den Tisch, wenn das Projekt schon bewiesen hat, dass es funktioniert. Es ist der schlechteste Moment, um auf sie zu stoßen, denn dann erwarten alle nur noch, dass jemand den Schalter umlegt.

Mein Interesse an dieser Geschichte

Aus demselben Grund beginnen die Projekte, die ich am interessantesten finde, oft dann, wenn die Demo schon gelungen ist. Die Frage nach dem Modell ist dann beantwortet. Offen bleibt, durch welche Systeme es hindurchmuss, welche Daten es nutzen darf, mit welchen Ausnahmen es umgehen muss und was geschehen muss, damit das Unternehmen es sich leisten kann, davon abzuhängen.

Daran habe ich ein unmittelbares Interesse. Ich arbeite in einer Softwarefirma, die genau von der Strecke zwischen einem gelungenen Test und einem System lebt, auf das sich ein Unternehmen oder eine Behörde verlassen kann. Eine Studie, die diese Strecke als die schwierigste beschreibt, kommt mir ebenso gelegen wie denen, die sie veröffentlicht haben. Der Maßstab ist also zuerst an uns selbst anzulegen.

Bei uns schreibt einen Großteil des Codes schon eine Maschine, nach einer Spezifikation, die wir schreiben, und das Review bleibt bei einem Menschen. Bestünde unser Handwerk nur darin, Code zu schreiben, wären wir unter den Ersten, die zusehen, wie es an Wert verliert. Der Rest des Handwerks, also das, was ich bis hierher beschrieben habe, muss sich Projekt für Projekt beweisen, und wer mit uns arbeitet, hat das Recht zu fragen, wie wir es machen.

Nicht jeder Test muss ein System werden

Dazu kommt eine Folge, die unbequemer ist für alle, die von Integration leben. Nicht jedes Pilotprojekt verdient es, ein Unternehmenssystem zu werden. Ein Assistent, den drei Leute nutzen und der Stunden spart, ohne sonst etwas anzufassen, kann bleiben, wie er ist, und das ist eine vernünftige Entscheidung. In anderen Fällen kostet es mehr, einen Test verlässlich zu machen, als er je einbringen wird, und das früh herauszufinden ist ein gutes Ergebnis: viel besser, als drei Jahre lang eine gelungene Demo zu verteidigen. Wer an der Integration verdient, hat allen Grund zu antworten, dass sie sich immer lohnt.

Der Maßstab, an dem man uns messen soll, ist dieser: vor der Unterschrift zu sagen, was es kosten wird, einen gelungenen Test verlässlich zu machen, und es auch dann zu sagen, wenn die richtige Antwort lautet, ihn zu lassen, wie er ist.

Wer entscheidet, dem lasse ich eine Frage da. Welches Ihrer KI-Projekte funktioniert im Test bereits, und trotzdem würden Sie es noch nicht hundert echten Nutzern überlassen, ohne dass die Person danebensitzt, die es gebaut hat?

Der Autor

Andrea MargiovanniKI

Ich verfolge das Verhältnis zwischen KI und europäischer Regulierung als politisches Faktum, nicht als technisches Spektakel. Ich arbeite mit Teams, die KI mit AI Act, CRA, NIS2 vereinbar machen müssen, ohne Compliance auf eine Checkliste zu reduzieren.

Zum Weg →