RAG-Systeme für Unternehmen: Wissen sicher mit KI nutzen

Viele Unternehmen haben kein Wissensproblem. Sie haben ein Zugriffsproblem.

Die Informationen existieren bereits: in Handbüchern, Netzlaufwerken, Tickets, Wikis, PDF-Dateien, Projektordnern und E-Mails. Trotzdem verbringen Mitarbeiter viel Zeit damit, die richtige Version zu finden oder eine Person zu fragen, die „weiß, wo es steht“.

Ein RAG-System kann diesen Zugriff deutlich vereinfachen. RAG steht für Retrieval-Augmented Generation: Das System sucht zunächst passende Abschnitte in freigegebenen Quellen und übergibt sie anschließend an ein Sprachmodell, das daraus eine Antwort formuliert. Der Unterschied zu einem allgemeinen Chatbot ist, dass die Antwort auf den eigenen Unternehmensinhalten beruhen soll und nicht auf dem Trainingswissen des Modells.

Dieser Beitrag beschreibt die Architektur- und Datenseite eines solchen Systems: wie Dokumente aufbereitet und zerlegt werden, warum die Suche wichtiger ist als die Modellwahl, wie Berechtigungen bis in den Abruf reichen, wie man vor dem Produktivstart prüft — und wo die Grenzen des Verfahrens liegen.

Ein RAG-System besteht aus zwei Strecken, nicht aus einem Chatfenster

Sichtbar ist meist nur die Eingabezeile. Technisch bestehen RAG-Systeme aus zwei getrennten Verarbeitungswegen, die zu unterschiedlichen Zeitpunkten laufen.

Die Indexierungsstrecke läuft im Hintergrund, meist nach Zeitplan: Quellsysteme anbinden, Text und Struktur aus den Dateien extrahieren, Dokumente in Abschnitte zerlegen, jeden Abschnitt mit Metadaten anreichern, in Vektoren umrechnen und in einen Index schreiben.

Die Abfragestrecke läuft pro Frage in Sekundenbruchteilen: Frage entgegennehmen, gegebenenfalls umformulieren oder aufteilen, Berechtigungs- und Metadatenfilter anwenden, Kandidaten suchen, die Treffer neu ordnen, den besten Kontext zusammenstellen, das Modell antworten lassen, Quellen ausweisen.

Beide Strecken laufen zu unterschiedlichen Zeitpunkten. Ein Qualitätsproblem entsteht fast immer oben und fällt unten auf.

Diese Unterscheidung ist mehr als eine Beschreibung. Die meisten Qualitätsprobleme entstehen in der Indexierungsstrecke, werden aber in der Abfragestrecke bemerkt — und dort dann mit dem falschen Werkzeug bekämpft. Wenn eine Antwort unbrauchbar ist, lautet die erste Frage nicht „Welches Modell nutzen wir?“, sondern: Waren die richtigen Abschnitte überhaupt im Kontext? Diese Frage ist beantwortbar, wenn das System protokolliert, welche Abschnitte es an das Modell übergeben hat.

Unternehmensdaten sind selten indexreif

Wer alle Dateien ungeprüft in ein System lädt, digitalisiert nicht das Wissen, sondern auch die vorhandene Unordnung. Typische Befunde:

mehrere Versionen desselben Dokuments, ohne erkennbare Verbindlichkeit
veraltete Anweisungen, die formal nie zurückgezogen wurden
eingescannte PDFs ohne brauchbare Textebene
Tabellen und Preislisten, deren Bedeutung an der Spaltenüberschrift hängt
uneinheitliche Bezeichnungen für dieselbe Sache
fehlende Metadaten zu Bereich, Stand und Gültigkeit
vertrauliche Inhalte ohne klare Rechtezuordnung
Dokumente, die mehrere Themen vermischen
Aussagen, die nur im Zusammenhang eines Projekts verständlich sind

Vor der technischen Umsetzung gehören die Quellen deshalb bewertet, und zwar entlang von vier Fragen.

Relevanz. Welche Fragen soll das System beantworten? Ein Assistent für den technischen Support braucht andere Quellen als einer für Personalthemen. Ein gemeinsamer Index für beides erzeugt vor allem Rauschen.

Verbindlichkeit. Welche Fassung gilt? Wenn eine Richtlinie geändert wird, muss die alte aus dem Index verschwinden oder als überholt markiert sein. Solange zwei Fassungen gleichberechtigt im Index liegen, entscheidet der Zufall der Suche, welche Auskunft ein Mitarbeiter bekommt.

Qualität. Sind die Inhalte eindeutig, vollständig und ohne Insiderwissen verständlich? Widersprüchliche Dokumente führen zu widersprüchlichen Antworten — nur formuliert das System sie dann in einem gleichbleibend selbstsicheren Ton.

Rechtezuordnung. Ist für jede Quelle bekannt, wer sie sehen darf? Diese Frage muss vor dem ersten Index beantwortet sein, nicht danach.

Es ist normal, dass diese Bewertung mehr Zeit kostet als der technische Aufbau. Sie ist auch die Arbeit, die niemand ersetzen kann: Ob eine Aussage in einem Dokument fachlich noch stimmt, kann keine Software beurteilen.

Wie Dokumente zerlegt werden, entscheidet darüber, was überhaupt auffindbar ist

Ein Sprachmodell bekommt nie ein ganzes Handbuch, sondern einzelne Abschnitte. Die Zerlegung („Chunking“) ist deshalb keine Formatfrage, sondern legt fest, welche Information zusammen gefunden werden kann und welche auseinandergerissen wird.

Der grundlegende Zielkonflikt: Kleine Abschnitte treffen genauer, verlieren aber den Zusammenhang. Ein Satz wie „Dies gilt nicht für Bestandskunden“ ist ohne den vorangehenden Absatz wertlos und im schlimmsten Fall irreführend. Große Abschnitte transportieren den Zusammenhang, verwässern aber die Suche: Ein Kapitel über zehn Themen liegt zu jedem dieser Themen nur mittelmäßig nah an der Frage und verdrängt im Kontextfenster präzisere Treffer.

Was in der Praxis hilft:

An der Dokumentstruktur entlang zerlegen, nicht nach fester Zeichenzahl. Überschriften, Abschnitte, Listen und Tabellen sind bereits eine Gliederung, die jemand mit Absicht angelegt hat.
Den Überschriftenpfad in jeden Abschnitt schreiben. Ein Abschnitt, der mit „Handbuch Anlage B › Wartung › Halbjährliche Prüfung“ beginnt, ist auffindbar und interpretierbar; derselbe Text ohne diese Zeile ist es oft nicht.
Überlappung sparsam einsetzen. Etwas Überlappung verhindert, dass ein Satz genau an der Schnittstelle zerrissen wird. Viel Überlappung bläht den Index auf und liefert mehrfach denselben Treffer.
Tabellen gesondert behandeln. Eine über zwei Abschnitte zerschnittene Tabelle produziert Zeilen ohne Spaltenüberschriften — eine zuverlässige Quelle falscher Zahlen. Tabellen gehören entweder als Ganzes in einen Abschnitt oder in eine strukturierte Ablage, die direkt abgefragt wird.
Gescannte Dokumente vor der Indexierung durch eine Texterkennung schicken und das Ergebnis stichprobenartig prüfen. Ein Index über fehlerhaft erkannten Text ist schlechter als kein Index, weil er Treffer liefert.
Regel und Ausnahme zusammenhalten. Wenn die Ausnahme drei Seiten nach der Regel steht, findet die Suche typischerweise nur eine von beiden. Solche Stellen sind ein Argument dafür, das Quelldokument zu überarbeiten statt die Zerlegung zu verfeinern.

Bei jedem Abschnitt gehören Metadaten mit in den Index: Bereich, Dokumenttyp, Stand und Gültigkeit, Version, Sprache, Zugriffsgruppe — und ein stabiler Verweis auf das Originaldokument samt Fundstelle. Der letzte Punkt wird oft übersehen und ist später nicht nachrüstbar: Nur wenn ein Abschnitt weiß, woher er stammt, kann das System seine Quelle nennen und der Nutzer sie öffnen. Quellenangaben sind damit eine Entscheidung im Datenmodell und keine Funktion der Oberfläche.

Die Trefferqualität entscheidet stärker als die Modellwahl

Wenn das System die falschen Abschnitte abruft, kann auch ein sehr leistungsfähiges Modell keine verlässliche Antwort erzeugen. Es wird aus dem vorhandenen Kontext eine plausible Antwort formulieren — und ein besseres Modell formuliert eine falsche Antwort überzeugender. Die Modellwahl verbessert Sprache, Struktur und Regeltreue. Sie ersetzt keine Information, die nie im Kontext war.

Praktisch bedeutet das, dass die Suche konfiguriert und gemessen werden muss:

Hybrid suchen. Semantische Suche findet sinnverwandte Formulierungen, versagt aber häufig bei Artikelnummern, Kürzeln, Eigennamen und exakten Paragrafen. Die klassische Schlagwortsuche kann genau das. Die Kombination beider Verfahren ist in Unternehmensbeständen meist deutlich robuster als eines allein. Der BEIR-Benchmark zeigte dazu, dass das klassische BM25-Verfahren ein erstaunlich starker Ausgangspunkt bleibt und dichte Vektormodelle außerhalb ihrer Trainingsdomäne oft schlechter abschneiden als erwartet — ein Grund, die Suche an den eigenen Dokumenten zu testen statt sie aus einer Rangliste zu übernehmen.
Treffer neu ordnen. Ein Re-Ranker bewertet die 20 bis 50 Kandidaten aus der ersten Suche noch einmal gegen die konkrete Frage und sortiert sie um. Das ist nach der Zerlegung häufig der zweite große Hebel, weil es die Präzision im Kontextfenster erhöht, ohne den Index zu ändern.
Nach Metadaten filtern und aktuelle Fassungen bevorzugen, statt sich darauf zu verlassen, dass das aktuellere Dokument zufällig ähnlicher formuliert ist.
Komplexe Fragen aufteilen oder umformulieren. Eine Frage nach zwei Sachverhalten liefert oft nur zu einem davon Treffer. Beides kostet zusätzliche Modellaufrufe, also Zeit und Geld — eine bewusste Abwägung, keine Selbstverständlichkeit.
Nicht mehr Kontext ist besser. Ein größeres Kontextfenster verführt dazu, einfach 30 Abschnitte zu übergeben. Zusätzliche, nur mittelmäßig passende Abschnitte erhöhen jedoch das Risiko, dass das Modell die falsche Stelle verwendet, und sie erhöhen Kosten und Antwortzeit. Wie empfindlich ein System auf solches Rauschen reagiert, lässt sich messen.

Das Einbettungsmodell ist eine Architekturentscheidung, keine Einstellung

Das Modell, das Text in Vektoren umrechnet, bestimmt, welche Formulierungen als ähnlich gelten. Drei Konsequenzen werden regelmäßig unterschätzt.

Deutsch und Fachsprache. Nicht jedes Einbettungsmodell arbeitet im Deutschen so gut wie im Englischen, und branchenspezifische Abkürzungen, Typenbezeichnungen oder interne Projektnamen liegen selten in seinem Sprachraum. Genau für diese Fälle ist der lexikalische Teil der hybriden Suche zuständig.

Ein Wechsel bedeutet Neuaufbau. Vektoren verschiedener Modelle sind nicht miteinander vergleichbar. Wer das Einbettungsmodell tauscht, muss den gesamten Bestand neu einlesen und neu berechnen. Bei großen Beständen ist das ein planbarer, aber realer Kosten- und Zeitposten — und ein Argument dafür, den Rohtext samt Metadaten getrennt vom Vektorindex aufzubewahren, damit ein Neuaufbau nicht wieder bei den Quellsystemen beginnt.

Wo gerechnet wird, ist eine Datenschutzfrage. Wird die Einbettung über einen externen Dienst erzeugt, verlässt jeder indexierte Textabschnitt einmal das Haus — nicht nur die später gestellten Fragen. Das ist bei der Bewertung der Architektur getrennt vom Antwortmodell zu betrachten.

Berechtigungen müssen bis in den Abruf reichen — und dort scheitern die meisten Projekte

Ein häufiger Fehler besteht darin, Dokumente aus allen Bereichen in einem gemeinsamen Index abzulegen und die Zugriffskontrolle erst in der Oberfläche umzusetzen. Das funktioniert im Demo-Betrieb und fällt spätestens dann auf, wenn jemand nach Gehältern, Kündigungen oder Angebotspreisen fragt.

Vorfiltern statt nachfiltern. Die Berechtigung des fragenden Nutzers muss als Filter in die Suchanfrage eingehen, nicht auf das Suchergebnis angewendet werden. Wer erst die besten zehn Abschnitte holt und danach entfernt, was der Nutzer nicht sehen darf, bekommt zwei Probleme: Die Antwort wird lückenhaft, weil unter den zehn Treffern keine erlaubten Abschnitte mehr übrig sind — und die verworfenen Inhalte waren bereits im Verarbeitungsweg.

Rechte gehören an den Abschnitt. Jeder indexierte Abschnitt trägt die Zugriffsgruppen seines Quelldokuments als Metadatum. Der Filter wird zur Abfragezeit aus der Identität des angemeldeten Nutzers aufgelöst. Das setzt voraus, dass das System den Nutzer kennt — ein anonymer Assistent kann keine differenzierten Rechte durchsetzen.

Rechte veralten. Berechtigungen ändern sich im Quellsystem: Ein Mitarbeiter wechselt die Abteilung, ein Ordner wird neu freigegeben, ein Dokument wird verschoben oder gelöscht. Wenn die Synchronisation nur Inhalte, aber keine Rechte abgleicht, bleibt der Index auf dem Stand des ersten Imports. Gelöschte Dokumente müssen aus dem Index verschwinden, nicht nur aus dem Quellsystem.

Der Indexdienst hat mehr Rechte als jeder Nutzer. Für den Import läuft in der Regel ein technisches Konto mit weitreichendem Lesezugriff. Genau deshalb darf die Antwortstrecke niemals mit den Rechten dieses Kontos arbeiten. Diese Trennung sauber zu halten, ist die eigentliche Ingenieursaufgabe im Berechtigungsmodell.

Sehr sensible Bestände gehören in einen eigenen Index — Personal-, Vertrags- oder Gesundheitsdaten getrennt von der allgemeinen Wissensbasis, mit eigener Zugriffsprüfung. Getrennte Bereiche sind unbequemer als ein Filterfeld, aber sie versagen nicht durch eine falsche Zeile Konfiguration.

Auch Metadaten verraten etwas. Ein Hinweis wie „3 weitere Treffer, kein Zugriff“ bestätigt die Existenz eines Dokuments. Ob das akzeptabel ist, ist eine bewusste Entscheidung.

Protokollieren, wer was gefragt und welche Abschnitte das System verwendet hat. Ohne dieses Protokoll ist ein Verdacht auf ungewollte Offenlegung im Nachhinein nicht überprüfbar. Zugleich ist das Protokoll selbst schutzbedürftig, weil es Fragen von Mitarbeitern enthält.

Nachträglich lässt sich ein Berechtigungsmodell nur mit hohem Aufwand einziehen, weil es Zerlegung, Metadaten und Index betrifft. Es gehört deshalb an den Anfang des Projekts — auch dann, wenn der Pilot zunächst nur öffentlich zugängliche Handbücher umfasst.

Ein indexiertes Dokument ist eine Eingabe, keine Anweisung

Alles, was im Index liegt, landet irgendwann im Kontextfenster eines Sprachmodells. Damit wird jedes indexierte Dokument zu einer Eingabe, die das Verhalten des Systems beeinflussen kann.

Das OWASP-Projekt zu Sicherheitsrisiken generativer KI führt Prompt Injection als Risiko LLM01 und unterscheidet ausdrücklich die indirekte Variante, bei der die Anweisung nicht vom Nutzer kommt, sondern aus einer Datei oder Webseite, die das System abruft. Als Beispielszenario nennt es genau den RAG-Fall: Ein Angreifer verändert ein Dokument in einer Ablage, die von einem RAG-System indexiert wird; sobald eine Anfrage diesen Inhalt zurückliefert, wirken die eingebetteten Anweisungen auf die Ausgabe.

Für die Architektur folgt daraus:

Abgerufener Text ist Datenmaterial, nicht Befehl. Systemregeln und abgerufener Inhalt gehören klar getrennt und als solche gekennzeichnet.
Ein reiner Wissensassistent sollte keine Werkzeuge mit Schreibrechten besitzen. Wer Auskunft und Handlung in einer Komponente bündelt, macht aus einem Textproblem ein Betriebsproblem.
Quellen, in die von außen geschrieben werden kann — geteilte Postfächer, Uploadordner, Lieferantenportale — sind gesondert zu bewerten, bevor sie in den Index gelangen.
Auffällige Ausgaben und die zugehörigen Abschnitte sollten protokolliert werden, damit ein manipuliertes Dokument auffindbar ist.

RAG reduziert falsche Antworten, es beseitigt sie nicht

Das ist die Aussage, die in Produktpräsentationen am häufigsten fehlt. RAG verankert die Antwort in konkreten Dokumenten und senkt dadurch die Wahrscheinlichkeit frei erfundener Inhalte deutlich. Es macht sie nicht unmöglich. Typische verbleibende Fehler:

Das Modell interpretiert eine Quelle falsch oder überdehnt sie.
Es verbindet Aussagen aus zwei Dokumenten, die nicht zusammengehören.
Es beantwortet eine mehrdeutige Frage zu bestimmt, statt nachzufragen.
Es übersieht eine Einschränkung, die im abgerufenen Abschnitt nicht mehr enthalten war.
Es gibt eine korrekte Quelle ungenau wieder.

Hinzu kommen Fragetypen, für die das Verfahren strukturell ungeeignet ist. Zählende und aggregierende Fragen („Wie viele Verträge laufen im dritten Quartal aus?“) beantwortet eine Ähnlichkeitssuche über Textabschnitte nicht zuverlässig — dafür ist eine Abfrage auf strukturierte Daten das richtige Werkzeug. Verneinende Fragen („Gibt es eine Regelung, die das verbietet?“) sind besonders heikel, weil das Fehlen eines Treffers nicht bedeutet, dass es die Regelung nicht gibt; es kann auch heißen, dass sie nicht indexiert oder anders formuliert ist. Vergleiche über viele Dokumente hinweg überschreiten schnell das, was in ein Kontextfenster passt.

Deshalb gehören Antwortregeln zur Architektur: nur auf Basis der bereitgestellten Quellen antworten, bei fehlender Grundlage ausdrücklich keine Antwort geben, Unsicherheit benennen, bei widersprüchlichen Quellen beide zeigen statt eine zu wählen, verwendete Quellen immer ausweisen und keine Aktionen auslösen. Solche Regeln sind allerdings eine Wahrscheinlichkeitssteuerung, keine Garantie — deshalb bleibt die Quellenangabe die wichtigste Sicherung, die ein Nutzer selbst prüfen kann.

Ohne Testfragenkatalog wissen Sie vor dem Start nichts über die Qualität

„Wir haben es kurz ausprobiert und es klang gut“ ist keine Prüfung. Vor dem produktiven Einsatz braucht das System einen festen Fragenkatalog, der gemeinsam mit dem Fachbereich entsteht und aufbewahrt wird. Er enthält:

häufige Standardfragen mit bekannter richtiger Antwort
seltene Sonderfälle
Fragen, auf die es bewusst keine Antwort in den Quellen gibt
mehrdeutige Formulierungen
Fragen, die mehrere Quellen zugleich benötigen
Fragen mit falscher Annahme im Fragetext
Fragen, die ein Nutzer mit eingeschränkten Rechten nicht beantwortet bekommen darf

Bewerten Sie dabei die beiden Strecken getrennt. Für den Abruf zählt, ob die passenden Abschnitte überhaupt gefunden wurden und wie viel Beiwerk mitkam; für die Erzeugung, ob die Antwort durch die gefundenen Abschnitte gedeckt ist und ob sie die Frage trifft. Ein Auswertungswerkzeug wie RAGAS bildet genau diese Trennung ab — Context Precision und Context Recall auf der Abrufseite, Faithfulness und Response Relevancy auf der Antwortseite, dazu ein Maß für die Empfindlichkeit gegenüber irrelevantem Kontext. Diese Zahlen sagen Ihnen, an welcher Stelle Sie ansetzen müssen, statt nur, dass etwas nicht stimmt.

Zwei Dinge machen den Katalog erst nützlich: Er wird vor der Optimierung festgelegt, damit nicht am Testfall entlang entwickelt wird. Und er wird nach jeder Änderung erneut durchlaufen — auch nach einer scheinbar kleinen, etwa einer geänderten Abschnittsgröße oder einem Modell-Update des Anbieters. Ohne diesen Regressionslauf merkt niemand, dass eine Verbesserung an einer Stelle eine Verschlechterung an drei anderen erzeugt hat.

Automatische Metriken unterstützen, ersetzen aber keine fachliche Durchsicht. Legen Sie außerdem vor dem Start fest, welches Ergebnis für eine Freigabe genügt. Ein Wert, der erst nach der Messung definiert wird, ist immer erreicht.

Ein Index veraltet schneller als die Dokumente dahinter

Ein RAG-System ist kein einmaliger Import. Der Betrieb braucht regelmäßige Synchronisierung, die Erkennung gelöschter und ersetzter Dokumente, ein Versionskonzept, Fehlerprotokolle für fehlgeschlagene Importe, Überwachung von Antwortzeiten und Kosten, eine Rückmeldemöglichkeit, die die zugehörigen Abschnitte mit erfasst, sowie einen Umgang mit Modell- und Komponentenupdates.

Der wichtigste Punkt ist organisatorisch: Es muss klar sein, wer für den Inhalt verantwortlich ist. Die IT kann ein Dokument technisch verfügbar machen, aber nicht entscheiden, ob seine fachliche Aussage noch stimmt. Fehlt diese Zuständigkeit, verfällt die Antwortqualität still, während die Technik einwandfrei arbeitet.

Bei lokal, Cloud oder hybrid geht es darum, welcher Text das Haus verlässt

Cloud-Modelle bieten hohe Qualität, einfache Skalierung und schnelle Verfügbarkeit. Zu prüfen sind Verarbeitungsort, Vertragsgrundlage, Aufbewahrung, Weiterverwendung der Eingaben und die Zugriffsmöglichkeiten des Anbieters.

Lokale Modelle geben mehr Kontrolle über die technische Umgebung. Dafür steigen die Anforderungen an Hardware, Betrieb, Aktualisierung und eigene Qualitätsprüfung — und die erreichbare Antwortqualität hängt stärker von der Sorgfalt bei Zerlegung und Suche ab.

Hybride Aufteilungen suchen und filtern intern und übergeben nur den notwendigen Kontext an einen externen Dienst. Das reduziert die Menge, hebt die Frage aber nicht auf: Der übergebene Kontext besteht aus Originalpassagen der eigenen Dokumente.

Die Entscheidung folgt nicht einem Lager, sondern der Sensibilität der Daten, der Nutzungsintensität, der geforderten Antwortqualität und dem Budget. Sinnvoll ist häufig eine Aufteilung nach Datenklassen statt eine Grundsatzentscheidung für das ganze Unternehmen.

Ab dem 2. August 2026 kommen die Transparenzpflichten aus Artikel 50 der KI-Verordnung (EU) 2024/1689 hinzu. Sie betreffen unter anderem die Erkennbarkeit, dass Nutzer mit einem KI-System interagieren, sowie die maschinenlesbare Kennzeichnung erzeugter Inhalte. Ob und in welcher Rolle Ihr konkretes System davon erfasst wird, ist eine Rechtsfrage und gehört in die juristische Prüfung. Technisch vorbereiten lässt es sich unabhängig davon — eine eindeutige Kennzeichnung in der Oberfläche, eine Markierung erzeugter Texte und eine Dokumentation der eingesetzten Komponenten sind ohnehin sinnvoll.

Wann RAG die falsche Antwort auf das Problem ist

RAG ist ungeeignet, wenn:

die relevanten Informationen noch gar nicht dokumentiert sind — dann fehlt die Grundlage, und ein Index über Lücken erzeugt nur höfliche Fehlanzeigen
die Daten überwiegend strukturiert in einer Datenbank liegen und exakt abgefragt werden können
feste Regeln eine eindeutige und reproduzierbare Antwort liefern müssen
die Quellen zu widersprüchlich oder zu veraltet sind, um sie kurzfristig zu bereinigen
eine ordentlich konfigurierte Volltextsuche das Bedürfnis bereits deckt
niemand dauerhaft für Pflege und Inhalt verantwortlich sein wird

Wenn Ihre häufigsten Fragen sich auf eine überschaubare Zahl von Sachverhalten zurückführen lassen, ist eine gepflegte, gut strukturierte Wissensseite die schnellere und billigere Maßnahme — und dafür brauchen Sie kein KI-Projekt. Sie ist zugleich die beste Vorbereitung: Was für Menschen gut lesbar strukturiert ist, ist auch für ein RAG-System gut zerlegbar.

Eine tragfähige Reihenfolge für den Projektstart

Einen klar abgegrenzten Wissensbereich auswählen, nicht das gesamte Unternehmen.
Die tatsächlich gestellten Fragen sammeln — aus Tickets, Postfächern und Rückfragen an Kollegen.
Quellen benennen und für jede Quelle festlegen, wer inhaltlich verantwortlich ist.
Das Zugriffsmodell entwerfen, bevor der erste Index entsteht.
Einen kleinen Pilotindex aufbauen und Zerlegung und Metadaten daran erproben.
Den Fragenkatalog aufstellen und den Ausgangsstand messen.
Gezielt an Zerlegung, Filtern und Neuordnung arbeiten und nach jeder Änderung erneut messen.
Erst danach weitere Quellen aufnehmen — jede zusätzliche Quelle mit eigener Rechtezuordnung.

Nachtrag vom 3. August 2026

Die oben angekündigten Transparenzpflichten nach Artikel 50 der KI-Verordnung gelten seit dem 2. August 2026. Zu diesem Datum wurde die Verordnung allgemein anwendbar; die Verpflichtungen für Hochrisikosysteme nach Anhang III wurden dagegen durch den sogenannten AI Omnibus, der am 27. Juli 2026 in Kraft trat, auf den 2. Dezember 2027 verschoben. Am 10. Juni 2026 hat die Europäische Kommission zudem den finalen Code of Practice on Transparency of AI-generated Content veröffentlicht, den sie als geeignetes freiwilliges Instrument zum Nachweis der Einhaltung bezeichnet.

Für den Aufbau eines internen Wissensassistenten ändert das nichts an der Architektur, wohl aber am Zeitpunkt: Kennzeichnung und Dokumentation sind keine spätere Ausbaustufe mehr. Eine verbindliche rechtliche Einordnung Ihres Systems nehmen wir nicht vor.

Die Qualität entsteht vor dem ersten Prompt

Ein RAG-System ist keine magische Schicht über ungeordneten Dateien. Es ist ein Datenprojekt mit einem Sprachmodell am Ende der Kette.

Die Qualität entsteht durch verbindliche Quellen, saubere Zerlegung, aussagekräftige Metadaten, eine getestete Suche, ein Berechtigungsmodell, das bis in den Abruf reicht, und eine Prüfung, die nach jeder Änderung wiederholt wird. Das Sprachmodell ist wichtig — aber es ist selten der Teil, an dem ein Projekt scheitert.

Handlungsaufruf

Sie möchten internes Wissen zuverlässig auffindbar machen?
TakFlow unterstützt bei der Bewertung der Quellen, der Zerlegung und Anreicherung der Dokumente, dem Zugriffsmodell, der Architektur und der Evaluation vor dem Produktivstart. Wenn sich zeigt, dass eine bessere Suche oder eine aufgeräumte Wissensbasis Ihr Problem schneller löst, sagen wir Ihnen das.

RAG-Projekt besprechen

Weiterführend: Dokumenten- und Wissensverarbeitung mit KI · KI-Agenten und Workflows im Vergleich · Prozesse vor der Automatisierung verstehen

RAG-Systeme: Wie Unternehmenswissen mit KI nutzbar wird, ohne dem Modell blind zu vertrauen