RAG-Projekte enttäuschen selten, weil die Technologie grundsätzlich falsch ist. Sie enttäuschen, weil Unternehmen Dokumente, Zuständigkeiten, Qualitätssicherung und Prozesse unterschätzen. Wer RAG als Suchmaschine mit Sprachmodell behandelt, bekommt oft schöne Antworten, aber nicht automatisch verlässliches Unternehmenswissen.
Viele Unternehmen starten ihr erstes RAG-Projekt mit einem erstaunlich einfachen Bild im Kopf. Man nimmt interne Dokumente, legt sie in eine Vektordatenbank, verbindet ein Sprachmodell damit und erhält danach einen Assistenten, der endlich alles weiß. Die Demo funktioniert meistens schnell. Ein PDF wird hochgeladen, eine Frage gestellt, die Antwort klingt ordentlich. Genau dort beginnt das Missverständnis.
Denn ein RAG-System ist nicht dann erfolgreich, wenn es auf drei Testfragen gut antwortet. Es ist erfolgreich, wenn es im Arbeitsalltag stabil bleibt. Wenn es alte von neuen Dokumenten unterscheiden kann. Wenn es weiß, welche Quelle verbindlich ist. Wenn es bei Unsicherheit sauber bremst. Wenn Mitarbeiter erkennen können, warum eine Antwort zustande kam. Und wenn es nicht nur Wissen findet, sondern in echte Abläufe passt.
Gerade im deutschen Mittelstand ist diese Lücke besonders relevant. Dort liegen Informationen nicht in einem perfekt gepflegten Wissensgraphen, sondern in Dateiablagen, E-Mails, PDFs, Ticketsystemen, SharePoint-Ordnern, Excel-Listen, Wartungsprotokollen, Angeboten, alten Vorlagen und in den Köpfen erfahrener Mitarbeiter. RAG kann hier sehr wertvoll sein. Aber nur, wenn man es nicht als reines IT-Experiment behandelt.
Warum wirkt die erste RAG-Demo oft besser als das spätere Produkt?
Die erste Demo ist meistens freundlich. Der Datenbestand ist klein, die Fragen sind bekannt, die Dokumente sind halbwegs sauber und niemand testet die schwierigen Fälle. In dieser Umgebung sieht RAG fast immer überzeugend aus. Die Antwort ist flüssig, die Quellen werden angezeigt, und alle im Raum haben das Gefühl, dass man kurz vor einem Durchbruch steht.
Im Produktivbetrieb ändert sich die Situation. Nutzer fragen ungenau. Dokumente widersprechen sich. Abteilungen benutzen unterschiedliche Begriffe. Eine alte Verfahrensanweisung liegt neben einer neuen. Ein Kunde heißt in einem System anders als im anderen. Ein PDF enthält eingescannte Tabellen. Ein Angebot verweist auf eine Anlage, die nicht indexiert wurde. Und plötzlich zeigt sich: RAG ist weniger ein KI-Projekt als ein Wissens-, Daten- und Prozessprojekt.
Gartner prognostizierte bereits 2024, dass mindestens 30 Prozent der GenAI-Projekte bis Ende 2025 nach dem Proof of Concept aufgegeben werden, unter anderem wegen schlechter Datenqualität, unzureichender Risikokontrollen, steigender Kosten und unklarem Geschäftswert. Das passt sehr gut zu dem, was man bei RAG-Projekten sieht: Die Demo ist nicht das Problem. Die industrielle Nutzbarkeit ist das Problem.
Warum ist schlechte Datenqualität bei RAG so gefährlich?
RAG klingt nach einer eleganten Lösung gegen falsche Antworten, weil das Modell nicht nur aus seinem Trainingswissen antwortet, sondern zusätzliche Unternehmensquellen erhält. Das stimmt grundsätzlich. Aber die Qualität der Antwort kann nur so gut sein wie die Qualität des gefundenen Kontextes.
Wenn ein Unternehmen alte Preislisten, veraltete SOPs, doppelte Prozessbeschreibungen und widersprüchliche Projektvorlagen indexiert, dann macht RAG daraus kein sauberes Wissenssystem. Es findet lediglich Fragmente aus einem unsauberen Bestand. Manchmal sogar sehr überzeugend formuliert.
Das ist gefährlich, weil schlechte RAG-Antworten oft plausibel wirken. Ein Mitarbeiter erkennt vielleicht nicht sofort, dass die Antwort auf einer alten Richtlinie basiert. Ein Servicetechniker übernimmt eine veraltete Vorgehensweise. Ein Vertriebsmitarbeiter nutzt eine falsche Formulierung im Angebot. Ein interner Support verweist auf einen Prozess, der längst geändert wurde.
McKinsey berichtete 2025, dass mehr als 80 Prozent der befragten Organisationen noch keinen spürbaren EBIT-Effekt durch GenAI sehen. Das ist kein Beweis gegen GenAI. Es zeigt aber, dass der Weg von der technischen Nutzung zum messbaren Geschäftswert deutlich schwieriger ist als viele Pilotprojekte vermuten lassen.
Warum reicht eine Vektordatenbank allein nicht aus?
Eine Vektordatenbank findet ähnliche Inhalte. Das ist nützlich. Aber Ähnlichkeit ist nicht dasselbe wie Verbindlichkeit.
Wenn ein Mitarbeiter fragt, wie ein bestimmter Reklamationsfall zu behandeln ist, reicht es nicht, irgendeinen ähnlichen Fall zu finden. Das System muss erkennen, ob der Fall noch aktuell ist, welche Richtlinie gilt, welche Rolle entscheiden darf und ob es Ausnahmen gibt. Genau hier scheitern viele einfache RAG-Architekturen.
Ein klassischer Fehler besteht darin, alle Dokumente gleich zu behandeln. Ein freigegebenes Prozesshandbuch, eine alte PowerPoint, eine private Notiz und ein exportierter Chatverlauf landen im selben Index. Technisch funktioniert das. Fachlich ist es riskant.
RAG braucht deshalb Metadaten. Dazu gehören Dokumenttyp, Gültigkeit, Version, Eigentümer, Freigabestatus, Branche, Kunde, Standort, Sprache, Vertraulichkeit und Aktualisierungsdatum. Ohne diese Informationen kann das System zwar suchen, aber nicht zuverlässig gewichten.
| Ansatz | Was oft gebaut wird | Was im Mittelstand wirklich gebraucht wird |
|---|---|---|
| Datenbasis | Alle Dateien werden indexiert | Nur geprüfte, klassifizierte und versionierte Quellen werden produktiv verwendet |
| Suche | Ähnlichkeit über Embeddings | Kombination aus semantischer Suche, Metadaten, Filtern und Regeln |
| Antwort | Sprachmodell formuliert frei | Antwort mit Quellen, Unsicherheitslogik und klaren Grenzen |
| Betrieb | Einmaliger Import | Laufende Pflege, Monitoring, Feedback und Verantwortlichkeit |
| Erfolgsmessung | Demo wirkt gut | Wiederholbare Tests gegen reale Arbeitsfragen |
Warum entstehen falsche Erwartungen an RAG?
Viele Erwartungen entstehen aus einer Vermischung von drei Dingen: Chatbot, Unternehmenssuche und Entscheidungsunterstützung. Ein Chatbot kann freundlich antworten. Eine Suche kann relevante Dokumente finden. Entscheidungsunterstützung muss dagegen fachlich belastbar, nachvollziehbar und begrenzt sein.
RAG wird oft als Abkürzung verkauft. Man müsse angeblich nur das interne Wissen anschließen. In Wirklichkeit muss man zuerst entscheiden, welches Wissen überhaupt gültig ist. Das ist unbequem, weil es alte organisatorische Probleme sichtbar macht. Wer ist für die Pflege verantwortlich? Welche Quelle ist führend? Welche Dokumente dürfen Mitarbeiter sehen? Welche Antworten sind rechtlich oder wirtschaftlich kritisch? Wann muss das System eskalieren?
Stanford HAI berichtet im AI Index 2025, dass 78 Prozent der Organisationen 2024 KI nutzten, nach 55 Prozent im Vorjahr. Die Nutzung steigt also schnell. Doch Nutzung ist nicht gleich Reife. Gerade RAG-Projekte zeigen, dass viele Unternehmen schneller experimentieren, als sie ihre Wissensbasis ordnen.
Warum ist Evaluation der unterschätzte Teil jedes RAG-Projekts?
In vielen Projekten wird getestet, ob das System „gute Antworten“ gibt. Das ist zu weich. RAG braucht Testsets mit echten Fragen aus dem Arbeitsalltag. Nicht zehn Fragen aus dem Projektteam, sondern Dutzende oder Hunderte wiederkehrende Fragen aus Vertrieb, Service, Support, IT, Qualität, Einkauf oder Außendienst.
Gute Evaluation trennt mehrere Ebenen. Hat das System das richtige Dokument gefunden? Hat es den richtigen Abschnitt gefunden? Hat das Modell nur aus dem gefundenen Kontext geantwortet? Wurde eine veraltete Quelle verwendet? Wurde Unsicherheit korrekt angezeigt? Wurde eine nicht beantwortbare Frage trotzdem beantwortet?
Microsoft beschreibt RAG-Evaluatoren als Mittel, um zu prüfen, ob Antworten relevant und konsistent mit den Grounding-Dokumenten sind. LlamaIndex verweist bei Retrieval Evaluation unter anderem auf Metriken wie Hit Rate, Precision und Mean Reciprocal Rank. Das klingt technisch, ist aber in der Praxis sehr konkret: Findet das System die richtige Grundlage, bevor es spricht?
Warum enttäuschen RAG-Projekte besonders bei unklarem Scope?
Ein RAG-System für „alle Unternehmensfragen“ ist fast immer zu breit. Es klingt attraktiv, aber es ist selten ein guter Startpunkt. Besser ist ein enges, wertvolles Anwendungsfeld: Angebotswissen, interne IT-Hilfe, Wartungsfälle, wiederkehrende Kundenfragen, Qualitätsabweichungen, Arbeitsschutzanweisungen oder technische Dokumentation.
Je klarer der Scope, desto besser lassen sich Quellen prüfen, Fragen sammeln, Rollen definieren und Qualität messen. Ein RAG-Projekt für SHK-Wartungsberichte braucht andere Quellen als ein RAG-Projekt für Verkehrssicherung, Gerüstbau oder interne IT. Die Sprache ist anders, die Risiken sind anders, die Dokumenttypen sind anders.
Viele Enttäuschungen entstehen nicht, weil RAG nichts kann, sondern weil man zu früh zu viel will. Das System soll gleichzeitig suchen, beraten, dokumentieren, entscheiden, kontrollieren und automatisieren. Dadurch wird es unklar. Und unklare Systeme werden schwer testbar.
Warum ist Zugriffskontrolle mehr als ein technisches Detail?
Ein internes RAG-System kann nur dann produktiv genutzt werden, wenn Rechte sauber abgebildet werden. Wer darf welche Kundeninformationen sehen? Welche HR-Dokumente sind ausgeschlossen? Darf ein Monteur die komplette Kundenhistorie sehen oder nur auftragsbezogene Informationen? Was passiert mit vertraulichen Kalkulationen? Werden Dokumente in eine zentrale Vektordatenbank kopiert oder zur Laufzeit aus Quellsystemen abgefragt?
Diese Fragen sind nicht nachgelagert. Sie gehören an den Anfang. Gerade in Deutschland sind Datenschutz, Vertraulichkeit und Nachvollziehbarkeit keine Dekoration, sondern Teil der Produktfähigkeit.
Ein RAG-Projekt ohne Zugriffskonzept erzeugt schnell Misstrauen. Dann nutzen Mitarbeiter das System nicht, Führungskräfte geben es nicht frei, und die IT blockiert den Rollout. Das ist kein Kulturproblem. Es ist ein Architekturproblem.
Warum braucht RAG einen fachlichen Eigentümer?
Ein RAG-System ohne fachlichen Eigentümer altert schnell. Neue Dokumente kommen hinzu. Alte Prozesse laufen aus. Begriffe ändern sich. Kundenanforderungen verschieben sich. Wenn niemand verantwortlich ist, wird der Index zu einem digitalen Speicherraum, in dem alles liegt und wenig verlässlich ist.
Der Eigentümer muss nicht alles selbst pflegen. Aber er muss entscheiden können, welche Quellen verbindlich sind, welche Inhalte freigegeben werden und welche Antwortqualität akzeptabel ist. In kleineren und mittleren Unternehmen kann diese Rolle bei der Geschäftsführung, IT-Leitung, Serviceleitung, Qualitätsleitung oder einer fachlichen Schlüsselperson liegen.
Die technische Seite braucht ebenfalls Verantwortung: Monitoring, Indexaktualisierung, Fehleranalyse, Modellwechsel, Kostenkontrolle, Rechteprüfung und Logging. RAG ist kein einmaliges Projekt. Es ist ein Betriebsmodell.
Warum sollte RAG nicht mit einem Company Brain verwechselt werden?
RAG ist eine Architekturtechnik. Ein Company Brain ist ein betriebliches Wissenssystem. Das ist ein wichtiger Unterschied.
RAG kann Teil eines Company Brains sein. Es kann helfen, Dokumente semantisch zu durchsuchen, ähnliche Fälle zu finden und Antworten aus internen Quellen zu formulieren. Aber ein Company Brain braucht mehr: Wissensstruktur, Rollen, Freigaben, Templates, Prozesslogik, Versionierung, Feedback, Verantwortlichkeiten und eine klare Verbindung zu Arbeitsabläufen.
Wer nur RAG baut, baut oft eine bessere Suche. Wer ein Company Brain baut, baut eine wiederverwendbare Wissensinfrastruktur. Für den Mittelstand ist genau diese Unterscheidung entscheidend. Denn der eigentliche Schmerz liegt nicht darin, dass Mitarbeiter keine schöne Chatoberfläche haben. Der Schmerz liegt darin, dass Wissen verstreut, veraltet, personenbezogen und schwer wiederverwendbar ist.
Welche Lessons Learned bleiben nach enttäuschenden RAG-Projekten?
Die wichtigste Lektion lautet: Nicht mit Technologie beginnen, sondern mit Arbeitsfragen. Welche Fragen kommen jede Woche wieder? Wo verlieren Mitarbeiter Zeit? Wo werden alte Fälle nicht gefunden? Wo entstehen Risiken durch falsche Auskünfte? Wo hängt Wissen an einzelnen Personen?
Die zweite Lektion: Datenqualität ist kein Vorprojekt, das man irgendwann erledigt. Sie ist Teil des Produkts. Ohne gepflegte Quellen, Metadaten und Verantwortlichkeiten bleibt RAG instabil.
Die dritte Lektion: Evaluation muss von Anfang an mitgebaut werden. Ein RAG-System ohne Testfragen, Qualitätsmetriken und Feedbackschleifen ist kaum steuerbar.
Die vierte Lektion: Der Nutzen entsteht nicht durch eine Antwort, sondern durch Wiederverwendbarkeit. Wenn ein gelöster Fall, eine gute Angebotslogik oder eine bewährte Checkliste dauerhaft auffindbar wird, entsteht Geschäftswert.
RAG enttäuscht also nicht, weil es unwichtig ist. Es enttäuscht, wenn es als schnelle Abkürzung verstanden wird. Richtig gebaut, ist es ein starkes Werkzeug. Falsch gebaut, ist es nur ein sprachgewandter Zugriff auf ungeordnetes Wissen.
Quellenangabe der verwendeten Kennzahlen
- Gartner: „Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025“
https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025 - McKinsey: „The state of AI: How organizations are rewiring to capture value“
https://www.mckinsey.de/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value - Stanford HAI: „The 2025 AI Index Report“
https://hai.stanford.edu/ai-index/2025-ai-index-report - McKinsey: „The State of AI: Global Survey 2025“
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
Interessante Links
- Microsoft Learn: „Retrieval-augmented generation in Azure AI Search“
https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview - LlamaIndex: „Evaluating“
https://developers.llamaindex.ai/python/framework/module_guides/evaluating/ - Google Cloud: „What is Retrieval-Augmented Generation?“
https://cloud.google.com/use-cases/retrieval-augmented-generation
Warum scheitern viele RAG-Projekte nach dem Proof of Concept?
Viele RAG-Projekte scheitern nach dem Proof of Concept, weil die Demo unter kontrollierten Bedingungen entsteht. Im Alltag kommen unklare Fragen, widersprüchliche Dokumente, alte Versionen, fehlende Rechte und schwierige Sonderfälle hinzu. Dann zeigt sich, ob das System nur beeindruckend antwortet oder tatsächlich belastbar arbeitet.
Was ist der häufigste Fehler bei RAG-Projekten im Mittelstand?
Der häufigste Fehler ist, ungeprüfte Dokumente einfach zu indexieren. Dadurch entsteht zwar schnell ein nutzbarer Prototyp, aber kein verlässliches Wissenssystem. Ohne Dokumentenqualität, Metadaten, Gültigkeit, Freigaben und Verantwortlichkeiten liefert RAG Antworten auf Basis eines Datenbestands, dem fachlich niemand vollständig vertraut.
Warum reicht RAG allein nicht für ein Company Brain?
RAG kann Informationen finden und Antworten aus Quellen formulieren. Ein Company Brain braucht zusätzlich Struktur, Pflege, Rollen, Versionierung, Freigaben, Prozesswissen und Feedback. RAG ist damit eher eine technische Komponente. Das Company Brain ist das organisatorische System, das Unternehmenswissen dauerhaft nutzbar macht.
Welche Daten eignen sich für ein RAG-System?
Geeignet sind geprüfte, aktuelle und fachlich relevante Inhalte: Prozesshandbücher, SOPs, technische Dokumentationen, Angebotsvorlagen, Wartungsprotokolle, gelöste Tickets, Checklisten und freigegebene interne Richtlinien. Weniger geeignet sind ungeordnete Dateiablagen, alte Chatverläufe, private Notizen oder Dokumente ohne Eigentümer und ohne klaren Gültigkeitsstatus.
Wie misst man die Qualität eines RAG-Systems?
Man misst RAG-Qualität nicht nur an schönen Antworten. Wichtig sind Trefferqualität, Quellenrelevanz, Aktualität, Antworttreue zum gefundenen Kontext, Umgang mit Unsicherheit und Wiederholbarkeit. Dafür braucht man reale Testfragen aus dem Betrieb und regelmäßige Auswertung, nicht nur spontane Tests während der Einführung.
Wann lohnt sich ein RAG-Projekt für ein mittelständisches Unternehmen?
Ein RAG-Projekt lohnt sich, wenn viele wiederkehrende Fragen auftreten, Wissen über Systeme verteilt ist und Mitarbeiter regelmäßig Zeit mit Suchen, Nachfragen oder Wiedererfinden verlieren. Besonders interessant sind Service, IT, Support, Vertrieb, technische Dokumentation, Wartung, Qualitätsmanagement und regulierte Abläufe mit vielen internen Quellen.
Welche Rolle spielt Datenschutz bei RAG?
Datenschutz ist zentral, weil RAG-Systeme häufig interne Dokumente, Kundeninformationen oder personenbezogene Daten durchsuchen. Entscheidend sind Zugriffskontrolle, Protokollierung, Datenminimierung, Hosting, Berechtigungskonzepte und klare Regeln für vertrauliche Inhalte. Ohne diese Grundlage wird ein RAG-System im Unternehmen oft nicht freigegeben.
Wie startet man ein RAG-Projekt richtig?
Der beste Start ist ein enger Anwendungsfall mit echten Arbeitsfragen. Danach werden Quellen geprüft, Rollen geklärt, Testfragen erstellt und Qualitätskriterien definiert. Erst dann sollte die technische Architektur festgelegt werden. So entsteht kein isolierter Chatbot, sondern ein kontrollierbares Wissenssystem mit messbarem Nutzen.
