DSGVO-konformer KI-Support: Wo eure Kundendaten wirklich landen

"Wenn ich KI in meinen Support lasse, wandern dann die Daten meiner Kunden in eine US-Cloud – und ich verstoße gegen die DSGVO?"

Das ist die Frage, die vermutlich der Grund ist, warum du diesen Artikel liest. Und es ist eine gute Frage. Sie ist nur falsch gestellt.

Die Angst dahinter ist berechtigt. Die zugrunde liegende Vorstellung ("US-Cloud = automatischer DSGVO-Verstoß") stimmt aber so nicht mit dem Gesetz überein, und sie zeigt auch nicht auf das eigentliche Risiko. Das echte Risiko ist nicht geografisch, sondern vertraglich und architektonisch: unklare Subprozessor-Ketten, Training-auf-Kundendaten-Klauseln versteckt in den AGB, und die Abhängigkeit von einem Datentransfer-Konstrukt, das schon zwei Vorgänger auf dem Gewissen hat.

Dieser Artikel dreht die Frage um: nicht "Cloud oder keine Cloud", sondern "Wer verarbeitet was, wo, und unter welchem Vertrag". Danach zeige ich dir, wie ein in Deutschland gehosteter, KI-nativer Helpdesk diese Unklarheit komplett auflöst.

Ein Hinweis vorab: Das ist Einordnung, keine Rechtsberatung. Für den konkreten Einzelfall sprich mit deinem Datenschutzbeauftragten.

Was heute tatsächlich mit euren Kundendaten passiert

Bevor wir über die DSGVO reden, lohnt ein Blick auf den technischen Ablauf. Wenn eine Kundin ein Ticket schreibt und dein Tool eine KI-Funktion darauf loslässt, passiert typischerweise Folgendes:

Das Ticket landet in der Datenbank des Anbieters. Dann greift eine KI-Funktion darauf zu, etwa für einen Antwortvorschlag, eine Zusammenfassung oder eine automatische Klassifizierung. Dafür wird der Inhalt des Tickets an ein Sprachmodell geschickt. Dieses Modell läuft in den meisten Fällen nicht beim Helpdesk-Anbieter selbst, sondern bei einem externen Modellanbieter (OpenAI, Anthropic oder ein eigenes Modell auf AWS, Azure oder GCP). Von dort kommt die generierte Antwort zurück.

Das klingt nach einem einzigen Schritt. Es sind aber mehrere Übergaben, und jede davon ist datenschutzrechtlich relevant.

Die etablierten Tools wurden nicht für EU-Inferenz gebaut

Zendesk, Intercom und Freshdesk haben ihre KI-Features auf Ticketing-Infrastruktur aufgesetzt, die aus einer Zeit stammt, in der EU-Datenresidenz kein Thema war. Die KI-Schicht kam später dazu, oben drauf. Das ist ein Retrofit, kein Neubau.

Was das konkret für die Subprozessoren jedes einzelnen Anbieters bedeutet, solltest du nie aus einem Blogartikel übernehmen. Auch nicht aus diesem. Diese Listen ändern sich häufig. Prüf die aktuelle DPA und Subprozessoren-Liste des jeweiligen Anbieters selbst, bevor du dir eine Meinung bildest. Was sich aber allgemein sagen lässt: Wo KI-Inferenz standardmäßig über US-Hyperscaler läuft, wird die Kette länger und schwerer zu prüfen.

Sub-Processing ist die eigentliche Angriffsfläche

Nicht "die Cloud" als abstraktes Konzept ist das Problem. Es ist die Kette der Beteiligten. Nach Art. 28 DSGVO braucht jeder Subprozessor eine gültige vertragliche Grundlage: der Modellanbieter, der Hosting-Provider, der Logging- und Monitoring-Dienst, der Mailversand.

Je mehr Hände die Daten berühren, desto schwieriger wird das Auditieren. Genau das ist das praktische Argument für einen in Deutschland gehosteten Stack: weniger Glieder in der Kette. Nicht bloß "anderes Land".

Training auf Kundendaten – die Linie, die viele unbemerkt überschreiten

Hier wird es scharf. Wenn die Nutzungsbedingungen eines Anbieters erlauben, eure Support-Konversationen zur Verbesserung ihrer Modelle zu verwenden, dann ist das ein neuer Verarbeitungszweck. Und ein neuer Zweck braucht eine eigene Rechtsgrundlage.

Der Bitkom-Leitfaden zu KI und Datenschutz und die Stellungnahme des EDSA adressieren das direkt: Personenbezogene Daten, die für "die Beantwortung eines Support-Tickets" erhoben wurden, dürfen nicht stillschweigend zu Trainingsdaten für ein Foundation-Model werden. Ein Standard-AVV nach Art. 28 deckt das in der Regel nicht ab.

Das ist einer der konkretesten Prüfpunkte, die du sofort anwenden kannst. Und einer, den viele KMU übersehen, bis es zu spät ist.

Was die DSGVO tatsächlich verlangt (und was nicht)

Jetzt zur Korrektur des Denkfehlers. Die DSGVO verbietet US-Verarbeiter nicht. Sie verlangt Rechenschaft über die gesamte Kette.

Art. 28 verbietet keine US-Prozessoren – er fordert Nachvollziehbarkeit

Das rechtliche Minimum: ein gültiger Auftragsverarbeitungsvertrag (AVV), dokumentierte Subprozessoren und durchsetzbare Weisungen. Ein US-Anbieter mit EU-only-Hosting und einem soliden AVV kann datenschutzrechtlich sauberer aufgestellt sein als ein europäischer Anbieter, der seine Inferenz über einen ungenannten US-Subprozessor schickt.

Diese Nuance geht in den meisten Datenschutz-Diskussionen unter. "US-Firma" und "US-Rechenzentrum" sind nicht dasselbe Risiko. Wer beides in einen Topf wirft, argumentiert an der Realität vorbei.

Zweckbindung und Transparenz – hier werden KI-Tools schlampig

Der Landesdatenschutzbeauftragte Baden-Württemberg formuliert es klar: Daten, die für einen bestimmten Zweck erhoben wurden, dürfen nicht ohne separate Grundlage für einen anderen Zweck verwendet werden. Support-Ticket beantworten und Modell trainieren sind zwei verschiedene Zwecke.

Die EDSA-Stellungnahme vom Dezember 2024 zu KI-Modellen geht noch weiter. Sie behandelt die Frage, wann ein trainiertes Modell selbst als "anonym" gelten kann. Das ist eine technisch-rechtlich ungelöste Frage, die ein fachkundiges Publikum kennen sollte. Wir sind hier nicht in einem Bereich mit sauberen, endgültigen Antworten. Wir sind in einem sich entwickelnden, umstrittenen Feld.

Automatisierte Entscheidungen (Art. 22) – das Schläfer-Thema

Wenn ein KI-System eigenständig entscheidet, eine Rückerstattung abzulehnen, eine Beschwerde zu eskalieren oder einen Kunden als Risiko einzustufen – ohne dass ein Mensch draufschaut – kann das Pflichten aus Art. 22 DSGVO auslösen.

Für den Support-Kontext ist das kaum ausdiskutiert. Nimm es als das, was es ist: ein Punkt für das nächste Gespräch mit deinem Datenschutzbeauftragten, nicht als feststehende Regel. Wichtig ist die Gestaltung deiner Automatisierung. Ein KI-Agent, der Vorschläge macht, die ein Mensch freigibt, ist etwas anderes als einer, der autonom Kundenrechte betrifft.

Der AI Act – weniger dramatisch, als die Schlagzeilen suggerieren

Viele Artikel werfen DSGVO und AI Act zusammen und erzeugen dabei unnötigen Alarm. Die meisten Support-Chatbots fallen unter Art. 50 AI Act in die Kategorie "begrenztes Risiko". Die zentrale Pflicht dort: Transparenz. Nutzer müssen wissen, dass sie mit einer KI sprechen.

Das ist deutlich niedrigschwelliger als die "Hochrisiko"-Kategorie, die die AI-Act-Debatte dominiert. Die Verpflichtungen werden seit Februar 2025 gestaffelt eingeführt, mit unterschiedlichen Fristen für verbotene Praktiken, GPAI-Modelle und Hochrisiko-Systeme (Quelle: IHK-Einordnungen). Ein Support-Chatbot mit einem klaren Hinweis "Du sprichst mit einem KI-Assistenten" erfüllt die Kernpflicht bereits.

Ein ehrlicher Blick auf internationale Datentransfers

Jetzt der Teil, den die meisten Anbieter lieber überspringen.

Seit Juli 2023 gibt es das EU-US Data Privacy Framework (DPF), eine Angemessenheitsentscheidung, die Datentransfers in die USA rechtlich absichert – für Unternehmen, die sich zertifiziert haben. Auf dem Papier ist die Übertragung an einen DPF-zertifizierten US-Anbieter also legal.

Aber schau dir die Historie an. Das DPF ist der dritte Anlauf. Sein Vorgänger, das Privacy Shield, wurde 2020 vom EuGH gekippt (Schrems II). Dessen Vorgänger, Safe Harbor, fiel 2015 (Schrems I). Zwei von zwei Vorgänger-Konstrukten sind vor Gericht gescheitert.

Das ist keine Rechtsberatung, sondern eine ingenieursmäßige Risikoeinschätzung: Nur weil etwas heute legal ist, heißt das nicht, dass es risikoarm ist. Wenn du deine Architektur auf ein Konstrukt stützt, das schon zweimal einkassiert wurde, baust du auf einem Fundament mit bekannter Bruchgeschichte. Und auch das DPF selbst ist juristisch umstritten – ob es einer erneuten Prüfung dauerhaft standhält, ist offen.

Der praktische Ausweg ist unaufgeregt: Wenn die Verarbeitung ohnehin in der EU stattfindet, brauchst du das ganze Transfer-Konstrukt gar nicht. Kein DPF, keine Standardvertragsklauseln, keine Transfer-Impact-Assessment. Das Problem verschwindet, statt vertraglich gemanagt zu werden.

Die fünf Fragen, die du jedem Anbieter stellen solltest

Hier kommt der Teil, den du dir speichern kannst. Bevor du einen KI-Support-Tool kaufst, stell dem Vertrieb genau diese fünf Fragen. Die Antworten trennen Marketing von Substanz.

1. Wo findet die Speicherung statt – und wo die Inferenz?

Das sind zwei verschiedene Fragen, und die meisten Anbieter beantworten nur die erste. Ein Tool kann seine Datenbank brav in Frankfurt hosten und trotzdem jede einzelne KI-Anfrage an eine US-basierte Modell-API schicken.

Das ist die wichtigste, unscheinbarste Erkenntnis dieses ganzen Artikels: Hosting-Standort und Inferenz-Standort sind nicht dasselbe. Frag explizit nach dem Ort der Inferenz, nicht nur nach dem Speicherort. Wenn der Vertrieb ins Stocken gerät, hast du deine Antwort.

2. Gibt es eine aktuelle, veröffentlichte Subprozessoren-Liste?

Kann der Anbieter dir eine vollständige, aktuelle Liste aller Subprozessoren aushändigen – Modellanbieter, Hosting, Monitoring, Mailversand, alles? Wenn nicht, ist das für jede ernsthafte Datenschutz-Folgenabschätzung (DSFA) disqualifizierend.

Eine offene Subprozessoren-Liste ist kein Papierkram. Sie ist ein Vertrauenssignal.

3. Ist "kein Training auf euren Daten" vertraglich garantiert?

Frag konkret: Steht das im AVV oder nur in einem Blogpost, einer FAQ oder auf einer Landingpage? Viele Anbieter sagen es öffentlich, gewährleisten es aber nicht vertraglich. Eine Marketing-Aussage ist im Streitfall nichts wert. Eine Klausel im AVV schon.

4. Wie sieht der AVV konkret aus?

Ist der Auftragsverarbeitungsvertrag verfügbar, unterschriftsreif und vollständig? Deckt er die KI-Verarbeitung ab, nicht nur das klassische Ticketing? Lies ihn, bevor du unterschreibst, oder lass ihn lesen.

5. Wie ist die Automatisierung gestaltet – mit oder ohne Mensch?

Trifft die KI autonome Entscheidungen, die Kundenrechte berühren, oder macht sie Vorschläge, die ein Mensch freigibt? Das ist relevant für Art. 22 und für dein eigenes Risikoprofil.

Diese fünf Fragen sind ein Mini-Audit. Nimm sie mit ins nächste Verkaufsgespräch.

Wie inbrix jeden dieser Punkte beantwortet

Jetzt wird es konkret. inbrix ist als deutsche, DSGVO-konforme Alternative zu Zendesk, Intercom und Freshdesk gebaut. Der Unterschied liegt nicht in einem Datenschutz-Versprechen, sondern in der Architektur. Gehen wir die Checkliste durch.

Speicherung und Inferenz – beides in Deutschland

inbrix wird bei Hetzner in Deutschland gehostet. Die KI-Inferenz läuft in Frankfurt. Beide Fragen aus Punkt 1 haben dieselbe Antwort: Die Daten bleiben in der EU, auch während der KI-Verarbeitung.

Damit entfällt das gesamte Transfer-Problem aus dem DPF-Abschnitt. Kein Umweg über US-Hyperscaler, keine Abhängigkeit von einem Angemessenheitsbeschluss mit Bruchgeschichte.

Self-hosted Monitoring – die Kette bleibt kurz

Das Monitoring läuft selbst gehostet, nicht über einen externen Logging-Anbieter, der wiederum in einer US-Cloud sitzt. Das ist genau das "Kette verkürzen" aus dem Sub-Processing-Abschnitt. Weniger Glieder, weniger Prüfaufwand, weniger Angriffsfläche.

Offene Subprozessoren-Liste

Die Subprozessoren sind offengelegt. Kein Ratespiel, keine Blackbox. Genau das Vertrauenssignal, das Punkt 2 der Checkliste verlangt.

KI-nativ statt KI-nachgerüstet

Und hier liegt der strukturelle Vorteil. Legacy-Plattformen schrauben KI-Features an eine Architektur aus den 2010ern, die alte Subprozessor-Beziehungen und Datenflüsse mitschleppt, die nie für EU-Inferenz gedacht waren.

Ein Neubau kann "EU-only-Inferenz" zum Standard machen, statt zu einem Konfigurations-Schalter, den nie jemand umlegt. KI-nativ zu sein ist hier nicht nur ein Produktvorteil. Es ist ein Compliance-Vorteil. Die autonomen KI-Agenten in inbrix arbeiten mit zwei Guardrails, jeder Bot wie ein echtes Teammitglied, in einer Omnichannel-Inbox aus E-Mail, Chat, Web-Tickets und Shopware.

Was du jetzt tun solltest

Fassen wir die praktischen Schritte zusammen, ohne dass du den ganzen Artikel nochmal lesen musst:

Nimm die fünf Fragen mit ins nächste Anbieter-Gespräch. Frag getrennt nach Speicher- und Inferenz-Standort. Verlange die Subprozessoren-Liste und den AVV vor der Unterschrift, nicht danach. Prüf, ob "kein Training auf euren Daten" vertraglich steht oder nur beworben wird. Und klär mit deinem Datenschutzbeauftragten, ob eure Automatisierung Art. 22 berührt.

Und noch eine Umkehrung des Denkens: DSGVO-Konformität ist für deutsche und europäische Käufer keine lästige Steuer mehr. Sie wird zum Argument, das Deals entscheidet. Laut Bitkom (Erhebung 2026, ein Branchenverband mit eigenem Interesse an dieser Erzählung, entsprechend einzuordnen) sehen sechs von zehn deutschen Unternehmen Datenschutz als Vorteil für die KI-Entwicklung in Deutschland und Europa. Compliance als Positionierung, nicht als Bremse.

Zum Schluss

Wenn dich diese Checkliste bei deinem aktuellen Setup nervös gemacht hat, ist das kein schlechtes Zeichen. Es heißt, du stellst die richtigen Fragen.

inbrix wurde für genau diesen Anspruch gebaut: KI im Support ohne die Datenschutz-Unklarheit. Gehostet in Deutschland, Inferenz in Frankfurt, offene Subprozessoren-Liste, DSGVO-konform von der Architektur her.

Wenn du sehen willst, wie das in deinem Arbeitsalltag aussieht, wirf einen Blick auf inbrix und sichere dir einen Platz im Early Access. Kein Verkaufsdruck – schau es dir an und stell uns die fünf Fragen, die wir dir gerade gegeben haben.