Der AVV ist ein Versprechen, keine Kontrolle: Einen KI-Anbietervertrag darauf lesen, was er tatsächlich bindet

KERNTHESE Ein Auftragsverarbeitungsvertrag ist keine technische Kontrolle — er ist eine vertragliche Zuweisung der Verantwortung für eine solche. Er hindert Daten nicht am Zugriff; er legt fest, wer rechenschaftspflichtig ist, wenn darauf zugegriffen wird, entlang einer Unterauftragsverarbeiter-Kette, die bei einem modernen KI-Anbieter mehrere Parteien tief reichen und dabei in die US-Gerichtsbarkeit übergehen kann. Der Verantwortliche bleibt für die gesamte Kette rechenschaftspflichtig — dafür, sich zu vergewissern, dass jedes Glied hinreichende Garantien bietet — auch wenn der Auftragsverarbeiter, mit dem er einen Vertrag geschlossen hat, ihm gegenüber für die darunterliegenden Unterauftragsverarbeiter haftbar bleibt. Einen KI-AVV gut zu lesen bedeutet, ihn auf drei Dinge zu lesen: was er verbietet, wen er sonst noch an die Daten heranlässt und wo er schweigt.

Zwei Fragen zu KI und personenbezogenen Daten erhalten in der Regel die meiste Aufmerksamkeit. Die erste ist, was mit einem Prompt geschieht: Ein Enterprise-AVV verbietet das Training, garantiert aber keine Speicherfreiheit und sagt nichts darüber, wer gezwungen werden kann, die Daten herauszugeben. Die zweite ist, was geschieht, wenn eine Organisation ein Modell mit ihren eigenen Daten trainiert: Selbst-Hosting beantwortet die Übermittlungsfrage, nicht aber die Rechtsgrundlagen- oder Löschfragen. Beide führen auf denselben zugrunde liegenden Gegenstand zurück, und es ist einer, den Organisationen selten direkt untersuchen: den Vertrag selbst — den Auftragsverarbeitungsvertrag, den eine Organisation mit einem KI-Anbieter unterzeichnet und den sie dann tendenziell ablegt, als ob das Unterzeichnen dasselbe wäre wie der dadurch gewährte Schutz.

Ist es nicht. Und die Lücke zwischen diesen beiden Dingen ist der Ort, an dem die meisten KI-Anbieterbeziehungen ein Risiko tragen, von dem der Verantwortliche nicht weiß, dass er es trägt.

Ein AVV, den ich kürzlich prüfte, macht den Punkt. Der Anbieter war eine bekannte KI-Plattform; der Vertrag war professionell abgefasst; das Trainingsverbot war klar; die Sicherheitszusagen waren erheblich. Das Beschaffungsteam der Organisation hatte das Kästchen angekreuzt: „DSGVO-konformer AVV vorhanden.” Was niemand auf der Beschaffungsseite gelesen hatte, war der Unterauftragsverarbeiter-Anhang — drei Seiten, weit hinten, der die anderen Unternehmen auflistete, an die der Anbieter die Daten weitergeben durfte. Es waren elf. Vier waren in den USA eingetragen. Zwei stellten Infrastruktur bereit, die als US-kontrollierte Stellen potenziell in den Anwendungsbereich von US-Offenlegungspflichten fiel, einschließlich der mit dem CLOUD Act verbundenen. Das Trainingsverbot, über das das Beschaffungsteam so erfreut gewesen war, band den Anbieter — und sagte nichts darüber, wozu diese elf Unterauftragsverarbeiter gezwungen werden konnten.

Die Frage, die dieser Artikel beantwortet, ist die, die das Ankreuzen des Beschaffungskästchens überspringt: Wenn Sie den AVV eines KI-Anbieters unterzeichnen, was haben Sie tatsächlich gebunden — und, wichtiger, was nicht? Der Vertrag ist die Schicht, die unter sowohl der Prompt-Frage als auch der Trainingsfrage liegt, und ihn richtig zu lesen ist die Disziplin, die den ganzen Gegenstand zusammenbindet.

Was ein AVV ist — und der Kategorienfehler, ihn als Schutz zu behandeln

Nach Art. 28 DSGVO ist immer dann, wenn ein Dritter personenbezogene Daten im Auftrag eines Verantwortlichen verarbeitet, ein Auftragsverarbeitungsvertrag zwingend, muss vor Beginn jeder Verarbeitung vorliegen und muss die spezifischen Klauseln enthalten, die Art. 28 Abs. 3 vorschreibt.¹ Ein KI-Anbieter, der personenbezogene Daten für einen Geschäftskunden verarbeitet, ist auf den Enterprise-Ebenen ein Auftragsverarbeiter in genau diesem Sinne, und der AVV ist das Instrument, das die Vereinbarung rechtmäßig macht.

Aber beachten Sie, was der AVV tut. Er verschlüsselt nichts. Er bewegt keinen Server. Er hindert eine US-Behörde nicht daran, eine Anordnung zu erlassen. Er ist ein Vertrag — eine Zuweisung von Pflichten und Haftungen zwischen Verantwortlichem und Auftragsverarbeiter. Seine schützende Kraft ist gänzlich abgeleitet: Er wirkt in dem Maße, in dem der Auftragsverarbeiter erfüllt, was er versprochen hat, und in dem Maße, in dem ein Gericht das Versprechen durchsetzen würde. Dies ist der Kategorienfehler, den „wir haben einen AVV” so oft verbirgt: Ein AVV ist keine Kontrolle, er ist ein Versprechen über Kontrollen, und die Unterscheidung zählt genau dann am meisten, wenn das Versprechen am schwersten zu halten ist — unter einem rechtlichen Zwang, dem der Auftragsverarbeiter nicht rechtmäßig widerstehen kann.

Die wichtigste strukturelle Tatsache über die Verantwortlicher-Auftragsverarbeiter-Beziehung folgt unmittelbar: Der Verantwortliche lagert seine Verantwortung nicht aus, indem er einen Auftragsverarbeiter bestellt. Er bleibt verantwortlich. Die Auswahl eines Auftragsverarbeiters ohne angemessene Garantien oder ohne einen konformen AVV setzt den Verantwortlichen der Durchsetzung aus, unabhängig davon, ob die Verletzung beim Anbieter ihren Ursprung hatte.² Der AVV verteilt die vertragliche Haftung zwischen den Parteien neu; er verteilt nicht die aufsichtsrechtliche Rechenschaftspflicht des Verantwortlichen gegenüber der Aufsichtsbehörde neu. Diese Rechenschaftspflicht bleibt, wo sie ist.

Die Unterauftragsverarbeiter-Kette: wohin die Daten tatsächlich gehen

Der mit Abstand am wenigsten gelesene Teil des AVV eines KI-Anbieters ist die Unterauftragsverarbeiter-Bestimmung, und es ist der Ort, an dem die Prompt-Frage und die Trainingsfrage beide in konkreter Form wieder auftauchen.

Moderne KI-Plattformen laufen nicht auf der Infrastruktur eines einzigen Unternehmens. Sie sitzen auf geschichtetem Cloud-Hosting, nutzen Drittanbieter-Infrastruktur für die Rechenleistung, leiten über Content-Delivery- und Observability-Dienste und rufen zunehmend andere Modelle als Komponenten auf. Jedes davon ist ein Unterauftragsverarbeiter — eine Partei, die der primäre Auftragsverarbeiter wiederum mit der Verarbeitung personenbezogener Daten beauftragt. Art. 28 reguliert dies streng. Ein Auftragsverarbeiter darf ohne vorherige Genehmigung des Verantwortlichen — sei sie spezifisch oder allgemein — keinen Unterauftragsverarbeiter beauftragen; unter einer allgemeinen Genehmigung muss der Auftragsverarbeiter den Verantwortlichen im Voraus über jede beabsichtigte Hinzufügung oder Ersetzung eines Unterauftragsverarbeiters informieren und ihm die Gelegenheit zum Widerspruch geben.³ Und entscheidend: Dieselben Datenschutzpflichten, die den primären Auftragsverarbeiter binden, müssen vertraglich an jeden Unterauftragsverarbeiter in der Kette weitergegeben werden.⁴

Die Rechenschaftsstruktur, die der EDSA in seiner Stellungnahme 22/2024 darlegte, ist der Teil, den Praktiker am häufigsten falsch verstehen. Wenn ein Unterauftragsverarbeiter seine Pflichten nicht erfüllt, bleibt der anfängliche Auftragsverarbeiter dem Verantwortlichen gegenüber haftbar — sodass der Verantwortliche einen vertraglichen Anspruch gegen den Auftragsverarbeiter geltend machen kann, mit dem er tatsächlich einen Vertrag geschlossen hat, statt einem Unterauftragsverarbeiter vier Glieder weiter nachgehen zu müssen, mit dem er keine direkte Beziehung hat.⁵ Aber — und das ist der Stachel — der EDSA ist ebenso eindeutig, dass die letztendliche Verantwortung für die Leistung der Kette beim Verantwortlichen liegt. Der Verantwortliche muss sich vergewissern, dass nicht nur der Auftragsverarbeiter, sondern jeder Unterauftragsverarbeiter wirklich hinreichende Garantien bietet; er kann dies erfüllen, indem er vom Auftragsverarbeiter verlangt, angemessen zu kontrahieren und die Kette zu überwachen, aber er kann es nicht erfüllen, indem er nicht hinsieht.⁶ Der Verantwortliche ist zudem nach der Standard-SCC-Mechanik und Art. 28 Abs. 3 lit. h berechtigt, Kopien der Unterauftragsverarbeitungsverträge anzufordern.⁷

Übertragen Sie das zurück auf den Anhang mit elf Unterauftragsverarbeitern. Der Verantwortliche, der ihn unterzeichnete, hatte rechtlich die Verarbeitung seiner personenbezogenen Daten durch alle elf genehmigt, die Verantwortung übernommen, sich zu vergewissern, dass alle elf hinreichende Garantien boten, und die Pflicht auf sich genommen, Änderungen der Liste zu verfolgen. Was er tatsächlich getan hatte, war, die Liste nicht zu lesen. Das Trainingsverbot, auf das er sich verließ, war ein Versprechen des primären Anbieters; es sagte dem Verantwortlichen nichts darüber, ob ein in den USA eingetragener Infrastruktur-Unterauftragsverarbeiter unter dem CLOUD Act gezwungen werden konnte, Daten herauszugeben, die der Anbieter an ihn weitergegeben hatte.

Die Übermittlungsebene: ein AVV verschiebt keine Gerichtsbarkeit

Art. 28 regelt die Verantwortlicher-Auftragsverarbeiter-Beziehung; er legitimiert für sich genommen keine internationalen Übermittlungen.⁸ Das ist ein gesondertes Regime — Kapitel V DSGVO, Art. 44 ff. — und bei einem KI-Anbieter mit in den USA eingetragenen Parteien in der Kette ist es unvermeidlich.

Die Mechanismen sind gut etabliert, und jeder hat einen präzisen Anwendungsbereich. Für Übermittlungen an eine US-Organisation, die für die relevanten Datenkategorien unter dem EU-US Data Privacy Framework (DPF) zertifiziert ist, dient das DPF derzeit als Angemessenheitsgrundlage nach Art. 45, sodass für diese spezifische Übermittlungsroute keine Standardvertragsklauseln erforderlich sind — aber die Zertifizierung muss die fraglichen Daten und den fraglichen Dienst tatsächlich abdecken, nicht bloß existieren.⁹ Für US-Auftragsverarbeiter, die nicht DPF-zertifiziert sind, ist die Standardroute die Standardvertragsklauseln (SCCs) der Kommission von 2021 — für die meisten Verantwortlicher-zu-Auftragsverarbeiter-SaaS-Beziehungen Modul 2 — plus, seit Schrems II, eine Transfer Impact Assessment, die bewertet, ob das Recht des Bestimmungslands den von den SCCs versprochenen Schutz untergräbt.¹⁰ Der AVV muss dokumentieren, welcher Übermittlungsmechanismus für jeden außerhalb des EWR niedergelassenen Auftragsverarbeiter und Unterauftragsverarbeiter gilt.¹¹

Hier trifft die vertragliche Ebene auf die architektonische. Die TIA ist das Dokument, das die Frage im Kern jeder Übermittlungsbewertung erzwingen sollte — wer kann gezwungen werden, die Daten herauszugeben? — und eine verteidigungsfähige TIA verweist auf echte technische Schutzmaßnahmen: kundenseitige Hoheit über die Verschlüsselungsschlüssel, eine kundenseitige Pseudonymisierungsdomäne, eine prüfbare Fähigkeit, den Zugriff zu verweigern. Eine TIA, die „Daten in der EU gespeichert” und „Anbieter ist DPF-zertifiziert” rezitiert, ohne die gerichtsbarkeitsbezogene Exposition der Unterauftragsverarbeiter-Kette und die kryptografische und Pseudonymisierungs-Architektur zu untersuchen, ist keine TIA, die ihre Arbeit getan hat; sie ist ein Ankreuzen, das einen Mechanismus benennt, ohne zu prüfen, ob der Mechanismus den Kontakt mit dem US-Zwangsrecht überlebt. Das DPF verringert den SCC-Papierkram; es schafft nicht die zugrunde liegende Realität ab, dass ein in den USA eingetragener Unterauftragsverarbeiter in Reichweite der US-Behörden bleibt — ein Punkt, den noch kein Angemessenheitsbeschluss zum Verschwinden bringen konnte und den aufeinanderfolgende Anfechtungen am Leben halten.

Falls das wie eine übervorsichtige Lesart dessen klingt, was ein Vertrag kann und nicht kann, existiert die höchste jemals verhängte DSGVO-Geldbuße, um den Streit beizulegen. Am 22. Mai 2023 verhängte die irische Datenschutzkommission, handelnd auf einer verbindlichen Entscheidung des EDSA nach Art. 65, eine Geldbuße von 1,2 Milliarden Euro gegen Meta Platforms Ireland für die Übermittlung der personenbezogenen Daten von EU-Nutzern in die Vereinigten Staaten unter Verstoß gegen Art. 46 Abs. 1 DSGVO.¹² Die entscheidende Feststellung ist die, die jeder Verantwortliche, der sich auf einen US-KI-Anbieter verlässt, zweimal lesen sollte: Meta hatte die Daten auf der Grundlage der Standardvertragsklauseln der Europäischen Kommission übermittelt und hatte umfangreiche zusätzliche Maßnahmen daraufgelegt — interne Richtlinien, Verschlüsselung der Daten bei der Übermittlung, eine dokumentierte Praxis, behördliche Zugriffsersuchen anzufechten — und die DPC und der EDSA befanden, dass all das zusammen immer noch nicht genug war, um die Mängel im US-Überwachungsrecht auszugleichen, die der EuGH in Schrems II identifiziert hatte.¹³ Der Vertrag war real. Die zusätzlichen Maßnahmen waren real. Sie verschoben die Gerichtsbarkeit nicht, und so verschoben sie das Risiko nicht. Meta wurde nicht nur zur Zahlung verurteilt, sondern auch, weitere Übermittlungen auszusetzen und die Daten in die EU zurückzuführen — Anordnungen, gegen die Meta Berufung einlegt und deren praktische Schärfe es bisher vermieden hat, indem es nach der Annahme des EU-US Data Privacy Framework im Juli 2023 zu diesem überging.¹⁴ Dieser nachträgliche Ausweg mildert die Feststellung nicht: In dem Moment, in dem die Geldbuße bemessen wurde, wurde ein unterzeichneter SCC plus umfangreicher Schutzmaßnahmen für unzureichend befunden, und das ist die Feststellung, auf die es für jeden ankommt, der sich heute allein auf einen Vertrag verlässt. Das bedeutet nicht, dass jede aktuelle US-Übermittlung rechtswidrig ist — eine Übermittlung an einen DPF-zertifizierten Empfänger beruht auf einer anderen und derzeit gültigen Grundlage. Es bedeutet, dass der Übermittlungsmechanismus und der Zertifizierungsstatus des Empfängers für die Oberfläche, die Sie tatsächlich nutzen, bewertet werden müssen, nicht aus einer Unterschrift angenommen. (Zur Größenordnung: Die Geldbuße von 746 Millionen Euro gegen Amazon in Luxemburg — historisch die zweithöchste DSGVO-Geldbuße, auch wenn ein luxemburgisches Gericht sie im März 2026 aus verfahrensrechtlichen Gründen aufhob und an die Behörde zurückverwies — war nicht annähernd so hoch.) Die Lehre überträgt sich direkt auf einen AVV mit einem US-KI-Anbieter: Eine Unterschrift und ein Ordner voller Schutzmaßnahmen ist genau das, was Meta hatte. Was fehlte, war eine Architektur, in der die Daten außerhalb der Reichweite des US-Zwangs lagen — und dieser Mangel ist das, wofür die Geldbuße verhängt wurde.

Einen AVV darauf lesen, was er nicht sagt

Die praktische Fähigkeit besteht darin, den AVV eines KI-Anbieters auf drei Achsen gleichzeitig zu lesen. Die ersten zwei sind, was er enthält; die dritte — diejenige, die eine echte Prüfung von einer Beschaffungsformalität trennt — ist, was er auslässt.

Achse eins — was er verbietet. Schließt er die Nutzung von Kundendaten zum Training der Basismodelle des Anbieters in klaren Worten aus, über die Oberflächen hinweg, die Sie tatsächlich nutzen? (Die Enterprise- und Verbraucherebenen einer Marke können sich hierin völlig unterscheiden.) Regelt er die Speicherung — und wenn Speicherfreiheit angenommen wird, ist ZDR für die spezifische Oberfläche eingeschrieben oder bloß aus der Existenz des AVV abgeleitet?

Achse zwei — wen er sonst noch an die Daten heranlässt. Lesen Sie den Unterauftragsverarbeiter-Anhang, jeden Eintrag. Für jeden: Wo ist er eingetragen, was verarbeitet er, und ist er in einem Drittland? Unter welchem Genehmigungsmodell kann der Anbieter die Liste ändern, und was ist Ihr Widerspruchsrecht und ‑fenster? Ist die Pflicht, dieselben Schutzmaßnahmen an jeden Unterauftragsverarbeiter weiterzugeben, ausgesprochen oder bloß angedeutet?

Achse drei — wo er schweigt. Dies ist das analytische Herz der Prüfung. Ein AVV kann hervorragend zu Training und Speicherung sein und nichts über die Übermittlungsarchitektur sagen — kein Übermittlungsmechanismus pro Unterauftragsverarbeiter benannt, keine TIA referenziert, keine Anerkennung des US-Zwangsrechts, keine Zusage zur Schlüsselhoheit oder Pseudonymisierung. Schweigen ist nicht Abwesenheit von Risiko; es ist nicht zugewiesenes Risiko, und nicht zugewiesenes Risiko bei einem Vertrag nach Art. 28 fällt standardmäßig dem Verantwortlichen zu, weil der Verantwortliche der Ort ist, an dem die aufsichtsrechtliche Rechenschaftspflicht letztlich ruht. Die Frage, die man jedem Schweigen stellen muss, ist die Frage, die sich durch den ganzen Gegenstand zieht: Lässt diese Lücke personenbezogene Daten erreichbar für jemanden, der nicht gebunden ist, sie nicht zu erreichen?

Ein Fünf-Fragen-Abschluss, ausführbar bei jedem KI-AVV in fünfzehn Minuten:

Eins: Verbietet er das Training mit unseren Daten, auf den Oberflächen, die wir nutzen — verifizierbar, nicht nach Ruf? Zwei: Ist die Speicherung geregelt, und ist jede Speicherfreiheits-Behauptung für die tatsächliche Oberfläche eingeschrieben? Drei: Habe ich jeden Unterauftragsverarbeiter gelesen, und weiß ich, welche in Drittländern sind? Vier: Ist für jeden Nicht-EWR-Auftragsverarbeiter und ‑Unterauftragsverarbeiter ein Übermittlungsmechanismus benannt, und gibt es eine TIA, die ihn gegen das Zwangsrecht prüft — nicht bloß gegen „EU-Speicherung”? Fünf: Was adressiert der Vertrag nicht — und wo landet dieses nicht adressierte Risiko? (Es landet bei uns.)

Wenn Frage fünf keine Antwort hat, hat die Prüfung noch nicht stattgefunden.

Eine Prüfung verdient ihr Geld nur, wenn jedes „Nein” eine festgelegte Maßnahme auslöst statt einer Notiz. Paaren Sie also jede Frage mit ihrem Heilmittel:

Wenn das Training für Ihre Oberfläche nicht verifizierbar ausgeschlossen ist — setzen Sie nicht auf dieser Oberfläche ein; verlangen Sie den Ausschluss schriftlich für die genaue Ebene oder wechseln Sie zu einer, die ihn hat. Wenn die Speicherung ungeregelt ist oder Speicherfreiheit angenommen, aber nicht eingeschrieben — schreiben Sie Ihre eigene Speicherregel in den Vertrag und streichen Sie jede interne Behauptung von „Speicherfreiheit”, die der Vertrag tatsächlich nicht stützt. Wenn Sie nicht jeden Unterauftragsverarbeiter gelesen haben oder nicht sagen können, welche in Drittländern sind — halten Sie die Freigabe zurück, bis der Anhang Zeile für Zeile gelesen und jeder Eintrag nach Gerichtsbarkeit getaggt ist; ein ungelesener Anhang ist ein nicht freigegebener AVV. Wenn ein Nicht-EWR-Auftragsverarbeiter oder ‑Unterauftragsverarbeiter keinen benannten Übermittlungsmechanismus hat oder die TIA nur „EU-Speicherung” rezitiert — schicken Sie ihn für einen Mechanismus pro Partei und eine TIA zurück, die gegen das Zwangsrecht prüft, und verlangen Sie, wo die Daten sensibel sind, eine echte technische Schutzmaßnahme (kundenseitige Verschlüsselungsschlüssel, eine kundenseitige Pseudonymisierungsdomäne) statt einer Papierzusicherung. Für alles, was der Vertrag nicht adressiert — weisen Sie dieses Restrisiko einem benannten Verantwortlichen auf Ihrer Seite zu, weil nicht zugewiesenes Risiko nicht nicht zugewiesen bleibt; es fällt stillschweigend dem Verantwortlichen zu.

Diese fünf Heilmittel sind der Unterschied zwischen einem AVV, den Sie abgelegt haben, und einem AVV, den Sie tatsächlich unter Kontrolle gebracht haben.

Ein Belastungstest: der Unterauftragsverarbeiter, den Sie nie genehmigt haben

Lassen Sie den Vertrag durch ein Versagen laufen, das er tatsächlich wahrscheinlich erleidet. Der AVV ist unterzeichnet, der Unterauftragsverarbeiter-Anhang wurde gelesen, jeder Eintrag hat einen benannten Übermittlungsmechanismus, die TIA ist verteidigungsfähig. Sechs Monate später sendet der Anbieter eine routinemäßige Mitteilung unter der Allgemeingenehmigungsklausel: Er fügt einen neuen Unterauftragsverarbeiter — einen in den USA eingetragenen Analytics-Anbieter — der Liste hinzu, wirksam in dreißig Tagen. Die Mitteilung landet während einer arbeitsreichen Woche in einem geteilten Postfach. Niemand widerspricht, weil niemand sie rechtzeitig liest. Am einunddreißigsten Tag fließen personenbezogene EU-Daten an eine neue US-Partei, die niemand auf der Seite des Verantwortlichen je bewertet hat.

Nichts hier war ein Vertragsbruch. Der Anbieter tat genau das, was der AVV erlaubte: Allgemeine Genehmigung bedeutet, dass er die Liste ändern darf, vorbehaltlich nur einer vorherigen Mitteilung und der Gelegenheit des Verantwortlichen zum Widerspruch — einer Gelegenheit, die wertlos ist, wenn niemand das Postfach beobachtet.³ Und doch ist der Verantwortliche nun genau in der Position, die die Meta-Entscheidung bestraft: personenbezogene Daten in den Händen einer US-erreichbaren Partei, ohne frische Übermittlungsbewertung, auf dem eigenen aufsichtsrechtlichen Konto des Verantwortlichen. Die Haftung des Auftragsverarbeiters für die Kette rettet den Verantwortlichen hier nicht, weil der EDSA ausdrücklich war, dass die letztendliche Verantwortung für die Leistung der Kette beim Verantwortlichen liegt — die Resthaftung des Auftragsverarbeiters ist ein vertraglicher Rückhalt, keine Übertragung der Rechenschaftspflicht.⁵

Dies ist der Belastungstest, der offenlegt, was ein AVV wirklich ist. Der Vertrag versagte nicht; die Überwachung versagte, und der Vertrag war von vornherein nie eine Überwachungskontrolle — er war ein Versprechen, das zuwies, wer rechenschaftspflichtig ist, wenn die Überwachung aussetzt. Die verteidigungsfähige Haltung ist daher operativ, nicht vertraglich: ein benannter Verantwortlicher für Unterauftragsverarbeiter-Mitteilungen, eine stehende Regel, dass jeder neue Drittland-Unterauftragsverarbeiter eine TIA-Auffrischung vor Schließung des Widerspruchsfensters auslöst, und eine Voreinstellung des Widerspruchs-bis-zur-Prüfung statt Schweigen-als-Zustimmung. Die Unterschrift erkaufte das Recht zum Widerspruch. Erst ein Prozess macht aus diesem Recht eine Kontrolle.

Das Fazit

ZUSAMMENFASSUNG FÜR ENTSCHEIDUNGSTRÄGER Ein AVV ist ein vertragliches Versprechen über Kontrollen, keine Kontrolle — er weist die Verantwortung für den Schutz zu, er führt ihn nicht aus, und die aufsichtsrechtliche Rechenschaftspflicht des Verantwortlichen bleibt beim Verantwortlichen, egal wie lang die Auftragsverarbeiter-Kette ist. Der Unterauftragsverarbeiter-Anhang ist das Dokument, das Ihnen sagt, wohin Ihre Daten tatsächlich gehen; bei einem KI-Anbieter kann er mehrere Parteien tief reichen und in die US-Gerichtsbarkeit übergehen, und Sie haben jede Partei darauf genehmigt — und die Verantwortung dafür übernommen — ob Sie die Liste gelesen haben oder nicht. Lesen Sie jeden KI-AVV auf drei Achsen: was er verbietet, wen er sonst noch an die Daten heranlässt und — entscheidend — wo er schweigt, weil Schweigen zur Übermittlungsarchitektur nicht zugewiesenes Risiko ist, das Ihnen zufällt.

Ein AVV ist für sich genommen keine operative Kontrolle — er schützt Daten nicht von sich aus. Er sagt, wer für ihren Schutz verantwortlich ist — und die Antwort schließt am Ende jeder Kette den Verantwortlichen ein. Die Unterschrift als den Schutz zu behandeln ist das mit Abstand häufigste und teuerste Fehllesen von Art. 28 in der KI-Beschaffung.

Der Unterauftragsverarbeiter-Anhang ist der Ort, an dem die Abstraktionen zu einer Liste benannter Unternehmen in benannten Gerichtsbarkeiten werden. Das Trainingsverbot, das Sie unterzeichnet haben, bindet den Anbieter; die vier US-Unterauftragsverarbeiter drei Seiten später sind durch ihre eigenen Pflichten gebunden und durch ihre eigenen Behörden erreichbar, und das ist eine gesonderte Frage, die das Verbot nie berührte.

Lesen Sie auf die Schweigen hin. Ein Vertrag, der stark beim Training und stumm bei Übermittlungen ist, hat das Übermittlungsproblem nicht gelöst — er hat es nicht zugewiesen gelassen, und nicht zugewiesenes Risiko bei einem Vertrag nach Art. 28 hat einen Standardeigentümer. Die eine Frage, die es wert ist, durch jeden KI-Anbietervertrag mitzunehmen: Wer kann die Daten erreichen, und sind sie gebunden, es nicht zu tun? Alles andere ist Papierkram, der um diese eine Antwort herum angeordnet ist.

Glossar der Abkürzungen

Rechtlicher Hinweis: Dieser Artikel dient allgemeinen Informationszwecken und stellt keine Rechtsberatung dar. Für eine rechtssichere Beurteilung im konkreten Einzelfall wird die Konsultation einer auf Datenschutz spezialisierten Anwältin oder eines Anwalts empfohlen. Stand: Juni 2026.