KI für echte Wertschöpfung, Teil 2: Wer haftet, wenn’s schiefgeht? Die Subunternehmer-Kette bei KI
Transparenzvermerk: Dieser Artikel ist Teil 2 unserer Serie „KI für echte Wertschöpfung“. Teil 1 endete mit dem Versprechen, tiefer einzusteigen in „KI, Datenschutz und die Wahrheit hinter den Systemen“ — konkret: Datenstandorte bei API-Anbindungen, die technische Realität der Systeme im Hintergrund, und die Kontrolle über Betriebswissen bei KI-Nutzung. Dieser Artikel löst den ersten Teil dieses Versprechens ein: Wir schauen uns an, wer eigentlich hinter der Zusage „DSGVO-konform“ steckt, wenn man genauer hinsieht.
Ein Satz, der auf fast jeder KI-Anbieter-Website steht: „DSGVO-konform.“ Ein Satz, der fast nie dabeisteht: wer die Daten tatsächlich verarbeitet, sobald sie das Unternehmen des Anbieters verlassen. Und genau da fängt das eigentliche Problem an.
Was Auftragsverarbeitung rechtlich bedeutet
Wenn ein Unternehmen einen KI-Dienst nutzt und dabei personenbezogene Daten hochlädt — Kundendaten, Mitarbeiterdaten, interne Dokumente mit Namen darin —, ist das Unternehmen der „Verantwortliche“ im Sinne der DSGVO. Der KI-Anbieter ist der „Auftragsverarbeiter“. Dafür braucht es einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO, der unter anderem regelt, welche technischen und organisatorischen Maßnahmen gelten und wer die Daten anfassen darf.
Der entscheidende Absatz steht in Art. 28 Abs. 2: Ein Auftragsverarbeiter darf selbst wieder Unterauftragsverarbeiter — Subprozessoren — einsetzen, aber nur mit vorheriger Genehmigung des Verantwortlichen. Zwei Formen sind üblich: entweder eine spezifische Genehmigung für jeden einzelnen namentlich genannten Subprozessor, oder eine allgemeine Genehmigung, bei der der Anbieter über jede Änderung informieren muss und der Verantwortliche widersprechen kann. Für jeden Subprozessor gilt: Er unterliegt denselben Datenschutzpflichten wie der Hauptauftragsverarbeiter.
Klingt sauber geregelt. Ist es auf dem Papier auch. Das Problem liegt in der Praxis.
Die Ketten-Realität
Ein KI-Anbieter, der „DSGVO-konform“ wirbt, betreibt die Systeme selten komplett selbst. Er nutzt Cloud-Infrastruktur eines Hyperscalers für Rechenleistung und Speicher. Er nutzt womöglich ein fremdes Sprachmodell über eine API, statt ein eigenes zu betreiben. Er nutzt vielleicht einen weiteren Dienstleister für Monitoring, für Backups, für Support-Tools. Jede dieser Stationen ist ein weiteres Kettenglied — ein weiterer Subprozessor, der theoretisch in der AVV-Liste stehen müsste.
Die Realität: Standard-AVVs vieler Cloud-KI-Dienste sind oft unzureichend — insbesondere fehlt häufig eine wirklich transparente, aktuelle Subprozessor-Liste, sodass Unternehmen nachverhandeln müssen, um überhaupt eine vollständige Übersicht zu bekommen. Wer die eigenen Daten nicht lokalisieren kann, kann auch die von Aufsichtsbehörden geforderte Prozessorkontrolle und Governance nicht belegen — ein Befund, der in der aktuellen Fachliteratur zu Cloud-KI-Compliance wiederholt auftaucht.
Das heißt konkret: Ein Unternehmen unterschreibt eine AVV mit einem Anbieter — und weiß am Ende oft nicht genau, durch wie viele Hände die eigenen Daten tatsächlich gehen, bevor eine Antwort zurückkommt.
Warum entstehen solche Ketten überhaupt? Nicht aus böser Absicht, sondern aus wirtschaftlicher Logik. Eigene Rechenzentren zu betreiben ist teuer; ein eigenes Sprachmodell zu trainieren ist für die meisten Anbieter schlicht nicht wirtschaftlich darstellbar. Also mietet man Infrastruktur, bindet ein fremdes Modell per API an, kauft Spezialdienste für einzelne Funktionen zu. Jedes einzelne Glied für sich ist eine nachvollziehbare unternehmerische Entscheidung. Das Problem entsteht erst in der Summe — wenn niemand mehr die komplette Kette im Blick hat, am wenigsten das Unternehmen am Ende der Kette, das am Ende trotzdem haftet.
Die Haftungsfrage — und hier wird es unbequem
Jetzt zum Kern: Wer haftet, wenn irgendwo in dieser Kette etwas schiefgeht — ein Subprozessor wird gehackt, speichert Daten außerhalb der vereinbarten Region, oder verarbeitet sie für einen Zweck, der nie genehmigt wurde?
Art. 82 DSGVO regelt das über gesamtschuldnerische Haftung: Sind mehrere Verantwortliche oder Auftragsverarbeiter an derselben Verarbeitung beteiligt, haftet grundsätzlich jeder für den gesamten Schaden gegenüber der betroffenen Person — damit Betroffene tatsächlich Schadensersatz bekommen, statt sich durch eine Ketten-Zuständigkeit kämpfen zu müssen. Nach außen, gegenüber dem Betroffenen, haftet also potenziell jeder Beteiligte voll. Wer intern wie viel trägt, können die Beteiligten über Regressansprüche untereinander regeln — das interessiert den Betroffenen aber erstmal nicht.
Für Auftragsverarbeiter gibt es eine Einschränkung: Sie haften nur, wenn sie gegen die ihnen spezifisch auferlegten DSGVO-Pflichten verstoßen haben oder entgegen rechtmäßiger Anweisungen des Verantwortlichen gehandelt haben. Für den Verantwortlichen — also das Unternehmen, das den KI-Dienst nutzt — gilt das nicht. Es haftet für jede Verarbeitung, die nicht DSGVO-konform abläuft, unabhängig davon, wie viele Glieder der Kette dazwischenliegen.
Klartext: Wenn der Subprozessor eines Subprozessors deines KI-Anbieters einen Fehler macht, bist du als nutzendes Unternehmen trotzdem in der Haftungskette — nicht weil du etwas falsch gemacht hast, sondern weil du der Verantwortliche bist, der diese Verarbeitung überhaupt in Gang gesetzt hat. Fehlende Übersicht über die eigene Anbieterkette schützt nicht vor Haftung — sie erschwert im Ernstfall nur, den eigentlichen Verursacher zu identifizieren und Regress zu nehmen.
Was das für Unternehmen praktisch bedeutet
Drei Dinge, die sich aus der Rechtslage direkt ableiten lassen, bevor ein KI-Dienst zum Einsatz kommt:
Subprozessor-Liste aktiv einfordern. Wenn ein Anbieter keine aktuelle, konkrete Liste seiner Subprozessoren liefern kann oder will, ist das ein Warnsignal — nicht Kleingedrucktes.
AVV wirklich lesen, nicht nur unterschreiben. Speziell die Klauseln zu Genehmigungsform (spezifisch vs. allgemein), Informationspflichten bei Änderungen und Widerspruchsrecht. „DSGVO-konform“ auf der Website ist ein Werbeversprechen, kein Vertragstext.
Datenstandorte konkret nachfragen, nicht annehmen. „Serverstandort Deutschland“ beim Hauptanbieter sagt nichts darüber aus, wo ein API-angebundenes Modell die Anfrage tatsächlich verarbeitet, wenn ein weiteres Kettenglied dazwischenhängt.
Fehlt eine ordnungsgemäße AVV oder Prozessorkontrolle, drohen laut DSGVO Bußgelder bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes — ein Risiko, das nicht beim Anbieter bleibt, sondern beim Unternehmen, das die Daten verantwortet.
Ein realistisches Szenario macht das greifbar: Ein Unternehmen nutzt einen KI-Assistenten für die Kundenkommunikation, unterschreibt eine AVV mit „Serverstandort Deutschland“ und ist zufrieden. Der Anbieter bindet aber für die eigentliche Sprachverarbeitung ein Modell über eine API eines dritten Unternehmens an, das die Anfrage technisch auf Servern außerhalb der EU verarbeitet — vertraglich über Standardvertragsklauseln abgesichert, aber im AVV des Hauptanbieters nicht klar als eigener Subprozessor ausgewiesen. Kommt es zu einer Beanstandung durch eine betroffene Person oder eine Aufsichtsbehörde, ist es das nutzende Unternehmen, das erklären muss, warum es diesen Umstand nicht kannte — „das wusste ich nicht“ ist datenschutzrechtlich keine Entlastung, sondern oft selbst schon ein Kontrolldefizit.
Kurzer Bezug zu unserer eigenen Praxis
Wir erwähnen das hier bewusst kurz, weil es nicht das Hauptthema dieses Artikels ist: Bei CI4U bleibt die Verarbeitung standardmäßig lokal — kein externes Sprachmodell über eine fremde API, kein zusätzlicher Cloud-Subprozessor für die eigentliche KI-Verarbeitung. Ausnahmen sind möglich, aber das entscheiden Sie selbst.
Bei unserer SaaS-Variante sowie bei Backups verarbeiten bzw. speichern wir Daten auf eigener bzw. angemieteter Infrastruktur — auch das ist rechtlich eine Auftragsverarbeitung, wir machen daraus kein Geheimnis. Der Unterschied zur üblichen Praxis: Diese Kette hat ein, höchstens zwei bekannte Glieder — uns und, falls genutzt, ein einzelnes, benanntes Rechenzentrum für Backups — statt einer langen, oft nicht vollständig einsehbaren Kette aus KI-Anbieter, Cloud-Infrastruktur und weiteren Subprozessoren. Kürzer und bekannt statt lang und undurchsichtig.
Ausblick auf Teil 3
Im nächsten Teil der Serie wird es konkret: Wir schauen uns reale, dokumentierte DSGVO-Bußgeldverfahren gegen KI-Anbieter an — was genau vorgeworfen wurde, wie hoch die Bußgelder ausfielen, und was sich daraus für die eigene Anbieterauswahl lernen lässt. Denn abstrakte Paragrafen überzeugen selten so gut wie echte Fälle.
Quellen:
– DSGVO Art. 28 (Auftragsverarbeiter) — dsgvo-gesetz.de/art-28-dsgvo, Praxishinweise der GDD für Auftragsverarbeiter
– DSGVO Art. 82 (Haftung und Recht auf Schadenersatz) — dsgvo-gesetz.de/art-82-dsgvo, dr-datenschutz.de: Haftung zwischen Verantwortlichem und Auftragsverarbeiter
– Bitkom: Praxisleitfaden Künstliche Intelligenz & Datenschutz, Version 2.0
– Kiteworks: DSGVO-Durchsetzung 2026 — mangelhafte Anbieterüberwachung als Bußgeld-Multiplikator
– Bild generiert mit Gemini
Rechtshinweis: Dieser Artikel ersetzt keine Rechtsberatung. Er beschreibt die allgemeine Rechtslage nach DSGVO Art. 28 und 82 sowie branchenweit beobachtete Praxismuster bei Cloud-/KI-Dienstleistern, ohne sich auf einen konkreten Anbieter zu beziehen.
KIDeutschland #Datenschutz #DSGVO #ITManagement #Digitalisierung #TechRealität #KIEthik #CI4U
