DSGVO-konforme KI: Was rechtssicher wirklich bedeutet
Eine DSGVO-konforme KI ist keine Eigenschaft eines Modells, sondern das Ergebnis einer Architektur- und Vertragsentscheidung. Wer KI im Unternehmen einsetzt und dabei personenbezogene Daten verarbeitet, und das passiert schneller als gedacht, etwa in E-Mails, Verträgen, Support-Tickets oder Bewerbungen, muss dieselben Pflichten erfüllen wie bei jeder anderen Datenverarbeitung. Die Frage "KI DSGVO: dürfen wir das?" lässt sich nicht pauschal beantworten, sondern entlang konkreter Artikel der Verordnung. Dieser Beitrag ordnet die wichtigsten Pflichten ein und zeigt, warum souveränes Self-Hosting auf eigenen Servern ein besonders sauberer Weg zu einer wirklich datenschutzkonformen KI ist.
Wichtig vorab: Beyonetix berät und baut entlang dieser Rahmenwerke, ist aber keine Rechtsberatung. Wir besitzen keine ISO- oder BSI-Zertifizierungen und geben keine Konformitäts- oder Rechtsgarantie. Die folgenden Punkte ersetzen keine juristische Prüfung im Einzelfall; eine verbindliche Bewertung gehört in die Hände Ihres Datenschutzbeauftragten oder einer auf Datenschutzrecht spezialisierten Anwältin bzw. eines Anwalts. Wir strukturieren hier die technischen und organisatorischen Weichenstellungen, die in der Praxis über Konformität mitentscheiden.
Rechtsgrundlage, Auftragsverarbeitung und der Drittlandtransfer
Jede Verarbeitung personenbezogener Daten braucht eine Rechtsgrundlage nach Art. 6 DSGVO. In der Praxis kommen meist das berechtigte Interesse (Art. 6 Abs. 1 lit. f) oder die Einwilligung (lit. a) in Betracht. Das berechtigte Interesse verlangt eine dokumentierte Abwägung gegen die Interessen der Betroffenen, der Europäische Datenschutzausschuss hat dafür in seiner Stellungnahme 28/2024 zu KI-Modellen einen dreistufigen Test bestätigt; die Einwilligung muss freiwillig, informiert und widerrufbar sein. Eine pauschale "KI-Klausel" in den AGB trägt diese Last nicht.
Sobald ein externer KI-Anbieter Daten in Ihrem Auftrag verarbeitet, wird er zum Auftragsverarbeiter, und es braucht eine Auftragsverarbeitungsvereinbarung (AVV) nach Art. 28. Diese muss Weisungsbindung, Vertraulichkeit, Unterauftragsverarbeiter, technische Maßnahmen und Löschpflichten regeln. Viele Cloud-LLM-Dienste bieten zwar eine AVV an, doch die entscheidende Schwachstelle liegt woanders.
Sitzt der Anbieter in den USA oder ist er ein US-Konzern, greift der Drittlandtransfer nach Art. 44 ff. Hier gibt es seit 2023 mit dem EU-US Data Privacy Framework (DPF) wieder einen Angemessenheitsbeschluss: Übermittlungen an dort zertifizierte US-Unternehmen sind grundsätzlich zulässig. Doch das DPF löst das Kernproblem nicht und ist juristisch umstritten, eine Klage (Latombe) wurde 2025 vom EuG abgewiesen, ein Rechtsmittel ist beim EuGH anhängig. Vor allem aber gilt: Nach dem Schrems-II-Urteil reichen auch Standardvertragsklauseln allein nicht, wenn der Empfänger US-Recht unterliegt. Der US CLOUD Act und FISA 702 verpflichten US-kontrollierte Anbieter, Daten auch dann an Behörden herauszugeben, wenn die Server in Europa stehen, und weder DPF noch SCC verhindern diese Zugriffsbefugnis. Genau hier scheitern viele "EU-Region"-Angebote: Die rechtliche Zugriffsmöglichkeit bleibt bestehen.
Datenresidenz ist nicht Souveränität
Das ist der am häufigsten übersehene Punkt: Datenresidenz in der EU bedeutet nicht digitale Souveränität. Ein Rechenzentrum in Frankfurt schützt nicht vor extraterritorialem Zugriff, wenn der Betreiber einem Drittlandrecht unterliegt. Souveränität entsteht erst, wenn weder ein ausländischer Mutterkonzern noch dessen Heimatrecht technischen oder rechtlichen Zugriff erzwingen können.
Der saubere Weg ist souveränes Self-Hosting: offene Modelle wie Llama, Mistral, Qwen oder das von Fraunhofer/OpenGPT-X entwickelte deutsche Teuken werden auf eigenen Servern in Deutschland mit vLLM betrieben, gebündelt hinter einem LiteLLM-Gateway. Die Daten verlassen die kontrollierte Umgebung nicht, es gibt keine Telemetrie an Dritte und standardmäßig keine US-Modelle. Damit verschwindet die Drittlandfrage nicht durch Verträge, sondern strukturell. Wie das in der Praxis aussieht, beschreiben wir unter souveräne KI und KI-Infrastruktur & Hosting.
Datenminimierung, Zweckbindung und kein heimliches Training
Die Grundsätze aus Art. 5 gelten auch für KI: Es dürfen nur die Daten verarbeitet werden, die für den konkreten Zweck nötig sind (Datenminimierung), und nur für diesen Zweck (Zweckbindung). Ein häufiger Verstoß ist das stille Weitertrainieren von Modellen mit Kunden- oder Mitarbeiterdaten, ohne eigene Rechtsgrundlage ist das unzulässig. Bei selbst gehosteten Modellen entscheiden Sie selbst, ob, womit und wann trainiert oder feinjustiert wird; bei vielen Public-Cloud-Diensten müssen Sie auf vertragliche Zusagen vertrauen.
Technisch lassen sich diese Prinzipien stützen, etwa durch Pseudonymisierung vor der Verarbeitung, klare Mandantentrennung und nachvollziehbares Logging. Wer KI auf Wissensbeständen einsetzt, sollte Quelle und Antwort sauber trennen, was direkt zur Architekturfrage führt.
Betroffenenrechte: warum RAG die Löschung erleichtert
Betroffene haben Anspruch auf Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17) und Widerspruch (Art. 21). Bei einem Modell, in dessen Gewichten personenbezogene Daten einfließen, ist die Löschung einzelner Daten praktisch kaum sauber durchführbar, ein zentrales Risiko generativer Systeme.
Eine citation-grounded RAG-Architektur entschärft genau das. Statt Wissen in Modellgewichte zu "backen", bleiben die Inhalte in einer kontrollierten, durchsuchbaren Wissensbasis; das Modell ruft sie zur Laufzeit ab und belegt jede Aussage mit ihrer Quelle. Ein Löschbegehren wird dann an einer einzigen, kontrollierten Stelle erfüllt, der Datensatz wird aus der Wissensbasis entfernt, und die KI kann ihn nicht mehr zitieren. Dieses Muster, verbunden mit PageIndex und einem Wissensgraphen, setzen wir produktiv in einem großen KI-Archiv mit Millionen Dokumenten ein und beschreiben es unter Recherche- & Archivsysteme. Belegte Antworten reduzieren zugleich Halluzinationen und machen Verarbeitung prüfbar.
TOMs, DSFA, der EU AI Act und eine Praxis-Checkliste
Nach Art. 32 sind technische und organisatorische Maßnahmen (TOMs) Pflicht: Verschlüsselung, Zugriffskontrolle, Mandantentrennung, Protokollierung und ein Rollen- und Rechtekonzept. Bei Verarbeitungen mit voraussichtlich hohem Risiko, und KI gilt häufig als solche, verlangt Art. 35 eine Datenschutz-Folgenabschätzung (DSFA) vor dem Produktivbetrieb. Parallel greift der EU AI Act, der KI-Systeme nach Risikoklassen reguliert und schrittweise in Kraft tritt; für viele Anwendungen ergänzt er Transparenz-, Dokumentations- und Aufsichtspflichten. DSGVO und AI Act sind nebeneinander einzuhalten, nicht alternativ.
Eine praxisnahe Checkliste für den Start: Rechtsgrundlage je Anwendungsfall festlegen; AVV mit jedem Anbieter abschließen; Drittlandtransfer prüfen (DPF-Zertifizierung, SCC oder Self-Hosting) oder strukturell vermeiden; Datenminimierung und Pseudonymisierung umsetzen; Training mit personenbezogenen Daten nur mit Grundlage; Betroffenenrechte technisch operationalisieren (RAG erleichtert Löschung); TOMs nach Art. 32 dokumentieren; DSFA bei hohem Risiko durchführen; AI-Act-Einstufung vornehmen; alles im Verzeichnis von Verarbeitungstätigkeiten festhalten. Die konkrete Ausgestaltung sollten Sie mit Ihrem Datenschutzbeauftragten abstimmen.
Der regulatorische Rahmen wird in den kommenden Jahren eher dichter als lockerer, mit der schrittweisen Anwendung des AI Act und einer zunehmend kritischen Aufsichtspraxis bei Drittlandtransfers. Unternehmen, die KI heute auf einer souveränen, belegbaren Architektur aufsetzen, müssen morgen seltener nachrüsten: Wer Datenhoheit, Nachvollziehbarkeit und kontrollierte Löschung von Anfang an einbaut, hat die schwierigsten Fragen bereits weitgehend beantwortet.