Warum KI-Projekte scheitern: es liegt nicht an der Technik

Wenn ein KI-Projekt scheitert, liegt es fast nie am Modell.

Es liegt daran, dass der Pilot auf aufgeräumten Daten lief und der Betrieb nicht. Daran, dass niemand benannt war, der die Ergebnisse verantwortet. Daran, dass vorher nicht festgelegt wurde, woran man Erfolg erkennt. Daran, dass der Prozess, den die KI verbessern sollte, vorher schon nicht funktioniert hat. Und daran, dass Datenschutz und Sicherheit erst geprüft wurden, als das System längst stand.

Das sind fünf organisatorische Punkte. Die Technik steht in dieser Liste nicht.

Dieser Artikel beschreibt zuerst, was zwischen einem funktionierenden Piloten und dem Betrieb tatsächlich liegt, geht dann die fünf Ursachen durch, jeweils mit dem Anzeichen, an dem man sie früh erkennt, und endet mit den Fragen, die wir vor dem Start eines KI-Projekts stellen.

‍

Was zwischen Pilot und Betrieb steht

Ein Pilot entsteht fast immer am Rand des Unternehmens. Eine kleine Gruppe probiert etwas aus, auf einem eigenen Zugang, mit Beispieldaten, ohne Anbindung an die Systeme, in denen die Arbeit sonst stattfindet. Das ist der richtige Weg, um schnell zu sehen, ob eine Idee trägt.

Genau diese Abschottung ist aber der Grund, warum der nächste Schritt so schwerfällt. Zwischen einem Piloten, der überzeugt, und einem Betrieb, auf den sich Menschen verlassen, liegen drei Dinge, die im Piloten niemand gebraucht hat.

Die Freigabe für echte Daten. Im Betrieb fließen Kunden- und Personendaten. Damit werden Auftragsverarbeitung, Rollen und Rechte, Protokollierung und Löschfristen zu Voraussetzungen und nicht zu Formalitäten. Wurde das im Piloten nicht mitgedacht, steht das Projekt an dieser Stelle, obwohl die Technik längst funktioniert.

Die Anbindung an das Bestandssystem. Ein Pilot lebt von hochgeladenen Dateien. Der Betrieb muss dort stattfinden, wo die Vorgänge ohnehin liegen: im ERP, im Dokumentenmanagement, im Ticketsystem, in der Fachanwendung. Das bedeutet Schnittstellen, Berechtigungen, Fehlerbehandlung und einen Betrieb, der überwacht wird. Dieser Teil ist der aufwendigste im ganzen Projekt und wird am häufigsten unterschätzt. Er ist auch der Punkt, an dem die meisten Unternehmen einen Partner dazuholen, weil er nichts mehr mit Ausprobieren zu tun hat.

Die Menschen, die damit arbeiten sollen. Der Betrieb setzt voraus, dass die Fachabteilung weiß, was das System tut, was es nicht tut und woran sie ein falsches Ergebnis erkennt. Ohne diese Einweisung entsteht entweder blindes Vertrauen oder stille Ablehnung. Beides macht den Nutzen zunichte.

Wer diese drei Punkte erst nach dem Piloten anfängt, verliert Monate. Wer sie beim Zuschnitt des Piloten schon kennt, baut ihn anders.

‍

Ursache 1: Der Pilot lief auf Daten, die es im Betrieb nicht gibt

Für einen Piloten wird ein Datensatz zusammengestellt. Jemand aus der Fachabteilung sucht Beispiele heraus, räumt sie auf, entfernt die Ausreißer. Das Ergebnis überzeugt, die Trefferquote stimmt, alle sind zufrieden.

Im Betrieb kommen dann die echten Daten. Dokumente mit Scanfehlern, Freitextfelder, in die jemand drei Informationen gequetscht hat, Sonderfälle, die seit zwölf Jahren so behandelt werden und nirgends dokumentiert sind. Die Trefferquote fällt, das Vertrauen fällt mit, und nach einigen Wochen benutzt es niemand mehr.

‍

Woran Sie es früh erkennen: Fragen Sie, wer den Datensatz für den Piloten zusammengestellt hat und wie lange das gedauert hat. Wenn die Antwort zwei Tage, hat die Kollegin gemacht lautet, testen Sie nicht Ihre Daten, sondern eine Auswahl davon.

Was stattdessen hilft: Den Piloten auf einem Ausschnitt echter Produktionsdaten laufen lassen, inklusive der Fälle, die niemand mag. Lieber eine schlechtere Trefferquote im Piloten und eine ehrliche Zahl als umgekehrt.

‍

Ursache 2: Niemand ist für das Ergebnis zuständig

Ein KI-System trifft Vorschläge, keine Entscheidungen. Irgendwer muss diese Vorschläge prüfen, freigeben oder korrigieren, und irgendwer muss dafür geradestehen, wenn etwas falsch durchgeht.

In vielen Piloten ist das die Projektleitung, weil sie ohnehin da ist. Im Betrieb ist die Projektleitung weg. Wenn dann nicht festgelegt ist, wer die Rolle übernimmt, passiert eines von zwei Dingen: Entweder prüft niemand, und das erste sichtbare Fehlergebnis beendet das Projekt. Oder alle prüfen alles doppelt, und die Zeitersparnis, wegen der das Ganze angefangen wurde, ist verschwunden.

Woran Sie es früh erkennen: Fragen Sie, wer nach dem Go-live die Ausgaben kontrolliert, und zwar namentlich. Kommt eine Abteilung als Antwort statt einer Person, ist die Rolle nicht besetzt.

Was stattdessen hilft: Die Prüfung gehört in die Oberfläche, nicht in eine Nebenaufgabe. Ein Mensch prüft das ist schnell in ein Konzept geschrieben. In der Software braucht es einen Ort, an dem dieser Mensch sieht, was das System vorschlägt, und es ändern kann, ohne den Vorgang zu verlassen. Fehlt dieser Ort, wird aus der Prüfung ein Durchklicken.

Dazu gehört die Einweisung. Wer prüfen soll, muss wissen, wie das System zu seinem Vorschlag kommt und in welchen Fällen es typischerweise danebenliegt. Eine Stunde zum Start und ein fester Ansprechpartner für Rückfragen reichen meistens. Fehlt beides, wird aus der Prüfung eine Formsache.

‍

Ursache 3: Erfolg wurde nicht definiert, bevor es losging

Diese Ursache ist die häufigste und die am leichtesten zu vermeidende.

Ein Pilot startet mit dem Ziel, zu sehen, was geht. Nach drei Monaten steht ein System, das erkennbar etwas kann. Dann stellt jemand aus der Geschäftsführung die Frage, was es gebracht hat, und niemand hat eine Zahl. Es gibt keine Zahl, weil vorher nicht gemessen wurde, wie lange der Vorgang ohne das System gedauert hat.

Ohne Ausgangswert gibt es keinen Vergleich. Ohne Vergleich gibt es keine Freigabe für den Rollout. Das Projekt scheitert nicht an schlechten Ergebnissen, sondern daran, dass es keine Ergebnisse vorweisen kann.

Das ist kein Randphänomen: Im GenAI Impact Report Germany 2026 von adesso geben 17 Prozent der Unternehmen an, den Return on Investment ihres KI-Einsatzes gar nicht zu messen.

Woran Sie es früh erkennen: Fragen Sie vor dem Start, welche Zahl sich verbessern soll und wie hoch sie heute ist. Wenn die zweite Hälfte der Frage unbeantwortet bleibt, ist der Pilot noch nicht startbereit.

Was stattdessen hilft: Vor dem Bauen eine Woche messen. Wie viele Vorgänge pro Tag, wie lange pro Vorgang, wie hoch die Fehlerquote heute. Das ist unspektakulär und entscheidet später darüber, ob das Projekt weiterläuft.

‍

Ursache 4: Der Prozess darunter funktioniert nicht

Der unangenehmste Punkt, und der Grund, warum wir Kunden regelmäßig von KI abraten.

KI beschleunigt einen Ablauf. Sie ordnet ihn nicht. Wenn ein Prozess unklare Zuständigkeiten hat, wenn dieselbe Information an drei Stellen gepflegt wird, wenn es für jeden zweiten Fall eine Ausnahme gibt, dann macht ein KI-System diesen Prozess schneller und gleichzeitig unübersichtlicher. Das Ergebnis ist schlechter als vorher, obwohl die Technik funktioniert.

In diesen Fällen ist die richtige Antwort nicht ein besseres Modell, sondern eine Prozessklärung oder eine Schnittstelle, die verhindert, dass dieselbe Information dreimal existiert. Das ist weniger attraktiv als ein KI-Projekt und löst das Problem.

Woran Sie es früh erkennen: Lassen Sie sich den Prozess von zwei Personen beschreiben, die ihn täglich machen. Weichen die Beschreibungen voneinander ab, gibt es keinen Prozess, sondern eine Gewohnheit.

Was stattdessen hilft: Den Prozess so weit klären, dass zwei Menschen ihn gleich beschreiben. Danach lässt sich seriös beurteilen, ob KI dort etwas beiträgt. Vorher nicht.

‍

Ursache 5: Compliance wurde erst am Ende geprüft

Im Piloten fragt niemand nach dem Datenschutz, weil mit Testdaten gearbeitet wird. Beim Schritt in den Betrieb stellt sich die Frage auf einmal vollständig, und zwar von mehreren Seiten: Der Datenschutz will wissen, welche Daten wohin fließen. Die IT-Sicherheit will Rollen und Protokolle sehen. Die Geschäftsführung will wissen, wer geradesteht, wenn ein Ergebnis falsch ist.

Wenn das erst jetzt beginnt, ist das Ergebnis selten ein Nein. Häufiger sind es Monate, in denen ein fertiges System dasteht und niemand die Freigabe erteilen will. Diese Monate kosten den Rückhalt im Unternehmen, und mit dem Rückhalt endet das Projekt.

Woran Sie es früh erkennen: Fragen Sie, wer den Datenschutz im Projekt vertritt und wann er das erste Mal gefragt wurde. Lautet die Antwort, das machen wir, wenn es so weit ist, steht der Termin für den Betrieb nur auf dem Papier.

Was stattdessen hilft: Datenschutz und IT-Sicherheit beim Zuschnitt des Piloten an den Tisch holen, nicht zur Abnahme. Meistens geht es um wenige Festlegungen: welche Daten das System sehen darf, wo sie verarbeitet werden, wer Zugriff hat und wie lange etwas gespeichert bleibt. Früh geklärt sind das Rahmenbedingungen. Spät geklärt sind es Blockaden. Welche Nachweise Sie dafür von einem Dienstleister verlangen können, steht unter Compliance-Nachweise beim Softwaredienstleister.

‍

Was keine Ursache ist

Drei Dinge, die regelmäßig verdächtigt werden und selten schuld sind.

Das falsche Modell. Die Auswahl des Modells ist inzwischen eine der leichteren Entscheidungen im Projekt und lässt sich später ändern. Sie entscheidet fast nie über Erfolg oder Misserfolg.

Zu wenig Budget. Das Modell ist der billigste Teil der Rechnung. Der Aufwand steckt in der Anbindung an bestehende Systeme, in den Berechtigungen und darin, die Daten überhaupt erreichbar zu machen. Wer beim Modell spart und diesen Teil unterschätzt, hat das Verhältnis umgedreht. Auch die Befragten im GenAI Impact Report Germany 2026 sehen das so: Budget nennen nur 21 Prozent als Hürde, deutlich hinter den organisatorischen Gründen.

Die fehlende KI-Strategie. Was Ihnen nicht weiterhilft, ist ein externer Berater, der eine allgemeine KI-Strategie als Foliensatz abliefert und danach wieder weg ist. Was Ihnen weiterhilft, ist ein Strategiepapier, das beschreibt, wo KI in Ihrer vorhandenen Softwarelandschaft ansetzt, und die konkrete Einordnung Ihres Vorhabens: keine Absichtserklärung, sondern die Entscheidung, welches System künftig welche Aufgabe übernimmt. Wie das aussieht, steht im nächsten Abschnitt.

‍

Warum ein Vorlauf das Projekt schneller macht

Ein Pilot soll schnell sein, und das ist richtig. Schnell heißt aber nicht, ohne Plan anzufangen.

Für einen einzelnen Anwendungsfall lässt sich fast immer ein Werkzeug finden, das genau diesen Fall abdeckt. Das trägt, solange es bei diesem einen Fall bleibt. Kommt der zweite dazu, liegt derselbe Datenbestand plötzlich an zwei Stellen, die Berechtigungen unterscheiden sich, und beim Datenschutz steht statt einer Prüfung eine zweite an. Nach dem dritten Werkzeug verwaltet das Unternehmen Insellösungen statt Software.

Deshalb beginnt ein KI-Projekt bei uns nicht mit dem Piloten, sondern mit einer Einordnung in die bestehende Softwarelandschaft: Welche Systeme sind im Einsatz, welche tragen noch, welche werden abgelöst, wo wird erweitert statt ersetzt. Erst danach steht fest, an welcher Stelle eine KI-Funktion sinnvoll andockt, welche Daten sie sehen darf und ob die Entscheidung von heute auch in zehn Jahren noch trägt.

Das deckt sich mit der Praxis: Im GenAI Impact Report Germany 2026 nennen 43 Prozent der IT-Verantwortlichen fehlende Anbindungsmöglichkeiten für KI als einen der größten Treiber für Modernisierung, und 46 Prozent erwarten von einer Modernisierung vor allem bessere Voraussetzungen für den KI-Einsatz.

Dieser Vorlauf klärt vier Dinge:

• Welche Anwendungen bleiben, welche abgelöst und welche erweitert werden.
• Wo die Daten liegen, die gebraucht werden, und wer darauf zugreifen darf.
• Welcher Rahmen für Datenschutz und IT-Sicherheit gilt, bevor gebaut wird.
• Welcher Zuschnitt in sechs Wochen etwas Benutzbares ergibt.

‍

Ab diesem Punkt geht es schnell. Sind diese Fragen beantwortet, ist der Rest Umsetzung. KI-Agenten schreiben Code inzwischen sehr schnell, Oberflächen entstehen als Prototyp in wenigen Tagen, und ein erster benutzbarer Stand nach sechs Wochen ist realistisch. Was sich nicht beschleunigen lässt, ist die Entscheidung darüber, was gebaut werden soll.

Was wir dafür brauchen. Der Vorlauf funktioniert nur mit den Fachbereichen zusammen. Wir brauchen Einblick darin, wie intern tatsächlich gearbeitet wird, welche Systeme im Einsatz sind und an welchen Stellen die Abläufe von der offiziellen Beschreibung abweichen. Ohne diesen Einblick entsteht keine Strategie, sondern eine Vermutung. Sechs Wochen sind deshalb kein Versprechen für jedes Projekt, sondern das, was möglich wird, wenn vorher entschieden wurde.

‍

Die Sechs-Wochen-Regel

Eine Regel aus der Praxis, die sich als brauchbarer Filter erwiesen hat: Wenn nach sechs Wochen nichts Benutzbares da ist, war der Zuschnitt falsch.

Die sechs Wochen beginnen nicht beim ersten Gespräch. Sie beginnen an dem Punkt, an dem der Vorlauf abgeschlossen ist: Anforderungen stehen, der Zuschnitt ist entschieden, der Datenzugriff ist geklärt. Ab da ist die Uhr aussagekräftig, vorher misst sie nichts.

‍

Benutzbar heißt nicht fertig. Es heißt, dass jemand aus der Fachabteilung es öffnen, damit arbeiten und sagen kann, ob es in die richtige Richtung geht. Ein Prototyp, den nur das Projektteam bedienen kann, zählt nicht.

Die Regel hilft weniger beim Bauen als beim Zuschneiden. Ein Vorhaben, das in sechs Wochen nichts Benutzbares hervorbringt, ist meistens zu groß geschnitten und lässt sich teilen. Für einen ersten produktiven Stand oder eine einfache Prozessautomatisierung sind sechs bis zwölf Wochen ein realistischer Rahmen, mittelgroße bis komplexe Anwendungen liegen bei etwa drei bis sechs Monaten.

‍

Häufige Fragen

Wie viele KI-Projekte scheitern?

Die Zahlen schwanken je nach Untersuchung und je nachdem, was als Scheitern gezählt wird. Aussagekräftiger ist, woran es liegt. Im GenAI Impact Report Germany 2026 von adesso nennen 38 Prozent der Befragten Compliance und Sicherheit als größte Hürde für KI in der Softwareentwicklung, 34 Prozent fehlende Kompetenzen im Team und 25 Prozent mangelnde Akzeptanz. Veraltete Architektur (20 Prozent) und fehlender Datenzugriff (15 Prozent) folgen erst dahinter. Entscheidend ist also nicht die Prozentzahl, sondern dass die Mehrheit nicht an der Technik scheitert, sondern am Übergang vom Piloten in den Betrieb.

Woran scheitern KI-Projekte am häufigsten?

An fünf Punkten: Der Pilot lief auf bereinigten Daten, die es im Betrieb nicht gibt. Nach dem Go-live ist niemand namentlich für die Ergebnisse zuständig. Es wurde kein Ausgangswert gemessen, mit dem sich der Nutzen belegen ließe. Der zugrundeliegende Prozess war schon vorher nicht klar genug. Und Datenschutz und IT-Sicherheit wurden erst geprüft, als das System bereits stand.

Warum kommt unser Pilot nicht in den Betrieb?

Meistens, weil der Betrieb drei Dinge voraussetzt, die im Piloten niemand gebraucht hat: eine Freigabe für echte Daten, die Anbindung an die Systeme, in denen die Arbeit stattfindet, und eine Einweisung der Menschen, die mit den Ergebnissen arbeiten sollen. Alle drei lassen sich vorbereiten, solange der Pilot noch läuft.

Was kostet ein KI-Projekt?

Der Modellbetrieb ist meist der kleinste Posten. Der Aufwand liegt in der Anbindung an bestehende Systeme, in Berechtigungen und Datenzugriff sowie in der Oberfläche, über die Menschen die Ergebnisse prüfen.

Wann ist KI die falsche Antwort?

Wenn der Prozess darunter nicht klar ist, wenn die benötigten Daten nicht zugänglich sind, oder wenn eine einfache Regel dasselbe leistet. In diesen Fällen raten wir ab. Eine Schnittstelle oder eine Prozessklärung ist dann die günstigere und haltbarere Lösung.

Müssen wir unsere Software ersetzen, um KI einzusetzen?

In der Regel nicht. KI wird an bestehende Anwendungen angebunden, dort wo die Arbeit ohnehin stattfindet. Eine Neuentwicklung ist nur dann sinnvoll, wenn das bestehende System keine Schnittstellen hat und auch keine bekommen kann.

Wie lange dauert es, bis ein KI-Projekt im Betrieb ist?

Gerechnet ab dem Punkt, an dem Anforderungen und Zuschnitt stehen: sechs bis zwölf Wochen für einen ersten produktiven Stand oder eine einfache Prozessautomatisierung, etwa drei bis sechs Monate für mittelgroße bis komplexe Anwendungen. Davor liegt der Vorlauf, in dem das Vorhaben in die bestehende Softwarelandschaft eingeordnet wird. Wie lange der dauert, hängt davon ab, wie schnell die Fachbereiche Einblick geben.

‍

Was wir vor dem Start klären

Fünf Fragen, die wir in jedem KI-Projekt am Anfang stellen. Sie kosten ein Gespräch und ersparen im Zweifel einen Piloten.

Welcher Prozess soll besser werden, und wie gut ist er heute?

Ohne Ausgangswert gibt es später keinen Nachweis.

Welche Daten muss das System sehen?

Diese eine Frage entscheidet mehr über die Architektur als jede andere. Welche Rechtsgrundlage dafür nötig ist und mit welchen vier Bauweisen sich das Risiko technisch senken lässt, steht unter Kundendaten in KI-Systeme geben.

Wer prüft die Ausgaben nach dem Go-live?

Namentlich, nicht als Abteilung, und an einer festen Stelle in der Oberfläche.

Was ist der kleinste Zuschnitt, der in sechs Wochen benutzbar ist?

Falls es keinen gibt, wird geteilt, bevor gebaut wird.

Wer gibt den Betrieb frei, und was braucht diese Person dafür?

Datenschutz und IT-Sicherheit gehören in das erste Gespräch, nicht in die Abnahme.

Devware entwickelt seit 2004 Software für den Mittelstand und bindet KI in bestehende Anwendungen ein, ISO 27001 und ISO 9001 zertifiziert. Den Ablauf finden Sie unter KI-Integration, den Umgang mit Kundendaten unter KI und Compliance. Welche Nachweise Sie von einem Dienstleister verlangen können, steht unter Compliance-Nachweise beim Softwaredienstleister.

‍

Hinweis: Dieser Artikel ist eine fachliche Einordnung aus der Sicht eines Softwareentwicklers, keine Rechtsberatung.

Zur Entstehung: Unsere Inhalte entstehen mit Unterstützung von KI, aber jeder Text geht durch eine doppelte menschliche Prüfung, bevor er veröffentlicht wird.

‍

Quellen

• GenAI Impact Report Germany 2026, Schwerpunkt Softwareentwicklung, adesso SE.
• Umfrage Anwendungsmodernisierung 2026, adesso SE, zitiert im GenAI Impact Report Germany 2026.
• Verordnung (EU) 2016/679, Datenschutz-Grundverordnung, insbesondere Artikel 28 und 32.
• DIN EN ISO/IEC 27001:2024, Informationssicherheitsmanagementsysteme.