RAG-Architektur: Komponenten, Datenfluss und Betriebsmodell

Die meisten RAG-Demos zeigen denselben Ausschnitt: eine Frage wird eingegeben, eine plausible Antwort erscheint, fertig. Was dazwischen liegt – wie Dokumente überhaupt in das System kommen, wer auf welche Inhalte zugreifen darf, wo die Daten liegen und wer sie aktuell hält – bleibt unsichtbar. Genau das ist aber der Teil, der in der Praxis über Erfolg oder Misserfolg entscheidet, und der Teil, an dem die meisten Projekte mehr Zeit verlieren als an der Modellauswahl.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die eine RAG-Lösung – etwa einen internen Wissens-Chatbot oder eine Dokumentensuche – nicht nur nutzen, sondern auch grob verstehen wollen, bevor sie sie beauftragen oder aufbauen lassen. Er gehört zum Themen-Cluster RAG, Wissensdatenbanken und Daten; was RAG grundsätzlich ist, klärt der Einstiegsartikel des Clusters, Zugriffsrechte im Detail ein eigener Vertiefungsartikel.

Begriffe kurz geklärt

Für den Rest des Artikels sind fünf Begriffe wichtig, die in der Praxis oft synonym verwendet werden, obwohl sie es nicht sind:

• Referenzdokumente sind die Ausgangsdaten – Handbücher, Richtlinien, Vertragsvorlagen, Wissensartikel –, die dem System als Wissensbasis zur Verfügung stehen sollen.
• Chunk ist ein Textabschnitt fester oder inhaltlich begründeter Länge, in den ein Referenzdokument vor der weiteren Verarbeitung zerlegt wird.
• Embedding ist die Vektordarstellung eines Textabschnitts oder einer Anfrage, erzeugt durch ein Embedding-Modell. Ähnliche Inhalte erhalten dabei rechnerisch nahe beieinanderliegende Vektoren.
• Retriever ist die Suchfunktion, die zu einer Anfrage die inhaltlich nächstliegenden Chunks in der Vektordatenbank ermittelt.
• RAG-Subsystem bezeichnet alles vor dem Sprachmodell: Datenaufbereitung, Embedding, Vektordatenbank und Retriever zusammen. Das Sprachmodell selbst gehört laut Datenschutzkonferenz explizit nicht zum RAG-Subsystem – eine Unterscheidung, die für Zugriffskontrolle und Datenschutz zentral ist, wie weiter unten deutlich wird.

Welche Komponenten gehören dazu?

Eine RAG-Architektur hat laut der Orientierungshilfe der Datenschutzkonferenz zu RAG-Systemen im Kern vier technische Bausteine plus das Sprachmodell: Referenzdokumente (aufbereitet in Chunks), ein Embedding-Modell, eine Vektordatenbank und einen Retriever, der die Suche übernimmt. In der Praxis kommen zwei weitere Bausteine hinzu, die in Demos meist fehlen, aber für den produktiven Betrieb genauso wichtig sind: ein Rechte- und Rollenkonzept und ein Aktualisierungsprozess.

Komponente	Aufgabe	Typische Stolperfalle
Referenzdokumente	Rohdaten der Wissensbasis (Handbücher, Richtlinien, Tickets, Verträge)	Veraltete oder widersprüchliche Dokumentversionen bleiben unbemerkt in der Basis
Datenaufbereitung / Chunking	Zerlegung der Dokumente in handhabbare Textabschnitte	Chunks zu groß (verwässerte Treffer) oder zu klein (Kontext geht verloren)
Embedding-Modell	Wandelt Chunks und Anfragen in vergleichbare Vektoren um	Modell nicht für die verwendete Sprache trainiert, dadurch schlechtere Trefferqualität
Vektordatenbank	Speichert Vektoren mit Verweis auf den Ursprungstext	Keine Mandantentrennung – alle Nutzenden landen im selben Suchraum
Retriever	Findet zur Anfrage die semantisch nächsten Chunks	Rechteprüfung fehlt an dieser Stelle, obwohl sie hier hingehört
Sprachmodell (LLM)	Formuliert aus Anfrage und gefundenen Chunks die Antwort	Modell greift bei Widersprüchen auf antrainiertes statt auf bereitgestelltes Wissen zurück
Rechte- und Rollenkonzept	Steuert, wer welche Chunks überhaupt sehen darf	Wird nachträglich draufgesetzt statt von Anfang an mitgeplant
Aktualisierungsprozess	Hält Referenzdokumente und Vektordatenbank aktuell	Kein Owner, keine Kopplung an Quellsysteme, „einmal eingespielt, nie gepflegt“

Eigene Aufstellung Philogic Labs auf Basis der DSK-Orientierungshilfe zu RAG-Systemen (Abschnitt 2) und der BSI-Maßnahme M14; die letzten beiden Zeilen sind Betriebskomponenten, die in rein technischen Beschreibungen oft fehlen.

Wie fließen Dokumente und Anfragen? Das vollständige Architekturdiagramm

Der Datenfluss läuft auf zwei zeitlich getrennten Pfaden – das ist der Punkt, der in Verkaufsdemos meist übersprungen wird, weil dort nur der zweite Pfad sichtbar ist.

Pfad A – Aufbereitung (läuft vor der Nutzung, wiederholt sich bei jeder Aktualisierung):

Referenzdokumente
   │  (1) Datenaufbereitung: Kopf-/Fußzeilen entfernen, in Fließtext überführen
   ▼
Chunks (Textabschnitte)
   │  (2) Embedding-Modell wandelt jeden Chunk in einen Vektor um
   ▼
Vektor + Chunk-Referenz
   │  (3) Speicherung mit Rechte-/Rollen-Metadaten (wer darf diesen Chunk sehen?)
   ▼
Vektordatenbank

Pfad B – Anfrage (läuft bei jeder Nutzung neu):

Nutzeranfrage + Rolle/Kontext der anfragenden Person
   │  (4) Embedding-Modell wandelt die Anfrage in einen Anfragevektor um
   ▼
Anfragevektor
   │  (5) Retriever vergleicht Anfragevektor mit Vektordatenbank
   │      UND filtert nach Rechte-/Rollen-Metadaten aus Schritt (3)
   ▼
Passende, zugriffsberechtigte Chunks
   │  (6) Chunks + ursprüngliche Anfrage werden als erweiterter Prompt zusammengestellt
   ▼
Sprachmodell (LLM)
   │  (7) Formuliert Antwort auf Basis von Anfrage und Chunks
   ▼
Ausgabe (idealerweise mit Quellenverweis auf genutzte Chunks)

Eigenes Architekturdiagramm Philogic Labs, zusammengeführt aus der Systembeschreibung der DSK-Orientierungshilfe zu RAG-Systemen (Abschnitt 2.1) und der Maßnahmenbeschreibung M14 des BSI zu Rechte- und Rollenkonzepten in der Suche.

Zwei Dinge an diesem Diagramm werden in Demos regelmäßig unterschlagen. Erstens: Schritt (1) bis (3) – die gesamte Aufbereitung – passiert nicht einmalig, sondern muss laufend wiederholt werden, sobald sich Referenzdokumente ändern; dazu mehr im Abschnitt zur Aktualisierung. Zweitens: Die Rechteprüfung in Schritt (5) ist kein optionales Add-on, sondern laut BSI-Maßnahme M14 ein Bestandteil des Retrieval-Schritts selbst – „hierfür sollte genau geprüft werden, wer auf welche Informationen zugreifen darf“, heißt es dort wörtlich, mit der ausdrücklichen Warnung, das Rechte- und Rollensystem nicht über textuelle Instruktionen an das Sprachmodell umzusetzen, da das angreifbar ist.

Wo findet Zugriffskontrolle statt?

Die kurze Antwort: im RAG-Subsystem, nicht im Sprachmodell. Die Datenschutzkonferenz stellt das in ihrer Orientierungshilfe zu RAG-Systemen explizit fest: Im Sprachmodell selbst lässt sich nicht steuern, auf welche Informationen bestimmte Nutzende Zugriff haben dürfen und auf welche nicht. Ein LLM kennt keine Benutzerrollen – es verarbeitet, was ihm im Prompt übergeben wird. Die Kontrolle muss also an drei Stellen davor ansetzen:

1. Bei der Datenaufbereitung. Schon beim Einlesen der Referenzdokumente wird festgelegt, welchem Bereich, welcher Abteilung oder welchem Mandanten ein Dokument zugeordnet ist – etwa durch Aufteilung der Dokumente oder Metadaten pro Chunk.
2. In der Vektordatenbank. Über Mandantentrennung beziehungsweise funktionale Trennung werden Zugangsbeschränkungen zu Bereichen der Datenbank umgesetzt – vergleichbar mit klassischen Aktenkreisen in einer Organisation.
3. Im Retriever. Vor jeder Suche muss die Rolle der anfragenden Person mit den zugänglichen Bereichen abgeglichen werden, sodass nur Chunks in die Trefferliste gelangen, auf die diese Person zugreifen darf.

Diese dreistufige Kontrolle ist kein Nice-to-have, sondern in der DSK-Terminologie eine etablierte technische und organisatorische Maßnahme zur Gewährleistung von Vertraulichkeit. Sie hat zugleich eine positive Kehrseite: Weil Vertraulichkeit im RAG-Subsystem separat vom Sprachmodell gesteuert werden kann, lassen sich laut Datenschutzkonferenz unter Einhaltung der übrigen datenschutzrechtlichen Anforderungen auch besonders schutzbedürftige personenbezogene Daten in die Wissensbasis aufnehmen – vorausgesetzt, sie verbleiben in Referenzdokumenten und Vektordatenbank und werden nicht gezielt zum Training oder Nachtraining des Sprachmodells verwendet.

In der Praxis sehe ich hier den größten Unterschied zwischen einer Testinstallation und einem produktionsreifen System: Ein Prototyp mit einer gemeinsamen Vektordatenbank für alle Nutzenden lässt sich in Tagen aufsetzen. Ein Rechte- und Rollenkonzept, das Mandanten- oder Abteilungsgrenzen tatsächlich durchsetzt, verlangt dagegen eine bewusste Entscheidung, bevor der erste Chunk eingespielt wird – nachträglich in eine bestehende Vektordatenbank hineinzufiltern ist deutlich aufwändiger, als sie von Anfang an entlang der Rechtestruktur zu befüllen.

Welche Speicher braucht man?

Mindestens zwei Speicherarten sind für ein funktionierendes RAG-System nötig:

• Ablage der Referenzdokumente. Die aufbereiteten Ausgangsdokumente selbst – ob in einem Dateisystem, einem Dokumentenmanagementsystem oder einer bestehenden Wissensdatenbank – müssen erreichbar und versioniert bleiben, damit Löschungen und Aktualisierungen nachvollziehbar sind.
• Vektordatenbank. Speichert die Embeddings zusammen mit einem Verweis auf den zugehörigen Chunk beziehungsweise Text sowie – siehe oben – den Rechte- und Rollen-Metadaten. Diese Einträge sind laut Datenschutzkonferenz direkt adressierbar, was gezieltes Löschen einzelner Datensätze technisch einfach macht.

Je nach Betriebsmodell kommen zwei weitere Speicher hinzu, die kein Muss, aber in der Praxis häufig sind: ein Anfrage- beziehungsweise Antwort-Log zur Nachvollziehbarkeit (relevant für Transparenzpflichten und Fehleranalyse) und ein Cache für wiederkehrende Anfragen, der Rechenkosten senkt. Beide Speicher enthalten möglicherweise personenbezogene Daten aus Eingaben oder Ausgaben und unterliegen denselben Sorgfaltspflichten wie die Vektordatenbank.

Eine Entscheidung, die früh getroffen werden muss: Cloud-Betrieb bei einem externen Anbieter oder On-Premise. Weil ein RAG-System einem Sprachmodell weniger eigenes Faktenwissen abverlangt – das Wissen steckt ja in den Referenzdokumenten –, kommt laut Datenschutzkonferenz für den Einsatz eine größere Auswahl an Sprachmodellen infrage, unter Umständen auch kleinere, lokal betreibbare Modelle. Das kann den On-Premise-Betrieb des gesamten RAG-Systems erleichtern und vermeidet, dass personenbezogene Daten an externe Betreiber großer Sprachmodelle übertragen werden. Das ist kein Automatismus, sondern eine Option, die pro Anwendungsfall geprüft werden muss.

Wie aktualisiert man?

Der praktische Vorteil von RAG gegenüber einem neu trainierten oder feinabgestimmten Sprachmodell liegt genau hier: Referenzdokumente und Einträge in der Vektordatenbank lassen sich löschen, ersetzen oder ergänzen, ohne das Sprachmodell selbst anzufassen. Die Löschung erfolgt laut Datenschutzkonferenz technisch durch Entfernen der Einträge aus Datenbank und Referenzdokumenten – direkt adressierbar, auch für einzelne personenbezogene Daten. Klassische Mechanismen zur Löschung nach Ablauf von Aufbewahrungsfristen lassen sich damit sowohl auf die Vektordatenbank als auch auf die Referenzdokumente anwenden.

Was diese technische Möglichkeit nicht automatisch mitbringt, ist ein Prozess, der sie auch nutzt. Aus meiner Erfahrung mit internen Wissenssystemen sind drei Elemente entscheidend:

1. Ein benannter Owner. Jemand muss verantwortlich sein für die Frage, ob die Wissensbasis noch stimmt – sonst verfällt sie, wie jedes ungepflegte System.
2. Ein Rhythmus. Ob wöchentlich, monatlich oder ereignisgesteuert bei jeder Dokumentänderung: Ohne festen Turnus bleibt Aktualisierung ein gelegentliches Aufräumen statt eines Betriebsprozesses.
3. Eine Kopplung an die Quellsysteme. Im Idealfall stößt eine Änderung im Ursprungsdokument automatisch eine Neuaufbereitung des betroffenen Chunks an. Ohne diese Kopplung driften Referenzdokument und Vektordatenbank-Eintrag unbemerkt auseinander.

Die Datenschutzkonferenz weist an anderer Stelle ausdrücklich darauf hin, dass die Zuverlässigkeit eines RAG-Systems stark von Qualität, Aktualität und Vollständigkeit der Referenzdokumente abhängt und die verantwortliche Stelle regelmäßig prüfen muss, ob diese Anforderungen noch erfüllt sind. Ein RAG-System ist damit kein Projekt mit Enddatum, sondern – ähnlich wie eine klassische Wissensdatenbank – ein Betriebsgegenstand mit laufendem Pflegeaufwand.

Umsetzung: typischer Ablauf beim Aufbau

Aus Projekten, die ich begleitet habe, hat sich grob diese Reihenfolge bewährt – als Orientierung, nicht als starres Rezept:

1. Quellen und Rechtestruktur klären, bevor die erste Zeile Code steht. Welche Dokumente gehören in die Wissensbasis, wer darf sie sehen, gibt es Mandanten- oder Abteilungsgrenzen? Diese Fragen im Nachgang zu beantworten ist deutlich teurer.
2. Datenaufbereitung und Chunking pro Dokumenttyp festlegen. Verträge, FAQ-Einträge und technische Handbücher brauchen unterschiedliche Chunk-Größen und -Grenzen, damit Sinnabschnitte erhalten bleiben.
3. Embedding-Modell und Vektordatenbank wählen, passend zur Sprache der Dokumente und zum geplanten Betriebsmodell (Cloud oder On-Premise).
4. Retriever mit Rechteprüfung verdrahten – nicht als nachträglicher Filter, sondern als Bestandteil der Suche selbst.
5. Pilot mit einem klar abgegrenzten Dokumentenbestand und einer Nutzergruppe, inklusive Vorher-Nachher-Vergleich der Antwortqualität gegen manuell recherchierte Referenzantworten.
6. Aktualisierungsprozess und Owner festlegen, bevor der Pilot in den Regelbetrieb übergeht – nicht danach.

Wer diesen Aufbau nicht selbst leisten kann oder will: Eine externe Beratung prüft typischerweise zuerst Rechtestruktur und Datenlage, bevor überhaupt über Technologieauswahl gesprochen wird – in der falschen Reihenfolge liegt der häufigste Grund, warum RAG-Projekte später umgebaut werden müssen. Wo Teams die Grundlagen selbst erarbeiten wollen, sind gezielte Schulungen oft der schnellere Weg als Trial-and-Error.

Risiken & Grenzen

Eine RAG-Architektur löst nicht alle Probleme, die man ihr in Verkaufsgesprächen manchmal zuschreibt:

• Das Sprachmodell kann trotzdem widersprechen. Die Anreicherung des Prompts beeinflusst die Ausgabe, verändert aber nicht das antrainierte Wissen des Modells. Bei widersprüchlichen Inhalten kann das Modell auf sein Trainingswissen zurückfallen statt auf die bereitgestellten Chunks – ein Systemprompt, der zur ausschließlichen Nutzung der Referenzquellen anweist, kann das abmildern, aber nicht garantieren.
• Wissensvergiftung ist ein reales Risiko. Das BSI führt Retrieval-Augmented Generation ausdrücklich mit dem Risiko der Vergiftung hinterlegter Wissensdaten auf: Manipulierte Inhalte in der Wissensbasis können das Modell bei bestimmten Eingaben zu vordefinierten, falschen Ausgaben verleiten. Wer externe oder wenig vertrauenswürdige Quellen einbindet, muss das einkalkulieren.
• Zusammenhänge über mehrere Chunks hinweg werden leicht übersehen. Die Anreicherung findet nur im semantisch benachbarten Bereich statt; komplexe Gedankenketten über weit auseinanderliegende Textpassagen werden vom Retriever unter Umständen nicht vollständig erfasst.
• Zweckbindung ist nicht automatisch gelöst. Wenn ein RAG-System für unterschiedliche Zwecke genutzt wird, müssen Nutzende vor jeder Abfrage die für den jeweiligen Zweck korrekte Rolle erhalten – sonst kann es laut Datenschutzkonferenz zu einer nicht in der Ausgabe erkennbaren Verkettung personenbezogener Daten kommen.
• Betroffenenrechte im Sprachmodell selbst bleiben ungelöst. RAG verbessert Löschung und Berichtigung für Referenzdokumente und Vektordatenbank spürbar, ändert aber nichts daran, dass Auskunfts- und Löschansprüche gegenüber einem bereits trainierten Sprachmodell weiterhin eine offene technische Frage sind.
• Rechtlich bleibt Einzelfallprüfung nötig (Stand Juli 2026, keine Rechtsberatung). Für den Einsatz eines RAG-Systems braucht es eine eigene datenschutzrechtliche Rechtsgrundlage, unter anderem weil personenbezogene Daten aus Referenzdokumenten durch das Embedding-Modell verarbeitet und in der Vektordatenbank gespeichert werden. Verbindliche Bewertungen gehören zur Datenschutzkonferenz oder zu einer Rechtsberatung, nicht in diesen Artikel.

Und eine Grenze in eigener Sache: Dieser Artikel beschreibt eine Architektur, keine fertige Lösung. Ob Chunk-Größe X oder Embedding-Modell Y für einen konkreten Dokumentenbestand passt, wie viel Zeit die Aufbereitung realistisch braucht und welches Betriebsmodell zum Budget passt, entscheidet sich am konkreten Fall – dafür gibt es keine pauschale Zahl, die seriös wäre.

Checkliste: RAG-Architektur vor dem Start prüfen

1. Wir haben festgelegt, welche Referenzdokumente in die Wissensbasis gehören und wer sie inhaltlich verantwortet.
2. Die Rechtestruktur (Mandanten, Abteilungen, Rollen) steht fest, bevor Dokumente aufbereitet werden – nicht danach.
3. Wir wissen, wo die Zugriffskontrolle technisch ansetzt: Datenaufbereitung, Vektordatenbank, Retriever – nicht im Sprachmodell.
4. Chunking-Strategie und Embedding-Modell sind auf Sprache und Dokumenttyp abgestimmt.
5. Es ist entschieden, ob Cloud- oder On-Premise-Betrieb zum Schutzbedarf der Daten passt.
6. Ein Owner ist benannt, der die Aktualität der Wissensbasis laufend verantwortet.
7. Ein Rhythmus für Prüfung und Nachpflege der Referenzdokumente ist festgelegt, keine einmalige Befüllung.
8. Die Rechtsgrundlage für die Verarbeitung personenbezogener Daten im RAG-Subsystem ist datenschutzrechtlich geklärt.
9. Ein Pilot mit klar abgegrenztem Dokumentenbestand und Vorher-Nachher-Vergleich ist geplant, bevor der Rollout beginnt.
10. Risiken wie Wissensvergiftung durch unvertrauenswürdige Quellen sind bewusst adressiert, nicht ausgeblendet.

Wenn du diese Punkte für dein Vorhaben noch nicht klar beantworten kannst, ist das kein Grund, RAG zu verwerfen – aber ein guter Grund, die Architektur vor der Toolauswahl zu klären. Ein kurzes, unverbindliches Erstgespräch reicht oft, um die offenen Punkte zu sortieren.