Warum KI-Projekte scheitern – und warum das Modell selten das Problem ist

Wenn ein KI-Projekt stockt, ist der Reflex oft derselbe: „Wir brauchen ein besseres Modell.“ Das ist verständlich, weil das LLM der sichtbarste Teil des Systems ist. In der Praxis liegt der Engpass aber häufig woanders – bei Daten, Prozess, Integration, Evaluation, Verantwortung oder Betrieb.

Ein leistungsfähiges Modell kann eine schlechte Systemarchitektur nicht kompensieren.

Die wichtigste Frage lautet deshalb nicht zuerst „Welches Modell?“, sondern: Welche Aufgabe soll zuverlässig besser funktionieren – und woran erkennen wir, dass sie funktioniert?

Die kurze Antwort: Warum KI-Projekte scheitern

Acht Ursachen tauchen besonders häufig auf:

1. kein klarer Business Case,
2. ungeeignete oder schlecht zugängliche Daten,
3. keine messbaren Qualitätskriterien,
4. unklare Verantwortlichkeiten,
5. Integration erst nach dem PoC,
6. Security, Datenschutz und Rechte zu spät,
7. kein Betriebsmodell,
8. fehlende Adoption im realen Workflow.

Das Modell kann bei jedem dieser Punkte technisch hervorragend sein und das Projekt trotzdem keinen belastbaren Nutzen erzeugen.

1. Der Business Case bleibt zu abstrakt

„Wir wollen KI einsetzen“ ist kein Use Case.

Ein belastbarer Use Case beschreibt:

• wer die Aufgabe heute erledigt,
• welches konkrete Problem entsteht,
• welche Informationen benötigt werden,
• welches Ergebnis erwartet wird,
• welche Fehler tolerierbar sind,
• und wie sich ein besserer Zustand beobachten lässt.

Beispiel: „Ein interner Chatbot für Wissen“ ist zu breit. „Servicemitarbeiter finden für Produktgruppe X die aktuelle technische Richtlinie inklusive Quelle in unter zwei Minuten“ ist wesentlich besser prüfbar.

Je konkreter die Aufgabe, desto leichter lassen sich Daten, Architektur und Evaluation darauf ausrichten.

2. Die Daten passen nicht zur Erwartung

KI-Projekte scheitern häufig nicht an zu wenig Daten, sondern an falscher Datenrealität.

Typische Probleme:

• dieselbe Information liegt in mehreren Versionen vor,
• Dokumente sind veraltet,
• wichtige Inhalte fehlen,
• Berechtigungen sind historisch gewachsen,
• PDFs lassen sich schlecht parsen,
• Daten liegen in Systemen, die nicht sauber angebunden werden können,
• fachliche Owner sind unklar.

Ein RAG-System kann nur finden, was in einer verwertbaren Form vorhanden ist.

Wenn Sie mehrere Systeme anbinden müssen, zeigt der Leitfaden RAG-Datenquellen anbinden, welche Fragen zu Synchronisierung, ACLs, Metadaten und Löschungen vor dem ersten Embedding geklärt werden sollten.

3. Niemand definiert, was „gut genug“ bedeutet

Ein Demo-Moment ist kein Qualitätskriterium.

Wenn ein Team zehn Fragen stellt und acht Antworten „ganz gut“ wirken, lässt sich daraus keine Produktionsfreigabe ableiten.

Für einen Pilot sollten Sie vorab definieren:

• repräsentative Testfragen,
• erwartete Quellen oder Ergebnisse,
• kritische Fehlerklassen,
• akzeptable Antwortgrenzen,
• Latenzanforderungen,
• und klare Stop-/Go-Kriterien.

Bei RAG kommen Retrieval-Qualität, Groundedness und Citation Accuracy hinzu. Bei Agents zusätzlich Tool Calls, Freigaben und Seiteneffekte.

Ohne solche Kriterien wird jede Änderung subjektiv diskutiert.

4. Verantwortlichkeiten bleiben zwischen Fachbereich und IT hängen

Wer besitzt die Antwortqualität? Wer entscheidet, welche Quellen gültig sind? Wer darf einen Prompt, ein Modell oder eine Retrieval-Regel ändern? Wer reagiert auf einen Vorfall?

In klassischen Anwendungen sind Zuständigkeiten oft klarer. Bei KI verschwimmen sie zwischen Fachbereich, IT, Security, Datenschutz und Anbieter.

Vor dem Go-live braucht das System mindestens einen fachlichen Owner und einen technischen Owner. Bei kritischen Workflows sollten zusätzlich Freigabe- und Eskalationswege definiert sein.

5. Integration kommt zu spät

Viele PoCs leben in einem separaten Chatfenster. Das ist praktisch für eine Demo, aber häufig nicht der Ort, an dem der Nutzer seine Arbeit tatsächlich erledigt.

Produktiver Nutzen entsteht erst, wenn die KI in den realen Prozess passt:

• bestehende Anwendung,
• DMS,
• CRM,
• ERP,
• Service-Desk,
• E-Mail- oder Dokumentenworkflow,
• interne Plattform.

Dabei entstehen Fragen, die der PoC oft nicht beantwortet hat: Identität, Berechtigungen, Rückschreiben, Fehlerfälle, Quellenanzeige, Auditierbarkeit und Zuständigkeiten.

Deshalb sollte die Integrationsgrenze schon in der Pilotphase mitgedacht werden.

6. Security, Datenschutz und Rechte werden auf „später“ verschoben

Ein System, das nur mit Testdaten funktioniert, beweist noch wenig über seinen späteren Betrieb.

Sobald reale Unternehmensdaten beteiligt sind, müssen unter anderem geklärt sein:

• welche Daten verarbeitet werden,
• wer darauf zugreifen darf,
• welche Systeme oder Anbieter beteiligt sind,
• wo Daten gespeichert oder übertragen werden,
• welche Logs entstehen,
• wie Mandanten- oder Abteilungsgrenzen durchgesetzt werden.

Bei RAG ist permission-aware retrieval besonders wichtig: Die KI darf nicht zum alternativen Weg um bestehende Berechtigungen werden.

Eine souveräne oder lokale Architektur kann Kontrollmöglichkeiten erhöhen, ist aber nicht automatisch DSGVO-konform. Die technische Einordnung finden Sie unter Souveräne KI für Unternehmen. Sie ersetzt keine Rechtsberatung.

7. Der Betrieb wird erst nach dem Pilot erfunden

Ein PoC kann mit manuellem Datenimport und einem einzelnen Entwickler funktionieren. Produktion braucht mehr.

Mindestens zu klären sind:

• Monitoring,
• Fehleranalyse,
• Daten- und Index-Aktualität,
• Modell- und Prompt-Änderungen,
• Regressionstests,
• Kosten,
• Latenz,
• Backups und Wiederherstellung,
• Security Updates,
• Ansprechpartner bei Störungen.

Besonders bei schnell veränderlichen Modellen und Datenquellen ist „einmal getestet“ keine dauerhafte Qualitätsgarantie.

8. Die Lösung passt nicht in den Arbeitsalltag

Technische Qualität allein erzeugt noch keine Nutzung.

Ein System kann gute Antworten liefern und trotzdem ignoriert werden, wenn:

• Nutzer dafür den Workflow verlassen müssen,
• Antworten nicht überprüfbar sind,
• die Bedienung langsamer als der bestehende Weg ist,
• unklar ist, wann man dem Ergebnis vertrauen darf,
• oder die KI einen zusätzlichen Arbeitsschritt statt Entlastung erzeugt.

Deshalb ist Task Success wichtiger als eine isolierte Modellmetrik. Die Frage lautet: Wird die reale Aufgabe besser erledigt?

Architektur vor Tool-Wahl

Die Frage „Welches Tool?“ kommt fast immer zu früh.

Eine bessere Reihenfolge:

1. Business-Aufgabe definieren
2. reale Daten und Rechte klären
3. Testfälle und Qualitätskriterien festlegen
4. Zielarchitektur und Integrationsgrenzen bestimmen
5. kleinen Pilot bauen
6. gegen reale Fälle evaluieren
7. erst danach skalieren

So bleiben Modell, Vector Database und Framework austauschbare Bausteine statt frühe Architekturzwänge.

Der Unterschied zwischen Pilot und Production Readiness

Ein Pilot beantwortet:

Können wir mit vertretbarem Aufwand einen echten Nutzenfall technisch abbilden?

Wie Scope, Daten, Testfälle, Metriken und Go/No-Go dafür konkret aussehen, zeigt der Leitfaden KI-Pilot planen: vom Use Case zum belastbaren Go/No-Go.

Production Readiness beantwortet:

Können wir dieses System mit realen Nutzern, Daten, Berechtigungen und Fehlerfällen verantwortbar betreiben?

Dafür reichen schöne Demo-Antworten nicht.

Ein belastbarer Readiness-Check betrachtet beispielsweise:

| Bereich | Leitfrage | |---|---| | Business Fit | Löst das System die definierte Aufgabe? | | Daten | Sind Quellen aktuell, vollständig und kontrolliert? | | Retrieval | Wird die richtige Evidenz gefunden? | | Qualität | Sind Fehler reproduzierbar messbar? | | Rechte | Sieht jeder Nutzer nur erlaubte Inhalte? | | Integration | Funktioniert der reale End-to-End-Workflow? | | Security | Sind relevante Angriffs- und Missbrauchspfade berücksichtigt? | | Betrieb | Gibt es Monitoring, Ownership und Regressionstests? | | Kosten/Latenz | Ist das System unter realistischen Lasten tragfähig? |

Ein praktischer 30-Minuten-Projektcheck

Wenn ein KI-Projekt gerade festhängt, beantworten Sie diese Fragen ohne Tooldiskussion:

1. Wer ist der konkrete Nutzer?
2. Welche Aufgabe soll besser werden?
3. Welche fünf realen Beispiele repräsentieren diese Aufgabe?
4. Welche Quellen werden dafür benötigt?
5. Welche Fehler wären geschäftlich kritisch?
6. Wer darf welche Daten sehen?
7. Wo muss die KI in den bestehenden Prozess integriert werden?
8. Wer besitzt Qualität und Betrieb?
9. Woran entscheidet das Team Go oder No-Go?
10. Welche Annahme ist aktuell am wenigsten belegt?

Wenn mehrere Antworten fehlen, ist ein Modellwechsel wahrscheinlich nicht der erste Hebel.

Was ich in festgefahrenen KI-Projekten zuerst prüfen würde

Ich würde das System nicht sofort neu bauen. Zuerst trenne ich die Fehlerklasse:

• Architektur unklar? Dann KI-Architekturberatung.
• Datenquellen und Integration sind das Problem? Dann RAG-Implementierung & KI-Integration.
• Ein PoC existiert, aber Qualität und Go-live sind unsicher? Dann AI Production Readiness.
• Datenhoheit oder Hosting ist der zentrale Engpass? Dann Souveräne KI.

Ihr PoC funktioniert in der Demo, aber niemand kann belastbar sagen, ob er produktionsreif ist?
→ KI-System vor dem Go-live prüfen

Die technische Einordnung zu Datenschutz und Compliance ersetzt keine Rechtsberatung.