Warum KI-Projekte in kleinen Betrieben scheitern, und was die anders gemacht haben, die funktioniert haben
LEITFADEN · FÜR SKEPTIKER · 11 MIN
Angaben auf dieser Seite geprüft im August 2026.
Die kurze Antwort: fast nie das Modell, fast immer die Art, wie das Projekt aufgesetzt wurde
KI-Projekte scheitern an Entscheidungen, die fallen, bevor überhaupt eine Software ausgewählt ist. Vier Ursachen erklären das meiste davon. Niemand hat die Zahl aufgeschrieben, die das Projekt bewegen sollte. Niemand war zuständig, sobald es lief. Die Maschine stand neben der eigentlichen Arbeit, nicht in ihr. Und der Umfang wurde gewählt, weil er interessant war, und nicht, weil dort Geld versickerte. Alle vier sind organisatorisch, alle vier sind bei zwanzig Leuten billig zu beheben, und bei keiner von ihnen geht es darum, welches Modell Sie einsetzen.
Die Zahl, die alle zitieren, richtig gelesen
Sie kennen die Schlagzeile: 95 Prozent der KI-Projekte in Konzernen bringen nichts. Sie stammt aus einer einzigen Studie, sie ist ein echter Befund, und fast jeder Artikel, der sie wiederholt, gibt falsch wieder, worauf sie sich bezieht. Hier steht, was sie gemessen hat.
95 % · 5 %
Gezählt wurden große Organisationen, nicht Betriebe wie Ihrer. 150 Interviews mit Führungskräften, eine Befragung von 350 Mitarbeitern und 300 öffentlich dokumentierte Inbetriebnahmen, alles auf Konzernebene. Das ist ein Befund über Programme mit generativer KI in großen Unternehmen. Es ist kein Befund, dass die Technik nicht funktioniert, und keine Vorhersage, dass ein Betrieb mit zwanzig Leuten, der einen Agenten an sein Telefon hängt, in neunzehn von zwanzig Fällen scheitert.
Die zweite Zahl schreiben die meisten dem falschen Herausgeber zu. Suchen Sie nach Ausfallraten von KI-Projekten, und Sie lesen, RAND habe herausgefunden, dass mehr als 80 Prozent der KI-Projekte scheitern. Öffnen Sie den Bericht, dann steht der Satz in der Einleitung, mit einer Fußnote auf einen Zeitschriftenkommentar.
> 80 %
Was RAND tatsächlich gemacht hat, ist nützlicher als die geborgte Zahl. 65 Interviews mit Data Scientists und Ingenieuren mit mindestens fünf Jahren Berufserfahrung, geführt zwischen August und Dezember 2023, daraus fünf Grundursachen. Vier der fünf sind organisatorisch: das falsche Problem, die falschen Daten, hinter der Technik herlaufen statt hinter dem Nutzer, und eine Infrastruktur, die ein Modell im Betrieb nicht trägt. Nur die fünfte betrifft die Grenzen der Technik selbst.
Die dritte Zahl sagt, dass die Fehlschläge bemerkt werden und dass jemand handelt. Die Abbruchquote ist binnen eines Jahres stark gestiegen, und das ist ein gesünderes Signal, als es klingt: Unternehmen stoppen jetzt, was nicht funktioniert, statt es angeschaltet zu lassen.
42 % · 17 %
Liest man die drei zusammen, wird das Muster deutlich. Scheitern ist häufig, es nimmt zu, und es ist ganz überwiegend organisatorisch. Jede dieser Studien hat Unternehmen betrachtet, die weit größer sind als Ihres. Das begrenzt, was sie belegen, und darin liegt zugleich die Chance: Die genannten Ursachen sind bei zwanzig Leuten billiger zu vermeiden als bei zwanzigtausend, weil bei zwanzig Leuten derjenige entscheidet, der die Maschine auch laufen sieht.
Die fünf Arten, wie es wirklich schiefgeht
Jedes Fehlermuster unten beschreibt zuerst, wie es im Betrieb von innen aussieht, und danach, was die Projekte stattdessen gemacht haben, die funktioniert haben. Keines davon ist exotisch. Jedes entscheidet sich in den ersten zwei Wochen, meist in einem Gespräch, das niemand aufgeschrieben hat.
Eins: Es gab nie einen Ausgangswert. Freigegeben wurde das Projekt aus dem Gefühl heraus, dass etwas langsam läuft, und ein Jahr später wird es nach einem anderen Gefühl beurteilt. Niemand kann sagen, was das Telefon vorher gekostet hat, also kann auch niemand sagen, was es jetzt kostet, und der Posten verliert die nächste Budgetdiskussion still an etwas, das eine Zahl vorlegen kann. Das ist das häufigste der fünf und das billigste, das man hätte vermeiden können.
Zwei: Nach dem Start war niemand zuständig. Der Aufbau war fertig, der Dienstleister weg, und die Automatisierung gehörte allen und damit niemandem. Sechs Wochen später änderte sich eine Öffnungszeit, oder eine Preisliste wurde angepasst, und der Agent gab eine Antwort, die früher richtig war. Niemand hatte die Aufgabe, das zu bemerken, also bestand die Reparatur darin, ihn abzuschalten.
Drei: Die Maschine lief neben der Arbeit statt in ihr. Die Maschine lieferte etwas Richtiges, und dann musste jemand es in das System übertragen, in dem die Arbeit wirklich stattfindet. Dieses Übertragen ist die Steuer, an der die Nutzung stirbt: klein genug, dass sich niemand beschwert, und groß genug, dass die Leute es binnen eines Monats sein lassen. Ein Werkzeug, das in einem eigenen Tab wohnt, ist ein Werkzeug, das in einer vollen Woche liegen bleibt.
Vier: Der Umfang wurde gewählt, weil er interessant war. Der Chatbot auf der Website, die Dokumentenklassifikation, das Ding, das sich gut vorführen lässt. Nichts davon hat das Telefon berührt, das um zwei Uhr nachmittags ins Leere klingelt. Interesse ist ein schlechter Anhaltspunkt für Kosten, und die Aufgaben, die Menschen interessant zu automatisieren finden, sind fast nie die Aufgaben, bei denen still das Geld versickert.
Fünf: Es gab keinen Weg zurück. Der alte Ablauf wurde an dem Tag abgeschaltet, an dem der neue in Betrieb ging, und so wurde aus der ersten schlechten Woche ein Notfall statt einer Entscheidung. Betriebe, die nicht zurückfallen können, können nicht ausprobieren, und Betriebe, die nicht ausprobieren können, verteidigen am Ende einen Aufbau, den niemand belegen kann, statt ihn zu stoppen.
Warum ein kleiner Betrieb die Projekte aus diesen Studien nicht stemmen kann
Die Studien oben beschreiben einen Projektzuschnitt, den Sie sich nicht leisten können und nicht wollen sollten. Ein sechsmonatiges Erkundungsprogramm mit Lenkungsausschuss ist die Art, wie ein Konzern herausfindet, ob sich etwas lohnt. Ein Betrieb mit zwanzig Leuten braucht einen kleineren Zuschnitt mit schärferer Kante, und der muss so oder so eine Antwort liefern.
- Eine Verlustquelle, vorab benannt. Keine Abteilung und keine Kategorie. Der unbeantwortete Anruf, die erste Antwort erst am nächsten Tag, der Termin, der leer bleibt, das Dokument, das jemand abtippt. Versickert an zwei Stellen Geld, nehmen Sie die größere Verlustquelle und lassen die andere in Ruhe, bis diese hier belegt ist.
- Eine Zahl, erhoben, bevor der Aufbau beginnt. Aus Ihrer eigenen Anrufliste, Ihrem Kalender oder Ihrem Postfach, nicht aus einem Branchendurchschnitt. Genau muss sie nicht sein. Sie muss Ihre sein, und sie muss dort stehen, wo beide Seiten sie sehen, denn an ihr wird das Ergebnis gemessen.
- Ein Abnahmetest, geschrieben von dem, der bezahlt. Ein Satz, der das hier zum Erfolg macht, in Ihren Worten, bevor irgendjemand irgendetwas baut. Kann der Käufer diesen Satz nicht schreiben, hat das Projekt keine Ziellinie, und am Ende wird darüber gestritten statt gemessen. Wenn der Dienstleister ihn für Sie schreibt, ist das genau das Fehlermuster in der Verkleidung der Hilfsbereitschaft.
- Ein Weg zurück, erprobt statt versprochen. Die alte Weiterleitung bleibt eingerichtet, jemand hat während des Aufbaus tatsächlich einmal zurückgeschaltet, und die zwei Wochen, die ein kompletter Abbruch kosten würde, sind ein Preis, den Sie eingeplant haben, bevor Sie angefangen haben.
Diese Liste ist das, was wir vertraglich liefern, keine Theorie über das Scheitern anderer. So sieht ein erster Aufbau hier aus: zehn Arbeitstage bis zum ersten lauffähigen Prototyp, eine Verlustquelle, eine Zahl, ein Abnahmetest in Ihren Worten, und der alte Weg bleibt darunter angeschaltet. Wir haben das so aufgeschrieben, weil wir genau diese fünf Fehlermuster bei Betrieben gesehen haben, bevor sie uns angerufen haben.
Die Nachbetrachtung, auch die für das Projekt, das nicht funktioniert hat
Ein erstes Projekt, das nicht ehrlich scheitern kann, ist kein Versuch, sondern ein Kauf. Deshalb steht am Ende eine kurze schriftliche Auswertung mit vier Fragen, und die wird geschrieben, egal ob das Ergebnis gut oder schlecht war. Diesen Teil macht fast niemand, und deshalb haben so viele Betriebe eine Schublade voller Automatisierungen, für die niemand Rechenschaft ablegen kann.
- Wie war die Zahl vorher, und wie ist sie jetzt? Dasselbe Maß, auf dieselbe Weise erhoben, über einen vergleichbaren Zeitraum. Hat sich die Messung auf halbem Weg geändert, schreiben Sie das in die Auswertung, statt die Fassung zu nehmen, die dem Ergebnis schmeichelt.
- Was hat die Maschine an einen Menschen zurückgegeben, und warum? Übergaben sind keine Fehler, sie sind der Aufbau, der tut, was er tun soll. Aber die Gründe sind eine Karte: Wenn ein Viertel der Anrufe aus demselben Grund übergeben wird, ist dieser Grund entweder die nächste Regel, die geschrieben wird, oder die Grenze dessen, was überhaupt automatisiert gehört.
- Was ist ausgefallen, und wie lange hat es gedauert, bis es jemand bemerkt hat? Die zweite Hälfte wiegt schwerer als die erste. Ein Fehler, der nach einer Stunde auffällt, ist eine Störung. Derselbe Fehler, der nach fünf Wochen auffällt, ist ein Messproblem, und die Reparatur heißt Überwachung, nicht Software.
- Ausweiten, halten oder aufhören? Alle drei sind in Ordnung, und einem Betrieb, der die Zahl nie aufgeschrieben hat, stehen nur zwei davon offen. Die zwei Wochen, die das Aufhören kostet, sind nicht verschwendet: Aufhören ist die billigste wahre Antwort, die Sie auf eine Frage bekommen, die sonst drei Jahre Misstrauen gegen das Ganze kostet.
Damit landet das ganze Argument wieder vor dem Aufbau, wo es hingehört. Das meiste, was schiefgeht, entscheiden die Verlustquelle, die Sie auswählen, und die Zahl, die Sie aufschreiben, und beides ist von außen lesbar. Der Check für 29 € liest Ihre Anrufwege, Antwortwege, Buchungswege und Dokumentenwege am selben Tag und kommt mit den Kandidaten in einer Rangfolge zurück, mit offengelegter Rechnung, damit das erste Projekt nach Belegen ausgewählt wird und nicht danach, welche Vorführung am überzeugendsten war.