Warum Ihr LLM-Proxy ein DSGVO-Auftragsverarbeiter ist (und was das für Sie bedeutet)

Der Standardfehler

In nahezu jedem unserer LLM-Architektur-Reviews kehrt dasselbe Muster wieder: Ein Team hat eine kundenseitige Anwendung gebaut, die einen Upstream-LLM-Anbieter (Anthropic, OpenAI, manchmal beides) im Hintergrund aufruft, der Prompt der Nutzerin trägt regelmäßig identifizierende personenbezogene Daten — Name, E-Mail, gelegentlich eine Kundennummer —, die Anwendung reicht den Prompt unverändert an das Modell weiter, die Antwort kommt zurück, das Konversationsprotokoll wird gespeichert. Sechs Schritte, scheinbar trivial, rechtlich folgenreich.

Wir bitten um den Auftragsverarbeitungsvertrag mit dem LLM-Anbieter. Die Antwort lautet meistens: „Wir haben den AGBs zugestimmt. Der AVV ist meines Wissens per Verweis enthalten."

Diese Antwort ist der Verstoß. Art. 28 Abs. 3 DSGVO verlangt, dass die Verarbeitung durch einen Auftragsverarbeiter „auf der Grundlage eines Vertrags oder eines anderen Rechtsinstruments nach dem Unionsrecht oder dem Recht der Mitgliedstaaten erfolgt, der bzw. das den Auftragsverarbeiter in Bezug auf den Verantwortlichen bindet und in dem Gegenstand und Dauer der Verarbeitung, Art und Zweck der Verarbeitung, die Art der personenbezogenen Daten, die Kategorien betroffener Personen und die Pflichten und Rechte des Verantwortlichen festgelegt sind." Eine Checkbox in einem Anmeldeformular mit der Aufschrift „Ich akzeptiere die AGB" erfüllt das selten.

Hinter dem Papierkram steckt eine strukturelle Fehlklassifizierung: Das Team sieht den LLM-Anbieter als Werkzeuglieferanten, Art. 28 sieht ihn als Auftragsverarbeiter, der personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet — und an diesen beiden Rollen hängen sehr unterschiedliche Pflichtenkataloge. Aus diesem Rollenfehler folgt der Großteil der Beanstandungen, die wir in DSGVO-Reviews zu LLM-Architekturen sehen. Wer das Werkzeug-Bild übernimmt, baut den AVV-Stack gar nicht erst auf, an dem Art. 28 ihn später messen wird.

Verantwortlicher vs. Auftragsverarbeiter — angewandt auf LLM-Proxies

Art. 4 Nr. 7 DSGVO definiert den Verantwortlichen als „die natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet." Art. 4 Nr. 8 definiert den Auftragsverarbeiter als „eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet."

Wenden Sie das auf einen LLM-Proxy an, der zwischen Ihrer Kundin und einem Upstream-LLM-Anbieter sitzt. Drei klar getrennte Rollen entstehen:

• Ihre Kundin verarbeitet personenbezogene Daten ihrer Endnutzer für einen Zweck, den sie bestimmt. Sie ist die Verantwortliche.
• Sie, betreiben den Proxy, verarbeiten diese Daten im Auftrag Ihrer Kundin, um den von ihr beauftragten Dienst zu erbringen. Sie sind ein Auftragsverarbeiter Ihrer Kundin.
• Der Upstream-LLM-Anbieter verarbeitet die Daten ein weiteres Mal — in Ihrem Auftrag — um eine Modellantwort zu berechnen. Er ist ein Unterauftragsverarbeiter für Sie und über Sie hinaus für Ihre Kundin.

Aus dieser Rollenkette folgen sofort zwei eigenständige Art.-28-Verträge — einer zwischen Ihrer Kundin und Ihnen, ein zweiter zwischen Ihnen und dem LLM-Anbieter. Art. 28 Abs. 2 nennt die Voraussetzung dafür ausdrücklich: keine Weiterbeauftragung ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen. In der Konsequenz heißt das, dass Ihre Kundin überhaupt erst erfahren muss, welche Unterauftragsverarbeiter im Hintergrund laufen, und ihr ein operatives Widerspruchsrecht zustehen muss — nicht nur formell, sondern mit einem Kanal, über den ein Widerspruch tatsächlich Wirkung entfaltet.

Es gibt eine zweite Falle, die viele Teams übersehen. Wenn der Proxy selbst entscheidet, welches LLM-Modell aufgerufen wird, welcher System-Prompt angewendet wird, welche Filterung läuft — trifft er Entscheidungen über Mittel der Verarbeitung. Die Leitlinien des Europäischen Datenschutzausschusses zu den Begriffen Verantwortlicher und Auftragsverarbeiter (Leitlinien 07/2020) sind eindeutig: Ein Auftragsverarbeiter, der über die wesentlichen Mittel der Verarbeitung entscheidet, ist kein reiner Auftragsverarbeiter mehr; er ist mindestens ein gemeinsam Verantwortlicher für diese Entscheidungen.

Bei reinen Pass-Through-Proxies — die Anfrage wird wortgetreu an das konfigurierte Upstream-Modell weitergeleitet — bleibt das sauber in der Auftragsverarbeiter-Rolle. Bei Proxies, die System-Prompts hinzufügen, Sanitisierung durchführen, Modelle inhaltsbasiert auswählen oder Nachverarbeitungsregeln anwenden, wird die Rolle differenzierter. Die defensive Position ist, diese Entscheidungen im AVV gegenüber der Kundin transparent zu dokumentieren, sodass die Verantwortliche nicht überrascht wird.

Art. 28 Abs. 3 — die verbindlichen Klauseln

Art. 28 Abs. 3 DSGVO listet acht konkrete Pflichten auf, die im Vertrag zwischen Verantwortlicher und Auftragsverarbeiter enthalten sein müssen. Nicht „sollten." Nicht „können." Müssen. Jede Pflicht entspricht einer konkreten Klausel in der AVV-Architektur:

• a) Verarbeitung nur auf dokumentierte Weisung des Verantwortlichen. Der AVV muss sagen, was der Auftragsverarbeiter darf. Ein vages „zur Erbringung des Dienstes" reicht nicht — die dokumentierten Weisungen müssen so konkret sein, dass eine Behörde feststellen kann, ob eine bestimmte Verarbeitungstätigkeit autorisiert war.
• b) Vertraulichkeitsverpflichtung der zur Verarbeitung befugten Personen. NDAs für Mitarbeiter, in denen personenbezogene Daten genannt werden, oder eine Vertraulichkeitsklausel im Arbeitsvertrag. Auditierbar.
• c) Sicherheitsmaßnahmen nach Art. 32. Pseudonymisierung und Verschlüsselung personenbezogener Daten, Fähigkeit zur dauerhaften Sicherstellung von Vertraulichkeit und Integrität, Wiederherstellbarkeit nach Vorfällen, regelmäßige Wirksamkeitstests. Der AVV verweist auf Art. 32; die Implementierungsnachweise liegen separat.
• d) Bedingungen für die Inanspruchnahme weiterer Auftragsverarbeiter einhalten. Die Genehmigungskette für Unterauftragsverarbeiter. Konkrete oder allgemeine schriftliche Genehmigung. Vorankündigung beabsichtigter Änderungen.
• e) Unterstützung des Verantwortlichen bei Anfragen betroffener Personen. Auskunft, Berichtigung, Löschung, Übertragbarkeit, Widerspruch. Der AVV muss den Auftragsverarbeiter zur Unterstützung verpflichten — typischerweise durch technische Mittel, mit denen der Verantwortliche der Anfrage nachkommen kann.
• f) Unterstützung bei Art. 32–36. Sicherheit, Meldung von Verletzungen, Datenschutz-Folgenabschätzungen, vorherige Konsultation. Hier werden meist die Fristen für Verletzungs-Meldungen festgehalten.
• g) Löschung oder Rückgabe aller personenbezogenen Daten nach Beendigung der Verarbeitung. Eine Löschungs- oder Rückgabeverpflichtung mit konkreter Frist und einem Lösch-Bestätigungsartefakt.
• h) Nachweis der Einhaltung. Auditrechte, Inspektionsrechte, Möglichkeit, externe Auditoren hinzuzuziehen.

Ein AVV, dem eine dieser acht Pflichten fehlt, ist nicht konform. Ein AVV, der alle acht in vager Sprache aufzählt („der Auftragsverarbeiter wird unterstützen") und keinen operativen Mechanismus dahinter hat, ist auch in keinem sinnvollen Sinne konform — Art. 28 Abs. 3 Buchst. h verlangt, dass der Verantwortliche die Einhaltung nachweisen kann, was bedeutet, dass der operative Mechanismus irgendwo existieren muss.

Häufige Lücken

In der Prüfung realer LLM-Stack-AVVs tauchen immer wieder dieselben Lücken auf.

Datenlokalisierung fehlt. Der AVV sagt nicht, wo die personenbezogenen Daten verarbeitet werden. Für eine EU-Verantwortliche, die einen US-LLM-Anbieter nutzt, ist das ein Schrems-II-Problem, bevor überhaupt eine Auftragsverarbeiter-Frage entsteht. Die „dokumentierten Weisungen" nach Art. 28 Abs. 3 Buchst. a sollten den geografischen Verarbeitungsumfang einschließen — wo die Verantwortliche entschieden hat, dass die Daten hingelangen dürfen.

Liste der Unterauftragsverarbeiter veraltet. Der AVV enthält eine Liste, die aber vor sechs Monaten verfasst wurde. Der LLM-Anbieter hat seitdem eine neue Infrastrukturabhängigkeit hinzugefügt — vielleicht eine neue Region eines Cloud-Anbieters, vielleicht einen neuen Content-Safety-Partner. Die Verantwortliche wurde nicht informiert. Art. 28 Abs. 2 verlangt vorherige Genehmigung; eine veraltete Liste ist ein Verstoß in Zeitlupe.

Anlage 1 / Anlage 2 als toter Buchstabe. Eine spezifisch deutsche Variante der Listenstaleness: AVV-Vorlagen aus dem Bestandsgeschäft tragen häufig eine „Anlage 1 — Verzeichnis der Verarbeitungstätigkeiten" und eine „Anlage 2 — TOMs" als statisches PDF, das bei Vertragsschluss gestempelt wurde und seither nicht mehr angefasst worden ist. Bei einem LLM-Stack, dessen Sub-Processor-Liste sich quartalsweise ändert, wird dieser Anhang innerhalb weniger Monate sachlich falsch. Der AVV selbst verweist dann auf eine Realität, die im operativen Setup nicht mehr existiert. Praktisch bedeutet das: Anlage 1 und Anlage 2 sollten entweder durch Verweise auf eine versionierte Online-Liste ersetzt werden (mit dokumentierter Notification-Pflicht), oder der Vertrag sollte einen klaren Update-Mechanismus enthalten, der nicht von einer manuellen Vertragsänderung abhängt.

Keine Frist für Verletzungs-Meldungen. Art. 33 verpflichtet die Verantwortliche, eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden zu melden. Der Vertrag mit dem Auftragsverarbeiter muss der Verantwortlichen Zeit dafür lassen. Ein Vertrag, der besagt „wir werden die Verantwortliche so bald wie praktikabel über eine Verletzung informieren", lässt keinen Spielraum für die Einhaltung der 72-Stunden-Uhr.

„Training-Opt-out" nicht tatsächlich verdrahtet. Viele LLM-Anbieter-AGBs enthalten Formulierungen, dass Kundendaten ohne Zustimmung nicht für Training verwendet werden. Die vertragliche Klausel existiert. Die technische Umsetzung ist manchmal unklar. Eine Verantwortliche kann sich nicht auf eine Klausel verlassen, ohne den technischen Mechanismus prüfen zu können, der sie durchsetzt. Das ist eine Frage, die eine kompetente Aufsichtsbehörde stellen wird, und die Verantwortliche muss die Antwort haben.

Mehrdeutigkeit bei gemeinsamer Verantwortlichkeit. Wo der Proxy selbst materielle Verarbeitungslogik hinzufügt (Sanitisierung, Content-Filterung, Modellauswahl), kann der AVV als Vereinbarung über gemeinsame Verantwortlichkeit nach Art. 26 für diese Untermenge an Entscheidungen neu gefasst werden müssen. Die meisten Vorlagen sehen das nicht vor. Ein sauberer Architektur-Review klassifiziert jede Verarbeitungsentscheidung und ordnet sie dem richtigen Rechtsinstrument zu.

Schrems II und der LLM-Stack

Das Urteil des EuGH von 2020 in der Rechtssache Datenschutzbeauftragter gegen Facebook Ireland und Maximillian Schrems (Rs. C-311/18, „Schrems II") erklärte den Privacy-Shield-Rahmen für ungültig, der die EU-US-Datentransfers regelte. Der 2023 verabschiedete EU-US Data Privacy Framework ist in Kraft, aber die zugrunde liegende Prüfungsstruktur bleibt: Eine EU-Verantwortliche, die personenbezogene Daten in ein Drittland überträgt, muss prüfen, ob das drittstaatliche Rechtssystem ein im Wesentlichen gleichwertiges Schutzniveau wie die DSGVO bietet.

Für einen LLM-Stack bedeutet das: Jeder API-Aufruf von Ihrem Gateway zu einem US-LLM-Anbieter ist ein Drittlandstransfer der personenbezogenen Daten im Prompt. Standardvertragsklauseln (SCCs) helfen. Sie sind notwendig. Sie sind nicht ausreichend, wenn die übertragenen Daten identifizierbar sind und der Drittstaat Überwachungsbefugnisse hat, die die Schutzvorkehrungen der SCC materiell überschreiben.

Hier verändert die Pseudonymisierung vor dem LLM-Aufruf die Rechnung tatsächlich. Die Empfehlungen des Europäischen Datenschutzausschusses zu ergänzenden Maßnahmen (Empfehlungen 01/2020) sind ausdrücklich: Pseudonymisierung, die vor der Übertragung in einer Weise durchgeführt wird, dass der Empfänger die betroffenen Personen nicht re-identifizieren kann, kann eine wirksame ergänzende Maßnahme sein. Der architektonische Test lautet: Kann der Empfänger — einschließlich einer Regierung mit gesetzlichem Zugriff auf die Systeme des Empfängers — eine natürliche Person aus dem identifizieren, was er empfängt? Lautet die Antwort nein, sind die übertragenen Daten aus Sicht des Drittland-Empfängers nicht mehr „personenbezogen" im selben Sinne, und die Schrems-II-Analyse fällt deutlich günstiger aus.

Das ist kein Schlupfloch. Es ist die regulatorische Designlogik hinter Art. 25 DSGVO („Datenschutz durch Technikgestaltung") in der vorgesehenen Funktion. Wenn die Architektur sicherstellt, dass Identifizierbarkeit die Übertragungsgrenze nicht überquert, ändert sich das Risikoprofil der Übertragung. Wir haben das im Detail in warum Datenschwärzung scheitert ausgeführt — Schwärzung allein ist nicht dasselbe wie architektonische Pseudonymisierung, und der Unterschied zählt unter Schrems II.

Eine funktionierende AVV-Architektur für ein EU-KI-Deployment

Eine funktionierende AVV-Architektur für ein typisches EU-KI-Deployment sieht so aus:

• Kunden-AVV. Ein Art. 28 Abs. 3-AVV mit jeder Kundin. Enthält den geografischen Verarbeitungsumfang, die Liste der Unterauftragsverarbeiter, einen Zeitrahmen für Verletzungs-Meldungen abgestimmt auf das 72-Stunden-Fenster aus Art. 33, einen Lösch-Zeitrahmen, Auditrechte.
• Interne Art.-28-Kette. Jeder im Kunden-AVV genannte Unterauftragsverarbeiter hat seinen eigenen Art.-28-Vertrag mit Ihnen. Art. 28 Abs. 4 verlangt, dass „dieselben Datenschutzpflichten", die für Sie gelten, auch für Ihre Unterauftragsverarbeiter gelten — die kundenseitigen Verpflichtungen müssen weitergereicht werden.
• Liste der Unterauftragsverarbeiter. Als lebendiges Dokument geführt. Benachrichtigungsmechanismus im Kunden-AVV dokumentiert: Wer wird informiert, über welchen Kanal, mit welcher Vorlauffrist. Die Lucairn-Liste der Unterauftragsverarbeiter (Hetzner, Cloudflare, Supabase, Resend, Plausible, Anthropic, FreeTSA, Sigstore Rekor) ist ein Beispiel — jeder hat eine definierte Rolle und einen definierten Vertrag.
• Lösch-Zeitrahmen. Konkret. „Innerhalb von 30 Tagen nach Vertragsende" mit einem Lösch-Bestätigungsartefakt. „Personenbezogene Daten werden gemäß unseren Richtlinien gelöscht" ist nach Art. 28 Abs. 3 Buchst. g nicht konform, weil es keine Verpflichtung ist.
• Auditrechte. Art. 28 Abs. 3 Buchst. h bedeutet, dass die Verantwortliche den Auftragsverarbeiter prüfen kann. Der AVV legt fest, wie (vor Ort, remote, Drittprüfer), wie oft, und wer es bezahlt.
• Aufbewahrungsrichtlinie. Getrennt von der Löschung bei Vertragsende. Pro Datenkategorie eine Aufbewahrungsdauer, zurückgeführt auf die Rechtsgrundlage der Aufbewahrung.

Die LLM-spezifische Ergänzung ist, Modellanbieter explizit als Unterauftragsverarbeiter zu nennen, den geografischen Pfad jeder Anfrage zu beschreiben und die Entscheidungen in der Proxy-Schicht zu klassifizieren, die nach den Leitlinien 07/2020 als „wesentliche Mittel" gelten.

Wo Lucairn ansetzt

Pseudonymisierung vor dem LLM-Aufruf ist die architektonische Grundoperation, die den Rest der AVV-Architektur handhabbar macht. Wenn der Proxy identifizierende Elemente aus dem Prompt entfernt, bevor der Aufruf Ihre Grenze verlässt — und [PERSON_1], [EMAIL_1], [IBAN_1] für die zugrunde liegenden Werte einsetzt — müssen Sie die Art.-28-Vertrauenskette für diese Datenelemente nicht auf den LLM-Anbieter ausdehnen. Der LLM-Anbieter verarbeitet Tokens, nicht personenbezogene Daten, für die pseudonymisierten Teile. Das verändert die Vertragsoberfläche.

Das Lucairn-Gateway führt diese Sanitisierungsschicht an der Grenze aus. Der kryptografische Re-Linkage-Zustand liegt in einer separaten Sandbox, zu der das LLM-Modell keinen Netzwerkpfad hat. Die Integrität der Redaktion wird in einem signierten Manifest erfasst, das Teil der Audit-Aufzeichnung nach Art. 12 der KI-Verordnung wird. Wenn eine Behörde fragt, wie die Verantwortliche sich sicher sein kann, dass der LLM-Anbieter die zugrunde liegenden personenbezogenen Daten nicht gesehen hat, ist die Antwort strukturell statt vertraglich: Das Gateway hat ein signiertes Manifest erzeugt, das auflistet, welche Felder redigiert wurden, das Manifest ist in einem öffentlichen Transparenzlog verankert, und der LLM-Anbieter besitzt kein Schlüsselmaterial, mit dem er die Redaktion umkehren könnte, selbst wenn er es wollte.

Das beseitigt die AVV-Architektur nicht. Sie brauchen weiterhin den Kunden-AVV, den Unterauftragsverarbeiter-Vertrag mit dem LLM-Anbieter und den Rest der Art.-28-Kette. Was es bewirkt, ist eine Verkleinerung der Vertrauensoberfläche jeder dieser Vereinbarungen. Der AVV mit dem LLM-Anbieter deckt das ab, was der LLM-Anbieter tatsächlich sieht — was bei pseudonymisierten Feldern ein opakes Token ist. Die Schrems-II-Analyse auf diesem Pfad verbessert sich entsprechend.

Zur operativen Architektur dahinter siehe /private-ai-inference und /security. Zur rechtlichen Einordnung in die breitere Pflicht aus Art. 25 DSGVO siehe DSGVO Art. 25 in der Praxis.

Art. 28 DSGVO ist kein Papierkram. Er ist das vertragliche Gerüst, das einer Verantwortlichen erlaubt, ihre Architekturentscheidungen vor einer Behörde zu verteidigen. Ein LLM-Proxy, der Art. 28 ignoriert, ist nicht nur unvollständig — er ist die erste Feststellung, die die Verantwortliche bekommt, wenn eine Untersuchung eröffnet wird. Die Acht-Klausel-Checkliste oben ist ein nützlicher Selbsttest. Fehlt eine davon in Ihrer aktuellen AVV-Architektur, ist die Lücke ein bekanntes, behebbares Problem, das geschlossen werden kann, bevor eine Behörde es benennt.