Wer eine SaaS-Anwendung betreibt, in die Kunden personenbezogene Daten eingeben, ist in Bezug auf diese Daten Auftragsverarbeiter. Das ist keine Frage der Gestaltung, sondern eine der Rolle: Der Kunde bestimmt Zweck und Mittel, der Anbieter verarbeitet in dessen Auftrag.
Daraus folgt eine Vertragspflicht. Was daraus in der Praxis folgt, ist meist eine heruntergeladene Vorlage, die an drei Stellen nicht zum eigenen Produkt passt.
Was der Vertrag zwingend enthalten muss
Artikel 28 gibt den Inhalt vor. Der Vertrag muss Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der Daten und die Kategorien betroffener Personen benennen, sowie die Rechte und Pflichten des Verantwortlichen.
Hinzu kommen die Verpflichtungen des Auftragsverarbeiters: Verarbeitung nur auf dokumentierte Weisung, Vertraulichkeit der eingesetzten Personen, Umsetzung angemessener technischer und organisatorischer Massnahmen, Bedingungen für den Einsatz weiterer Auftragsverarbeiter, Unterstützung bei Betroffenenrechten, Unterstützung bei Sicherheitspflichten und Folgenabschätzungen, Löschung oder Rückgabe nach Ende der Erbringung sowie Nachweis- und Prüfmöglichkeiten.
Diese Liste ist in praktisch jeder Vorlage abgebildet. Der Unterschied zwischen einer brauchbaren und einer unbrauchbaren Vereinbarung liegt woanders.
Erste Schwachstelle: die Weisungsbindung im eigenen Produkt
Die Verarbeitung darf nur auf Weisung des Verantwortlichen erfolgen. Bei SaaS bedeutet das: Die dokumentierte Weisung ergibt sich aus dem vertraglich vereinbarten Leistungsumfang, also aus dem, was das Produkt tut.
Problematisch wird es, wenn der Anbieter Kundendaten für eigene Zwecke nutzt — zur Produktverbesserung, zur Erstellung von Statistiken oder zum Training von Modellen. In diesem Umfang handelt er nicht mehr als Auftragsverarbeiter, sondern als Verantwortlicher, mit allen Folgen für Rechtsgrundlage und Transparenz.
Viele Vorlagen enthalten eine Klausel, die eine solche Nutzung pauschal erlaubt. Das löst das Problem nicht, sondern verlagert es: Der Kunde stimmt einer Konstruktion zu, die rechtlich nicht trägt. Sauberer ist, die Nutzung für eigene Zwecke offen zu benennen, klar abzugrenzen und auf eine eigene Grundlage zu stellen — oder sie zu unterlassen.
Zweite Schwachstelle: die Unterauftragskette
Jeder Dienst, der im Betrieb Zugriff auf Kundendaten hat, ist Unterauftragsverarbeiter. Bei einer typischen SaaS-Anwendung sind das mehr als die drei, die üblicherweise genannt werden: neben Hosting und Datenbank auch Fehlererfassung, Protokollierung, Überwachung, E-Mail-Versand, Support-Werkzeuge, Zahlungsabwicklung und zunehmend Schnittstellen zu Sprachmodellen.
Der Vertrag muss regeln, ob eine allgemeine oder eine gesonderte Genehmigung gilt. Bei der allgemeinen Genehmigung — dem üblichen Weg im SaaS — ist der Kunde über beabsichtigte Änderungen zu informieren und muss die Möglichkeit zum Einspruch haben.
Praktisch heisst das: eine öffentlich erreichbare, gepflegte Liste und ein Weg, über Änderungen zu informieren. Beides fehlt bei vielen kleineren Anbietern, und beides wird in Beschaffungsprozessen grösserer Kunden verlangt.
Der Anbieter bleibt gegenüber dem Kunden für die Einhaltung durch die Unterauftragsverarbeiter verantwortlich. Diese Kette bricht nicht dadurch ab, dass ein Dienst weit unten in der Infrastruktur liegt.
Dritte Schwachstelle: Prüfrechte, die niemand ausüben kann
Der Vertrag muss dem Kunden ermöglichen, die Einhaltung zu überprüfen, einschliesslich Inspektionen. Für einen SaaS-Anbieter mit vielen Kunden ist eine unbeschränkte Vor-Ort-Prüfung durch jeden einzelnen nicht praktikabel.
Der übliche und tragfähige Weg ist, das Prüfrecht durch Nachweise zu erfüllen — Zertifikate, Prüfberichte, ausgefüllte Fragebögen — und Vor-Ort-Prüfungen an Voraussetzungen wie Ankündigungsfrist und Anlass zu knüpfen. Was nicht funktioniert, ist das Prüfrecht faktisch auszuschliessen.
Löschung, Rückgabe und der Exportpunkt
Nach Ende der Leistungserbringung sind die Daten nach Wahl des Kunden zu löschen oder zurückzugeben. Der Vertrag sollte benennen, in welchem Format ein Export erfolgt und innerhalb welcher Frist die Löschung abgeschlossen ist.
Der Punkt, der in Vorlagen praktisch immer fehlt: Sicherungen. Wenn Backups mit einer Aufbewahrungsdauer von mehreren Wochen laufen, ist eine sofortige vollständige Löschung technisch nicht möglich. Das ist unproblematisch, wenn es benannt und begründet ist — und ein Mangel, wenn der Vertrag etwas anderes behauptet.
Was jetzt sinnvoll ist
Erstens: Die tatsächliche Liste der Unterauftragsverarbeiter aus dem Betrieb erheben, nicht aus der Erinnerung. Ein Blick in die Konfiguration der Produktivumgebung fördert regelmässig Dienste zutage, die in keiner Liste stehen.
Zweitens: Die eigene Nutzung von Kundendaten ehrlich einordnen. Wenn Daten für Produktverbesserung oder Modelltraining verwendet werden, gehört das offen geregelt statt in einer Klausel versteckt.
Drittens: Die Löschfristen mit der tatsächlichen Sicherungsstrategie abgleichen und im Vertrag abbilden, was technisch stimmt.
Was offen bleibt
Die Einordnung von Schnittstellen zu Sprachmodellen in der Auftragsverarbeitungskette ist noch nicht in allen Konstellationen geklärt, insbesondere wenn Anbieter Eingaben zur Verbesserung eigener Modelle verwenden. Wer solche Dienste einbindet, sollte die vertraglichen Zusagen des Anbieters prüfen statt sich auf allgemeine Aussagen zu verlassen.