Zmiana dostawcy SaaS: jak wyjść z danymi według Data Act?

Wyobraź sobie, że firma zmienia system do obsługi zgłoszeń klientów. Nowe narzędzie jest już wybrane, budżet zatwierdzony, a zespół chce ruszać. Dotychczasowy dostawca udostępnia przycisk „eksport”. Po jego użyciu dostajesz plik z treścią zgłoszeń, ale bez załączników, relacji między rekordami i historii zmian.

Plik da się otworzyć, ale nie odtworzysz na nim obsługi klientów. Zespół nadal musi ustalić, jak przenieść brakujące elementy.

Data Act wymaga usuwania barier przy zmianie dostawcy usług przetwarzania danych, do których może należeć SaaS. Reguluje umowę, terminy, pomoc przy wyjściu i przenoszenie danych. Nie obiecuje jednak, że nowy produkt będzie miał identyczne funkcje ani że dawny dostawca zbuduje Ci integrację z konkurentem.

Czego dowiesz się z tego tekstu?

W skrócie

• Zasady zmiany dostawcy z rozdziału VI Data Act stosuje się od 12 września 2025 r. do usług spełniających ustawową definicję. Sama etykieta SaaS nie rozstrzyga sprawy.
• Umowa ma określać przenoszone dane i zasoby, procedurę, pomoc, terminy oraz usunięcie danych po zakończeniu procesu.
• Standardowo okres uprzedzenia przed rozpoczęciem migracji nie może przekroczyć dwóch miesięcy, a okres przejściowy wynosi najwyżej 30 dni kalendarzowych. Istnieją wyjątki.
• Po okresie przejściowym klient powinien mieć co najmniej 30 dni kalendarzowych na pobranie danych.
• Dla usług objętych zakazem od 12 stycznia 2027 r. nie wolno pobierać opłat za samą zmianę dostawcy. To nie znosi automatycznie zwykłych opłat za usługę ani dopuszczalnych opłat za wcześniejsze zakończenie umowy.

Czy Data Act obejmuje każdy SaaS?

Obejmuje usługi przetwarzania danych spełniające określone cechy, a nie każdą stronę internetową z abonamentem. Chodzi o usługę cyfrową zapewniającą dostęp przez sieć na żądanie do współdzielonych, konfigurowalnych, skalowalnych zasobów, które można szybko przydzielać i zwalniać przy minimalnej obsłudze dostawcy. W SaaS zasobem może być aplikacja.

Przy systemie zgłoszeń sprawdź, czy klient rzeczywiście korzysta z takiej usługi: uruchamia środowisko, zarządza dostępem i zmienia zakres wykorzystania aplikacji. Samo oglądanie filmów w serwisie streamingowym nie oznacza automatycznie korzystania z usługi przetwarzania danych w tym rozumieniu. Komisja Europejska wyjaśnia te granice w FAQ, zwłaszcza w pytaniach 52 i 58a.

Znaczenie ma także rynek: przepisy obejmują dostawców oferujących te usługi klientom w UE niezależnie od miejsca siedziby dostawcy. Amerykański adres w regulaminie sam w sobie nie wyłącza obowiązków. Podstawą są definicja usługi i zakres podmiotowy Data Act, art. 2 pkt 8 oraz art. 1 ust. 3 lit. f.

Nie przenoś tu automatycznie wyjątków dla małych producentów urządzeń z innych części rozporządzenia. Propozycje dodatkowych zwolnień dla mniejszych dostawców chmury w Digital Omnibus trzeba odróżniać od obowiązującego prawa. Na 6 października 2026 r. procedura dotycząca tego projektu nadal oczekuje na decyzję komisji parlamentarnych.

Co klient powinien móc zabrać?

Zakres eksportu obejmuje dane wejściowe, wyjściowe i metadane powstałe bezpośrednio lub pośrednio przez korzystanie z usługi, z ustawowymi wyłączeniami. Metadane to informacje opisujące inne dane, np. powiązanie załącznika ze zgłoszeniem albo czas jego utworzenia. Ich brak może sprawić, że eksport będzie mało użyteczny.

W naszym systemie sprawdziłbym osobno treść zgłoszeń, załączniki, identyfikatory, powiązania, statusy i historię zmian. To lista do oceny na podstawie faktycznego produktu, nie uniwersalny katalog obowiązkowego eksportu dla każdego SaaS.

Umowa powinna wyczerpująco wskazywać kategorie przenoszonych danych i zasobów cyfrowych. Zasoby cyfrowe to elementy potrzebne do używania danych w nowym środowisku, z których klient ma prawo korzystać niezależnie od umowy z dotychczasowym dostawcą. Mogą obejmować konfigurację czy aplikacje, ale zakres trzeba sprawdzić dla konkretnej usługi.

Wyłączenia chronią m.in. własność intelektualną i tajemnice przedsiębiorstwa dostawcy lub osób trzecich. Data Act nie daje klientowi automatycznie kodu źródłowego platformy. Umowa ma też wskazywać wyłączone kategorie danych dotyczących wewnętrznego działania usługi, gdy istnieje ryzyko naruszenia tajemnicy dostawcy; takie wyłączenia nie mogą blokować ani opóźniać ustawowej zmiany dostawcy. Te granice wynikają z definicji i art. 25 Data Act.

Czy plik CSV wystarczy do migracji?

Format trzeba ocenić razem z zawartością, dokumentacją i możliwością użycia danych. CSV może być dobrym rozwiązaniem dla prostej tabeli. Przy zgłoszeniach z załącznikami, relacjami i historią potrzebujesz sposobu przeniesienia także tych elementów.

Dla SaaS przepisy przewidują bezpłatne otwarte interfejsy ułatwiające zmianę dostawcy. Interfejs, np. API, powinien być opisany na tyle dokładnie, żeby można było stworzyć oprogramowanie komunikujące się z usługą. Obowiązek zapewnienia zgodności z określonymi standardami zależy od ich publikacji w unijnym repozytorium i właściwego terminu. Dla zmiany między usługami tego samego typu, gdy takich standardów nie opublikowano, rozporządzenie przewiduje na żądanie eksport wszystkich danych podlegających eksportowi w formacie ustrukturyzowanym, powszechnie używanym i nadającym się do odczytu maszynowego. Art. 26 i 30 Data Act.

Przed podpisaniem umowy poproś o próbkę eksportu, opis pól, sposób pobrania załączników i ograniczenia API. Potem wykonaj próbny import. To rekomendacja organizacyjna: ustawa nie każe każdemu klientowi wykonywać identycznego testu.

Ile trwa zmiana dostawcy SaaS?

Trzeba rozdzielić trzy okresy. „Dane dostępne przez 30 dni” nie wyjaśnia jeszcze, kiedy zaczyna się migracja i kiedy kończy umowa.

Etap	Zasada	Co ustalić
Uprzedzenie o zmianie	Maksymalnie dwa miesiące przed rozpoczęciem procesu	Kanał zgłoszenia, data otrzymania i początek migracji
Okres przejściowy	Bez zbędnej zwłoki, standardowo najwyżej 30 dni kalendarzowych	Pomoc, ciągłość usługi, bezpieczeństwo i plan przełączenia
Pobranie danych po okresie przejściowym	Co najmniej 30 dni kalendarzowych	Dostęp, termin usunięcia i potwierdzenie zakończenia procesu

Jeżeli 30-dniowy okres przejściowy jest technicznie niewykonalny, dostawca ma 14 dni roboczych od otrzymania żądania zmiany, żeby zawiadomić klienta, uzasadnić niewykonalność i wskazać alternatywny okres, nie dłuższy niż siedem miesięcy. Samo „mamy dużo zgłoszeń” nie jest takim uzasadnieniem. Klient ma też umowne prawo do jednokrotnego przedłużenia okresu przejściowego do terminu odpowiedniego dla swoich potrzeb. Art. 25 Data Act.

Umowa ma przewidywać jej zakończenie po udanej zmianie dostawcy. Gdy klient wybiera wyłącznie usunięcie danych bez migracji, zakończenie następuje po maksymalnym okresie uprzedzenia.

W systemie zgłoszeń najpierw przenosimy starsze sprawy i testujemy import. Potem planujemy końcowy eksport nowych zgłoszeń oraz przełączenie integracji. Zespół powinien wiedzieć, kto potwierdza poprawność migracji. Późniejsze okno pobrania danych nie jest automatycznie obietnicą dalszego działania całej aplikacji na dotychczasowych zasadach.

Za co można zapłacić przed i po 12 stycznia 2027 r.?

Dla usług objętych art. 29 do 12 stycznia 2027 r. opłaty za zmianę nie mogą przekraczać kosztów dostawcy bezpośrednio związanych z danym procesem. Od tej daty takich opłat nie wolno pobierać. Obejmuje to również transfer danych związany ze zmianą, określany jako data egress.

Trzeba jednak rozdzielić opłatę za migrację od zwykłego abonamentu oraz opłaty za wcześniejsze zakończenie kontraktu. Definicja opłat za zmianę nie obejmuje tych dwóch ostatnich kategorii. Ich dopuszczalność i wysokość ocenia się osobno według umowy i właściwego prawa. Zakaz nie oznacza więc, że od stycznia można bez żadnego rozliczenia wyjść z każdej wieloletniej umowy. Dostawca powinien ujawnić te koszty przed jej zawarciem. Art. 2 pkt 36 i art. 29 Data Act.

Nie każdy transfer między chmurami jest zmianą dostawcy. Stałe równoległe korzystanie z usług może wiązać się z innym rozliczeniem transferu także po tej dacie. Komisja odróżnia taki model od migracji w pytaniu 54 FAQ.

Wyjątki: rozwiązanie szyte na miarę i wersja testowa

Indywidualna umowa nie wystarczy, żeby cały SaaS uznać za wyłączony. Szczególne zasady dotyczą usług, których większość głównych funkcji powstała dla potrzeb jednego klienta albo wszystkie komponenty opracowano dla niego, i które nie są oferowane na szeroką skalę przez katalog dostawcy.

Taki wariant jest zwolniony z konkretnych obowiązków, w tym art. 29 o opłatach. Nadal obowiązują inne przepisy, np. dotyczące umowy, informacji, otwartych interfejsów i eksportu. Dodanie logo klienta, konfiguracja ról czy kilka integracji do standardowego systemu nie rozstrzygają automatycznie o spełnieniu wyjątku.

Osobny wyjątek obejmuje nieprodukcyjną wersję udostępnioną do testów i oceny na ograniczony czas. Wówczas rozdział VI nie ma zastosowania. Dostawca ma poinformować przed zawarciem umowy, które obowiązki nie mają zastosowania. Art. 31 Data Act.

Kto odtwarza procesy i kiedy usuwa dane?

Data Act nie nakłada na dostawcę SaaS ogólnego obowiązku odtworzenia jego produktu u konkurenta. Szczególne wymaganie ułatwiania osiągnięcia równoważności funkcjonalnej dotyczy infrastruktury IaaS. SaaS ma inne obowiązki techniczne, w tym interfejsy i eksport. Zakres odpowiedzialności dotychczasowego dostawcy pozostaje związany z jego własną usługą. Art. 24 i 30 oraz pytanie 58b FAQ Komisji.

Firma zmieniająca system zgłoszeń powinna więc przypisać komuś odtworzenie automatyzacji, ról i integracji w nowym narzędziu. Potrzebne są także uzgodnienia z nowym dostawcą: format przyjęcia danych, terminy i odpowiedzialność za import.

Usunięcie danych planujemy po udanym przejściu i upływie okresu pobrania albo późniejszego uzgodnionego terminu, zgodnie z umową wymaganą przez Data Act. Gdy dostawca przetwarza dane osobowe w imieniu klienta, dochodzi art. 28 ust. 3 lit. g RODO: po zakończeniu takich usług umowa ma przewidywać zwrot lub usunięcie danych według decyzji administratora oraz usunięcie kopii, chyba że prawo UE lub państwa członkowskiego wymaga przechowywania. Harmonogram migracji trzeba z tym pogodzić, a nie wpisać „kasujemy wszystko po wypowiedzeniu” i liczyć na szczęście.

Co uzgodnić, zanim firma będzie chciała odejść?

W systemie zgłoszeń dobry załącznik do umowy powinien pozwolić zespołowi zaplanować wyjście bez odkrywania podstaw produktu w ostatnim tygodniu:

• kategorie danych i zasobów, które przenosimy, oraz uzasadnione wyłączenia;
• formaty, dokumentację, interfejsy i sposób przekazania załączników;
• terminy zgłoszenia, migracji, pobrania i usunięcia;
• odpowiedzialność za eksport, import, walidację i końcowe przełączenie;
• zasady pomocy, ciągłości usługi, bezpieczeństwa i rozliczeń.

Plan wyjścia uzupełnia SLA i pomiar dostępności usługi. Przy narzędziach wykorzystujących AI warto połączyć go również z oceną dostawcy, retencji i przepływów danych.

Jeżeli sprzedajesz SaaS albo negocjujesz jego zakup, w ramach wsparcia prawnego dla SaaS możemy sprawdzić, czy zapis o wyjściu da się wykonać na Twoich danych i w Twoim produkcie. Umów konsultację.

Źródła i stan przepisów

Stan na 6 października 2026 r.

• Data Act, rozporządzenie 2023/2854, zwłaszcza definicje, rozdział VI i art. 50. Oficjalny tekst EN w Urzędzie Publikacji UE.
• FAQ Komisji Europejskiej, wersja 1.4 z 22 stycznia 2026 r.: zakres SaaS i granice obowiązków przy migracji. FAQ pomaga w interpretacji, ale nie zastępuje przepisu.
• RODO: obowiązki procesora przy zakończeniu usług.
• Digital Omnibus, procedura 2025/0360(COD): projekt zmian, oddzielony od obecnych obowiązków.