Was geschieht, wenn Chatbot-Daten an einen externen KI-Anbieter gesendet werden?

💡 Kurzfassung: Kernaussagen

• Wenn Sie Chatbot-Daten nicht in Ihren eigenen Systemen speichern, verschwinden die an einen externen Modellanbieter gesendeten Daten nicht. Erreicht die Nachricht des Nutzers den Anbieter, müssen die Verarbeitung und in vielen Fällen auch die Übermittlung weiterhin bewertet werden.
• „Wir verwenden Kundendaten nicht für das Modelltraining“ reicht allein nicht aus. Rechtliche Rolle, Zweck, Aufbewahrung, Unterauftragsverarbeiter, Sicherheitsmaßnahmen, internationale Übermittlungen und Hinweise an Nutzer müssen getrennt geprüft werden.
• Maskierung kann eine nützliche Kontrolle sein, ist aber nicht immer Anonymisierung. Kann der Kontext die Person weiterhin identifizieren, bleiben die Informationen möglicherweise personenbezogene Daten.
• Gesundheits-, Finanz- und Kinderdaten sowie andere sensible Daten verändern den Maßstab. Dieselbe Chatbot-Architektur kann für einen Hotelanwendungsfall vertretbar sein und im Medizintourismus eine deutlich strengere Prüfung verlangen.

Ein Gast beginnt ein Gespräch mit einem Hotel-Chatbot und fragt nach Zimmertypen. Danach nennt er Reisedaten. Anschließend schreibt er: „Mein Ehepartner reagiert empfindlich auf Gluten. Gibt es beim Frühstück geeignete Angebote?“ Dieselbe Architektur kann bei einem Medizintourismus-Unternehmen eine ganz andere Nachricht erhalten: „Ich heiße Ayşe. Ich hatte bereits diese Operation. Kann ich Ihnen ein Foto schicken?“

Das Unternehmen speichert vielleicht keines dieser Gespräche in seiner eigenen Datenbank. Es kann dem Nutzer sogar mitteilen: „Wir bewahren Ihre Nachrichten nicht in unserem System auf.“

Diese Aussage kann stimmen und dennoch unvollständig sein.

Wenn der Chatbot das Gespräch an OpenAI, Anthropic, Gemini, einen in China ansässigen Modelldienst oder einen anderen externen Anbieter sendet, um eine Antwort zu erzeugen, haben die Daten das System des Unternehmens verlassen. Name, Telefonnummer, E-Mail-Adresse, Buchungsangaben, Reisepläne, gesundheitliche Beschwerde oder Foto des Nutzers befinden sich dann nicht mehr nur in der Anwendung des Unternehmens.

An diesem Punkt werden DSGVO und die türkische KVKK relevant. Ob das Unternehmen die Daten speichert, ist wichtig. Dass es sie nicht im eigenen System speichert, ändert jedoch nichts an der Übermittlung an einen externen Anbieter. Zweck, Anbieter, Bedingungen und Schutzmaßnahmen dieser Übermittlung müssen gesondert geprüft werden.

Dies ist der datenschutzrechtliche Teil der Reihe zum EU AI Act. Das Thema ist nicht der EU AI Act selbst. Wie der vorherige Beitrag erläutert, kann jedoch selbst ein nach dem EU AI Act als risikoarm eingestufter Chatbot ernsthafte Fragen nach DSGVO und KVKK aufwerfen, sobald er personenbezogene Daten verarbeitet.

Zuerst den Datenfluss sichtbar machen

Der erste Fehler in einem Chatbot-Projekt besteht häufig darin, mit der Modellwahl zu beginnen. Im Datenschutz gibt es einen ähnlichen Fehler: „Welcher Anbieter ist sicherer?“ zu fragen, bevor der Datenfluss erfasst wurde.

Schreiben Sie zunächst auf, welchen Weg das Gespräch nimmt.

Über welchen Kanal kommt der Nutzer? Website, Landingpage, WhatsApp, Instagram-Direktnachricht und eine Callcenter-Oberfläche sind nicht dasselbe. Erreicht die Nachricht zuerst den Server des Unternehmens? Liegen dazwischen ein CRM, ein Live-Chat-Werkzeug, eine Automatisierungsplattform oder ein Messaging-Anbieter? Welche Modell-API erhält die Nachricht anschließend? Wo wird die Antwort des Modells protokolliert? Wer kann zur Fehlersuche, Qualitätskontrolle, Sicherheit oder Missbrauchsprüfung darauf zugreifen?

Ohne diese Karte sagt „Wir sind DSGVO-konform“ sehr wenig aus.

Die Grundsätze der DSGVO sind Rechtmäßigkeit, Verarbeitung nach Treu und Glauben und Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Sicherheit und Rechenschaftspflicht. Sie gelten für die Verarbeitung, nicht nur für Einträge in einer Datenbank.

Auch die KVKK verlangt, dass personenbezogene Daten für festgelegte, eindeutige und rechtmäßige Zwecke verarbeitet werden, für diese Zwecke relevant, begrenzt und verhältnismäßig bleiben und nur so lange gespeichert werden, wie es das Gesetz oder der Verarbeitungszweck erfordert. Der Leitfaden der türkischen Behörde zu generativer KI und Schutz personenbezogener Daten betont außerdem, dass Verantwortliche diese Risiken über den gesamten Lebenszyklus berücksichtigen sollten.

Die praktische Frage ist einfach: Welche Informationen benötigt der Chatbot tatsächlich für seine Antwort? Muss alles, was ein Nutzer eingibt, das Modell erreichen? Muss das System eine vollständige Buchungsnummer, Telefonnummer oder medizinische Vorgeschichte wortgetreu verwenden? Das sind Fragen der Produktgestaltung.

Welche Rolle hat der Modellanbieter?

Nach der DSGVO kann ein Unternehmen, das Zwecke und Mittel der Verarbeitung festlegt, Verantwortlicher sein. Eine Partei, die Daten in seinem Auftrag verarbeitet, kann Auftragsverarbeiter sein. Legen zwei Parteien Zwecke und Mittel gemeinsam fest, kann eine gemeinsame Verantwortlichkeit entstehen. Die Unterscheidung zwischen Datenverantwortlichem und Datenverarbeiter in der KVKK führt zu einer vergleichbaren betrieblichen Frage.

Nutzt ein Unternehmen eine Modell-API für seine Kunden, bestimmt es häufig den Zweck des Chatbots. Je nach Vertrag, Produkt und Bedingungen der Datennutzung kann der Modellanbieter als Auftragsverarbeiter handeln.

Davon darf man nicht einfach ausgehen. Vertrag und Produkteinstellungen müssen gelesen werden.

Mit Stand vom 31. August 2026 erklärt OpenAI, dass Daten von Business- und API-Kunden standardmäßig nicht für das Modelltraining verwendet werden. Das Unternehmen beschreibt eine Aufbewahrung von API-Eingaben und -Ausgaben von bis zu 30 Tagen, vorbehaltlich benannter Ausnahmen, sowie Zero-Data-Retention-Optionen für berechtigte Kunden.

Anthropic erklärt ebenfalls, Ein- und Ausgaben kommerzieller Produkte und der API standardmäßig nicht für das Modelltraining zu verwenden. Die Dokumentation zur Aufbewahrung bei der Claude API beschreibt gesondert Zero-Data-Retention-Vereinbarungen und funktions- oder modellspezifische Ausnahmen.

Diese Informationen sind wertvoll. Zwei weitere Fragen beantworten sie allein nicht.

Erstens bedeutet der Verzicht auf Training nicht, dass die Daten nicht verarbeitet werden. Begrenzte Verarbeitung oder Aufbewahrung kann weiterhin für Sicherheitsklassifizierung, Missbrauchserkennung, technischen Betrieb, Fehlersuche, Support oder rechtliche Verpflichtungen stattfinden.

Zweitens unterliegen möglicherweise nicht alle Produkte und Funktionen demselben Datenregime. Verbraucher-Chat, API, Dateiupload, Stapelverarbeitung, Werkzeugnutzung, Codeausführung, Suchintegration und Fine-Tuning können unterschiedliche Folgen für Aufbewahrung und Zugriff haben.

„Wir nutzen OpenAI“ oder „Wir nutzen Anthropic“ ist daher keine Compliance-Prüfung. Das Unternehmen muss wissen, welches Produkt, welcher Vertrag, welche Einstellung, welcher Endpunkt, welche Verarbeitungsregion und welche Datenkategorie betroffen sind.

Maskierung ist keine Anonymisierung

Der sauberste Weg, keine personenbezogenen Daten zu senden, ist, sie gar nicht erst zu erheben. Bei einem Chatbot ist das nicht immer einfach.

Nutzer geben Namen und Telefonnummern ein. In einem Hotelkontext können sie Flugzeiten, das Alter ihrer Kinder oder Allergien nennen. Gespräche im Medizintourismus können deutlich weitergehen: medizinische Vorgeschichte, Fotos, Medikamente, Operationsdetails, Berichte, Symptome und Erwartungen können in einem einzigen Austausch vorkommen.

Drei Begriffe sollten nicht verwechselt werden.

Anonymisierung bedeutet, dass Informationen keiner Person mehr zugeordnet werden können. Wird dieses Niveau tatsächlich erreicht, können die Daten außerhalb des Datenschutzrechts liegen. In Gesprächstexten erschweren jedoch mehrere kontextuelle Hinweise eine echte Anonymisierung.

Pseudonymisierung bedeutet, direkt identifizierende Informationen zu trennen oder zu ersetzen. Nach der DSGVO ist sie eine wichtige Maßnahme für Sicherheit und Risikoreduzierung, hebt den Personenbezug allein aber nicht auf. Der Ansatz des Europäischen Datenschutzausschusses zur Pseudonymisierung erinnert Organisationen daran, dass Daten personenbezogen bleiben, wenn sie mithilfe zusätzlicher Informationen wieder einer Person zugeordnet werden können.

Maskierung ist eine praktische Produktkontrolle. Aus „Ayşe Yılmaz“ kann „Kunde 123“ werden. Ein System kann nur die letzten vier Stellen einer Telefonnummer, eine Altersspanne statt des vollständigen Geburtsdatums oder eine Buchungsart statt der Hotelzimmernummer senden. Das unterstützt Datenminimierung und kann das Risiko einer Re-Identifizierung sowie die Folgen einer Datenschutzverletzung senken.

Identifiziert der übrige Gesprächsverlauf die Person, ist Maskierung jedoch keine Anonymisierung.

Ein Beispiel: „Ich bleibe ab 10. September zwei Nächte, komme um 23:40 Uhr aus Istanbul an, und mein Ehepartner reagiert empfindlich auf Gluten.“ Das Entfernen des Namens verhindert möglicherweise nicht, dass die Nachricht mit dem Buchungssystem abgeglichen wird. Im Medizintourismus können Aussagen wie „Ich hatte diese Operation vor drei Jahren, reise aus diesem Land an und habe bereits diesen Arzt kontaktiert“ für eine Identifizierung genügen.

Die bessere Frage lautet deshalb nicht nur, ob maskiert wird. Sie lautet: Welche personenbezogenen Daten benötigt das Modell tatsächlich für die Aufgabe, und wie schließt das System unnötige Details systematisch aus?

Kann lokale Vorverarbeitung helfen?

Ja, in vielen Fällen. Allein ist sie keine vollständige Lösung.

Bevor das Gespräch an einen externen Anbieter geht, kann ein Unternehmen es durch ein lokales Modell oder eine regelbasierte Schicht leiten. Diese Schicht kann versuchen, Namen, Telefonnummern, E-Mail-Adressen, Identitätsnummern, Buchungsreferenzen, Gesundheitsbegriffe oder Fotos zu erkennen. Anschließend sendet sie nur den notwendigen Kontext an das Hauptmodell.

Beim Hotelbeispiel muss das Modell möglicherweise nur wissen: „Der Gast fragt, ob glutenfreie Frühstücksoptionen verfügbar sind.“ Name, Telefonnummer und Buchungscode können unnötig sein.

Im Gesundheitsbereich ist es schwieriger. Manche Gesundheitsinformationen können für eine nützliche Antwort erforderlich sein. Ein möglicher Patient kann außerdem eine sehr spezifische Situation beschreiben, die ihn schon für sich genommen identifiziert. Lokale Vorverarbeitung kann weiterhin helfen. Die Behauptung „Wir senden keine personenbezogenen Daten mehr“ wäre dennoch riskant.

Die lokale Schicht schafft an drei Stellen Wert.

Erstens Datenminimierung: Nur notwendige Informationen erreichen das Hauptmodell.

Zweitens Durchsetzung von Regeln: Erkennt das System Kinderdaten, Zahlungsangaben, Identitätsnummern oder Gesundheitsfotos, kann es das Gespräch stoppen oder an einen Menschen übergeben.

Drittens Evidenz: Das Unternehmen kann zeigen, welche Daten am Verlassen des Systems gehindert wurden und unter welchen Bedingungen eine menschliche Übergabe ausgelöst wurde.

Die Schicht ist selbst eine Verarbeitungstätigkeit. Sie kann fehlschlagen, Protokolle speichern oder personenbezogene Daten übersehen. Deshalb sollte sie als Datenschutz-Gateway in der Produktarchitektur gestaltet und getestet werden.

Internationale Übermittlung kann unvermeidbar sein

Verarbeitet der externe Modellanbieter Daten außerhalb der Türkei oder der EU, stellen sich Fragen zur internationalen Übermittlung.

Nach der DSGVO unterliegen Übermittlungen personenbezogener Daten an Drittländer oder internationale Organisationen Kapitel V der DSGVO. Angemessenheitsbeschlüsse, geeignete Garantien, Standardvertragsklauseln und gegebenenfalls Transferfolgenabschätzungen können relevant werden.

Nach Änderungen, die am 1. Juni 2024 in Kraft traten, umfasst der türkische Rahmen für internationale Datenübermittlungen Angemessenheitsbeschlüsse, geeignete Garantien, Standardverträge, verbindliche Unternehmensregeln und begrenzte Fälle gelegentlicher Übermittlung. Wird der Weg über Standardverträge gewählt, gehört auch die Benachrichtigung der Behörde innerhalb von fünf Arbeitstagen zum Verfahren.

„Der Anbieter ist DSGVO-konform“ reicht nicht. Das Unternehmen muss den Rechtsmechanismus der eigenen Übermittlung, die Rollen der Beteiligten, Datenkategorien, Unterauftragsverarbeiter, technischen und organisatorischen Maßnahmen sowie die Aufbewahrungsdauer kennen.

Auch die Lieferkette zählt. Ein Modellanbieter kann die Infrastruktur eines anderen Cloud-Anbieters nutzen. Bestimmte Funktionen können in verschiedenen Ländern verarbeitet werden. Manche Produkte bieten Datenresidenz oder regionale Verarbeitung, andere nicht.

Die Beschaffungsfrage reicht deshalb über eine Funktionsliste hinaus: Kann der Anbieter die Informationen und vertraglichen Zusagen liefern, die Sie für Ihre Datenschutzdokumentation benötigen?

Gesundheits- und andere sensible Daten verändern den Maßstab

Ein Hotel-Chatbot und ein Chatbot für Medizintourismus sollten nicht dieselbe Datenschutzprüfung erhalten.

Gesundheitsdaten sind nach der KVKK besondere Kategorien personenbezogener Daten. Die Erläuterung der Behörde zu besonderen Kategorien personenbezogener Daten stellt fest, dass sie strengeren Schutz benötigen und nur unter begrenzten Bedingungen verarbeitet werden dürfen. Auch die DSGVO unterstellt Gesundheitsdaten einem anspruchsvolleren Regime für besondere Kategorien.

Im Medizintourismus stellt eine Person häufig mehr als Kontaktdaten bereit. Sie beschreibt Symptome, teilt Fotos, spricht über frühere Operationen und Medikamente und erklärt Erwartungen oder manchmal ihren psychischen Zustand. Diese Angaben können innerhalb eines Vertriebsprozesses auftauchen. Aus Sicht des Datenschutzes sind sie trotzdem keine leichten Daten.

Vor dem Start eines Gesundheits-Chatbots sollten daher folgende Entscheidungen getroffen werden:

• Ab welchem Punkt kann ein Nutzer allgemeine Informationen erhalten, ohne Gesundheitsdaten zu teilen?
• Wann sind klare und gesonderte Informationen erforderlich?
• Welche Daten dürfen niemals an das Hauptmodell gesendet werden?
• Über welchen Kanal sollen Fotos, Berichte und Krankengeschichten erfasst werden?
• Welche Antworten bleiben allgemeine Informationen, und welche gehören in die Hände medizinischen Fachpersonals?
• Kann der Modellanbieter die vertraglichen, sicherheitstechnischen und übermittlungsbezogenen Anforderungen für besondere Kategorien und Gesundheitsdaten erfüllen?

Das sind nicht nur Fragen des Rechtsrisikos. Schlechte Führung, falsche Erwartungen, eine verpasste Übergabe oder unnötige Datenerhebung können auch das Vertrauen eines möglichen Patienten beschädigen.

Der nächste Beitrag der Reihe behandelt KI im Gesundheitswesen deshalb gesondert. Er ergänzt die hier erörterten Datenschutzfragen um die Grenzen von Medizinprodukten, Triage, Diagnose, Behandlung, menschlicher Aufsicht und den Betrieb im Medizintourismus.

Was sollte der Nutzer erfahren?

Ein Transparenzhinweis sollte mehr sagen als „Dieser Chatbot verwendet KI.“

Der Nutzer sollte verstehen können, wer seine Nachrichten zu welchem Zweck verarbeitet, ob sie an einen externen Anbieter gesendet werden, welche Datenkategorien er nicht teilen sollte, wie lange die Daten gespeichert oder nicht gespeichert werden, wie er seine Rechte ausübt und wie er bei Bedarf mit einem Menschen fortfahren kann.

Diese Informationen in Kleinschrift unter dem Chatbot zu platzieren, reicht als Produktverhalten selten aus. Der Hinweis sollte erscheinen, bevor ein Nutzer persönliche oder sensible Informationen eingibt. Bei Zahlungskartendaten, Identitätsnummern, Gesundheitsfotos oder Kinderdaten sollte das System den Nutzer führen und das Gespräch nötigenfalls stoppen.

Gute Produktgestaltung und Datenschutz treffen sich am selben Punkt: Der Nutzer sollte wissen, wem er was mitteilt.

Eine praktische Checkliste für Unternehmen

Bevor ein Chatbot mit einem externen KI-Anbieter verbunden wird, sollten folgende Fragen beantwortet werden:

Diese Tabelle ist keine vollständige Rechtsdokumentation. Sie macht das tatsächliche System sichtbar.

Einer der gefährlichsten Sätze in einem Chatbot-Projekt lautet: „Wir speichern die Daten nicht.“

Vielleicht tun Sie das tatsächlich nicht. Erreicht die Nachricht des Nutzers jedoch ein externes Modell, ist die Datenschutzfrage des Unternehmens nicht beendet. Sie hat nur den Ort gewechselt.

Ein besserer Ausgangssatz lautet:

Welche Daten verlassen das System während dieses Gesprächs, müssen sie das wirklich, und welche Evidenz zeigt, dass wir damit angemessen umgehen?

Dieser Artikel bietet allgemeine Informationen und ist keine Rechtsberatung für ein bestimmtes System oder Unternehmen.