Warum KI-Projekte scheitern
Die Szene ist inzwischen fast Standard: Ein Team zeigt eine beeindruckende KI-Demo, alle sind begeistert, und ein paar Wochen später zeigt sich: Im echten Workflow bleibt der Nutzen hinter der Demo zurück. Das Ergebnis ist selten ein Beweis gegen KI. Meist ist es ein Hinweis darauf, dass wir KI an der falschen Stelle einsetzen, mit den falschen Erwartungen, oder ohne das Umfeld zu bauen, das sie braucht.
Der schnellste Weg, KI-Projekte scheitern zu lassen, ist, sie wie ein reines Technologie-Projekt zu behandeln. Wer so startet, landet schnell in vertrauten Mustern: Das Modell wird optimiert, bevor man Ziele klärt. Man feilt an Prompts, obwohl Inputs und Schnittstellen noch schwanken. Und man rollt Funktionen aus, bevor man Betrieb, Qualitätssicherung und Verantwortung geregelt hat. Das ist nicht „zu wenig KI", sondern „KI am falschen Hebel".
Damit das nicht passiert, hilft ein kurzer Fit-Check. Nicht als Bürokratie, sondern als Abkürzung: weg von Tool-Diskussionen, hin zu Wirkung.
Frage 1: Was soll messbar besser werden?
Wenn das Ziel nicht messbar ist, wird jede Demo zum Erfolg und jede Produktion zum Streit. „Wir wollen effizienter werden" klingt gut, ist aber kein Steuerungsinstrument. Besser ist eine klare Metrik, die sich im Alltag beobachten lässt, zum Beispiel Durchlaufzeit, Fehlerquote, Erstlösungsrate, Bearbeitungskosten pro Fall oder Kundenzufriedenheit. Ebenso wichtig ist eine Baseline. Ohne Ausgangswert kann man Verbesserung nur behaupten, nicht belegen.
Wenn diese Frage aktuell nicht sauber beantwortet werden kann, ist das kein Stopp-Signal für KI, sondern der richtige Startpunkt. Ziel und Baseline zu definieren ist oft der schnellste Fortschritt im ganzen Vorhaben, weil es Scope, Datenbedarf und Evaluationslogik sofort schärft.
Frage 2: Ist die Aufgabe regelbasiert oder variantenreich und unstrukturiert?
Viele „KI-Use-Cases" sind in Wahrheit Automatisierungs-Use-Cases. Wenn ein Problem deterministisch regelbar ist, gewinnt man häufig schneller mit Workflow-Logik, Validierungen, klaren Formularen, Routing und einfachen Regeln. Das ist stabil, gut testbar und gut erklärbar.
KI spielt ihre Stärken dort aus, wo Menschen heute viel Zeit mit unstrukturierten Informationen verbringen. Dazu gehören E-Mails, Tickets, Dokumente, Gesprächsnotizen, Richtlinien, Freitextfelder und generell Situationen mit hoher Varianz. In solchen Bereichen kann KI zusammenfassen, klassifizieren, extrahieren, Entwürfe erzeugen oder Wissen besser auffindbar machen. Der entscheidende Punkt ist nicht „KI ja oder nein", sondern die Zuordnung von Problemtyp zu Werkzeugtyp.
Frage 3: Sind Prozess und Inputs stabil genug?
KI ist kein Ersatz für Prozessklarheit. Wenn niemand genau sagen kann, wann ein Vorgang beginnt und endet, wer entscheidet, wie Ausnahmen behandelt werden oder welche Mindestinformationen nötig sind, dann produziert man mit KI vor allem mehr Variation. Genau das fühlt sich später an wie „KI ist unzuverlässig", obwohl das eigentliche Problem Instabilität im System ist.
Wenn die Inputs schwanken, helfen oft unspektakuläre Maßnahmen: Pflichtfelder dort, wo sie wirklich nötig sind; eine klare Taxonomie; Templates; definierte Übergaben; eine einfache „Definition of Done". Das klingt nach Grundlagenarbeit, ist aber in der Praxis oft die Voraussetzung dafür, dass KI nicht nur Inhalte generiert, sondern messbar Arbeit reduziert.
Frage 4: Wie teuer sind Fehler, und wie hoch ist die Nachweispflicht?
Generative Modelle können überzeugend klingen und trotzdem falsch liegen. Das ist kein Randphänomen, sondern ein strukturelles Risiko, das man gestalten muss. In Low-Stakes-Kontexten ist das oft beherrschbar, wenn man Stichproben, Feedback und klare Nutzungsgrenzen etabliert. In High-Stakes-Kontexten braucht es mehr: definierte Review-Rollen, Freigaben, Protokollierung, Tests vor dem Rollout und klare Regeln, wann ein Mensch entscheiden muss.
Hier lohnt auch ein Blick auf den EU AI Act. Er staffelt Pflichten nicht pauschal, sondern nach Einsatzzweck und Risikokategorie. Für viele Unternehmensanwendungen bedeutet das vor allem Transparenzpflichten, zum Beispiel wenn Menschen wissen müssen, dass sie mit einem KI-System interagieren. In sensibleren Bereichen wie Personalentscheidungen, Kreditvergabe oder Bildungszugang kommen weitergehende Anforderungen hinzu: Dokumentation, menschliche Aufsicht, Protokollierung. Wichtig dabei ist, diese Einordnung nicht auf den Rollout zu vertagen. Wer früh weiß, welcher Kategorie ein System angehört, kann Nachweispflichten von Anfang an einplanen, statt sie nachträglich aufzurüsten.
Unabhängig davon gilt als gutes Prinzip: Je folgenreicher eine Entscheidung, die KI vorbereitet oder trifft, desto mehr sollte das System nachvollziehbar arbeiten. Das kann bedeuten, dass Antworten auf explizite Quellen verweisen, dass Unsicherheit sichtbar gemacht und eskaliert wird statt geraten, und dass relevante Systemaktionen protokolliert werden.
Frage 5: Was darf das System tun - und was explizit nicht?
Sobald ein Modell nicht nur Text erzeugt, sondern aktiv handelt und Daten bearbeitet, Tickets anlegt, E-Mails auslöst oder Prozesse anstößt, verändert sich die Risikolage grundlegend. Die entscheidende Designfrage ist dann nicht mehr nur „Was kann das System?", sondern „Was soll es dürfen?"
Das ist keine technische Detailfrage, sondern eine Governance-Entscheidung. In der Praxis bedeutet das klare Grenzen für erlaubte Aktionen, Freigabe-Logik für kritische Schritte, Nachvollziehbarkeit aller Systemaktionen und definierte Eskalationswege, wenn das System an seine Grenzen stößt. Für Systeme, die in regulierten Bereichen eingesetzt werden, schreibt der EU AI Act genau diese Art von Kontrollen vor. Wer sie von Anfang an einplant, baut robuster und vermeidet teure Nachrüstungen.
Frage 6: Können wir das betreiben?
Hier scheitern viele Vorhaben, die in der Demo stark waren. Betrieb heißt nicht nur „läuft in der Cloud", sondern Qualitätsmessung, Monitoring, Feedback-Loop, Incident-Prozess und Ownership. Wer ist verantwortlich, wenn das System falsche Prioritäten setzt? Wie wird Nutzerfeedback in Verbesserungen übersetzt? Welche Fehlertypen tracken wir, und wie reagieren wir, bevor das Vertrauen kippt?
Dazu kommt Enablement. Ein KI-System verändert Arbeit. Wenn Menschen nicht wissen, wie sie Ergebnisse prüfen sollen, wann sie eskalieren müssen und was „gute Nutzung" bedeutet, entstehen entweder blinde Übernahme, komplette Ablehnung, oder Schatten-KI. All dies verhindert wert.
Weiter gehört zum Betrieb ein Mechanismus zur kontinuierlichen Überwachung: Verändert sich die Qualität der Ausgaben über Zeit? Driften die Inputs? Gibt es neue Risiken, die beim initialen Design noch nicht absehbar waren? Der EU AI Act fordert genau das für Hochrisiko-Systeme explizit - aber es ist schlicht gutes Engineering für jeden ernsthaften KI-Einsatz.
Ein kurzes Beispiel aus dem Alltag: Ticket- und E-Mail-Flut
Nehmen wir Support-Tickets. Häufig lautet der Wunsch: „Wir brauchen KI, die Tickets beantwortet." Der Fit-Check lenkt die Reihenfolge. Zuerst wird das Ziel konkret, etwa kürzere Durchlaufzeit und höhere Erstlösungsrate. Dann trennt man Regelbares von Variablen. Routing, Priorisierung und Pflichtinformationen sind oft regelbar. Inhalte und Formulierungen sind variantenreich.
In der Praxis bringt das eine sinnvolle Kette: Erst stabilisiert man Taxonomie, Pflichtfelder und Wissensbasis, inklusive Ownership und Aktualität. Danach setzt man KI dort ein, wo sie tatsächlich Arbeit abnimmt: Ticket-Klassifikation, Zusammenfassungen, Antwortentwürfe, Vorschläge für Knowledge-Artikel. Je nach Risiko bleibt der Mensch in der Freigabe. Das Ergebnis ist keine „Support-Automatisierung um jeden Preis", sondern weniger Such- und Schreibarbeit bei klarer Verantwortung und einem Betriebsmodell, das auch regulatorischen Anforderungen standhält.
Fazit
Der Punkt ist nicht, weniger KI zu nutzen. Der Punkt ist, weniger falsch platzierte KI zu bauen. Mit sechs Fragen kommt man dorthin, wo die Diskussion hingehört: auf Wirkung, Passung, Risiko und Betrieb. Und genau dann wird KI nicht zum Selbstzweck und auch nicht zur Compliance-Last, sondern zu einem Werkzeug, das reale Probleme löst und dabei rechtlich und organisatorisch tragfähig ist.
