KI-Funktionen in SaaS: Wer verarbeitet eigentlich die Daten?

Ein SaaS-System ist seit Jahren freigegeben. Dann erscheint im nächsten Release ein neuer Button: „Mit KI zusammenfassen“. Für den Nutzer sieht das nach einer zusätzlichen Funktion aus. Für Datenschutz, Informationssicherheit und Beschaffung kann sich dahinter aber ein neuer Datenfluss öffnen.

Das muss kein Problem sein. Ein Modell kann vom SaaS-Anbieter selbst betrieben werden, ein spezialisierter Anbieter kann als Unterauftragsverarbeiter eingebunden sein oder eine Funktion kann mehrere Dienste kombinieren. Genau deshalb ist die Frage „Ist der SaaS-Anbieter freigegeben?“ für ein neues KI-Feature zu grob.

Ein belastbarer Check behandelt die KI-Funktion als Delta zum bereits bewerteten Dienst: Welche Daten fließen zusätzlich? Welche Akteure kommen hinzu? Für welche Zwecke dürfen sie die Daten verarbeiten? Welche Speicher-, Transfer- und Änderungsregeln gelten?

Das unterscheidet die Situation von Shadow AI. Dort nutzt jemand KI außerhalb des vorgesehenen Rahmens. Hier kann die KI direkt im bereits beschafften und grundsätzlich freigegebenen System stecken – und gerade deshalb leicht durch die bestehende Freigabe rutschen.

Ein KI-Feature ist nicht automatisch nur eine neue Oberfläche

Wie konkret diese zusätzliche Lieferkette inzwischen geworden ist, zeigt Microsoft in seiner aktuellen Dokumentation zu „KI-Unterauftragsverarbeitern“. Für Microsoft Online Services werden dort Drittanbieter beschrieben, die KI-Funktionen betreiben, warten oder unterstützen und dabei Kundendaten oder personenbezogene Daten im Auftrag von Microsoft verarbeiten können.

Das Beispiel beweist nicht, dass jede SaaS-KI externe Modellanbieter nutzt. Es zeigt das Gegenteil: Die technische und vertragliche Konstruktion ist produktspezifisch. Manche Modelle werden vom Plattformanbieter betrieben, andere von einem weiteren Dienstleister. Für die Prüfung zählt deshalb nicht das Label „KI“, sondern der konkrete Verarbeitungsweg der Funktion.

NIST adressiert genau diese Konstellation im Generative-AI-Profil des AI Risk Management Framework. Die Behörde empfiehlt, Beschaffungs- und Vendor-Due-Diligence-Prozesse auch auf Lösungen auszurichten, die eingebettete generative KI verwenden. Außerdem sollen Organisationen Drittparteien inventarisieren, die Zugriff auf Organisationsinhalte haben, und Abhängigkeiten sowie Fallbacks für Drittanbieter-KI berücksichtigen.

Die praktische Konsequenz ist simpel: Eine frühere SaaS-Freigabe ist wertvolle Vorarbeit. Sie beantwortet aber nur dann auch die neue KI-Funktion, wenn die dafür relevanten Datenflüsse, Akteure und Nutzungsbedingungen tatsächlich unverändert bleiben.

Unterauftragsverarbeiter sind Teil des Dienstes, auch wenn man sie nicht sieht

Artikel 28 DSGVO verlangt bei Auftragsverarbeitung, dass Verantwortliche nur Auftragsverarbeiter mit hinreichenden Garantien einsetzen. Ein Auftragsverarbeiter darf weitere Auftragsverarbeiter nicht ohne vorherige spezifische oder allgemeine schriftliche Genehmigung einbinden. Bei einer allgemeinen Genehmigung muss er über beabsichtigte Änderungen informieren, damit der Verantwortliche widersprechen kann.

Der Europäische Datenschutzausschuss hat diese Kette 2024 präzisiert. Nach Opinion 22/2024 sollten Verantwortliche die Identität aller Auftrags- und Unterauftragsverarbeiter in der Verarbeitungskette jederzeit verfügbar haben. Der erste Auftragsverarbeiter soll diese Informationen proaktiv liefern und aktuell halten.

Die Verantwortung endet damit nicht an der ersten Vertragsbeziehung. Der EDPB sieht die Prüfung hinreichender Garantien grundsätzlich auch für die weitere Verarbeitungskette beim Verantwortlichen; wie intensiv geprüft werden muss, kann sich mit dem Risiko unterscheiden. Gleichzeitig verlangt der EDPB nicht, dass Unternehmen pauschal sämtliche Unterauftragsverträge anfordern. Ob das nötig ist, soll im Einzelfall nach dem Accountability-Prinzip bewertet werden.

Für ein eingebettetes KI-Feature folgt daraus keine Pflicht zu einem Vertragsarchiv ohne Ende. Wohl aber eine klare Mindestfrage: Wer verarbeitet für diese konkrete Funktion tatsächlich Daten – und unter welcher Rolle?

Der Vertragstitel löst die Rollenfrage nicht

Gerade bei KI-Lieferketten wird die Rollenfrage schnell mit Produktnamen beantwortet: SaaS-Anbieter, Modellanbieter, Cloud-Provider. Datenschutzrechtlich reicht das nicht.

Die EDPB Guidelines 07/2020 behandeln Verantwortlicher und Auftragsverarbeiter als funktionale Begriffe. Maßgeblich sind die tatsächlichen Rollen und Umstände der Verarbeitung, nicht allein die Bezeichnung im Vertrag. Ein Auftragsverarbeiter verarbeitet personenbezogene Daten im Auftrag des Verantwortlichen und nach dessen Weisungen. Bestimmt er für eine Verarbeitung eigene Zwecke und Mittel, kann er für genau diese Verarbeitung selbst zum Verantwortlichen werden.

Deshalb gehört in die Prüfung nicht nur die Frage, welcher Modellanbieter beteiligt ist. Ebenso wichtig ist, wofür er die erhaltenen Daten verwenden darf. Dient die Verarbeitung ausschließlich dazu, die angeforderte Funktion auszuführen? Welche Telemetrie oder Betriebsdaten entstehen? Gibt es darüber hinaus eigene Zwecke, etwa für Produktverbesserung oder Modelltraining? Solche Fragen lassen sich nicht aus dem Namen des Modells ableiten. Sie müssen aus Vertrag, Produktdokumentation und tatsächlicher Architektur beantwortet werden.

Der Prompt ist nur der sichtbare Teil des Datenflusses

Bei einem Chatfenster ist die Eingabe offensichtlich. Eingebettete KI kann aber je nach Funktion zusätzlichen Kontext aus dem SaaS heranziehen: ein Dokument, ein Ticket, einen Datensatz, Suchtreffer oder andere Inhalte, die der Nutzer nicht noch einmal in ein Promptfeld kopiert. NIST nennt bei der Bewertung von GenAI-Anwendungen ausdrücklich unterschiedliche Datenquellen wie Grounding und Retrieval-Augmented Generation als relevante Einsatzmerkmale.

Für die Bestandsaufnahme sollte deshalb nicht nur „Promptdaten“ im Verzeichnis stehen. Entscheidend ist, welche Daten die Anwendung an die KI-Komponente übergibt, welche Ausgabe zurückkommt und welche Protokoll-, Telemetrie- oder Zwischendaten im konkreten Dienst entstehen. Nicht jede Funktion erzeugt jede dieser Datenarten. Genau das ist der Punkt der Prüfung.

Die Gegenposition: Mehr Anbieter sind nicht automatisch mehr Risiko

Bei KI-Lieferketten liegt eine bequeme Schlussfolgerung nahe: je mehr beteiligte Unternehmen, desto schlechter. So einfach ist es nicht.

Eine sauber dokumentierte Einbindung eines Modellanbieters kann vertraglich klar begrenzt, technisch abgesichert und administrativ steuerbar sein. Umgekehrt wird eine KI-Funktion nicht automatisch unkritisch, nur weil der SaaS-Anbieter sie vollständig selbst betreibt. Anbieterzahl ist kein Risikoscore.

Auch NIST fordert nicht, für generative KI alle bestehenden Beschaffungs- und Sicherheitsprozesse neu zu erfinden. Das Profil beschreibt ausdrücklich, dass bestehende Risikokontrollen und Due-Diligence-Verfahren auf proprietäre oder offene GenAI-Technologien und Drittanbieter angewendet und angepasst werden können.

Der gleiche Gedanke steckt in der risikobasierten EDPB-Linie: Die Verantwortung zur Prüfung verschwindet nicht, aber ihre Tiefe kann sich nach Risiko und Verarbeitung unterscheiden. Für eine harmlose Textfunktion ohne sensible Inhalte kann die nötige Prüftiefe anders aussehen als für KI, die Personal-, Gesundheits- oder vertrauliche Kundendaten verarbeitet.

Der Zweck des Checks ist deshalb nicht, externe Modelle aus Prinzip zu verhindern. Er soll verhindern, dass eine neue Verarbeitungskette unbemerkt unter einer alten Freigabe mitläuft.

Was vor der Aktivierung konkret geklärt sein sollte

Zuerst braucht es einen funktionsbezogenen Datenfluss. Nicht „unsere SaaS-Lösung nutzt KI“, sondern: Welche Daten erhält die KI-Funktion aus welchem Systemteil, an welchen Dienst werden sie übergeben und welches Ergebnis fließt wohin zurück?

Danach folgt die Verarbeitungskette. Die aktuelle Liste der Auftrags- und Unterauftragsverarbeiter muss erkennen lassen, welche Akteure für die Funktion relevant sind. Bei neuen oder austauschbaren Modellanbietern ist zusätzlich wichtig, wie Änderungen angekündigt werden und welche Steuerungsmöglichkeiten der Kunde hat.

Die dritte Ebene sind Zwecke und Aufbewahrung. Beschaffung und Datenschutz sollten unterscheiden können, was für die unmittelbare Leistungserbringung nötig ist und ob Daten darüber hinaus für Betrieb, Sicherheit, Produktverbesserung oder Training verwendet werden dürfen. Wo Angaben fehlen, ist das eine Due-Diligence-Lücke – kein Beweis für eine unzulässige Verarbeitung.

Viertens gehören Speicher- und Transferwege in den konkreten Funktionscheck. Wenn Daten oder Zugriffe Ländergrenzen überschreiten können, gelten die normalen Regeln für Drittlandtransfers weiter. Wie Datenresidenz, Zugriffe und Unterauftragsverarbeiter bei einer Standortzusage geprüft werden können, behandelt der separate Beitrag zu Deutschland-Hosting im Anbietercheck.

Schließlich braucht die Funktion einen Betriebszustand. Wer darf sie aktivieren? Lässt sie sich für Gruppen oder Datenarten begrenzen? Was passiert bei einem Wechsel des Modellproviders? Gibt es eine brauchbare Alternative, wenn die KI-Komponente ausfällt oder aus Governance-Gründen deaktiviert werden muss? NIST nimmt solche Fallback- und Change-Fragen ausdrücklich in die Betrachtung von Drittanbieter-GenAI auf.

Das eigentliche Prüfobjekt ist das Delta zur bisherigen SaaS-Freigabe

Die sauberste Prüfung beginnt nicht bei null. Wenn ein SaaS-Dienst bereits bewertet ist, bleiben viele Kontrollen, Verträge und Betriebsprozesse weiter relevant. Das spart Arbeit.

Neu geprüft werden muss der Teil, den die KI-Funktion tatsächlich verändert. Kommt ein weiterer Unterauftragsverarbeiter hinzu? Werden zusätzliche Daten aus dem Systemkontext an ein Modell übergeben? Ändert sich der Verarbeitungszweck? Entstehen andere Speicher- oder Transferwege? Gibt es neue Abhängigkeiten oder Administratorentscheidungen?

Wenn die Antwort auf diese Fragen „nein“ lautet und das belastbar dokumentiert ist, kann der bestehende Prüfstand weit tragen. Wenn sich etwas ändert, ist genau dieser Unterschied das Arbeitsprogramm für Datenschutz, Security, Einkauf und AI Governance.

Die richtige Einheit der Prüfung ist deshalb nicht „KI: ja oder nein?“ und auch nicht die Zahl der beteiligten Anbieter. Es ist der konkrete Daten- und Verarbeitungsweg der Funktion – und das, was sich gegenüber dem bereits freigegebenen Dienst verändert.