RAG für Unternehmen: Firmen-Chatbot auf eigenen Daten

Gartner rechnete Anfang 2025 damit, dass bis Ende 2026 rund 60 Prozent aller KI-Vorhaben aufgegeben werden, denen keine KI-taugliche Datenbasis zugrunde liegt. In derselben Mitteilung steht ein Befragungsergebnis: 63 Prozent der weltweit befragten Datenverantwortlichen sagten, sie hätten kein passendes Datenmanagement für KI oder wüssten nicht, ob sie eins haben. Eine DACH-Zahl ist das nicht. Die Richtung deckt sich aber mit dem, was uns in Projekten begegnet. Genau dieser Punkt entscheidet auch darüber, ob RAG im Unternehmen funktioniert oder eine teure Enttäuschung wird.

Retrieval Augmented Generation ist der Standardweg, wenn ein Sprachmodell auf deinen eigenen Unterlagen antworten soll. Die Technik ist inzwischen unspektakulär und in wenigen Wochen aufgebaut. Der Aufwand liegt woanders, und darüber redet kaum ein Anbieter im Erstgespräch.

Was bei RAG im Unternehmen tatsächlich passiert

Vier Schritte, mehr ist es nicht. Erstens werden deine Dokumente in Abschnitte zerlegt, die sogenannten Chunks. Zweitens wandelt ein Embedding-Modell jeden Abschnitt in eine Zahlenreihe um, die seine Bedeutung abbildet. Drittens sucht das System bei einer Frage die Abschnitte mit der ähnlichsten Bedeutung heraus, meist die besten fünf bis zehn. Viertens bekommt das Sprachmodell diese Abschnitte zusammen mit der Frage vorgelegt und formuliert daraus die Antwort.

Der letzte Satz ist der wichtige. Das Modell weiß nichts über deine Firma. Es formuliert aus dem, was der Suchschritt ihm hinlegt. Liefert die Suche den falschen Abschnitt, formuliert das Modell eine sprachlich einwandfreie falsche Antwort. Das Fraunhofer IESE bringt es in seinem Blog auf den Punkt: RAG stellt einem Sprachmodell mittels einer guten Suche Wissensquellen zur Seite. Die Betonung liegt auf “guter Suche”, nicht auf “Sprachmodell”.

Deshalb ist die Modellwahl beim Aufbau die unwichtigste Entscheidung. Ein besseres Modell macht aus einem falschen Ausschnitt keine richtige Antwort.

Welche Datenquellen taugen und welche nicht

Gut geeignet: ein gepflegtes Wiki oder Handbuch mit Überschriftenstruktur, Produktdaten aus PIM oder ERP, freigegebene Angebots- und Vertragsvorlagen, Support-Tickets mit Lösungstext. Gemeinsames Merkmal: Es gibt jeweils eine gültige Fassung, und jemand ist dafür zuständig.

Nicht geeignet: das über Jahre gewachsene Netzlaufwerk. Dort liegen Preisliste_final, Preisliste_final_2, Preisliste_final_NEU und drei Entwürfe, die nie gültig waren. Ein Mensch erkennt am Kontext, welche zählt. Der Suchschritt tut das nicht, er kennt nur Bedeutungsähnlichkeit, und alle vier Dateien handeln von Preisen.

Ebenfalls nicht geeignet: gescannte PDFs ohne Texterkennung. Was für dich wie ein Dokument aussieht, ist technisch ein Bild. Ohne vorgeschaltete OCR landet davon kein Wort im Index. Der Anteil solcher Dateien in deutschen Firmenablagen ist erfahrungsgemäß deutlich höher, als die IT vermutet. Betroffen ist vor allem alles, was einmal unterschrieben und wieder eingescannt wurde: Lieferantenverträge, Prüfprotokolle, Abnahmen.

Prüf das vor jedem Projekt, nicht danach. Eine Stichprobe von 50 Dateien aus dem Zielordner reicht: Text markierbar oder nicht, Gültigkeitsdatum erkennbar oder nicht.

Chunking und Metadaten entscheiden über die Trefferqualität

Chunking klingt nach einer technischen Nebensache und ist der Hebel mit der größten Wirkung. Zerlegst du zu grob, kommt bei jeder Frage ein halbes Kapitel Kontext mit und die eigentliche Aussage geht darin unter. Zerlegst du zu fein, verlierst du den Zusammenhang.

Der teuerste Zerlegungsfehler in der Praxis betrifft Tabellen. Wird eine Preistabelle mitten durchgeschnitten, landet die Kopfzeile mit “gültig ab 01.01.2026” im einen Abschnitt und die Zahlen im anderen. Der Chatbot findet die Zahlen, sieht die Gültigkeit nicht und nennt sie als aktuelle Preise. Tabellen und Listen gehören deshalb als Ganzes in einen Abschnitt, notfalls mit wiederholter Kopfzeile.

Metadaten sind die zweite Hälfte der Arbeit. Jeder Abschnitt braucht mindestens Quelldatei, Änderungsdatum, Gültigkeit und Zuständigkeit als Zusatzinformation. Damit kannst du beim Suchen filtern statt nur ähnlich zu raten, und die Antwort kann sagen, wie alt ihre Grundlage ist. Das Fraunhofer IESE berichtet zusätzlich von guten Erfahrungen mit einer hybriden Suche, also semantischer Suche kombiniert mit klassischer Stichwortsuche. Der Grund liegt aus unserer Sicht bei Artikelnummern, Kürzeln und Eigennamen: Die findet reine Bedeutungsähnlichkeit oft nicht.

Berechtigungen sind der am häufigsten übersehene Punkt

Ein RAG-System bricht Informationssilos auf. Das ist der Nutzen und gleichzeitig das Risiko. Was der Fragende nicht sehen darf, darf der Chatbot nicht ausgeben, und das ist keine Einstellung, die man am Ende noch schnell setzt.

Die entscheidende Regel: Berechtigungen werden beim Abruf geprüft, nicht beim Befüllen des Index. Wer nur einmal beim Indexieren filtert, hat ein System, das jede spätere Rechteänderung ignoriert. Praktisch heißt das, die Zugriffsrechte des jeweiligen Nutzers laufen als Filter in jede Suchanfrage mit ein.

Das BSI beschreibt in seinem Papier zu generativen KI-Modellen genau diesen Weg: Informationen werden im Rahmen der Suche über ein Rechte- und Rollenkonzept selektiert. Und es zieht eine Grenze, die in der Praxis ständig überschritten wird. Von einer Implementierung des Rechte- und Rollensystems über textuelle Instruktionen sei wegen der Angreifbarkeit abzusehen. Im Klartext: Ein Satz im Systemprompt, der dem Modell verbietet, Gehaltsdaten herauszugeben, ist kein Berechtigungskonzept. Das ist eine Bitte.

Wie real das Problem ist, siehst du daran, dass Microsoft in der eigenen Bereitstellungsanleitung für Microsoft Copilot die erste von drei Säulen darauf verwendet, “Oversharing” zu beheben. Der Assistent erzeugt das Problem nicht. Er macht sichtbar, dass eine SharePoint-Bibliothek vor vier Jahren für “alle Mitarbeiter” freigegeben wurde und seitdem Gehaltsdaten enthält. Die zweite BSI-Empfehlung dazu ist schnell umgesetzt: die Zugriffs- und Ausführungsrechte einer LLM-basierten Anwendung auf das notwendige Minimum beschränken.

Ab wann sich RAG rechnet

Hier die Schwelle, und zwar als Erfahrungswert aus unseren Projekten, nicht als Erhebung. Der Aufbau eines produktionsreifen RAG-Systems liegt bei 8 bis 15 Entwicklertagen, inklusive Datenaufbereitung, Berechtigungsmodell und Evaluation. Bei einem Tagessatz um 1.000 Euro sind das 8.000 bis 15.000 Euro einmalig. Dazu kommt laufende Pflege von rund einem halben Tag im Monat, also etwa 6.000 Euro im Jahr.

Auf der Nutzenseite: Suchen 20 Leute zweimal pro Woche etwas, das sie mit dem System zehn Minuten schneller finden, sind das bei 45 Arbeitswochen rund 300 Stunden im Jahr. Zu 50 Euro internen Stundenkosten also 15.000 Euro. Abzüglich Pflege bleiben 9.000 Euro. Der Aufbau trägt sich damit nach einem bis zwei Jahren, je nach Zuschnitt. Bei fünf Leuten sind es 3.750 Euro Nutzen gegen 6.000 Euro Pflege. Das rechnet sich nie.

Die Regel: Ab rund 500 aktiv gepflegten Dokumenten und mindestens 15 bis 20 Personen, die regelmäßig darin suchen, lohnt sich RAG. Darunter nicht, weil die laufende Pflege des Index die eingesparte Suchzeit auffrisst.

Und miss den Nutzen, sonst diskutierst du nach sechs Monaten über Gefühle. Zwei Zahlen reichen: Sammle 30 echte Fragen aus dem Tagesgeschäft mit bekannter richtiger Antwort und zähle, in wie vielen Fällen die richtige Quelle unter den gelieferten Abschnitten war. Unter 80 Prozent ist das System nicht produktionsreif. Für den fortlaufenden Betrieb gibt es dafür fertige Werkzeuge, Fraunhofer nennt etwa das Open-Source-Projekt RAGAS.

Wann RAG die falsche Antwort ist

Drei Situationen, in denen wir davon abraten.

Unter etwa 50 Dokumenten. Dann ist die Auswahl der richtigen Datei noch von Hand machbar. Ein Custom GPT mit hochgeladenen Dateien oder schlicht eine bessere Volltextsuche liefert dasselbe Ergebnis in zwei Tagen statt in zwei Wochen. Diese Vorstufen stehen im Reifegradmodell für ChatGPT im Unternehmen, in dem RAG erst Stufe 3 ist.

Wenn sich die Daten täglich ändern. Bestände, Preise, Verfügbarkeiten, Auftragsstatus. Der Index läuft dem echten Stand immer hinterher, und eine veraltete Antwort mit Quellenangabe ist schlimmer als gar keine. Solche Fragen gehören per Schnittstelle direkt an ERP oder Shop, nicht in einen Vektorspeicher.

Wenn die eigentliche Frage eine Berechtigungsfrage ist. Wenn niemand sagen kann, wer welche Unterlagen sehen darf, löst RAG das nicht. Es macht die Unklarheit nur schneller abfragbar. Erst die Rechte klären, dann bauen.

Der teuerste Fehler zieht sich durch alle drei Fälle: Der Chatbot liefert die alte Preisliste mit ordentlicher Quellenangabe, weil sie nie als ungültig gekennzeichnet und nie archiviert wurde. Die Quellenangabe erzeugt Vertrauen, keiner prüft nach, und das Angebot geht mit den Preisen von vorletztem Jahr raus. Aufräumen kommt vor Anbinden, immer.

Was du jetzt tun kannst

Fang nicht mit der Technik an, sondern mit einer Zählung. Wie viele Dokumente sind wirklich gültig und gepflegt? Wie viele davon haben eine Textebene? Wer darf was sehen? Diese drei Antworten entscheiden über Erfolg oder Misserfolg des Projekts, lange bevor jemand ein Modell auswählt.

Wenn du wissen willst, ob dein Bestand trägt, schau dir an, wie wir als KI-Agentur solche Systeme aufsetzen, und wo die Grenzen eines klassischen KI-Chatbots liegen. Oder buch dir eine Fokus-Session: 60 Minuten, in denen wir uns deine Ablage ansehen und dir sagen, ob sie für RAG trägt oder vorher aufgeräumt gehört.