Worum es geht
Seit dem 12. September 2025 gilt Kapitel VI des Data Act. Anbieter von Datenverarbeitungsdiensten müssen Kunden den Wechsel ermöglichen — zwei Monate Ankündigungsfrist, Exportpflicht in strukturiertem Format, spätestens ab 12. Januar 2027 keine Wechselentgelte mehr. Die Regeln greifen also tief in die Vertragsgestaltung ein.
Die erste Frage richtet sich damit nach dem Anwendungsbereich des Data Acts auf SaaS Systeme.
Die Europäische Kommission hat zuletzt am 22. Januar 2026 eine aktualisierte Fassung ihrer Data Act FAQ veröffentlicht (Version 1.4). Frage 58a widmet sich der Scope-Frage für SaaS. Sie verdient einen genaueren Blick, weil sie einiges klarstellt — was ich vorher anders interpretiert habe.
1.) Art 2 Nr.8 DA: Kann der Kunde selbst skalieren?
Art. 2 Nr. 8 DA definiert den Datenverarbeitungsdienst als digitale Dienstleistung, die einen flächendeckenden und bedarfsgesteuerten Netzzugang zu einem gemeinsam genutzten Pool konfigurierbarer, skalierbarer und elastischer Rechenressourcen ermöglicht, die mit minimalem Verwaltungsaufwand oder minimaler Interaktion des Anbieters rasch bereitgestellt und freigegeben werden können.
Ich habe diesen Bereich unter Anwendung der Kommentare zunächst weit gezogen. Die Kommission hat den Bereich in einem Dokument FAQ enger gezogen.
Sie referenziert auf vier Merkmale. Drei davon sind die klassischen Cloud-Computing-Merkmale: Zugriff auf Rechenressourcen, bedarfsgesteuerte Bereitstellung, elastische Skalierbarkeit. Das vierte — und für die Praxis entscheidende — Merkmal betrifft die Anbieter-Beteiligung: „rapidly provisioned and released with minimal management effort or service provider interaction, which implies that the unilateral provision can be done without significant intervention from the service provider.“
Das ist der Schlüsselpunkt. Erwägungsgrund 80 DA präzisiert diesen Aspekt ausdrücklich: Der Kunde muss die Fähigkeit haben, innerhalb der vertraglichen Vereinbarung einseitig Rechenressourcen zu provisionieren — ohne Anbieter-Eingriff oder mit allenfalls „sehr begrenztem Anbieter-Eingriff“ (was immer das bedeuten mag). Der Dienst muss automatisiert oder nahezu automatisiert bereitgestellt werden, typischerweise über ein Dashboard oder ein Interface, der Kunde muss selbst Lizenzen, Speicher etc. hinzufügen oder eleminieren können.
Daraus folgt die maßgebliche Abgrenzung: Kann der Kunde Kapazitätserweiterungen selbst über eine Interface-Funktion auslösen — mehr Nutzer anlegen, Speichervolumen hinzubuchen, weitere Module aktivieren —, ist der Dienst Datenverarbeitungsdienst im Sinne des Art. 2 Nr. 8 DA. Muss der Kunde einen Change-Request an den Anbieter auslösen, den dieser bearbeitet, freigibt und umsetzt, ist das Merkmal nicht erfüllt. Der Dienst fällt aus dem Anwendungsbereich des Kapitels VI heraus.
Die Trennlinie ist damit binär angelegt: Self-Service des Kunden versus anbieter-gesteuerter Prozess. Die reine Skalierungsgeschwindigkeit ist sekundär. Auch eine rasche Bearbeitung einer Kapazitätsanforderung durch den Anbieter — etwa innerhalb von 24 Stunden — erfüllt das Merkmal nicht, wenn sie an einen Anbieter-Prozess gebunden ist. Umgekehrt erfüllt ein Dashboard, über das der Kunde sofort provisioniert, das Merkmal auch dann, wenn die tatsächliche Umsetzung technisch einige Minuten dauert.
2.) Der Zweck für den Kunden
Q58a verweist auf Art. 2 Nr. 30 DA und argumentiert, es sei zusätzlich zu prüfen, ob der Vertrag seinem Zweck nach auf die Inanspruchnahme eines Datenverarbeitungsdienstes gerichtet sei — oder ob der Kunde lediglich eine Funktionalität nutze, die durch einen Datenverarbeitungsdienst ermöglicht werde, etwa Musikhören oder Videoansehen.
Diese Unterscheidung ist im FAQ-Text nicht trennscharf formuliert. Im Wortlaut steht die Alternative „data processing service as such“ versus „functionality enabled by a data processing service“ nebeneinander, als wäre sie selbsterklärend. Ist sie aber nicht. Aus operativer Sicht macht es für den Kunden keinen Unterschied, ob er den einen oder den anderen Dienst nutzt — er klickt auf Play, er öffnet eine Anwendung, er bearbeitet seine Daten.
Die kohärentere Auslegung trennt entlang einer anderen Linie: Bringt der Kunde eigene Daten in den Dienst ein und lässt sie dort verarbeiten — dann handelt es sich um einen Datenverarbeitungsdienst. Konsumiert der Kunde demgegenüber Daten, die der Anbieter selbst bereitstellt, ohne eigene Daten einzubringen, dient der Dienst der Content-Auslieferung. Die Systematik des DA stützt diese Lesart: Art. 23 lit. c und e DA beziehen sich durchgängig auf „exportierbare Daten des Kunden“. Wo keine kundeneigenen Daten vorhanden sind, laufen die Wechselmechaniken sachlogisch leer. Das ist wichtig zu erwähnen, weil bestimmte Hinweise der Kommission auf Musikdienste hinweisen, die von dem Anwendungsbereich ausgenommen seien. Solle der Kunde nur die Funktionsweise der Dienste in Anspruch nehmen wollen, läge typischerweise kein SaaS Dienst vor. Dass der Kunde aber nur die Funktionsweise eines Internetdienstes in Anspruch nehmen möchte, ist eine Selbstverständlichkeit, die nicht als Merkmal zur Abgrenzung taugt.
Für die Masse der B2B-SaaS-Anwendungen — ERP, CRM, Branchenlösungen aller Art — führt dieser zweite Prüfschritt in der Regel zur Scope-Eröffnung, weil Geschäftskunden mit dem Dienst eigene Daten verarbeiten. Der Zweckbindungstest ist damit kein tragendes Argument für den Scope-Ausschluss bei B2B-Software. Er greift allenfalls bei Grenzfällen rein content-orientierter Dienste.
3.) Die Grenzen für das, was wirklich unter das sechste Kapitel des DA fällt, ist damit für viele meiner Kunden eng gewählt und bedeutet am Ende, dass ihre Dienste nicht unter den Data Act fallen. Mit der Einschätzung muss man aber vorsichtig sein.
Grenzen der Aussagekraft der FAQ
Drei Punkte lässt Q58a offen, die in der Beratungspraxis erheblich sind.
Erstens: Die FAQ ist formal unverbindlich. Sie wird — so die ausdrückliche Vorbemerkung der Kommission — nicht als offizielle Position der Europäischen Kommission behandelt. Sie hat keine Bindungswirkung für nationale Gerichte, für die Bundesnetzagentur als deutsche Aufsichtsbehörde nur Orientierungsfunktion. Ein Gericht kann die Scope-Definition im Einzelfall anders auslegen, insbesondere im Rahmen einer Vorlagefrage an den EuGH.
Zweitens: Die Grenze zwischen „very limited actions from the provider“ und „significant intervention from the service provider“ ist nicht definiert. Ein vollautomatisches Dashboard ist klar Self-Service, ein mehrwöchiger Freigabe- und Validierungsprozess klar nicht. Dazwischen liegt eine Grauzone, in der das Ergebnis vom Einzelfall, von der Dokumentation des Prozesses und vom Tempo der Umsetzung abhängt. Die Kommission überlässt diese Grauzone bewusst der Praxis.
Drittens: Die teleologische Auslegung kann in eine andere Richtung ziehen als die wortlautbasierte. Der Schutzzweck des Kapitels VI — Abbau von Lock-in-Effekten — legt ein weites Verständnis nahe. Ein Gericht, das diesen Schutzzweck stark betont, könnte argumentieren, dass auch Dienste mit Change-Request-basierter Skalierung erfasst sind, wenn die Gesamtstruktur Lock-in-Effekte erzeugt. Das ist nicht die Linie der FAQ, aber es ist eine in der Literatur vertretene Gegenposition, und sie ist nicht abwegig.
Konsequenzen für die Vertragsgestaltung
Aus dieser Unsicherheit folgt eine beraterische Konsequenz, die ich Mandanten in dieser Phase durchgängig empfehle: Die Argumentation über den Anwendungsbereich allein reicht nicht. Es reicht nicht zu sagen: Wir fallen nicht unter das 6 Kapitel des Data Acts.
Es bleibt ein Prognoserisiko — und vor allem bleibt die Drohkulisse durch unzufriedene Kunden, die sich auf Art. 25 DA berufen und mit einer Aufsichtsanzeige bei der BNetzAgentur drohen.
Es braucht eine saubere Gestaltung in der technischen Architektur und in der Vertragsgestaltung. Das umfasst typischerweise Laufzeitrabatt-Konstruktionen, falls der Vertrags vorzeitig beendet wird, vorvertragliche Informationserfüllung nach Art. 29 Abs. 4 DA und Kündigungsvergütungs-Klauseln für den Switch-Fall — angelehnt an § 284 BGB, um den vergütungsmodell-agnostischen Aufwandsersatz dogmatisch sauber zu verankern.
