EU-DIGITALRECHT: Welche Rechtspflichten treffen zukünftig Anbieter von SaaS-Diensten (Software as a Service)?

Cloudbasierte Softwarelösungen („Software as a Service“, SaaS) sind für viele Unternehmen inzwischen ein zentraler Bestandteil operativer Prozesse und digitaler Geschäftsmodelle. Produktions- und Betriebsdaten werden in Echtzeit über zentrale Plattformen verarbeitet, Anwendungen werden standortübergreifend bereitgestellt und Funktionen lassen sich flexibel skalieren. Diese Entwicklung schafft Effizienz und neue Wertschöpfungsmöglichkeiten, führt aber zugleich zu wachsender Abhängigkeit von externen Diensten, vernetzten Systemen und komplexen Datenflüssen. Damit rücken auch rechtliche Anforderungen stärker in den Mittelpunkt. Unternehmen stehen vor der Aufgabe, ihre SaaS-Lösungen sowohl vertraglich als auch technisch so auszugestalten, dass sie regulatorische Vorgaben erfüllen und zugleich betriebliche Flexibilität sichern. Im Folgenden beleuchten wir die maßgeblichen rechtlichen Fragestellungen und zeigen auf, wie SaaS im Unternehmenskontext rechtssicher und zukunftsfähig eingesetzt werden kann.

I. Überblick: SaaS im Spannungsfeld der EU-Regulierung

SaaS-Dienste nehmen im europäischen Digitalrechtsrahmen eine besondere Stellung ein, weil sie zugleich Infrastruktur, Datenverarbeitungsumgebung und oftmals Bestandteil von Produkten oder Geschäftsprozessen sind. Ihre Einordnung entscheidet darüber, welche Pflichten zu Datenzugang, Sicherheit, Interoperabilität oder Verantwortlichkeit gelten; die Vorgaben unterscheiden sich je nach Funktionsumfang erheblich. Zudem greifen unterschiedliche Regelungslogiken ineinander: Plattformregulierung, Sicherheitsrecht, Produktrecht und Zugangsregeln verfolgen jeweils eigene Schutzzwecke und überschneiden sich in SaaS-Umgebungen regelmäßig. Für Unternehmen entsteht dadurch die Herausforderung, technische, vertragliche und organisatorische Entscheidungen konsequent an einer zutreffenden regulatorischen Qualifikation auszurichten.

II. SaaS und der Data Act

Mit Inkrafttreten des Data Act im September 2025 und den nun vorliegenden Vorschlägen der Kommission zum Digital-Omnibus, der zentrale Begriffe präzisiert und einzelne Pflichten entschärft oder neu fasst (wir berichteten), entsteht für Unternehmen ein klarer, zugleich aber anspruchsvoller Rechtsrahmen für den Umgang mit SaaS-Diensten.

1. SaaS als „verbundener Dienst“ (Art. 2 Nr. 6)

SaaS-Dienste werden zum „verbundenen Dienst“, wenn sie funktional mit einem vernetzten Produkt verknüpft sind und dessen Nutzung im praktischen Betrieb erst ermöglichen oder wesentlich erweitern. Dieser Fall liegt häufig vor, wenn Maschinen, Fahrzeuge oder Geräte ihre Betriebsdaten nicht lokal verarbeiten, sondern über eine Cloud-Anwendung bereitstellen, auswerten oder miteinander austauschen. Die Cloud-Plattform wird dann Teil des Produktökosystems, weil Nutzer ohne sie nicht auf die erzeugten Daten zugreifen oder zentrale Funktionen des Produkts nutzen könnten. Für den Anbieter bedeutet dies, dass er als Dateninhaber im Sinne des Data Act auftritt und Nutzern ein rechtlich abgesicherter Zugang zu Produkt- und Servicedaten eröffnet werden muss. Die Nutzer erhalten einen Anspruch auf Auskunft und Weitergabe der Daten an von ihnen ausgewählte Dritte, und die technische Gestaltung des Dienstes muss sicherstellen, dass dieser Datenzugriff auch tatsächlich realisierbar ist. Dies betrifft insbesondere den Echtzeitabruf, die Bereitstellung technischer Schnittstellen sowie die Verpflichtung, die Weitergabe nicht durch vertragliche oder technische Barrieren zu erschweren (wir berichteten).

In der Praxis wird dies etwa relevant, wenn der SaaS-Dienst Betriebszustände von Maschinen analysiert, Fernzugriffe ermöglicht oder als Kommunikationsschnittstelle zwischen einzelnen Produkten dient. Solche Konstellationen führen dazu, dass Daten, die bislang exklusiv beim Hersteller lagen, nun dem Nutzer zustehen und auf dessen Wunsch auch Wettbewerbern zugänglich gemacht werden können. Der Anbieter hat zugleich sicherzustellen, dass Geschäftsgeheimnisse geschützt und nur unter angemessenen Vertraulichkeitsanforderungen weitergegeben werden. Der Digital-Omnibus-Entwurf verstärkt diese Schutzmechanismen, indem er ausdrücklich klarstellt, dass Dateninhaber die Weitergabe verweigern dürfen, wenn ein hohes Risiko besteht, dass Betriebs- oder Geschäftsgeheimnisse in Drittstaaten mit unzureichendem Schutzniveau offengelegt werden könnten. Die Verweigerung muss jedoch begründet werden und bleibt auf eng begrenzte Ausnahmefälle beschränkt.

2. SaaS als „Datenverarbeitungsdienst“ (Art. 2 Nr. 8)

Über die spezifische Produktanbindung hinaus fallen viele SaaS-Angebote unter das Regime für Datenverarbeitungsdienste. Dieses Kapitel des Data Act betrifft sämtliche Cloud-Dienste, die Daten speichern, verarbeiten oder in einer Plattformumgebung bereitstellen. Die zentrale Zielsetzung besteht darin, Wechselbarrieren abzubauen und Interoperabilität zwischen Diensten zu fördern. Für SaaS-Anbieter entsteht dadurch die Pflicht, ihre Systeme so auszugestalten, dass Kunden Daten in praktikabler Form exportieren und zu einem anderen Dienst überführen können. Verträge müssen klare Informationen über Leistungsumfang, technische Abhängigkeiten und die Bedingungen eines Anbieterwechsels enthalten; insbesondere dürfen Wechsel oder Datenausleitungen nicht durch überhöhte Gebühren oder proprietäre Formate behindert werden.

Der Digital-Omnibus greift hierbei mehrere praktischen Probleme auf. Für SaaS-Dienste, die nicht „von der Stange“ kommen, sondern in hohem Maße an die individuellen Anforderungen eines Kunden angepasst wurden, werden die Wechselpflichten abgemildert. Da solche Dienste ohne umfangreiche Vorkonfiguration oftmals nicht funktionsfähig sind, soll ihre vollständige Migration nicht erzwungen werden. Auch für kleinere Anbieter schafft der Entwurf Erleichterungen: Sie erhalten längere Übergangsfristen, dürfen bestimmte Vertragsmodelle fortführen und können Exit-Verfahren pragmatischer gestalten, ohne das Ziel des Data Act – die schrittweise Abschaffung von Lock-in-Effekten – zu gefährden. Gleichwohl bleiben zentrale Grundprinzipien erhalten, etwa das absehbare Verbot von Egress-Gebühren, das als essentiell für einen offenen Cloud-Markt gilt.

III. SaaS und der Digital Services Act

Für viele SaaS-Angebote stellt sich neben dem Data Act auch die Frage nach ihrer Einordnung als Hosting-Dienst im Sinne des Digital Services Act. Entscheidend ist dabei weniger, ob ein Dienst öffentlich zugänglich ist oder auf einen spezifischen Nutzerkreis beschränkt bleibt, sondern ob Nutzer – seien es Unternehmen, Mitarbeiter oder externe Partner – Inhalte, Daten oder sonstige Informationen „auf eigene Veranlassung“ in das System einstellen. Diese Voraussetzung ist bei modernen SaaS-Anwendungen regelmäßig erfüllt, da sie typischerweise Funktionen zum Upload, Austausch oder zur Speicherung von Daten bereitstellen. Damit unterfallen sie den allgemeinen Pflichten für Hosting-Dienste und müssen Verfahren vorhalten, die einen verantwortungsvollen Umgang mit gemeldeten rechtswidrigen Inhalten ermöglichen.

Der DSA differenziert nicht zwischen B2C- und B2B-Kontexten; maßgeblich ist allein die Rolle des Anbieters als Intermediär für Inhalte Dritter. Dies führt dazu, dass SaaS-Anbieter klare Prozesse für Hinweise auf rechtswidrige Inhalte etablieren müssen, nachvollziehbare Entscheidungen über deren Entfernung treffen und betroffene Nutzer hierüber informieren. Zudem besteht die Erwartung, dass Anbieter die Integrität ihres Dienstes aktiv schützen und im Falle erheblicher Straftaten entsprechende Meldungen an Behörden ermöglichen.

Diese Anforderungen greifen unabhängig von der Größe des Anbieters oder der Reichweite des Dienstes. Anders als die zusätzlichen Pflichten für sehr große Online-Plattformen gelten die Grundpflichten für sämtliche Hosting-Anbieter und damit für nahezu alle SaaS-Konstellationen. Unternehmen, die SaaS-Lösungen bereitstellen oder nutzen, sollten deshalb sicherstellen, dass ihre Plattformen über transparente Meldekanäle, strukturierte Prüfprozesse und eine nachvollziehbare Dokumentation von Entscheidungen verfügen. Dies gilt insbesondere dann, wenn Plattformen als Bestandteil größerer Ökosysteme eingesetzt werden, etwa zur Speicherung technischer Dokumentation, zur Kommunikation mit Kunden oder zur Verwaltung maschinengenerierter Daten.

IV. SaaS und KI-VO

Bei SaaS-Lösungen, die KI-Funktionalitäten bereitstellen, stellt sich zunächst die Frage, wer im Sinne der KI-Verordnung als Anbieter und wer als Betreiber des Systems einzustufen ist. Diese Rollen schließen sich nicht gegenseitig aus, sondern können je nach Organisationsmodell zusammenfallen oder auf mehrere Akteure verteilt sein. Entscheidend ist die tatsächliche Kontrolle über das System und die Verantwortung dafür, wie es eingesetzt wird. Ein Unternehmen, das ein KI-System selbst entwickelt oder für eigene Zwecke erstellen lässt, ist regelmäßig Anbieter und zugleich Betreiber, weil es sowohl die technische Ausgestaltung als auch die praktische Nutzung steuert. Werden hingegen nur die Ausgaben eines KI-Systems genutzt, ohne dass die technischen Abläufe oder die Betriebsumgebung kontrolliert werden, liegt lediglich die Rolle des Verwenders von Ausgaben vor, nicht aber die eines Betreibers. Die Unterscheidung ist wesentlich, weil Anbieter und Betreiber jeweils unterschiedlich umfassenden Pflichten der KI-Verordnung unterliegen.

Für SaaS-Modelle ist besonders die Konstellation relevant, in der ein Anbieter das KI-System über eine cloudbasierte Plattform bereitstellt und die technische Kontrolle über das System – also die Infrastruktur, das Modell und die Abläufe im Hintergrund – vollständig bei ihm verbleibt. In solchen Fällen entscheidet der Kunde darüber, wann und wofür das KI-System eingesetzt wird, während der Anbieter die Funktionsfähigkeit, Aktualisierungen, Monitoring-Mechanismen und technische Überwachung gewährleistet. Aus Sicht der KI-Verordnung spricht dies dafür, dass der Kunde Betreiber ist, weil er die Zwecke des Einsatzes definiert, Eingabedaten bestimmt und die Ausgaben bewertet, während der SaaS-Anbieter als zusätzlicher Anbieter einzustufen ist, sofern er das KI-System unter eigener Marke in Verkehr bringt oder zur Nutzung bereitstellt. Dass sich die Rechenprozesse auf Servern des SaaS-Anbieters abspielen, ändert an der Betreiberrolle des Kunden nichts; der Anbieter wird in dieser Hinsicht im Herrschaftsbereich des Kunden tätig und stellt lediglich die notwendigen technischen Komponenten bereit.

Besondere Relevanz gewinnt die Rollenabgrenzung in Bereichen, in denen SaaS-gestützte KI-Systeme in hochregulierten Einsatzfeldern verwendet werden, etwa bei der Verarbeitung von HR-Daten oder in Bildungsverfahren. Die KI-Verordnung stuft Systeme, die Entscheidungen über Zugang zu Beschäftigung, Personalentwicklung oder Leistungsbewertung treffen, ebenso wie Systeme, die Lernverläufe, Prüfungsleistungen oder Studierfähigkeit bewerten, grundsätzlich als Hochrisiko-KI ein. Damit unterliegen SaaS-Anbieter und -Betreiber weitreichenden Anforderungen an Datenqualität, Dokumentation, menschliche Aufsicht und Risikomanagement. Für SaaS-Anbieter bedeutet dies, dass sie, sobald ihr System für solche Zwecke eingesetzt wird, nicht nur technische Vorgaben erfüllen, sondern auch klären müssen, ob sie selbst als Anbieter, als nachgeschalteter Anbieter oder als Betreiber einzustufen sind. Für Kunden wiederum ergibt sich, dass sie bei Verwendung eines KI-SaaS-Dienstes zu HR- oder Bildungszwecken – etwa bei automatisierten Bewerbungsanalysen, Kompetenzbewertungen oder adaptiven Lernsystemen – regelmäßig als Betreiber gelten und damit selbst dem vollständigen Hochrisiko-Regime unterfallen.

V. SaaS und andere EU-Verordnungen

Über den Data Act, den DSA und die KI-VO hinaus werden SaaS-Dienste durch weitere europäische Regelwerke berührt, deren Anwendungsbereich sich allerdings unterschiedlich zur Natur cloudbasierter Dienste verhält. Besonders deutlich zeigt sich dies beim Cyber Resilience Act, der primär auf „Produkte mit digitalen Elementen“ abzielt und damit in erster Linie Hardware oder lokal installierte Software erfasst. Rein cloudbasierte SaaS-Dienste, die vollständig über Server des Anbieters bereitgestellt werden und ohne lokale Komponenten auskommen, fallen nach Erwägungsgrund 12 ausdrücklich nicht in den Anwendungsbereich des CRA. Für sie gelten stattdessen – je nach Ausgestaltung – die Vorgaben aus NIS2, insbesondere wenn der SaaS-Dienst als wesentlicher oder wichtiger Dienst mit Relevanz für die Unternehmens- oder Sektorsicherheit qualifiziert wird.

Eine weitere Rolle spielt das Barrierefreiheitsstärkungsgesetz, das digitale Dienste zur barrierefreien Gestaltung verpflichtet, wenn sie verbraucherorientierte Funktionen bereitstellen. Für SaaS-Anbieter wird dies etwa relevant, wenn über die Anwendung Buchungs-, Service- oder Interaktionsprozesse abgewickelt werden, die unmittelbar Endnutzer betreffen. Eine Online-Buchungsfunktion innerhalb einer SaaS-Plattform kann damit bereits ausreichen, um die Anforderungen an Zugänglichkeit, Wahrnehmbarkeit und Bedienbarkeit auszulösen. Auch im B2B-Umfeld kann dies Bedeutung gewinnen, sobald ein Dienst nicht ausschließlich intern, sondern als Kundenschnittstelle genutzt wird.

Schließlich schafft die E-Evidence-Verordnung ein verbindliches Verfahren für die grenzüberschreitende Anforderung von elektronischen Beweismitteln durch Strafverfolgungsbehörden. SaaS-Anbieter werden damit in die Pflicht genommen, innerhalb sehr kurzer Fristen – in der Regel zehn Tage, im Notfall acht Stunden – auf Anordnungen zu reagieren und gespeicherte Kommunikations- oder Nutzungsdaten bereitzustellen. Da sich die Verordnung unmittelbar an Anbieter digitaler Dienste richtet, müssen SaaS-Anbieter Verfahren implementieren, um Anfragen rechtzeitig zu identifizieren, zu prüfen und zu beantworten. Für Unternehmen, die SaaS-Dienste nutzen, entsteht dadurch eine zusätzliche Compliance-Ebene, weil Daten, die im Rahmen des Dienstes verarbeitet oder übertragen werden, potenziell Gegenstand solcher Anordnungen sein können.

VI. Handlungsempfehlungen

Für Unternehmen, die SaaS-Dienste anbieten oder nutzen, wird es zunehmend wichtiger, technische und vertragliche Strukturen frühzeitig auf die neuen regulatorischen Anforderungen auszurichten. Ausgangspunkt sollte eine klare Einordnung des jeweiligen Dienstes sein, da die Rollen als verbundener Dienst, Datenverarbeitungsdienst, Hosting-Anbieter oder KI-Betreiber unterschiedliche Pflichten auslösen. Im Bereich vernetzter Produkte empfiehlt es sich, die eigene Architektur so zu gestalten, dass Datenzugriffe, Weitergabemöglichkeiten und Schutzmaßnahmen für Geschäftsgeheimnisse von Beginn an berücksichtigt werden. Auch SaaS-Anbieter ohne Produktbezug sollten prüfen, inwieweit Wechselprozesse und Datenexporte technisch realisierbar sind und welche Anpassungen in der Vertragsgestaltung erforderlich werden.

Im Umgang mit KI-Funktionalitäten ist eine sorgfältige Rollen- und Risikoklassifizierung unverzichtbar. Unternehmen sollten dokumentieren, ob sie Anbieter, Betreiber oder Verwender eines KI-Systems sind und welche Prozesse zur Qualitätssicherung, menschlichen Aufsicht und Modellverwaltung implementiert werden müssen. Schließlich ist es ratsam, interne Compliance-Strukturen zu schaffen, die auch die Anforderungen des DSA, der E-Evidence-Verordnung oder des BFSG berücksichtigen. Dazu gehören dokumentierte Meldewege, transparente Entscheidungsprozesse, Sicherheitskonzepte nach NIS2 und verlässliche Abläufe zur Reaktion auf behördliche Anfragen. Eine frühzeitige Abstimmung zwischen Recht, IT, Produktentwicklung und Einkauf erleichtert es, diese Pflichten wirksam zu erfüllen und zugleich die eigene Flexibilität im Betrieb zu erhalten.

VII. Fazit

SaaS-Dienste werden künftig in nahezu allen Unternehmensbereichen unter einem deutlich engeren europäischen Rechtsrahmen betrieben. Mit dem Data Act, dem DSA und der KI-Verordnung stehen Regelwerke bereit, die den Betrieb, die Datenarchitektur und die Anbieterbeziehungen von SaaS grundlegend beeinflussen. Der nun vorliegende Digital-Omnibus-Entwurf schafft zusätzliche Klarheit, indem er zentrale Begriffe neu fasst und zugleich Übergangsfristen sowie Entlastungen vorsieht. 

Dieser Beitrag wurde in Zusammenarbeit mit unserer stud. Mitarbeiterin Emily Bernklau erstellt.