KI-Pilot gescheitert: Budget neu bewerten

Sie haben es schon versucht. Das Tech-Team hat einen ChatGPT-Wrapper gebaut, die Operations-Abteilung hat einen Automatisierungs-Pilot evaluiert, irgendwer hat eine Use-Case-Liste gemacht. Und am Ende ist nicht viel davon im Tagesgeschäft angekommen.

Sie sind nicht allein damit. Das MIT NANDA Project hat 2025 gemessen, dass fünf Prozent der generativen KI-Pilots in Unternehmen tatsächlich in den Regelbetrieb übergehen. Fünfundneunzig Prozent versanden — nicht weil die Technik schlecht war, sondern fast immer an denselben drei strukturellen Stellen.

Dieser Beitrag ist für die zweite Hälfte: für Geschäftsführer:innen im Mittelstand, die jetzt überlegen, ob ein zweiter Anlauf Sinn ergibt — oder ob sie das Thema sauber vertagen sollten. Beides kann die richtige Antwort sein. Welche es ist, hängt von drei ehrlichen Fragen ab.

Drei strukturelle Gründe, warum Pilots scheitern

Nach der MIT-Studie und unserer eigenen Beobachtung im deutschen Mittelstand lassen sich die Fehlschläge fast immer auf drei Muster zurückführen.

1. Der Pilot war eine Tech-Demo, kein Workflow

Das häufigste Anti-Pattern: jemand zeigt, dass ein Sprachmodell Rechnungen extrahieren oder Anfragen klassifizieren kann. Auf einem Notebook, mit hübschen Beispiel-Daten. Niemand misst, wie das im echten Tagesgeschäft funktioniert: bei Belegen, die schlechter fotografiert sind als im Demo-Set, bei Kundenanfragen, die nicht zur Schema-Vorlage passen, bei Workflows, in denen drei verschiedene Systeme aneinander hängen müssen.

Materna hat dieses Muster für den deutschen Mittelstand 2024 als „den Sprung von der PoC zur Produktion" beschrieben. Bei genauer Betrachtung war der PoC oft gar kein Pilot, sondern eine Machbarkeitsstudie. Beides ist sinnvoll, aber nur, wenn die Erwartungshaltung klar ist.

2. Keine ehrliche Erfolgsdefinition

Die zweite Stelle, an der Pilots versanden: niemand hat vorab festgelegt, woran man erkennt, dass das Projekt funktioniert hat. „Wir wollen mit AI experimentieren" ist kein Erfolgskriterium. „Drei Mitarbeiter sparen pro Woche je vier Stunden, gemessen über sechs Wochen mit Korrekturen unter zehn Prozent" ist eines.

Wenn das Kriterium fehlt, gewinnt am Ende die lauteste Stimme. Und die lauteste Stimme ist im Mittelstand selten die, die das Tagesgeschäft macht.

3. Kein Anschluss an bestehende Systeme

Pilot läuft, Zahlen sind gut, alle sind begeistert — und dann scheitert die Produktivsetzung daran, dass die Lösung mit DATEV nicht spricht, das CRM keinen API-Zugang hat oder die Datenbank an die der Pilot-Workflow gedacht war, formell zu jemand anders im Haus gehört.

Wir sehen diese Schwelle besonders oft bei mittelständischen Betrieben, die zehn bis fünfzig Mitarbeitende haben: die Pilot-Architektur lebt isoliert, weil sie sonst nie fertig geworden wäre. Aber genau diese Isolation macht den Übergang in den Regelbetrieb dann unmöglich.

Drei ehrliche Fragen vor dem Neustart

Bevor Sie nochmal Budget freigeben — oder das Thema vertagen — gehen Sie diese drei durch.

Frage 1: War der Use-Case echt oder gewollt?

Ein häufiges Muster: das Thema „AI" hat Druck erzeugt, also wurde irgendein Use-Case gewählt, an dem man es schnell zeigen konnte. Wenn der Use-Case nicht aus einem echten Schmerzpunkt im Tagesgeschäft kam, sondern aus dem Versuch, „etwas mit AI zu machen", ist der nächste Pilot mit hoher Wahrscheinlichkeit wieder ein gewollter.

Der ehrliche Test: Wenn AI nicht existierte, wären die involvierten Mitarbeitenden trotzdem motiviert, diesen Prozess zu verbessern? Wenn die Antwort nein ist, ist der zweite Anlauf vermutlich keine Investition wert.

Frage 2: Sind die Daten wirklich da?

Die zweite Stelle, an der wir Neustarts früh stoppen: wenn die Daten, die der Use-Case braucht, in der Realität nicht in der nötigen Qualität oder Vollständigkeit existieren. Drei Excel-Dateien mit unterschiedlichen Spalten, ein PDF-Archiv ohne OCR, ein E-Mail-Postfach ohne sinnvolle Tags — das ist die typische Datenlage im Mittelstand. AI macht aus schlechten Daten keine guten.

Der ehrliche Test: Wenn das Datenfundament zuerst aufgeräumt werden müsste, ist „Excel-Ablösung" oder „Datenmodell-Sortierung" möglicherweise der ehrlichere erste Schritt. Wir haben Mittelstands-Kunden, bei denen genau diese Reihenfolge — erst Daten, dann AI — das eigentliche Investment war. Mehr dazu in unserer Excel-zu-Web-App-Leistung.

Frage 3: Was passiert nach dem zweiten Pilot?

Die dritte Frage stellt sich kaum jemand, und sie entscheidet, ob der Neustart in die Produktion kommt: Wer übernimmt die fertige Lösung im Tagesgeschäft? Wer hostet sie? Wer korrigiert, wenn das Modell sich anders verhält als erwartet? Wer schreibt die Standardarbeitsanweisungen neu?

Wenn diese Fragen unklar sind, läuft der zweite Pilot in dieselbe Sackgasse wie der erste — eine funktionierende Demo, die nie produktiv geht.

Welche Neustarts sich rechnen

Aus den drei Fragen ergibt sich ein klares Bild dafür, wann ein Zweitanlauf Sinn macht und wann nicht.

Ein Neustart lohnt sich, wenn:

• Der ursprüngliche Use-Case aus echtem Schmerz kam, aber der Pilot-Scope zu groß oder die Erfolgsdefinition zu wage war
• Die Daten in einigermaßen brauchbarem Zustand existieren (oder mit überschaubarem Aufwand aufgeräumt werden können)
• Eine konkrete Person/Rolle die produktive Lösung später übernimmt — nicht „das Team" abstrakt
• Sie bereit sind, den zweiten Pilot kleiner zu schneiden als den ersten und früher zu stoppen, wenn er nicht trägt

Ein Neustart lohnt sich nicht, wenn:

• Der Use-Case schon im ersten Versuch ein „etwas mit AI"-Use-Case war
• Die Datenarbeit größer ist als das eigentliche Projekt — dann ist Datenarbeit das eigentliche Projekt
• Niemand im Haus für die Produktivsetzung verantwortlich werden kann oder will
• Die Geschäftsführung den ersten Versuch nicht ehrlich aufgearbeitet hat — derselbe Fehler passiert dann wieder

Der ehrliche Mittelweg: Vertagen

Eine Antwort, die im Mittelstand erstaunlich selten ausgesprochen wird: das Thema bewusst aussetzen, sauber dokumentieren, was im ersten Versuch gelernt wurde, und in sechs oder zwölf Monaten neu ansehen. Das ist kein Versagen. Das ist eine valide Entscheidung — gerade wenn parallel andere Themen größeren Hebel hätten (E-Rechnungspflicht, Zeiterfassungspflicht, eine Excel-Datei, die zum Risiko wird).

Das empfehlen wir deutlich häufiger, als es Beratungen tun, die am Verkauf eines Folge-Pilots verdienen. Im Zweifel ist „vertagen mit klarem Wiedervorlage-Datum" der ehrlichere Vorschlag — gerade wenn parallel andere Themen größeren Hebel hätten.

So fängt ein zweiter Anlauf an, der trägt

Wenn Sie nach den drei Fragen zur Entscheidung „nochmal versuchen" gekommen sind: der zweite Pilot funktioniert anders als der erste. Drei strukturelle Unterschiede.

1. Engerer Scope. Ein einzelner Workflow, eine einzelne Datenquelle, eine einzelne messbare Veränderung. Nicht „AI für die Buchhaltung", sondern „Belegerfassung für die Eingangsrechnungen aus DATEV-Vorerfassung — drei Mitarbeiter sparen je vier Stunden pro Woche, gemessen über sechs Wochen."
2. Frühere Erfolgsdefinition. Bevor irgendwas gebaut wird: klare Metrik, klares Stop-Kriterium, klares Eskalationsdatum. So dass das Projekt nicht heimlich weiterläuft, wenn die Zahlen nicht stimmen.
3. Klarheit über die Produktivsetzung. Wer hostet, wer pflegt, wer trainiert nach, wenn das Modell driftet. Die Antworten existieren vor dem zweiten Pilot, nicht danach.

Das ist nicht spektakulär. Das ist die Disziplin, die fünfundneunzig Prozent der ersten Pilots nicht hatten.

1. 01

   2 Wochen

   Use-Case schärfen

   Schmerzpunkt aus dem Tagesgeschäft identifizieren, Erfolgskriterien schriftlich festlegen, Stop-Kriterium und Eskalationsdatum definieren — bevor irgendwas gebaut wird.

2. 02

   2–3 Wochen

   Daten & Systeme klären

   Datenqualität und -vollständigkeit prüfen, Systemzugänge (API, Export) sicherstellen, Verantwortlichen für die spätere Produktivsetzung benennen.

3. 03

   4–6 Wochen

   Pilot bauen & testen

   Lösung mit produktionsnahen Daten im echten Workflow testen, Metriken wöchentlich messen, Abweichungen dokumentieren und frühzeitig korrigieren.

4. 04

   1–2 Wochen

   Auswerten & entscheiden

   Ergebnisse gegen Erfolgskriterien halten, Produktivsetzung oder bewusstes Stoppen beschließen — kein Weiterlaufen ohne klare Entscheidung.

1. 01

   2 Wochen

   Use-Case schärfen

   Schmerzpunkt aus dem Tagesgeschäft identifizieren, Erfolgskriterien schriftlich festlegen, Stop-Kriterium und Eskalationsdatum definieren — bevor irgendwas gebaut wird.

2. 02

   2–3 Wochen

   Daten & Systeme klären

   Datenqualität und -vollständigkeit prüfen, Systemzugänge (API, Export) sicherstellen, Verantwortlichen für die spätere Produktivsetzung benennen.

3. 03

   4–6 Wochen

   Pilot bauen & testen

   Lösung mit produktionsnahen Daten im echten Workflow testen, Metriken wöchentlich messen, Abweichungen dokumentieren und frühzeitig korrigieren.

4. 04

   1–2 Wochen

   Auswerten & entscheiden

   Ergebnisse gegen Erfolgskriterien halten, Produktivsetzung oder bewusstes Stoppen beschließen — kein Weiterlaufen ohne klare Entscheidung.

Wenn Sie es einmal in Ruhe besprechen wollen

Wir betreuen regelmäßig Mittelstands-Inhaber, die genau in dieser Frage stecken. Im 30-Minuten-Sparring schauen wir uns Ihren ersten Pilot konkret an, gehen die drei Fragen mit Ihnen durch und sagen ehrlich, ob ein Neustart sich rechnet — oder ob Vertagen die bessere Antwort ist.

Kein Verkaufsgespräch. Wenn das Ergebnis „erstmal nicht" ist, ist das auch ein Ergebnis.

Mehr zu unserer AI-Beratung: /leistungen/ki-strategie-beratung Erste Reibung schon klar: Gespräch anfragen

---

Quellen: MIT NANDA, „State of AI in Business 2025"; Materna, „Warum 95 % der KI-Projekte scheitern und was der Mittelstand daraus lernen muss" (2024); Bitkom, „Künstliche Intelligenz in Deutschland 2025". EU-AI-Act-Fristen Stand Digital Omnibus Mai 2026 — Hochrisiko-Pflichten verschoben auf Dezember 2027 / August 2028.