KI-Projekte scheitern selten an der Technik: die vier häufigsten Gründe

KI-Projekte scheitern selten an der Technik. Sie scheitern an vier organisatorischen Stellen: an einem Piloten, der nie ein Abnahmekriterium hatte, an fehlender Zuständigkeit nach dem Start, an der unterschätzten letzten Meile ins Bestandssystem und an einer Wirtschaftlichkeitsrechnung, die den laufenden Betrieb nicht enthielt.

Das ist eine gute Nachricht, denn alle vier sind vor dem Start adressierbar und kosten in der Vorbereitung deutlich weniger als in der Reparatur. Dieser Artikel geht sie einzeln durch, mit dem Muster, an dem man sie erkennt, und mit dem, was man stattdessen tut.

Was die Zahlen zur Scheiterquote wirklich sagen

Die meistzitierte Zahl zum Thema stammt aus dem Bericht «The GenAI Divide: State of AI in Business 2025» der MIT-Initiative NANDA vom August 2025: 95 Prozent der untersuchten Pilotprojekte mit generativer KI zeigten keine messbare Wirkung auf die Erfolgsrechnung. Die Grundlage waren 52 Interviews mit Führungskräften, eine Befragung von 153 Verantwortlichen und die Auswertung von 300 öffentlich dokumentierten Einsätzen.

Zwei Einschränkungen gehören dazu, sonst wird aus einer nützlichen Beobachtung ein Angstargument. Erstens beschreibt die Untersuchung grosse Unternehmen mit entsprechenden Budgets, nicht Schweizer KMU mit fünf bis fünfzig Mitarbeitenden. Zweitens misst «keine messbare Wirkung auf die Erfolgsrechnung» auch dort mit, wo schlicht nichts gemessen wurde — was für sich genommen schon der erste der vier Gründe ist.

Die für uns wichtigere Aussage des Berichts ist nicht die Prozentzahl, sondern die Ursachenzuschreibung: Die Autoren führen das Ergebnis auf mangelhafte Integration in bestehende Abläufe zurück, nicht auf die Qualität der Modelle. Genau das deckt sich mit dem, was in kleineren Organisationen passiert — nur mit kleineren Beträgen.

Grund 1: Der Pilot hatte kein Abnahmekriterium

Der häufigste Grund ist der unauffälligste: Ein Pilot startet ohne vorher gemessenen Ausgangswert und ohne festgelegte Schwelle, ab der er als bestanden gilt. Damit kann er weder bestehen noch scheitern — er versandet, wenn die Aufmerksamkeit nachlässt.

Das Muster ist immer gleich. Es gibt eine Vorführung, die alle beeindruckt, danach eine Testphase «zum Ausprobieren», dann drei Wochen ohne Termin, und schliesslich die Frage in einer Sitzung, ob das eigentlich noch läuft. Niemand kann sie beantworten, weil niemand definiert hat, woran man es erkennen würde.

Ein Abnahmekriterium besteht aus drei Teilen: einer Grösse, die ihr vor dem Start gemessen habt, einer Schwelle und einem Datum. «Die durchschnittliche Bearbeitungszeit pro Vorgang sinkt bis zum 30. November von 90 auf unter 50 Minuten, bei höchstens fünf Prozent Nacharbeit» ist ein Abnahmekriterium. «Wir schauen mal, ob es hilft» ist keines.

Der zweite Teil der Disziplin ist unangenehmer: Das Kriterium muss auch gelten, wenn es verfehlt wird. Ein Pilot, der reissverschlussartig weiterläuft, weil «wir schon so viel investiert haben», ist kein Projekt mehr, sondern eine Kostenstelle. Welche Grössen sich überhaupt eignen, haben wir in Digitale KPIs für KMU genauer aufgeschlüsselt.

Grund 2: Nach dem Go-live war niemand zuständig

Der zweite Grund zeigt sich erst nach dem Start: Für den laufenden Betrieb ist keine Person mit Namen und Zeitbudget verantwortlich. Ein KI-gestützter Ablauf ist kein Möbelstück, das man aufstellt. Er verändert sich, weil sich Modelle, Vorlagen, Preise und Anliegen verändern.

Was ohne Zuständigkeit passiert, lässt sich präzise vorhersagen. Vorlagen veralten, weil das neue Produkt fehlt. Prompts liefern schlechtere Ergebnisse, weil sich das Modell im Hintergrund geändert hat. Fehlerfälle stapeln sich in einem Postfach, das niemand mehr öffnet. Nach ein paar Monaten arbeitet das Team wieder auf dem alten Weg, ohne dass jemals eine Entscheidung gegen das System getroffen worden wäre.

Die Gegenmassnahme ist unspektakulär und wirkt sofort: eine benannte Person mit einem Zeitbudget — realistisch zwei bis vier Stunden im Monat für ein einzelnes System — und einem festen Termin, an dem sie eine Stichprobe prüft. Diese Person muss nicht technisch sein. Sie muss beurteilen können, ob die Ergebnisse fachlich stimmen, und befugt sein, das System abzuschalten, wenn nicht.

In kleinen Betrieben scheitert das oft daran, dass die Rolle zwar vergeben, aber nicht bezahlt wird: Sie kommt zusätzlich zur bestehenden Arbeit obendrauf und verliert im Alltag gegen alles, was einen Kunden hat. Wer die Stunden nicht sichtbar aus etwas anderem herausnimmt, hat die Rolle nicht besetzt, sondern nur benannt.

Grund 3: Die letzte Meile ins Bestandssystem wurde unterschätzt

Der dritte Grund kostet am meisten Geld: Der Aufwand, ein KI-Ergebnis dorthin zu bringen, wo tatsächlich gearbeitet wird, wird regelmässig unterschätzt — und solange Menschen das Ergebnis von Hand ins CRM, in die Buchhaltung oder ins ERP kopieren, ist der Nutzen nur geliehen.

Das Muster erkennt man an einem Satz: «Das exportieren wir dann einfach.» Dahinter steckt in der Praxis das Zusammenführen zweier Datenmodelle, die nie füreinander gebaut wurden, Feldzuordnungen, Dubletten, Zeichensätze, Berechtigungen und die Frage, was passiert, wenn beide Seiten denselben Datensatz gleichzeitig ändern. Diese Arbeit ist unsichtbar in jeder Präsentation und sichtbar in jeder Schlussrechnung.

Zwei Konsequenzen folgen daraus. Erstens gehört die Integration in den Piloten, nicht dahinter: Ein Pilot, der auf Kopieren und Einfügen aufbaut, misst einen Nutzen, den es im Regelbetrieb nicht gibt. Zweitens entscheidet die Anschlussfähigkeit eures Bestandssystems über die Machbarkeit mehr als die Wahl des Modells — eine Frage, die sich in ähnlicher Form auch bei der Grundsatzentscheidung CRM kaufen oder selbst entwickeln stellt.

Manchmal ist die ehrliche Antwort, dass die letzte Meile im aktuellen Systemumfeld nicht wirtschaftlich zu bauen ist. Auch das ist ein brauchbares Projektergebnis, wenn es nach vier Wochen feststeht und nicht nach acht Monaten.

Grund 4: Die Rechnung enthielt nur die Bauzeit

Der vierte Grund ist ein Rechenfehler mit Ansage: Kalkuliert wird der Aufbau, budgetiert wird der Aufbau, und der laufende Betrieb taucht in keiner Zeile auf. Dabei übersteigt er den Aufbau im ersten Jahr regelmässig — und der grösste Posten sind nicht die Modellkosten, sondern menschliche Zeit.

Ein durchgerechnetes Beispiel für ein mittelgrosses internes System mit acht Nutzenden:

Über zwölf Monate ergeben sich CHF 13'020 laufende Kosten gegenüber CHF 12'000 Aufbau. Der Betrieb ist im ersten Jahr also teurer als das Projekt, und rund 61 Prozent davon — CHF 665 im Monat — sind Arbeitszeit von Menschen, nicht Rechnungen von Anbietern.

Wer die Modellkosten selbst im Griff behalten will, findet die Stellschrauben in KI-Kosten kontrollieren. Der Prüfaufwand dagegen sinkt vor allem über Qualität: Je verlässlicher die Ausgaben, desto kleiner die Stichprobe, die es braucht — weshalb der Umgang mit Halluzinationen direkt auf die Betriebskosten durchschlägt.

Was die vier Gründe gemeinsam haben

Alle vier Gründe teilen dieselbe Wurzel: Sie entstehen dort, wo ein Vorhaben als Technikprojekt geführt wird statt als Veränderung eines Arbeitsablaufs. Abnahme, Zuständigkeit, Integration und Betrieb sind allesamt Fragen der Organisation — und genau deshalb fallen sie durch, wenn die Verantwortung beim Werkzeug liegt und nicht bei der Abteilung, die damit arbeitet.

Daraus folgt die praktische Konsequenz: Die Auswahl des Modells oder des Anbieters ist die am wenigsten entscheidende Entscheidung im Projekt. Sie fühlt sich wichtig an, weil sie konkret ist und weil dazu viel geschrieben wird. Sie ist aber austauschbar, während eine fehlende Zuständigkeit oder eine nicht gebaute Schnittstelle das ganze Vorhaben trägt oder fallen lässt.

Die fünf Fragen vor dem Start

Die vier Gründe lassen sich vor dem Start mit fünf Fragen abfangen, die zusammen weniger als eine Sitzung kosten. Erstens: Welche Grösse messen wir heute, und wie hoch ist sie? Zweitens: Ab welchem Wert und bis zu welchem Datum gilt der Pilot als bestanden? Drittens: Wer prüft nach dem Start die Ergebnisse, wie oft, und aus welchem Zeitbudget? Viertens: In welches System muss das Ergebnis fliessen, und wer hat diese Verbindung schon gebaut? Fünftens: Was kostet der Betrieb pro Monat, Arbeitszeit eingerechnet?

Wer alle fünf beantworten kann, hat kein garantiert erfolgreiches Projekt — aber eines, das rechtzeitig scheitert, wenn es scheitert. Das ist der eigentliche Unterschied zwischen einem teuren und einem günstigen Fehlschlag.

Vieles davon lässt sich vor der ersten Zeile Code klären. Ob die Voraussetzungen überhaupt gegeben sind, prüft der KI-Readiness-Check; wo man am besten anfängt, zeigen die drei Anwendungsfälle, die sich fast immer rechnen. Für Vorhaben, die über einen Standardfall hinausgehen, ist ein Prototyp zur Validierung ab CHF 10'000 der Weg, das Risiko einzugrenzen, bevor es gross wird — und wer den ganzen Rahmen extern gesetzt haben möchte, findet den Ablauf unter KI-Beratung Schweiz.