DSGVO-konforme KI auf der Website ist möglich – aber nie als Pauschalantwort, und nie durch das Einbinden eines Chatbots aus den USA. Wer eine klare Linie sucht, bekommt sie, sobald er zwei Fragen sauber trennt: Wohin fließen die Daten, und woher stammen sie.
In jedem zweiten Gespräch der letzten zwölf Monate kommt diese Frage in irgendeiner Form: „Können wir KI auf unserer Website einsetzen, ohne mit der DSGVO in Konflikt zu geraten?" Wir sind keine Anwälte und ersetzen keine Rechtsberatung. Aber wir bauen seit zwei Jahren KI-gestützte Funktionen in B2B-Websites – Lead-Qualifizierung, Content-Generierung, semantische Suche – und haben sehr konkret damit gerungen, was technisch und vertraglich nötig ist, damit das im europäischen Rahmen trägt. Wer am Ende rechtliche Sicherheit braucht, spricht trotzdem mit einer Anwältin. Aber dann mit deutlich konkreteren Fragen.
Warum „DSGVO-konforme KI" so selten klar beantwortet wird
Die Frage bleibt offen, weil sie zwei Dinge vermischt, die getrennt gehören. Die erste Bruchlinie ist der Datenfluss: Welche Daten fließen, wohin, und wer verarbeitet sie? Daraus folgt, ob Sie eine Auftragsverarbeitung brauchen, ob ein Drittlandtransfer stattfindet, ob Standardvertragsklauseln greifen müssen. Die zweite Bruchlinie ist die Datenherkunft: Wessen Daten dürfen überhaupt verarbeitet werden, und landen sie in den Trainingsdaten eines Modells?
Wer diese beiden Achsen anlegt, sortiert jeden Use-Case in eine von vier Kategorien: unproblematisch, einwilligungspflichtig, vertraglich abzudecken – oder besser gar nicht. Das ersetzt das Bauchgefühl durch eine Entscheidungslogik, die Sie auch vor dem Datenschutzbeauftragten oder dem Vorstand verteidigen können.
Die vier Kategorien für jeden KI-Use-Case
Fall 1: Server-seitige KI ohne personenbezogene Daten. Ein Schlagwort-Generator, eine Übersetzung, eine Zusammenfassung redaktioneller Inhalte. Hier ist die DSGVO nicht der Engpass, weil schlicht kein Personenbezug entsteht. Trotzdem gilt: Anbieter mit europäischer Server-Region (Anthropic Claude, OpenAI über Azure EU, Mistral, Aleph Alpha), ein sauberer Auftragsverarbeitungsvertrag, eine disziplinierte API-Schlüsselverwaltung. Das ist die unproblematische Kategorie – und der überwiegende Teil dessen, was Marketing-Abteilungen tatsächlich wollen, fällt hier hinein.
Fall 2: KI mit Nutzerdaten in Echtzeit. Chatbot, semantische Suche, Lead-Qualifizierung. Sobald die IP-Adresse oder der Eingabeinhalt an einen externen LLM-Anbieter fließt, verarbeiten Sie personenbezogene Daten. Was hier trägt: ein dokumentierter Datenflussplan, ein Auftragsverarbeitungsvertrag mit dem LLM-Anbieter, eine transparente Datenschutzerklärung, die Anbieter und Art der Daten benennt, und eine echte Einwilligung für KI vor der Aktivierung – kein vorausgewähltes Banner. Sitzt der Anbieter außerhalb der EU, kommen Standardvertragsklauseln und eine Drittlandtransfer-Bewertung nach Schrems II hinzu. Das ist die einwilligungspflichtige, vertraglich abzudeckende Kategorie.
Fall 3: KI mit langfristiger Datenspeicherung. Konversationen, die „lernen", Profile, Personalisierung. Hier greifen Zweckbindung, Datensparsamkeit, Speicherbegrenzung und das Recht auf Auskunft und Löschung mit voller Wucht. Pseudonymisieren oder anonymisieren Sie, wo es geht. Definieren Sie Speicherzeiten und erzwingen Sie sie automatisch. Und – der Punkt, an dem es technisch ernst wird – halten Sie einen Löschpfad bereit, der auch Embeddings im Vector-Store und die Konversationshistorie erfasst. Wer pgvector als KI-Backend einsetzt, muss diesen Pfad mitdenken, sonst bleibt die Löschung Theorie; wir haben die Architektur dahinter an anderer Stelle ausführlich beschrieben.
Fall 4: KI, die wir nicht empfehlen. Dazu gleich ein eigener Abschnitt – diese Kategorie verdient mehr als eine Zeile.
Der oft übersehene Punkt: Trainingsdaten
Werden die an einen LLM-Anbieter geschickten Daten zum Training verwendet? Bei den großen Anbietern – OpenAI, Anthropic, Google – ist die Antwort in B2B-, API- und Enterprise-Tarifen standardmäßig nein. In Consumer-Tarifen nicht, und die Praxis kann sich ändern. Genau deshalb gehört der Trainingsausschluss vor jeder Integration in den Vertrag und nicht in die Annahme.
Wir bevorzugen Anbieter, die den Trainingsausschluss als Standard kommunizieren, statt ihn als Premium-Option zu verkaufen. Das ist kein Detail für die Rechtsabteilung, sondern ein Argument, das direkt in die Datenschutzerklärung wandert und das Sie gegenüber Kunden vertreten können. Wer hier auf den Goodwill eines US-Anbieters baut, baut auf Sand – die Diskussion, ob europäische Daten auf US-Infrastruktur überhaupt sicher liegen, ist nicht abgeschlossen, Stichwort CLOUD Act und die Frage nach der Datensouveränität.
Welche KI-Funktionen man bewusst nicht baut
Hier wird die ehrliche Antwort unbequem. Drei Klassen von Funktionen lassen sich technisch bauen, sollten es aber nicht.
Emotionsanalyse und verhaltensbasiertes Profiling über Webcam, Mikrofon oder Eingabemuster erzwingen fast immer eine Datenschutz-Folgenabschätzung, sind schwer zu bestehen und gesellschaftlich negativ aufgeladen. Der EU AI Act verschärft diese Linie zusätzlich: Emotionserkennung am Arbeitsplatz und im Bildungskontext fällt unter die verbotenen Praktiken, und biometrische Kategorisierung gilt als Hochrisiko-Anwendung mit erheblichen Pflichten. Sie addieren also eine zweite Regulierungsdimension oben auf die DSGVO – Stand Mitte 2026, die Übergangsfristen sind zu prüfen.
Die dritte Klasse sind vollautomatisierte Entscheidungen mit rechtlicher Wirkung – etwa ein Lead-Scoring, das Zugang oder Konditionen steuert. Das ist der Anwendungsbereich von Art. 22 DSGVO, der solche Entscheidungen grundsätzlich an enge Bedingungen knüpft. Unsere Empfehlung in allen drei Fällen: Prüfen Sie zuerst, ob das Geschäftsziel ohne diese Mechanik erreichbar ist. In neun von zehn Fällen ist es das.
Und dann ist da der wirklich schwierige Teil, der in keiner Vertragsvorlage steht: der Löschpfad. Eine Löschanfrage nach Art. 17 DSGVO muss die Daten überall erreichen – in der Hauptdatenbank, in der Konversationshistorie und in den Embeddings des Vector-Stores. Genau dort scheitern Systeme in der Praxis, weil der Vector-Store als nachgelagerter Index oft vergessen wird. Dazu kommt, dass die Rechtslage selbst in Bewegung ist: Das Verhältnis von Data Privacy Framework und Schrems, die Trainingspraxis der Anbieter, die Auslegung des AI Act – nichts davon ist endgültig sortiert. Wer hier auf einen Stichtag baut, baut falsch.
Das pragmatische Vorgehen vor jeder Integration
Bevor eine Zeile Integrationscode entsteht, beantworten wir fünf Fragen in dieser Reihenfolge. Erstens: Welche Daten fließen wirklich – vom Klick bis zur Antwort lückenlos aufgezeichnet? Zweitens: Welcher Anbieter, europäisch gehostet und mit Trainingsausschluss? Drittens: Welche Vertragsgrundlage – AVV, gegebenenfalls Standardvertragsklauseln, Drittlandtransfer-Bewertung? Viertens: Welche Einwilligung, technisch erzwungen vor Aktivierung? Fünftens: Wie sieht der Löschweg aus – wo liegen die Daten überall, und wie kommen sie restlos weg?
Der fünfte Punkt ist der am häufigsten vergessene und gleichzeitig der beste Lackmustest für die technische Reife eines Teams. Wer den Löschpfad nicht zeichnen kann, hat die Architektur nicht verstanden. Dieselbe Frage nach Datenhoheit und Speicherort stellt sich übrigens schon eine Ebene tiefer, beim Backend selbst – welche Architektur diese Kontrolle überhaupt ermöglicht, behandeln wir auf unserer Übersicht zur Supabase-Architektur.
Was ich Entscheidern rate
Verlassen Sie sich nicht auf die Compliance-Aussage eines einzelnen Anbieters, sondern auf eine Architektur, die drei Dinge erzwingt: den Trainingsausschluss im Vertrag, die Einwilligung technisch vor der Aktivierung, und einen Löschpfad, der jeden Speicherort bis in den Vector-Store erreicht. Diese drei Hausaufgaben sind nicht verhandelbar – sie entscheiden, ob das System rechtlich betreibbar bleibt, wenn die Rechtslage sich das nächste Mal verschiebt.
Der Rest ist Sortierarbeit. Trennen Sie Datenfluss und Datenherkunft, ordnen Sie jeden Use-Case in die vier Kategorien ein, und streichen Sie die vierte ohne Diskussion. Wer so vorgeht, betreibt KI auf der Website nicht trotz der DSGVO, sondern in einer Form, die er vor dem Vorstand und vor der Aufsichtsbehörde gleichermaßen vertreten kann. Das ist kein juristisches Kunststück, sondern Engineering-Hygiene.
