KI-Engineering · Tag 1: Warum KI-Projekte scheitern

Willkommen zu Tag 1 unserer Serie KI-Engineering. Über die nächsten Folgen bauen wir Schritt für Schritt auf, wie man KI-Features nicht nur demonstriert, sondern in den produktiven Betrieb bringt – belastbar, messbar und bezahlbar. Bevor wir bauen, klären wir aber die unbequeme Frage: Warum scheitern so viele KI-Projekte? Denn wer die Fallen kennt, baut von Anfang an anders.

Warum die meisten KI-Projekte nie in Produktion gehen

Ein Prototyp, der im Meeting begeistert, ist schnell gebaut. Ein KI-Feature, das seit Monaten zuverlässig echten Nutzern hilft, ist etwas völlig anderes. Zwischen „funktioniert in der Demo" und „funktioniert im Betrieb" liegt die eigentliche Arbeit – und genau dort bleiben die meisten Vorhaben stecken. Nicht, weil das Modell zu schwach wäre, sondern weil um das Modell herum das Engineering fehlt.

Die gute Nachricht: Fast alle Gründe fürs Scheitern sind bekannt und vermeidbar. Es sind selten exotische Forschungsprobleme, sondern immer wieder dieselben handwerklichen Lücken. Gehen wir sie durch.

Die häufigsten Gründe, warum KI-Projekte scheitern

1. Kein klar umrissenes Problem

„Wir wollen etwas mit KI machen" ist kein Ziel, sondern ein Wunsch. Ohne ein konkretes, messbares Problem – „Support-Anfragen der Kategorie X automatisch beantworten und dabei die Lösungsquote halten" – gibt es keinen Maßstab für Erfolg. Projekte ohne klaren Use-Case verlaufen im Sand, weil niemand sagen kann, wann sie fertig oder gut genug sind. (Wie du den richtigen Use-Case findest, ist Thema von Tag 2 dieser Serie.)

2. Schlechte oder fehlende Daten

KI ist nur so gut wie die Informationen, auf die sie zugreift. Ein Chatbot, der auf veraltete oder widersprüchliche Inhalte zugreift, erfindet selbstbewusst Unsinn. Viele Projekte unterschätzen, wie viel Arbeit in sauberen, aktuellen und strukturierten Wissensquellen steckt – und scheitern nicht am Modell, sondern an der Datengrundlage.

3. Der Prototyp wird mit Produktion verwechselt

Ein Notebook-Skript, das an drei Beispielen funktioniert, ist kein Produkt. Produktion heißt: Fehlerbehandlung, Timeouts, Wiederholungen, Rate-Limits, Logging, Monitoring, Versionierung. Wer den Sprung von „läuft bei mir" auf „läuft für alle, jederzeit" nicht plant, erlebt ihn als bösen Sturz.

4. Niemand misst die Qualität

„Sieht gut aus" ist keine Qualitätssicherung. Ohne systematische Auswertung (Evals) weißt du nicht, ob eine Änderung am Prompt oder Modell die Antworten besser oder schlechter macht. Teams, die nur nach Gefühl optimieren, drehen im Kreis – und merken Regressionen erst, wenn Kunden sich beschweren. (Evals bekommen eine eigene Folge.)

5. Kosten und Latenz werden unterschätzt

In der Demo mit einer Handvoll Anfragen ist alles günstig und schnell. Im Betrieb mit tausenden Anfragen summieren sich Token-Kosten – und lange Antwortzeiten kosten Nutzer und Conversions. Wer Kosten und Latenz erst nach dem Launch anschaut, steht schnell vor einer Rechnung, die den Business Case kippt.

6. Keine Guardrails und keine Sicherheit

Eine KI, die auf Nutzereingaben reagiert, ist eine neue Angriffsfläche: Prompt-Injection, das Ausplaudern interner Daten, Missbrauch für fremde Zwecke. Ohne Schutzmechanismen wird aus dem hilfreichen Feature ein Risiko – rechtlich (Datenschutz) wie fürs Vertrauen.

7. Der Betrieb wird vergessen

KI-Features sind keine Software, die man einmal ausliefert und vergisst. Modelle ändern sich, Daten veralten, Anbieter passen Preise und Verhalten an. Ohne Observability, Fallbacks und einen Plan für Wartung verrottet ein KI-Feature leise – bis es eines Tages falsch antwortet und keiner weiß, warum.

8. Erwartungsmanagement gegen den Hype

Zwischen „KI ersetzt alles" und „KI ist nur Spielerei" liegt die Realität. Überzogene Erwartungen führen zu Enttäuschung, wenn das Feature nicht zaubert; zu geringe Erwartungen verhindern sinnvolle Investitionen. Beides bringt Projekte zu Fall. Ehrliche Kommunikation, was KI heute leisten kann und was nicht, ist Teil des Engineerings.

Was gute KI-Features stattdessen ausmacht

Dreht man die Fehlerliste um, entsteht ein überraschend nüchternes Bild davon, was gute KI-Features gemeinsam haben:

• Ein klar umrissenes Problem mit einem messbaren Erfolgskriterium – nicht „KI", sondern „diese Aufgabe, dieser Maßstab".
• Eine saubere Datengrundlage, die aktuell gehalten wird – oft der größte Hebel für Qualität.
• Produktionsdenken von Tag 1: Fehlerfälle, Wiederholungen und Grenzen sind eingeplant, nicht nachgereicht.
• Messbarkeit: Es gibt Evals, mit denen jede Änderung objektiv bewertet wird.
• Kostenbewusstsein: Token-Verbrauch und Latenz sind bekannt und im Griff.
• Sicherheit und Guardrails: Missbrauch, Datenabfluss und rechtliche Risiken sind bedacht.
• Betreibbarkeit: Monitoring, Fallbacks und ein Wartungsplan sorgen dafür, dass das Feature auch in einem Jahr noch gut ist.

Auffällig: Kein einziger dieser Punkte handelt vom „besten Modell". Das Modell ist eine Zutat. Ob ein KI-Feature erfolgreich wird, entscheidet das Engineering drumherum – und genau darum geht es in dieser Serie.

Ein Beispiel: dasselbe Feature, zwei Ausgänge

Stell dir zwei Unternehmen vor, die dasselbe wollen: einen KI-Assistenten, der Kundenanfragen im Shop beantwortet. Unternehmen A startet mit „Bau uns einen Chatbot mit KI". Das Team greift zum stärksten Modell, verkabelt es mit der Website, und in der Demo beantwortet es Fragen erstaunlich gut. Drei Monate später ist das Projekt tot: Der Bot erfand Versandkosten, die es nicht gab, empfahl vergriffene Produkte, und niemand konnte messen, wie oft er danebenlag. Die Kosten liefen aus dem Ruder, weil jede Anfrage das teuerste Modell mit dem gesamten Produktkatalog fütterte.

Unternehmen B beginnt kleiner: „Beantworte Fragen zu Versand und Rückgabe auf Basis unserer offiziellen Hilfe-Seiten – und sag ehrlich, wenn du etwas nicht weißt." Das Team pflegt die Hilfe-Inhalte, baut eine Handvoll Testfragen mit erwarteten Antworten, misst damit jede Änderung, setzt ein günstigeres Modell ein und begrenzt, worauf der Assistent überhaupt zugreifen darf. Das Feature ist unspektakulärer – und läuft seit Monaten, senkt die Support-Last messbar und lässt sich Stück für Stück erweitern. Der Unterschied war nie das Modell. Es war das Engineering drumherum.

Warum Disziplin bei KI wichtiger ist als bei klassischer Software

Klassische Software ist deterministisch: gleiche Eingabe, gleiches Ergebnis. Bei KI ist das nicht garantiert – dieselbe Frage kann leicht unterschiedliche Antworten erzeugen, und ein Anbieter-Update kann das Verhalten über Nacht verschieben. Was in klassischer Software die Ausnahme ist, wird bei KI zum Normalfall: Du musst mit Unsicherheit umgehen, statt sie wegzudefinieren.

Deshalb sind die vermeintlich „langweiligen" Engineering-Praktiken – Tests, Monitoring, klare Grenzen, Fallbacks – bei KI nicht weniger, sondern mehr wert. Sie sind der Unterschied zwischen einem Feature, dem man vertrauen kann, und einer Blackbox, die manchmal richtig liegt. Wer KI wie etwas behandelt, das man einmal baut und dann sich selbst überlässt, hat schon verloren. Wer sie wie einen Motor behandelt, den man überwacht, wartet und nachjustiert, gewinnt.

Wie du ein KI-Projekt richtig startest

Der pragmatische Weg ist erstaunlich unspektakulär. Beginne mit einem klar umrissenen Anwendungsfall, bei dem ein Fehler nicht katastrophal ist und der Nutzen offensichtlich. Definiere vorab, woran du Erfolg misst. Bau die kleinstmögliche Version, die echten Nutzern hilft – aber bau sie von Anfang an produktionstauglich: mit Logging, Fehlerbehandlung und einer Handvoll Evals. Miss, lerne, iteriere. Erst wenn dieser eine Fall trägt, skalierst du auf den nächsten.

Dieser Ansatz klingt langsamer, ist aber schneller – weil er die teuren Sackgassen vermeidet, in denen die gescheiterten Projekte enden. Und er ist genau der Ansatz, den wir in den nächsten Folgen konkret durcharbeiten: vom richtigen Use-Case über wissensbasierte Antworten (RAG) und Agents bis zu Evals, Kosten, Sicherheit und Betrieb.

Konkret heißt das für die ersten Wochen: Sprich mit den Menschen, die das Problem heute lösen – Support, Vertrieb, Betrieb – und lass dir echte Fälle zeigen, nicht die idealisierten. Sammle 20 bis 30 typische Anfragen samt der Antworten, die du dir wünschst; das ist dein erstes Testset. Bau dann eine bewusst enge erste Version und lass sie gegen dieses Testset laufen, statt sie nur „auszuprobieren". Zeig das Ergebnis denselben Menschen und stell die entscheidende Frage: Würdet ihr dem im Kundenkontakt vertrauen? Diese Rückkopplung ist mehr wert als jede Diskussion über das beste Modell – sie erdet das Projekt in der Realität, bevor Budget in die Breite fließt. Und sie liefert dir nebenbei genau die Grundlage, auf der die nächsten Folgen dieser Serie aufbauen.

Kurze Checkliste vor dem Start

Bevor du Zeit und Budget in ein KI-Feature steckst, beantworte ehrlich:

• Kannst du das Problem in einem Satz benennen – inklusive dem, woran du Erfolg misst?
• Gibt es eine verlässliche, aktuelle Datengrundlage – oder musst du sie erst schaffen?
• Was passiert im schlimmsten Fall, wenn die KI falsch antwortet? Ist das tolerierbar?
• Wie sieht die kleinste Version aus, die echten Nutzern schon hilft?
• Wer betreibt und pflegt das Feature nach dem Launch – und mit welchem Budget?

Wenn du bei mehr als einer Frage ins Stocken gerätst, ist das kein Grund aufzugeben – aber ein klares Zeichen, dass die Vorarbeit wichtiger ist als der schnelle Prototyp. Genau diese Vorarbeit entscheidet am Ende zwischen einem teuren Experiment und einem Feature, das trägt.

Fazit

KI-Projekte scheitern selten an der KI. Sie scheitern an fehlenden Problemen, schlechten Daten, verwechselten Prototypen, fehlender Messung, unterschätzten Kosten, fehlenden Guardrails und vergessenem Betrieb. Wer diese sieben Fallen kennt, baut vom ersten Tag an anders – und landet dort, wo die meisten nie hinkommen: bei einem KI-Feature, das im echten Betrieb Wert schafft.

In der nächsten Folge dieser Serie klären wir die wichtigste Frage überhaupt: Wo lohnt sich KI wirklich – und wo nicht? Alle Folgen findest du in der Serien-Übersicht KI-Engineering.

Du willst KI nicht experimentieren, sondern in den Betrieb bringen? Sieh dir unsere KI-Engineering-Leistungen an → oder schilder uns kurz deinen Anwendungsfall – wir sagen dir ehrlich, ob und wie sich KI dafür lohnt.