Wissen · Aktualisiert: 4. Juni 2026
RAG mit eigenen Daten — datenschutzbewusst umgesetzt
RAG entfaltet seinen Wert erst mit Ihren eigenen Daten. Wenn diese auch personenbezogene Informationen enthalten, kommt es darauf an, den Datenfluss bewusst zu gestalten. Dieser Beitrag zeigt, wie das datenschutzbewusst gelingt — ohne rechtliche Versprechen, die niemand seriös geben kann.
Von Slava Spitsyn · AI Builder · Redaktionelle Grundsätze (englisch)
Ein RAG-System wird erst durch Ihre eigenen Daten wertvoll — und genau dann stellt sich die Datenschutzfrage. Sobald Dokumente personenbezogene Informationen enthalten, kommt es darauf an, den Datenfluss bewusst zu gestalten: zu wissen, wo welche Daten verarbeitet werden, und den Abfluss in Drittländer zu vermeiden. Dieser Beitrag zeigt, wie Sie eigenen Datenbestand datenschutzbewusst für RAG nutzbar machen. Er gibt dabei keine rechtlichen Garantien — und erklärt, warum genau das die ehrliche Position ist.
Eine technische Einführung in RAG liefert der Leitfaden RAG für Unternehmenswissen. Hier geht es um den verantwortungsvollen Umgang mit eigenen, auch sensiblen Daten.
Warum eigene Daten der Kern von RAG sind
Der ganze Sinn von RAG besteht darin, ein Sprachmodell mit Ihrem spezifischen Wissen zu verbinden. Dieses Wissen steckt in Handbüchern, Tickets, Verträgen, Wikis und E-Mails — und genau dort finden sich häufig auch personenbezogene Daten: Namen, Kontaktdaten, Vorgänge, manchmal besonders schützenswerte Informationen.
Das ist kein Grund, auf RAG zu verzichten. Es ist ein Grund, den Aufbau bewusst zu wählen. Der entscheidende Vorteil von RAG gegenüber einem fest trainierten Modell: Der Datenfluss ist sichtbar und steuerbar. Sie wissen, welche Dokumente im Index liegen, welche Stellen abgerufen werden und welches Modell die Antwort erzeugt — und können an jeder dieser Stationen ansetzen.
Den Datenfluss bewusst gestalten
Ein datenschutzbewusstes RAG-System beginnt mit der Frage: Wo geht welche Information hin? Drei Stationen sind dabei besonders relevant:
- Aufbereitung und Indexierung. Ihre Dokumente werden in Abschnitte geteilt und in Vektoren übersetzt. Schon hier können Sie entscheiden, welche Inhalte überhaupt in den Index gehören — und ob bestimmte personenbezogene Felder vorab entfernt oder reduziert werden. Hier setzt auch Pseudonymisierung oder Anonymisierung an: personenbezogene Merkmale lassen sich vor der Einbettung ersetzen oder entfernen, sodass sie gar nicht erst in den Index gelangen.
- Speicherung im Vektor-Store. Der Index mit Ihren Inhalten kann vollständig in Ihrer eigenen Infrastruktur liegen. Häufig genügt dafür eine Erweiterung einer bestehenden PostgreSQL-Datenbank wie pgvector, sodass kein zusätzlicher externer Dienst nötig ist.
- Abruf und Generierung. Bei jeder Anfrage werden Stellen abgerufen und an ein Sprachmodell übergeben. Genau hier entscheidet sich, ob Inhalte das eigene System verlassen. Ein EU-gehostetes oder lokal betriebenes Modell hält diesen Schritt in Ihrer Kontrolle.
Wer diese drei Stationen bewusst gestaltet, vermeidet den häufigsten Fehler: dass sensible Inhalte unbemerkt an externe Dienste in Drittländern abfließen.
Datenhoheit, EU-Infrastruktur und lokale Modelle
Drei technische Hebel reduzieren das Datenabfluss-Risiko spürbar:
- Datenhoheit. Der Vektor-Store mit Ihren Dokumenten läuft unter Ihrer Kontrolle. Ihre Inhalte verlassen Ihre Infrastruktur nicht, nur weil ein KI-System darauf arbeitet.
- EU-Infrastruktur. Hosting, Datenbank und — wo gewünscht — auch das Sprachmodell lassen sich in der EU betreiben. Das senkt das Risiko, dass personenbezogene Daten in Drittländer gelangen.
- Lokale Modelle als Option. Wo Daten besonders sensibel sind, kann ein On-Premise-Modell die Verarbeitung im eigenen Rechenzentrum halten. Wann das sinnvoll ist und was es praktisch bedeutet, vertieft der Beitrag RAG on-premise betreiben.
Diese Hebel sind technische Maßnahmen zur Risiko-Reduktion. Sie machen aus einem offenen Datenfluss einen kontrollierten — mehr, aber auch nicht mehr.
Die ehrliche Einordnung: Risiko-Reduktion, keine Garantie
An dieser Stelle ist Klarheit wichtig: Eine datenschutzbewusste Architektur reduziert Risiken — sie ist keine Zusicherung rechtlicher Konformität. Formulierungen wie „garantiert DSGVO-konform“ sind irreführend, weil DSGVO-Konformität kein technischer Schalter ist, den man umlegt, sondern ein rechtlicher Gesamtzustand.
Zu diesem Gesamtzustand gehören Fragen, die über die Technik hinausgehen:
- Rechtsgrundlage der Verarbeitung und Zweckbindung.
- Auftragsverarbeitung und vertragliche Grundlagen mit beteiligten Dienstleistern.
- Betroffenenrechte wie Auskunft, Berichtigung und Löschung.
- Löschkonzepte — auch für Inhalte, die bereits in den Index eingeflossen sind.
- Dokumentation der gesamten Verarbeitung.
Diese Aspekte gehören in fachkundige Hände — in eine fundierte datenschutzrechtliche Prüfung. Die Architektur schafft die technische Grundlage dafür, dass eine solche Prüfung zu einem tragfähigen Ergebnis kommen kann. Sie ersetzt diese Prüfung aber nicht. Wer das anders darstellt, verspricht etwas, das sich technisch nicht halten lässt.
Fazit
RAG mit eigenen Daten ist kein Widerspruch zum Datenschutz — vorausgesetzt, der Datenfluss wird bewusst gestaltet. Datenhoheit, EU-Infrastruktur und lokale Modelle sind wirksame Hebel, um das Datenabfluss-Risiko deutlich zu senken. Entscheidend bleibt die ehrliche Einordnung: Diese Maßnahmen reduzieren Risiken, ersetzen aber keine rechtliche Prüfung. Eine solide technische Grundlage und eine fachkundige rechtliche Bewertung gehören zusammen — erst beide gemeinsam tragen einen verantwortungsvollen Betrieb.