Warum 80% der KI-Pilotprojekte sterben — und was dagegen hilft

Vor zwei Wochen saß ich in einem Gespräch mit dem Geschäftsführer eines deutschen Mittelständlers. 120 Mitarbeiter, B2B-Dienstleister, solide aufgestellt. Er hatte in den letzten achtzehn Monaten vier KI-Pilotprojekte gestartet. Vier. Davon laufen heute null. Nicht eins.

Das ist kein Einzelfall. Branchen-Erhebungen — McKinsey, BCG, Gartner — kommen aktuell auf eine Sterberate von KI-Pilotprojekten zwischen 70 und 85 Prozent. Das sind nicht nur die kleinen Experimente. Das sind auch sechsstellige Investitionen, die nach acht Monaten in einer Slack-Diskussion enden mit dem Satz: „Lassen wir das erstmal liegen."

Die Diagnose ist nicht, dass die KI schlecht war. Die Diagnose ist, dass das Pilotprojekt von Anfang an strukturell zum Scheitern angelegt war. Und das hat drei Gründe, die sich mit erschreckender Regelmäßigkeit wiederholen.

Grund 1: Kein Operations-Anschluss

Ein typischer KI-Pilot bei einem Mandanten sieht so aus: Der CTO oder der Innovations-Verantwortliche identifiziert einen Anwendungsfall — sagen wir, automatische Klassifikation eingehender Kundenanfragen. Ein externer Dienstleister oder ein internes Team baut einen Prototyp. Der funktioniert in einer Demo-Umgebung beeindruckend. Genauigkeit 92 Prozent. Vorstand applaudiert.

Sechs Monate später steht das Prototyp-Tool ungenutzt auf einem Server. Warum? Weil niemand geklärt hat, wie es in den tatsächlichen Eingangs-Workflow integriert wird. Wer hat den Zugriff? Wo werden die Klassifikations-Ergebnisse hingeschrieben? Was passiert mit den 8 Prozent Fehlklassifikationen — wer korrigiert die? Wie merkt das Tool, dass eine Korrektur stattgefunden hat?

Das sind keine technischen Fragen. Das sind Operations-Fragen. Und Operations ist genau das, worüber niemand spricht, wenn ein Pilot konzipiert wird. Der Fokus liegt auf der Modell-Qualität — und die Modell-Qualität ist heute selten das Problem. Das Problem ist die Anschlussfähigkeit an einen real laufenden Geschäftsprozess.

Was hilft: Bevor eine einzige Code-Zeile geschrieben wird, sollte ein Operations-Diagramm existieren, das zeigt, wo das Tool sitzt, wer es bedient, wer korrigiert, wer eskaliert. Nicht in PowerPoint — in einer Form, die nach der Implementierung als Runbook verwendet werden kann.

Grund 2: Kein Owner über mehrere Bereiche

Der zweite Grund ist organisatorisch. KI-Pilotprojekte werden typischerweise einem Bereich zugeordnet — IT, Marketing, Vertrieb. Das ist falsch. KI berührt fast immer Schnittstellen zwischen mindestens zwei Bereichen.

Beispiel aus einem Mandat: Ein KI-Tool sollte Vertriebsmitarbeitern Vorschläge für Cross-Selling generieren. Sitz im Vertrieb. Datenquelle: das CRM, das von Marketing verwaltet wird. Datenqualität: maßgeblich abhängig davon, wie Operations die Aufträge dokumentiert. Datenschutz: berührt die HR-Daten der Mitarbeiter, die mit den Kunden arbeiten.

Vier Bereiche, ein Tool. Verantwortlich war nominell der Vertriebsleiter. Realer Einfluss auf Erfolg: 25 Prozent. Die anderen 75 Prozent hingen an Bereichen, in denen die Vertriebsleiterin keine Weisungsbefugnis hatte. Ergebnis nach neun Monaten: Tool tot, weil das CRM nicht so gepflegt wurde, wie der Pilot es brauchte, und niemand sich verantwortlich fühlte, das zu ändern.

Was hilft: Eine Eskalationsebene über den beteiligten Bereichen. In kleineren Mittelständlern ist das oft die Geschäftsführung selbst. In größeren ein konkret benannter Operations- oder Transformations-Verantwortlicher mit echter Durchgriffs-Befugnis. Nicht „der Innovationsmanager" — sondern jemand, der einer Bereichsleitung sagen kann, dass ihre CRM-Pflege ab Montag anders aussieht.

Grund 3: Keine Compliance-Klärung vor dem Bau

Der dritte Grund ist der teuerste. Ein KI-Pilot wird gebaut, läuft acht Wochen erfolgreich — und stirbt dann beim Compliance-Check. Häufige Auslöser: DSGVO-Bewertung kommt zu spät zu dem Schluss, dass die genutzten Trainingsdaten so nicht hätten verwendet werden dürfen. Oder der Datenschutzbeauftragte verlangt eine Auftragsverarbeitungsvereinbarung mit dem Modellanbieter, die so nicht existiert. Oder seit August 2025 EU AI Act: Der Anwendungsfall wird als Hochrisiko klassifiziert, was eine Konformitätsbewertung erfordert, die niemand eingeplant hat.

Diese Probleme sind alle vermeidbar — wenn die Klärung am Anfang stattfindet, nicht am Ende. In der Praxis findet sie typischerweise statt, nachdem der Prototyp läuft, weil der Datenschutzbeauftragte erst dann von dem Projekt erfährt. Dann ist es entweder teuer (Nachbau mit anderen Datenquellen) oder unmöglich (Architektur-Annahmen waren falsch).

Was hilft: Eine sehr einfache Praxis — der Datenschutzbeauftragte und der EU-AI-Act-Verantwortliche bekommen das Konzept zur Stellungnahme, bevor die erste Code-Zeile entsteht. Das kostet ein bis zwei Wochen am Anfang. Es spart oft drei bis sechs Monate am Ende.

Wie wir das in der SEODACH Solutions GmbH lösen

Wir betreiben unsere eigene GmbH durchgängig KI-unterstützt. Sieben Bereiche, jeder mit einem digitalen Bereichsleiter, der bis zu definierten Budget-Grenzen selbst entscheidet, eskaliert, wenn die Grenzen überschritten werden, und seine Entscheidungen vollständig protokolliert. Das System läuft nicht, weil wir besonders gute Modelle einsetzen — die Modelle sind dieselben, die jeder einsetzt. Es läuft, weil drei Dinge von Anfang an geklärt waren.

Erstens: jede Agent-Entscheidung hat einen Operations-Anschluss. Wenn der digitale Marketing-Leiter eine Outreach-Sequenz startet, ist klar, wo die Antworten landen, wer eskaliert wird, wenn ein potenzieller Kunde direkt antwortet, und wer den abschließenden Termin bucht. Das ist nicht im Code festgelegt — es ist im Bereichs-Doktrin festgelegt, einem strukturierten Dokument pro Bereich, das die Befugnisse, Verbote und Eskalationspfade beschreibt.

Zweitens: über allen Bereichen sitzt die Geschäftsführung mit einer 30-Sekunden-Sicht pro Tag. Ein einziges Dashboard, das aktive Krisen, pausierte Agenten, anstehende Eskalationen und finanzielle Limits zeigt. Wenn ein Bereich gegen eine andere Bereichsentscheidung läuft, sehe ich das, bevor es zwischen den Agenten zur Eskalation kommt.

Drittens: jede Agent-Aktion hat ein Audit-Log. Wer hat was wann entschieden, mit welchem Modell, auf welcher Wissensgrundlage, mit welchem Budget. Das ist nicht für Compliance gebaut — es ist für die Geschäftsführung gebaut, damit Vertrauen in das System entsteht. Compliance ist ein angenehmer Nebeneffekt.

Das Ergebnis ist, dass wir keine „Piloten" mehr fahren. Wir bauen Bereiche. Jeder neue Bereich ist ein neuer Bereichsleiter, der nach demselben Muster integriert wird. Sterberate: null, weil es keine isolierten Prototypen mehr gibt, die isoliert sterben können.

Was Sie konkret tun können, bevor Sie den nächsten Piloten starten

Drei Fragen, die in jeder Projektidee vor dem Bau beantwortet sein sollten. Wenn auch nur eine offen ist, ist das Risiko, dass das Projekt zu den 80 Prozent gehört, hoch.

Frage 1: Welcher Workflow steht nach der Ausgabe? Wenn die KI ein Ergebnis liefert — wer übernimmt es, in welchem System, mit welcher nächsten Aktion? Nicht „das Marketing-Team prüft das" — sondern „Frau Müller bekommt eine Aufgabe in HubSpot mit folgenden Pflichtfeldern". Wenn dieser Workflow nicht beschrieben werden kann, bauen Sie kein Operations-fähiges Tool, sondern eine Demo.

Frage 2: Wer hat Weisungsbefugnis über alle berührten Bereiche? Wenn Ihre Antwort „der Projektleiter berichtet an mich, aber die Bereiche entscheiden selbst" lautet, haben Sie keine Owner-Struktur. Sie haben ein Abstimmungs-Konstrukt, das in der Praxis zu Stillstand führt.

Frage 3: Was sagt Ihr Datenschutzbeauftragter zu der Architektur? Nicht „wir holen das noch ein". Sondern ein konkreter Termin in den nächsten zwei Wochen mit dem Architektur-Entwurf auf dem Tisch.

Wenn Sie diese drei Fragen klar beantworten können, ist die Wahrscheinlichkeit, dass Ihr Pilot die nächsten neun Monate überlebt, um ein Vielfaches höher. Wenn nicht — verschieben Sie den Bau um vier Wochen und klären Sie es. Das ist die billigste Phase des Projekts, in der Sie etwas ändern können.

Sie planen ein KI-Projekt und wollen vor dem Bau prüfen, ob die Architektur trägt?Erstgespräch buchen — 30 Minuten, kostenfrei. Wir gehen Ihre drei Fragen durch und Sie wissen am Ende, ob Sie weiterbauen oder nochmal nachschärfen.