Kundinnen und Kunden erzählen Chatbots weit mehr, als man fragt. Sie tippen Bestellnummern und Lieferadressen ein, beschweren sich über den Paketboten, nennen ihre Medikamente oder den Grund, warum die Lastschrift geplatzt ist. Sobald ein Chatbot oder KI-Assistent live geht, wird es zu einem Ihrer meistgenutzten Systeme mit personenbezogenen Daten – und nach der DSGVO sind Sie dafür verantwortlich, nicht der Modellanbieter.
Das klingt aufwendiger, als es ist. Ein DSGVO-fester Chatbot hängt an einer Handvoll Entscheidungen vor dem Start: Wer verarbeitet was, auf welcher Rechtsgrundlage, wo liegen die Daten, wie lange werden Protokolle gespeichert und was passiert im Ernstfall? Wer diese Punkte sauber klärt, hat mit derselben Dokumentation die Antworten für die Datenschutzbeauftragte, den Einkauf von Großkunden und die Transparenzpflichten der KI-Verordnung.
Warum ein Chatbot ein DSGVO-Projekt ist
Drei Eigenschaften unterscheiden Konversations-KI von einem Kontaktformular:
- Freitext. Sie können nicht steuern, was Menschen eintippen. Besondere Kategorien personenbezogener Daten (Gesundheit, Religion, Herkunft – Art. 9 DSGVO) tauchen auf, ohne dass Sie danach fragen.
- Eine lange Dienstleisterkette. Typisch sind Chat-Widget, Orchestrierung, LLM-API, Vektordatenbank, CRM oder Helpdesk sowie Logging und Analyse. Jedes Glied kann Daten speichern.
- Undurchsichtige Weiterverwendung. Manche KI-Anbieter speichern Prompts zur Missbrauchserkennung oder nutzen sie in Verbrauchertarifen zum Training. Wer das nicht prüft, findet Kundendaten womöglich an Orten, die in keiner Datenschutzerklärung stehen.
Deutsche Unternehmen wissen das. Unter den Firmen, die bereits KI einsetzen, nennen 66 % Datenschutzanforderungen und 45 % das Risiko von Datenabflüssen als Hemmnisse (Bitkom). Ein Bot, der seinen Umgang mit Daten belegen kann, räumt diese Einwände schneller aus als ein etwas klügerer Bot, der das nicht kann.
Schritt 1: Den Datenfluss aufzeichnen
Vor jeder rechtlichen Bewertung zeichnen Sie den Weg einer einzigen Nachricht nach:
- Widget oder Kanal – Website, WhatsApp, Telegram, E-Mail. Seit dem 15. Januar 2026 erlaubt die WhatsApp Business API keine Allzweck-KI-Assistenten mehr; Unternehmens-Bots für eigene Kunden bleiben erlaubt (TechCrunch).
- Orchestrierung – eine Plattform wie Botpress oder Intercom, eine selbst gehostete n8n-Instanz oder eigener Code.
- Modell – die LLM-API, ihre Region und die Frage, ob Prompts gespeichert werden.
- Retrieval – die Vektordatenbank und die darin indexierten Dokumente.
- Aktionen – CRM, Warenwirtschaft, Terminkalender.
- Logs und Analyse – Transkripte, Traces, Fehler-Tracking, Dashboards.
Notieren Sie für jedes Kästchen, welche personenbezogenen Daten ankommen, wo gehostet wird und wie lange gespeichert wird. Diese Skizze ist der Kern Ihres Verzeichnisses von Verarbeitungstätigkeiten (Art. 30) und Ihrer DSFA.
Schritt 2: Rechtsgrundlage je Zweck wählen
Es gibt nicht „die eine Rechtsgrundlage für den Chatbot“. Jeder Zweck braucht seine eigene.
| Zweck | Typische Rechtsgrundlage (Art. 6 DSGVO) | Worauf achten |
|---|---|---|
| Fragen beantworten, Bestellung oder Retoure bearbeiten | Vertrag oder vorvertragliche Maßnahmen, Art. 6 Abs. 1 lit. b | Nur die für die Anfrage nötigen Daten |
| Bestellstatus, Terminbuchung, Kontoänderungen | Vertrag, Art. 6 Abs. 1 lit. b | Vor jeder Auskunft authentifizieren |
| Transkripte auswerten, um Antworten zu verbessern | Berechtigtes Interesse, Art. 6 Abs. 1 lit. f | Interessenabwägung dokumentieren; pseudonymisieren |
| Marketing-Nachfassen, Newsletter-Anmeldung im Chat | Einwilligung, Art. 6 Abs. 1 lit. a | Getrennt, nicht vorausgewählt, nachweisbar |
| Gesundheitsfragen im Praxis-Bot | Zusätzlich Bedingung nach Art. 9 Abs. 2, meist ausdrückliche Einwilligung | Medizinische Themen ggf. ganz ausklammern |
| Training des Anbietermodells mit Ihren Chats | Vermeiden | In Einstellungen und Vertrag ausschließen |
Am saubersten ist ein zweckgebundenes Design: Der Bot beantwortet, bucht und eskaliert – und sagt das gleich zu Beginn des Gesprächs.
Schritt 3: AVV und Kette der Unterauftragsverarbeiter
Jeder Dienstleister, der Gespräche in Ihrem Auftrag verarbeitet, ist Auftragsverarbeiter, und Art. 28 verlangt einen schriftlichen Auftragsverarbeitungsvertrag (AVV). Ein guter AVV mit einem KI-Anbieter regelt:
- Verarbeitung nur auf Ihre dokumentierte Weisung – die das Training mit Ihren Daten ausschließen sollte;
- Vertraulichkeit der Beschäftigten und angemessene technische und organisatorische Maßnahmen (Art. 32);
- eine Liste der Unterauftragsverarbeiter und Ihr Widerspruchsrecht gegen neue;
- Unterstützung bei Betroffenenanfragen und DSFA;
- Löschung oder Rückgabe der Daten bei Vertragsende;
- Meldung von Datenpannen ohne schuldhaftes Zögern, damit Sie Ihre eigene 72-Stunden-Frist einhalten können;
- Prüfrechte oder anerkannte Zertifizierungen.
Stellen Sie jedem KI-Anbieter dieselben fünf Fragen: Trainieren Sie mit unseren Daten? Wie lange speichern Sie Prompts und Ausgaben und wozu? In welchen Regionen werden Daten verarbeitet? Wer sind Ihre Unterauftragsverarbeiter? Wie schnell informieren Sie uns über einen Vorfall? Die Antworten gehören in die Lieferantenakte – und entscheiden oft über die Anbieterwahl.
Schritt 4: Datenresidenz und Drittlandübermittlung
Wer personenbezogene Daten außerhalb des Europäischen Wirtschaftsraums verarbeiten lässt, braucht eine Grundlage nach Kapitel V DSGVO. Bei US-Anbietern ist das meist eine Zertifizierung nach dem EU-US Data Privacy Framework oder Standardvertragsklauseln samt Transfer-Folgenabschätzung. US-Plattformen für Chat und Telefonie werden in Europa üblicherweise so eingesetzt; das funktioniert, bedeutet aber Papierarbeit und ein politisches Risiko, das viele Einkäufer einpreisen. In von Deloitte berichteten Umfragen achten 77 % der Unternehmen auf das Herkunftsland ihres KI-Anbieters, 66 % sorgen sich um die Abhängigkeit von ausländischer KI (DEV Community).
| Option | Aufwand für Übermittlung | Qualität und Kosten | Passt für |
|---|---|---|---|
| US-Modell-API über DPF oder SCC | Transfer-Prüfung, Anbieter-Checks | Spitzenmodelle, Abrechnung pro Token | Support mit wenig sensiblen Daten |
| Großer Anbieter mit EU-Verarbeitungsregion | Geringer; Region vertraglich festhalten | Spitzenmodelle, teils höherer Preis | Die meisten Support-Bots im Mittelstand |
| Open-Weight-Modell (z. B. Mistral) mit EU-Hosting | Keine Übermittlung aus dem EWR | Etwas geringere Qualität, fixe Infrastrukturkosten | Sensible Daten, regulierte Branchen |
| Modell on-premises | Keine | Höchster Aufwand | Strenge Branchenregeln, große Volumen |
Auch die Orchestrierung zählt. Die Community Edition von n8n lässt sich kostenlos auf einem eigenen Server in Deutschland betreiben (n8n); Workflow-Daten und Zugangsdaten bleiben so in Ihrer Infrastruktur. Vor- und Nachteile eigener Modelle beschreiben wir in private und On-Premises-LLMs für europäische Unternehmen.
Schritt 5: Logs – behalten, was nötig ist, den Rest löschen
Protokolle brauchen Sie: um falsche Antworten zu analysieren, um Streitfälle zu klären („Ihr Bot hat mir eine Erstattung zugesagt“), um Missbrauch zu erkennen und – bei Hochrisiko-Systemen nach der KI-Verordnung – um automatisch erzeugte Logs mindestens sechs Monate aufzubewahren. Der Grundsatz der Speicherbegrenzung (Art. 5 Abs. 1 lit. e) schließt „alles für immer“ aber aus.
Ein Löschkonzept, das wir oft als Ausgangspunkt nutzen – anzupassen an Ihre Zwecke und zu dokumentieren:
| Daten | Vorgeschlagene Speicherdauer | Hinweise |
|---|---|---|
| Rohe Transkripte mit Personenbezug | 30–90 Tage | Reicht für Qualitätsprüfung und Reklamationen |
| Eskalierte Gespräche | Wie das zugehörige Ticket im CRM | Bestehende Regeln für Kundenakten anwenden |
| Pseudonymisierte Traces (Prompt, Modell, Latenz, Kosten) | 6–12 Monate | Für Evals, Kostenkontrolle und Fehlersuche |
| Aggregierte Auswertungen | Unbegrenzt | Kein Personenbezug mehr |
| Sicherheits- und Zugriffsprotokolle | Gemäß Sicherheitsrichtlinie | Schützen wie Produktivdaten |
Zwei Techniken verkleinern das Problem erheblich. Maskierung vor dem Modell: E-Mail-Adressen, Telefonnummern, IBANs und Bestellnummern werden ersetzt, bevor der Prompt Ihr System verlässt, und nur dort wieder eingesetzt, wo eine Aktion sie braucht. Eigene Observability: Tracing-Werkzeuge wie Langfuse oder Helicone, die zum Standard guter KI-Teams gehören (HouseofMVPs), lassen sich in Ihrer eigenen Umgebung betreiben – die Traces landen dann nicht bei einem weiteren Anbieter.
Schritt 6: Transparenz und Betroffenenrechte
Ihre Datenschutzerklärung muss den Chatbot abdecken (Art. 13 und 14): Zwecke, Rechtsgrundlagen, Empfänger einschließlich KI-Anbietern, Drittlandübermittlungen, Speicherdauer, Rechte. Zu Beginn des Chats genügt eine kurze Zeile mit Link. Seit dem 2. August 2026 verlangt die KI-Verordnung zusätzlich den Hinweis, dass die Nutzer mit einem KI-System sprechen – ein Satz kann beides leisten. Die KI-Verordnungsseite erklären wir im Leitfaden zur KI-Verordnung für KMU.
Planen Sie Betroffenenanfragen ab dem ersten Tag ein:
- Auskunft (Art. 15) und Löschung (Art. 17) – finden Sie alle Gespräche einer Person in Widget, Logs und CRM? Verknüpfen Sie sie mit einer Kunden-ID.
- Widerspruch (Art. 21) – bei Verarbeitungen auf Basis berechtigten Interesses wie der Qualitätsauswertung beachten.
- Automatisierte Entscheidungen (Art. 22) – trifft der Bot Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung, etwa die Ablehnung einer Erstattung oder eines Kredits, brauchen Sie eine menschliche Überprüfung und eine Erklärung der Logik.
- Frist – ein Monat für die Antwort (Art. 12 Abs. 3).
Schritt 7: Sicherheit gehört zur Compliance
Art. 32 verlangt ein dem Risiko angemessenes Schutzniveau, und das KI-Ökosystem liefert genug warnende Beispiele. Eine Prüfung von 5.600 öffentlich erreichbaren, per „Vibe Coding“ gebauten Apps fand über 2.000 schwere Schwachstellen, 400 offene Geheimnisse und 175 Lecks personenbezogener Daten (SoftwareSeni). Eine KI-Chat-App legte über eine Firebase-Regel, die alles erlaubte, 406 Millionen Datensätze offen (Cloud Security Alliance).
Hinzu kommt Prompt Injection – Anweisungen, versteckt in Nachrichten oder Dokumenten, die das Modell dazu bringen, Daten preiszugeben oder Werkzeuge zu missbrauchen. Selbst OpenAI räumt ein, dass sich das Problem womöglich nie vollständig lösen lässt (Brandon Ta). Die praktische Antwort ist Architektur: dem Bot nur die engsten nötigen Werkzeuge geben, Berechtigungen außerhalb des Modells durchsetzen, keine freien Datenbankabfragen zulassen und Angriffe vor dem Start testen. Mehr dazu in Prompt Injection und Agentensicherheit.
Kommt es doch zu einer Datenpanne, haben Sie nach Art. 33 72 Stunden für die Meldung an die Aufsichtsbehörde. Legen Sie den Ablauf vor dem Start fest, nicht danach.
Wann Sie eine DSFA brauchen
Art. 35 verlangt eine Datenschutz-Folgenabschätzung, wenn eine Verarbeitung voraussichtlich ein hohes Risiko birgt. Typische Auslöser bei Chatbots: neue Technologie in großem Umfang, besondere Datenkategorien, systematische Überwachung, Gesprächsaufzeichnungen und Stimmbiometrie. In der Praxis ist eine DSFA für einen Support-Bot ein kompaktes Dokument: Datenflussskizze, Rechtsgrundlagen, Risiken (falsche Antworten, Lecks, Injection, Übermittlungen) und die Maßnahmen dagegen. Sie ist zugleich das Dokument, das Großkunden in der Due Diligence anfordern.
Praxisbeispiel: Support-Bot für einen Onlineshop
Ein Möbelversender aus Nordrhein-Westfalen verkauft in Deutschland und den Niederlanden und möchte einen Bot für Produktfragen, Sendungsverfolgung und Retouren. So setzen sich die Entscheidungen um:
- Umfang. Produktfragen beantwortet der Bot nur aus dem öffentlichen Katalog – ohne personenbezogene Daten. Für Sendungsstatus und Retoure müssen sich Kunden mit Bestellnummer und Postleitzahl ausweisen, bevor der Bot etwas preisgibt.
- Rechtsgrundlage. Vertrag (Art. 6 Abs. 1 lit. b) für Bestellungen und Retouren; berechtigtes Interesse für die stichprobenartige Auswertung von Transkripten, dokumentiert in einer kurzen Interessenabwägung.
- Dienstleister. Bot-Orchestrierung auf einem eigenen Server in Deutschland, das LLM über eine EU-Verarbeitungsregion, Shopsystem und Helpdesk mit bestehenden AVVs. Training mit Shopdaten vertraglich ausgeschlossen.
- Maskierung. Namen, Adressen und Telefonnummern werden vor dem Prompt ersetzt; die Bestellabfrage erledigt der Code, nicht das Modell.
- Logs. Rohe Transkripte 60 Tage, pseudonymisierte Traces ein Jahr, Eskalationen beim Helpdesk-Ticket.
- Transparenz. Erste Nachricht, auf Deutsch oder Niederländisch je nach Shopversion: „Ich bin der KI-Assistent des Shops. Wie wir mit Ihren Daten umgehen, steht in unserer Datenschutzerklärung. Tippen Sie ‚Mitarbeiter‘, um mit einem Menschen zu sprechen.“ – mit verlinkter Datenschutzerklärung.
Nichts davon ist exotisch. Es ist Designarbeit, die einmal am Anfang erledigt wird, statt sie unter Druck nachzurüsten, wenn der erste Großkunde oder die erste Auskunftsanfrage kommt.
Typische Fehler
- Verbraucherkonten von KI-Diensten für den Unternehmens-Bot. Verbraucherbedingungen erlauben oft Training mit Eingaben und bieten keinen AVV.
- Kein Überblick über Unterauftragsverarbeiter. Die Datenschutzerklärung nennt einen Anbieter, tatsächlich verarbeiten fünf die Daten.
- „Alle Logs behalten, man weiß ja nie.“ Unbegrenzte Speicherung verstößt gegen die Speicherbegrenzung und macht jede Panne groß.
- Das Modell entscheiden lassen, wer was sehen darf. Berechtigungen gehören in den Code, nicht in den Prompt.
- Gesundheitsdaten als Randfall behandeln. In Praxen, Versicherungen oder HR sind sie der Normalfall – also einplanen oder ausklammern.
- Den Weg zum Menschen vergessen. Ohne Eskalation an eine Person holen Sie Art. 22 und verärgerte Kunden ein.
Fazit
Ein DSGVO-konformer Chatbot ist kein Spezialprodukt, sondern ein normales Produkt, das mit Disziplin gebaut wurde: Datenfluss skizziert, Rechtsgrundlage je Zweck, AVV mit jedem Auftragsverarbeiter, bewusste Wahl des Datenstandorts, Löschkonzept, Maskierung vor dem Modell und ein Plan für Datenpannen. Am Anfang getroffen, kosten diese Entscheidungen Tage statt Monate – und sie halten Ihnen Optionen offen, denn Daten, die Sie kontrollieren, können Sie auch mitnehmen. Genau darum geht es in KI selbst besitzen und Vendor-Lock-in vermeiden.
Lotus Libre entwickelt KI-Agenten für Support und Vertrieb und die Systeme drumherum – mit EU-Hosting, Maskierung, Protokollierung und AVV-fertiger Dokumentation. Sie möchten einen zweiten Blick auf Ihren bestehenden oder geplanten Bot? Buchen Sie ein kostenloses 15-Minuten-Audit.
Dieser Artikel dient der allgemeinen Information und ist keine Rechtsberatung. Für Entscheidungen in Ihrem konkreten Fall wenden Sie sich an eine qualifizierte Rechtsanwältin, einen Rechtsanwalt oder Ihre Datenschutzbeauftragten.