# RAG Chatbot DSGVO: Datenfluss, Löschung und DSFA prüfen

> RAG Chatbot und DSGVO: wo personenbezogene Daten liegen, Rechtsgrundlage, AVV, Löschung in Index und Logs, DSFA und eine Checkliste für den Datenschutz.

- URL: https://newlifedigital.de/blog/rag-chatbot-dsgvo/
- Autor: Simon Maiwald (https://newlifedigital.de/team/simon-maiwald/)
- Veröffentlicht: 2026-10-17
- Aktualisiert: 2026-10-17

**Kurzantwort:** Ein RAG-Chatbot ist weder pauschal zulässig noch pauschal unzulässig. Klären Sie zuerst, an welchen Stellen des Ablaufs personenbezogene Daten liegen: in Quelldokumenten, im Vektorindex, in Fragen, Antworten und Protokollen. Für jede Stelle brauchen Sie Zweck und Rechtsgrundlage, bei externen Anbietern einen Vertrag nach Art. 28 DSGVO, Zugriffsrechte vor der Antwort und einen Löschweg. Ob eine Datenschutz-Folgenabschätzung nötig ist, entscheiden Sie in einer dokumentierten Vorabprüfung; die Bewertung liegt bei Ihrem Datenschutzbeauftragten oder Ihrer Rechtsberatung.

Ein typischer Anlass: Die Servicekollegen sollen per Chat Antworten aus internen Daten wie Handbüchern und Ticketarchiv bekommen. Die IT zeigt eine Demo, und die Datenschutzbeauftragte fragt, wo in diesem System Kundennamen und Mitarbeiterdaten liegen und wie sie wieder herauskommen. Der Beitrag [RAG im Unternehmen](/blog/rag-im-unternehmen-wissensdatenbank/) ordnet das Thema ein, der [Leitfaden zu ChatGPT und Claude im Unternehmen](/blog/dsgvo-konforme-ki-integration-2026/) behandelt Chat-Werkzeuge allgemein. Hier verfolgen wir eine Frage durch den RAG-Ablauf, gestützt auf die Orientierungshilfe der Datenschutzkonferenz (DSK) zu RAG-Systemen von Oktober 2025.

## Wo stehen in einem RAG-Chatbot personenbezogene Daten?

Die DSK beschreibt ein RAG-System als Zusammenspiel aus Embedding-Modell, Vektordatenbank, Retriever und Sprachmodell. Quelldokumente werden in Abschnitte (Chunks) zerlegt, in Vektoren überführt und gespeichert; bei jeder Frage übergibt der Retriever ähnliche Abschnitte mit der Frage an das Sprachmodell. Daraus ergeben sich sechs Stationen:

| Station | Was dort liegen kann | Prüffrage |
| --- | --- | --- |
| 1. Quelldokumente | Namen, Mailadressen, Vertragsdaten, Freitext in Tickets; Autorennamen in Dateimetadaten | Welche Quellen sind für den Zweck nötig? |
| 2. Abschnitte und Vektorindex | dieselben Inhalte als Textabschnitte, dazu die Vektoren | Wer betreibt und liest den Index? |
| 3. Embedding-Aufruf | Abschnitte und Fragen, die an ein Embedding-Modell gehen | Eigener Betrieb oder Anbieter? |
| 4. Erweiterter Prompt | Fragetext plus gefundene Abschnitte für das Sprachmodell | Welcher Anbieter, Ort, welche Speicherung? |
| 5. Antwort und Quellenangaben | Zusammenfassungen mit Personenbezug, Dokumentverweise | Darf die fragende Person die Quelle sehen? |
| 6. Protokolle, Caches, Feedback, Sicherungen | Fragen und Antworten im Klartext, Bewertungen, Kopien | Wer liest mit, wie lange, wie wird gelöscht? |

Zwei Hinweise zur Einordnung. Erstens: Der [Bayerische Landesbeauftragte für den Datenschutz](https://www.datenschutz-bayern.de/ki/AI_nut_01.pdf) sieht Vektoren aus personenbezogenen Quellen regelmäßig weiterhin als personenbezogene Daten an, weil sich über die Ähnlichkeitssuche Rückschlüsse auf die Inhalte ziehen lassen. Er nennt außerdem Autorennamen in Dateimetadaten als Beispiel für Personenbezug. Die Handreichung richtet sich an bayerische öffentliche Stellen; unsere Empfehlung für Ihre Planung lautet trotzdem, den Index wie die Quelle zu behandeln. Zweitens: Die DSK legt ein Szenario zugrunde, in dem das gesamte System im eigenen Betrieb läuft. Verteilen Sie Komponenten auf Dienstleister, kommen weitere Aspekte hinzu, etwa Auftragsverarbeitung oder gemeinsame Verantwortlichkeit.

## Welche Rechtsgrundlage und welcher Zweck tragen den Chatbot?

Nach der [DSK-Orientierungshilfe](https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf) braucht ein RAG-System eine Rechtsgrundlage, denn schon das Embedding und die Speicherung in der Vektordatenbank verarbeiten personenbezogene Daten aus den Referenzdokumenten. Art. 6 Abs. 1 der [Datenschutz-Grundverordnung](https://eur-lex.europa.eu/eli/reg/2016/679/oj/deu) nennt sechs mögliche Grundlagen. Je nach Quelle können zum Beispiel ein Vertrag mit der betroffenen Person (Buchstabe b) oder berechtigte Interessen (Buchstabe f) in Betracht kommen; Letztere verlangen eine Abwägung gegen die Rechte der Betroffenen. Welche Grundlage trägt, entscheidet sich pro Quelle und Zweck.

Die Zweckbindung (Art. 5 Abs. 1 Buchst. b) ist bei RAG die typische Falle. Ein Ticketarchiv entstand, um Kundenfälle zu lösen. Wird es zur Wissensbasis für alle Beschäftigten oder für den Vertrieb, ist das eine neue Verwendung. Art. 6 Abs. 4 nennt Kriterien für diese Prüfung, etwa die Art der Daten und mögliche Folgen für die Betroffenen. Nach der DSK erhalten Mitarbeitende je Verarbeitungszweck eine eigene Rolle, und im Index lässt sich die Zweckbindung durch Mandantentrennung oder funktionale Trennung umsetzen. Außerdem warnt die DSK vor einer Verkettung: Das Sprachmodell kann Daten aus dem Index mit personenbezogenen Daten verbinden, die im Modell selbst stecken, ohne dass man es der Ausgabe ansieht.

Datenminimierung beginnt bei der Quellenwahl. Entfernen oder anonymisieren Sie personenbezogene Daten, soweit sie für den Zweck nicht erforderlich sind, so die DSK zur Datenaufbereitung. Eine Websuche als Zusatzquelle erfüllt die Anforderungen an Rechtmäßigkeit, Eignung und Richtigkeit nach der DSK regelmäßig nicht. Betreffen Quellen Beschäftigte, binden Sie früh Personalleitung und gegebenenfalls Betriebsrat ein.

## Brauchen Sie einen AVV, und wo liegen die Daten?

Verarbeitet ein Dienstleister personenbezogene Daten in Ihrem Auftrag, verlangt Art. 28 DSGVO einen Vertrag (Auftragsverarbeitungsvertrag, AVV) oder ein anderes Rechtsinstrument. Er regelt unter anderem die Verarbeitung nur nach Ihrer Weisung, Unterauftragsverarbeiter, die Unterstützung bei Betroffenenanfragen und die Löschung oder Rückgabe nach Ende der Leistung (Abs. 3). Ob ein Anbieter Auftragsverarbeiter ist, hängt von seiner Rolle im konkreten Vorgang ab. Ein RAG-System hat mehrere mögliche Beteiligte, deshalb gehen Sie jede Komponente einzeln durch:

| Komponente | Zu klären |
| --- | --- |
| Embedding-Modell (eigener Betrieb oder Schnittstelle) | Gehen Abschnitte und Fragen an einen Anbieter? Wie lange speichert er sie? |
| Vektordatenbank (selbst betrieben oder als Dienst) | Standort, Betreiber, Support-Zugriff, Sicherungen |
| Sprachmodell | Anbieter, Verarbeitungsregion, Aufbewahrung der Eingaben, Unterauftragsverarbeiter |
| Plattform, Hosting, Monitoring | Wer sieht Protokolle und Fehlerberichte, die Fragetexte enthalten? |

Verlassen Daten den Europäischen Wirtschaftsraum oder können Stellen in Drittländern darauf zugreifen, gelten die Bedingungen des Kapitels V der DSGVO (ab Art. 44). Eine EU-Region in den Einstellungen beantwortet das nicht allein, denn Support-Zugriffe und Unterauftragsverarbeiter gehören zum Datenfluss. Die DSK weist außerdem darauf hin, dass RAG ein Sprachmodell mit weniger Faktenwissen erlaubt. Dann kann das System unter Umständen im eigenen Betrieb laufen, ohne personenbezogene Daten an Online-Betreiber großer Sprachmodelle zu übertragen.

## Wie stellen Sie Zugriffsrechte vor der Antwort sicher?

Das Sprachmodell kann nicht steuern, wer welche Informationen sehen darf. Rechte- und Rollenkonzept sowie Mandantentrennung greifen laut DSK an der Vektordatenbank und an den Referenzdokumenten. Datenschutzrechtlich hängen daran die Vertraulichkeit (Art. 5 Abs. 1 Buchst. f) und angemessene Schutzmaßnahmen nach Art. 32. Für die Abnahme heißt das:

- Rechte stammen aus dem Quellsystem oder einem zentralen Konzept und gelten auf Abschnittsebene im Index.
- Der Filter wirkt, bevor Abschnitte an das Sprachmodell gehen, nicht über eine Anweisung im Prompt.
- Negativtests: Eine Person ohne Zugriff fragt nach Inhalten eines gesperrten Dokuments, und das System lehnt ab.
- Quellen unbekannter oder zweifelhafter Herkunft kommen nicht in den Index. Die DSK nennt Data-Poisoning, also manipulierte Inhalte, als Risiko für Daten im RAG-Subsystem.

Den technischen Aufbau beschreibt der Abschnitt zur Architektur im [Hub-Beitrag](/blog/rag-im-unternehmen-wissensdatenbank/). Wie sich Berechtigungen aus Microsoft- und Atlassian-Umgebungen übernehmen lassen, steht im Beitrag zu [SharePoint und Confluence](/blog/sharepoint-confluence-ki-wissen-anbinden/).

## Wie löschen Sie Daten, und wie beantworten Sie Betroffenenanfragen?

### Löschkonzept für Index, Protokolle und Sicherungen

Die DSK sieht hier einen Vorteil von RAG: Einträge in der Vektordatenbank und die Referenzdokumente sind direkt adressierbar und lassen sich gezielt löschen, auch über klassische Löschfristen. Aus dem Sprachmodell selbst lassen sich Daten laut DSK weiterhin nicht gezielt entfernen; das betrifft nur Ihre eigenen Speicherorte. Ein Löschkonzept für RAG erfasst deshalb jede Kopie:

| Speicherort | Auslöser | Nachweis |
| --- | --- | --- |
| Quelldokument | Löschung im Quellsystem, Fristablauf | Quellsystem meldet die Löschung an den Index |
| Abschnitte und Vektoren | Quelle gelöscht oder geändert | Löschtest: Eine Frage, die den Abschnitt vorher fand, liefert ihn nicht mehr |
| Caches | Quelle oder Rechte geändert | Leerung getestet |
| Protokolle und Feedback | Aufbewahrungsfrist, Betroffenenantrag | Frist technisch erzwungen |
| Sicherungen und Snapshots | Rotation | Dokumentiert, wie lange Gelöschtes noch liegt; nach einer Wiederherstellung wird erneut gelöscht |
| Speicher beim Anbieter | Vertrag, Konfiguration | Art. 28 Abs. 3 Buchst. g, Einstellungen geprüft |

Rechtlich stützen sich diese Fristen auf die Speicherbegrenzung (Art. 5 Abs. 1 Buchst. e) und das Recht auf Löschung (Art. 17); Art. 17 Abs. 3 nennt Ausnahmen, etwa zur Geltendmachung von Rechtsansprüchen. Die DSK-Orientierungshilfe behandelt Protokolle, Caches und Sicherungen nicht gesondert, die Zeilen dazu sind unsere Praxisempfehlungen auf Grundlage dieser Grundsätze. Jeder Abschnitt sollte die Kennung seines Quelldokuments tragen, sonst finden Sie ihn zum Löschen nicht. Bei veralteten Dokumenten gilt die Richtigkeit nach Art. 5 Abs. 1 Buchst. d: Korrigieren Sie die Quelle und indexieren Sie neu, statt nur eine Antwort zu korrigieren.

### Auskunft, Berichtigung und Löschung auf Anfrage

Betroffene haben Rechte nach Art. 15 ff. DSGVO an Eingaben und Ausgaben, Referenzdokumenten und Vektordatenbank, soweit dort personenbezogene Daten stehen. Transparenz, Auskunft, Berichtigung und Löschung lassen sich dafür nach der DSK in der Regel umsetzen. Für das Sprachmodell selbst bezeichnet sie die Umsetzung der Betroffenenrechte als weitgehend ungelöst. Praktisch brauchen Sie drei Dinge:

1. Einen Suchweg, der alle Abschnitte, Protokolle und Feedbackeinträge zu einer Person findet, etwa über Name, Kundennummer oder Mailadresse.
2. Eine benannte Zuständigkeit für Anfragen, auch beim Dienstleister (Art. 28 Abs. 3 Buchst. e).
3. Aktualisierte Datenschutzhinweise, die den Chatbot nennen; die DSK verweist auf die Informationspflichten bei der Auswahl der Referenzdokumente.

Angezeigte Quellen zeigen, welche Dokumente den Input bildeten; über die Entstehung der Antwort im Modell sagen sie laut DSK nichts.

## Wann braucht es eine DSFA, und was verlangt der EU AI Act?

### Datenschutz-Folgenabschätzung nach Art. 35

Art. 35 Abs. 1 DSGVO verlangt eine Folgenabschätzung, wenn eine Verarbeitung, insbesondere bei neuen Technologien, voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen hat. Die [DSK-Liste nach Art. 35 Abs. 4](https://www.datenschutzkonferenz-online.de/media/ah/20181017_ah_DSK_DSFA_Muss-Liste_Version_1.1_Deutsch.pdf) für den nicht-öffentlichen Bereich (Version 1.1 von 2018) führt unter Nr. 11 den Einsatz von KI zur Steuerung der Interaktion mit Betroffenen auf. Als Beispiel nennt sie ein System, das mit Kunden per Konversation interagiert und dafür personenbezogene Daten durch KI verarbeitet. Zugleich hält die Liste fest, dass sie nicht abschließend ist und die allgemeinen Regeln in Art. 35 Abs. 1 und 3 ergänzt: Auch ein nicht aufgeführter Vorgang kann eine Folgenabschätzung erfordern. Als Maßstab verweist sie auf neun Kriterien aus dem Arbeitspapier WP 248 der Artikel-29-Gruppe. Die Vorabprüfung schriftlich festzuhalten, ist unsere Empfehlung.

| Konstellation | Einordnung |
| --- | --- |
| Chatbot für Kunden, der Kundendaten verarbeitet | Entspricht dem Beispiel der DSK-Liste, eine Folgenabschätzung liegt sehr nahe |
| Quellen mit Gesundheits- oder anderen besonderen Kategorien in großem Umfang | Regelbeispiel nach Art. 35 Abs. 3 Buchst. b |
| Antworten bewerten oder ordnen Personen ein (Leistung, Bonität, Bewerbungen) | Kriterium Bewerten und Einstufen; zusätzlich Art. 22 DSGVO und die Einstufung nach dem EU AI Act prüfen |
| Interner Chat über Handbücher ohne Personenbezug (außer Metadaten) | Unsere Einschätzung: Die Vorabprüfung fällt meist unkritischer aus, bleibt aber dokumentationspflichtig |

Die Liste stammt von 2018 und nennt RAG nicht, das DSK-Papier von 2025 äußert sich nicht zur Folgenabschätzung. Begründen Sie Ihre Vorabprüfung deshalb schriftlich. Eine Folgenabschätzung beschreibt nach Art. 35 Abs. 7 die Verarbeitungsvorgänge und Zwecke, bewertet Notwendigkeit, Verhältnismäßigkeit und Risiken und nennt Abhilfemaßnahmen. Die Stationen-Tabelle oben liefert die Beschreibung der Vorgänge.

### Transparenz bei Chatbots nach dem EU AI Act

Die DSK ordnet ein RAG-System als KI-System im Sinne des EU AI Act ein. Für Chatbots enthält [Art. 50 Abs. 1](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50) eine Transparenzregel: Systeme, die direkt mit Menschen interagieren, sind so zu gestalten, dass diese über die Interaktion mit einem KI-System informiert werden, außer es ist offensichtlich. Nach der [Übersicht der Europäischen Kommission](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) greifen die Transparenzregeln ab August 2026. Die Pflicht richtet sich an Anbieter; wer ein System selbst bereitstellt, prüft seine Rolle im Einzelfall. Praktisch kommt dafür ein klarer Hinweis im Chatfenster infrage.

## Fiktives Beispiel: Service-Chatbot eines Maschinenbauers

**Fiktives Beispiel, kein Kundenprojekt.** Annahmen: Ein Betrieb mit etwa 150 Beschäftigten will Servicekollegen Antworten aus Handbüchern und einem Ticketarchiv geben. Die Tickets enthalten in Freitexten Namen und Mailadressen von Ansprechpartnern der Kunden. Embedding und Sprachmodell kommen von Dienstleistern.

| Station | Entscheidung im Beispiel |
| --- | --- |
| Quellen | Handbücher aufnehmen, Dateimetadaten bereinigen; Tickets erst nach Entfernen von Namen und Mailadressen oder gar nicht |
| Zweck und Rollen | Zweck „Servicefälle lösen“; nur die Rolle Service hat Zugriff; Vertrieb erst nach neuer Zweckprüfung |
| Anbieter | Je Komponente AVV, Region, Unterauftragsverarbeiter und Eingabespeicherung geprüft |
| Löschung | Jeder Abschnitt trägt die Ticket-Kennung; Löschtest bei jeder neuen Version; Frageprotokolle werden nach einer festgelegten Frist gelöscht (Beispielwert: 30 Tage) |
| Folgenabschätzung, Hinweise | Vorabprüfung dokumentiert und vom Datenschutzbeauftragten bewertet; KI-Hinweis im Chat, Datenschutzhinweis ergänzt |

## Checkliste für Datenschutzbeauftragte

1. Zweck und Nutzergruppen sind je Quelle festgelegt, ein Quellenregister nennt Personenbezug, Metadaten und Ausschlüsse.
2. Die Rechtsgrundlage ist je Quelle und Zweck dokumentiert; bei neuer Verwendung liegt eine Prüfung nach Art. 6 Abs. 4 vor.
3. Eine Datenflusskarte zeigt Embedding, Vektorspeicher, Sprachmodell, Hosting und Protokollierung mit Anbieter, Ort und Unterauftragsverarbeitern.
4. Für jede Komponente mit Auftragsverarbeitung liegt ein Vertrag nach Art. 28 vor; Drittlandübermittlungen haben eine Grundlage nach Kapitel V.
5. Das Rollenkonzept gilt im Index und ist mit Negativtests geprüft.
6. Das Löschkonzept deckt Quelle, Abschnitte, Vektoren, Caches, Protokolle, Feedback und Sicherungen ab und hat einen Löschtest.
7. Umfang, Zugriff und Aufbewahrung der Protokolle sind begrenzt und festgelegt.
8. Betroffenenanfragen haben einen Suchweg und eine Zuständigkeit; die Datenschutzhinweise sind aktuell.
9. Die Vorabprüfung zur Folgenabschätzung ist begründet dokumentiert.
10. KI-Hinweis im Chat und Rolle nach dem EU AI Act sind geprüft; neue Quellen, Modelle oder Anbieter lösen eine Neubewertung aus.

## Die Entscheidung in einem Satz

Geben Sie einen RAG-Chatbot erst frei, wenn für jede Station vom Quelldokument bis zur Sicherung Zweck, Vertrag, Zugriffsrecht und Löschweg dokumentiert und getestet sind.

Wir planen und bauen RAG-Anwendungen mit diesen Kontrollen im technischen Entwurf: Rechtefilter vor der Generierung, Löschwege je Speicherort, begrenzte Protokolle. Die rechtliche Bewertung bleibt bei Ihnen und Ihrem Datenschutzbeauftragten. Der Einstieg ist unser bezahlter Discovery-Sprint für 4.900 € netto in 5 Arbeitstage, mit Live-Demo, Bewertung und Entscheidungsempfehlung; ein Build ist optional und folgt zum Festpreis nach geklärtem Umfang. Unsere [KI-Integration aus Mannheim](/leistungen/ki-integration-mannheim/) beschreibt den Projektweg. [Den Datenfluss Ihres Chatbots im Erstgespräch besprechen](/kontakt/?source=ki-datenschutz).