- Über Nutzen oder Misserfolg entscheidet die Datenbasis, nicht das Modell.
- Nicht jeder Bestand braucht RAG: Gut strukturierte Doku bedient eine direkte Suche oft besser.
- Ein RAG-System ist nur so sicher wie die Zugriffsrechte, die es respektiert.
- RAG ist ein laufender Betrieb, kein Projektabschluss.
In vielen Unternehmen liegt das Wissen verstreut: in Dokumentenablagen, alten Angeboten, Wikis und Postfächern. Die Idee, einen internen Assistenten darauf anzusetzen, der Fragen in normaler Sprache beantwortet, ist naheliegend. Genauso naheliegend sind die Bedenken: Wer darf was sehen? Bleiben die Daten im Haus? Und woher weiß ich, dass die Antwort stimmt?
Die Technik dahinter heißt meist RAG. Bevor Sie ein erstes Projekt starten, lohnt sich eine nüchterne Vorab-Einordnung, denn über Erfolg oder Misserfolg entscheidet selten das Sprachmodell und fast immer das, was darunter liegt. Ich habe diese Einordnung gerade selbst durchlaufen, mit einem Ergebnis, das in vielen RAG-Artikeln fehlt: Ein Teil des Wissens braucht gar kein RAG.
Was RAG für Unternehmen wirklich bedeutet
RAG steht für Retrieval Augmented Generation. Vereinfacht: Das Sprachmodell bekommt bei jeder Anfrage passende Passagen aus Ihrer eigenen Wissensbasis mitgeliefert und formuliert die Antwort auf dieser Grundlage.
Die entscheidende Konsequenz: Ein RAG-System ist nur so gut wie das Wissen dahinter und nur so sicher wie die Zugriffsrechte, die es respektiert. Die Qualität der Antworten hängt an der Datenbasis, nicht an einem cleveren Prompt.
Die Frage vor der Frage: Brauchen Sie überhaupt RAG?
Ein Schritt wird oft übersprungen: Braucht der Bestand überhaupt einen semantischen Index, oder beantwortet eine direkte Suche die Fragen besser? Drei Kriterien entscheiden das.
Die Größe: Ein Bestand, der sich in Sekunden vollständig durchsuchen lässt, braucht keinen Index. Die Struktur: Gut benannte, gegliederte Dokumente findet eine Stichwortsuche zuverlässig, und sie ist nachvollziehbarer als ein Vektor-Index. Der Zugriffsweg: Arbeitet ohnehin ein KI-Agent direkt auf der Ablage, sucht er wie ein Mensch, nur schneller: lesen, verwerfen, weitersuchen.
Dass das keine Randmeinung ist, zeigt ausgerechnet ein KI-Hersteller: Anthropic testete für sein Entwickler-Werkzeug Claude Code einen RAG-Ansatz und entschied sich dagegen, weil die agentische Suche in den eigenen Tests besser abschnitt und veraltete Indizes vermeidet (so Claude-Code-Erfinder Boris Cherny; die Begründung liefert der Anthropic-Engineering-Blog).
Umgekehrt: Sobald ein Bestand groß, heterogen und unstrukturiert ist oder die Frage andere Worte benutzt als das Dokument, scheitert die direkte Suche. Dort beginnt der RAG-Fall.
Wann sich ein internes Wissenssystem eignet
Nicht jeder Wissensbestand ist ein guter Kandidat. Die Matrix zeigt, ob ein Bereich reif ist, welche Rechtefrage zuerst zu klären ist und welche Betriebsaufgabe daran hängt.
| Wissensbestand | Eignung für RAG | Zuerst zu klärende Rechtefrage | Laufende Betriebsaufgabe |
|---|---|---|---|
| Technische Dokumentation | hoch, wenn gepflegt | Wer darf welche Bauteile/Projekte sehen? | Veraltete Stände aussortieren |
| Angebote und Verträge | mittel bis hoch | Vertraulichkeit, Mandanten- und Kundentrennung | Abgelaufene Dokumente kennzeichnen |
| E-Mail-Archive | niedrig | Personenbezug, Betriebsrat, Aufbewahrung | kaum kuratierbar, hoher Rauschanteil |
| Wiki / Confluence | hoch, wenn aktuell | Rollen- und Bereichsrechte spiegeln | verwaiste Seiten erkennen |
| Personalakten | ungeeignet | besonders schützenswerte Daten | nicht ohne klare Rechtsgrundlage |
Die Lesart: Wo die Datenbasis gepflegt ist und sich Rechte sauber abbilden lassen, trägt ein Wissenssystem früh. Wo der Bestand unstrukturiert, veraltet oder hochsensibel ist, beginnt das Projekt mit Aufräumen, nicht mit Technik. Und bei kleinen, gut strukturierten Beständen gehört der Gegencheck aus dem vorigen Abschnitt dazu.
Wie ich die Frage für mich selbst beantwortet habe
Mein Dokumentenbestand wächst täglich: Verträge, Rechnungen und Kundendossiers als PDF auf der einen Seite, eine strukturierte, konsequent benannte Wissensbasis auf der anderen.
Das Ergebnis war ein Split, kein Entweder-oder. Für die strukturierte Wissensbasis habe ich mich gegen einen Vektor-Index entschieden: Sie ist überschaubar genug, dass die direkte Suche jede Frage beantwortet, ein Index wäre die schlechtere Kopie einer Fähigkeit, die schon da ist. Bei den unstrukturierten PDFs fiel sie andersherum aus, denn dort scheitert die Stichwortsuche regelmäßig: Wer nach einer Vereinbarung sucht, benutzt selten dieselben Worte wie der Vertrag.
Zwei Randbedingungen prägten die Entscheidung: Alles läuft lokal, weil Finanz- und Personendaten meine Systeme nicht verlassen dürfen. Gebaut wird stufenweise: erst klein und messbar, dann nur Ausbaustufen mit belegtem Nutzen.
Zur Ehrlichkeit gehört: Mein Bestand ist klein. Bei zehn Jahren Wiki-Historie und Dutzenden Ablagen kippt die Abwägung schneller Richtung RAG. Die Prüfung selbst bleibt dieselbe.
Die Rechte- und Datenschutzfrage zuerst
Der häufigste vermeidbare Fehler ist, das Rechtekonzept ans Ende zu schieben. Ein Assistent, der Quellen zusammenführt, kann Wissen sichtbar machen, das einzelne Mitarbeitende nie gebündelt sehen sollten.
Die Zugriffsrechte aus den Quellsystemen müssen sich deshalb im Assistenten wiederfinden, nicht erst nachträglich. Für deutsche Unternehmen kommen Datenhaltung, Nachvollziehbarkeit und Quellenangabe hinzu. RAG wird hierzulande zu Recht als Compliance-Thema gelesen; ein Bezug zu DSGVO und EU AI Act gehört dazu, ohne Panikmache und ohne ihn zu überspringen.
Warum RAG ein Betrieb ist, kein Projektabschluss
Ein RAG-System ist kein Produkt, das man einmal aufsetzt, sondern ein laufender Betrieb. Wissen veraltet, Dokumente kommen hinzu, Rechte ändern sich, und die Qualität der Antworten driftet mit der Pflege der Quelle.
Daraus folgt eine Frage, die mindestens so wichtig ist wie die Technik: Wer pflegt die Wissensbasis und verantwortet die Quellen? Ohne klare Zuständigkeit verfällt ein anfangs guter Assistent leise. Und der größere Kostenposten ist der laufende Betrieb, nicht die Einführung.
Ein sinnvoller erster Schritt
Statt alles auf einmal anzubinden, bewährt sich ein abgegrenzter erster Anwendungsfall. Drei Muster aus der Praxis:
- Ein Assistent für die technische Dokumentation, der Zugriffsrechte respektiert und Antworten mit Quellenverweis liefert. Geeignet, weil der Bestand strukturiert und der Nutzen messbar ist.
- Die Angebots- und Vertragssuche im Mittelstand als enger Pilot. Wertvoll, sobald Mandanten- und Kundentrennung sauber abgebildet ist, sonst riskant.
- Der typische Fehlschlag zur Abgrenzung: Ein Assistent auf einer ungepflegten Wissensbasis antwortet souverän und oft falsch, weil veraltete Stände gleichberechtigt mitgelesen werden. Kein Modellproblem, ein Datenproblem.
Ein enger Pilot mit klarer Rechtegrenze und einer benannten Pflegeverantwortung sagt mehr über die Tragfähigkeit aus als jede Demo.
Fazit: was jetzt zu klären ist
Bevor Sie in ein RAG-Projekt einsteigen, sind vier Dinge wichtiger als die Werkzeugwahl: Braucht der Bestand überhaupt einen semantischen Index? Ist die Wissensbasis gepflegt? Lassen sich die Zugriffsrechte sauber abbilden? Und gibt es jemanden, der den Betrieb verantwortet? Wer diese Fragen ehrlich beantwortet, weiß schon vor dem ersten Prototyp, ob das Vorhaben trägt.
RAG ist dann kein Versprechen, sondern ein gut beherrschbares Werkzeug, vorausgesetzt, man behandelt es als das, was es ist: ein Betrieb, kein Projektabschluss. Wenn Sie einschätzen wollen, ob ein internes Wissenssystem in Ihrem Fall trägt, können Sie das Vorhaben unverbindlich einordnen lassen. Die technische Sicht auf KI-Funktionen in bestehender Software: KI-gestützte Softwareentwicklung. Weiterführend im selben Themenfeld: KI-Agenten in Produktion: Verlässlichkeit durch Evals und Tests.
