Dieser Beitrag wurde mit KI-Unterstützung erstellt, fachlich geprüft und redaktionell freigegeben.

Artikelbild-Kennzeichnung: AI GENERATED

Ein RAG-Chatbot wirkt auf einer Website oft wie ein zusätzliches Eingabefeld. Technisch ist er aber eine kleine Verarbeitungskette: Eine Frage kommt von einem Menschen, wird mit einer Wissensbasis abgeglichen, geht mitsamt Kontext an ein Sprachmodell und erscheint als Antwort. Kommen Protokollierung, Analyse oder eine Übergabe an den Support hinzu, entstehen weitere Stationen. Genau deshalb beginnt eine KI-Chatbot Datenschutzerklärung nicht beim letzten Textbaustein, sondern beim Plan des Datenflusses.

Für österreichische Betriebe ist das besonders praktisch: Wer die Wege vor dem Go-live sichtbar macht, kann die Datenschutzerklärung, das Verzeichnis von Verarbeitungstätigkeiten, Verträge und technische Einstellungen aus derselben belastbaren Liste ableiten. Das reduziert Nacharbeiten, wenn aus einem einfachen FAQ-Chat später ein Lead-Formular, ein Ticketsystem oder eine interne Wissenssuche wird. Dieser Beitrag bietet dafür einen Arbeitsrahmen, keine Rechtsberatung und keine Garantie für einen konkreten Einzelfall.

Warum RAG mehr als ein Chatfenster ist

RAG steht für Retrieval-Augmented Generation. Vereinfacht gesagt sucht das System zunächst passende Inhalte aus einer Wissensbasis und legt sie dem Sprachmodell als Kontext vor. Die Antwort wird also nicht nur aus einer allgemeinen Modellantwort erzeugt. Für Datenschutz und Dokumentation zählt daher nicht nur der Chat-Anbieter. Relevant sind auch die Quelle der Dokumente, die Aufbereitung und Indexierung, ein möglicher Vektor-Datenspeicher, die Modell-Schnittstelle, Protokolle und angeschlossene Systeme.

Ein Beispiel aus einer kleinen Druckerei: Auf der Website beantwortet ein Chatbot Fragen zu Papierformaten, Lieferzeiten und Druckdaten. Die Wissensbasis enthält freigegebene Produktblätter, Versandhinweise und eine redigierte FAQ. Eine Besucherin fragt nach einer Reklamation und schreibt dabei Auftragsnummer, Telefonnummer und den Namen ihres Unternehmens in das Chatfeld. Diese Angaben können je nach Aufbau am Webserver, beim Chatdienst, in Sicherheits- oder Fehlerprotokollen, beim Modellanbieter und bei einer späteren Ticket-Übergabe anfallen. Die Antwort selbst kann wiederum im Chatverlauf oder in einer Qualitätsauswertung erscheinen.

Die zentrale Frage lautet deshalb nicht: “Speichert der Chatbot Daten?” Sondern: Welche Datenkategorien erreichen welche Stelle, zu welchem Zweck, wie lange, unter wessen Verantwortung und mit welcher Schutzmaßnahme? Die Informationspflichten nach Art. 13 DSGVO machen unter anderem Angaben zu Verantwortlichem, Zweck, Rechtsgrundlage, Empfängern, Übermittlungen, Speicherdauer und Betroffenenrechten erforderlich. Der verbindliche Ausgangstext steht in der Datenschutz-Grundverordnung.

Die Datenkette vor dem Start aufzeichnen

Am besten funktioniert ein gemeinsamer Termin mit Fachbereich, Webentwicklung, IT-Sicherheit und der Person, die Datenschutzfragen koordiniert. Nicht die perfekte Grafik ist das Ziel, sondern eine vollständige, überprüfbare Arbeitsliste. Beginnen Sie mit einer echten Testfrage und verfolgen Sie sie von der Eingabe bis zur Löschung oder Archivierung. Wiederholen Sie den Weg für eine Wissensquelle und für eine Support-Übergabe.

1. Einstieg und Website-Umfeld

Notieren Sie, wie das Widget geladen wird: eigene Domain, eingebettetes Script oder externer Dienst. Erfassen Sie die technisch anfallenden Kategorien, etwa IP-Adresse, Zeitstempel, Browser- und Geräteinformationen, Sitzungskennung, Einwilligungsstatus oder Fehlermeldungen. Ergänzen Sie, ob Cookies oder ähnliche Technologien beteiligt sind und welche Stelle sie setzt. Auch wenn eine Person im Chat keinen Namen eingibt, kann die Websiteumgebung Daten verarbeiten. Das gehört in die Bestandsaufnahme, nicht in eine Fußnote.

2. Eingaben und Gesprächsverlauf

Dokumentieren Sie, was Besucher freiwillig eingeben können und was das Interface technisch zulässt: Freitext, Dateien, Bilder, Kontaktdaten, Bestellnummern oder Gesundheitsangaben. Freitext ist kein datensparsames Datenformat, nur weil er offen ist. Definieren Sie deshalb klare Hinweise im Eingabefeld, sensible Angaben nicht einzugeben, und prüfen Sie, ob Anhänge oder bestimmte Felder wirklich erforderlich sind. Halten Sie außerdem fest, ob der vollständige Verlauf, nur Auszüge oder gar keine Inhalte gespeichert werden und wer darauf zugreifen darf.

3. Wissensbasis und Retrieval

Listen Sie jede Quelle einzeln auf: öffentliche Website-Inhalte, freigegebene Handbücher, interne Anweisungen, Produktkataloge oder exportierte Support-Artikel. Zu jeder Quelle gehören Eigentümer, Freigabestatus, Aktualisierungsweg und die Entscheidung, ob personenbezogene oder vertrauliche Inhalte ausgeschlossen sind. Bei der Aufbereitung können Dokumente zerlegt, mit Metadaten versehen und für die Suche repräsentiert werden. Auch wenn ein System keine vollständige Originaldatei an das Modell sendet, ist das keine pauschale Entwarnung. Die konkrete Architektur und der Inhalt der Quelle entscheiden darüber, welche Datenkategorien und Risiken zu dokumentieren sind.

Praktisch bewährt sich eine Freigabeliste: “öffentlich und freigegeben”, “nur intern”, “gesperrt”. In die erste Gruppe gehören etwa aktuelle Lieferhinweise; in die gesperrte Gruppe Kundenakten, Personalunterlagen, Vertragsentwürfe mit Namen oder ungeprüfte E-Mail-Archive. Ein RAG-Projekt wird sicherer, wenn die Wissensbasis bewusst kleiner beginnt und jede neue Quelle einen nachvollziehbaren Freigabeschritt braucht.

4. Modell, Infrastruktur und weitere Empfänger

Für jede technische Station sollten Name, Rolle und Standort erfasst sein: Hosting, Vektorsuche, Modell-Schnittstelle, Logging, Monitoring, Content-Delivery-Netz, E-Mail- oder Ticketsystem. Klären Sie, ob der Dienst nach Weisung verarbeitet oder selbst Zwecke und Mittel mitbestimmt. Die EDPB-Leitlinien zu Verantwortlichen und Auftragsverarbeitern helfen bei dieser Rollenprüfung; ein Vertragsname allein beantwortet sie nicht.

Notieren Sie bei jeder Station auch den tatsächlichen Datenstandort, Subdienstleister, Fernzugriffe und mögliche Übermittlungen. Eine europäische Benutzeroberfläche bedeutet nicht automatisch, dass jeder Verarbeitungsschritt im EWR bleibt. Für Drittland-Konstellationen müssen Teams den konkreten Empfänger und Übermittlungsweg prüfen; die EDPB-Leitlinien zu internationalen Übermittlungen liefern dafür den Rahmen. Die Dokumentation sollte den technischen Weg beschreiben, nicht nur ein Herkunftsland in eine Tabelle schreiben.

5. Ausgabe, Protokolle und menschliche Übergabe

Erfassen Sie, wo die Antwort angezeigt, zwischengespeichert und ausgewertet wird. Gehören Antworten in die Qualitätssicherung? Gibt es Missbrauchserkennung, Fehlersuche, Statistik oder Training? Wird bei einer Kontaktanfrage ein Ticket mit Chat-Auszug erzeugt? Gerade diese letzte Verzweigung wird oft übersehen: Sobald ein Team im CRM oder Helpdesk weiterarbeitet, ist ein neuer Empfängerkreis und häufig ein eigener Aufbewahrungs- und Berechtigungskontext betroffen.

Der Arbeitsbogen: acht Spalten, die Lücken sichtbar machen

Eine Tabelle mit acht Spalten reicht für den ersten belastbaren Durchgang. Tragen Sie pro Datenfluss ein: Station, Datenkategorien, Zweck, Rolle und Empfänger, Speicherort, Frist, Zugriffsberechtigte und Schutzmaßnahme. Als Stationen können etwa Website-Widget, API-Gateway, Retrieval, Wissensbasis, Modellaufruf, Chatprotokoll, Monitoring und Ticketübergabe auftauchen. Die Tabelle ist kein Ersatz für das Verzeichnis von Verarbeitungstätigkeiten. Sie liefert aber die technische Detailtiefe, die dort und in der Datenschutzerklärung oft fehlt.

Bei den Datenkategorien genügt eine sachliche Beschreibung: Kontaktangaben, Vertrags- oder Bestelldaten, Freitext, technische Nutzungsdaten, Inhalte aus einer freigegebenen Wissensquelle. Schreiben Sie nicht einfach “alle Daten”. Das ist unpräzise und verhindert die Diskussion, ob eine Kategorie wirklich gebraucht wird. Bei Fristen unterscheiden Sie operativen Chatverlauf, Sicherheitslog, Sicherungskopie und Supportticket. Ein Nachtschichtprotokoll kann beispielsweise für die Fehleranalyse erforderlich sein, während ein nicht übergebener Gesprächsverlauf viel kürzer vorgehalten wird. Die konkrete Angemessenheit ist für den jeweiligen Einsatz zu prüfen.

Die letzte Spalte macht die Tabelle handlungsorientiert. Bei einer internen Wissensbasis können Rollenrechte, Quellfreigabe und ein Sperrprozess für veraltete Dokumente stehen. Für den Modellaufruf kommen eine minimierte Kontextübergabe, getrennte Zugangsdaten und eine prüfbare Anbietervereinbarung in Betracht. Beim Chat-Widget können ein deutlicher Eingabehinweis, TLS, Rate-Limits und ein kontaktloser Fallback sinnvoll sein. So wird aus einer Datenschutzliste eine Liste konkreter Entscheidungen, die Entwicklung und Betrieb umsetzen können.

Abgeschlossen ist der Arbeitsbogen erst nach einem kontrollierten Test mit erfundenen Angaben. Das Team gibt eine fiktive Anfrage ein, prüft Protokolle und Ticketweg, löscht das Testartefakt im vorgesehenen Prozess und vergleicht jeden beobachteten Schritt mit der Tabelle. Taucht eine neue Station auf, etwa ein Analyse-Dienst oder eine automatische Benachrichtigung, wird zuerst die Dokumentation aktualisiert. Dieser kleine Ablauf verhindert, dass die Datenschutzerklärung eine Wunscharchitektur beschreibt, während der Betrieb bereits anders funktioniert.

Aus der technischen Liste wird eine verständliche Datenschutzerklärung

Die Datenschutzerklärung sollte nicht den Quellcode nacherzählen. Sie muss für Besucher verständlich erklären, welche Verarbeitung mit dem KI-Chat verbunden ist. Aus der Datenkette lassen sich dazu belastbare Bausteine ableiten: verantwortliche Stelle und Kontakt, Zweck der Chatfunktion, Kategorien von Eingaben und technischen Daten, Rechtsgrundlage, eingesetzte Empfänger beziehungsweise Kategorien, Speicher- oder Prüffristen, Drittlandbezug und Schutzmechanismen, Rechte der Betroffenen sowie ein klarer Weg für Auskunft, Löschung oder Widerspruch.

Wichtig ist die Trennung zwischen einem allgemeinen Website-Hinweis und der tatsächlichen Konfiguration. Wer beispielsweise Chatinhalte nach 30 Tagen löscht, darf keine unbestimmte Formulierung über eine “dauerhafte Verbesserung” stehen lassen. Wer eine menschliche Übergabe anbietet, sollte Zweck und Weg dieser Übergabe nennen. Wer ausschließlich öffentliche Inhalte als Wissensbasis freigibt, sollte nicht suggerieren, dass der Chatbot auf beliebige Kundendaten zugreift.

Für die Struktur einer Datenschutzerklärung kann der AdSimple Datenschutz Generator ein sinnvoller Ausgangspunkt sein. Entscheidend bleibt aber die saubere Auswahl der passenden Angaben für den konkreten technischen Aufbau. Den Unterschied zwischen plausibel klingendem KI-Text und einer prüfbaren Grundlage behandelt auch der AdSimple-Beitrag Warum ChatGPT keine Datenschutzerklärung verfassen sollte.

Entscheidungshilfe: Reicht eine Dokumentation oder braucht es mehr Prüfung?

Jeder KI-Chatbot braucht eine dokumentierte Datenkette. Ob darüber hinaus eine Datenschutz-Folgenabschätzung erforderlich ist, hängt vom konkreten Risiko ab, nicht vom Etikett “KI”. Nach Art. 35 Abs. 1 DSGVO ist sie vorab durchzuführen, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Art. 35 Abs. 3 nennt dazu insbesondere drei Fallgruppen: eine systematische und umfassende Bewertung persönlicher Aspekte auf Grundlage automatisierter Verarbeitung einschließlich Profiling, wenn sie als Grundlage für Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung dient; die umfangreiche Verarbeitung besonderer Kategorien personenbezogener Daten oder von Daten über strafrechtliche Verurteilungen und Straftaten; sowie die systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche. Das ist keine pauschale Liste aller KI-Einsätze. Auch die EDPB-Leitlinien zu Datenschutz durch Technikgestaltung betonen, Schutzmaßnahmen früh in die Gestaltung einzubeziehen.

Für die erste Einordnung helfen fünf Fragen: Kann der Chat gezielt besondere Kategorien personenbezogener Daten aufnehmen? Werden Personen bewertet, priorisiert oder mit Folgen für Vertrag, Preis oder Zugang automatisiert eingeordnet? Ist die Zielgruppe besonders schutzbedürftig, etwa Kinder oder Patientinnen und Patienten? Werden große Mengen von Gesprächsdaten dauerhaft ausgewertet? Und lässt sich das Risiko durch Datenminimierung, klare Sperrlisten, Zugriffskontrollen, kurze Löschfristen und eine menschliche Eskalation tatsächlich reduzieren? Bei einem Ja sollten Datenschutzverantwortliche und gegebenenfalls fachkundige Beratung vor dem Start genauer prüfen.

Häufige Fehlerbilder im RAG-Projekt

Nur das Chatfenster beschreiben: Dann fehlen Vektorsuche, Modellaufruf, Protokollierung oder Ticketübergabe. Besser ist eine Station-für-Station-Liste mit Daten, Zweck, Empfänger und Frist.

Eine Auftragsverarbeitung als Endpunkt ansehen: Eine Vereinbarung kann nötig sein, ersetzt aber weder die Rollenprüfung noch Informationen für Betroffene, technische Schutzmaßnahmen oder ein aktuelles Verzeichnis.

Eine Wissensbasis ungeprüft importieren: Alte E-Mail-Exporte und PDF-Sammlungen enthalten oft Namen, Kontaktdaten oder vertrauliche Anlagen. Freigabe, Redigierung und Herkunft müssen vor der Indexierung stattfinden.

Speicherfristen nur für die Originaldatei definieren: Gesprächsverläufe, Fehlerlogs, Backups, Vektorindex und Tickets können unterschiedliche Lebenszyklen haben. Jede Kopie braucht eine nachvollziehbare Regel.

Den Hinweis erst kurz vor dem Go-live schreiben: Dann ist unklar, welche technische Aussage überhaupt stimmt. Ein Testlauf mit einer fiktiven Anfrage zeigt, ob die Dokumentation den realen Weg trifft.

Ein pragmatischer Start für österreichische Unternehmen

Planen Sie zuerst einen kleinen, klar begrenzten Einsatz: öffentlich freigegebene Wissensquellen, keine Datei-Uploads, keine automatische Entscheidung über Menschen, kurze Protokollfristen und eine sichtbare Übergabe an Mitarbeitende. Dokumentieren Sie jede Systemstation in einer Tabelle und lassen Sie Fachbereich und Technik gegenlesen. Danach prüfen Sie Datenschutztext, Verzeichnis, Rollen, Verträge, Zugriffsrechte und Löschkonzept gemeinsam. Erst wenn der Testdatenfluss zur Beschreibung passt, ist der Chatbot bereit für den nächsten Schritt.

Eine sorgfältig gepflegte KI-Chatbot Datenschutzerklärung macht den Dienst nicht automatisch rechtskonform. Sie schafft aber Transparenz über die tatsächliche Verarbeitung und zwingt das Projektteam zu den richtigen Fragen. Für die anschließende, passende Textstruktur bietet der AdSimple Datenschutz Generator eine praktische Grundlage. Bei besonderen Daten, komplexen Übermittlungen oder hohem Risiko sollte die konkrete Ausgestaltung vor dem Start individuell fachlich geprüft werden.

Quellen und weiterführende Grundlagen