Data Act a zmiana dostawcy chmury — jak przygotować Cloud Exit i uniknąć vendor lock-in?

Migracja do chmury zwykle zaczyna się od pytania, jak szybko uruchomić system, obniżyć koszty infrastruktury i zwiększyć skalowalność. Znacznie rzadziej przedsiębiorca pyta na początku projektu, jak za kilka lat z tej chmury wyjdzie. Problem pojawia się dopiero wtedy, gdy firma chce zmienić dostawcę, przenieść dane do konkurencyjnego środowiska, wrócić do infrastruktury lokalnej albo rozdzielić poszczególne usługi pomiędzy kilku operatorów.

Wówczas okazuje się, że techniczne uruchomienie systemu było znacznie prostsze niż jego migracja. Dane znajdują się w specyficznym formacie, aplikacja korzysta z usług dostępnych wyłącznie u jednego dostawcy, dokumentacja jest niekompletna, koszt transferu danych jest bardzo wysoki, a rozwiązanie umowy nie oznacza automatycznie uzyskania kompletnego i użytecznego eksportu. Zjawisko to określane jest jako vendor lock-in, czyli uzależnienie klienta od konkretnego dostawcy technologii.

Problem od lat występuje w przypadku usług chmurowych, hostingu i SaaS, ale od wejścia w życie unijnego Data Act zmieniło się jego znaczenie prawne. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2023/2854, określane jako Data Act albo akt w sprawie danych, zawiera cały rozdział poświęcony zmianie dostawców usług przetwarzania danych. Celem regulacji jest ograniczenie barier technicznych, handlowych, organizacyjnych i umownych, które utrudniają klientowi przeniesienie się do innego dostawcy albo własnej infrastruktury ICT.

Dla przedsiębiorców korzystających z chmury oznacza to możliwość silniejszego zabezpieczenia prawa do migracji. Dla dostawców SaaS, PaaS i infrastruktury cloud oznacza natomiast konieczność zmiany sposobu konstruowania umów i procedur zakończenia współpracy.

Data Act nie sprawia jednak, że migracja automatycznie stanie się łatwa. Rozporządzenie nie przeniesie aplikacji z AWS do Azure, nie przepisze kodu korzystającego z usług proprietary i nie odtworzy dokumentacji, której nikt nie prowadził. Dlatego regulacyjne prawo do zmiany dostawcy powinno być połączone z odpowiednio zaprojektowanym Cloud Exit Planem oraz właściwą architekturą systemu.

Czym jest vendor lock-in?

Vendor lock-in oznacza sytuację, w której zmiana dostawcy jest możliwa teoretycznie, ale w praktyce jest bardzo kosztowna, długotrwała albo wiąże się z utratą danych, funkcjonalności lub istotnej części wcześniejszej inwestycji.

Uzależnienie może wynikać z technologii. System może wykorzystywać usługi właściwe wyłącznie dla jednej platformy, specyficzne bazy danych, mechanizmy serverless, narzędzia analityczne albo własne API dostawcy.

Może również wynikać z modelu danych. Nawet jeżeli klient posiada prawo do ich pobrania, nie musi oznaczać to możliwości łatwego zaimportowania danych do innego systemu. Plik może być niekompletny, pozbawiony relacji, metadanych, historii zdarzeń albo informacji potrzebnych do zachowania ciągłości biznesowej.

Vendor lock-in może mieć także charakter czysto umowny. Wieloletnia umowa może przewidywać wysoką opłatę za wcześniejsze zakończenie, bardzo długi okres wypowiedzenia albo odpłatność za każdą godzinę wsparcia migracyjnego.

Kolejną barierą bywa organizacja. Klient może nie posiadać własnej dokumentacji, a cała wiedza o konfiguracji środowiska znajduje się po stronie obecnego dostawcy.

Data Act próbuje ograniczyć kilka z tych mechanizmów jednocześnie. Nie dotyczy tylko eksportu plików. Art. 23 rozporządzenia nakazuje usuwać bariery przedkomercyjne, handlowe, techniczne, umowne i organizacyjne utrudniające klientowi zmianę dostawcy, przejście do infrastruktury lokalnej albo korzystanie jednocześnie z usług kilku dostawców.

Data Act obowiązuje już dzisiaj

Data Act jest stosowany od 12 września 2025 r. Oznacza to, że w 2026 r. jego regulacje dotyczące usług przetwarzania danych nie są już przyszłym obowiązkiem, do którego firmy dopiero powinny się przygotowywać.

Szczególne znaczenie ma rozdział VI rozporządzenia dotyczący zmiany dostawców usług przetwarzania danych.

Regulacja obejmuje między innymi usługi umożliwiające dostęp na żądanie do współdzielonych zasobów obliczeniowych, takich jak sieci, serwery, infrastruktura, platformy i oprogramowanie. Komisja Europejska wyraźnie wskazuje, że mechanizm zmiany dostawcy odnosi się do usług cloud i edge oraz obejmuje również Platform as a Service i Software as a Service.

Dlatego obowiązki Data Act nie dotyczą wyłącznie największych operatorów infrastruktury, takich jak AWS, Microsoft Azure czy Google Cloud.

Mogą mieć znaczenie również dla europejskich dostawców SaaS i innych przedsiębiorców oferujących usługi przetwarzania danych mieszczące się w definicji rozporządzenia.

Co Data Act rozumie przez zmianę dostawcy?

Rozporządzenie definiuje zmianę dostawcy jako proces, w którym uczestniczy dotychczasowy dostawca, klient oraz, jeżeli jest to potrzebne, nowy dostawca, a klient przechodzi z jednej usługi przetwarzania danych do innej usługi albo do własnej infrastruktury ICT.

Proces może obejmować ekstrakcję, transformację i załadowanie danych. Jest to ważne, ponieważ regulacja nie ogranicza się do prostego prawa pobrania pliku z danymi. Migracja jest traktowana jako proces. Dotychczasowy dostawca ma współpracować w sposób umożliwiający klientowi rzeczywiste przejście do innego środowiska.

Data Act przewiduje również możliwość korzystania przez klienta z kilku dostawców jednocześnie. Regulacja nie chroni więc wyłącznie klasycznego scenariusza, w którym firma całkowicie rezygnuje z jednej chmury na rzecz drugiej. Ma także przeciwdziałać przeszkodom utrudniającym modele multi-cloud.

Umowa musi regulować zmianę dostawcy

Jedną z najważniejszych zmian wprowadzonych przez Data Act jest wymaganie, aby prawa klienta i obowiązki dostawcy związane ze zmianą dostawcy zostały jasno opisane w pisemnej umowie.

Dostawca powinien udostępnić tę umowę klientowi przed jej podpisaniem w sposób umożliwiający jej zapisanie i odtworzenie. Nie wystarczy więc ogólny zapis, zgodnie z którym „po zakończeniu umowy klient może pobrać swoje dane”. Umowa powinna opisywać cały proces.

To właśnie w tym miejscu Cloud Exit przestaje być wyłącznie zagadnieniem technicznym i staje się jednym z podstawowych elementów kontraktu cloud lub SaaS.

Maksymalny okres przejściowy

Data Act przewiduje konkretny mechanizm czasowy zmiany dostawcy.

Co do zasady klient powinien móc przejść do nowego dostawcy albo przenieść dane do własnej infrastruktury bez zbędnej zwłoki, a proces powinien zostać zakończony w obowiązkowym maksymalnym okresie przejściowym wynoszącym 30 dni kalendarzowych po upływie odpowiedniego okresu wypowiedzenia. W okresie tym dotychczasowa umowa nadal obowiązuje, a dostawca ma zapewniać rozsądną pomoc klientowi i upoważnionym przez niego osobom uczestniczącym w migracji.

Nie oznacza to jednak, że każda migracja skomplikowanego środowiska powinna technicznie zakończyć się dokładnie trzydziestego dnia.

Niektóre systemy mogą wymagać dłuższego procesu. Data Act przewiduje sytuacje, w których okres może zostać odpowiednio dostosowany ze względu na techniczną niewykonalność zakończenia migracji w podstawowym terminie.

Z punktu widzenia umowy najważniejsze jest jednak odejście od modelu, w którym dostawca może dowolnie przedłużać proces wyjścia.

Cloud Exit powinien być planowany przed podpisaniem umowy

Najlepszy moment na ustalanie zasad wyjścia z chmury przypada przed migracją do chmury. Po pięciu latach korzystania z jednego ekosystemu możliwości negocjacyjne klienta są znacznie mniejsze.

Firma posiada już setki gigabajtów albo terabajtów danych, własny zespół zna konkretny system, integracje zostały dostosowane do konkretnego API, a zmiana wymaga wielomiesięcznej pracy. Dlatego podczas wyboru dostawcy należy analizować nie tylko funkcjonalności i cenę wejścia, ale również koszty wyjścia. Cloud Exit Plan powinien zostać przygotowany jeszcze przed podpisaniem najważniejszego kontraktu.

Nie oznacza to konieczności wskazania już wtedy przyszłego konkurencyjnego dostawcy. Firma nie musi wiedzieć, czy za pięć lat przeniesie się do AWS, Azure czy własnego data center.

Powinna natomiast wiedzieć, jakie dane będzie mogła wyeksportować, w jakim formacie, jak długo potrwa migracja, jakie wsparcie zapewni dostawca oraz jakie komponenty mogą być trudne do odtworzenia.

Jakie dane powinny zostać wyeksportowane?

Data Act posługuje się pojęciem danych eksportowalnych.

Obejmuje ono dane wejściowe i wyjściowe, w tym metadane, bezpośrednio lub pośrednio wygenerowane albo współgenerowane wskutek korzystania przez klienta z usługi. Wyłączone są natomiast określone aktywa i dane objęte prawami własności intelektualnej albo tajemnicą przedsiębiorstwa dostawcy lub osoby trzeciej.

Jest to znacznie szersze podejście niż pobranie podstawowej tabeli klientów.

W praktyce trzeba ustalić, czy migracja wymaga historii zdarzeń, konfiguracji, parametrów, metadanych, logów, danych transakcyjnych, załączników, struktur folderów oraz innych informacji pozwalających zachować funkcjonalność.

Umowa powinna maksymalnie precyzyjnie określić, co oznacza „dane klienta”. W przypadku rozbudowanego SaaS różnica pomiędzy „eksportem danych” a „eksportem umożliwiającym migrację” może być ogromna.

Format danych ma znaczenie

Sam fakt uzyskania kopii informacji nie oznacza realnej przenośności.

Dostawca może przekazać klientowi plik w technicznie możliwym do odczytania formacie, którego jednak praktycznie nie da się wykorzystać bez napisania dedykowanego narzędzia migracyjnego.

Komisja Europejska wskazuje, że w przypadku dostawców PaaS i SaaS Data Act wymaga zapewnienia otwartych interfejsów oraz co najmniej eksportu danych w powszechnie używanym i nadającym się do odczytu maszynowego formacie.

W umowie warto pójść jeszcze dalej i wskazać konkretny format tam, gdzie jest to możliwe. Może nim być CSV, JSON, XML, standardowy dump bazy danych albo format branżowy. Im bardziej standardowy format, tym mniejsze ryzyko vendor lock-in.

Dane to nie wszystko

Największym błędem podczas przygotowania Cloud Exit jest skupienie się wyłącznie na danych. W rzeczywistości migracja może wymagać znacznie więcej.

System może wykorzystywać konfiguracje, reguły biznesowe, automatyzacje, własne skrypty, dashboardy, definicje workflow, modele uprawnień, szablony dokumentów i integracje.

Część z tych elementów może stanowić dane eksportowalne, część może być aktywem cyfrowym klienta, a część może należeć do dostawcy. Właśnie dlatego przed zawarciem umowy warto przygotować mapę własności.

Należy ustalić, które elementy są własnością klienta, które dostawca jedynie udostępnia, które mogą zostać wyeksportowane oraz które będą musiały zostać odtworzone w nowym środowisku.

Równoważność funkcjonalna

Data Act posługuje się również pojęciem równoważności funkcjonalnej.

W przypadku infrastruktury IaaS dostawca powinien podejmować środki ułatwiające osiągnięcie przez klienta w nowym środowisku materialnie porównywalnych wyników dla funkcji wspólnych dla obu usług.

Nie należy jednak interpretować tego jako gwarancji, że konkurencyjna chmura będzie działać identycznie. AWS, Azure i Google Cloud posiadają różne usługi, API i modele konfiguracji. Data Act nie może usunąć różnic technologicznych pomiędzy konkurencyjnymi platformami. Dlatego architektura aplikacji nadal ma podstawowe znaczenie.

System korzystający głównie ze standardowych kontenerów, typowych baz danych i powszechnie stosowanych protokołów będzie łatwiejszy do migracji niż rozwiązanie silnie wykorzystujące unikalne usługi jednego dostawcy.

Data Act nie likwiduje technicznego vendor lock-in

Jest to jedna z najważniejszych rzeczy, które przedsiębiorca powinien rozumieć. Data Act ogranicza przeszkody w zmianie dostawcy, ale nie zmusza firm do tworzenia identycznych technologicznie produktów.

Jeżeli przedsiębiorca zdecydował się zbudować aplikację całkowicie opartą na narzędziach jednego dostawcy, migracja nadal może wymagać przebudowy systemu. Dlatego compliance powinien być połączony z architekturą.

Prawnik może zagwarantować prawo do eksportu danych, ale nie zagwarantuje prostego przeniesienia funkcji Lambda do Azure Functions, jeżeli aplikacja została napisana bez uwzględnienia możliwości migracji.

Vendor lock-in powinien być więc analizowany wspólnie przez dział prawny i techniczny.

Czy dostawca może pobierać opłatę za zmianę dostawcy?

Tak, ale jesteśmy właśnie w końcowym okresie przejściowym.

Do 12 stycznia 2027 r. dostawca może pobierać obniżone opłaty związane z procesem zmiany dostawcy. Nie mogą one przekraczać kosztów poniesionych przez dostawcę i bezpośrednio związanych z konkretną migracją.

Od 12 stycznia 2027 r. dostawcy usług przetwarzania danych nie będą mogli nakładać na klientów opłat z tytułu zmiany dostawcy. Regulacja obejmuje w tym zakresie również opłaty z tytułu wychodzącego ruchu danych mieszczące się w definicji opłat switchingowych. To bardzo istotna zmiana dla rynku chmurowego.

Opłaty za transfer dużych ilości danych były jednym z mechanizmów zwiększających koszt migracji z infrastruktury jednego dostawcy. Jednocześnie trzeba odróżnić opłatę za zmianę dostawcy od innych kosztów.

Data Act nie oznacza, że nowy dostawca musi bezpłatnie przeprowadzić migrację ani że klient nie poniesie kosztów własnych programistów, konsultantów, przebudowy aplikacji czy równoległego utrzymywania dwóch środowisk.

Regulacja eliminuje określone bariery po stronie dostawcy wyjściowego, a nie wszystkie koszty transformacji technologicznej.

Kara za wcześniejsze rozwiązanie umowy to osobna kwestia

Data Act odróżnia switching charges od standardowych opłat za usługę oraz kar lub opłat związanych z wcześniejszym rozwiązaniem umowy. Dostawca ma obowiązek jasno poinformować przyszłego klienta o takich kosztach przed zawarciem umowy.

Oznacza to, że zakaz opłat za zmianę dostawcy od stycznia 2027 r. nie powinien być rozumiany jako automatyczne prawo do bezkosztowego zerwania każdej umowy zawartej na kilka lat.

Jeżeli klient zawarł kontrakt na trzy lata z określonym zobowiązaniem minimalnym, przedterminowe zakończenie może nadal mieć konsekwencje ekonomiczne. Dlatego przy negocjowaniu umowy trzeba analizować dwa odrębne problemy.

Pierwszym jest możliwość technicznego wyjścia. Drugim jest możliwość prawnego rozwiązania kontraktu. Dobrze przygotowany Cloud Exit powinien uwzględniać oba.

Okres wypowiedzenia może być formą lock-in

Nawet świetna technicznie migracja nie pomoże, jeżeli klient musi jeszcze przez dwa lata płacić abonament staremu dostawcy. Dlatego warto analizować długość okresu wypowiedzenia oraz automatyczne przedłużanie umowy. Długie kontrakty nie są same w sobie niedopuszczalne. Dostawca może uzależniać niższą cenę od kilkuletniego zobowiązania. Klient powinien jednak świadomie ocenić koszt takiego modelu.

W szczególności należy uważać na automatyczne przedłużenie na kolejny długi okres, jeżeli wypowiedzenie musi zostać złożone wiele miesięcy przed końcem umowy.

Co powinien zawierać Cloud Exit Plan?

Cloud Exit Plan nie powinien być jedynie jednym paragrafem w umowie. W większych projektach warto potraktować go jako osobny załącznik techniczno-organizacyjny. Powinien opisywać proces od momentu podjęcia decyzji o migracji do ostatecznego usunięcia danych ze starego środowiska.

Należy ustalić, kto inicjuje proces, kto jest osobą kontaktową, jakie dane i aktywa podlegają eksportowi, w jakim formacie będą przekazywane oraz w jaki sposób nastąpi transfer.

Trzeba również określić odpowiedzialność za mapowanie danych, testy integralności, migrację użytkowników, konfigurację integracji i weryfikację nowego środowiska. Dla krytycznych systemów warto przewidzieć okres równoległego działania obu środowisk. Cloud Exit powinien również opisywać plan awaryjny na wypadek nieudanej migracji.

Kiedy migrację uznajemy za zakończoną?

To pozornie banalne pytanie często prowadzi do sporów. Dostawca może uznać migrację za zakończoną w momencie udostępnienia pliku z eksportem. Klient może uważać, że proces kończy się dopiero wtedy, gdy system u nowego operatora działa produkcyjnie. Umowa powinna zatem określić kryteria zakończenia procesu.

Może nim być potwierdzenie kompletności danych, zakończenie testów, uruchomienie nowego systemu albo podpisanie protokołu. Warto również ustalić, co stanie się w przypadku częściowego niepowodzenia.

Jeżeli 99,9% danych zostało przeniesionych, ale brakuje kilku tysięcy historycznych załączników, trudno uznać migrację za w pełni zakończoną.

Usunięcie danych po migracji

Cloud Exit nie kończy się na eksporcie. Trzeba ustalić, co dotychczasowy dostawca zrobi z pozostałymi kopiami. Umowa powinna określać termin usunięcia danych produkcyjnych, backupów, środowisk testowych i kopii wykorzystywanych do supportu.

Nie zawsze możliwe jest natychmiastowe selektywne usunięcie informacji ze wszystkich kopii zapasowych. Można więc przewidzieć ich dalsze pozostawanie do czasu automatycznego nadpisania, pod warunkiem że są zabezpieczone i nie są dalej wykorzystywane.

W przypadku danych osobowych zasady Cloud Exit muszą być dodatkowo spójne z umową powierzenia i wymaganiami RODO.

Co z backupami podczas migracji?

Migracja jest momentem podwyższonego ryzyka. Dane są kopiowane, eksportowane, transformowane i importowane do nowego systemu. Może się okazać, że dopiero po kilku dniach firma odkryje niekompletność danych. Dlatego nie należy usuwać starego środowiska natychmiast po pierwszym uruchomieniu nowego.

Umowa powinna przewidywać uzgodniony okres retencji bezpieczeństwa. Z drugiej strony nie należy utrzymywać dwóch pełnych środowisk bezterminowo, ponieważ zwiększa to koszt i powierzchnię ataku.

Prawo do pomocy dostawcy

Data Act wymaga, aby w okresie zmiany dotychczasowy dostawca zapewniał rozsądną pomoc klientowi i upoważnionym przez niego osobom trzecim.

W umowie warto jednak doprecyzować, co dokładnie oznacza pomoc. Czy obejmuje wyłącznie wygenerowanie eksportu? Czy dostawca odpowiada na pytania nowej firmy migracyjnej? Czy przygotuje dokumentację schematu bazy? Czy udostępni API migracyjne? Czy jego pracownicy będą uczestniczyli w spotkaniach technicznych? itd.

Im bardziej krytyczna usługa, tym bardziej szczegółowa powinna być odpowiedź.

Exit assistance w umowach enterprise

W większych kontraktach można zastosować rozbudowaną klauzulę exit assistance. Dostawca zobowiązuje się wówczas przez ustalony okres pomagać klientowi albo nowemu wykonawcy w przejęciu usługi.

Pomoc może obejmować dokumentację, przekazywanie wiedzy, wsparcie konfiguracji, eksport danych, spotkania techniczne i wyjaśnianie architektury.

Należy jednak dokładnie oddzielić czynności, które dostawca musi wykonać jako element swoich obowiązków wynikających z Data Act, od dodatkowych usług konsultingowych.

Od stycznia 2027 r. nie powinno się wykorzystywać odpłatnych usług dodatkowych do obchodzenia zakazu opłat za sam proces zmiany dostawcy.

Co z własnością intelektualną dostawcy?

Prawo klienta do migracji nie oznacza prawa do przejęcia całego know-how dostawcy.

Data Act wyraźnie wyłącza z pojęcia danych eksportowalnych określone aktywa i dane chronione prawami własności intelektualnej albo stanowiące tajemnicę przedsiębiorstwa dostawcy lub osoby trzeciej. Jest to szczególnie istotne przy SaaS.

Klient może posiadać prawo do swoich danych, ale nie oznacza to prawa do otrzymania kodu źródłowego aplikacji, algorytmów dostawcy czy dokumentacji jego własnej infrastruktury.

Dlatego należy rozróżnić przenośność danych od przenośności całego rozwiązania.

Jeżeli klient chce posiadać możliwość przejęcia kodu po zakończeniu współpracy, trzeba to uregulować osobno, przykładowo poprzez przeniesienie praw autorskich, licencję albo escrow kodu źródłowego.

SaaS a escrow kodu

W niektórych projektach cloud exit można uzupełnić o escrow. Kod źródłowy albo kluczowe materiały są przechowywane przez niezależny podmiot i mogą zostać wydane klientowi po wystąpieniu określonych zdarzeń, przykładowo upadłości dostawcy, trwałym zaprzestaniu świadczenia usługi albo istotnym naruszeniu obowiązków.

Escrow nie jest potrzebne przy każdym systemie SaaS. Może być jednak uzasadnione, jeżeli aplikacja jest krytyczna dla biznesu klienta, nie istnieje łatwy zamiennik, a dostawca jest niewielką firmą. Samo posiadanie kodu również nie rozwiązuje całego problemu. Trzeba mieć dokumentację, konfigurację, zależności i prawa do komponentów osób trzecich.

Cloud Exit a ciągłość działania

Zmiana dostawcy chmury powinna być częścią strategii ciągłości działania.

Firma powinna odpowiedzieć sobie na pytanie, co zrobi nie tylko wtedy, gdy sama postanowi zmienić operatora, ale również wtedy, gdy dostawca przestanie świadczyć usługę. Przyczyną może być upadłość, decyzja biznesowa, konflikt kontraktowy, sankcje, cyberatak albo utrata możliwości świadczenia usługi.

W tym kontekście Cloud Exit Plan powinien być regularnie aktualizowany. Plan przygotowany trzy lata wcześniej może nie uwzględniać nowych systemów, integracji i danych.

Czy plan migracji trzeba testować?

W krytycznych środowiskach zdecydowanie warto. Firma może posiadać dokument opisujący eksport danych, ale dopiero próba testowa pokaże, czy plik jest kompletny i czy można go rzeczywiście odtworzyć.

Nie zawsze trzeba przeprowadzać pełną migrację do konkurencyjnej chmury. Można wykonać test eksportu, próbne odtworzenie części danych albo sprawdzić dokumentację procesu.

Najważniejsze jest upewnienie się, że Cloud Exit nie jest jedynie teoretycznym załącznikiem do umowy.

Data Act a umowy już zawarte

Data Act ma znaczenie nie tylko dla nowych kontraktów. Przedsiębiorcy powinni przeanalizować istniejące umowy dotyczące usług przetwarzania danych i sprawdzić, czy procedury wyjścia odpowiadają wymaganiom rozporządzenia.

W szczególności warto zweryfikować okresy wypowiedzenia, eksport danych, opłaty, format eksportu, obowiązek pomocy, retencję oraz zasady usunięcia danych.

Jeżeli istniejący kontrakt przewiduje rozwiązania niezgodne z obowiązującymi przepisami, samo pozostawienie starej treści umowy nie oznacza, że dostawca może skutecznie korzystać z każdej przewidzianej w niej bariery.

Praktycznie jednak lepiej dostosować dokumentację i usunąć sprzeczności, niż pozostawiać ich ocenę na moment konfliktu.

Data Act a DORA

Dla podmiotów finansowych Cloud Exit ma dodatkowe znaczenie. DORA nakłada na podmioty finansowe rozbudowane obowiązki w zakresie zarządzania ryzykiem zewnętrznych dostawców ICT, w tym zapewnienia odpowiednich strategii wyjścia w przypadku usług wspierających funkcje krytyczne lub istotne.

Data Act i DORA nie są tym samym. Data Act tworzy ogólne zasady dotyczące możliwości zmiany dostawców usług przetwarzania danych.

DORA koncentruje się natomiast na odporności operacyjnej sektora finansowego i wymaga, aby zakończenie współpracy z dostawcą nie powodowało nieakceptowalnego zakłócenia działalności.

W praktyce instytucja finansowa powinna więc uwzględniać oba reżimy w jednym procesie Cloud Exit.

Data Act a NIS2

Podobny związek występuje z NIS2. Podmioty objęte NIS2 mają obowiązek zarządzać ryzykiem związanym z łańcuchem dostaw.

Uzależnienie od jednego dostawcy cloud może być istotnym ryzykiem ciągłości działania. Data Act ułatwia prawnie zmianę dostawcy, natomiast NIS2 wymaga spojrzenia na problem przez pryzmat cyberbezpieczeństwa i odporności organizacji.

Cloud Exit staje się więc elementem szerszego compliance technologicznego.

Jak powinien wyglądać audyt vendor lock-in?

Audyt powinien obejmować jednocześnie warstwę prawną i techniczną.

Po stronie umownej należy przeanalizować czas trwania kontraktu, wypowiedzenie, automatyczne przedłużanie, opłaty, eksport danych, prawa własności intelektualnej, obowiązki migracyjne i zasady korzystania z podwykonawców.

Po stronie technicznej należy ustalić, z jakich usług proprietary korzysta system, jakie formaty danych stosuje, które komponenty mogą zostać łatwo zastąpione oraz jak długo potrwa realna migracja.

Dopiero połączenie obu analiz daje rzetelną odpowiedź. Kontrakt może być idealny, ale system technologicznie niemożliwy do szybkiej migracji.

System może być również doskonale przenośny technicznie, ale klient może być związany wieloletnią umową uniemożliwiającą ekonomicznie uzasadnione wyjście.

Jak negocjować nową umowę cloud lub SaaS?

Najważniejsze jest odejście od myślenia, że exit clause jest postanowieniem potrzebnym dopiero przy sporze. Jest to normalny element cyklu życia usługi.

Podczas negocjacji trzeba ustalić format danych, czas migracji, zakres pomocy, usunięcie informacji po zakończeniu usługi, zasady okresu przejściowego i koszty.

Należy również zweryfikować, czy klient może skorzystać z usług konkurencyjnych równolegle. Warto zadbać o dokumentację i otwarte API.

Jeżeli system korzysta z wielu niestandardowych technologii dostawcy, klient powinien co najmniej wiedzieć, jaka jest cena tej wygody w postaci przyszłego kosztu migracji.

Najczęstsze błędy przy Cloud Exit

Najczęstszy błąd polega na braku jakiegokolwiek planu.

Drugi to utożsamianie prawa do eksportu danych z możliwością migracji systemu. Trzeci problem polega na braku ustalonego formatu eksportu. Często pomijane są metadane, konfiguracje i historia zdarzeń. Kolejnym problemem jest nieuwzględnienie integracji i komponentów proprietary.

Firmy zapominają również o testowaniu procesu oraz o zapewnieniu okresu równoległego działania. Po stronie umownej szczególnie niebezpieczne są długie okresy wypowiedzenia, automatyczne odnowienia i niejasne zasady dodatkowej pomocy.

W 2026 r. dodatkowo trzeba pamiętać o szybko zbliżającej się dacie 12 stycznia 2027 r., od której dostawcy nie będą mogli pobierać od klientów opłat z tytułu samego procesu zmiany dostawcy.

Czy Data Act rozwiąże problem vendor lock-in?

Nie całkowicie. Rozporządzenie znacząco poprawia pozycję klientów, ponieważ usuwa część barier kontraktowych i finansowych oraz wymusza większą przenośność danych.

Nie może jednak usunąć wszystkich zależności technologicznych. Firma, która przez kilka lat buduje rozwiązanie przy wykorzystaniu unikalnych usług jednej platformy, nadal może ponieść znaczący koszt przebudowy. Dlatego najlepszą ochronę daje połączenie prawa, architektury i zarządzania ryzykiem.

Data Act tworzy prawo do wyjścia. Dobrze zaprojektowany system sprawia, że z tego prawa można realnie skorzystać.

Podsumowanie

Data Act znacząco zmienił zasady korzystania z usług cloud i SaaS.

Klient nie powinien być już traktowany jako podmiot, który po wejściu do konkretnego ekosystemu technologicznego ma pozostawać w nim wyłącznie dlatego, że dostawca stworzył bariery ekonomiczne lub organizacyjne utrudniające migrację.

Rozporządzenie wymaga usuwania przeszkód przed zmianą dostawcy i nakazuje odpowiednio uregulować proces w umowie. Nie oznacza to jednak końca vendor lock-in.

Najbardziej trwałe uzależnienie nadal wynika z technologii, architektury aplikacji, praw własności intelektualnej i niedostatecznej dokumentacji. Dlatego Cloud Exit powinien być projektowany przed wejściem do chmury, a nie dopiero wtedy, gdy relacja z dostawcą zaczyna się psuć.

Przedsiębiorca powinien wiedzieć, jakie dane będzie mógł wyeksportować, w jakim formacie, kto pomoże przy migracji, jak długo potrwa proces oraz co stanie się z kopiami po jego zakończeniu. Szczególne znaczenie ma 12 stycznia 2027 r. Od tego dnia dostawcy usług przetwarzania danych nie będą mogli nakładać na klientów opłat z tytułu procesu zmiany dostawcy.

Nie eliminuje to kosztów przebudowy systemu ani usług nowego operatora, ale usuwa jeden z istotnych mechanizmów ekonomicznego uzależniania klienta od dotychczasowego dostawcy.

Z perspektywy umów IT najważniejszy wniosek jest prosty: dobry kontrakt cloud powinien regulować nie tylko sposób rozpoczęcia współpracy, ale również sposób jej zakończenia.

Przy zmianie dostawcy chmury warto zestawić te zasady z postanowieniami umowy SaaS oraz wymaganiami RODO dla przetwarzania danych w SaaS.