Warum KI-Projekte scheitern und wie man das vermeidet

In den letzten zwei Jahren wiederholte sich das Muster regelmäßig: Ein Unternehmen investiert mehrere Monate und Budget in ein KI-Projekt, startet einen Piloten, und nach acht Wochen setzt Stagnation ein. Das Modell „funktioniert“, aber die Geschäftsergebnisse verbessern sich nicht. Das Team weiß nicht, was zu verbessern ist. Das Projekt landet in der Schublade.

Die Ursache lag fast nie am Modell. Es war der Prozess drumherum.

KI-Projekte, die mit „Lasst uns mal schauen, was man mit KI machen kann“ beginnen, haben ein inhärentes Problem: Es gibt kein Erfolgskriterium. Ohne dieses sieht jede Modelldemonstration gut aus, und jeder Fehler ist „nachzubessern“.

Ein messbares Ziel ist ein konkreter Satz: „Die Bearbeitungszeit einer Anfrage sinkt von 8 auf 3 Minuten in 80 % der Fälle“ oder „Der Klassifikator leitet 70 % der Anfragen ohne menschliches Eingreifen in die richtige Warteschlange.“ Ein solcher Satz legt auch fest, wann das Projekt bereit ist, vom Piloten in die Produktion überzugehen.

Praktische Konsequenz: Definieren Sie das Ziel vor der Modellauswahl, nicht danach. Das Modell wird auf das Ziel abgestimmt, nicht umgekehrt. Wenn Sie das Ziel nicht in einem Satz mit einer Zahl und einem Zeitrahmen formulieren können, ist das Projekt zu unbestimmt, um zu starten. Ein Tool zur vorläufigen Bewertung der Prozessbereitschaft ist der Automatisierungsfinder.

Ein Modell ist nur so gut wie die Daten, mit denen es arbeitet. Das häufigste Szenario: Ein Unternehmen bereitet eine Wissensdatenbank mit Dokumentation vor, die seit einem Jahr nicht aktualisiert wurde. Oder es trainiert das Modell mit historischen Daten, die keine Ausnahmefälle enthalten, da diese manuell außerhalb des Systems bearbeitet wurden.

Drei Symptome schlechter Eingabedaten:

• Das Modell antwortet gut auf Fragen aus der Dokumentation, aber schlecht auf Fragen, die Kunden tatsächlich stellen.
• Die Ergebnisse im Testdatensatz sind gut, aber bei produktiven Daten treten regelmäßig Halluzinationen oder falsche Klassifizierungen auf.
• Das Modell verwendet Terminologie, die im Unternehmen nicht mehr verwendet wird, da sie aus Dokumenten vor der Reorganisation stammt.

Bevor Sie mit dem Aufbau von RAG oder Fine-Tuning beginnen, führen Sie ein Daten-Audit durch: Welche Dokumente sind aktuell, welche sind verwaist, welche enthalten Widersprüche. Der Artikel zur Vorbereitung von Unternehmensdaten für KI beschreibt dieses Audit Schritt für Schritt.

Ein Sprachmodell ohne Guardrails ist wie ein Mitarbeiter ohne Aufgabenbereich: Es macht alles, worum man es bittet, einschließlich Dinge außerhalb seiner Kompetenz. In einer Unternehmensumgebung bedeutet das Antworten auf Fragen, auf die das Modell nicht antworten sollte, oder das Erfinden von Antworten, wenn das Wissen in der Datenbank fehlt.

Zwei Mechanismen, die in jedem Produktionssystem obligatorisch sind:

Antwort „Ich weiß nicht“ mit Eskalation. Ein Modell, das keine ausreichend sichere Antwort in der Wissensdatenbank findet, sollte nicht raten. Es sollte direkt sagen: „Ich habe keine sicheren Informationen zu diesem Thema“ und den Kontakt zu einem Menschen vorschlagen. Die Gestaltung dieses Pfades beschreibt der Artikel über Monitoring und Qualität eines KI-Agenten.

Thematische Guardrails. Ein System, das im Bereich Kundenservice eines Online-Shops arbeitet, antwortet nicht auf rechtliche Fragen, gibt keine konkreten Versicherungspreise an und diagnostiziert keine medizinischen Probleme. Guardrails werden als Liste zulässiger Intentionen oder blockierter Kategorien von Anfragen definiert. Jeder Versuch, den Rahmen zu verlassen, wird protokolliert und eskaliert.

Das Fehlen dieser Mechanismen führt nicht nur zu schlechter Antwortqualität, sondern auch zu rechtlicher Haftung für die vom System produzierten Inhalte.

KI-Projekte fallen regelmäßig in die Falle: Daten sind angebunden, das Modell antwortet, aber niemand hat überprüft, was eigentlich an das Modell gesendet wird und wo es verarbeitet wird. Besonders kritische Szenarien:

• Personenbezogene Daten von Kunden (Namen, Bestellnummern, Adressen) gelangen in Prompts an externe APIs ohne Pseudonymisierung.
• Konversationsprotokolle enthalten PII in Klartext und werden ohne rechtliche Grundlage gespeichert.
• Das Unternehmen nutzt eine Cloud-API für das Modell, und der Vertrag mit dem Anbieter erfüllt nicht die Anforderungen von Art. 28 RODO (Datenverarbeiter).

Mindestanforderungen an die Sicherheit für jedes KI-Projekt, das personenbezogene Daten verarbeitet:

1. Maskierung von PII vor der Übergabe an das Modell (im Router, nicht in der Client-Anwendung).
2. Auftragsverarbeitungsvertrag mit dem Modellanbieter oder Self-Hosting in der eigenen Infrastruktur.
3. Datenaufbewahrung von Konversationen auf das für den Zweck notwendige Minimum beschränkt, mit automatischer Löschung.
4. Pfad zur Umsetzung des Rechts auf Löschung von Daten (RODO Art. 17), besonders relevant bei Embeddings und Vektordatenbanken.

Für Prozesse mit hohem Risiko (Gesundheitsdaten, Finanzdaten, Personaldaten) ist eine DPIA vor dem Start erforderlich. Details zu den Pflichten von Unternehmen im Jahr 2026 beschreibt der Artikel AI Act und RODO 2026.

KI-Systeme, die im Namen des Unternehmens handeln (E-Mails versenden, Datensätze aktualisieren, Transaktionen genehmigen), benötigen einen Freigabemechanismus für irreversible Schritte. Ein Projekt, das diesen nicht hat, wird früher oder später eine Nachricht an den falschen Adressaten senden, einen wichtigen Datensatz überschreiben oder eine Aktion auf Basis einer falschen Klassifizierung genehmigen.

Human-Gate bedeutet nicht die vollständige Abschaltung der Automatisierung. Es bedeutet, dass der Agent vor einem irreversiblen Schritt anhält und auf die explizite Freigabe durch einen Operator wartet. Die Freigabe wird protokolliert: wer, wann, in welchem Kontext. In der Praxis bewährt sich das Modell von fünf Fragen vor jeder risikoreichen Aktion:

1. Verändert die Aktion den Systemzustand in einer schwer umkehrbaren Weise?
2. Hat ein Fehler in dieser Aktion direkte Auswirkungen auf den Kunden oder finanzielle Folgen?
3. Hatte das Modell Zugang zu allen notwendigen Daten für diese Entscheidung?
4. Ist das Ergebnis des vorherigen Schrittes sicher (nicht geschätzt)?
5. Wurde diese Aktion bereits in einem ähnlichen Kontext erfolgreich durchgeführt?

Eine „Nein“-Antwort auf eine dieser Fragen ist ein Signal zum Anhalten und Eskalieren. Die detaillierte Architektur dieses Mechanismus beschreibt der Artikel über die Rolle des Menschen im Agentenkreislauf.

Ein KI-Projekt wird gestartet, funktioniert zwei Wochen lang gut, dann verschlechtert sich die Qualität allmählich. Niemand bemerkt es, weil keine Metriken vorhanden sind. Das Modell antwortet weiterhin, aber die Antworten werden immer weniger treffend, immer mehr Kunden werden aufgrund falscher Antworten des Systems an einen Menschen weitergeleitet.

Qualitätsdrift ist ein systematisches Phänomen: Die Daten im Unternehmen ändern sich (neue Produkte, geänderte Verfahren, neue Vorschriften), aber die Wissensdatenbank des Modells hält nicht Schritt. Ein System, das seine eigene Qualität nicht überwacht, hat keine Möglichkeit, den Moment zu erkennen, in dem es zum Problem wird.

Mindestanforderungen an das Monitoring für ein Produktionssystem:

Die Architektur eines vollständigen Monitorings beschreibt der Artikel über Monitoring und KPI eines KI-Agenten. Die Bewertung der Antwortqualität von RAG mit der Golden-Set-Methode beschreibt der Artikel über RAG-Evaluierung.

Nicht jeder Prozess eignet sich für das erste KI-Projekt. Der häufigste Fehler: Ein Unternehmen wählt entweder einen zu trivialen Prozess (FAQ, dessen Bearbeitung 10 Minuten pro Tag in Anspruch nahm) oder einen zu komplexen (Beschwerdebearbeitung, die Expertenbewertung und Verhandlungen erfordert). Der erste rechtfertigt die Investition nicht. Der zweite scheitert, weil das Modell den Experten nicht zuverlässig ersetzen kann.

Merkmale eines geeigneten Prozesses für den Start:

• Wiederholbarkeit: Mindestens 50 ähnliche Fälle pro Monat.
• Definierbarkeit: Jeder Schritt lässt sich durch eine Regel oder ein Entscheidungsschema beschreiben.
• Überprüfbarkeit: Das Ergebnis lässt sich programmatisch oder durch einfache Kontrolle überprüfen.
• Begrenzter Entscheidungsumfang: Erfordert kein Kontextwissen außerhalb der verfügbaren Daten.
• Kein Hochrisikoprozess im Sinne von AI Act Anhang III (oder das Unternehmen ist bereit für vollständige Compliance).

Vor der Auswahl eines Prozesses lohnt es sich, den Automatisierungsfinder zu durchlaufen, der die Eignung des Prozesses für die KI-Automatisierung nach diesen Kriterien bewertet. Die Methodik zur Auswahl des ersten Prozesses beschreibt auch der Artikel Wo man mit der KI-Implementierung beginnt.

Von den Projekten, die in die Produktion überführt werden, hat die überwiegende Mehrheit die Phase des Shadow Mode durchlaufen. Der Agent arbeitet parallel zum Menschen für 2-4 Wochen: Er verarbeitet dieselben Daten, generiert dieselben Antworten, aber die Ergebnisse werden nicht angewendet. Stattdessen werden sie mit den Entscheidungen des Menschen verglichen.

Shadow Mode deckt Lücken auf, die keine Unit-Tests finden: branchenspezifische Randfälle, Terminologie, die von Kunden verwendet wird und nicht zur Dokumentation passt, Situationen, in denen die Daten in der Datenbank widersprüchlich sind.

Erst nach dem Shadow Mode mit einer Abweichung unter einem festgelegten Schwellenwert (typischerweise 5-10 % unterschiedliche Entscheidungen im Vergleich zum Menschen) geht das System in die Pilotphase mit Human-Gate über. Einen vollständigen Zeitplan und Implementierungsplan Schritt für Schritt beschreibt der Artikel KI-Implementierungsplan.

Beschreiben Sie das KI-Projekt, das Sie planen oder das feststeckt. Das Modell zeigt an, welcher der sieben Fehler am besten zu Ihrem Fall passt und schlägt konkrete Korrekturschritte vor. (Playground: PII maskiert, keine Retention):

Nein. RAG (Suche auf Basis einer Wissensdatenbank) funktioniert gut mit einigen hundert bis einigen tausend Dokumenten, wenn sie aktuell und konsistent sind. Fine-Tuning erfordert große Datensätze, aber die meisten Projekte in der ersten Phase benötigen dies nicht. Entscheidend ist die Qualität und Aktualität der Daten, nicht ihre Menge. Ein Unternehmen mit 200 guten Dokumenten wird ein besseres System produzieren als ein Unternehmen mit 20.000 Dokumenten, von denen die Hälfte veraltet oder widersprüchlich ist. Ein Daten-Audit vor dem Projekt beschreibt der Artikel über Vorbereitung von Unternehmensdaten für KI.

Für einen gut ausgewählten Prozess: 6-10 Wochen vom Vertragsabschluss bis zur Entscheidung über den Übergang in die Produktion. Woche 1-2: Daten- und Guardrails-Audit. Wochen 3-5: Shadow Mode. Wochen 6-8: Pilot mit Human-Gate und Monitoring. Wochen 9-10: Entscheidung und eventuelle Korrekturen. Projekte verkürzen sich, wenn das Unternehmen bereits vorbereitete Daten und ein definiertes Ziel hat. Sie verlängern sich bei der Integration mit mehreren Systemen oder fehlendem Zugang zu historischen Daten. Die ungefähren Kosten eines Piloten berechnet der ROI-Rechner.

Prüfen Sie, ob der Prozess als Hochrisikosystem im Sinne von AI Act Anhang III eingestuft wird. Dies betrifft Bereiche wie: Beschäftigung (Auswahl von Bewerbern, Mitarbeiterbewertung), Finanzdienstleistungen (Kreditscoring), Bildung, Gesundheitswesen und einige andere. Für solche Systeme sind erforderlich: DPIA, technische Dokumentation, Registrierung des Systems in der EU-Datenbank, Mechanismus für menschliche Aufsicht und Transparenz gegenüber Nutzern. Eine detaillierte Beschreibung der Pflichten im Jahr 2026 enthält der Artikel AI Act und RODO 2026.

Vier Kontrollfragen vor dem Übergang vom Piloten zur Produktion: (1) Liegt die Fehlerrate im Golden Set unter dem festgelegten Schwellenwert? (2) Wurden Guardrails an realen Randfällen getestet, nicht nur an synthetischen? (3) Funktioniert der Eskalationspfad zum Menschen und wird überwacht? (4) Sind die Daten in der Wissensdatenbank aktuell und konsistent mit dem aktuellen Angebot oder den Verfahren? Erst wenn alle vier Punkte grün sind, macht die Produktionsimplementierung Sinn. Die Bereitschaftsbewertung unterstützt das Tool Bereitschaftsbewertung.

Ja, aber es erfordert eine Diagnose der Ursache, nicht das Hinzufügen weiterer Funktionen. Die häufigsten Reparaturen: Aktualisierung der Wissensdatenbank (wenn das Problem Daten-Drift ist), Hinzufügen einer Guardrails-Schicht und eines „Ich weiß nicht“-Pfades (wenn das Problem unkontrollierte Antworten sind), Implementierung eines Golden-Set-Monitorings (wenn das Problem mangelnde Sichtbarkeit ist). Projekte, die aufgrund der falschen Prozesswahl feststecken, erfordern einen Rückschritt zur Auswahl und möglicherweise einen Piloten mit einem anderen Prozess. Der erste Schritt ist immer die Diagnose, nicht das komplette Neuschreiben. Schreiben Sie uns über Kontakt mit einer Beschreibung der Situation. Wir analysieren und schlagen einen Reparaturpfad vor.