Data Act a wyjście z SaaS. Jakie dane można przenieść i gdzie kończą się obowiązki dostawcy?

Data Act obejmuje SaaS, ale sama nazwa usługi nie wystarcza

Rozdział VI Data Act reguluje zmianę dostawcy usług przetwarzania danych. Rozporządzenie stosuje się od 12 września 2025 r.

Art. 2 pkt 8 definiuje usługę przetwarzania danych jako usługę cyfrową świadczoną klientowi, która zapewnia sieciowy dostęp na żądanie do wspólnego zbioru konfigurowalnych, skalowalnych i elastycznych zasobów obliczeniowych. Motyw 81 wskazuje IaaS, PaaS i SaaS jako podstawowe modele świadczenia takich usług.

Nie oznacza to, że każda aplikacja sprzedawana pod nazwą SaaS automatycznie podlega wszystkim obowiązkom rozdziału VI. W przypadku konkretnej usługi trzeba najpierw sprawdzić, czy spełnia definicję z art. 2 pkt 8 oraz czy nie ma zastosowania jeden ze szczególnych wyjątków.

Data Act definiuje też „usługę tego samego typu”. Są to usługi, które mają ten sam główny cel, opierają się na tym samym modelu usługi przetwarzania danych i mają te same najważniejsze funkcje. To rozróżnienie ma znaczenie m.in. dla części obowiązków technicznych związanych ze zmianą dostawcy.

Dane eksportowalne nie oznaczają całej zawartości platformy

Dla procesu migracji podstawowe znaczenie ma pojęcie „danych eksportowalnych”.

Art. 2 pkt 38 obejmuje dane wejściowe i wyjściowe, w tym metadane, bezpośrednio lub pośrednio wygenerowane albo współwygenerowane wskutek korzystania przez klienta z usługi przetwarzania danych. Definicja wyłącza aktywa i dane chronione prawami własności intelektualnej albo stanowiące tajemnicę przedsiębiorstwa dostawcy lub osoby trzeciej.

W systemie CRM, ERP lub innym SaaS-em zakresem eksportu mogą więc być objęte dane wprowadzone przez klienta, dane wyjściowe powstające podczas korzystania z systemu oraz związane z nimi metadane, o ile spełniają definicję ustawową i nie podlegają wyłączeniu.

Nie można z tej definicji wyprowadzić ogólnego prawa do otrzymania kodu źródłowego aplikacji, algorytmów dostawcy, jego narzędzi administracyjnych czy wszystkich informacji wykorzystywanych wewnętrznie przez platformę.

Aktywa cyfrowe są odrębną kategorią

Art. 2 pkt 32 definiuje aktywa cyfrowe jako elementy w formacie cyfrowym, w tym aplikacje, do których klient ma prawo użytkowania niezależne od stosunku umownego dotyczącego usługi, z której zamierza odejść.

Znaczenie ma zatem nie tylko techniczna obecność danego komponentu w środowisku SaaS, ale również podstawa prawna korzystania z niego.

Jeżeli klient ma niezależne prawo do konkretnej aplikacji lub innego zasobu cyfrowego, taki element może kwalifikować się jako aktywo cyfrowe. Sam fakt, że komponent jest wykorzystywany przez system dostawcy, nie daje natomiast automatycznie prawa do jego przejęcia.

Data Act wyznacza także granice obowiązków dostawcy

Art. 30 ust. 6 wskazuje wprost, czego dostawca nie musi robić w ramach zmiany usługi.

Przepis nie wymaga opracowywania nowych technologii ani nowych usług na potrzeby migracji. Dostawca nie jest również zobowiązany do ujawniania lub przekazywania klientowi albo nowemu dostawcy aktywów cyfrowych chronionych prawami własności intelektualnej lub stanowiących tajemnicę przedsiębiorstwa. Proces zmiany nie może też prowadzić do naruszenia bezpieczeństwa i integralności usługi klienta lub dostawcy.

To istotna granica między przenoszalnością danych a przeniesieniem samej technologii produktu. Data Act reguluje wyjście z usługi, ale nie ustanawia prawa do sklonowania SaaS u innego dostawcy.

Umowa powinna określać zakres migracji jeszcze przed jej rozpoczęciem

Art. 25 wymaga, aby prawa klienta i obowiązki dostawcy związane ze zmianą dostawcy były jasno określone w pisemnej umowie.

Umowa ma zawierać m.in. wyczerpującą specyfikację kategorii danych i aktywów cyfrowych, które można przenieść. Zakres musi obejmować co najmniej wszystkie dane eksportowalne. Powinna również wskazywać kategorie danych specyficznych dla wewnętrznego funkcjonowania usługi, które wyłączono ze względu na ryzyko naruszenia tajemnicy przedsiębiorstwa dostawcy. Takie wyłączenia nie mogą utrudniać ani opóźniać procesu zmiany przewidzianego w art. 23.

Art. 26 nakłada dodatkowo obowiązek przekazania klientowi informacji o dostępnych procedurach, metodach i formatach zmiany dostawcy oraz o znanych ograniczeniach technicznych. Dostawca ma również wskazać aktualny rejestr internetowy opisujący struktury i formaty danych oraz odpowiednie standardy i otwarte specyfikacje interoperacyjności.

Zakres wyjścia z systemu można więc analizować na etapie wyboru SaaS i negocjowania umowy. Nie trzeba czekać do momentu wypowiedzenia.

Otwarte interfejsy mają ułatwiać zmianę dostawcy

Art. 30 rozróżnia obowiązki usług infrastrukturalnych od pozostałych usług przetwarzania danych.

W przypadku usług innych niż infrastrukturalne określone w art. 30 ust. 1 dostawca ma bezpłatnie udostępnić otwarte interfejsy swoim klientom oraz właściwym dostawcom docelowym. Interfejsy mają zawierać informacje wystarczające do stworzenia oprogramowania komunikującego się z usługą na potrzeby przenoszenia danych i interoperacyjności.

Komisja Europejska jako przykłady tej kategorii wskazuje PaaS i SaaS.

Zakres tego obowiązku nadal zależy jednak od kwalifikacji konkretnej usługi na podstawie Data Act oraz od ewentualnych wyjątków z art. 31.

Eksport w formacie maszynowym zależy od rodzaju migracji

Art. 30 ust. 5 przewiduje szczególną regułę przy zmianie pomiędzy usługami tego samego typu.

Jeżeli odpowiednie wspólne specyfikacje lub normy zharmonizowane dotyczące interoperacyjności nie zostały opublikowane w centralnym repozytorium Unii, dostawca na żądanie klienta eksportuje wszystkie dane eksportowalne w formacie ustrukturyzowanym, powszechnie używanym i nadającym się do odczytu maszynowego.

Przepis nie gwarantuje, że format eksportowy będzie identyczny z modelem danych używanym przez nowego dostawcę. Nie wynika z niego również obowiązek automatycznego przekształcenia wszystkich rekordów do struktury docelowego systemu.

Sama definicja zmiany dostawcy w Data Act uwzględnia ekstrakcję, transformację i załadowanie danych. Migracja może więc wymagać dodatkowego mapowania i przekształcenia danych mimo prawidłowo wykonanego eksportu.

Równoważność funkcjonalna nie jest ogólną gwarancją dla SaaS

Obowiązek podejmowania rozsądnych środków w celu ułatwienia osiągnięcia równoważności funkcjonalnej z art. 30 ust. 1 dotyczy usług opartych na skalowalnych i elastycznych zasobach obliczeniowych ograniczonych do elementów infrastrukturalnych, takich jak serwery, sieci i zasoby wirtualne.

Nie należy więc zakładać, że po migracji pomiędzy dwoma systemami CRM, ERP czy innymi aplikacjami SaaS nowa usługa musi automatycznie odtworzyć sposób działania poprzedniej.

W konkretnym projekcie mogą być potrzebne mapowanie modeli danych, odtworzenie konfiguracji, przebudowa integracji, ponowne skonfigurowanie autoryzacji lub przeniesienie procesów zależnych od funkcji charakterystycznych dla dotychczasowej platformy. To techniczne elementy projektu migracyjnego, których nie zastępuje samo prawo do eksportu danych.

W zmianie dostawcy uczestniczy więcej niż jedna strona

Art. 27 nakłada obowiązek współpracy w dobrej wierze na wszystkie strony uczestniczące w procesie, w tym na docelowego dostawcę usług przetwarzania danych.

Celem współpracy ma być skuteczna zmiana dostawcy, terminowe przekazanie danych oraz utrzymanie ciągłości usługi.

Nie wszystkie zadania techniczne związane z migracją są zatem obowiązkiem wyłącznie dostawcy, z którego klient rezygnuje.

Data Act określa maksymalne terminy procesu

Umowa musi przewidywać maksymalny okres wypowiedzenia rozpoczynający proces zmiany dostawcy. Nie może on przekroczyć dwóch miesięcy.

Po nim maksymalny obowiązkowy okres przejściowy wynosi co do zasady 30 dni kalendarzowych. Jeżeli dotrzymanie tego terminu jest technicznie niewykonalne, dostawca ma w ciągu 14 dni roboczych od otrzymania wniosku poinformować klienta, uzasadnić przyczynę i wskazać alternatywny okres przejściowy. Nie może on przekroczyć siedmiu miesięcy.

Klient ma ponadto prawo jednokrotnie przedłużyć okres przejściowy o okres, który uzna za odpowiedniejszy do swoich potrzeb. Po jego zakończeniu umowa musi zapewniać co najmniej 30 dni kalendarzowych na pobranie danych.

30 dni nie jest więc bezwzględnym czasem trwania każdej migracji.

Od 12 stycznia 2027 r. znikną opłaty objęte art. 29

Art. 29 ust. 1 stanowi, że od 12 stycznia 2027 r. dostawcy usług przetwarzania danych nie mogą nakładać na klienta opłat z tytułu zmiany dostawcy za proces zmiany.

Definicja takich opłat obejmuje należności inne niż standardowe opłaty za usługę lub kary za wcześniejsze rozwiązanie umowy, nakładane za działania wymagane przez Data Act przy przejściu do systemu innego dostawcy lub infrastruktury lokalnej. Obejmuje również opłaty za wychodzący ruch danych.

Do 12 stycznia 2027 r. możliwe są obniżone opłaty z tytułu zmiany dostawcy, ale nie mogą przekraczać kosztów poniesionych przez dostawcę i bezpośrednio związanych z konkretnym procesem zmiany.

Zniesienie tych opłat nie oznacza, że każda migracja będzie całkowicie bezkosztowa. Standardowe opłaty za usługę pozostają poza definicją switching charges. Możliwe są również zgodne z prawem kary za wcześniejsze rozwiązanie umowy. Dodatkowe usługi zamówione przez klienta ponad obowiązki wynikające z Data Act mogą być odpłatne, jeżeli klient zaakceptował ich cenę.

Niektóre usługi zbudowane na zamówienie podlegają szczególnemu reżimowi

Art. 31 ust. 1 wyłącza część obowiązków rozdziału VI wobec usług, w których większość głównych cech została opracowana na zamówienie dla indywidualnego klienta albo wszystkie komponenty stworzono dla tego klienta, jeżeli jednocześnie usługa nie jest oferowana komercyjnie na szeroką skalę poprzez katalog dostawcy.

W takim przypadku nie stosuje się m.in. art. 29 oraz art. 30 ust. 1 i 3.

Sam marketingowy opis produktu jako „dedykowanego SaaS” nie rozstrzyga więc o zastosowaniu wyjątku. Trzeba sprawdzić przesłanki z art. 31.

Art. 31 ust. 2 przewiduje dodatkowy wyjątek dla usług udostępnianych jako wersje nieprodukcyjne do testowania i oceny przez ograniczony czas. W ich przypadku nie stosuje się obowiązków całego rozdziału VI.

Digital Omnibus pozostaje projektem

19 listopada 2025 r. Komisja Europejska przedstawiła projekt Digital Omnibus, COM(2025) 837 final, który obejmuje również proponowane zmiany Data Act. Projekt jest procedowany pod numerem 2025/0360(COD).

Pierwotny wniosek Komisji przewiduje m.in. dodatkowe rozwiązania dotyczące części usług dostosowanych do indywidualnego klienta oraz określonych usług świadczonych przez MŚP i małe spółki o średniej kapitalizacji na podstawie starszych umów. Propozycja odróżnia te przypadki od obecnego wyjątku dla usług custom-built z art. 31 ust. 1.

Na 25 września 2026 r. Digital Omnibus nie jest obowiązującym prawem. Procedura Parlamentu Europejskiego ma status „Awaiting committee decision”.

Przy ocenie aktualnych obowiązków dostawcy należy więc opierać się na obowiązującym brzmieniu Data Act. Projekt Digital Omnibus ma znaczenie dla monitorowania możliwych zmian, ale nie powinien być przedstawiany jako obecny stan prawny.

Sam eksport danych nie usuwa vendor lock-in

Możliwość pobrania danych jest tylko jednym z elementów wyjścia z SaaS. Zależność od dostawcy może wynikać również z architektury aplikacji, sposobu konfiguracji procesów, dostępnych integracji, modelu danych czy wykorzystania funkcji, których nie ma w systemie docelowym.

Przed zawarciem umowy warto dlatego sprawdzić zakres danych eksportowalnych, dostępne formaty, dokumentację API, możliwość automatycznego pobierania danych, sposób opisania relacji między rekordami, prawa do aktywów cyfrowych oraz umowne zasady zmiany dostawcy.

Data Act wyznacza prawne ramy migracji i ogranicza część barier związanych ze zmianą usług. Nie zastępuje technicznego planu migracji ani oceny, które elementy obecnego systemu można rzeczywiście odtworzyć u innego dostawcy.

Stan prawny i dokumentacyjny: 25 września 2026 r.

Tekst ma charakter informacyjny. Ocena konkretnej usługi, postanowień umownych, zakresu danych eksportowalnych oraz zastosowania wyjątków może wymagać analizy danego przypadku.