1. Werkzeug vor Problem
Der Pilot startet mit einer Technologieentscheidung, nicht mit einem klar beschriebenen Engpass. Dann wird getestet, was das Werkzeug kann, statt zu messen, ob ein relevantes Problem besser gelöst wird.
Viele KI-Initiativen scheitern nicht sichtbar, sondern bleiben ohne messbaren Ergebnisbeitrag — Projekte, die laufen, Aufmerksamkeit binden und trotzdem nichts ändern.
„95 Prozent der KI-Projekte scheitern“ ist ein eingängiger Satz und entstammt zuletzt dem MIT-NANDA-Bericht von 2025. Analytisch bleibt die Zahl grob: die Methodik ist umstritten (Mollick 2025), und der häufigere Fall ist ohnehin nicht der sichtbare Crash, sondern das stille Verpuffen — ein Pilot, der funktioniert, aber keinen signifikanten Effekt auf Ergebnis, Produktivität, Qualität oder Geschwindigkeit hat.
Die präzisere Frage lautet deshalb: Warum entstehen trotz funktionierender Technologie keine belastbaren Resultate? Meine Antwort darauf ist eine einfache Taxonomie aus vier Fehlern im Projektaufbau.
Der Pilot startet mit einer Technologieentscheidung, nicht mit einem klar beschriebenen Engpass. Dann wird getestet, was das Werkzeug kann, statt zu messen, ob ein relevantes Problem besser gelöst wird.
KI-Anwendungsfälle wirken plausibel, aber niemand definiert vorher, woran der Umsetzungserfolg wirklich erkennbar wäre. Dann endet der Pilot mit einem Bauchgefühl, nicht mit einer Entscheidung.
Der Prototyp beeindruckt, aber niemand hat geklärt, wer ihn betreibt, wartet, finanziert und verantwortet, wenn die Demo vorbei ist. Dann läuft er weiter, ohne dass ihn jemand stoppt, skaliert oder verantwortet — technisch funktionsfähig, organisatorisch verwaist.
Der Anwendungsfall ist von Grund auf unprüfbar: zu offen, zu politisch oder zu vage, als dass sich Ergebnisqualität überhaupt definieren ließe. Anders als bei Fehler 2 hilft hier auch die sauberste vorab definierte Metrik nicht, weil das Problem im Aufgabentyp liegt. KI erzeugt Ergebnisse, aber niemand hat einen belastbaren Maßstab dafür.
Typischer Satz: „Wir pilotieren GenAI parallel in mehreren Bereichen und schauen, wo es am besten trägt.“ Was fehlt, ist ein präziser Geschäftsengpass mit Priorität und Zielbild.
Typischer Satz: „Der Fachbereich ist begeistert.“ Was fehlt, ist eine vorher definierte Metrik für Qualität, Durchlaufzeit, Kosten oder Ergebnisbeitrag.
Typischer Satz: „Das bauen wir im Pilot einmal schnell zusammen.“ Was fehlt, ist die Antwort auf die Frage, wer nach dem Pilot Verantwortung übernimmt.
Typischer Satz: „Die KI soll strategische Empfehlungen geben.“ Bei strategischen Empfehlungsaufgaben fehlt oft ein prüfbarer Maßstab. Eine gute Strategie lässt sich nicht automatisch kompilieren, testen oder gegen eine eindeutige Zielantwort prüfen. Selbst ein sorgfältig geplanter Projektaufbau kann für solche Aufgaben keinen objektiven Prüfmaßstab liefern.
Ein aktueller Extremfall aus der mathematischen Forschung zeigt, warum Prüfbarkeit für KI so entscheidend ist. Google DeepMind AlphaProof Nexus löste laut einem im Mai 2026 veröffentlichten Paper neun von 353 formalisierten offenen Erdős-Problemen. Das System nutzt LLM-Agenten für Beweisvorschläge und Lean als formalen Verifier. Lean ist eine formale Sprache und ein Proof Assistant: Definitionen, Annahmen und Beweisschritte werden so formuliert, dass ein Computer sie streng prüfen kann.
Die eigentliche Leistung lag nicht darin, dass ein Sprachmodell frei einen überzeugenden Beweistext schrieb. Jeder Vorschlag wurde durch den Lean-Compiler geprüft. Wenn ein Schritt logisch nicht passte, wurde der Beweis nicht akzeptiert. Die Fehlermeldung ging zurück an den Agenten, der den Beweis änderte, zerlegte oder neu versuchte. Ein Ergebnis zählte erst, wenn der formale Beweis ohne offene Lücke akzeptiert wurde.
Für Unternehmen ist daran nicht die Mathematik der relevante Punkt, sondern der Arbeitsprozess. KI wird dort verlässlich, wo sie in einen Prüfkreislauf gezwungen wird: Vorschlag, Kontrolle, Fehlerfeedback, Korrektur. In Software übernehmen Compiler, Tests und Typprüfung diese Rolle. In der Strategiearbeit gibt es keinen Lean-Compiler. Deshalb ist ein Pilot mit dem Auftrag „Strategie entwickeln“ schlecht geschnitten. Besser ist ein engerer Auftrag: Annahmen sichtbar machen, Optionen strukturieren, Gegenargumente formulieren, Zahlen konsolidieren und Entscheidungskriterien prüfen. Die Entscheidung bleibt Managementarbeit.
Bessere Piloten beginnen mit einem klar beschriebenen Problem, einem prüfbaren Aufgabentyp und einem vorab definierten Erfolgsmaß. Der Pilot wird als Vorstufe eines späteren Betriebsmodells behandelt, nicht als isolierte Innovation. Auch offene Managementfragen müssen dafür in überprüfbare Teilaufgaben zerlegt werden.
Ein klar benannter Engpass, ein priorisierter Anwendungsfall und ein messbares Ziel. Nicht fünf Ideen gleichzeitig und keine offene Werkzeugsuche ohne Priorisierung.
Klare Prüfschritte, menschliche Kontrolle und sichtbare Metriken. Kein Pilot, der nur auf Präsentationen gut aussieht.
Eine Entscheidung: einstellen, nachschärfen oder in den Betrieb überführen. Nicht „weiter beobachten“, weil niemand die Verantwortung übernehmen will.
Keine allgemeine Empfehlung beauftragen, sondern die Vorarbeit trennen: Annahmenliste, Evidenzprüfung, Szenarien, Gegenargumente, Entscheidungskriterien. KI unterstützt die Prüfung. Sie ersetzt nicht das Urteil.
Die entscheidende Führungsfrage lautet nicht, ob der erste KI-Pilot perfekt wird. Relevant ist, ob das Unternehmen schnell erkennt, an welchem der vier Punkte im Projektaufbau es hängt. Wenn das klar ist, wird aus einem „gescheiterten“ Pilot oft ein sauber diagnostizierter erster Lernzyklus.
Genau deshalb ist die Qualität der ersten Pilot-Entscheidung so wichtig: Sie prägt, ob KI intern als teure Kuriosität eingeordnet wird oder als Werkzeug, das unter klaren Bedingungen Kosten senkt, Durchlaufzeiten verkürzt oder Qualität verbessert.