Ihr Unternehmen hat eine interne KI aufgebaut, die auf Ihre eigenen Dokumente zugreift. HR-Richtlinien, Produkthandbücher, Kundenverträge. Das System antwortet präzise, weil es auf echtem Firmenwissen basiert – nicht auf allgemeinem Trainingswissen aus dem Internet. Ein technischer Erfolg.
Dann fragt ein Mitarbeiter seinen Datenschutzbeauftragten: Dürfen Kundendaten, die wir für den Vertrieb erhoben haben, auch in unser HR-Assistenzsystem fließen? Die Antwort ist: Nein. Und das ist nur eine von mehreren DSGVO-Pflichten, die bei Retrieval-Augmented Generation gelten – obwohl RAG-Systeme gegenüber anderen KI-Architekturen sogar klare Datenschutzvorteile haben. Dieser Artikel zeigt, wo die Pflichten liegen, wo ein strukturelles Problem bleibt, das die gesamte KI-Branche noch nicht gelöst hat – und was Mittelständler konkret tun können.
Warum RAG datenschutzrechtlich besser abschneidet als Training
Die Alternative zu RAG ist, Ihr Firmenwissen direkt in ein Sprachmodell hineinzutrainieren. Das klingt verlockend: Das Modell "weiß" dann alles aus dem Stand. Datenschutzrechtlich ist es ein Problem. Wer Daten ins Training gibt, schreibt sie in die Modellgewichte – mathematische Parameter, die nicht einzeln adressierbar sind. Einen bestimmten Datensatz später zu löschen ist ungefähr so möglich wie ein eingerührtes Ei aus dem Teig zu entfernen. Das kollidiert direkt mit dem Recht auf Löschung nach Art. 17 DSGVO.
Knowledge Injection über RAG funktioniert anders. Das Modell selbst bleibt unberührt; Ihr Firmenwissen liegt in einer externen Wissensbasis, die das Modell bei jeder Anfrage abruft. Was in dieser Datenbank liegt, können Sie kontrollieren, aktualisieren – und löschen. Das macht RAG zur datenschutzfreundlicheren Architektur. Aber es befreit nicht von den Pflichten, die entstehen, sobald personenbezogene Daten in diese Wissensbasis fließen.
Zweckbindung – die unterschätzte Pflicht
Art. 5 Abs. 1 lit. b DSGVO legt fest, dass personenbezogene Daten nur für die Zwecke verwendet werden dürfen, für die sie ursprünglich erhoben wurden. Diese Zweckbindung gilt auch für Daten, die als Referenzdokumente in ein RAG-System fließen. Das klingt abstrakt. Ein konkretes Beispiel macht es greifbar.
Ihr Vertrieb hat Kundenkontaktdaten, Gesprächsnotizen und Kaufhistorien in einem CRM-System. Diese Daten wurden erhoben, um Kundenbeziehungen zu pflegen und Angebote zu erstellen. Wenn Sie dieselben Daten in eine Wissensbasis speisen, die Ihrem HR-Chatbot bei Gehaltsverhandlungen antwortet – verlassen Sie den ursprünglichen Erhebungszweck. Das ist nach DSGVO nicht ohne weiteres zulässig. Praktisch bedeutet das: Jede Abteilung, jede Datenquelle, jeder Dokumententyp braucht eine eigene Zweckprüfung, bevor er in eine RAG-Wissensbasis fließt. Wer das nicht strukturiert dokumentiert, hat kein technisches Problem – sondern ein rechtliches.
Hinzu kommt ein Risiko, das spezifisch für RAG-Architekturen ist: die unzulässige Verknüpfung. Das RAG-System zieht aus Ihrer Wissensbasis – aber das Basis-Sprachmodell hat selbst Trainingswissen. In der Antwortgenerierung werden beide Schichten kombiniert. Wenn dabei Daten aus verschiedenen Zwecken verknüpft werden, ohne dass dafür eine Rechtsgrundlage besteht, entsteht eine DSGVO-Verletzung, die technisch schwer nachzuweisen ist, aber rechtlich trotzdem gilt. Die Gegenmaßnahme liegt in der Konzeptionsphase: klare Datentrennung nach Zweck, dokumentierte Einschränkung der Abrufkontexte, und ein Systemprompt, der das Modell anweist, ausschließlich aus den verifizierten Quellen zu antworten.
Betroffenenrechte: Was bei RAG funktioniert – und was nicht
Das Recht auf Löschung (Art. 17 DSGVO), auf Berichtigung (Art. 16) und auf Auskunft (Art. 15) gelten unabhängig davon, in welchem System Daten verarbeitet werden. Bei RAG-Architekturen gibt es hier echte Vorteile – und eine offene Flanke.
Der Vorteil: Weil Ihr Firmenwissen in einer adressierbaren Wissensbasis liegt, können Löschungen und Berichtigungen technisch "auf Knopfdruck" umgesetzt werden. Wenn ein ehemaliger Mitarbeiter die Löschung seiner Personalakte verlangt, können Sie das Dokument aus der Datenbank entfernen. Ab diesem Moment fließen die Daten nicht mehr in KI-Antworten ein. Das ist bei trainierten Modellen nicht möglich.
Die offene Flanke heißt Machine Unlearning – und sie ist eines der ungelösten Probleme der gesamten KI-Industrie. Das Basis-Sprachmodell, auf dem Ihr RAG-System läuft – ob ein Modell von Anthropic, OpenAI, Google oder ein Open-Source-Modell – wurde auf riesigen Textmengen trainiert. Wenn Daten Ihres Unternehmens, Ihrer Mitarbeiter oder Ihrer Kunden in diesen Trainingsdaten enthalten waren, sind sie in den Modellgewichten. Nicht adressierbar. Nicht löschbar. Die technischen Verfahren, um einzelne Informationen aus einem bereits trainierten Modell zu entfernen, sind Stand 2026 noch kein zuverlässig einsetzbares Werkzeug.
Die praktische Konsequenz: Unternehmen sollten bereits in der Designphase sicherstellen, dass sensible Rohdaten nie in das Training eines Basis-Modells fließen. Wer ein Modell eines externen Anbieters nutzt, trägt dafür keine Verantwortung rückwirkend – aber er trägt die Verantwortung dafür, was er dem Modell im laufenden Betrieb als Eingabedaten gibt.
Cloud oder On-Premise? Die AVV-Frage
Die meisten RAG-Implementierungen laufen auf Cloud-Infrastruktur. Das ist in vielen Fällen sinnvoll – aber datenschutzrechtlich nicht trivial. Wenn Sie einen Cloud-Anbieter für Ihre KI-Infrastruktur nutzen, verarbeitet dieser Anbieter möglicherweise personenbezogene Daten in Ihrem Auftrag. Art. 28 DSGVO schreibt dann einen Auftragsverarbeitungsvertrag (AVV) zwingend vor. Kein AVV bedeutet: Die Verarbeitung ist rechtswidrig – unabhängig davon, wie gut die Technik funktioniert. Bei Anbietern aus Drittstaaten, insbesondere den USA, gilt zusätzlich: Ohne angemessenes Schutzniveau ist der Transfer personenbezogener Daten unzulässig. Der US Cloud Act und vergleichbare Regelungen ermöglichen US-Behörden unter bestimmten Voraussetzungen Zugriff auf Daten bei US-Unternehmen – auch dann, wenn die Server physisch in Europa stehen. Für den Transfer ist in diesen Fällen eine wirksame Rechtsgrundlage erforderlich, in der Praxis meist Standardvertragsklauseln (SCCs) der EU-Kommission.
Ein weiterer kritischer Punkt: Ob Ihre Eingaben – also die Prompts, die Nutzer in Ihr RAG-System eingeben – vom Anbieter zum weiteren Training seines Modells verwendet werden. Das ist bei vielen Cloud-Diensten standardmäßig aktiviert. Ein Opt-Out muss explizit vertraglich gesichert sein. Wenn Nutzeranfragen, die interne Daten oder Personenbezüge enthalten, in das Training eines Anbietermodells fließen, ist das im Regelfall eine DSGVO-Verletzung – und Sie als Betreiber sind verantwortlich.
Für Unternehmen mit besonders sensiblen Daten – etwa Gesundheitsdaten, Betriebsgeheimnisse oder Mitarbeiterdaten im Personalbereich – empfiehlt sich daher der On-Premise-Betrieb: Die gesamte KI-Infrastruktur läuft auf eigener Hardware, kein Datentransfer an externe Anbieter. Das KI-Betriebsmodell ist für diesen Ansatz konzipiert: Firmenwissen bleibt im eigenen Haus, die Wissensbasis ist vollständig kontrollierbar.
Fünf Maßnahmen für rechtssicheres RAG
Die folgenden fünf Punkte decken die wesentlichen DSGVO-Pflichten bei RAG-Implementierungen ab:
1. Zweckprüfung vor jedem Dokument-Import. Jede Datenquelle, die in die Wissensbasis fließt, braucht eine dokumentierte Zweckprüfung: Für welchen Erhebungszweck wurden die Daten erhoben? Ist dieser Zweck kompatibel mit dem KI-Anwendungsfall?
2. AVV mit allen Cloud-Anbietern abschließen. Das gilt für den LLM-Anbieter, den Vektordatenbank-Anbieter und jede andere Infrastrukturkomponente, die personenbezogene Daten verarbeiten könnte.
3. Opt-Out für Prompt-Training vertraglich sichern. Kein Nutzer-Input und kein KI-Output darf ohne explizite Rechtsgrundlage in das Training von Anbietermodellen fließen.
4. Wissensbasis auf Löschbarkeit ausrichten. Dokumente in der RAG-Datenbank müssen individuell adressierbar sein. Eine monolithische Wissensbasis, aus der einzelne Datensätze nicht entfernt werden können, ist datenschutzrechtlich problematisch.
5. Datenschutz-Folgenabschätzung bei Hochrisiko-Anwendungen. Art. 35 DSGVO verlangt eine DSFA, wenn die Verarbeitung wahrscheinlich ein hohes Risiko für Betroffene birgt – das gilt insbesondere für KI im Recruiting, bei der Verarbeitung von Gesundheitsdaten und bei systematischer Verhaltensanalyse.
Was das mit Ihrem KI-Betriebsmodell zu tun hat
Der Kern jedes zukunftssicheren KI-Betriebsmodells bildet das Proprietary Knowledge System. Es beinhaltet die organisatorische Entscheidung, welches Wissen Ihres Unternehmens für welche KI-Anwendung zugänglich sein soll – und unter welchen Bedingungen.
Diese Entscheidung hat eine technische Dimension: Wie ist die Wissensbasis strukturiert? Wie werden Chunks gebildet, wie werden Dokumente aktualisiert? Sie hat aber auch eine rechtliche Dimension, die in der Praxis häufig übersehen wird: Wer hat für welche Dokumente die Verarbeitungshoheit? Welche Zwecke sind dokumentiert? Wer ist verantwortlich, wenn eine Löschanforderung eingeht?
Unternehmen, die ein PKS aufbauen, ohne diese Fragen zu beantworten, schaffen eine leistungsstarke Wissensinfrastruktur – und eine unkontrollierte Datenschutzhaftung. Der KI-Governance Stresstest analysiert genau diesen Schnittbereich: wo Ihre KI-Architektur steht, welche Datenschutzpflichten bereits gelten und wo strukturelle Lücken bestehen. Ein Tag, remote, mit einem konkreten Ergebnisbericht – bevor aus einer offenen Flanke ein ernstes Problem wird.
Wer mehr über die technische Seite von Knowledge Injection erfahren will: Der Artikel RAG erklärt beschreibt, wie Wissensbasisarchitekturen funktionieren. Die DSGVO-Pflichten, die dabei entstehen, kennen Sie jetzt.